Как вы запускали новый код в Kubernetes?

В моих проектах на Node.js развертывание в Kubernetes было частью CI/CD-пайплайна. Вот типичный процесс:

1. Сборка и тегирование Docker-образа: После успешного прохождения тестов в GitLab CI/CD (или аналогичном инструменте) запускался скрипт сборки.

   # Определяем тег образа (например, по хэшу коммита или номеру сборки)
   IMAGE_TAG=$CI_COMMIT_SHA
   docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
   docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG

2. Обновление конфигурации развертывания: Для управления манифестами мы использовали Helm. Обновление сводилось к изменению значения тега образа в values.yaml или через команду.

   # Способ 1: Обновление через set (для простых случаев)
   helm upgrade --install my-app ./chart 
    --set image.tag=$IMAGE_TAG 
    --namespace production
   
   # Способ 2: Использование отдельного values-файла, который обновлялся в пайплайне

3. Стратегия обновления: В манифесте Deployment была настроена стратегия RollingUpdate. Это позволяло Kubernetes постепенно заменять старые поды новыми без простоя сервиса.

   spec:
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 25%
        maxSurge: 1

   Kubernetes сам управлял процессом: создавал под с новой версией, ждал его готовности (readiness probe), затем удалял один старый под, и так далее.

4. Проверки (Health Checks): Критически важны были livenessProbe и readinessProbe в конфигурации пода. Для Node.js-приложения это обычно HTTP-эндпоинт /health, который проверяет подключение к БД и другим критическим сервисам.

   livenessProbe:
    httpGet:
      path: /health
      port: 3000
    initialDelaySeconds: 30
    periodSeconds: 10

5. Откат (Rollback): В случае проблем (например, падение метрик в Prometheus после деплоя) откат выполнялся одной командой:

   helm rollback my-app 0 # Откат к предыдущему релизу
   # или
   kubectl rollout undo deployment/my-app

Таким образом, процесс был автоматизирован, предсказуем и позволял быстро реагировать на проблемы.