Kubernetes

3.1Модель и базовые объекты

От Go-разработчика не ждут навыков администратора кластера. Ждут другого: что ты знаешь, куда попадает твой образ, кто и когда убивает твой под, почему при деплое теряются запросы и что именно надо написать в манифесте, чтобы этого не было. Всё это и есть контракт между приложением и платформой.

Зачем k8s и модель желаемого состояния

До кластеров деплой был императивным: «зайди на четыре сервера, останови сервис, положи бинарь, запусти, проверь». Каждый шаг мог упасть посередине, и состояние системы становилось неизвестным. Kubernetes переворачивает подход: ты описываешь желаемое состояние («хочу 6 реплик образа app:1.4.2 с такими лимитами»), а кластер сам приводит к нему реальность и дальше удерживает её там вечно.

Технически всё держится на одном паттерне, цикле согласования (reconciliation loop). API-сервер с базой в etcd хранит объекты. Контроллер подписывается на изменения нужного типа объектов (watch), в бесконечном цикле сравнивает spec (чего хотят) с status (что есть) и делает шаг в сторону сближения. Никто не отдаёт команды напрямую: Deployment-контроллер создаёт ReplicaSet, ReplicaSet-контроллер создаёт Pod-объекты, scheduler проставляет им nodeName, kubelet на этой ноде видит «мой под» и просит container runtime запустить контейнеры. Каждый занят своим маленьким инвариантом.

Базовые объекты: от Pod до Ingress

Три типа Service

• ClusterIP (по умолчанию) даёт виртуальный IP, доступный только внутри кластера. DNS-имя app.default.svc.cluster.local. Основной рабочий вариант: сервис-к-сервису ходят именно так.
• NodePort добавляет к этому один и тот же порт из диапазона 30000–32767, открытый на каждой ноде кластера. Прийти можно на любую ноду, дальше DNAT уведёт на под, возможно на другой ноде. В проде сам по себе почти не нужен: это строительный блок для внешнего балансировщика.
• LoadBalancer добавляет к NodePort запрос к облаку на внешний балансировщик, который раскидывает трафик по нодам. Неприятный нюанс тут один: каждый такой Service оборачивается отдельным платным LB в облаке, поэтому наружу обычно торчит один LoadBalancer перед Ingress Controller, а все приложения живут за ним на ClusterIP.
• Ещё есть headless (clusterIP: None): DNS отдаёт не один VIP, а список IP всех готовых подов. Нужен, когда клиент балансирует сам: gRPC-клиент, драйвер БД, StatefulSet с адресацией конкретной реплики.

ConfigMap и Secret: env против volume

ConfigMap и Secret устроены одинаково: наборы пар ключ-значение в etcd. Главных отличий три: значения Secret в API передаются в base64 (в etcd лежат сырые байты), к нему обычно применяют отдельные RBAC-правила, а смонтированный томом он лежит у kubelet в tmpfs, а не на диске. Base64 не шифрует, а кодирует; kubectl get secret -o yaml плюс base64 -d отдают пароль в открытом виде любому, у кого есть права на чтение секретов в неймспейсе.

Подключить и то и другое можно двумя способами, и разница между ними принципиальна.

apiVersion: apps/v1
kind: Deployment
metadata: { name: app }
spec:
  selector: { matchLabels: { app: app } }
  template:
    metadata: { labels: { app: app } }
    spec:
      containers:
        - name: app
          image: registry.local/app:1.4.2
          env:
            # 1) отдельный ключ из ConfigMap
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef: { name: app-config, key: log_level }
            # 2) секрет как переменная окружения
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef: { name: app-secrets, key: db_password }
            # 3) поля самого пода через Downward API
            - name: POD_NAME
              valueFrom: { fieldRef: { fieldPath: metadata.name } }
            - name: POD_NAMESPACE
              valueFrom: { fieldRef: { fieldPath: metadata.namespace } }
          envFrom:
            - configMapRef: { name: app-config }   # все ключи разом
          volumeMounts:
            - name: config
              mountPath: /etc/app        # файлы, обновляются на лету
              readOnly: true
      volumes:
        - name: config
          configMap: { name: app-config }

# 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

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

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'

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 }]    # снимаем по чуть-чуть

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 }   # дать время эндпоинтам разойтись

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 трейсов и метрик

# Как это выглядит в командах
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'

3.2Под изнутри

В API под занимает одну запись, а на узле это процесс pause, процессы приложения и ветка дерева cgroup. Между ними работают планировщик, kubelet и containerd, и почти любая странность пода (Pending на пустом кластере, выселение не того сервиса, SIGKILL при аккуратном shutdown) объясняется тем, что каждый из них делает со spec.

Прогоны сняты на kind-кластере из одного узла: Kubernetes 1.37.0, containerd 2.3.4, runc 1.4.3, cgroup v2, узел работает контейнером в Docker Desktop (ядро 7.0.12-linuxkit, 4 CPU, 8 ГБ). В кластер ничего не записывалось, только чтение и apply --dry-run=server, поэтому остановка, выселение и перезапуски описаны по исходникам тех же версий.

kubelet, CRI и pause-контейнер

kubelet следит за подами, у которых spec.nodeName совпадает с его узлом, но процессы сам не создаёт, а просит runtime по CRI (Container Runtime Interface). Это gRPC-API из двух сервисов: RuntimeService (RunPodSandbox, CreateContainer, StopContainer…) и ImageService (PullImage…). На другом конце сокета сидит containerd со встроенным CRI-плагином, под ним shim и runc, который собирает namespaces и cgroups (глава 2.1 статьи «Docker»). SyncPod в pkg/kubelet/kuberuntime запускает sandbox пода, потом эфемерные, init- и основные контейнеры, каждый по схеме: образ, создание, запуск, postStart.

Узел kind сам работает Docker-контейнером с systemd, kubelet и containerd, а crictl в нём ходит по тому же CRI. Команды с приглашением # выполнены в узле после docker exec -it dv-k8s-control-plane bash:

# crictl pods --name coredns-559f6c778d-gx9h8
POD ID              CREATED             STATE               NAME                       NAMESPACE           ATTEMPT             RUNTIME
72dc4b02b885b       About an hour ago   Ready               coredns-559f6c778d-gx9h8   kube-system         0                   (default)
# crictl inspectp 72dc4b02b885b | jq -r '.info.runtimeSpec.linux.namespaces[] | "\(.type) \(.path // "")"'
pid
ipc
uts
mount
network /var/run/netns/cni-fedd7ca7-3931-e378-385a-7a85106f2848
# ps -o pid,ppid,comm -p 4419,4508,4704
    PID    PPID COMMAND
   4419       1 containerd-shim
   4508    4419 pause
   4704    4419 coredns

В списке контейнеров crictl ps pause нет: для CRI это sandbox пода. В нём один процесс, /pause из образа registry.k8s.io/pause:3.10, и работы у него нет: он держит namespaces пода, пока контейнеры приложения падают и перезапускаются. Четыре namespaces runc создаёт с нуля, а сетевой получает готовым: его заранее создал containerd, а вызванный им CNI-плагин завёл там адрес. Сравним namespaces pause и CoreDNS, детей одного shim:

# for ns in net ipc uts pid mnt; do echo "$ns $(readlink /proc/4508/ns/$ns) $(readlink /proc/4704/ns/$ns)"; done
net net:[4026532730] net:[4026532730]
ipc ipc:[4026533122] ipc:[4026533122]
uts uts:[4026533121] uts:[4026533121]
pid pid:[4026533123] pid:[4026533139]
mnt mnt:[4026533120] mnt:[4026533138]
# stat -L -c %i /var/run/netns/cni-fedd7ca7-3931-e378-385a-7a85106f2848
4026532730

net, ipc и uts общие, и inode сетевого namespace совпадает с файлом в netns; pid и mnt у контейнера свои. Контейнеры пода делят localhost, hostname и System V IPC, но процессов друг друга не видят без shareProcessNamespace: true. IP принадлежит sandbox и переживает перезапуск приложения. Если же sandbox потерян (pause убит, пропал IP), kubelet создаёт новый с ATTEMPT на единицу больше и перезапускает в нём все контейнеры пода (PodSandboxChanged).

Планировщик: отсев и оценка узлов

Дальше все примеры про один под, billing (в Deployment это был бы шаблон пода):

# billing-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: billing
  labels: { app: billing }
spec:
  terminationGracePeriodSeconds: 45
  tolerations:
    - { key: dedicated, operator: Equal, value: backend, effect: NoSchedule }
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector: { matchLabels: { app: billing } }
  initContainers:
    - name: migrate
      image: registry.example.com/billing:1.8.0
      command: ["/billing", "migrate", "up"]
    - name: otel-agent                        # нативный sidecar
      image: otel/opentelemetry-collector-contrib:0.135.0
      restartPolicy: Always
      resources:
        requests: { cpu: 50m, memory: 64Mi }
        limits: { memory: 128Mi }
  containers:
    - name: app
      image: registry.example.com/billing:1.8.0
      resources:
        requests: { cpu: 250m, memory: 128Mi, ephemeral-storage: 100Mi }
        limits: { cpu: "1", memory: 256Mi, ephemeral-storage: 1Gi }
      lifecycle:
        preStop:
          sleep: { seconds: 10 }

kube-scheduler берёт из очереди под без nodeName и прогоняет через плагины. На этапе Filter хватает одного «нельзя» от любого плагина, чтобы узел выбыл. На этапе Score плагины ставят оставшимся узлам от 0 до 100 очков, очки умножаются на вес плагина и складываются; побеждает наибольшая сумма, ничью решает случай. На большом кластере Filter останавливается, набрав достаточно подходящих узлов: 50 % минус число узлов / 125, но не меньше 5 % и не меньше 100 узлов, так что из 1000 узлов до оценки доходят не больше 420 (numFeasibleNodesToFind).

Ещё узлы отсеивают по cordon, hostPort и томам, а очки добавляют за баланс CPU и памяти и за скачанный образ. Считается всё по requests, реальную загрузку узла планировщик не видит. Под без requests в фильтре весит ноль, а в оценке NodeResourcesFit идёт как 100m CPU и 200 МиБ.

Taints и tolerations

Taint на узле говорит «сюда нельзя», toleration в поде отвечает «мне можно», но никуда под не тянет: billing с toleration dedicated=backend сядет и на обычный узел. Чтобы он шёл только на выделенные, добавляют nodeAffinity на их метку. NoSchedule проверяет планировщик, PreferNoSchedule лишь снижает оценку, NoExecute ещё и выгоняет работающие поды: этим занят taint-eviction-controller в kube-controller-manager.

Часть taints ставит сам кластер: узел без отчётов 50 секунд (node-monitor-grace-period) получает node.kubernetes.io/unreachable, узел с Ready=False получает not-ready, оба NoExecute. На этот случай admission-плагин DefaultTolerationSeconds дописывает каждому поду по toleration:

$ kubectl apply --dry-run=server -f billing-pod.yaml -o yaml | sed -n '/^  tolerations:/,/^  topologySpreadConstraints:/p;/^status:/,$p'
  tolerations:
  - effect: NoSchedule
    key: dedicated
    operator: Equal
    value: backend
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  topologySpreadConstraints:
status:
  phase: Pending
  qosClass: Burstable

Под с пропавшего узла контроллер сразу помечает неготовым, но выселяет только через пять минут. Для stateless-сервиса это долго; своя toleration на тот же ключ с меньшим tolerationSeconds сохранится, а недостающую плагин допишет. У узла kind taints нет вовсе, хотя это control plane: kubeadm ставит node-role.kubernetes.io/control-plane:NoSchedule, но kind снимает его, если узел в кластере один.

Affinity против topologySpreadConstraints

Жёсткая podAntiAffinity по kubernetes.io/hostname не даст запустить реплик больше, чем узлов: лишние останутся в Pending. Мягкая только снижает оценку; у CoreDNS в kind мягкая, с весом 100, и обе реплики живут на единственном узле. topologySpreadConstraints следит за перекосом: насколько подходящих подов в домене topologyKey больше, чем в самом пустом. Узел без метки из topologyKey фильтр отсеивает, и зональное ограничение с DoNotSchedule на кластере без зон оставит в Pending все поды. Если своих ограничений нет, а под выбран Service, ReplicaSet или StatefulSet, планировщик подставляет системные: по hostname maxSkew: 3, по зоне maxSkew: 5, оба ScheduleAnyway.

Init-контейнеры и нативные sidecar

Init-контейнеры идут по одному, каждый должен выйти с кодом 0. Упавший init-контейнер kubelet перезапускает с растущей паузой, а при restartPolicy: Never весь под становится Failed. В kubectl get pods это Init:1/2, Init:Error или Init:CrashLoopBackOff.

Агенту или прокси в init места нет: init обязан завершиться. Раньше агента клали вторым контейнером в containers и получали три беды: приложение стартовало раньше агента, Job не завершался, потому что агент не выходит, а при остановке агент получал SIGTERM вместе с приложением и мог умереть первым. Нативный sidecar устроен иначе: это init-контейнер с restartPolicy: Always, стабильный с Kubernetes 1.33.

Запрос пода планировщик берёт по формуле KEP-753 (AggregateContainerRequests): большее из суммы основных контейнеров со всеми sidecars и самого тяжёлого шага инициализации, где работает init-контейнер и запущенные до него sidecars. У billing 250m + 50m = 300m и 192 МиБ; миграция с requests.memory: 2Gi сделала бы весь под двухгигабайтным. Ненулевые коды выхода sidecars при остановке пода документация считает нормой. А restartPolicy: Always у контейнера в containers API с 1.35 тоже примет (бета ContainerRestartRules), но sidecar из него не получится: это просто политика перезапуска.

Как requests и limits становятся файлами cgroup

QoS-класс API пишет в status.qosClass при создании пода. По нему kubelet выбирает ветку cgroup (у Burstable и BestEffort свои slice, Guaranteed висят прямо в kubepods) и создаёт slice пода, а runc внутри него заводит scope на каждый контейнер, включая pause. Приставку kubelet- дал kind: он ставит kubelet cgroupRoot: /kubelet, а на узле kubeadm путь начнётся с kubepods.slice/kubepods-burstable.slice.

# cat /proc/4704/cgroup
0::/kubelet.slice/kubelet-kubepods.slice/kubelet-kubepods-burstable.slice/kubelet-kubepods-burstable-pod7d672ea5_d2db_4c8e_be14_cd10571ef470.slice/cri-containerd-27db794ea19c9b8b338df14d71e507f1bd2f04a6846aeb20201883322d62877a.scope
# cd /sys/fs/cgroup/kubelet.slice/kubelet-kubepods.slice
# for d in . kubelet-kubepods-burstable.slice kubelet-kubepods-besteffort.slice; do echo "$d: cpu.weight=$(cat $d/cpu.weight) memory.max=$(cat $d/memory.max)"; done
.: cpu.weight=157 memory.max=8320299008
kubelet-kubepods-burstable.slice: cpu.weight=37 memory.max=max
kubelet-kubepods-besteffort.slice: cpu.weight=1 memory.max=max
# cd kubelet-kubepods-burstable.slice/kubelet-kubepods-burstable-pod7d672ea5_d2db_4c8e_be14_cd10571ef470.slice
# for f in cpu.weight cpu.max memory.max memory.oom.group memory.high; do echo "$f: pod=$(cat $f) coredns=$(cat cri-containerd-27db*/$f) pause=$(cat cri-containerd-72dc*/$f)"; done
cpu.weight: pod=4 coredns=17 pause=1
cpu.max: pod=max 100000 coredns=max 100000 pause=max 100000
memory.max: pod=178257920 coredns=178257920 pause=max
memory.oom.group: pod=0 coredns=1 pause=0
memory.high: pod=max coredns=max pause=max

У CoreDNS requests.cpu: 100m, requests.memory: 70Mi и limits.memory: 170Mi.

• kubepods: в memory.max вся память узла (8125292Ki) за вычетом kube-reserved и system-reserved, которых в kind нет; cpu.weight 157 получен из 4 CPU.
• QoS-slice: вес Burstable 37 посчитан из суммы CPU-requests Burstable-подов узла (950m); kubelet пересчитывает его при запуске и остановке подов и раз в минуту.
• slice пода: в memory.max и cpu.max идут суммы лимитов, если лимит есть у каждого контейнера, включая init (ResourceConfigForPod). У billing нет лимита CPU у агента и памяти у migrate, так что slice пода получит max в обоих файлах.
• scope контейнера: memory.max = limits.memory, в cpu.max квота и период в микросекундах (глава 3.1): у app с лимитом 1 CPU это 100000 100000, без лимита max 100000.
• memory.oom.group=1 kubelet на cgroup v2 ставит каждому контейнеру, и при OOM гибнут все его процессы (глава 1.4 статьи «Linux и ОС»).
• memory.high=max: MemoryQoS в kubelet 1.37 в бете и включена, но без memoryThrottlingFactor (по умолчанию пуст) файл не пишется.

Две детали API меняют эти числа ещё до узла. Контейнер с одними limits (limits-only.yaml) получает такие же requests и молча становится Guaranteed:

$ kubectl apply --dry-run=server -f limits-only.yaml -o jsonpath='{.spec.containers[0].resources}{"\n"}{.status.qosClass}{"\n"}'
{"limits":{"cpu":"500m","memory":"256Mi"},"requests":{"cpu":"500m","memory":"256Mi"}}
Guaranteed

А ресурсы уровня пода, spec.resources, задают общий бюджет, в котором контейнеры без своих запросов делят CPU и память, и QoS тогда считается по поду. В 1.37 это бета и включена, dry-run такого пода проходит.

Нехватка памяти: выселение kubelet и OOM killer

OOM killer живёт в ядре и срабатывает, когда cgroup упёрлась в memory.max или кончилась память машины (выбор жертвы разобран в главе 1.4 статьи «Linux и ОС»). Выселение (node-pressure eviction) устраивает kubelet: раз в 10 секунд сравнивает сигналы узла с порогами и останавливает под целиком, помечая его Evicted. На выбор ядра kubelet влияет через oom_score_adj контейнеров:

# for id in $(crictl ps -q); do set -- $(crictl inspect -o go-template --template '{{.info.pid}} {{.status.metadata.name}}' $id); echo "$(cat /proc/$1/oom_score_adj) $2"; done
992 coredns
992 coredns
1000 local-path-provisioner
-997 kindnet-cni
-999 kube-proxy
-997 etcd
…

По GetContainerOOMScoreAdjust Guaranteed и любой под с system-node-critical получают −997 (так у kindnet и etcd, хотя они Burstable), BestEffort получает 1000, Burstable 1000 − 1000 × requests.memory / память узла в пределах от 3 до 999: у CoreDNS 1000 − 1000 × 70 МиБ / 7,75 ГиБ = 992. Чем меньше запросил, тем ближе к BestEffort. kube-proxy ставит себе −999 сам, pause получает −998 от containerd.

Пороги и порядок выселения

kubelet следит за сигналами memory.available (ёмкость минус working set), nodefs.* и imagefs.* (место и inode), pid.available. Жёсткие пороги по умолчанию в 1.37 на Linux: memory.available<100Mi, nodefs.available<10%, nodefs.inodesFree<5%, imagefs.available<15%, imagefs.inodesFree<5%. Мягкие (evictionSoft) срабатывают, продержавшись свой период ожидания. За диск kubelet сначала чистит мёртвые контейнеры и неиспользуемые образы. Жертв при нехватке памяти упорядочивает rankMemoryPressure, и QoS среди ключей нет: первыми идут поды, чьё потребление больше requests.memory, среди них с меньшим priority, затем с наибольшим превышением. BestEffort уходит первым, потому что нулевые requests превышены всегда, а Guaranteed выше своих requests почти не вырастет. Статические поды и поды с priority от 2 000 000 000 (system-cluster-critical, system-node-critical) kubelet не выселяет.

У выселенного пода phase Failed, reason Evicted и условие DisruptionTarget. При жёстком пороге kubelet даёт 1 секунду вместо terminationGracePeriodSeconds (документация пишет «0s»), но между сигналом и SIGKILL всё равно оставляет свой минимум в 2 секунды. При мягком пороге он берёт меньшее из evictionMaxPodGracePeriod и grace period пода. Порог памяти вычитается из Allocatable, но не из memory.max kubepods: остаётся окно, чтобы выселить под раньше ядра, но быстрый рост памяти его проскакивает.

$ kubectl describe node dv-k8s-control-plane | grep -E '^(Taints|Capacity|Allocatable):|^  (cpu|memory):'
Taints:             <none>
Capacity:
  cpu:                4
  memory:             8125292Ki
Allocatable:
  cpu:                4
  memory:             8125292Ki
$ kubectl get --raw /api/v1/nodes/dv-k8s-control-plane/proxy/configz | jq -c '.kubeletconfig | {evictionHard, mergeDefaultEvictionSettings, crashLoopBackOff, containerLogMaxSize, containerLogMaxFiles}'
{"evictionHard":{"imagefs.available":"0%","nodefs.available":"0%","nodefs.inodesFree":"0%"},"mergeDefaultEvictionSettings":false,"crashLoopBackOff":{"maxContainerRestartPeriod":"5m0s"},"containerLogMaxSize":"10Mi","containerLogMaxFiles":5}

ephemeral-storage

ephemeral-storage учитывает диск узла, который под тратит мимо PersistentVolume: слой записи контейнеров, логи в /var/log/pods и emptyDir на диске. Requests сверяет планировщик (Insufficient ephemeral-storage), а limits в cgroup не попадают: лимита на занятое место у cgroup v2 нет. Их проверяет kubelet в том же десятисекундном цикле и выселяет под с grace period в 1 секунду, если контейнер превысил свой лимит (логи плюс слой записи, когда образы на той же файловой системе), если сумма по поду превысила сумму лимитов или если emptyDir перерос sizeLimit. В сообщении будет «Container app exceeded its local ephemeral storage limit "1Gi"».

Логи входят в счёт, и болтливый Go-сервис с маленьким лимитом может выселить сам себя: ротацию по containerLogMaxSize и containerLogMaxFiles (на kind 10Mi и 5) kubelet проверяет раз в 10 секунд. А emptyDir с medium: Memory живёт в tmpfs и считается памятью (глава 2.3 статьи «Docker»).

Фазы, состояния и растущая пауза перезапуска

Фаз у пода пять: Pending, Running, Succeeded, Failed, Unknown, и все они грубые: Running значит лишь «контейнеры созданы, хотя бы один работает или перезапускается». Подробности лежат в состояниях контейнеров и условиях пода:

$ kubectl get pod -n kube-system coredns-559f6c778d-gx9h8 -o jsonpath='{range .status.conditions[*]}{.type}={.status} {end}{"\n"}'
PodReadyToStartContainers=True Initialized=True Ready=True ContainersReady=True PodScheduled=True

PodReadyToStartContainers (стабильно с 1.37) означает, что готовы sandbox и сеть, Initialized говорит о законченных init-контейнерах. В колонке STATUS у kubectl get pods фаза стоит не всегда: printPod заменяет её причинами ожидания и завершения контейнеров.

Паузу считает flowcontrol.Backoff в kubelet, ключ у неё «под плюс контейнер». После первого падения контейнер перезапускается сразу, дальше пауза 10 секунд и удваивается: 10, 20, 40, 80, 160, затем 300. Счёт сбрасывается, если от прошлого перезапуска до нового падения прошло больше 10 минут (HasExpiredFunc), и сервис, падающий раз в полчаса, каждый раз встаёт сразу. Потолок в 1.37 настраивается на узле: KubeletCrashLoopBackOffMax в бете с 1.35, поле crashLoopBackOff.maxContainerRestartPeriod принимает от 1 до 300 секунд (на kind 5m0s). Альфа ReduceDefaultCrashLoopBackOffDecay (от 1 до 60 секунд) выключена.

Остановка пода по шагам

Две независимые цепочки удаления (процессы на узле и адрес в балансировке) и пауза между ними разобраны в главе 3.1. Здесь они по участникам:

1. API-сервер. Берёт grace period из запроса, иначе из spec.terminationGracePeriodSeconds (по умолчанию 30); под без nodeName или завершённый удаляет сразу. Ставит deletionTimestamp в будущее, на сейчас плюс grace period, и оставляет объект в etcd (CheckGracefulDelete).
2. EndpointSlice. Адрес пода сразу получает ready: false и terminating: true, а serving повторяет readiness (podToEndpoint). kube-proxy убирает адрес из правил, когда до него дойдёт обновление, а адреса serving + terminating берёт, только если готовых не осталось. Открытые TCP-соединения правила не рвут.
3. kubelet. Выключает liveness- и startup-пробы (readiness работает дальше) и останавливает контейнеры параллельно; отсчёт grace period начинается здесь.
4. preStop. kubelet выполняет хук и ждёт не дольше grace period; время хука вычитается из остатка. sleep отсчитывает сам kubelet, exec запускает команду в контейнере.
5. Сигнал. CRI StopContainer получает остаток, но не меньше 2 секунд. containerd шлёт первому процессу контейнера lifecycle.stopSignal (альфа, выключена), иначе STOPSIGNAL образа, иначе SIGTERM, а когда время выйдет, SIGKILL. Sidecars ждут выхода основных контейнеров и получают сигнал после них.
6. Конец. Когда всё остановлено, kubelet удаляет под с grace period 0 и условием на UID.

Действие sleep стабильно с 1.34 и принимает ноль. API сверяет его с grace period; в sleep-too-long.yaml у пода terminationGracePeriodSeconds: 30 и sleep: { seconds: 40 }:

$ kubectl apply --dry-run=server -f sleep-too-long.yaml
The Pod "billing" is invalid: spec.containers[0].lifecycle.preStop.sleep: Invalid value: 40: must be non-negative and less than terminationGracePeriodSeconds (30)
$ kubectl get endpointslice -n kube-system -l kubernetes.io/service-name=kube-dns -o jsonpath='{range .items[*].endpoints[*]}{.targetRef.name} {.conditions}{"\n"}{end}'
coredns-559f6c778d-tdsh4 {"ready":true,"serving":true,"terminating":false}
coredns-559f6c778d-gx9h8 {"ready":true,"serving":true,"terminating":false}

Сообщение говорит «less than», но validateSleepAction пропускает и равное: sleep: 30 при 30 секундах проходит. Второй вывод показывает условия живых адресов CoreDNS; у удаляемого пода они сменятся, как в шаге 2.

# ls /proc/4704/root/bin /proc/4704/root/sbin /proc/4704/root/usr/bin
/proc/4704/root/bin:

/proc/4704/root/sbin:

/proc/4704/root/usr/bin:

Что делать при остановке самому Go-сервису, разобрано в главе 10.2 статьи «Веб-сервисы». Со стороны пода важно, что сигнал получает только первый процесс контейнера, а Go-бинарь без обработчика умирает по SIGTERM сразу, с кодом 143. Бюджет считают от хука: terminationGracePeriodSeconds ≥ preStop + самый долгий запрос + закрытие ресурсов + запас, у billing 10 + 25 + 5 + 5 = 45.

$ kubectl events -n kube-system --for pod/coredns-559f6c778d-gx9h8 | head -3
LAST SEEN   TYPE      REASON             OBJECT                         MESSAGE
81m         Warning   FailedScheduling   Pod/coredns-559f6c778d-gx9h8   0/1 nodes are available: 1 node(s) had untolerated taint(s). preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.
80m         Normal    Scheduled          Pod/coredns-559f6c778d-gx9h8   Successfully assigned kube-system/coredns-559f6c778d-gx9h8 to dv-k8s-control-plane

kubectl describe node <узел> | sed -n '/Allocated resources/,/Events/p'   # сколько уже расписано

kubectl get pod api-7d9f8b6c5d-xk2wq -o jsonpath='{.status.reason} {.status.containerStatuses[*].lastState.terminated.reason}{"\n"}'
kubectl events --for node/<узел> | grep -E 'EvictionThresholdMet|SystemOOM'

3.3Выкатка и упаковка

Deployment хранит историю в ReplicaSet-ах, HPA делит потребление на requests, CronJob ищет пропущенные слоты по своему статусу, а Helm кладёт релиз целиком в Secret. Отсюда видно, почему выкатка встала на полпути, drain висит час, а ночной отчёт стартовал в 03:14 вместо 03:10.

Прогоны: kind с Kubernetes 1.37.0 без записи в кластер, kubectl 1.37.0 с Kustomize 5.8.1, Helm 4.3.0, helm-diff 3.15.13, Go 1.27.1. Поведение контроллеров сверено с исходниками 1.37.

Ревизии Deployment живут в ReplicaSet-ах

Готовый пример в кластере есть: Deployment CoreDNS, его ставит kubeadm.

$ kubectl get rs -n kube-system -L pod-template-hash
NAME                 DESIRED   CURRENT   READY   AGE   POD-TEMPLATE-HASH
coredns-559f6c778d   2         2         2       64m   559f6c778d
$ kubectl get rs coredns-559f6c778d -n kube-system -o yaml | sed -n '/^  annotations:/,/^  creationTimestamp/p'
  annotations:
    deployment.kubernetes.io/desired-replicas: "2"
    deployment.kubernetes.io/max-replicas: "3"
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2026-09-17T07:22:13Z"
$ kubectl rollout history deployment/coredns -n kube-system
deployment.apps/coredns
REVISION  CHANGE-CAUSE
1         <none>

Хеш 559f6c778d контроллер считает FNV-32a от spec.template (ComputeHash в pkg/controller/controller_utils.go) и пишет в имя ReplicaSet, метку pod-template-hash и селектор: метка k8s-app: kube-dns общая у всех ревизий, а по хешу ReplicaSet отличает свои поды. CHANGE-CAUSE берётся из аннотации kubernetes.io/change-cause, её ставит разве что пайплайн.

Новая ревизия появляется только при смене шаблона пода. replicas, strategy и minReadySeconds лежат вне его, что видно в kubectl diff без записи в кластер:

# coredns-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system
spec:
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 0

$ kubectl diff -f coredns-patch.yaml
…
-  generation: 1
+  generation: 2
…
 spec:
+  minReadySeconds: 10
…
-      maxUnavailable: 1
+      maxUnavailable: 0
     type: RollingUpdate
   template:

С --server-side тот же diff падает с conflict with "kubeadm", успев напечатать «keeps changing»: конфликт владельца поля приходит с кодом 409, как конфликт версии, и kubectl делает четыре попытки.

kubectl rollout undo работает на стороне kubectl (polymorphichelpers/rollback.go): берёт шаблон ReplicaSet нужной ревизии, убирает метку pod-template-hash и патчем кладёт в Deployment. Дальше идёт обычный rolling update: контроллер находит этот ReplicaSet и поднимает его по тем же maxSurge и maxUnavailable. Номер ему достаётся максимальный плюс один, прежний уходит в аннотацию deployment.kubernetes.io/revision-history (SetNewReplicaSetAnnotations): после отката с 3 на 1 в истории останутся 2 и 3. У CoreDNS откатываться некуда:

$ kubectl rollout undo deployment/coredns -n kube-system --dry-run=server
error: no rollout history found for deployment "coredns"
$ kubectl rollout undo deployment/coredns -n kube-system --to-revision=1 --dry-run=server
deployment.apps/coredns skipped rollback (current template already matches revision 1) (server dry run)

Старые ReplicaSet с нулём реплик хранятся до revisionHistoryLimit (по умолчанию 10), лишние удаляет cleanupDeployment, когда выкатка закончена.

Шаг выкатки: maxSurge, maxUnavailable, minReadySeconds

Проценты округляет ResolveFenceposts: maxSurge вверх, maxUnavailable вниз. У CoreDNS 25 % от двух реплик дают 0,5, вверх это 1, отсюда max-replicas: "3". Если оба ушли в ноль, контроллер берёт maxUnavailable за 1, а явные нули в обоих полях не пропустит валидация. За проход rolloutRolling (pkg/controller/deployment/rolling.go) делает одно из двух:

• добавляет поды новому ReplicaSet, если сумма spec.replicas всех ReplicaSet меньше replicas + maxSurge, но не больше недостающего до replicas;
• убирает поды у старых, если доступных больше replicas − maxUnavailable; ещё не доступные новые поды вычитаются из запаса, неготовые старые гасятся первыми.

Доступным под становится, пробыв Ready minReadySeconds. Шаги ниже посчитаны по этим формулам в предположении, что новые поды становятся доступными одновременно.

progressDeadlineSeconds отсчитывается от последнего прогресса, а не от начала выкатки: DeploymentTimedOut сравнивает время с lastUpdateTime условия Progressing, а syncRolloutStatus (progress.go) обновляет его при каждом продвижении. Выкатка, застрявшая в состоянии 4, через 600 секунд получит Progressing=False с причиной ProgressDeadlineExceeded, и на этом всё.

Поды в Terminating в расчёт не входят: старый под с долгим terminationGracePeriodSeconds живёт сверх replicas + maxSurge, в 1.37 их число видно в status.terminatingReplicas. Recreate поднимает новые поды, только когда старые завершились полностью.

PodDisruptionBudget и drain

PodDisruptionBudget ограничивает только eviction API, подресурс pods/eviction. Через него выселяет поды kubectl drain. Rolling update удаляет поды через ReplicaSet, а kubectl delete pod и упавший узел обходятся без eviction: бюджет их не останавливает, но потери учитывает.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api
spec:
  maxUnavailable: 1                        # проценты округляются вверх
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels: { app: api }

Ожидаемое число подов бюджет берёт из spec.replicas владельца, а при целом minAvailable считает сами поды. EvictionREST.Create (pkg/registry/core/pod/storage/eviction.go) выселяет без проверки поды в Pending, Succeeded, Failed и уже удаляемые. Неготовый под при AlwaysAllow удаляется сразу, при умолчании IfHealthyBudget только если currentHealthy ≥ desiredHealthy. При disruptionsAllowed == 0 ответ 429 «Cannot evict pod as it would violate the pod's disruption budget.», иначе счётчик уменьшается и под удаляется с обычным grace period.

kubectl drain ставит cordon и выселяет поды параллельно (staging/src/k8s.io/kubectl/pkg/drain/drain.go). На 429 он пишет (will retry after 5s) и повторяет до --timeout, по умолчанию бесконечного (0). Прочие ошибки drain не повторяет.

HPA изнутри

Контроллер (pkg/controller/podautoscaler/horizontal.go) раз в 15 секунд берёт наибольшее из предложений по метрикам. Для Resource (GetResourceReplicas):

1. потребление подов с метриками делится на сумму их requests, отношение к цели даёт ratio;
2. при 0,9 ≤ ratio ≤ 1,1 число реплик не меняется; порог задаёт флаг --horizontal-pod-autoscaler-tolerance, а с 1.37 стабильно поле tolerance в behavior.scaleUp и scaleDown;
3. поды без метрик при росте считаются нулём, при уменьшении полным request (или целью, если она выше 100 %), неготовые поды для CPU при росте тоже нулём; если поправка меняет направление, масштаба нет;
4. результат: ceil(ratio × число учтённых подов).

Если часть метрик недоступна, реплики HPA не убирает. Рекомендации контроллер хранит в памяти и сглаживает: при уменьшении берёт наибольшую за окно stabilizationWindowSeconds (300 секунд), при росте наименьшую (окно 0). Что подставит API, видно на серверном dry-run HPA с одной политикой уменьшения { type: Pods, value: 1, periodSeconds: 60 }:

$ kubectl apply --dry-run=server -f hpa.yaml -o jsonpath='{.spec.behavior.scaleUp}{"\n"}{.spec.behavior.scaleDown}{"\n"}'
{"policies":[{"periodSeconds":15,"type":"Pods","value":4},{"periodSeconds":15,"type":"Percent","value":100}],"selectPolicy":"Max","stabilizationWindowSeconds":0}
{"policies":[{"periodSeconds":60,"type":"Pods","value":1}],"selectPolicy":"Max"}

Окно уменьшения API оставил пустым, 300 секунд подставит контроллер. Без behavior API не заполняет ничего, и рост за проход ограничен max(2 × текущее, 4). Справка kubectl explain hpa.spec.behavior пишет «4 pods per 60 seconds», а в коде, в dry-run и на kubernetes.io период 15 секунд. explain hpa.spec.minReplicas называет нулевой минимум alpha, но кластер принял minReplicas: 0 с метрикой External: gate HPAScaleToZero в 1.37 в beta и включён.

Job: попытки, индексы, уборка

backoffLimit (по умолчанию 6) считает упавшие поды, а при restartPolicy: OnFailure и перезапуски контейнеров. Новый под после падения создаётся с задержкой от 10 секунд с удвоением. Документация пишет «capped at six minutes», в коде 1.37 потолок MaxJobPodFailureBackOff = 10 * time.Minute (pkg/controller/job/job_controller.go). activeDeadlineSeconds сильнее backoffLimit. Разные причины падений разводят политика падений и индексы:

apiVersion: batch/v1
kind: Job
metadata:
  name: reindex
spec:
  completions: 8
  parallelism: 4
  completionMode: Indexed          # номер части в JOB_COMPLETION_INDEX
  backoffLimitPerIndex: 2          # у каждого индекса свои попытки
  maxFailedIndexes: 3              # больше трёх упавших - Job провалена
  ttlSecondsAfterFinished: 3600
  podFailurePolicy:
    rules:
      - action: FailIndex          # код 42: повтор не поможет
        onExitCodes: { containerName: reindex, operator: In, values: [42] }
      - action: Ignore             # вытеснение с узла не считать
        onPodConditions: [{ type: DisruptionTarget }]
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: reindex
          image: registry.local/api:1.4.2
          args: ["reindex", "--shard=$(JOB_COMPLETION_INDEX)"]

$ kubectl apply --dry-run=server -f job.yaml -o jsonpath='{.spec.backoffLimit} {.spec.podReplacementPolicy} {.spec.completionMode}{"\n"}'
2147483647 Failed Indexed

С backoffLimitPerIndex общий лимит становится MaxInt32, с podFailurePolicy замена пода создаётся после его полного завершения. Справка для обеих требует restartPolicy: Never, но API 1.37 проверяет это только у podFailurePolicy. ttlSecondsAfterFinished удаляет законченную Job вместе с подами. Миграции отдельной Job разобраны в главе 4.3 статьи «CI/CD».

CronJob: расписание, пропуски, конкуренция

CronJob заменяет пару .service и .timer из главы 1.4 статьи «Linux и ОС». Задачи запускает контроллер в kube-controller-manager, а пропущенные слоты ищет от status.lastScheduleTime.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report
spec:
  schedule: "0 3 * * *"
  timeZone: Europe/Moscow
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 600
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: report
              image: registry.local/api:1.4.2
              args: ["report", "daily"]

$ kubectl apply --dry-run=server -f cronjob.yaml -o jsonpath='{.spec.concurrencyPolicy} {.spec.successfulJobsHistoryLimit} {.spec.failedJobsHistoryLimit}{"\n"}'
Forbid 3 1
$ kubectl apply --dry-run=server -f cronjob-badtz.yaml
The CronJob "report" is invalid: spec.timeZone: Invalid value: "MSK": unknown time zone MSK

С TZ или CRON_TZ в schedule новый объект не пройдёт валидацию, а без timeZone расписание считается в часовом поясе процесса kube-controller-manager. Запускать ли Job, решает syncCronJob (pkg/controller/cronjob/cronjob_controllerv2.go):

• Слот. Берётся последний наступивший слот после lastScheduleTime: сколько бы их ни пропало за простой или suspend, Job будет одна.
• Дедлайн. Слот старше startingDeadlineSeconds пропускается, и пропуски ищутся только в этом окне.
• Конкуренция. Allow запускает поверх активной Job, Forbid пропускает слот с событием JobAlreadyActive, Replace удаляет активную Job.
• Имя. report-<время слота в минутах Unix>: второй Job на слот не будет и после перезапуска контроллера.

При сотне с лишним пропусков документация обещает не запускать Job. В 1.37 контроллер пишет событие TooManyMissedTimes и всё равно создаёт Job, так и в тесте "prev ran but done, long overdue, not past deadline, A".

StatefulSet: когда он действительно нужен

StatefulSet нужен программам, которые сами хранят данные или адресуются по имени реплики (Postgres, брокер, NATS с JetStream), а не Go-сервису без состояния. Deployment с общим PVC тут не годится: диск ReadWriteOnce подключается к одному узлу, и новый под на другом узле ждёт с событием FailedAttachVolume «Volume is already used by pod(s) …» (reportMultiAttachError в attach/detach-контроллере).

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nats
spec:
  serviceName: nats              # headless Service: nats-0.nats.<ns>.svc
  replicas: 3
  selector:
    matchLabels: { app: nats }
  template:
    metadata:
      labels: { app: nats }
    spec:
      containers:
        - name: nats
          image: nats:2.12
          args: ["--jetstream", "--store_dir=/data"]
          volumeMounts:
            - { name: data, mountPath: /data }
  volumeClaimTemplates:          # у каждого пода свой PVC: data-nats-0, data-nats-1…
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        resources:
          requests: { storage: 10Gi }

$ kubectl apply --dry-run=server -f sts.yaml -o jsonpath='{.spec.podManagementPolicy}{"\n"}{.spec.updateStrategy}{"\n"}{.spec.persistentVolumeClaimRetentionPolicy}{"\n"}'
OrderedReady
{"rollingUpdate":{"maxUnavailable":1,"partition":0},"type":"RollingUpdate"}
{"whenDeleted":"Retain","whenScaled":"Retain"}

OrderedReady создаёт поды от 0 вверх, дожидаясь готовности предыдущего, обновление идёт с наибольшего номера, partition: 2 обновит только nats-2. maxUnavailable в 1.37 включён (beta), но при OrderedReady может не действовать. PVC после удаления остаются.

Helm: чарт, values, шаблоны

helm create api создаёт Chart.yaml (version чарта и appVersion приложения), values.yaml и templates/ с типовыми объектами. Шаблоны пишутся на text/template с функциями Sprig. Файлы с подчёркиванием в начале имени движок в манифесты не рендерит (pkg/engine/engine.go), там определяют шаблоны для include: api.image собирает репозиторий и тег, по умолчанию appVersion. Чарт урезан до Deployment и хука:

# values.yaml
replicaCount: 2
image:
  repository: registry.local/api
  tag: ""              # пусто: берётся appVersion
resources:
  requests: { cpu: 100m, memory: 128Mi }
  limits: { memory: 256Mi }
tolerations:
  - { key: pool, value: general, effect: NoSchedule }

# values-prod.yaml
replicaCount: 6
resources:
  limits: { memory: 512Mi }
tolerations:
  - { key: pool, value: prod, effect: NoSchedule }

# templates/deployment.yaml, фрагмент
  replicas: {{ .Values.replicaCount }}
      containers:
        - name: api
          image: {{ include "api.image" . }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
      {{- with .Values.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
      {{- end }}

$ helm template api ./api -f api/values-prod.yaml --set image.tag=1.4.3 --show-only templates/deployment.yaml
…
  replicas: 6
…
          image: registry.local/api:1.4.3
          resources:
            limits:
              memory: 512Mi
            requests:
              cpu: 100m
              memory: 128Mi
      tolerations:
        - effect: NoSchedule
          key: pool
          value: prod
$ helm template api ./api --set replicaCount=8 -f api/values-prod.yaml --show-only templates/deployment.yaml | grep replicas
  replicas: 8

Словари сливаются вглубь: prod заменил limits.memory, requests остались. Списки заменяются целиком: от общего tolerations ничего не осталось. --set resources.limits=null убирает ключ из вывода. Порядок жёсткий, позиция флага не важна (MergeValues в pkg/cli/values/options.go): файлы -f по очереди, затем --set-json, --set, --set-string, --set-file, --set-literal, и всё это поверх values.yaml чарта. Поэтому --set перед -f победил. Что ловят helm lint, helm template и серверный dry-run, разобрано в главе 4.3 статьи «CI/CD».

Релиз, история и хуки

Каждая ревизия лежит в Secret пространства имён релиза (pkg/storage/driver/secrets.go): sh.helm.release.v1.<релиз>.v<ревизия>, тип helm.sh/release.v1, метки name, owner=helm, status, version. В data.release лежит JSON релиза в gzip и base64, а API добавляет ещё один base64. Ниже Secret, который драйвер Helm 4.3.0 записал в поддельный клиент (secret-last.json, как его отдал бы API):

$ jq -r '.data.release' secret-last.json | base64 -d | base64 -d | gunzip \
    | jq -c '{name, version, status: .info.status, chart: .chart.metadata.version, apply_method}'
{"name":"api","version":5,"status":"deployed","chart":"0.4.0","apply_method":"ssa"}

На кластере вместо файла будет kubectl get secret sh.helm.release.v1.api.v5 -o jsonpath='{.data.release}'. Внутри чарт целиком, values пользователя (config), манифест, хуки и статус, а Secret ограничен 1 МиБ (MaxSecretSize). Ревизий хранится 10 (--history-max), последняя успешная не удаляется, helm rollback создаёт следующую ревизию «Rollback to N».

--wait в Helm 4 принимает стратегию: без флага hookOnly (ждать только хуки), голый --wait означает watcher (готовность объектов через kstatus), есть legacy в стиле Helm 3. --atomic на helm upgrade печатает «Flag --atomic has been deprecated, use --rollback-on-failure instead».

Job миграции в чарте помечена helm.sh/hook: pre-install,pre-upgrade, hook-weight: "-5" и hook-delete-policy: before-hook-creation,hook-succeeded. Серверный dry-run печатает её отдельно:

$ helm upgrade --install api ./api -n default -f api/values-prod.yaml --dry-run=server
Release "api" does not exist. Installing it now.
…
STATUS: pending-install
REVISION: 1
DESCRIPTION: Dry run complete
TEST SUITE: None
HOOKS:
---
# Source: api/templates/job-migrate.yaml
…
MANIFEST:
---
# Source: api/templates/deployment.yaml
…

pkg/action/hooks.go сортирует хуки по весу, при равенстве по имени, удаляет прежний объект по before-hook-creation (это умолчание), создаёт новый и ждёт завершения Job в пределах --timeout, 5 минут. Упавший хук проваливает релиз. Хуки не входят в манифест релиза: helm uninstall их не удалит, откат не вернёт (документация Helm). Почему миграция в хуке компромисс, разобрано в главе 4.3 статьи «CI/CD». Объекты, пропавшие из чарта, helm upgrade удаляет, кроме помеченных helm.sh/resource-policy: keep.

helm diff остаётся плагином. Из git-репозитория Helm 4 ставит его только с --verify=false («plugin source does not support verification»), подписанный архив релиза проходит проверку. Плагин сравнивает рендер с манифестом последней ревизии из Secret и ручную правку в кластере не увидит, живые объекты сравнивает --three-way-merge. --detailed-exitcode даёт ненулевой код при разнице, для CI.

Kustomize: base, overlays, патчи

Kustomize не шаблонизирует: он берёт валидный YAML из base и накладывает преобразования overlay. kubectl kustomize печатает результат, kubectl apply -k применяет.

# base/kustomization.yaml
resources:
  - deployment.yaml
configMapGenerator:
  - name: api-config
    literals:
      - LOG_LEVEL=info

# overlays/prod/resources.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: api
          resources:
            limits: { memory: 512Mi }

# overlays/prod/kustomization.yaml
namespace: shop-prod
resources:
  - ../../base
images:
  - name: registry.local/api
    digest: sha256:e9646e3580e8557fc7a6609baf5b8585a9bfcd652268c0cb5fff1ded9d7e77f4
replicas:
  - name: api
    count: 6
configMapGenerator:
  - name: api-config
    behavior: merge
    literals:
      - LOG_LEVEL=warn
patches:
  - path: resources.yaml          # strategic merge
  - target: { kind: Deployment, name: api }
    patch: |-                     # JSON 6902
      - op: add
        path: /spec/template/spec/priorityClassName
        value: business-critical

$ kubectl kustomize base | grep -E 'name: api-config|LOG_LEVEL'
  LOG_LEVEL: info
  name: api-config-hf678c7m2b
            name: api-config-hf678c7m2b
$ kubectl kustomize overlays/prod
…
  name: api-config-dfk4bdbtkk
  namespace: shop-prod
…
  replicas: 6
…
            name: api-config-dfk4bdbtkk
        image: registry.local/api@sha256:e9646e3580e8557fc7a6609baf5b8585a9bfcd652268c0cb5fff1ded9d7e77f4
…
      priorityClassName: business-critical

Хеш содержимого в имени ConfigMap меняет шаблон пода при правке конфига, и начинается выкатка, как с checksum/config из главы 3.1. Старые ConfigMap остаются: kubectl apply без --prune лишнее не удаляет.

Helm или Kustomize

$ kubectl get cronjob report -o jsonpath='{.status.lastScheduleTime} {.status.lastSuccessfulTime}{"\n"}'
$ kubectl events --for cronjob/report
$ kubectl get jobs -o custom-columns='NAME:.metadata.name,SLOT:.metadata.annotations.batch\.kubernetes\.io/cronjob-scheduled-timestamp'

    0s after GC       memory.current=306Mi  working_set=306Mi  heap_objects=0Mi    heap_free=300Mi  heap_released=2Mi
  120s idle           memory.current=306Mi  working_set=306Mi  heap_objects=0Mi    heap_free=300Mi  heap_released=2Mi
  135s idle           memory.current=208Mi  working_set=208Mi  heap_objects=0Mi    heap_free=202Mi  heap_released=100Mi
  150s idle           memory.current=7Mi    working_set=7Mi    heap_objects=0Mi    heap_free=0Mi    heap_released=302Mi

3.4Сеть, доступ и отладка

Запрос из пода к соседу проходит через DNS-имя, адрес Service, правила kube-proxy и сетевую политику, а право ходить в API держится на токене и RBAC. Ломается любое звено одинаково невнятно, таймаутом или отказом, так что ниже звенья разобраны по очереди.

Кластер: kind 0.33.0, Kubernetes 1.37.0, один узел dv-k8s-control-plane, containerd 2.3.4, kindnet, CoreDNS 1.14.6. Его только читали: манифесты проверены --dry-run=server, а то, что без записи не увидеть, описано по документации и исходникам 1.37. Команды с # выполнены на узле.

Service: адрес, которого нет ни на одном интерфейсе

В главе 3.1 Service назван набором правил в ядре узла. Два таких Service есть почти в любом кластере:

$ kubectl get svc,endpointslices -A -o wide
NAMESPACE     NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE     SELECTOR
default       service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP                  4m57s   <none>
kube-system   service/kube-dns     ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   4m55s   k8s-app=kube-dns

NAMESPACE     NAME                                            ADDRESSTYPE   PORTS        ENDPOINTS               AGE
default       endpointslice.discovery.k8s.io/kubernetes       IPv4          6443         172.23.0.2              4m57s
kube-system   endpointslice.discovery.k8s.io/kube-dns-wkh2n   IPv4          53,53,9153   10.244.0.4,10.244.0.2   4m49s
$ kubectl get cm kube-proxy -n kube-system -o jsonpath='{.data.config\.conf}' | grep '^mode:'
mode: iptables

Адрес 10.96.0.10 никто не слушает, его знают только правила kube-proxy на каждом узле. Если режим не задан, kube-proxy 1.37 берёт iptables. Режим nftables стабилен с 1.33, на свежих ядрах советуют его, а ipvs устарел в 1.35: kube-proxy обещает отключить его по умолчанию в 1.40 и удалить в 1.43. Правила для DNS по UDP:

# iptables-save -t nat | grep 'A KUBE-SERVICES.*kube-dns:dns cluster IP'
-A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
# iptables-save -t nat | grep '^-A KUBE-SVC-TCOU7JCQXEZGVUNU'
-A KUBE-SVC-TCOU7JCQXEZGVUNU ! -s 10.244.0.0/16 -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-MARK-MASQ
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 10.244.0.2:53" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-YIL6JZP7A3QYXJU2
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 10.244.0.4:53" -j KUBE-SEP-WXWGHGKZOCNYRYI7

KUBE-SERVICES подключена к PREROUTING и OUTPUT и по адресу и порту отправляет пакет в цепочку сервиса. Там первое правило метит для MASQUERADE пакеты не из сети подов, например с узла: им подставят адрес узла, и ответ вернётся тем же путём. Дальше лестница: первое правило срабатывает с вероятностью 0,5, второе забирает остальное, а цепочка KUBE-SEP-… делает DNAT на под. Для N эндпоинтов вероятности 1/N, 1/(N−1) и так до 1/2 (writeServiceToEndpointRules в pkg/proxy/iptables/proxier.go).

Случайность видна по счётчикам. dig в сетевом namespace узла отправил тысячу запросов на ClusterIP:

# iptables-save -c -t nat | grep -o '^\[[0-9:]*\].*kube-dns:dns -> [0-9.:]*'
[1434:153438] -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 10.244.0.2:53
[1491:159522] -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 10.244.0.4:53
$ docker run --rm --network container:dv-k8s-control-plane --entrypoint sh \
    registry.k8s.io/e2e-test-images/agnhost:2.39 -c \
    'i=0; while [ $i -lt 1000 ]; do echo kube-dns.kube-system.svc.cluster.local; i=$((i+1)); done > /tmp/q; dig @10.96.0.10 +short -f /tmp/q | sort | uniq -c'
   1000 10.96.0.10
# iptables-save -c -t nat | grep -o '^\[[0-9:]*\].*kube-dns:dns -> [0-9.:]*'
[1921:205547] -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 10.244.0.2:53
[1982:212059] -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns -> 10.244.0.4:53
# conntrack -L -p udp --orig-dst 10.96.0.10 2>/dev/null | grep -o 'src=10.244.0.[0-9]*' | sort | uniq -c
    487 src=10.244.0.2
    491 src=10.244.0.4

Счётчики выросли на 487 и 491, как и число записей conntrack, а запросов было 1000: таблицу nat проходит только первый пакет потока (глава 1.3 статьи «Linux и ОС»), а 22 запроса ушли с порта, для которого запись в этой серии уже была. С TCP под выбирается на SYN. Если у Service нет готовых эндпоинтов, в filter стоит REJECT с комментарием has no endpoints, и клиент сразу получает отказ. В режиме nftables сервис ищется в словаре service-ips, без перебора всех сервисов подряд, а эндпоинт выбирает numgen random mod N.

EndpointSlice и sessionAffinity

Адреса kube-proxy берёт из EndpointSlice: до 100 адресов в срезе (--max-endpoints-per-slice), у каждого свои условия.

$ kubectl get endpointslices -n kube-system -l kubernetes.io/service-name=kube-dns \
    -o jsonpath='{range .items[*].endpoints[*]}{.addresses[0]} {.conditions} {.targetRef.name}{"\n"}{end}'
10.244.0.4 {"ready":true,"serving":true,"terminating":false} coredns-559f6c778d-tdsh4
10.244.0.2 {"ready":true,"serving":true,"terminating":false} coredns-559f6c778d-gx9h8

ready значит «готов и не удаляется», serving повторяет готовность пода, terminating говорит об удалении; как они меняются при остановке, разобрано в главе 3.2. Endpoints в 1.33 объявлен устаревшим, и kubectl get endpoints из главы 3.1 печатает об этом Warning.

# orders-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector:
    app: orders
  ports:
    - name: http
      port: 80
      targetPort: 8080
  sessionAffinity: ClientIP

$ kubectl apply --dry-run=server -f orders-svc.yaml \
    -o jsonpath='{.spec.clusterIP} {.spec.sessionAffinity} {.spec.sessionAffinityConfig}{"\n"}'
10.96.0.0 ClientIP {"clientIP":{"timeoutSeconds":10800}}

sessionAffinity: ClientIP закрепляет клиента за подом на 10800 секунд (допустимо до 86400). Адрес 10.96.0.0 подставил dry-run, настоящий ClusterIP не выделен. В iptables закрепление держит модуль recent: KUBE-SEP-… запоминает источник, а в KUBE-SVC-… перед лестницей встают правила -m recent --rcheck --seconds 10800 --reap. Список у каждого узла свой, клиентом считается IP, и весь трафик из-за одного NAT или от ingress-контроллера выглядит одним клиентом.

CoreDNS и записи Service

$ kubectl get cm coredns -n kube-system -o jsonpath='{.data.Corefile}'
.:53 {
    errors
    health {
       lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
       pods insecure
       fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
       max_concurrent 1000
    }
    cache 30 {
       disable success cluster.local
       disable denial cluster.local
    }
    loop
    reload
    loadbalance
}

kubernetes отвечает за cluster.local по данным из API, pods insecure добавляет записи вида 10-244-0-2.kube-system.pod.cluster.local без проверки пода. forward отправляет остальное серверам из resolv.conf пода CoreDNS, cache зону кластера не кэширует, loadbalance перемешивает A-записи. Ниже dig из образа agnhost в сетевом namespace узла:

# dig +noall +answer @10.96.0.10 kube-dns.kube-system.svc.cluster.local
kube-dns.kube-system.svc.cluster.local.	30 IN A	10.96.0.10
# dig +noall +answer @10.96.0.10 SRV _dns._udp.kube-dns.kube-system.svc.cluster.local
_dns._udp.kube-dns.kube-system.svc.cluster.local. 30 IN	SRV 0 100 53 kube-dns.kube-system.svc.cluster.local.
# dig @10.96.0.10 api.example.com.default.svc.cluster.local | grep -E "status|flags"
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25361
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096

На несуществующее имя зоны CoreDNS отвечает NXDOMAIN сам, с флагом aa. У headless Service нет ни адреса, ни правил kube-proxy, а записи по спецификации DNS для Kubernetes 1.1.0 такие:

# orders-headless.yaml
apiVersion: v1
kind: Service
metadata:
  name: orders-headless
spec:
  clusterIP: None
  selector:
    app: orders
  ports:
    - name: grpc
      port: 9000

$ kubectl apply --dry-run=server -f orders-headless.yaml \
    -o jsonpath='{.spec.clusterIP} {.spec.clusterIPs}{"\n"}'
None ["None"]

Hostname эндпоинт получает, когда у пода есть hostname и subdomain с именем Service, StatefulSet ставит их сам. gRPC за обычным Service держит одно соединение с одним подом (статья «Сети», глава 9.4). Headless Service отдаёт готовые адреса на момент запроса, а grpc-go 1.83 перечитывает DNS при обрыве соединения, не чаще раза в 30 секунд и без оглядки на TTL. Новые поды клиент увидит после обрыва, поэтому на сервере ставят MaxConnectionAge.

ndots:5: восемь запросов на одно имя

Под с dnsPolicy: ClusterFirst, это значение по умолчанию, получает resolv.conf от kubelet:

# cat /var/lib/containerd/io.containerd.grpc.v1.cri/sandboxes/$(crictl pods -q --name local-path-provisioner)/resolv.conf
search local-path-storage.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

kubelet (GetPodDNS в pkg/kubelet/network/dns/dns.go) ставит домены <namespace>.svc.<домен>, svc.<домен>, <домен> и домены узла, сервер из clusterDNS и ndots:5, а опции узла отбрасывает. Поды CoreDNS с dnsPolicy: Default получили файл узла как есть: сервер 192.168.65.254 (DNAT на DNS Docker) и ndots:0. Под с hostNetwork и ClusterFirst kubelet тоже переводит на Default, нужен ClusterFirstWithHostNet.

С ndots:5 имя, где точек меньше пяти, резолвер сначала пробует с каждым доменом поиска и потом как есть. В api.example.com две точки, в orders.default.svc.cluster.local четыре. Стенд в Docker: CoreDNS 1.14.6 с плагином log, у клиента resolv.conf пода из default, где вместо 10.96.0.10 этот CoreDNS, а resolve на Go 1.27.1 (CGO_ENABLED=0) вызывает net.DefaultResolver.LookupHost:

$ docker run --rm --network dv-c4-dns -v "$PWD/resolv.conf:/etc/resolv.conf:ro" \
    -v "$PWD/resolve:/resolve:ro" debian:13 /resolve api.example.com
api.example.com [203.0.113.10] <nil> 1ms
$ docker logs dv-c4-coredns 2>&1 | awk '/INFO/ {print $5, $7, $12}' | tr -d '"'
AAAA api.example.com.default.svc.cluster.local. NXDOMAIN
A api.example.com.default.svc.cluster.local. NXDOMAIN
AAAA api.example.com.svc.cluster.local. NXDOMAIN
A api.example.com.svc.cluster.local. NXDOMAIN
A api.example.com.cluster.local. NXDOMAIN
AAAA api.example.com.cluster.local. NXDOMAIN
A api.example.com. NOERROR
AAAA api.example.com. NOERROR

Шесть запросов из восьми ушли впустую, и каждый прошёл DNAT и conntrack. Отказы CoreDNS даёт сам, наружу уходят последние два. Число запросов зависит от библиотеки:

• Точка в конце делает имя полным. HTTP-клиент Go 1.27.1 шлёт SNI и сверяет сертификат без точки, а Host уходит как api.example.com., и принять его должен сервер.
• dnsConfig с ndots: "2" пускает имя с двумя точками как есть первым. Несуществующее имя Go и glibc всё равно проведут по доменам, а musl при точках не меньше ndots поиск не делает (name_from_dns_search), и orders.default.svc у него не нашёлся.
• NodeLocal DNSCache (стабилен с 1.18) ставит кэш на узел: запросов не меньше, но они минуют DNAT и conntrack, а отказы кэшируются рядом с подом.

# orders-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: orders-dns
spec:
  containers:
    - name: app
      image: registry.local/orders:1.4.2
  dnsConfig:
    options:
      - name: ndots
        value: "2"

$ kubectl apply --dry-run=server -f orders-pod.yaml \
    -o jsonpath='{.spec.dnsPolicy} {.spec.dnsConfig}{"\n"}'
ClusterFirst {"options":[{"name":"ndots","value":"2"}]}

Ingress, Gateway API и конец ingress-nginx

Таймауты, переписывание путей и canary в Ingress каждый контроллер задаёт своими аннотациями, и манифест под один контроллер другому не подходит. Документация называет API Ingress замороженным (не удалят, но и развивать не будут) и рекомендует Gateway API. Его CRD от SIG Network ставят отдельно, в kind их нет:

$ kubectl api-resources | grep -i -E 'gateway|ingress'
ingressclasses                                   networking.k8s.io/v1              false        IngressClass
ingresses                           ing          networking.k8s.io/v1              true         Ingress
$ kubectl apply --dry-run=server -f orders-route.yaml
error: resource mapping not found for name: "orders" namespace: "default" from "orders-route.yaml": no matches for kind "HTTPRoute" in version "gateway.networking.k8s.io/v1"
ensure CRDs are installed first

# orders-route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  namespace: default
spec:
  parentRefs:
    - name: public
      namespace: infra
  hostnames: ["api.example.com"]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /orders }
      backendRefs:
        - name: orders
          port: 80

В v1.6.2 (3 сентября 2026) стандартный канал держит в v1 GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant, BackendTLSPolicy, ListenerSet, TLSRoute, TCPRoute и UDPRoute, последние два с v1.6.0. GRPCRoute сопоставляет запросы по сервису и методу gRPC, то есть шлюз видит отдельные вызовы, а не соединение.

NetworkPolicy: кто её исполняет

NetworkPolicy описывает разрешённые соединения, а исполняет её CNI. API-сервер примет политику в любом кластере, поля «применена» у неё нет, а по документации без контроллера, который её реализует, политика не действует.

# orders-netpol.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: default-deny, namespace: default}
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: allow-dns, namespace: default}
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels: {kubernetes.io/metadata.name: kube-system}
          podSelector:
            matchLabels: {k8s-app: kube-dns}
      ports: [{protocol: UDP, port: 53}, {protocol: TCP, port: 53}]

$ kubectl apply --dry-run=server -f orders-netpol.yaml
networkpolicy.networking.k8s.io/default-deny created (server dry run)
networkpolicy.networking.k8s.io/allow-dns created (server dry run)
$ kubectl logs -n kube-system ds/kindnet \
    | grep -E 'kube-network-policies|Policy engine'
I0917 07:22:14.174492       1 controller.go:173] "Starting controller" name="kube-network-policies"
I0917 07:22:14.675365       1 controller.go:185] "Policy engine is ready."

Под изолирован в направлении, если его выбирает хоть одна политика с этим типом в policyTypes; разрешения складываются, запретов в API нет. Ответ на разрешённое соединение проходит сам, трафик с узла пода разрешён всегда, и пробы kubelet политика не режет. Service по имени не указать: поды выбирают метками, namespace — меткой kubernetes.io/metadata.name.

В kind 0.33 политики исполняет kindnet: с kind 0.24 в него встроен kube-network-policies. У его ClusterRole есть watch на networkpolicies, а на узле таблица inet kindnet-network-policies с набором podips-v4 и правилами ip saddr @podips-v4 queue flags bypass to 101: пакеты подов под политикой уходят через NFQUEUE в kindnetd, разрешённое соединение помечается меткой conntrack.

ServiceAccount, токен пода и RBAC

Под работает от имени ServiceAccount, по умолчанию default, и admission-плагин монтирует ему том kube-api-access-…, это видно и в dry-run:

$ kubectl apply --dry-run=server -f orders-pod.yaml -o jsonpath='{.spec.serviceAccountName} {.spec.volumes[*].name}{"\n"}'
default kube-api-access-h8g6x
$ kubectl describe pod -n kube-system coredns-559f6c778d-gx9h8 | sed -n '/kube-api-access-b6wbz:/,/DownwardAPI/p'
  kube-api-access-b6wbz:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    Optional:                false
    DownwardAPI:             true

Projected-том кладёт в /var/run/secrets/kubernetes.io/serviceaccount токен, CA кластера и имя namespace. Токен выдаёт TokenRequest, это JWT с привязкой к поду: в нём имя и UID пода, узла и ServiceAccount. Когда объект пода с этим UID исчезает из API, токен перестаёт действовать. Срок 3607 секунд, час и семь секунд, API-сервер узнаёт по константе WarnOnlyBoundTokenExpirationSeconds: с --service-account-extend-token-expiration (включён по умолчанию) выписывает токен на год, а настоящий срок пишет в warnafter. Дальше токен работает, но в аудите каждый запрос с ним помечен authentication.k8s.io/stale-token. kubelet обновляет файл после 80% срока, около 48 минут. Сервису без API том не нужен: automountServiceAccountToken: false.

Права даёт RBAC: Role действует в namespace, ClusterRole во всём кластере или как шаблон, RoleBinding и ClusterRoleBinding связывают роль с субъектом. Правила только разрешают и складываются. CoreDNS:

$ kubectl get clusterrolebinding system:coredns -o jsonpath='{.roleRef.name} {.subjects}{"\n"}'
system:coredns [{"kind":"ServiceAccount","name":"coredns","namespace":"kube-system"}]
$ kubectl auth can-i --list --as=system:serviceaccount:kube-system:coredns \
    | grep -E '^(Resources|endpoints|namespaces|pods|services|endpointslices)'
Resources                                       Non-Resource URLs                      Resource Names   Verbs
endpoints                                       []                                     []               [list watch]
namespaces                                      []                                     []               [list watch]
pods                                            []                                     []               [list watch]
services                                        []                                     []               [list watch]
endpointslices.discovery.k8s.io                 []                                     []               [list watch]
$ kubectl auth can-i get secrets -n kube-system --as=system:serviceaccount:kube-system:coredns
no

--as работает через impersonation, а встроенная роль edit в 1.37 разрешает impersonate на ServiceAccount: разработчик с edit может действовать от имени любого ServiceAccount своего namespace.

События, describe и логи упавшего контейнера

Event живёт час (--event-ttl API-сервера), и ночное падение утром в событиях не найти. kubectl get events выводит их в порядке имён, а имя события начинается с имени объекта, так что строки сгруппированы по объектам. kubectl events сортирует по времени, умеет --for, --types=Warning и -w:

$ kubectl events -n kube-system --for pod/coredns-559f6c778d-gx9h8
LAST SEEN   TYPE      REASON             OBJECT                         MESSAGE
27m         Warning   FailedScheduling   Pod/coredns-559f6c778d-gx9h8   0/1 nodes are available: 1 node(s) had untolerated taint(s). preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.
26m         Normal    Scheduled          Pod/coredns-559f6c778d-gx9h8   Successfully assigned kube-system/coredns-559f6c778d-gx9h8 to dv-k8s-control-plane
26m         Normal    Pulled             Pod/coredns-559f6c778d-gx9h8   Container image "registry.k8s.io/coredns/coredns:v1.14.6" already present on machine and can be accessed by the pod
26m         Normal    Created            Pod/coredns-559f6c778d-gx9h8   Container created
26m         Normal    Started            Pod/coredns-559f6c778d-gx9h8   Container started
26m         Warning   Unhealthy          Pod/coredns-559f6c778d-gx9h8   Readiness probe failed: Get "http://10.244.0.2:8181/ready": dial tcp 10.244.0.2:8181: connect: connection refused
26m         Warning   Unhealthy          Pod/coredns-559f6c778d-gx9h8   Readiness probe failed: HTTP probe failed with statuscode: 503

Здесь вся история старта: планировщик ждал готовности узла, потом readiness-проба не достучалась до порта, а затем получала 503, пока плагин kubernetes не синхронизировался (в логе пода plugin/ready: Plugins not ready: "kubernetes"). На старте это обычный шум. describe pod показывает события внизу, а выше то, чего в них нет:

logs --previous отдаёт лог прошлого экземпляра, а kubelet хранит один мёртвый экземпляр на контейнер (--maximum-dead-containers-per-container, по умолчанию 1): лог позапрошлого падения уже не достать. Без перезапусков ответ такой:

$ kubectl logs -n kube-system coredns-559f6c778d-gx9h8 --previous
Error from server (BadRequest): previous terminated container "coredns" in pod "coredns-559f6c778d-gx9h8" not found
$ kubectl logs -n kube-system -l k8s-app=kube-proxy | wc -l
10

С селектором kubectl logs отдаёт по 10 последних строк с пода (справка к --tail): начало лога так не увидеть.

kubectl debug и port-forward

В distroless нет shell (для Docker это разобрано в главе 2.2 статьи «Docker»). kubectl debug добавляет в работающий под эфемерный контейнер через подресурс pods/ephemeralcontainers, не перезапуская его. Команды раздела не запускались (эфемерный контейнер меняет под), поведение взято из kubectl explain и исходников kubectl 1.37.

$ kubectl debug -it orders-7d9f-xk2 --image=busybox:1.37 --target=app -- sh

Эфемерный контейнер нельзя изменить или удалить, у него нет resources, портов и проб, после выхода он остаётся в поде завершённым. Сеть у контейнеров пода общая, а --target=app добавляет пространство процессов app: ps покажет сервис, его файлы видны в /proc/<pid>/root, если хватает прав на ptrace. Остальное решает профиль:

legacy был умолчанием до 1.36 и уйдёт в 1.39. Под node-debugger-… от debug node/ терпит все taint и после выхода остаётся, удаляют его руками. С general он не привилегирован, но chroot /host вопреки документации пройдёт: право на chroot есть по умолчанию.

kubectl port-forward открывает поток через API-сервер (pods/portforward, с 1.31 по умолчанию поверх WebSocket) до kubelet, а containerd в сетевом namespace пода подключается к localhost:<порт> (sandbox_portforward_linux.go в containerd 2.3.4). Service, kube-proxy и политики в этом пути не участвуют, и port-forward service/orders лишь выбирает один под по селектору.

$ kubectl debug orders-7d9f-xk2 -it --copy-to=orders-debug --image=busybox:1.37 -- sh

# orders-egress-api.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: orders-to-apiserver, namespace: default}
spec:
  podSelector:
    matchLabels: {app: orders}
  policyTypes: [Egress]
  egress:
    - to: [{ipBlock: {cidr: 172.23.0.2/32}}]
      ports: [{protocol: TCP, port: 6443}]

$ kubectl get endpointslices kubernetes \
    -o jsonpath='{.endpoints[0].addresses[0]} {.ports[0].port}{"\n"}'
172.23.0.2 6443
$ kubectl apply --dry-run=server -f orders-egress-api.yaml
networkpolicy.networking.k8s.io/orders-to-apiserver created (server dry run)

$ kubectl apply --dry-run=server -f orders-from-api.yaml -o jsonpath='{.spec.policyTypes} {.spec.ingress[0].from}{"\n"}'
["Ingress"] [{"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"shop"}},"podSelector":{"matchLabels":{"app":"api"}}}]
$ kubectl apply --dry-run=server -f orders-from-api-or.yaml -o jsonpath='{.spec.policyTypes} {.spec.ingress[0].from}{"\n"}'
["Ingress"] [{"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"shop"}}},{"podSelector":{"matchLabels":{"app":"api"}}}]

# orders-rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata: {name: orders, namespace: default}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: orders-config-reader, namespace: default}
rules:
  - apiGroups: [""]
    resources: [configmaps]
    resourceNames: [orders-flags]
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: {name: orders-config-reader, namespace: default}
subjects:
  - {kind: ServiceAccount, name: orders, namespace: default}
roleRef: {apiGroup: rbac.authorization.k8s.io, kind: Role, name: orders-config-reader}

$ kubectl apply --dry-run=server -f orders-rbac.yaml
serviceaccount/orders created (server dry run)
role.rbac.authorization.k8s.io/orders-config-reader created (server dry run)
rolebinding.rbac.authorization.k8s.io/orders-config-reader created (server dry run)