Приходилось ли вам проектировать Kubernetes-манифесты (Deployments, Services и т.д.)?

«Приходилось ли вам проектировать Kubernetes-манифесты (Deployments, Services и т.д.)?» — вопрос из категории DevOps, который задают на 10% собеседований Java Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Да, проектировал и описывал Kubernetes-ресурсы для развертывания приложений. Ключевые принципы:

  • Stateless vs Stateful: Для stateless-сервисов используется Deployment, для stateful (с постоянным хранилищем) — StatefulSet.
  • Конфигурация и секреты: Вынос конфигурации в ConfigMap, а чувствительных данных (пароли, токены) — в Secret. Никогда не хардкодить в образ.
  • Пробы здоровья: Обязательное определение livenessProbe (перезапуск контейнера) и readinessProbe (исключение из балансировки нагрузки) для контроля состояния.
  • Управление ресурсами: Указание requests (гарантированные ресурсы) и limits (максимальный лимит) для CPU и памяти, чтобы избежать contention на ноде.
  • Сетевая политика: Использование NetworkPolicy для изоляции трафика между подами.

Пример манифеста Deployment для Spring Boot приложения:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: app
        image: my-registry/backend:1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080

Также проектировал Service для доступа к подам, HorizontalPodAutoscaler для автоматического масштабирования и использовал affinity/anti-affinity правила для распределения подов по нодам.