Ситуация. Вы сидите в высокой башне Фуфелшмерц Пакостин Корпорейшн, и вдруг во всем мире случается зомби‑апокалипсис. Очевидно, что у гениального ученого где‑то есть «инатор» для борьбы и выживания в таком случае.

Порывшись немного в кладовке, вы случайно находите главный сервер здания, где страшными буквами написано КуБеРнЕтИс СИ/СД Пипелайн (разумеется на русском). Слава Богу, что вас когда‑то в универе пытались научить чему‑то, и вы, вроде, что‑то начинаете вспоминать...

Осталось только придумать, как с помощью этого сервера раскатить защиту башни на распознавание зомби, а не Перри...

Вспомнив наставления своего мастера (и английский алфавит) вы вспомнили, что КуБерНеТиС на самом деле отлично подходит для настройки непрерывной интеграции и доставке (CI/CD), чтобы автоматически обновлять защиту башни и ~~мочить~~ защищаться от зомби.

Почему Kubernetes и зомби-апокалипсис?

Когда представляешь себе зомби‑апокалипсис, то понимаешь, что это хаос: толпы зомби, постоянные угрозы, уязвимости, и нет места для ошибок. Любая дырка в обороне — и башня пала. Это знакомо тем, кто хоть раз администрировал кластер Kubernetes.

Башня — это ваш кластер Kubernetes.
Выжившие устройства — это поды (pods).
Зомби — это любые угрозы: сбои, уязвимости, неудачные релизы, внезапные уроненные базы данных и всё что угодно.

Наша задача — построить такую архитектуру и процесс автоматических обновлений (CI/CD), чтобы башня выстояла при любой атаке.

Что такое CI/CD и зачем он нужен в условиях зомби‑апокалипсиса?

CI/CD — это две ключевые практики DevOps:

Непрерывная интеграция (CI): интеграция новых изменений в общий код и автоматическая проверка, что всё ещё держится крепко. Непрерывная доставка (CD): автоматическое выкатывание подтвержденных изменений (патчи безопасности, обновленные средства защиты) в реальную боевую среду (нашу «башню») с минимальными рисками.

В реальности зомби‑апокалипсиса это значит, что каждый новый «щит» или «баррикада» тестируется автоматически, и при успехе без задержек внедряется на передовую. Если вдруг обновление ломает ворота и зомби готовы ворваться, у нас есть механизмы быстрого отката.

Шаг 1: Настройка CI/CD Pipeline в Kubernetes с GitLab CI

Подготовка репозитория:

Создайте репозиторий в GitLab, где будет весь ваш код, плюс манифесты Kubernetes (например, deployment.yaml и другие необходимые файлы конфигурации). Убедитесь, что проект в GitLab подключён к GitLab CI (обычно это делается автоматически при наличии.gitlab‑ci.yml в корне репо).

Создание GitLab CI Pipeline:

Основной конфигурационный файл GitLab CI — это.gitlab‑ci.yml. Он описывает этапы нашего «сражения» против зомби: сборка (build), тестирование (test) и деплой (deploy).

Пример базового.gitlab‑ci.yml:

stages:
  - build
  - test
  - deploy

variables:
  DOCKER_REGISTRY: registry.gitlab.com
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE/myapp

before_script:
  - echo "Logging in to Docker registry"
  - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY

build:
  stage: build
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE

test:
  stage: test
  script:
    - docker run $DOCKER_IMAGE test

deploy:
  stage: deploy
  script:
    - kubectl apply -f kubernetes/deployment.yaml

build: Мы собираем Docker‑образ нашего приложения (это как подготовка новой ловушки для зомби) и отправляем его в реестр.
test: Затем запускаем тесты внутри контейнера, чтобы убедиться, что ловушка работает и зомби не смогут её сломать.
deploy: И наконец, применяем YAML‑манифесты к кластеру Kubernetes, чтобы «натянуть» ловушку на городские стены.
Чтобы Kubernetes не подумал, что вы зомби, нужно настроить доступы. В GitLab это делается просто:
1. Идёте в Settings → CI/CD → Variables.
2. Указываете секреты:
- $CI_REGISTRY_IMAGE (автоматическая переменная GitLab).
- $CI_JOB_TOKEN (также выдаётся GitLab).
- $KUBECONFIG или другие настройки, чтобы kubectl работал с вашим кластером.

Шаг 2: Rolling Updates и Canary Deployments для минимизации рисков

Обновление по частям

Rolling update — это когда вы постепенно обновляете приложение, заменяя старые версии новыми. Представьте, что у вас есть три бойца на балконе Башни, и вы меняете их по очереди, чтобы Башня не оставалась без защиты.

Вот пример Deployment‑манифеста:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: survivor-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: survivor
  template:
    metadata:
      labels:
        app: survivor
    spec:
      containers:
      - name: survivor-container
        image: nginx:latest
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

Здесь Kubernetes будет обновлять поды постепенно: пока запускается новый «боец», старый продолжает работать. Только когда новичок будет готов к бою, система выведет из боя предыдущего воина.

Canary Deployments

Canary Deployment — это когда новую версию выпускают «потихоньку» для небольшой части пользователей или трафика. Это как когда в тёмном переулке сначала посылают одну группу бойцов на разведку. Если они не стали обедом для зомби, значит, обновление хорошее — можно выпускать его для всех.

Для Canary Deployment часто используют Argo Rollouts. Там можно указать, сколько процентов подов нужно обновить на новом образе.

apiVersion: rollouts.k8s.io/v1alpha1
kind: Rollout
metadata:
  name: survivor-rollout
spec:
  replicas: 3
  strategy:
    canary:
      steps:
      - setWeight: 50
      - pause: {}
      - setWeight: 100
  template:
    spec:
      containers:
      - name: survivor-container
        image: nginx:latest

Сначала на новой версии «супероружия» будет 50% всего функционала. Если тесты пройдут успешно и всё будет работать как надо, то добавим ещё 50%.

Шаг 3: Автоматическое тестирование и откат изменений

Чтобы всё работало как надо, нужно провести тесты.

Для этого пишем юнит‑тесты (JUnit, PyTest, Go test — что угодно).

Ещё пишем интеграционные тесты (Selenium, Cypress — смотрим, всё ли работает как надо).
Можно даже провести нагрузочное тестирование (JMeter, Locust), чтобы проверить, выдержит ли система наплыв «зомби».

Все эти тесты выполняются в этапе test (в GitLab CI это удобно настроить в.gitlab‑ci.yml). Если что‑то пошло не так, можно быстро откатить изменения. Даже самый продуманный план может дать сбой. Поэтому очень важно быстро сделать «назад, пока не поздно!».

Для этого есть команда отката в kubectl.

kubectl rollout undo deployment/survivor-deployment

Она откатит всё назад до предыдущей версии.
Helm и Argo Rollouts тоже умеют откатывать, если вы ими пользуетесь для управления релизами.

В условиях зомби‑апокалипсиса это как иметь секретный ход к убежищу: если новая дверь оказалась ненадёжной и в город проникли зомби, мы быстро закрываем этот проход и возвращаемся к старой проверенной двери.

Заключение: Защита города с помощью CI/CD в Kubernetes

Мы разобрались, как настроить непрерывную интеграцию и непрерывное развёртывание (CI/CD) в Kubernetes с помощью GitLab CI. Это значит, что вы сможете:

Быстро создавать и выпускать новые «защитные устройства».
Постоянно тестировать их, чтобы не было неожиданностей.
Минимизировать риски с помощью постепенных обновлений и выборочного развёртывания.
Моментально откатываться, если что‑то пошло не так.

С этими практиками ваша «Башня» будет в безопасности — зомби (и любые другие проблемы, будь то ошибки или неожиданные сбои) не смогут ее захватить.

Пусть ваш Kubernetes‑кластер процветает, копии подов бдительно охраняют периметр, а тестовые сценарии отражают все атаки. И когда вы услышите зловещее «брааайнз!» или «проооод!» за воротами, просто проверьте логи вашей системы CI/CD — и спите спокойно: автоматика на страже!

Как автоматизировать оборону города с помощью Kubernetes CI/CD Pipeline: защита от зомби через автоматические обновления