Kubernetes, GitOps и SRE: промышленная эксплуатация

Четвёртый урок раздела. Когда сервисов и инстансов становится много, ручное управление перестаёт масштабироваться: никто не уследит за сотней контейнеров на десятке машин. Здесь три ответа, которые работают вместе. Kubernetes даёт декларативный оркестратор. GitOps делает git единственным источником истины. SRE переводит надёжность из ощущений в измеримые цели. Урок концептуальный: важнее понять модель, чем запомнить флаги kubectl.

Идея: reconciliation loop

В основе Kubernetes одна идея, и она объясняет почти всё его поведение. Ты описываешь желаемое состояние (сколько реплик, какой образ, какие сети), а кластер непрерывно крутит цикл сверки: сравнивает факт с желаемым и устраняет разницу. Упал под, контроллер поднимет новый. Указал три реплики, а живы две, поднимет третью. Ты не командуешь “запусти контейнер”, ты декларируешь “пусть их будет три”, а как этого добиться, решает кластер.

Из этой идеи выводятся примитивы:

• Pod: минимальная единица, один или несколько контейнеров вместе.
• Deployment: держит N реплик и катит новые версии rolling-апдейтом.
• Service: постоянный адрес и балансировка на эфемерные поды.
• Ingress: входная дверь снаружи, маршрутизация по хосту и пути.
• Namespace: логический раздел кластера (dev, staging, команда).

apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
  replicas: 3
  selector: { matchLabels: { app: api } }
  template:
    metadata: { labels: { app: api } }
    spec:
      containers:
        - name: api
          image: registry/api:1.4.2
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }

readinessProbe это тот же health-check: пока он не прошёл, под не получает трафик. Именно поэтому rolling-апдейт в Kubernetes идёт без простоя: новый под начинает принимать запросы только когда готов.

Шаблонизация манифестов

Манифестов быстро становится много, и их параметризуют. Helm упаковывает приложение в чарт с параметрами в values.yaml, а Kustomize накладывает патчи на базовые манифесты без шаблонов. Выбирают по вкусу: Helm мощнее для переиспользуемых пакетов, Kustomize проще для своих приложений.

GitOps: git как источник истины

GitOps это reconciliation loop, расширенный на git. Желаемое состояние лежит не в чьей-то голове и не в ручных kubectl apply, а в git-репозитории. Контроллер (ArgoCD или Flux) следит за репозиторием и приводит кластер к тому, что в нём записано.

Что это даёт:

• Деплой это коммит, откат это git revert. Никаких ручных команд в прод.
• Аудит бесплатно: git-история отвечает, кто, что и когда менял.
• Защита от дрейфа: если кто-то поправил кластер руками, контроллер вернёт его к состоянию из git. Реальность не расходится с описанием.

Деплой превращается в обычный PR: ревью, мерж, и контроллер выкатывает. Это тот же принцип воспроизводимости, что и IaC, доведённый до непрерывной сверки.