Какие объекты Kubernetes нужно создать, чтобы задеплоить сервис

Объекты Kubernetes для развертывания сервиса

Чтобы задеплоить сервис в Kubernetes, необходимо создать несколько взаимосвязанных объектов, которые обеспечат его работоспособность, сетевое взаимодействие, управление версиями и устойчивость. Вот ключевые объекты, которые я создаю в 99% случаев:

1. Deployment — основной объект для управления подами

Это основной контроллер для развертывания и управления репликами подов (Pods). Он обеспечивает декларативное обновление, откат и масштабирование.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: myregistry/my-app:1.0.0
        ports:
        - containerPort: 8080
        env:
        - name: ENV_VAR
          value: "production"
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"

Важные аспекты:

• Selector связывает Deployment с подами
• Replicas определяет количество экземпляров
• Template описывает спецификацию пода
• Resources устанавливает лимиты и запросы для управления QoS

2. Service — для сетевого доступа

Сервис обеспечивает стабильную конечную точку для доступа к подам, которые могут динамически создаваться и уничтожаться.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  type: ClusterIP

Типы сервисов:

• ClusterIP (по умолчанию) — доступ только внутри кластера
• NodePort — открывает порт на всех нодах
• LoadBalancer — создает внешний балансировщик нагрузки (в облачных провайдерах)
• ExternalName — CNAME-запись для внешнего сервиса

3. ConfigMap и Secret — для конфигурации

ConfigMap для некритичной конфигурации, Secret для чувствительных данных.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
data:
  application.properties: |
    server.port=8080
    logging.level=INFO

apiVersion: v1
kind: Secret
metadata:
  name: my-app-secret
type: Opaque
data:
  db-password: c2VjcmV0UGFzc3dvcmQ=  # base64 encoded

4. HorizontalPodAutoscaler (HPA) — для автоматического масштабирования

Автоматически увеличивает количество подов при высокой нагрузке.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

5. Ingress — для маршрутизации внешнего трафика (опционально)

Управляет входящим HTTP/HTTPS трафиком, предоставляет возможности маршрутизации на основе пути или хоста.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

Дополнительные объекты для production-развертывания

• PodDisruptionBudget (PDB) — гарантирует минимальное количество доступных подов во время добровольных сбоев
• ServiceAccount — для управления правами доступа пода к API Kubernetes
• NetworkPolicy — для контроля сетевого трафика между подами
• PersistentVolumeClaim (PVC) — для работы с постоянным хранилищем
• StatefulSet — для stateful-приложений (базы данных и т.д.)
• Liveness и Readiness Probes — проверки здоровья в спецификации контейнера

Практический подход к деплою

Я обычно начинаю с минимального набора:

1. Deployment с 2-3 репликами
2. Service типа ClusterIP
3. ConfigMap/Secret для конфигурации

Затем добавляю по мере необходимости:

• Ingress для внешнего доступа
• HPA для автоматического масштабирования
• Resource limits для контроля потребления
• Probes для мониторинга здоровья

Для управления этими объектами я использую kustomize или helm charts, которые позволяют параметризировать конфигурации для разных сред (dev/staging/production).

Важное замечание: Все эти объекты создаются декларативно через YAML-манифесты, что соответствует принципам Infrastructure as Code (IaC) и позволяет версионировать, ревьюить и автоматизировать процесс развертывания.