Что реально даёт кластер

• Самовосстановление. Процесс упал, kubelet перезапустил контейнер. Нода умерла, контроллер увидел, что подов меньше, чем в spec.replicas, и создал новые на других нодах. Никто не звонит дежурному.
• Service discovery без внешнего реестра. Адрес зависимости живёт в DNS: billing.prod.svc.cluster.local вместо списка IP в конфиге, который протухает при каждом перезапуске.
• Управляемая выкатка. Rolling update с контролем скорости и автоматической остановкой, если новые поды не становятся Ready. Откат делается одной командой, потому что старый ReplicaSet никуда не делся.
• Bin-packing и изоляция ресурсов. Планировщик раскладывает поды по нодам, глядя на requests, а cgroups не дают одному сервису съесть ноду.
• Горизонтальное масштабирование по метрике делает HPA, а ноды добавляет Cluster Autoscaler.
• Единый декларативный интерфейс. Вся конфигурация инфраструктуры живёт в git как YAML и применяется идемпотентно. На этом и стоит GitOps.

Объекты снизу вверх

• Pod планируется как единое целое: один или несколько контейнеров, которые делят network namespace (общий localhost и один IP) и могут делить тома. Под смертен и почти неизменяем: на месте меняются только образ контейнера и (с 1.35) ресурсы, остальное не «обновить», можно только удалить и создать новый под, уже с другим IP. Всё, что ты пишешь про «под перезапустился», почти всегда означает «перезапустился контейнер внутри того же пода» (restartCount растёт, IP не меняется).
• ReplicaSet держит один инвариант: «подов с такими labels должно быть ровно N». Руками его почти никогда не создают.
• Deployment управляет ReplicaSet-ами и задаёт стратегию обновления: на каждую версию pod-шаблона создаётся свой ReplicaSet, а деплой перекачивает реплики из старого в новый. Старые RS остаются (revisionHistoryLimit), поэтому rollout undo просто возвращает старый шаблон, а реплики перекачиваются обратно тем же rolling update.
• Service даёт стабильное имя и виртуальный IP меняющемуся множеству подов. Живёт над labels, а не над подами напрямую.
• Ingress описывает L7-маршрутизацию снаружи внутрь: хост, путь, TLS. Сам по себе это просто объект-описание; работает он, только если в кластере есть ingress-контроллер (Traefik, HAProxy, NGINX Ingress Controller от F5), который читает эти объекты и перенастраивает себя. API Ingress заморожен: Kubernetes рекомендует Gateway API.
• ConfigMap / Secret держат конфигурацию и чувствительные данные отдельно от образа.
• Рядом: StatefulSet (стабильные имена и своё хранилище на реплику, нужен для БД, Kafka, всего, где реплики не взаимозаменяемы), DaemonSet (по одному поду на каждую ноду, так живут агенты логов и метрик), Job/CronJob (разовые и периодические задачи), PVC (заявка на диск).

Типы Service - что за чем стоит

Именно поэтому наружу обычно торчит один LoadBalancer, за ним ingress-контроллер, а дальше уже десятки ClusterIP-сервисов: платить за LB на каждый микросервис никто не хочет, да и TLS с маршрутизацией по хостам всё равно нужны в одном месте.

Разница между объектами

Secret отличается от ConfigMap тремя вещами, и ни одна из них не даёт шифрования: в API значения передаются в base64 (это кодирование, а не защита), к секретам обычно применяют отдельные RBAC-правила, и kubelet держит их в tmpfs, а не на диске ноды. В etcd секрет лежит открытым текстом, пока на API-сервере не включён EncryptionConfiguration. Практический вывод: кто унёс бэкап etcd, унёс все пароли, а право get secrets в неймспейсе равно знанию всех паролей этого неймспейса.

env против volume - разница принципиальная

• env/envFrom. Значения подставляются в момент execve и после этого заморожены навсегда. Правка ConfigMap проходит мимо: spec Deployment-а не поменялся, значит поды пересоздавать незачем. Плюс значения видны в crictl inspect на ноде, в /proc/PID/environ, наследуется всеми дочерними процессами и регулярно попадает в креш-дампы и в трассировки паник.
• Volume. kubelet проецирует ключи как файлы через симлинки и обновляет их при изменении объекта, но не мгновенно, а с задержкой до пары минут (период синхронизации kubelet плюс задержка его кэша). Обновление атомарное: подменяется симлинк на новый каталог, так что частично записанного файла приложение не увидит. Секрет файлом можно ротировать без рестарта, и это главный аргумент.

Есть ещё immutable: true: помеченный так ConfigMap или Secret нельзя изменить (только удалить и создать заново), зато kubelet закрывает на него watch, и на больших кластерах это заметно снимает нагрузку с API-сервера.

Как правильно перезапускать поды на смену конфига

# Helm-идиома: хеш конфига в аннотации pod-шаблона.
# Меняется ConfigMap -> меняется аннотация -> меняется шаблон -> честный rolling update.
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

# Без Helm то же самое руками:
kubectl rollout restart deployment/app      # проставит kubectl.kubernetes.io/restartedAt

# Посмотреть, что реально лежит в секрете:
kubectl get secret app-secrets -o jsonpath='{.data.db_password}' | base64 -d

Что проверять в каждой

Как пробы роняют сервис - четыре сценария

1. БД в liveness. База моргнула на 30 секунд. Liveness падает у всех подов сразу, kubelet перезапускает их все, поды стартуют, снова не видят базу, снова умирают, и весь сервис уходит в CrashLoopBackOff. Проблема была на полминуты, а недоступность растянулась на десять минут. Правильно проверять БД в readiness. Тогда поды живы, соединения переустановятся сами, и как только база вернётся, трафик пойдёт без единого рестарта.
2. Слишком короткий liveness при медленном старте. Приложение поднимается 40 секунд (миграции, прогрев кэша), initialDelaySeconds: 10, порог 3, период 5. Контейнер убивают на 20–25-й секунде, и он никогда не стартует. Раньше это лечили большим initialDelaySeconds, но тогда зависший под тоже не перезапускался бы полминуты. Правильно ставить startupProbe: бюджет failureThreshold × periodSeconds задаётся щедро (скажем, 30 × 5 = 150 с), а после успеха liveness работает с жёсткими нормальными таймингами.
3. Тяжёлая проба. Readiness, которая на каждый вызов делает SELECT с диска, под нагрузкой начинает отваливаться по таймауту. Поды по очереди выпадают из балансировки, нагрузка перераспределяется на оставшихся, те тоже перестают успевать. Каскад. Проба должна быть дешёвой: читать заранее посчитанный флаг, а не ходить в базу синхронно.
4. Общий пул горутин/потоков. Если хендлер пробы обслуживается тем же сервером, что забит запросами, проба падает не потому, что сервис мёртв, а потому что он занят. Отсюда практика: отдельный порт и отдельный http.Server для /healthz и /readyz, не проходящий через общий middleware, rate limit и очередь.

startupProbe:                 # бюджет на старт: 30 × 5 = 150 секунд
  httpGet: { path: /readyz, port: 8081 }
  periodSeconds: 5
  failureThreshold: 30
readinessProbe:               # быстро выводим из ротации и быстро возвращаем
  httpGet: { path: /readyz, port: 8081 }
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 2
  successThreshold: 1
livenessProbe:                # долго терпим и только потом убиваем
  httpGet: { path: /healthz, port: 8081 }
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 6

Механика

• requests используются прежде всего при планировании: scheduler ищет ноду, где сумма requests всех подов плюс наш под влезает в allocatable. После размещения requests продолжают работать для CPU как вес: requests.cpu: 500m превращается в cpu.weight в cgroup v2, то есть в долю при конкуренции. Память requests не ограничивают вообще, это чисто учётная величина (по ней же считаются OOM-скоринг и порядок вытеснения).
• limits.cpu задаёт жёсткую квоту CFS: cpu.max, то есть «не больше X микросекунд процессорного времени за период 100 мс». Исчерпал квоту, и тебя останавливают до конца периода. Это троттлинг: процесс не падает, он просто стоит, и это видно как рост latency при низкой средней утилизации CPU.
• limits.memory превращается в memory.max. Превысил, и ядро вызывает OOM-killer внутри cgroup. На cgroup v2 kubelet (с 1.28) по умолчанию включает групповой OOM-kill, так что гибнут все процессы контейнера разом, а не один самый прожорливый. Никакого предупреждения, никакого шанса «освободить память»: SIGKILL, exit code 137.

QoS-классы: кого выселят первым

С QoS связаны две разные вещи, которые часто путают. Eviction устраивает kubelet, когда на ноде кончается память: выселяет поды по превышению requests и приоритету. При жёстком пороге (по умолчанию настроены только такие) под убивают почти без grace period, при мягком дают урезанный. OOMKill устраивает ядро, когда контейнер упёрся в собственный limits.memory: мгновенно и без разговоров. Первое видно как Evicted в статусе пода, второе как OOMKilled в lastState контейнера.

Диагностика OOMKilled

kubectl describe pod app-7d9f8b6c5d-xk2wq | sed -n '/Last State/,/Restart Count/p'
# так выглядит блок в kubectl 1.37 (время условное):
#   Last State:     Terminated
#     Reason:       OOMKilled
#     Exit Code:    137          # 128 + 9 (SIGKILL)
#     Started:      Thu, 17 Sep 2026 10:41:02 +0300
#     Finished:     Thu, 17 Sep 2026 10:44:19 +0300
#   Ready:          True
#   Restart Count:  4

kubectl get pod app-7d9f8b6c5d-xk2wq -o jsonpath='{.status.containerStatuses[0].lastState}'
kubectl logs app-7d9f8b6c5d-xk2wq --previous  # логи убитого контейнера, а не нового
kubectl top pod -l app=billing --containers   # текущее потребление (нужен metrics-server)

# На ноде это подтвердит ядро:
dmesg -T | grep -i -E 'oom|killed process'

Дальше вопрос сводится к «это утечка или просто мало памяти». Различить их помогает форма графика RSS: ровная пила с растущим основанием выдаёт утечку; ступенька под нагрузкой говорит, что лимит просто мал; одиночный всплеск значит, что какой-то запрос тянет в память гигантский ответ или файл целиком. Для Go дальше идут pprof (/debug/pprof/heap, сравнение двух снимков через go tool pprof -base) и метрики рантайма: go_memstats_heap_inuse_bytes, go_memstats_heap_idle_bytes, go_goroutines. Если число горутин растёт, почти наверняка течёт и память.

Как считает

Формула такая: desired = ceil(current × (metric / target)). Если 4 пода при целевых 60 % CPU показывают 90 %, HPA хочет ceil(4 × 90/60) = 6. Есть зона нечувствительности (по умолчанию 10 %), чтобы не дёргаться на шуме, и есть behavior, политики скорости: вверх обычно разрешают быстро, вниз медленно (stabilizationWindowSeconds: 300 на scale down по умолчанию), потому что за лишнюю реплику платишь деньгами, а за преждевременное снятие отказом.

Источники метрик: metrics-server (CPU/память подов, тип Resource), custom.metrics и external.metrics через адаптер (обычно prometheus-adapter или KEDA) - оттуда берутся RPS, длина очереди Kafka, глубина RabbitMQ, что угодно.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: api }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
  minReplicas: 4
  maxReplicas: 40
  metrics:
    - type: Resource                       # база: не даём упереться в CPU
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 60 }
    - type: Pods                           # основное: запросов в секунду на под
      pods:
        metric: { name: http_requests_per_second }
        target: { type: AverageValue, averageValue: "120" }
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies: [{ type: Percent, value: 100, periodSeconds: 30 }]   # можно удваиваться
    scaleDown:
      stabilizationWindowSeconds: 300
      policies: [{ type: Percent, value: 10, periodSeconds: 60 }]    # снимаем по чуть-чуть

Когда метрик несколько, HPA считает желаемое число по каждой и берёт максимум - то есть метрики работают как «или», а не как «и». Это удобно: CPU остаётся страховкой, когда бизнес-метрика ведёт себя нетипично.

Почему CPU часто врёт

• I/O-bound сервис не грузит CPU. Go-сервис, который ходит в базу и в три соседних API, при полном насыщении по latency показывает 25 % CPU: горутины стоят в ожидании сети. HPA по CPU не сработает. Сервис уже деградировал, а автоскейлер спокоен.
• Utilization считается от requests, а не от лимита и не от ядра ноды. Занизили requests, и «утилизация» показывает 300 %, HPA раздувает деплой на пустом месте. Завысили - HPA сработает поздно или не сработает вовсе. Метрика зависит от цифры, которую человек написал в манифесте.
• Троттлинг маскирует нагрузку. Под упёрся в квоту CFS: latency растёт, а cpu utilization держится ровно на лимите и выше не идёт. Сигнал есть в container_cpu_cfs_throttled_seconds_total, но HPA его не видит.
• Старт нового пода стоит CPU. Прогрев, JIT-подобные эффекты, установка пула соединений - новый под первые секунды жрёт больше, чем работающий. Пока под не стал Ready, HPA его CPU не учитывает (первые 5 минут после старта), но прогрев после readiness попадает в среднее и подталкивает HPA к следующему шагу. Отсюда «эффект качелей», если behavior не настроен.
• Средняя по подам скрывает перекос. Один под с «горячим» ключом нагружен на 100 %, три остальных на 10 %, в среднем выходит 32,5 %, HPA доволен, пользователи нет.

Параметры и что они означают на практике

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%          # можно временно иметь до 13 подов
      maxUnavailable: 0      # но ни одного меньше 10 доступных
  minReadySeconds: 10        # под считается доступным, только продержавшись Ready 10 с
  progressDeadlineSeconds: 600
  template:
    spec:
      terminationGracePeriodSeconds: 45
      containers:
        - name: app
          lifecycle:
            preStop:
              sleep: { seconds: 10 }   # дать время эндпоинтам разойтись

• maxUnavailable: 0 + maxSurge: 25% - безопасный выбор для сервисов, которые нельзя просаживать (по умолчанию оба параметра 25 %, процент maxSurge округляется вверх, maxUnavailable - вниз): сначала поднимаем новые, и только когда они Ready, гасим старые. Взамен нужен запас ресурсов на ноде.
• maxSurge: 0 + maxUnavailable: 1 берут, когда ресурсов в обрез или под держит эксклюзивный ресурс (лицензия, GPU, единственный PVC ReadWriteOnce). Правда, во время выкатки ёмкость меньше номинала.
• minReadySeconds недооценивают зря. Без него под, который стал Ready и через секунду упал, считается успешным, и выкатка едет дальше, убивая старые. С ним поломанный релиз останавливается сам.
• progressDeadlineSeconds задаёт, через сколько выкатка признаётся провалившейся (Progressing=False). Она не откатывается автоматически, просто останавливается; откатывать будешь ты сам или шаг CI.

Гонка, из-за которой теряются запросы

Удаление пода - это всего лишь deletionTimestamp и grace period в etcd. Дальше на него независимо реагируют две цепочки:

1. Быстрая: kubelet видит удаление → вызывает preStop → шлёт SIGTERM процессу → ждёт terminationGracePeriodSeconds → SIGKILL.
2. Медленная: EndpointSlice-контроллер помечает адрес в EndpointSlice как не готовый (terminating) → это событие разъезжается по всем нодам → kube-proxy на каждой ноде переписывает правила iptables/nftables → и параллельно ingress-контроллер обновляет свой апстрим, а облачный LB правит свой target group (это может занимать десятки секунд).

Вторая цепочка почти всегда финиширует позже первой. Значит, есть окно, в котором процесс уже начал закрываться, а трафик на него всё ещё направляют: клиент получает connection refused или обрыв соединения. Поэтому preStop: sleep 5..15 стал стандартной практикой: в этот момент процесс ещё полностью работоспособен и обслуживает запросы, а система успевает узнать, что под уходит.

Правильная последовательность выключения

1. Под помечен на удаление: адрес метят notReady по самому deletionTimestamp, readiness для этого не нужна. Отдавать 503 в коде по SIGTERM всё равно стоит - это видят балансировщики, которые сами проверяют под своим health check или при дренаже смотрят на условие serving завершающегося адреса, - но случится это уже после preStop.
2. preStop: sleep на время, заведомо большее, чем задержка распространения эндпоинтов в твоей инсталляции (5–15 секунд, для облачных LB бывает больше). Трафик за это время перетекает на другие поды.
3. SIGTERM → в коде srv.Shutdown(ctx): сервер перестаёт принимать новые соединения, но дожидается текущих запросов.
4. Закрываются фоновые воркеры и консьюмеры (дообработать сообщение и закоммитить оффсет), затем пул БД, затем flush метрик и трейсов.
5. Процесс выходит сам, не дожидаясь SIGKILL.

ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, syscall.SIGINT)
defer stop()

go func() { _ = srv.ListenAndServe() }()

<-ctx.Done()                 // пришёл SIGTERM
ready.Store(false)           // 1) /readyz -> 503 для балансировщиков с health check
stop()                       // вернуть дефолтную обработку сигналов: второй Ctrl+C убьёт сразу

sh, cancel := context.WithTimeout(context.Background(), 30*time.Second) // < terminationGracePeriod
defer cancel()
if err := srv.Shutdown(sh); err != nil {   // 2) дожидаемся активных запросов
    _ = srv.Close()                        //    не дождались, рвём принудительно
}
workers.Wait()               // 3) фоновые задачи и консьюмеры
db.Close()                   // 4) пул соединений
tp.Shutdown(sh)              // 5) flush трейсов и метрик

Тайминги надо свести: terminationGracePeriodSeconds должен быть больше, чем preStop + максимальное время обработки запроса. Grace period отсчитывается с момента удаления и включает в себя время preStop - если поставить preStop 30 с при grace 30 с, SIGTERM придёт лишь за 2 секунды до SIGKILL, и дообработать запросы процесс не успеет.

Шаг за шагом

1. Сборка и публикация образа. CI собирает multi-stage Dockerfile, тегирует образ неизменяемым тегом (git SHA, а не latest) и пушит в registry. Заодно стоит подписать образ и приложить SBOM.
2. Обновление манифеста. Меняется тег образа в Helm-values / kustomize-overlay. При GitOps это коммит в репозиторий конфигурации, который подхватывает Argo CD или Flux; при push-модели это helm upgrade прямо из CI.
3. API-сервер. Принимает объект: аутентификация → авторизация (RBAC) → admission (mutating - сюда влезают sidecar-инжекторы service mesh и defaulting) → валидация схемы объекта → admission (validating - сюда OPA/Kyverno, «без лимитов не пущу») → запись в etcd. На этом kubectl apply возвращает управление. Дальше всё асинхронно.
4. Deployment-контроллер видит новый template, считает его хеш и создаёт новый ReplicaSet, начиная перекачивать реплики из старого по правилам maxSurge/maxUnavailable.
5. ReplicaSet-контроллер создаёт Pod-объекты, пока без ноды (nodeName пуст, статус Pending).
6. Scheduler для каждого такого пода прогоняет две фазы: filter (какие ноды вообще подходят: хватает ли allocatable под requests, проходят ли nodeSelector, affinity, taints/tolerations, есть ли нужный том) и score (какая из подходящих лучше: балансировка, spread по зонам, уже скачанный образ). Победителю проставляется nodeName - это тоже просто запись в etcd.
7. kubelet нужной ноды видит «мой под»: монтирует тома и секреты, через CRI просит runtime создать sandbox (pause-контейнер, который держит network namespace), и runtime зовёт CNI за IP. Дальше для каждого контейнера kubelet тянет образ согласно imagePullPolicy (при необходимости - с imagePullSecrets) и запускает его: сначала init-контейнеры по очереди, затем основные (containerd → runc → namespaces + cgroups + процесс).
8. Пробы. startup держит остальные выключенными, потом readiness решает, пора ли пускать трафик.
9. EndpointSlice-контроллер помечает адрес пода в срезе готовым, kube-proxy на каждой ноде правит iptables/nftables, ingress-контроллер обновляет апстримы - и запросы поехали в новый под.
10. Старые поды гасятся по описанной выше процедуре (preStop → SIGTERM → grace → SIGKILL), Deployment досчитывает реплики и переходит в Progressing: NewReplicaSetAvailable.

# Как это выглядит в командах
docker build -t registry.local/app:$(git rev-parse --short HEAD) .
docker push registry.local/app:9f3c2a1

kubectl set image deploy/app app=registry.local/app:9f3c2a1   # или helm upgrade
kubectl rollout status deploy/app --timeout=5m                # ждём и падаем по таймауту
kubectl rollout undo   deploy/app                             # если что-то не так

# 1. Что происходит
kubectl get pods -l app=billing -o wide          # + нода и IP пода
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
kubectl get events --sort-by=.lastTimestamp -A | tail -40   # события всего кластера
kubectl get deploy,rs,endpointslices -l app=billing   # оба поколения RS и адреса за Service

# 2. Почему под в таком состоянии: секция Events внизу
kubectl describe pod billing-6f8c9d7b54-2xk9q

# 3. Логи
kubectl logs billing-6f8c9d7b54-2xk9q -c app --tail=200 -f
kubectl logs billing-6f8c9d7b54-2xk9q --previous   # логи упавшего контейнера
kubectl logs -l app=billing --max-log-requests=20 --since=10m --tail=-1 --prefix   # со всех подов сразу

# 4. Внутрь
kubectl exec -it billing-6f8c9d7b54-2xk9q -- sh
kubectl debug -it billing-6f8c9d7b54-2xk9q --image=nicolaka/netshoot --target=app  # для distroless

# 5. Напрямую к поду, мимо Service и Ingress
kubectl port-forward pod/billing-6f8c9d7b54-2xk9q 8081:8081
curl localhost:8081/readyz
curl localhost:8081/debug/pprof/heap -o heap.out

# 6. Выкатка
kubectl rollout status deploy/billing --timeout=5m
kubectl rollout history deploy/billing
kubectl rollout undo deploy/billing --to-revision=7
kubectl rollout restart deploy/billing            # перечитать смонтированный конфиг

# 7. Ресурсы
kubectl top pod -l app=billing --containers
kubectl describe node ip-10-0-3-14 | sed -n '/Allocated resources/,$p'