Перейти на PRO

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

Тип вопроса: DevOps Вероятность: 26% Категория: Node.js Разработчик

Ответ

В моих проектах на 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

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

Ответ 18+ 🔞

Ну и история, блядь, с этими деплоями в кубере! Как будто на дворе 2002-й год, а не современная разработка. Слушай, я тебе сейчас так распишу, что ты сам от себя охуеешь от простоты.

В общем, у меня в Node.js проектах этот цирк с Kubernetes был впаян прямо в CI/CD пайплайн. Представляешь? Автоматизация, ёпта, полная — чтобы руками не ебаться каждый раз.

Первым делом, конечно, сборка и тегирование Docker-образа. После того как все тесты в GitLab CI/CD пролетели удачно (а если нет — всем пидарасам шерстяным по шапке), запускался скрипт. Тут всё просто, как хуй с горы:

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

Толкаем образ в registry и поехали дальше. Дальше самое интересное — обновление конфигурации развертывания. Мы для управления этими манифестами использовали Helm, чтобы не ебаться с кучей yaml-файлов. Обновление сводилось к тому, чтобы подменить тег образа. Делалось это либо через прямое указание в команде, либо через файл values.yaml.

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

# Способ 2: Использование отдельного values-файла, который обновлялся в пайплайне

Дальше — магия. Чтобы сервис не ложился на время обновления, в манифесте Deployment была настроена стратегия RollingUpdate. Это, блядь, гениальная штука! Кубер сам, как хитрая жопа, постепенно заменяет старые поды новыми.

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

Он создаёт новый под, ждёт, пока тот скажет «я готов» (это вот readiness probe), потом один старый удаляет. И так по кругу, пока все не обновились. Красота, ёбана!

А про проверки (Health Checks) я тебе что скажу? Это святое! Без livenessProbe и readinessProbe — вообще никуда. Для Node.js-приложения мы всегда делали HTTP-эндпоинт /health, который проверял, жива ли база данных и прочая требуха.

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

Если проба не проходит — кубер сам понимает, что под сдох, и убивает его. Автоматизация, ёпта!

Ну и главный козырь — откат (Rollback). Вдруг после деплоя метрики в Prometheus поползли вниз, как угарелые? Без паники! Одна команда — и ты уже в прошлом.

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

Вот и весь сказ. Процесс получается автоматизированный, предсказуемый, и если что-то пошло не так — терпения ноль ебать, откатываемся за секунды. Удобно, блядь, как вилкой в глаз!

© ХакСобесов, 2026
support@hacksobesov.com