Какой минимальный набор шаблонов нужен, чтобы запустить приложение в Kubernetes?

Минимальный набор шаблонов Kubernetes для запуска приложения

Для запуска типичного stateless-приложения в Kubernetes минимально необходимый набор состоит из двух основных манифестов: Deployment и Service. Этот набор обеспечивает декларативное управление репликами приложения и доступ к нему как внутри кластера, так и извне. Однако в production-среде этот набор обычно расширяется.

1. Deployment — основа для управления подами

Deployment — это ключевой объект для декларативного описания желаемого состояния вашего приложения: какая версия образа, сколько реплик должно работать, как обновлять и откатывать.

Пример минимального deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 2  # Минимум две реплики для отказоустойчивости
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: myregistry/my-app:latest
        ports:
        - containerPort: 8080
        # Важно сразу добавить проверки жизнеспособности
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080

Deployment управляет созданием ReplicaSet, который, в свою очередь, гарантирует наличие нужного количества идентичных подов (Pod). Поды — это минимальная deployable единица, содержащая один или несколько контейнеров.

2. Service — единая точка доступа к подам

Service предоставляет стабильный сетевой endpoint (IP-адрес и DNS-имя) для доступа к группе подов, отобранных по селектору меток. Без Service доступ к подам был бы нестабильным, так как их IP-адреса меняются при рестартах и обновлениях.

Пример минимального service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app  # Должен совпадать с метками из Deployment
  ports:
  - protocol: TCP
    port: 80       # Порт, на котором Service принимает запросы
    targetPort: 8080  # Порт контейнера, куда перенаправлять трафик
  type: ClusterIP  # Тип по умолчанию — доступ только внутри кластера

Для доступа извне кластера потребуется Ingress (с контроллером, например, nginx-ingress) или изменение типа Service на LoadBalancer или NodePort.

3. Расширенный минимальный набор для production

Хотя двух вышеуказанных ресурсов технически достаточно для запуска, в реальной эксплуатации минимальный production-набор включает дополнительные компоненты:

• ConfigMap и/или Secret для отделения конфигурации и чувствительных данных от образа приложения.
• HorizontalPodAutoscaler (HPA) для автоматического масштабирования реплик на основе метрик (CPU, memory или кастомных).
• Ingress для маршрутизации HTTP/HTTPS трафика и организации доступа извне.
• PersistentVolumeClaim (PVC) — если приложению требуется постоянное хранилище.

Пример организованного набора файлов

my-app/
├── deployment.yaml       # Манифест Deployment с Pod template
├── service.yaml          # Service для внутреннего доступа
├── ingress.yaml          # Ingress для внешнего доступа (опционально)
├── configmap.yaml        # Конфигурационные данные
├── secret.yaml           # Секреты (хранить в зашифрованном виде!)
└── hpa.yaml              # Автомасштабирование

Практический совет: используйте Kustomize или Helm

Даже для минимального набора рекомендуется использовать инструменты управления конфигурацией:

• Kustomize (встроен в kubectl) для наложения патчей и управления окружениями.
• Helm для упаковки в чарты с параметризацией через values.yaml.

Пример kustomization.yaml для сборки минимального набора:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
  - configmap.yaml

Заключение

Минимальный набор для запуска — это Deployment + Service. Однако уже на этапе первого развертывания стоит добавить livenessProbe и readinessProbe в спецификацию контейнера, а также вынести конфигурацию в ConfigMap. Такой подход закладывает фундамент для отказоустойчивости, наблюдаемости и последующего масштабирования приложения в Kubernetes.

Итоговый список обязательных к рассмотрению шаблонов:

• Deployment — управление жизненным циклом приложения.
• Service — стабильный сетевой доступ.
• ConfigMap/Secret — управление конфигурацией (сильно рекомендуется).
• Ingress — если требуется внешний HTTP(S) доступ.
• HPA — для автоматического масштабирования (в production).