Оркестрация контейнеров: архитектура Kubernetes

В темах 3–6 контейнер рассматривался в пределах одного хоста. Тема 3 показала, что контейнер — это обычный процесс Linux, изолированный пространствами имён и ограниченный контрольными группами (cgroups), тема 5 — как задаются его ресурсы, политика перезапуска и проверка здоровья, тема 6 — как контейнеры получают адреса, находят друг друга по именам и публикуют порты, а Docker Compose описывает приложение из нескольких сервисов одним файлом. Всё это работает, пока приложение помещается на одну машину и пока эта машина исправна. Открытым остался вопрос, который на одном хосте не возникает: кто и как решает, на каком из многих серверов запустить контейнер, что делать, когда сервер пропал, и как обновить сотню копий сервиса, не прервав обслуживание.

Эти задачи решает оркестратор контейнеров. Фактическим стандартом стал Kubernetes — система, созданная в Google на основе десятилетнего опыта внутренних систем Borg и Omega и открытая в 2014 году; с 2015 года проект развивается под эгидой фонда Cloud Native Computing Foundation (CNCF) ¹. Kubernetes не запускает контейнеры сам: на каждом узле это делает та же связка «среда выполнения → runc», что и в Docker (тема 3). Kubernetes добавляет над ней распределённую систему управления, которая хранит описание желаемого состояния всего кластера и непрерывно приводит к нему фактическое.

Изложение построено так. Первый раздел вводит декларативную модель: желаемое состояние, контроллеры, цикл согласования и механизм подписки на изменения. Второй разбирает компоненты кластера, путь одной команды kubectl apply от манифеста до процесса на узле, хранилище etcd с его кворумом и поведение кластера при отказе узла и плоскости управления. Третий посвящён поду и его размещению: ресурсам и классам качества обслуживания, работе планировщика и пробам. Четвёртый — контроллерам рабочих нагрузок, прежде всего Deployment и его постепенному обновлению. Пятый — сети сервисов: Service, EndpointSlice, kube-proxy, DNS, Ingress, а также горизонтальному автомасштабированию. Шестой раздел собирает диагностику типовых состояний пода, ограничения модели и типичные ошибки понимания. Примеры по возможности строятся на приложении «Заметки» из курсового проекта: backend на Node.js с портом 3000 и двумя проверками — GET /api/live (процесс жив) и GET /api/health (процесс жив и база отвечает), frontend на nginx с портом 8080 и PostgreSQL. Конфигурация, секреты и тома вынесены в тему 8, права доступа, сетевые политики и securityContext — в тему 11.

Декларативная модель управления

Чего не хватает одному хосту

Пусть backend «Заметок» нужно запустить в трёх копиях на кластере из пяти серверов. С инструментами темы 6 это выглядит как последовательность команд: зайти на сервер 1 и выполнить docker run, затем на сервер 3, затем на сервер 4. Сразу возникают вопросы, на которые эти команды не отвечают. На каких серверах хватает памяти и процессора? Что делать, если сервер 3 перезагрузился ночью, — политика restart: always поднимет контейнер на нём же, но если сервер не вернулся, копий станет две, и никто об этом не узнает. Как клиенты узнают адреса копий, если копии переезжают? Как заменить версию 1.0 на 2.0 так, чтобы в каждый момент работало не меньше трёх копий?

Можно написать скрипт, который всё это делает. Такой скрипт будет императивным (англ. imperative): он описывает последовательность действий. Его слабость — в промежуточных состояниях. Если на шаге «остановить старую копию на сервере 4» оборвалась сеть, скрипт завершится с ошибкой, а система окажется в состоянии, которое никто не планировал: часть копий новые, часть старые, одна потеряна. Повторный запуск того же скрипта не обязательно приведёт систему в порядок, потому что скрипт рассчитан на определённое начальное состояние.

Kubernetes устроен иначе. Пользователь описывает не действия, а желаемое состояние (англ. desired state): «должно работать три копии пода с образом notes-backend:1.0, каждой нужно 0,2 ядра и 256 МиБ памяти». Это описание сохраняется в кластере как объект. Дальше специальные программы — контроллеры — сами вычисляют, какие действия нужны, чтобы фактическое состояние совпало с описанным, и повторяют это вычисление бесконечно. Такой подход называют декларативным (англ. declarative) ¹³.

Контроллеры и цикл согласования

Контроллер (англ. controller) — программа, которая следит за объектами одного типа и выполняет цикл согласования (англ. reconciliation loop): прочитать желаемое состояние, прочитать фактическое, вычислить разницу и сделать шаг, уменьшающий её. Цикл показан на рисунке ниже. Контроллер ReplicaSet, например, видит в описании replicas: 3, подсчитывает поды, подходящие под селектор этого ReplicaSet, и, обнаружив только два, создаёт ещё один. Обнаружив четыре, удаляет лишний. Обнаружив три, ничего не делает.

У этого устройства три важных следствия. Во-первых, контроллеру безразлично, почему возникло расхождение: под удалили вручную, его вытеснили с перегруженного узла или пропал весь узел — реакция одна и та же. Во-вторых, повторное выполнение безопасно: если контроллер упал посреди работы и перезапустился, он просто снова сравнит состояния и продолжит с того места, где система находится сейчас, а не с того, где остановилась программа. В-третьих, контроллеры легко комбинируются. Контроллер Deployment не создаёт поды: он создаёт и масштабирует объекты ReplicaSet, а поды из них создаёт контроллер ReplicaSet. Каждый отвечает за свой уровень и не знает о внутреннем устройстве соседа.

Объект Kubernetes отражает это разделение в своей структуре. Почти у каждого объекта есть поле spec — желаемое состояние, которое пишет пользователь, — и поле status — наблюдаемое состояние, которое пишет контроллер. Например, у Deployment в spec.replicas указано желаемое число копий, а в status.readyReplicas — сколько из них сейчас готовы. Расхождение spec и status — нормальное рабочее состояние системы в момент изменений; задача контроллеров — сделать его временным.

Подписка на изменения вместо опроса

Чтобы сравнивать состояния, контроллер должен знать о каждом изменении объектов. Простейший способ — опрашивать сервер API раз в несколько секунд — плохо масштабируется: в кластере тысячи подов и десятки контроллеров, и каждый опрос возвращал бы весь список заново. Поэтому сервер API поддерживает операцию watch — подписку на изменения ⁵. Каждый объект имеет поле metadata.resourceVersion, монотонно растущую метку версии. Клиент получает список объектов вместе с текущей версией, а затем открывает долгоживущий запрос GET /api/v1/namespaces/lab07/pods?watch=1&resourceVersion=10245, в ответ на который сервер присылает поток событий ADDED, MODIFIED, DELETED обо всех изменениях после указанной версии.

Сервер хранит историю изменений ограниченное время: в кластерах на etcd 3 — по умолчанию последние 5 минут ⁵. Если клиент отключился дольше, сервер отвечает кодом 410 Gone, и клиент обязан заново получить полный список и начать подписку с новой версии. В клиентских библиотеках эта логика «список, затем подписка» реализована готовой; поверх неё строится локальный кэш объектов (в библиотеке для Go он называется informer), из которого контроллер читает данные, не обращаясь к серверу.

Здесь проявляется ключевая особенность проектирования: контроллеры Kubernetes реагируют на уровень, а не на фронт (англ. level-triggered, а не edge-triggered). Событие watch служит лишь сигналом «что-то изменилось, пересчитай». Вычисление же всегда опирается на текущее состояние целиком, взятое из кэша. Если событие потерялось — при обрыве соединения, перезапуске контроллера, переполнении очереди, — следующее событие или периодическая ресинхронизация всё равно приведут к правильному результату. Система, построенная на реакции на отдельные события («создан под — увеличить счётчик»), накапливала бы ошибку от каждого пропущенного события ¹.

Объекты, пространства имён и метки

Всё, чем управляет Kubernetes, — объекты API: Pod, ReplicaSet, Deployment, Service, Node и десятки других типов. У каждого объекта есть тип (kind), версия API (apiVersion), метаданные (metadata) и, как правило, spec и status. Объекты большинства типов принадлежат пространству имён (англ. namespace) — логическому разделу кластера, внутри которого имена уникальны. Это не пространство имён Linux из темы 3: никакой изоляции процессов оно не создаёт, а служит областью видимости имён, единицей назначения прав (тема 11) и квот. Узлы, сами пространства имён и некоторые другие объекты от пространства имён не зависят.

Связь между объектами в Kubernetes устроена не через прямые ссылки, а через метки (англ. labels) — пары «ключ — значение» в metadata.labels — и селекторы (англ. selectors), выбирающие объекты по меткам. ReplicaSet не хранит список «своих» подов: он считает своими все поды пространства имён, метки которых подходят под его селектор. Service не хранит адреса подов: он вычисляет их по селектору. Это делает связи слабыми и вычисляемыми: под можно «вынуть» из ReplicaSet и Service, просто сменив ему метку, — контроллер создаст замену, а вынутый под останется для отладки.

Второй и третий столбцы таблицы объясняют одну из самых частых ошибок: опечатка в селекторе Service не вызывает никакой ошибки при создании, потому что Service без подходящих подов — допустимое состояние. Она проявляется лишь тем, что запросы к сервису не проходят. Этот случай разбирается в лабораторной работе.

Кроме меток, у объекта есть аннотации (англ. annotations) — тоже пары «ключ — значение», но не участвующие в выборе; в них хранят служебную информацию для инструментов. И есть ссылки владения metadata.ownerReferences: под, созданный ReplicaSet, ссылается на него как на владельца. По этим ссылкам работает сборщик мусора: удаление Deployment каскадно удаляет его ReplicaSet, а те — поды.

Архитектура кластера и путь запроса

Плоскость управления и рабочие узлы

Кластер Kubernetes делится на плоскость управления (англ. control plane) и рабочие узлы (англ. worker nodes) ⁴. Плоскость управления хранит состояние кластера и принимает решения, узлы выполняют поды. В учебном кластере minikube оба набора компонентов работают на одной машине, в промышленном кластере плоскость управления обычно занимает три отдельных сервера, а рабочих узлов — от нескольких до тысяч. Общая схема показана на рисунке.

Главная архитектурная мысль таблицы — в последнем столбце. Единственный компонент с долговременным состоянием — etcd, а единственный, кто с ним разговаривает, — kube-apiserver. Все остальные компоненты, включая планировщик, контроллеры и kubelet, — клиенты сервера API, такие же, как kubectl: они читают объекты, подписываются на изменения и пишут результаты своей работы обратно через API. Компоненты не вызывают друг друга напрямую. Планировщик не сообщает kubelet, что под назначен на его узел: он записывает имя узла в объект Pod, а kubelet узнаёт об этом из своей подписки. Такое устройство позволяет перезапускать и заменять любой компонент, кроме etcd, без потери информации: после перезапуска он прочитает всё нужное из API ¹⁴.

Связь kubelet со средой выполнения идёт через интерфейс Container Runtime Interface (CRI) — набор вызовов gRPC вида RunPodSandbox, CreateContainer, StartContainer. Его реализуют containerd и CRI-O. Docker Engine интерфейса CRI не реализует; встроенная прослойка dockershim была удалена в Kubernetes 1.24, и с тех пор Docker Engine используется только через внешний адаптер cri-dockerd. Именно так устроен minikube с драйвером docker и средой выполнения docker: внутри узла-контейнера работает свой Docker Engine, а kubelet обращается к нему через cri-dockerd. Для понимания курса это различие несущественно: ниже CRI в любом случае та же связка containerd → shim → runc, что и в теме 3.

Путь одного kubectl apply

Сведём компоненты вместе, проследив одну команду — создание Deployment из трёх подов. Последовательность показана на рисунке ниже; номера в тексте соответствуют номерам стрелок.

1. kubectl читает манифест, определяет по apiVersion и kind адрес ресурса и отправляет запрос в kube-apiserver: POST для нового объекта или PATCH для существующего. Сервер API пропускает запрос через конвейер: аутентификация (кто это?), авторизация (можно ли ему это?), изменяющие контроллеры допуска (англ. mutating admission, могут дописать поля, например значения по умолчанию), проверка схемы объекта и проверяющие контроллеры допуска (англ. validating admission, могут отклонить запрос). Подробно конвейер разбирается в теме 11.
2. Объект записывается в etcd и получает resourceVersion. В этот момент kubectl получает ответ 201 Created и завершается: команда не ждёт, пока поды запустятся. Всё дальнейшее происходит асинхронно.
3. Контроллер Deployment получает по watch событие о новом Deployment.
4. Он создаёт ReplicaSet с тем же шаблоном пода и replicas: 3.
5. Контроллер ReplicaSet получает событие о новом ReplicaSet.
6. Он создаёт три объекта Pod. Поле spec.nodeName у них пустое: поды существуют только как записи в etcd, ни на одном узле ничего не запущено. Статус таких подов — Pending.
7. Планировщик подписан на поды с пустым nodeName и получает три события.
8. Для каждого пода он выбирает узел (как — разбирается в разделе о размещении) и записывает решение подобъектом Binding.
9. kubelet каждого узла подписан на поды со своим именем в spec.nodeName и получает событие.
10. kubelet вызывает среду выполнения через CRI: создаёт песочницу пода с сетевым пространством имён, загружает образ при необходимости, создаёт и запускает контейнеры.
11. kubelet записывает в status пода фазу Running, адрес пода и результаты проб; когда проба готовности проходит, условие Ready становится истинным.

Каждый шаг виден снаружи. Если запустить kubectl apply с флагом подробного журнала, видны HTTP-запросы шага 1; примерный вид вывода для нового объекта:

kubectl apply -f 10-echo-deployment.yaml -v=6

... loader.go:402] Config loaded from file:  /home/user/.kube/config
... round_trippers.go:632] "Response" verb="GET" url="https://192.168.49.2:8443/apis/apps/v1/namespaces/lab07/deployments/echo" status="404 Not Found" milliseconds=6
... round_trippers.go:632] "Response" verb="POST" url="https://192.168.49.2:8443/apis/apps/v1/namespaces/lab07/deployments?fieldManager=kubectl-client-side-apply&fieldValidation=Strict" status="201 Created" milliseconds=14
deployment.apps/echo created

Сначала kubectl пытается получить существующий объект и, получив 404, создаёт его. При повторном apply изменённого манифеста вместо POST будет PATCH: клиент сравнивает три версии — последнюю применённую (она хранится в аннотации kubectl.kubernetes.io/last-applied-configuration), текущую в кластере и новую из файла — и отправляет только разницу. С флагом --server-side это слияние выполняет сам сервер API, отслеживая, какой менеджер владеет каким полем. Шаги 3–11 видны в событиях пространства имён:

kubectl -n lab07 get events --sort-by=.lastTimestamp

LAST SEEN   TYPE     REASON              OBJECT                      MESSAGE
12s         Normal   ScalingReplicaSet   deployment/echo             Scaled up replica set echo-6d8f7c9b54 from 0 to 3
12s         Normal   SuccessfulCreate    replicaset/echo-6d8f7c9b54  Created pod: echo-6d8f7c9b54-q7lmz
12s         Normal   Scheduled           pod/echo-6d8f7c9b54-q7lmz   Successfully assigned lab07/echo-6d8f7c9b54-q7lmz to lab07-m02
11s         Normal   Pulled              pod/echo-6d8f7c9b54-q7lmz   Container image "lab07/echo:1.0" already present on machine
11s         Normal   Created             pod/echo-6d8f7c9b54-q7lmz   Created container: echo
11s         Normal   Started             pod/echo-6d8f7c9b54-q7lmz   Started container echo
...

Отправителей событий легко сопоставить с компонентами: ScalingReplicaSet пишет контроллер Deployment, SuccessfulCreate — контроллер ReplicaSet, Scheduled — планировщик, остальные — kubelet узла. Если цепочка обрывается, место обрыва указывает на виновника: есть SuccessfulCreate, но нет Scheduled — разбираться нужно с планировщиком и ресурсами; есть Scheduled, но нет Started — с узлом и образом.

etcd и кворум

Хранилище etcd работает как кластер из нескольких членов, согласующих каждую запись по алгоритму Raft ². Один из членов — лидер — принимает записи, добавляет их в свой журнал и рассылает остальным; запись считается подтверждённой (англ. committed), когда её сохранило на диск большинство членов, включая лидера. Если лидер пропадает, оставшиеся выбирают нового, но только большинством голосов. Большинство называется кворумом (англ. quorum). Для кластера из n членов размер кворума и число переживаемых отказов равны

q = \left\lfloor \frac{n}{2} \right\rfloor + 1, \qquad f = n - q = \left\lfloor \frac{n-1}{2} \right\rfloor.

Подставим значения ⁶:

Таблица объясняет, почему членов etcd всегда нечётное число. Переход от трёх к четырём не добавляет устойчивости (f остаётся 1), но увеличивает кворум с 2 до 3 и число машин, которые могут отказать. Хуже того, при разделении сети четыре члена могут распасться на две половины по два, и ни у одной не будет большинства — кластер перестанет принимать записи целиком. При нечётном числе одна из частей разделённой сети всегда содержит большинство и продолжает работу. Кластер из двух членов хуже кластера из одного: отказов он не переживает, а машин, отказ любой из которых его останавливает, — две. Документация Kubernetes рекомендует для промышленных кластеров пять членов etcd, позволяя пережить отказ двух ⁶.

Что значит «потеря кворума» для Kubernetes? Если из трёх членов etcd работает один, он не может подтвердить ни одной записи. Сервер API не может создать, изменить или удалить ни один объект, а согласованные чтения тоже завершаются ошибкой или тайм-аутом. Контроллеры не могут записать результаты, планировщик — назначить узел, kubelet — обновить статус. Управление кластером останавливается полностью. Но останавливается именно управление: работающие поды продолжают работать (об этом — в следующем подразделе). Восстановление после необратимой потери большинства членов — ручная процедура из резервной копии, поэтому регулярные снимки etcd (etcdctl snapshot save) — обязательная часть эксплуатации самостоятельно развёрнутого кластера.

Ещё два ограничения etcd определяют, что вообще можно хранить в объектах Kubernetes. Размер одного запроса к etcd по умолчанию ограничен 1,5 МиБ, поэтому объект API не может быть больше; размер всей базы по умолчанию ограничен 2 ГиБ. Объекты Kubernetes — это метаданные кластера, а не данные приложений: большие файлы, журналы и содержимое баз данных хранятся в томах и внешних хранилищах (темы 8 и 10).

Отказ узла и отказ плоскости управления

Узел сообщает о себе двумя способами ⁴. kubelet обновляет объект Lease в пространстве имён kube-node-lease — это лёгкое сердцебиение, по умолчанию раз в 10 секунд, — и периодически обновляет status объекта Node с условиями Ready, MemoryPressure, DiskPressure, PIDPressure. Контроллер узлов в kube-controller-manager каждые 5 секунд проверяет, когда узел последний раз давал о себе знать. Если сердцебиения нет дольше --node-monitor-grace-period (по умолчанию 50 секунд), условие Ready получает значение Unknown, и узел показывается как NotReady.

Сразу после этого на узел ставится ограничение (англ. taint) node.kubernetes.io/unreachable с эффектом NoExecute. Эффект NoExecute означает «поды, не допускающие этого ограничения, должны быть выселены с узла». Однако при создании каждого пода контроллер допуска DefaultTolerationSeconds добавляет ему допуски (англ. tolerations) к ограничениям node.kubernetes.io/unreachable и node.kubernetes.io/not-ready с tolerationSeconds: 300, если таких допусков нет в манифесте ⁸. Иначе говоря, под соглашается оставаться на недоступном узле 5 минут — на случай, если это кратковременный сбой сети, а не гибель машины. По истечении допуска поды узла помечаются на удаление, контроллеры ReplicaSet видят нехватку копий и создают замену, планировщик размещает её на исправных узлах.

Сложим времена для узла, который выключился в момент t = 0:

Итого с настройками по умолчанию замена подов отказавшего узла начинается примерно через 5 минут 50 секунд. Для сервиса с несколькими копиями на разных узлах это время не означает простоя — оставшиеся копии продолжают обслуживание, — но означает пониженную ёмкость. Если такая задержка неприемлема, в шаблон пода записывают собственные допуски с меньшим tolerationSeconds; в лабораторной работе значение 30 секунд сокращает время до замены примерно до 80 секунд. Слишком малое значение опасно: при кратковременном сетевом сбое все поды будут перезапущены без нужды. Поды, которые получили отметку удаления на недоступном узле, остаются в состоянии Terminating, пока узел не вернётся или объект Node не будет удалён: сервер API не может убедиться, что kubelet действительно остановил контейнеры, ведь связи с узлом нет ⁸. Для обычных Deployment это не мешает, а для приложений с состоянием, где две копии с одним именем недопустимы, это важное свойство (тема 8).

Скорость выселения дополнительно ограничена: в здоровой зоне доступности контроллер узлов ставит ограничения не чаще чем на один узел в 10 секунд (--node-eviction-rate равен 0,1), а если недоступна значительная доля узлов зоны, темп снижается или выселение прекращается вовсе. Логика проста: когда одновременно «пропало» больше половины узлов, вероятнее отказ сети или самой плоскости управления, чем одновременная гибель машин, и массовое выселение сделало бы только хуже ⁴.

Теперь об отказе самой плоскости управления. Если недоступен сервер API (или потерян кворум etcd, что для клиентов выглядит так же), на рабочих узлах происходит следующее:

• запущенные контейнеры продолжают работать: kubelet и среда выполнения от сервера API для этого не зависят;
• kubelet продолжает выполнять пробы и перезапускает упавшие контейнеры по restartPolicy пода, потому что это локальное решение;
• правила kube-proxy остаются в ядре в последнем известном виде, и трафик между сервисами продолжает ходить по ним;
• зато ничего нового не происходит: не создаются поды взамен потерянных, не обрабатываются отказы узлов, не масштабируется HPA, не применяются манифесты; изменения состава подов не отражаются в правилах kube-proxy.

Кластер без плоскости управления похож на самолёт с отключённым автопилотом: он продолжает лететь по текущему курсу, но не может его исправить. Поэтому плоскость управления промышленного кластера делают отказоустойчивой — три или пять серверов с etcd и несколькими экземплярами сервера API за балансировщиком, причём планировщик и kube-controller-manager работают в нескольких экземплярах, из которых активен один, выбранный через объект Lease (англ. leader election).

Pod, ресурсы и размещение

Pod как единица размещения

Pod (под) — наименьшая единица, которую размещает Kubernetes: группа из одного или нескольких контейнеров, которые всегда запускаются на одном узле и разделяют сетевое пространство имён — один IP-адрес, один localhost, одно пространство портов. Это прямое продолжение режима --network container: из темы 6, где второй контейнер подключался к сетевому пространству первого. В Kubernetes сетевое пространство создаётся заранее, при создании песочницы пода (во многих средах выполнения его держит крошечный служебный контейнер pause), а контейнеры приложения подключаются к нему. Поэтому перезапуск контейнера приложения не меняет адрес пода.

Как правило, под содержит один контейнер приложения. Несколько контейнеров объединяют, когда они действительно неразделимы: обязаны жить на одном узле, обмениваться данными через localhost или общий том и масштабироваться вместе. Типичные случаи — вспомогательный контейнер (англ. sidecar), например прокси, добавляющий TLS к приложению, или сборщик журналов, и инициализирующие контейнеры (англ. init containers), которые выполняются по очереди до старта основных и готовят окружение. Backend и PostgreSQL «Заметок» в один под не объединяют: их масштабируют независимо (три копии backend и одна база), а отказ одного не должен перезапускать другой.

У пода нет собственной устойчивости. Под, созданный напрямую, будет перезапускать свои упавшие контейнеры, пока жив его узел, но если узел пропал, под исчезнет вместе с ним и никто его не воссоздаст: под привязан к узлу на всю жизнь и на другой узел не переносится. Перенос — это всегда создание нового пода с новым именем и новым IP-адресом контроллером более высокого уровня. Отсюда правило: поды почти никогда не создают вручную, их создают контроллеры — Deployment, StatefulSet, DaemonSet, Job.

Запросы, лимиты и классы качества обслуживания

Каждый контейнер может указать для процессора и памяти два значения ⁹. Запрос (англ. request) — сколько ресурса контейнеру нужно гарантированно; его использует планировщик при выборе узла. Лимит (англ. limit) — сколько контейнеру разрешено потреблять максимум; его применяет ядро узла через cgroups, как в теме 5. Процессор измеряется в ядрах и миллиядрах (250m — четверть ядра), память — в байтах с двоичными суффиксами (128Mi). Если для ресурса указан только лимит, запрос по умолчанию принимается равным лимиту.

Механизмы применения запросов и лимитов разные, и это важно понимать. Лимит процессора превращается в квоту планировщика CFS: в cgroup v2 лимит 500m даёт cpu.max = 50000 100000, то есть не больше 50 мс процессорного времени в каждом окне 100 мс. Превышение не убивает контейнер, а приостанавливает его до следующего окна — происходит дросселирование (англ. throttling). Числовой пример: обработка запроса требует 200 мс работы одного потока. Без лимита на свободном ядре она займёт 200 мс. С лимитом 500m контейнер получает 50 мс в каждые 100 мс, и та же работа растягивается минимум на 400 мс — задержка выросла вдвое при том, что узел мог быть почти пуст. Лимит памяти превращается в memory.max; при попытке превысить его ядро не может «притормозить» выделение и вызывает OOM killer внутри cgroup контейнера: процесс получает SIGKILL, контейнер завершается с кодом 137, и kubelet записывает причину OOMKilled. Запрос процессора задаёт вес cpu.weight, то есть долю процессора при конкуренции, а запрос памяти ядром вообще не применяется — он нужен только планировщику и логике вытеснения.

По сочетанию запросов и лимитов каждый под получает класс качества обслуживания (англ. Quality of Service class, QoS) ⁹:

Класс определяет судьбу пода, когда на узле кончается память. Тогда возможны два разных механизма. Первый — вытеснение kubelet'ом (англ. node-pressure eviction): kubelet замечает, что свободной памяти меньше порога, и сам завершает поды, начиная с BestEffort и Burstable, превысивших запросы. Такой под получает статус Evicted, и контроллер создаёт замену на другом узле. Второй — OOM killer ядра, если память кончилась быстрее, чем отреагировал kubelet; он выбирает жертву по oom_score, к которому kubelet прибавляет oom_score_adj из таблицы. Для Burstable значение вычисляется как \min(\max(2,\ 1000 - 1000 \cdot r / M),\ 999), где r — запрос памяти, M — объём памяти узла. Контейнер с запросом 64 МиБ на узле с 4 ГиБ получает 1000 - 1000 \cdot 64/4096 \approx 984, то есть почти первым кандидатом на уничтожение; контейнер с запросом 2 ГиБ на том же узле — 500.

Практический вывод для backend «Заметок»: запросы следует задавать по реально измеренному потреблению в обычном режиме, лимит памяти — с запасом на пики, а лимит процессора — осторожно, потому что дросселирование незаметно ухудшает задержку. Многие эксплуатационные команды задают для сервисов запрос процессора без лимита и лимит памяти, равный или немного больший запроса.

Планировщик: фильтрация и скоринг

Планировщик kube-scheduler получает поды без назначенного узла и для каждого выбирает узел в два этапа ⁷. На этапе фильтрации (англ. filtering) отбрасываются узлы, на которых под запустить нельзя: не хватает свободных ресурсов по запросам, есть ограничение без допуска, не выполнено обязательное правило привязки, занят нужный порт узла, узел помечен как недоступный для размещения. Оставшиеся узлы называются допустимыми (англ. feasible). На этапе скоринга (англ. scoring) каждый допустимый узел получает оценку от 0 до 100 от каждого из включённых модулей оценки; итог — взвешенная сумма, и под назначается на узел с наибольшей суммой. Если допустимых узлов нет, под остаётся в Pending с событием FailedScheduling, а планировщик повторит попытку при изменении кластера.

Важнейшая особенность: планировщик считает ресурсы по запросам, а не по фактической загрузке. «Свободно» на узле — это его выделяемый объём (англ. allocatable, ёмкость за вычетом зарезервированного под систему) минус сумма запросов уже назначенных подов. Узел, на котором поды запросили 3,9 из 4 ядер, но реально потребляют 0,2, для планировщика почти полон. И наоборот, узел с подами BestEffort, которые ничего не запросили, но съели всю память, для планировщика пуст. Поэтому поды без запросов ломают планирование: они не учитываются при размещении, но конкурируют за ресурсы.

Разберём пример. Под запрашивает cpu: 500m, memory: 512Mi. В кластере четыре узла:

Модуль NodeResourcesFit по умолчанию использует стратегию LeastAllocated: для каждого ресурса оценка равна доле, которая останется свободной после размещения, умноженной на 100, и оценки ресурсов усредняются. Для узла B это (62{,}5 + 68{,}75)/2 \approx 65{,}6, для C — (12{,}5 + 18{,}75)/2 \approx 15{,}6. Другие модули добавляют свои оценки: NodeResourcesBalancedAllocation предпочитает узлы, где загрузка процессора и памяти окажется сбалансированной, ImageLocality — узлы, где образ уже загружен, PodTopologySpread — равномерное распределение копий одного приложения по узлам и зонам, InterPodAffinity и NodeAffinity — выполнение мягких правил привязки, TaintToleration — узлы с меньшим числом ограничений эффекта PreferNoSchedule ⁷. В примере B выигрывает с большим отрывом. Заметим, что узел D — самый свободный, но недоступен для пода из-за ограничения: «наименее загруженный» узел не обязательно выбранный.

Управлять размещением можно с двух сторон. Ограничения и допуски действуют от узла: ограничение ставится на узел командой kubectl taint nodes node-d gpu=true:NoSchedule и отталкивает все поды, у которых нет соответствующего допуска. Эффекты: NoSchedule — не размещать новые поды, PreferNoSchedule — по возможности не размещать, NoExecute — не размещать и выселять уже работающие ⁸. Так выделяют узлы под особые задачи (с GPU, для системных компонентов): допуск ставится только тем подам, которым на этих узлах место. Сам допуск не притягивает под к узлу, а лишь разрешает там оказаться. Притягивание задаётся от пода: nodeSelector (простое совпадение меток узла), привязка к узлам (англ. node affinity) с обязательными (requiredDuringSchedulingIgnoredDuringExecution) и предпочтительными (preferredDuringScheduling...) правилами, а также привязка и антипривязка к другим подам (англ. pod affinity, anti-affinity), например «не размещать две копии backend на одном узле». Для узлов с GPU обычно используют оба механизма: ограничение отталкивает чужие поды, а привязка направляет туда свои.

Пробы: запуск, готовность и живость

kubelet может проверять каждый контейнер тремя видами проб (англ. probes), и каждая отвечает на свой вопрос ¹⁰:

Проба выполняется как HTTP-запрос (httpGet, успех — код от 200 до 399), TCP-подключение (tcpSocket), вызов gRPC (grpc) или команда внутри контейнера (exec). Значения по умолчанию: periodSeconds: 10, timeoutSeconds: 1, failureThreshold: 3, successThreshold: 1, initialDelaySeconds: 0 ¹⁰. Время до реакции легко посчитать: при периоде 5 с и пороге 3 зависший процесс будет перезапущен через 10–15 с после зависания. Для медленно стартующего приложения startupProbe с periodSeconds: 10 и failureThreshold: 30 даёт до 300 с на запуск, не ослабляя livenessProbe после него: без неё пришлось бы ставить большую initialDelaySeconds и ждать её при каждом перезапуске.

Главная ошибка в пробах — проверка живости, зависящая от внешних компонентов. Backend «Заметок» имеет эндпоинт GET /api/health, который выполняет запрос к PostgreSQL. Если указать его в livenessProbe, произойдёт следующее. База данных становится недоступна на минуту, например при перезапуске. Через 30 с (3 × 10 с) проба живости проваливается у всех копий backend одновременно, и kubelet перезапускает их все. Перезапуск не помогает — база по-прежнему недоступна, — и после нескольких циклов контейнеры попадают в CrashLoopBackOff с экспоненциально растущей задержкой перед следующим перезапуском: 10, 20, 40 секунд и так далее до 5 минут ¹⁰. База вернулась, но backend ещё несколько минут не отвечает, потому что ждёт окончания задержки. Кратковременный сбой одной зависимости превратился в длительный отказ всего сервиса, а массовый одновременный перезапуск с повторными подключениями мог дополнительно нагрузить и без того восстанавливающуюся базу.

Правильное разделение: livenessProbe проверяет только сам процесс — отвечает ли он вообще (обычно тривиальный эндпоинт вроде /healthz или /api/live у backend «Заметок», который возвращает 200 без обращений к зависимостям). Перезапуск лечит только то, что находится внутри контейнера: зависание, исчерпание потоков, утечку, после которой процесс перестал отвечать. Недоступность базы данных перезапуском backend не лечится, поэтому не должна вызывать перезапуска. readinessProbe может учитывать готовность самого экземпляра: прогрет ли кэш, установлено ли соединение с базой при старте. Но и здесь нужна осторожность: если готовность всех копий зависит от одной общей базы, её отказ уберёт из Service все копии разом, и клиенты вместо осмысленной ошибки «база недоступна, попробуйте позже» получат отказ в соединении. Часто лучше, чтобы приложение оставалось готовым и само отвечало кодом 503 на запросы, которым нужна база. Этот сценарий воспроизводится в лабораторной работе.

Контроллеры рабочих нагрузок

ReplicaSet и Deployment

ReplicaSet поддерживает заданное число подов по шаблону. Deployment управляет ReplicaSet'ами и добавляет то, чего у ReplicaSet нет: версии шаблона и стратегию перехода между ними ¹¹. Для каждой версии шаблона пода Deployment создаёт отдельный ReplicaSet, имя которого содержит хеш шаблона, — тот же хеш записывается в метку pod-template-hash его подов, чтобы селекторы разных ReplicaSet не пересекались. Обновление Deployment сводится к изменению числа реплик двух ReplicaSet: нового — вверх, старого — вниз. Старые ReplicaSet с нулём реплик сохраняются (по умолчанию 10, поле revisionHistoryLimit), и откат kubectl rollout undo — это просто масштабирование старого ReplicaSet обратно.

Минимальный разумный манифест backend «Заметок» выглядит так (образ notes-backend:1.0 собирается в курсовом проекте):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: notes
spec:
  replicas: 3
  selector:
    matchLabels:
      app: notes
      component: backend
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: notes
        component: backend
    spec:
      containers:
        - name: backend
          image: notes-backend:1.0
          ports:
            - name: http
              containerPort: 3000
          resources:
            requests:
              cpu: 200m
              memory: 192Mi
            limits:
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /api/health
              port: http
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /api/live
              port: http
            periodSeconds: 10
            failureThreshold: 3

Разберём поля, которые определяют поведение. spec.selector должен совпадать с метками шаблона, и после создания его нельзя изменить. replicas: 3 — желаемое число копий; если Deployment управляется HPA, это поле лучше не указывать в манифесте, чтобы повторный kubectl apply не сбрасывал решение автомасштабирования. В resources задан запрос процессора без лимита и лимит памяти с запасом над запросом — класс Burstable. readinessProbe использует /api/health, проверяющий базу: копия, которая не может достучаться до базы, не получает трафик. livenessProbe использует /api/live, который отвечает 200 без обращения к базе, то есть проверяет только «процесс жив и обслуживает HTTP». Изменение любого поля внутри template — образа, переменной окружения, пробы — создаёт новую версию шаблона и запускает обновление; изменение replicas обновления не вызывает.

Альтернатива стратегии RollingUpdate — Recreate: сначала удалить все старые поды, потом создать новые. Она даёт простой, но нужна, когда две версии не могут работать одновременно, например если новая версия меняет схему базы данных несовместимо со старой.

Постепенное обновление по шагам

Стратегия RollingUpdate задаётся двумя параметрами ¹¹. maxSurge — сколько подов сверх replicas можно создать во время обновления. maxUnavailable — на сколько число доступных подов может опуститься ниже replicas. Оба задаются числом или процентом от replicas; при пересчёте процента maxSurge округляется вверх, а maxUnavailable — вниз. Значения по умолчанию — 25 % и 25 %. Оба параметра не могут одновременно быть нулём, иначе обновление не сможет сделать ни шага.

Для 10 реплик со значениями по умолчанию: \lceil 10 \cdot 0{,}25 \rceil = \lceil 2{,}5 \rceil = 3 и \lfloor 2{,}5 \rfloor = 2. Значит, во время обновления подов будет не больше 10 + 3 = 13, а доступных — не меньше 10 - 2 = 8. Контроллер Deployment на каждой итерации проверяет оба ограничения: он увеличивает новый ReplicaSet, пока общее число подов не достигнет 13, и уменьшает старый, пока число доступных не опустится до 8. Дальше он ждёт, пока новые поды станут готовыми, и повторяет.

Рисунок ниже показывает обновление при replicas: 4, maxSurge: 1, maxUnavailable: 0. Это самый осторожный режим: доступных подов всегда не меньше четырёх, лишних ресурсов нужно ровно на один под, а обновление идёт по одному поду за шаг.

На шаге 1 создаётся один под новой версии; общее число становится 5, это предел. Пока новый под не прошёл readinessProbe, удалять старые нельзя: доступных стало бы 3. Когда он готов (шаг 2), контроллер уменьшает старый ReplicaSet до 3, и освободившееся место позволяет создать следующий новый под. Весь цикл повторяется четыре раза. Отсюда видно, почему readinessProbe — обязательное условие обновления без простоя: без неё под считается готовым, как только запущен процесс, и старые поды удаляются до того, как новые реально могут обслуживать запросы.

Тот же механизм защищает от плохой версии. Если образ новой версии не загружается (ImagePullBackOff) или новые поды не проходят пробу готовности, на шаге 1 обновление останавливается: новый под не становится готовым, старые не удаляются, сервис продолжает работать на старой версии. Через progressDeadlineSeconds (по умолчанию 600 с) Deployment получает условие Progressing=False с причиной ProgressDeadlineExceeded, и kubectl rollout status завершается с ошибкой. Автоматического отката Kubernetes не делает — это решение остаётся за человеком или системой доставки:

kubectl -n lab07 rollout status deployment/echo --timeout=60s
kubectl -n lab07 rollout history deployment/echo
kubectl -n lab07 rollout undo deployment/echo

Waiting for deployment "echo" rollout to finish: 1 out of 4 new replicas have been updated...
error: timed out waiting for the condition
deployment.apps/echo
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
deployment.apps/echo rolled back

При maxUnavailable больше нуля плохая версия успеет заменить часть подов, прежде чем обновление остановится, поэтому выбор параметров — это компромисс между скоростью обновления, запасом ресурсов кластера и риском.

Корректное завершение пода

Отсутствие ошибок во время обновления зависит не только от проб, но и от того, как завершаются старые поды. Когда под удаляется, параллельно происходят две независимые цепочки событий ¹¹¹²:

• kubelet узла получает отметку удаления, выполняет хук preStop, если он задан, и посылает основному процессу контейнера SIGTERM. Через terminationGracePeriodSeconds (по умолчанию 30 с) оставшиеся процессы получают SIGKILL;
• контроллер EndpointSlice помечает адрес пода как завершающийся и неготовый, kube-proxy на каждом узле получает это изменение через watch и перестраивает правила, Ingress-контроллер обновляет свой список адресов.

Вторая цепочка не мгновенна: она проходит через сервер API и через каждый узел кластера и занимает от долей секунды до нескольких секунд. Если приложение по SIGTERM сразу закрывает порт, часть новых соединений, отправленных по ещё не обновлённым правилам, получит отказ. Это и есть причина редких ошибок «connection refused» во время обновлений, которые не устраняются никакими пробами. Решение — продолжать обслуживание ещё несколько секунд после SIGTERM: приложение перестаёт отвечать «готов» на readinessProbe, доделывает текущие запросы, принимает новые, пока правила не обновятся, и только потом завершается. Если приложение этого не умеет, тот же эффект даёт хук preStop с паузой (команда sleep 5 в контейнере или встроенное действие sleep, которое kubelet выполняет сам, без утилиты sleep в образе). Сюда же относится урок темы 5: SIGTERM должен дойти до приложения, то есть процесс приложения должен быть PID 1 или получать сигнал от корректного init-процесса, иначе каждый под будет ждать все 30 секунд до SIGKILL.

Учебный сервис лабораторной работы реализует именно такое поведение: после SIGTERM он SHUTDOWN_DELAY секунд отвечает 503 на /readyz, но продолжает обслуживать запросы, и в работе можно сравнить число ошибок при задержке 5 с и при нулевой.

DaemonSet, Job и CronJob

Deployment подходит для сервисов без состояния, где копии взаимозаменяемы и их число задаётся. Другие формы нагрузки обслуживают другие контроллеры:

DaemonSet не использует replicas: число подов равно числу подходящих узлов, и при добавлении узла под на нём появляется автоматически. Поды DaemonSet получают допуски к unreachable и not-ready без ограничения времени, поэтому никогда не выселяются с недоступного узла — им некуда переезжать, их место именно на этом узле ⁸. Job отличается от Deployment смыслом успеха: завершение контейнера с кодом 0 — это не сбой, который нужно лечить перезапуском, а выполненная работа. У пода Job restartPolicy равна OnFailure или Never, а поле backoffLimit (по умолчанию 6) ограничивает число повторов при неудаче. CronJob добавляет расписание и политику одновременного выполнения concurrencyPolicy: разрешить, запретить или заменить предыдущий незавершённый запуск. Для «Заметок» естественное применение Job — миграция схемы перед обновлением backend, CronJob — ежесуточный дамп базы в объектное хранилище (тема 10).

Сеть сервисов и автомасштабирование

Service, EndpointSlice и kube-proxy

Сетевая модель Kubernetes требует, чтобы каждый под имел собственный IP-адрес и мог обратиться к любому другому поду кластера по этому адресу без трансляции адресов. Реализует модель сетевой модуль (англ. Container Network Interface, CNI), например kindnet в minikube, Calico или Cilium. Но адреса подов непригодны как точка обращения: при каждом пересоздании под получает новый адрес, а копий много. Эту задачу решает Service — объект, дающий группе подов устойчивое имя и устойчивый виртуальный адрес. Устройство показано на рисунке ниже.

Service с селектором app: echo получает адрес из выделенного диапазона, ClusterIP. Этот адрес не принадлежит ни одному интерфейсу и ни одному процессу: на него нельзя ответить ping, его нет в выводе ip addr ни на одном узле. Он существует только как ключ в правилах netfilter. Контроллер EndpointSlice следит за подами и сервисами и для каждого Service поддерживает объекты EndpointSlice со списком адресов подходящих подов и их состоянием: ready, serving, terminating ¹². Под, не прошедший readinessProbe, остаётся в слайсе, но с ready: false, и трафик на него не направляется. В одном слайсе по умолчанию не больше 100 адресов; у большого сервиса их несколько, и изменение одного пода меняет только один слайс, а не огромный список целиком, как было в старом API Endpoints, объявленном устаревшим в Kubernetes 1.33.

kube-proxy на каждом узле подписан на Service и EndpointSlice и программирует ядро узла. В режиме iptables, используемом по умолчанию, это цепочки правил в таблице nat: пакет к 10.96.120.15:80 попадает в цепочку сервиса, где правило со случайным выбором отправляет его в цепочку одного из подов, и там выполняется DNAT на 10.244.1.3:8080 ¹². Режим nftables (доступен в Linux с ядром 5.13 и новее) делает то же через более эффективный интерфейс ядра и в будущих версиях станет режимом по умолчанию; режим ipvs объявлен устаревшим в Kubernetes 1.35. Некоторые сетевые модули, например Cilium, заменяют kube-proxy полностью программами eBPF. Во всех режимах важно одно: балансировка выполняется в ядре узла-отправителя, при установлении соединения. Отдельного процесса-балансировщика, через который шёл бы трафик, нет; kube-proxy лишь пишет правила. Следствие, которое часто удивляет: долгоживущие соединения, например пул подключений к базе или HTTP/2 с keep-alive, «прилипают» к поду, выбранному при подключении, и не перераспределяются при добавлении новых копий.

Пустой слайс — характерный признак ошибки в селекторе:

kubectl -n lab07 get endpointslices -l kubernetes.io/service-name=web
kubectl -n lab07 describe service web

NAME        ADDRESSTYPE   PORTS     ENDPOINTS   AGE
web-xk2pq   IPv4          <unset>   <unset>     2m
...
Selector:          app=echo,tier=frontend
Endpoints:

Для Service без готовых адресов kube-proxy ставит правило, отвергающее соединение, поэтому клиент получает не тайм-аут, а немедленный отказ — «Connection refused».

Типы Service и DNS

Тип Service определяет, откуда он доступен:

Каждый следующий из первых трёх типов включает предыдущий. В minikube нет облачного балансировщика, поэтому Service типа LoadBalancer остаётся с внешним адресом <pending>, пока не запущен minikube tunnel.

Имена сервисов разрешает CoreDNS. Service echo в пространстве имён lab07 получает имя echo.lab07.svc.cluster.local, где cluster.local — домен кластера. kubelet записывает в /etc/resolv.conf каждого пода адрес CoreDNS и список доменов поиска:

search lab07.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

Поэтому под из lab07 может обращаться к сервису просто как echo, а к сервису другого пространства имён — как db.notes. Параметр ndots:5 означает: если в имени меньше пяти точек, сначала перебираются домены поиска и только потом имя пробуется как есть. У этого есть цена. Запрос к внешнему api.example.com (две точки) порождает сначала запросы api.example.com.lab07.svc.cluster.local, api.example.com.svc.cluster.local, api.example.com.cluster.local — все с ответом «нет такого имени», — и только четвёртым идёт правильный; если клиент запрашивает и A, и AAAA, запросов вдвое больше. Для приложений, активно обращающихся к внешним именам, это заметная нагрузка на CoreDNS и добавка к задержке; помогает запись полного имени с точкой на конце (api.example.com.).

Ingress и Gateway API

Service решает задачу балансировки на транспортном уровне: он не видит HTTP, не различает имена хостов и пути. Публиковать каждый HTTP-сервис отдельным LoadBalancer дорого — это отдельный внешний адрес и отдельный облачный балансировщик на каждый сервис. Ingress — объект, описывающий правила маршрутизации HTTP и HTTPS снаружи кластера к сервисам внутри: по имени хоста и префиксу пути, с завершением TLS ¹³. Например, для «Заметок» можно направить запросы notes.example.com/api/... прямо в Service backend, а остальные — в Service frontend (в курсовом проекте выбран более простой вариант: весь трафик идёт во frontend, а тот сам проксирует /api в backend).

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: notes
  namespace: notes
spec:
  ingressClassName: nginx
  rules:
    - host: notes.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend
                port:
                  number: 3000
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80

pathType: Prefix сравнивает путь по элементам, разделённым /: правило /api подходит к /api и /api/notes, но не к /apinotes. Exact требует точного совпадения, ImplementationSpecific оставляет решение контроллеру ¹³. При нескольких подходящих путях выбирается самый длинный префикс, поэтому порядок правил в манифесте неважен.

Сам объект Ingress ничего не делает. Его исполняет Ingress-контроллер — обычное приложение в кластере, чаще всего обратный прокси (nginx, HAProxy, Envoy, Traefik), которое подписано на объекты Ingress, Service и EndpointSlice и перестраивает свою конфигурацию. Поле ingressClassName указывает, какой из установленных контроллеров отвечает за данный Ingress. Без контроллера Ingress создаётся без ошибок и просто не работает — это ещё один пример «допустимого, но бездействующего» объекта. Сам контроллер публикуется наружу Service'ом типа LoadBalancer или NodePort, так что внешний балансировщик нужен один на все HTTP-сервисы. Большинство контроллеров, в том числе ingress-nginx, отправляют запросы прямо на адреса подов из EndpointSlice, минуя ClusterIP и kube-proxy: так они сами выбирают под и могут держать с ним постоянные соединения.

У API Ingress есть известные ограничения: в нём нет стандартных средств для разделения трафика по весам, перезаписи заголовков, маршрутизации не-HTTP протоколов, и всё это каждый контроллер добавляет своими аннотациями, несовместимыми между реализациями. Поэтому проект Kubernetes заморозил API Ingress: он остаётся стабильным и поддерживаемым, но не развивается, а рекомендуемой заменой назван Gateway API ¹³. Gateway API разделяет роли тремя типами объектов: GatewayClass описывает реализацию (аналог ingressClassName), Gateway — конкретную точку входа с адресами, портами и сертификатами, которой управляет администратор кластера, а HTTPRoute (а также GRPCRoute и другие) — маршруты приложения, которые пишут разработчики в своих пространствах имён. Веса, заголовки, зеркалирование трафика выражаются стандартными полями. Здесь важно не смешивать две разные вещи — API и его реализацию. Ресурс Ingress — часть API Kubernetes; он заморожен, но остаётся стабильным и поддерживается всеми версиями кластера. Ingress-контроллер — отдельный проект со своей судьбой. Самый распространённый из них, ingress-nginx, снят с поддержки: в ноябре 2025 года проект Kubernetes объявил о прекращении его развития, последние обновления вышли в марте 2026 года, и репозиторий переведён в архив. Новых версий и исправлений уязвимостей больше не будет, хотя существующие установки продолжают работать, а образы остаются доступными. Те же объекты Ingress продолжают обслуживать другие контроллеры — Traefik, HAProxy, Contour, Cilium и многие другие, — поэтому манифесты Ingress при смене контроллера обычно меняются лишь в поле ingressClassName и в аннотациях, специфичных для контроллера. Дополнение ingress в minikube, используемое в лабораторной работе и на первых этапах курсового проекта, по-прежнему разворачивает ingress-nginx: для изучения API Ingress это не имеет значения, а на этапе 6 курсового проекта контроллер заменяется на Traefik. Для новых промышленных установок направление развития — Gateway API и одна из его реализаций.

Горизонтальное автомасштабирование

HorizontalPodAutoscaler (HPA) — контроллер, который меняет replicas у Deployment (или другого объекта с подресурсом scale) так, чтобы метрика на под держалась около целевого значения ¹⁴. Чаще всего метрика — загрузка процессора в процентах от запроса. Данные о потреблении ресурсов HPA получает через Metrics API, который реализует отдельный компонент metrics-server: он периодически опрашивает kubelet каждого узла (интервал задаёт флаг --metric-resolution: 15 с в стандартном манифесте проекта, 60 с в дополнении minikube), хранит последние значения в памяти и отдаёт их через сервер API. Без metrics-server HPA показывает цель как <unknown> и ничего не делает; этот же компонент нужен команде kubectl top.

Каждые 15 секунд контроллер HPA вычисляет

\text{desired} = \left\lceil \text{current} \cdot \frac{\text{currentMetric}}{\text{targetMetric}} \right\rceil,

где current — текущее число реплик, currentMetric — среднее значение метрики по подам, targetMetric — целевое ¹⁴. Пример: у backend три копии с запросом cpu: 200m и целью 50 %, то есть 100m на под. Под нагрузкой средняя загрузка — 180m, или 90 % от запроса. Тогда \lceil 3 \cdot 90/50 \rceil = \lceil 5{,}4 \rceil = 6: HPA увеличивает число копий до шести. Если нагрузка не изменилась, суммарное потребление 540m распределится на шесть подов по 90m, или 45 %, и следующий расчёт даст \lceil 6 \cdot 45/50 \rceil = \lceil 5{,}4 \rceil = 6 — система пришла в равновесие.

Формула дополнена правилами, без которых она раскачивала бы систему ¹⁴:

• допуск (англ. tolerance) 0,1: если отношение текущего значения к целевому лежит между 0,9 и 1,1, масштабирование не выполняется. Четыре копии при загрузке 54 % дают отношение 1,08 и ничего не меняют, хотя формула дала бы \lceil 4{,}32 \rceil = 5;
• окно стабилизации при уменьшении — по умолчанию 300 секунд: HPA выбирает наибольшую из рекомендаций за последние 5 минут, поэтому после спада нагрузки копии убираются не сразу, а через 5 минут. Увеличение по умолчанию выполняется без окна, но не больше чем на 100 % или на 4 пода (что больше) за 15 секунд. Оба поведения настраиваются в spec.behavior;
• только что запущенные поды учитываются осторожно: в первые 5 минут после старта (--horizontal-pod-autoscaler-cpu-initialization-period) загрузка процессора пода игнорируется, если он не готов или замер сделан не целиком в период готовности. Иначе всплеск процессора при прогреве нового пода вызывал бы новое масштабирование.

HPA работает только с подами, у которых задан запрос процессора: процент считается от запроса, и без него нечего делить. HPA меняет число подов, но не узлов: если новые копии не помещаются на узлы, они останутся в Pending, и добавить узлы может только отдельный компонент — Cluster Autoscaler или аналог в облаке. Наконец, HPA реагирует с запаздыванием: до одного интервала metrics-server на обновление метрик, до 15 секунд на цикл HPA, затем время на размещение, загрузку образа и прохождение readinessProbe. От резкого всплеска трафика он не спасает; запас ёмкости (minReplicas) нужен всё равно.

Диагностика, ограничения и типичные ошибки интерпретации

Состояния пода и где искать причину

Большинство проблем с подами проявляется одним из нескольких состояний в столбце STATUS команды kubectl get pods. Это не фаза пода в строгом смысле (фаз всего пять: Pending, Running, Succeeded, Failed, Unknown), а краткая сводка, которую kubectl собирает из фазы и причин ожидания или завершения контейнеров. Порядок диагностики почти всегда один: kubectl get pods -o wide → kubectl describe pod (раздел Events внизу и Last State контейнера) → kubectl logs, для упавшего контейнера — kubectl logs --previous.

Пример вывода для пода, которому не хватило процессора (запрос 3 ядра в кластере из двух узлов по 2 ядра):

kubectl -n lab07 describe pod too-big

...
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  12s   default-scheduler  0/2 nodes are available: 2 Insufficient cpu. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod.

Сообщение планировщика построено как сводка фильтрации: сколько узлов отброшено и по какой причине. Слово «preemption» относится к вытеснению подов с меньшим приоритетом, которое планировщик пробует, если под нельзя разместить; здесь вытеснять некого. А так выглядит контейнер, убитый за превышение памяти:

    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
    Restart Count:  3

Код 137 — это 128 + 9, то есть завершение сигналом SIGKILL (тема 5). Сам по себе код 137 не доказывает OOM: тот же код получает контейнер, не успевший завершиться за terminationGracePeriodSeconds. Различает их поле Reason.

Ограничения модели

Декларативная модель с циклами согласования даёт устойчивость, но у неё есть границы, которые нужно знать.

Согласование конечно во времени, но не мгновенно. Между записью объекта и реальным изменением проходят секунды, а при отказах — минуты: 50 секунд на обнаружение недоступного узла, 300 секунд допуска, 15 секунд цикла HPA, задержки CrashLoopBackOff до 5 минут. Любой ответ API «принято» означает только то, что желаемое состояние записано. Скрипты, которые после kubectl apply сразу ждут работающий сервис, должны явно ждать нужного условия (kubectl rollout status, kubectl wait --for=condition=Available).

Kubernetes не делает приложение надёжным само по себе. Он перезапускает процессы и заменяет поды, но не может сделать безопасной повторную обработку запроса, не переносит состояние из памяти упавшего пода и не знает, корректно ли приложение обрабатывает SIGTERM. Две копии backend на одном узле не защищают от отказа узла: для этого нужно правило распределения по узлам, а для отказа зоны доступности — по зонам. Отказоустойчивость складывается из свойств приложения и правильных настроек, а не из самого факта развёртывания в Kubernetes.

Модель ресурсов основана на заявлениях, а не на измерениях. Планировщик верит запросам: завышенные запросы ведут к простаивающим узлам и подам в Pending при почти пустом кластере, заниженные — к перегруженным узлам, дросселированию и вытеснению. Лимит процессора защищает соседей, но добавляет задержку своему приложению. Подбор запросов по фактическому потреблению — постоянная эксплуатационная задача, для которой нужны метрики (тема 12).

Плоскость управления — общая зависимость. etcd с потерянным кворумом или перегруженный сервер API останавливают все контроллеры одновременно. Работающие поды переживают это, но кластер теряет способность реагировать на любые другие отказы. Масштаб тоже ограничен: проект Kubernetes заявляет поддержку кластеров до 5000 узлов и 150 000 подов, а на практике пределы часто наступают раньше — из-за числа объектов и частоты их изменений.

Наконец, сетевые механизмы Service работают на транспортном уровне. Балансировка выполняется при установлении соединения, долгие соединения не перераспределяются, ClusterIP недоступен снаружи кластера и не отвечает на ICMP, а Ingress зависит от установленного контроллера, функциональность которого за пределами базового API не переносится между реализациями.

Типичные ошибки интерпретации

1. «Планировщик выбирает наименее загруженный узел». Планировщик сначала отбрасывает узлы, не прошедшие фильтры, а затем складывает оценки многих модулей; оценка ресурсов считается по запросам, а не по фактической загрузке. Самый свободный узел может быть отброшен ограничением, а самый загруженный по факту — выглядеть пустым, если его поды ничего не запросили.
2. «Под переезжает на другой узел». Поды не переезжают. При отказе узла или вытеснении контроллер создаёт новый под с новым именем, новым адресом и пустой файловой системой контейнеров; старый под удаляется. Всё, что было в памяти и в слое записи контейнера, теряется (тема 3).
3. «Liveness и readiness — одно и то же, можно указать один эндпоинт». Провал readinessProbe только убирает под из балансировки, провал livenessProbe его перезапускает. Проверка зависимостей в livenessProbe превращает отказ базы данных в каскадный перезапуск всех копий сервиса и CrashLoopBackOff.
4. «Сервис недоступен — значит, сломан Service». Чаще всего Service в порядке, а пуст его EndpointSlice: опечатка в селекторе, поды не проходят readinessProbe или targetPort не совпадает с портом контейнера. Первое, что нужно смотреть, — kubectl get endpointslices -l kubernetes.io/service-name=имя.
5. «Узел пропал — поды сразу поднимутся на другом». С настройками по умолчанию замена начинается примерно через 5 минут 50 секунд: 50 секунд на признание узла недоступным и 300 секунд допуска. Всё это время ёмкость сервиса снижена.
6. «Потеря Control Plane останавливает приложения». Работающие контейнеры, пробы и локальные перезапуски, правила kube-proxy продолжают работать. Останавливается только управление: никакие изменения и восстановление после новых отказов не выполняются.
7. «Четыре члена etcd надёжнее трёх». Оба варианта переживают отказ одного члена, но у четырёх кворум больше, и при разделении сети пополам ни одна часть не может продолжать работу.
8. «kubectl apply завершился успешно — приложение работает». Успех apply означает, что объект прошёл проверки и записан в etcd. Запуск подов, загрузка образов и пробы происходят позже и могут не удаться; это проверяется по rollout status, событиям и состоянию подов.
9. «HPA защитит от всплеска трафика». HPA реагирует за десятки секунд и не добавляет узлы. Он хорошо справляется с плавными суточными колебаниями, но резкий всплеск должен поглощаться запасом minReplicas.

Итоги темы

Kubernetes превращает набор серверов в единую систему управления контейнерами, построенную на одной идее: пользователь записывает желаемое состояние, а контроллеры в бесконечном цикле приводят к нему фактическое. Контроллеры реагируют на уровень, а не на отдельные события, — они подписываются на изменения через watch, но вычисляют действие по полному текущему состоянию. Поэтому система устойчива к потерянным событиям, перезапускам собственных компонентов и любым причинам расхождения, а сложное поведение складывается из простых контроллеров, каждый из которых отвечает за свой уровень: Deployment управляет ReplicaSet'ами, ReplicaSet — подами, планировщик — назначением узлов, kubelet — контейнерами.

Архитектурно кластер — это хранилище etcd, единственный с ним работающий сервер API и множество клиентов этого API, которые не общаются друг с другом напрямую. etcd согласует записи по Raft и работает, пока доступен кворум \lfloor n/2 \rfloor + 1 членов, поэтому его делают из трёх или пяти машин. Потеря плоскости управления останавливает управление, но не приложения: запущенные контейнеры, пробы и сетевые правила продолжают работать. Отказ узла обнаруживается примерно за 50 секунд, а замена его подов по умолчанию начинается ещё через 300 секунд допуска к ограничению unreachable.

Под — единица размещения с общим сетевым пространством; его ресурсы задаются запросами, по которым планирует планировщик, и лимитами, которые ядро применяет через cgroups, а их сочетание определяет класс QoS и порядок вытеснения. Планировщик фильтрует узлы по запросам, ограничениям и правилам привязки и выбирает лучший по сумме оценок. Три вида проб отвечают на разные вопросы, и главное правило их использования — проба живости не должна зависеть от внешних компонентов. Deployment обновляет приложение, переключая реплики между двумя ReplicaSet в пределах maxSurge и maxUnavailable, и отсутствие простоя обеспечивается сочетанием проб готовности и корректного завершения подов с учётом задержки распространения изменений EndpointSlice.

Сетевая часть строится на Service — устойчивом имени и виртуальном адресе, за которыми стоят EndpointSlice с адресами готовых подов и правила netfilter, записанные kube-proxy на каждом узле. Ingress и пришедший ему на смену Gateway API добавляют маршрутизацию HTTP по именам и путям, а HPA с metrics-server меняет число копий по формуле пропорционального масштабирования с допуском и окном стабилизации. Все эти механизмы объединяет общий способ диагностики: сравнить желаемое с фактическим и по событиям найти звено цепочки, на котором согласование остановилось.

Одна существенная часть приложения пока осталась за рамками темы: конфигурация и данные. Backend «Заметок» нужны параметры подключения и пароль к базе, а PostgreSQL — том, переживающий пересоздание пода. Объектам ConfigMap и Secret, постоянным томам и StatefulSet посвящена тема 8.

Литература

1. Burns B., Grant B., Oppenheimer D., Brewer E., Wilkes J. Borg, Omega, and Kubernetes. — Communications of the ACM, 2016, vol. 59, no. 5, P. 50–57. DOI: 10.1145/2890784.
2. Ongaro D., Ousterhout J. In Search of an Understandable Consensus Algorithm. — Proceedings of the 2014 USENIX Annual Technical Conference (USENIX ATC '14), 2014, P. 305–319.
3. Burns B., Beda J., Hightower K., Evenson L. Kubernetes: Up and Running. 3rd ed. — O'Reilly Media, 2022.
4. Kubernetes Documentation. Cluster Architecture. — https://kubernetes.io/docs/concepts/architecture/ (дата обращения: 22.10.2026).
5. Kubernetes Documentation. Kubernetes API Concepts. — https://kubernetes.io/docs/reference/using-api/api-concepts/ (дата обращения: 22.10.2026).
6. etcd Documentation v3.6. Frequently Asked Questions (FAQ). — https://etcd.io/docs/v3.6/faq/ (дата обращения: 22.10.2026).
7. Kubernetes Documentation. Kubernetes Scheduler. — https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/ (дата обращения: 22.10.2026).
8. Kubernetes Documentation. Taints and Tolerations. — https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ (дата обращения: 22.10.2026).
9. Kubernetes Documentation. Resource Management for Pods and Containers. — https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ (дата обращения: 22.10.2026).
10. Kubernetes Documentation. Configure Liveness, Readiness and Startup Probes. — https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ (дата обращения: 22.10.2026).
11. Kubernetes Documentation. Deployments. — https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ (дата обращения: 22.10.2026).
12. Kubernetes Documentation. Virtual IPs and Service Proxies. — https://kubernetes.io/docs/reference/networking/virtual-ips/ (дата обращения: 22.10.2026).
13. Kubernetes Documentation. Ingress. — https://kubernetes.io/docs/concepts/services-networking/ingress/ (дата обращения: 22.10.2026).
14. Kubernetes Documentation. Horizontal Pod Autoscaling. — https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/ (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Чем декларативное управление отличается от императивного? Почему повторный запуск императивного скрипта после сбоя на середине не обязательно приводит систему в порядок, а повторный цикл согласования — приводит?
2. Из каких шагов состоит цикл согласования контроллера? Почему у объектов Kubernetes есть отдельные поля spec и status и кто пишет каждое из них?
3. Как работает операция watch и зачем нужен resourceVersion? Что должен сделать клиент, получив 410 Gone? Почему контроллеры реагируют «на уровень», а не «на фронт»?
4. Кластер etcd состоит из трёх членов, два из них потеряны. Что происходит с записью и чтением объектов, с работающими подами и с подами отказавшего за это время узла? Почему кластер из четырёх членов не надёжнее кластера из трёх? Запишите формулы кворума и числа переживаемых отказов.
5. Что продолжает работать на рабочих узлах, если сервер API недоступен, а что перестаёт? Перезапустит ли kubelet упавший контейнер в это время?
6. Перечислите по шагам путь kubectl apply для нового Deployment из трёх подов: какие компоненты, в каком порядке и через какой механизм узнают о нём? На каком шаге kubectl получает ответ?
7. Под запрашивает cpu: 1, memory: 1Gi. Узел A: выделяемый объём 4 ядра и 8 ГиБ, запрошено 3,5 ядра и 2 ГиБ. Узел B: 4 ядра и 8 ГиБ, запрошено 1 ядро и 6 ГиБ. Узел C: 8 ядер и 16 ГиБ, без запросов, с ограничением dedicated=db:NoSchedule. Какие узлы пройдут фильтрацию? Какой получит большую оценку LeastAllocated и почему? Каким будет итог, если у пода есть допуск к ограничению узла C? Почему сам допуск не притягивает под к узлу C и что для этого нужно добавить?
8. Определите класс QoS для трёх подов: а) запросы и лимиты CPU и памяти равны; б) задан только лимит памяти; в) ресурсы не указаны. Какой из них первым будет вытеснен при нехватке памяти узла? Почему лимит процессора увеличивает задержку, даже если узел почти не загружен?
9. Backend «Заметок» использует /api/health, проверяющий PostgreSQL, в livenessProbe. Опишите по шагам, что произойдёт при минутной недоступности базы. Как правильно распределить проверки между startupProbe, readinessProbe и livenessProbe?
10. Для Deployment с replicas: 8, maxSurge: 25 %, maxUnavailable: 25 % найдите предельные числа подов во время обновления. Что произойдёт, если новая версия не проходит readinessProbe, при maxUnavailable: 0 и при maxUnavailable: 2?
11. Почему во время обновления могут возникать ошибки «connection refused», даже если пробы настроены правильно? Какие два способа их устраняют?
12. Как запрос curl http://echo/ из пода доходит до конкретного пода сервиса? Какую роль играют CoreDNS, EndpointSlice, kube-proxy и netfilter? Почему на ClusterIP нельзя ответить ping?
13. Чем Ingress отличается от Service типа LoadBalancer? Что произойдёт с объектом Ingress, если в кластере нет Ingress-контроллера? Почему API Ingress заморожен и что пришло ему на смену?
14. Узел выключили в 10:00:00. Когда при настройках по умолчанию он станет NotReady, когда его поды получат отметку удаления и почему они останутся в Terminating? Что изменится при tolerationSeconds: 20?
15. HPA управляет Deployment из четырёх реплик с целью 50 % загрузки процессора, средняя загрузка — 80 %. Сколько реплик станет после цикла? Почему при загрузке 53 % ничего не изменилось бы, а после снятия нагрузки реплики убираются не сразу? Что нужно, чтобы HPA вообще мог работать?

Глоссарий темы

Шпаргалка по инструментам

Состояние кластера и объектов:

kubectl get nodes -o wide                         # узлы, адреса, версии, среда выполнения
kubectl get pods -A -o wide                       # все поды всех пространств имён с узлами и IP
kubectl get deploy,rs,pods -l app=echo            # иерархия объектов приложения
kubectl get pods --show-labels                    # метки подов
kubectl get events --sort-by=.lastTimestamp       # события по времени
kubectl describe pod ИМЯ                          # состояние, Last State, события
kubectl describe node ИМЯ                         # условия, ограничения, Allocated resources
kubectl get pod ИМЯ -o yaml                       # объект целиком: spec, status, ownerReferences
kubectl explain deployment.spec.strategy          # описание поля прямо из схемы API
kubectl api-resources                             # все типы объектов кластера
kubectl config set-context --current --namespace=lab07   # пространство имён по умолчанию

Развёртывание и обновление:

kubectl apply -f каталог_или_файл                 # создать или изменить объекты
kubectl apply -f файл --server-side               # слияние на стороне сервера API
kubectl diff -f файл                              # что изменит apply
kubectl set image deployment/echo echo=lab07/echo:2.0
kubectl rollout status deployment/echo --timeout=120s
kubectl rollout history deployment/echo
kubectl rollout undo deployment/echo              # к предыдущей ревизии
kubectl rollout restart deployment/echo           # пересоздать поды без изменения образа
kubectl scale deployment/echo --replicas=5
kubectl wait --for=condition=Available deployment/echo --timeout=120s

Сеть и диагностика:

kubectl get svc,endpointslices                    # сервисы и адреса за ними
kubectl get endpointslices -l kubernetes.io/service-name=echo -o yaml   # условия ready, serving, terminating
kubectl logs ИМЯ --previous                       # журнал упавшего экземпляра контейнера
kubectl exec -it ИМЯ -- sh                        # оболочка в контейнере
kubectl run tmp --rm -it --restart=Never --image=busybox:1.37.0 -- sh   # разовый отладочный под
kubectl port-forward svc/echo 8080:80             # доступ к Service с машины через сервер API
kubectl top pods; kubectl top nodes               # потребление (нужен metrics-server)
kubectl get hpa -w                                # цель, метрика и решение HPA
kubectl taint nodes ИМЯ gpu=true:NoSchedule       # поставить ограничение; с минусом в конце — снять
kubectl cordon ИМЯ; kubectl drain ИМЯ --ignore-daemonsets   # вывести узел из обслуживания

minikube:

minikube start -p lab07 --nodes=2 --cpus=2 --memory=2600 --kubernetes-version=v1.37.0
minikube -p lab07 addons enable metrics-server
minikube -p lab07 addons enable ingress
minikube -p lab07 image build --all-nodes -t lab07/echo:1.0 app/
minikube -p lab07 node stop lab07-m02             # имитировать отказ узла
minikube -p lab07 ssh -n lab07-m02 -- sudo iptables -t nat -L KUBE-SERVICES -n
minikube -p lab07 tunnel                          # доступ к LoadBalancer и Ingress на macOS и Windows
minikube delete -p lab07

Значения по умолчанию, которые полезно помнить:

Что почитать и посмотреть

• Burns B., Grant B., Oppenheimer D., Brewer E., Wilkes J. «Borg, Omega, and Kubernetes» — Communications of the ACM, 2016, https://doi.org/10.1145/2890784. Короткая статья авторов Kubernetes о том, какие решения перенесены из Borg и Omega и почему: единый API, контроллеры с согласованием, метки вместо жёстких групп, под как единица размещения. Лучший ответ на вопрос «почему Kubernetes устроен именно так».
• Verma A., Pedrosa L., Korupolu M., Oppenheimer D., Tune E., Wilkes J. «Large-scale cluster management at Google with Borg» — EuroSys 2015, https://doi.org/10.1145/2741948.2741964. Описание предшественника Kubernetes с цифрами эксплуатации: приоритеты и вытеснение, переподписка ресурсов, планирование десятков тысяч машин. Хорошо читается после этой темы.
• Burns B., Beda J., Hightower K., Evenson L. Kubernetes: Up and Running, 3rd ed. — O'Reilly, 2022. Практическое введение от создателей проекта; главы о подах, сервисах, Deployment и о том, как сервер API хранит объекты, дополняют лекцию примерами.
• Luksa M. Kubernetes in Action. — Manning, 2018. Подробная книга с разбором внутреннего устройства: глава о том, как компоненты взаимодействуют через watch при создании Deployment, почти дословно совпадает с разделом «Путь одного kubectl apply».
• Документация Kubernetes, раздел Concepts — https://kubernetes.io/docs/concepts/. Первоисточник по всем объектам темы; страницы Pod Lifecycle, Deployments, Virtual IPs and Service Proxies и Horizontal Pod Autoscaling стоит прочитать целиком.
• Kubernetes Documentation. Debug Pods и Debug Services — https://kubernetes.io/docs/tasks/debug/debug-application/. Пошаговые сценарии диагностики, по сути развёрнутая версия таблицы состояний пода из лекции.
• Hightower K. Kubernetes The Hard Way — https://github.com/kelseyhightower/kubernetes-the-hard-way. Ручная установка кластера без автоматизаций: сертификаты, etcd, сервер API, kubelet по отдельности. Даёт ощущение того, из чего состоит кластер, которое minikube скрывает.
• The Raft Consensus Algorithm — https://raft.github.io/. Страница алгоритма с интерактивной визуализацией выбора лидера и репликации журнала; помогает понять кворум etcd не по формуле, а по поведению.
• Gateway API — https://gateway-api.sigs.k8s.io/. Официальный сайт преемника Ingress: модель ролей, руководства по HTTPRoute, разделению трафика и переходу с Ingress, список реализаций.
• Kubernetes Blog. Ingress NGINX Retirement: What You Need to Know — https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/. Объявление о прекращении развития самого распространённого Ingress-контроллера и рекомендации по переходу.
• Kubernetes Blog — https://kubernetes.io/blog/. Объявления о выпусках показывают, как меняются значения по умолчанию и что объявлено устаревшим (Endpoints, режим ipvs); полезно сверяться с ними при чтении старых материалов.

Углубление (по желанию)

От Borg к Kubernetes

Google запускал контейнеры на собственной системе Borg с середины 2000-х годов, задолго до появления Docker. Borg управлял десятками тысяч машин в одном кластере, смешивая на них сервисы, отвечающие пользователям, и пакетные задачи, и именно в нём сложились идеи приоритетов, вытеснения и переподписки ресурсов. Его недостатки тоже повлияли на Kubernetes. Задачи в Borg адресовались по имени задания и номеру копии, и для сложных приложений приходилось кодировать структуру в именах — в Kubernetes вместо этого появились метки и селекторы. Все копии задания в Borg разделяли IP-адрес машины и боролись за порты — в Kubernetes у каждого пода свой адрес. Монолитный центральный процесс Borgmaster стал узким местом — экспериментальная система Omega разделила планирование на несколько независимых планировщиков, работающих с общим хранилищем состояния с оптимистичной блокировкой, и эта идея превратилась в архитектуру Kubernetes: общее хранилище, сервер API и множество независимых контроллеров. Статья «Borg, Omega, and Kubernetes» перечисляет эти уроки явно и стоит того, чтобы прочитать её после лекции.

Оптимистичная блокировка и конфликты записи

Если контроллеры работают независимо и одновременно, что мешает двум из них затереть изменения друг друга? Сервер API использует оптимистичную блокировку (англ. optimistic concurrency). Каждый объект несёт resourceVersion; клиент, изменяющий объект, отправляет его вместе с версией, которую прочитал. Если с тех пор объект изменил кто-то другой, версии не совпадут, и сервер ответит 409 Conflict. Клиент должен перечитать объект, заново применить своё изменение и повторить попытку. Внутри сервер API реализует это транзакцией etcd «сравнить и записать». Блокировок, удерживаемых между запросами, нет, поэтому зависший контроллер не может заблокировать объект. Отсюда и требования к самим контроллерам: их действия должны быть идемпотентными, а вычисление — опираться на свежее состояние, что естественно сочетается с реакцией «на уровень». Для полей, которые разные участники меняют независимо, существует серверное применение (kubectl apply --server-side): сервер запоминает, какой менеджер владеет каждым полем, и сообщает о конфликте только при попытке изменить чужое поле. Именно этот механизм позволяет HPA владеть полем replicas, а системе доставки — остальными полями Deployment.

Как планировщик освобождает место: приоритеты и вытеснение

Если под не помещается ни на один узел, планировщик не всегда сдаётся. Каждому поду можно назначить класс приоритета (объект PriorityClass), и если допустимых узлов нет, модуль DefaultPreemption ищет узел, на котором удаление подов с меньшим приоритетом освободило бы достаточно места. Найдя, он помечает жертв на удаление, записывает в под поле status.nominatedNodeName и ждёт, пока место освободится. Выбор жертв учитывает бюджеты нарушения доступности (PodDisruptionBudget), но не гарантирует их соблюдения. Так в одном кластере уживаются важные сервисы и фоновые задачи: пакетные вычисления занимают простаивающие ресурсы, а при всплеске нагрузки уступают место. Именно об этом говорит вторая часть сообщения FailedScheduling, разобранного в лекции: «preemption: 0/2 nodes are available: 2 No preemption victims found» означает, что поды с меньшим приоритетом, удаление которых помогло бы, не нашлись.

Лабораторная работа 7. Kubernetes изнутри: развёртывание, сервисы, обновление, отказы и автомасштабирование

• Раздел курса: тема 7 «Оркестрация контейнеров: архитектура Kubernetes»

Введение

В лабораторных работах 3–6 контейнеры запускались командами Docker на одном хосте, и за каждым действием стояла явная команда человека. В этой работе управление переходит к кластеру: вы описываете желаемое состояние манифестами, а наблюдаете за тем, как контроллеры, планировщик, kubelet и kube-proxy приводят к нему фактическое. Цель работы — не выучить команды kubectl, а увидеть механизмы темы 7 в действии: цепочку событий одного kubectl apply, вычисляемую связь Service с подами через EndpointSlice, разницу между пробами живости и готовности, ограничения maxSurge и maxUnavailable при обновлении, реакцию кластера на отказ узла и формулу автомасштабирования.

Учебный стенд — кластер minikube из двух узлов. Второй узел нужен для главного опыта работы: его можно выключить и проследить по времени, как кластер признаёт его недоступным, выжидает допуск и создаёт замену подам. Нагрузка — небольшой учебный сервис echo на Python, собранный в двух версиях: каждая отвечает строкой с номером версии, именем пода и узла, поэтому по ответам видно, какая версия и какой под обслужили запрос. У сервиса есть отдельные эндпоинты для проб, эндпоинт для нагрузки на процессор, для захвата памяти и для имитации «зависания».

Работа состоит из базовой части (части 1–8) и продвинутой (части 9–10). В базовой части разворачивается сервис, исследуются Service и DNS, диагностируются типовые состояния подов, выполняется обновление без простоя, настраиваются Ingress и HPA, исправляются две намеренно внесённые ошибки и воспроизводится отказ узла. Продвинутая часть посвящена корректному завершению подов и поведению кластера без компонентов плоскости управления.

Цель работы

Научиться разворачивать и обновлять сервис в Kubernetes, наблюдать и объяснять работу контроллеров, планировщика, проб, Service и HPA и диагностировать типовые неисправности по выводу kubectl.

После выполнения работы можно будет:

• проследить путь kubectl apply по HTTP-запросам и событиям кластера и указать, какой компонент отвечает за каждый шаг;
• объяснить по EndpointSlice и правилам netfilter узла, как запрос к Service попадает в конкретный под, и найти причину пустого EndpointSlice;
• определить по выводу kubectl describe pod причину состояний Pending, ImagePullBackOff, CrashLoopBackOff и OOMKilled;
• рассчитать ход постепенного обновления для заданных maxSurge и maxUnavailable и подтвердить отсутствие простоя непрерывным зондом;
• опубликовать сервис через Ingress и проверить маршрутизацию по имени хоста;
• рассчитать по формуле HPA ожидаемое число реплик и сравнить его с решением контроллера;
• измерить время от отказа узла до замены его подов и объяснить его через node-monitor-grace-period и tolerationSeconds.

Теоретический минимум

Теория изложена в теме 7: разделы «Декларативная модель управления», «Архитектура кластера и путь запроса», «Pod, ресурсы и размещение», «Контроллеры рабочих нагрузок», «Сеть сервисов и автомасштабирование», «Диагностика, ограничения и типичные ошибки интерпретации». Ниже — сжатая справка.

Схема стенда:

 хост (Ubuntu 24.04, Docker Engine)
 │
 ├─ контейнер-узел lab07  (192.168.49.2) — плоскость управления + рабочий узел
 │    etcd, kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS,
 │    ingress-nginx-controller (порты 80/443 узла), metrics-server, kindnet, kube-proxy
 │    поды namespace lab07: toolbox, часть подов echo
 │
 └─ контейнер-узел lab07-m02 (192.168.49.3) — рабочий узел
      kindnet, kube-proxy, часть подов echo        ← этот узел выключается в части 8

 Service echo: ClusterIP 10.96.x.y:80 → поды app=echo :8080
 Ingress echo: Host echo-<вариант>.lab07.local → Service echo:80

Адреса узлов и ClusterIP у вас могут отличаться; фактические значения возьмите из kubectl get nodes -o wide и kubectl get svc.

Учебный сервис lab07/echo (исходник app/app.py в архиве окружения):

Переменная SHUTDOWN_DELAY (по умолчанию 5 с) задаёт, сколько секунд сервис после SIGTERM продолжает обслуживать запросы, отвечая 503 на /readyz.

Основные команды:

Перечень оснащения

• ОС Ubuntu 24.04 (физическая машина, виртуальная машина или WSL2 с включённой интеграцией Docker) либо macOS или Windows с Docker Desktop; особенности последних оговорены в тексте.

• Docker Engine 27 или новее (docker version), пользователь в группе docker.

• minikube v1.39.0 (та же версия, что в курсовом проекте):

  curl -LO https://github.com/kubernetes/minikube/releases/download/v1.39.0/minikube-linux-amd64
  sudo install minikube-linux-amd64 /usr/local/bin/minikube
  

• kubectl v1.36, v1.37 или v1.38 (допускается расхождение с версией кластера на одну младшую версию):

  curl -LO https://dl.k8s.io/release/v1.37.0/bin/linux/amd64/kubectl
  sudo install kubectl /usr/local/bin/kubectl
  

• Кластер: Kubernetes v1.37.0 (версия по умолчанию в minikube v1.39.0), среда выполнения docker (через cri-dockerd), сетевой модуль kindnet (minikube выбирает его сам для нескольких узлов), kube-proxy в режиме iptables.

• Дополнения minikube: metrics-server (образ metrics-server/metrics-server:v0.9.0) и ingress. Дополнение ingress в minikube v1.39.0 разворачивает контроллер ingress-nginx (образ ingress-nginx/controller:v1.15.1). Проект ingress-nginx снят с поддержки: обновления прекращены в марте 2026 года, репозиторий переведён в архив, исправлений уязвимостей больше не будет. Для учебной работы это допустимо: изучается API Ingress, а не конкретный контроллер, и тот же аддон используется на этапах 3–5 курсового проекта (на этапе 6 он заменяется на Traefik). В эксплуатации новый кластер так строить не следует — см. тему 7, подраздел «Ingress и Gateway API».

• Образы: lab07/echo:1.0 и lab07/echo:2.0 (собираются из app/ на базе python:3.12.12-slim-bookworm), curlimages/curl:8.17.0, busybox:1.37.0.

• Архив окружения lr-env: up.sh, down.sh, probe.sh, app/, manifests/, broken/, patches/, README.md.

• Ресурсы: 4 ядра, 8 ГБ RAM (два узла по 2 ядра и 2600 МиБ), около 8 ГБ свободного места на диске, доступ в Интернет для загрузки образов.

Порядок выполнения работы

Распакуйте архив и поднимите стенд:

unzip lr-env.zip -d ~/lab07 && cd ~/lab07/lr-env && chmod +x *.sh
./up.sh
kubectl config set-context --current --namespace=lab07

Скрипт up.sh создаёт профиль minikube lab07 с двумя узлами, включает дополнения metrics-server и ingress, собирает оба тега учебного образа сразу на обоих узлах (minikube image build --all-nodes), создаёт пространство имён lab07 и вспомогательный под toolbox с curl. Третья команда делает lab07 пространством имён по умолчанию, поэтому ниже флаг -n lab07 опущен. Первый запуск занимает 5–10 минут.

Для нескольких частей нужны два-три терминала одновременно: в одном идёт наблюдение (-w) или зонд, в другом выполняются действия. Каждая часть, кроме оговорённых, начинается с исправного Deployment echo из части 1; если опыт его испортил, верните его командой kubectl apply -f manifests/10-echo-deployment.yaml с параметрами своего варианта. По окончании работы удалите кластер: ./down.sh.

Зонд probe.sh запускается внутри пода toolbox и раз в секунду печатает число ответов каждой версии и число ошибок:

kubectl exec -i toolbox -- sh -s -- http://echo/ 120 < probe.sh

Выберите вариант по номеру и подставляйте его значения в манифесты и команды. В manifests/ лежат значения варианта 1.

Часть 1. Компоненты кластера и путь kubectl apply

Задание

1. Посмотрите узлы и системные поды:

   kubectl get nodes -o wide
   kubectl get pods -n kube-system -o wide
   

   Найдите в выводе каждый компонент из таблицы раздела «Плоскость управления и рабочие узлы» темы 7. Какие компоненты есть на обоих узлах, а какие — только на lab07? Почему поды kube-apiserver-lab07, etcd-lab07 и другие компоненты плоскости управления имеют в имени суффикс узла? Подсказка: посмотрите на узле каталог /etc/kubernetes/manifests (minikube -p lab07 ssh -- ls /etc/kubernetes/manifests).

2. Откройте второй терминал и запустите наблюдение за событиями: kubectl get events -w.

3. Подставьте в manifests/10-echo-deployment.yaml значения replicas, maxSurge и maxUnavailable своего варианта. Предсказание: сколько и каких объектов появится в кластере после применения манифеста? Какие компоненты запишут события и в каком порядке?

4. Примените манифест с подробным журналом HTTP-запросов:

   kubectl apply -f manifests/10-echo-deployment.yaml -v=6 2>&1 | grep -E "Response|created|configured"
   

   Какие запросы отправил kubectl и с какими кодами ответа? Почему команда завершилась раньше, чем поды стали готовыми?

5. Сопоставьте события из второго терминала с компонентами: кто записал ScalingReplicaSet, SuccessfulCreate, Scheduled, Pulled, Created, Started?

6. Посмотрите иерархию объектов и связи владения:

   kubectl get deploy,rs,pods -l app=echo -o wide
   kubectl get pod ИМЯ_ПОДА -o yaml | grep -A6 ownerReferences
   kubectl get pods -l app=echo --show-labels
   

   Откуда в имени пода взялись две случайные на вид части? Где ещё встречается первая из них?

7. Повторите kubectl apply того же файла без изменений с -v=6. Какой запрос отправлен теперь и что ответил kubectl? Измените в манифесте только replicas и примените снова. Появился ли новый ReplicaSet? А если изменить значение SHUTDOWN_DELAY в шаблоне? Верните исходное значение.

8. Запишите распределение подов по узлам. Объясните его через фильтрацию и скоринг: какой узел и почему получил больше подов? Подсказка: kubectl describe node lab07 | grep -A8 "Allocated resources" и то же для lab07-m02.

Что должно получиться

Таблица «компонент — где работает — чем реализован (статический под, DaemonSet, Deployment)». Компоненты плоскости управления — статические поды, которые kubelet узла lab07 запускает прямо из файлов /etc/kubernetes/manifests, поэтому их имена содержат имя узла; kube-proxy и kindnet — поды DaemonSet, по одному на узел.

Ответ kubectl apply для нового объекта имеет примерно такой вид (у вас будут другие адреса и времена):

... "Response" verb="GET" url="https://192.168.49.2:8443/apis/apps/v1/namespaces/lab07/deployments/echo" status="404 Not Found" milliseconds=5
... "Response" verb="POST" url="https://192.168.49.2:8443/apis/apps/v1/namespaces/lab07/deployments?fieldManager=kubectl-client-side-apply&fieldValidation=Strict" status="201 Created" milliseconds=12
deployment.apps/echo created

При повторном применении без изменений вместо POST будет только GET, а kubectl напишет deployment.apps/echo unchanged; после изменения — PATCH и configured. Объекты: один Deployment, один ReplicaSet echo-<хеш шаблона>, поды echo-<хеш шаблона>-<случайный суффикс>; хеш совпадает с меткой pod-template-hash. Изменение replicas не создаёт нового ReplicaSet, а изменение любого поля шаблона создаёт. Обычно на рабочий узел lab07-m02 попадает больше подов: на lab07 запросы системных подов уже занимают около половины процессора, и оценка LeastAllocated у него ниже. Если поды распределились иначе, объясните это по выводу Allocated resources.

Часть 2. Service, EndpointSlice, kube-proxy и DNS

Задание

1. Создайте Service и посмотрите, что за ним стоит:

   kubectl apply -f manifests/20-echo-service.yaml
   kubectl get svc echo
   kubectl get endpointslices -l kubernetes.io/service-name=echo -o wide
   kubectl get pods -l app=echo -o wide
   

   Сопоставьте адреса в EndpointSlice с адресами подов.

2. Предсказание. Сколько ответов из 100 придётся на каждый под, если выполнить 100 запросов к Service? Проверьте:

   kubectl exec toolbox -- sh -c 'for i in $(seq 1 100); do curl -s http://echo/; done' | awk '{print $2}' | sort | uniq -c
   

3. Попробуйте ping до ClusterIP из разового пода (kubectl run pingtest --rm -it --restart=Never --image=busybox:1.37.0 -- ping -c 2 -W 1 АДРЕС) и найдите ClusterIP в выводе ip -4 addr на узле (minikube -p lab07 ssh -- ip -4 addr). Объясните результат.

4. Найдите правила kube-proxy для сервиса на узле lab07-m02:

   minikube -p lab07 ssh -n lab07-m02 -- sudo iptables -t nat -L KUBE-SERVICES -n | grep lab07/echo
   minikube -p lab07 ssh -n lab07-m02 -- sudo iptables -t nat -L ИМЯ_ЦЕПОЧКИ_KUBE-SVC -n
   

   Если вывод пуст, проверьте режим kube-proxy: kubectl -n kube-system get configmap kube-proxy -o yaml | grep mode (пустое значение означает iptables). Выпишите вероятности в правилах statistic mode random probability. Почему они разные, а распределение запросов в пункте 2 при этом близко к равномерному? Докажите расчётом.

5. В третьем терминале запустите kubectl get endpointslices -l kubernetes.io/service-name=echo -w. Уменьшите число реплик до 2, затем верните значение варианта. Как изменился слайс? Как изменились правила из пункта 4?

6. Исследуйте DNS: посмотрите /etc/resolv.conf пода toolbox и разрешите имена echo, echo.lab07, echo.lab07.svc.cluster.local, kubernetes.default:

   kubectl exec toolbox -- cat /etc/resolv.conf
   kubectl exec toolbox -- nslookup echo.lab07.svc.cluster.local
   

   Если в образе нет nslookup, используйте разовый под: kubectl run dns --rm -it --restart=Never --image=busybox:1.37.0 -- nslookup echo. Сколько запросов к DNS породит обращение пода к внешнему имени example.com при ndots:5? Объясните по списку search.

Что должно получиться

В EndpointSlice ровно столько адресов, сколько готовых подов, порт 8080. Распределение 100 запросов близко к равномерному, но не точно: при четырёх подах типичный разброс — от 18 до 32 на под. ClusterIP не отвечает на ping и не найден ни на одном интерфейсе: это не адрес хоста, а ключ в правилах netfilter. Цепочка сервиса для четырёх подов выглядит примерно так:

Chain KUBE-SVC-HQ2G4WMPSLX6C4TA (1 references)
target                     prot opt source          destination
KUBE-MARK-MASQ             tcp  --  !10.244.0.0/16  10.96.120.15  /* lab07/echo:http cluster IP */ tcp dpt:80
KUBE-SEP-7TJYQ5XHNBVAMB2K  all  --  0.0.0.0/0       0.0.0.0/0     /* lab07/echo:http -> 10.244.0.5:8080 */ statistic mode random probability 0.25000000000
KUBE-SEP-ZKL3EGQX6I2OJ4MZ  all  --  0.0.0.0/0       0.0.0.0/0     /* lab07/echo:http -> 10.244.1.3:8080 */ statistic mode random probability 0.33333333349
KUBE-SEP-BOVJ55WUE6WTCCPS  all  --  0.0.0.0/0       0.0.0.0/0     /* lab07/echo:http -> 10.244.1.4:8080 */ statistic mode random probability 0.50000000000
KUBE-SEP-K6OPLPS24GYIZQ5D  all  --  0.0.0.0/0       0.0.0.0/0     /* lab07/echo:http -> 10.244.1.5:8080 */

Правила проверяются по порядку: первое срабатывает с вероятностью 1/4; второе — с вероятностью 1/3 из оставшихся 3/4, то есть 1/4; третье — 1/2 из оставшейся половины, то есть 1/4; последнее забирает остаток 1/4. После изменения числа подов вероятности пересчитываются. В resolv.conf — search lab07.svc.cluster.local svc.cluster.local cluster.local и options ndots:5; обращение к example.com даёт до четырёх запросов для каждого типа записи: три с доменами поиска (все с ответом NXDOMAIN) и одно для самого имени.

Часть 3. Ресурсы, пробы и диагностика состояний пода

Задание

1. Определите класс QoS подов echo и toolbox:

   kubectl get pods -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass
   

   Объясните класс каждого по их манифестам. Как изменить манифест echo, чтобы класс стал Guaranteed?

2. Посмотрите, во что превратились лимиты внутри контейнера (cgroup v2):

   kubectl exec ИМЯ_ПОДА_ECHO -- cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/memory.max /sys/fs/cgroup/cpu.weight
   

   Объясните каждое число через resources манифеста.

3. Живость. Узнайте IP одного пода echo. Во втором терминале наблюдайте kubectl get pods -l app=echo -w. «Сломайте» под: kubectl exec toolbox -- curl -s http://IP_ПОДА:8080/break. Предсказание: через сколько секунд и что произойдёт с подом? Останется ли он в EndpointSlice, пока /healthz отвечает 500? Проверьте по событиям (kubectl describe pod) и по RESTARTS. Сменился ли IP пода после перезапуска?

4. Память. Выполните kubectl exec toolbox -- curl -s -m 10 "http://IP_ПОДА:8080/alloc?mb=200". Что ответил curl? Посмотрите kubectl describe pod — раздел Last State контейнера. Почему код выхода 137 и почему сам под не удалён?

5. Размещение. Примените broken/too-big.yaml. В каком состоянии под? Прочитайте событие FailedScheduling и объясните каждую его часть. Каким должен быть запрос процессора, чтобы под разместился, — оцените по Allocated resources узлов. Удалите под.

6. Образ. Создайте под с несуществующим тегом: kubectl run badimage --image=lab07/echo:9.9 --restart=Never. Какие состояния он проходит? Чем отличаются ErrImagePull и ImagePullBackOff? Найдите в событиях адрес реестра, к которому обращался узел, и объясните, почему именно туда. Удалите под.

Что должно получиться

Поды echo — Burstable (запросы меньше лимитов), toolbox — тоже Burstable (лимита процессора нет); для Guaranteed нужны лимиты процессора и памяти, равные запросам. Внутри контейнера cpu.max равно 50000 100000 (лимит 500m), memory.max — 134217728 (128 МиБ); cpu.weight отражает запрос 100m в шкале весов cgroup v2 (обычно 4). Если на узле cgroup v1, этих файлов нет — отметьте это и пропустите пункт.

После /break проба живости проваливается три раза с периодом 5 с, и примерно через 10–15 с kubelet перезапускает контейнер:

  Warning  Unhealthy  14s (x3 over 24s)  kubelet  Liveness probe failed: HTTP probe failed with statuscode: 500
  Normal   Killing    14s                kubelet  Container echo failed liveness probe, will be restarted

Под всё это время остаётся готовым и в EndpointSlice, потому что /readyz отвечает 200: пробы независимы. RESTARTS увеличивается на 1, имя и IP пода не меняются — перезапущен контейнер, а не под. После /alloc?mb=200 curl получает пустой ответ или обрыв соединения, а в описании контейнера — Last State: Terminated, Reason: OOMKilled, Exit Code: 137: ядро убило процесс сигналом SIGKILL (128 + 9) при превышении memory.max. Под too-big остаётся в Pending с сообщением вида 0/2 nodes are available: 2 Insufficient cpu. Под badimage проходит ErrImagePull (первая неудача) и ImagePullBackOff (ожидание перед повтором с растущей задержкой); образа нет локально, и узел пытается загрузить его из Docker Hub (docker.io/lab07/echo), где такого репозитория нет.

Часть 4. Постепенное обновление без простоя

Задание

1. Расчёт. Для своего варианта вычислите: максимальное число подов во время обновления, минимальное число доступных подов, число шагов «создать — дождаться готовности — удалить». Для варианта 10 учтите правила округления процентов. Нарисуйте таблицу шагов по образцу рисунка «RollingUpdate по шагам» из темы 7.

2. Подготовьте три терминала:

   • терминал A — зонд на 150 с: kubectl exec -i toolbox -- sh -s -- http://echo/ 150 < probe.sh;
   • терминал B — kubectl get rs -l app=echo -w;
   • терминал C — для команд.

3. В терминале C запустите обновление и проследите его:

   kubectl annotate deployment/echo kubernetes.io/change-cause="версия 2.0"
   kubectl set image deployment/echo echo=lab07/echo:2.0
   kubectl rollout status deployment/echo
   

   Сравните наблюдаемые в терминале B числа реплик двух ReplicaSet с расчётом пункта 1. Были ли в зонде ошибки (ERR)? В какие секунды отвечали обе версии одновременно?

4. Неудачная версия. Перезапустите зонд и выполните kubectl set image deployment/echo echo=lab07/echo:2.1 (такого тега нет). Предсказание: сколько подов старой версии будет удалено? Будут ли ошибки в зонде? Через kubectl rollout status deployment/echo --timeout=60s убедитесь, что обновление остановилось. Сравните поведение для вариантов с maxUnavailable: 0 и maxUnavailable: 1 (смените значение у себя и повторите).

5. Посмотрите историю и откатитесь на предыдущую ревизию:

   kubectl rollout history deployment/echo
   kubectl rollout undo deployment/echo
   kubectl get rs -l app=echo
   

   Какой ReplicaSet был масштабирован при откате — новый или существующий? Сколько ReplicaSet сейчас хранится и почему?

Что должно получиться

Для варианта 1 (4 реплики, maxSurge: 1, maxUnavailable: 0): не больше 5 подов, не меньше 4 доступных, четыре цикла по одному поду. Вывод зонда при обновлении имеет примерно такой вид (числа запросов в секунду зависят от машины):

14:02:10 1.0=41
14:02:11 1.0=39
14:02:12 1.0=33 2.0=8
14:02:13 1.0=30 2.0=11
...
14:02:24 1.0=6 2.0=33
14:02:25 2.0=40
ИТОГО запросов=6012 1.0=3105 2.0=2907

Ошибок нет: новые поды получают трафик только после прохождения readinessProbe, а завершаемые старые поды по SIGTERM сразу отвечают 503 на /readyz, но ещё 5 с обслуживают запросы, пока EndpointSlice и правила kube-proxy обновляются. Для тега 2.1 при maxUnavailable: 0 создаётся maxSurge подов в ErrImagePull или ImagePullBackOff, старые поды не удаляются, ошибок в зонде нет; rollout status завершается по тайм-ауту. При maxUnavailable: 1 один старый под удаляется сразу, ёмкость снижается, но сервис работает. При откате масштабируется существующий ReplicaSet предыдущей ревизии, новый не создаётся; в rollout history предыдущая ревизия получает новый номер. Если в зонде всё же появились единичные ERR во время обновления, проверьте, что readinessProbe в манифесте указывает на /readyz, и что SHUTDOWN_DELAY не равен 0.

Часть 5. Ingress

Задание

1. Убедитесь, что Ingress-контроллер работает и зарегистрирован класс nginx:

   kubectl get pods -n ingress-nginx -o wide
   kubectl get ingressclass
   

   На каком узле работает контроллер и почему именно на нём? Подсказка: kubectl get deploy -n ingress-nginx ingress-nginx-controller -o yaml | grep -A2 nodeSelector.

2. Подставьте хост своего варианта в manifests/30-echo-ingress.yaml и примените его. Дождитесь, пока в kubectl get ingress echo появится адрес.

3. Обратитесь к сервису с хоста через Ingress:

   IP=$(minikube -p lab07 ip)
   curl -s -H "Host: echo-a.lab07.local" http://$IP/
   curl -s -o /dev/null -w '%{http_code}\n' http://$IP/
   curl -s -o /dev/null -w '%{http_code}\n' -H "Host: other.lab07.local" http://$IP/
   

   На macOS и Windows с Docker Desktop адрес узла с хоста недоступен: запустите в отдельном терминале minikube -p lab07 tunnel и используйте 127.0.0.1 вместо $IP. Объясните коды ответа для запросов без правильного заголовка Host. Кто их вернул — Service, под echo или контроллер?

4. Добавьте в Ingress второе правило: путь /api с pathType: Prefix к тому же Service. Предсказание: какие из путей /api, /api/x, /apix, /API подойдут под это правило? Учебный сервис на всё, кроме своих путей, отвечает 404 — по какому признаку в ответе различить «404 от сервиса» и «404 от контроллера»?

5. Запустите зонд с хоста через Ingress и одновременно выполните обновление на версию 2.0 и обратно:

   sh probe.sh http://$IP/ 120 echo-a.lab07.local
   

   Есть ли ошибки? Чем путь запроса отличается от пути в части 4?

Что должно получиться

Контроллер работает на узле lab07 (в манифесте дополнения задан nodeSelector на основной узел minikube) и принимает соединения на портах 80 и 443 узла. С правильным заголовком Host возвращается строка version=… pod=…, без него или с чужим именем — 404 от контроллера, потому что ни одно правило не подошло. Различить источник 404 можно по телу ответа и заголовку Server: контроллер отвечает HTML-страницей nginx, учебный сервис — строкой not found и заголовком Server: lab07-echo/…. Под правило /api подходят /api и /api/x; /apix не подходит (сравнение по элементам пути), /API тоже (регистр учитывается). Ingress-контроллер сам выбирает под по EndpointSlice и обращается к нему напрямую, минуя ClusterIP; обновление через Ingress проходит без ошибок.

Часть 6. Сломать и починить

В этой части ошибки уже внесены в манифесты каталога broken/. Сначала проведите диагностику только по выводу kubectl, и лишь потом читайте манифесты.

Задание

1. Сервис, который не отвечает. Примените broken/web-service.yaml. Пользователи сообщают: запросы к http://web/ не проходят. Проверьте kubectl exec toolbox -- curl -s -m 3 http://web/ и проведите диагностику: kubectl get svc web, kubectl describe svc web, kubectl get endpointslices -l kubernetes.io/service-name=web. Сформулируйте гипотезу и проверьте её командой kubectl get pods -l СЕЛЕКТОР_СЕРВИСА. Почему curl получил немедленный отказ, а не тайм-аут? Исправьте манифест минимальным изменением, примените и убедитесь, что слайс заполнился, а запросы проходят.

2. Каскадный перезапуск. Примените broken/deep-liveness.yaml: он создаёт «базу данных» db-stub и сервис api, обращающийся к ней. Убедитесь, что все поды api готовы. Во втором терминале запустите kubectl get pods -l app=api -w. Имитируйте отказ базы:

   kubectl scale deployment/db-stub --replicas=0
   

   Предсказание: что произойдёт с подами api и через сколько секунд? Наблюдайте 3–4 минуты. Запишите, как менялись RESTARTS и STATUS. Затем верните базу (--replicas=1) и засеките, через сколько секунд все поды api снова готовы.

3. Найдите причину по kubectl describe pod одного из подов api и только теперь прочитайте манифест. Исправьте пробы так, чтобы отказ базы не перезапускал api. Предложите два варианта: а) livenessProbe на /healthz, readinessProbe на /deep; б) обе пробы без проверки зависимости. Для каждого повторите опыт пункта 2 и сравните: что видит клиент api во время отказа базы (kubectl exec toolbox -- curl -s -m 2 -w ' %{http_code}\n' http://api/), как быстро сервис восстанавливается после возврата базы? Какой вариант вы выбрали бы для backend «Заметок» и почему?

4. Удалите объекты: kubectl delete -f broken/deep-liveness.yaml -f broken/web-service.yaml.

Что должно получиться

В первом случае describe svc web показывает селектор app=echo,tier=frontend и пустое поле Endpoints, а kubectl get pods -l app=echo,tier=frontend ничего не находит: у подов метка tier=backend. Для Service без готовых адресов kube-proxy ставит правило, отвергающее соединение, поэтому curl сразу получает «Connection refused» (код выхода 7). Исправление — tier: backend в селекторе (или удаление строки tier).

Во втором случае примерно через 10 с после отказа базы (failureThreshold: 2 × periodSeconds: 5) все три пода api одновременно перезапускаются, затем снова — и через несколько циклов переходят в CrashLoopBackOff:

NAME                   READY   STATUS             RESTARTS      AGE
api-6c9d7f5b8d-4kq2x   1/1     Running            3 (22s ago)   4m
api-6c9d7f5b8d-9wmzp   0/1     CrashLoopBackOff   3 (8s ago)    4m
api-6c9d7f5b8d-tz5lc   1/1     Running            3 (25s ago)   4m

В событиях — Liveness probe failed: HTTP probe failed with statuscode: 503 и Back-off restarting failed container. После возврата базы поды, находящиеся в ожидании, остаются недоступными до конца текущей задержки (до десятков секунд или минут, в зависимости от числа перезапусков). В варианте а) поды api не перезапускаются, но все становятся неготовыми, EndpointSlice пустеет, и клиент получает отказ в соединении; после возврата базы готовность восстанавливается за 2–4 с. В варианте б) api остаётся в Service и отвечает клиенту сам — в учебном сервисе это ответ 200 на /, а в настоящем backend это был бы осмысленный ответ 503 «база недоступна». Обоснуйте свой выбор.

Часть 7. Горизонтальное автомасштабирование

Задание

1. Убедитесь, что metrics-server отдаёт данные: kubectl top nodes и kubectl top pods. Если команда отвечает metrics not available yet, подождите 1–2 минуты: в дополнении minikube metrics-server собирает данные раз в 60 с (--metric-resolution=60s), поэтому и HPA в этой работе реагирует медленнее, чем в кластере со стандартными 15 с.

2. Подставьте параметры своего варианта в manifests/40-echo-hpa.yaml и примените его. Во втором терминале наблюдайте kubectl get hpa echo -w, в третьем — kubectl get pods -l app=echo -w. Что HPA сделал с числом реплик без нагрузки и почему не сразу?

3. Включите нагрузку и наблюдайте 4–5 минут:

   kubectl apply -f manifests/60-loadgen.yaml
   kubectl scale deployment/loadgen --replicas=1
   

   Генератор в цикле просит сервис занять процессор на 50 мс и ждёт 100 мс. Расчёт: оцените создаваемую нагрузку в миллиядрах. Возьмите из kubectl get hpa первое значение метрики под нагрузкой и вычислите по формуле \lceil \text{current} \cdot \text{metric}/\text{target} \rceil ожидаемое число реплик. Совпало ли оно с решением HPA? Какое значение метрики установилось после масштабирования и почему HPA на нём остановился?

4. Увеличьте нагрузку до --replicas=3. Упёрся ли HPA в maxReplicas? Если часть новых подов осталась в Pending, объясните почему.

5. Снимите нагрузку (--replicas=0) и засеките, через сколько секунд HPA уменьшил число реплик. Сравните с stabilizationWindowSeconds в манифесте и со значением по умолчанию.

6. Конфликт владельцев. При работающем HPA выполните kubectl apply -f manifests/10-echo-deployment.yaml. Что произошло с числом реплик сразу и через минуту? Как устранить конфликт в манифесте?

7. Удалите HPA (kubectl delete hpa echo) и верните число реплик своего варианта.

Что должно получиться

Без нагрузки метрика около 1–3 %, и HPA уменьшает число реплик до minReplicas, но не сразу, а после окна стабилизации уменьшения (60 с в манифесте, 300 с по умолчанию). Один генератор создаёт около 300m нагрузки (50 мс работы на каждые примерно 150 мс цикла), фактически чуть меньше из-за задержек сети. Для варианта 1 при двух репликах это около 150 % от запроса 100m, расчёт \lceil 2 \cdot 150/50 \rceil = 6. Вывод HPA имеет примерно такой вид:

NAME   REFERENCE         TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
echo   Deployment/echo   cpu: 2%/50%    2         8         2          3m
echo   Deployment/echo   cpu: 148%/50%  2         8         2          4m10s
echo   Deployment/echo   cpu: 148%/50%  2         8         6          4m25s
echo   Deployment/echo   cpu: 49%/50%   2         8         6          5m40s

После масштабирования те же 300m делятся на шесть подов, около 50 % — отношение к цели в пределах допуска 0,1, и HPA останавливается. При трёх генераторах формула даёт больше maxReplicas, и HPA останавливается на максимуме. Поды в Pending возможны, если сумма запросов превысила свободное по запросам на узлах (HPA не добавляет узлов). После снятия нагрузки уменьшение происходит примерно через 60 с окна стабилизации плюс время, за которое metrics-server обновит данные (до 60 с), и один-два цикла HPA. Повторный apply манифеста с полем replicas сбрасывает число реплик к значению из файла, а HPA через цикл возвращает своё: два владельца одного поля спорят. Решение — не указывать replicas в манифесте Deployment, которым управляет HPA.

Часть 8. Отказ узла

Задание

1. Убедитесь, что поды echo есть на обоих узлах (kubectl get pods -l app=echo -o wide); если все на одном, увеличьте replicas на 2. Посмотрите допуски любого пода:

   kubectl get pod ИМЯ_ПОДА -o yaml | grep -B2 -A3 tolerationSeconds
   

   Кто добавил эти допуски, если в манифесте их нет?

2. Опыт с настройками по умолчанию. Подготовьте четыре терминала:

   • A — зонд на 480 с: kubectl exec -i toolbox -- sh -s -- http://echo/ 480 < probe.sh (под toolbox закреплён на узле lab07 полем nodeSelector, поэтому выключение второго узла его не затронет);
   • B — kubectl get nodes -w;
   • C — kubectl get pods -l app=echo -o wide -w;
   • D — для команд.

   Предсказание: через сколько секунд после выключения узла он станет NotReady, через сколько его поды получат статус Terminating и когда появятся замены? Будут ли ошибки в зонде и в какой промежуток времени? Выключите узел и запишите время:

   date +%T; minikube -p lab07 node stop lab07-m02
   

3. Пока идёт ожидание, посмотрите ограничения и условия узла: kubectl describe node lab07-m02 | grep -A3 -E "Taints|Conditions". Какое ограничение поставлено и когда? Почему проба готовности не убрала поды выключенного узла из Service сразу?

4. Дождитесь появления замен и запишите времена трёх событий: NotReady, Terminating старых подов, Running 1/1 новых. Сравните с таблицей времени из темы 7. В каком состоянии остались старые поды и почему они не удалены?

5. Включите узел: minikube -p lab07 node start lab07-m02. Что стало со старыми подами? Вернулись ли поды на восстановленный узел? Почему?

6. Опыт с короткими допусками. Подставьте tolerationSeconds своего варианта в patches/fast-eviction.yaml и примените патч:

   kubectl patch deployment echo --patch-file patches/fast-eviction.yaml
   kubectl rollout status deployment/echo
   

   Распределите поды по обоим узлам (например, kubectl rollout restart deployment/echo после возврата узла) и повторите пункты 2–5. Рассчитайте ожидаемое время до замены и сравните с измеренным.

7. Какие недостатки у очень маленького tolerationSeconds, например 1 с? Какие поды в кластере никогда не выселяются с недоступного узла (посмотрите допуски подов kube-proxy и kindnet)?

Что должно получиться

Допуски node.kubernetes.io/not-ready и node.kubernetes.io/unreachable с tolerationSeconds: 300 добавляет при создании пода контроллер допуска DefaultTolerationSeconds. Ожидаемая хронология с настройками по умолчанию (время от выключения узла):

Проба готовности не помогла в первые 50 секунд, потому что пробы выполняет kubelet самого узла, а он выключен: снаружи пробы не проверяются, и до решения контроллера узлов поды формально остаются готовыми. Зонд в этот промежуток показывает ошибки примерно пропорционально доле подов на выключенном узле, причём каждая ошибка — это ожидание до тайм-аута 2 с, поэтому общее число запросов в секунду резко падает:

14:20:31 1.0=40
14:20:33 1.0=9 ERR=3
14:20:35 1.0=12 ERR=2
...
14:21:20 1.0=38

Старые поды остаются в Terminating, пока узел не вернётся: сервер API не может подтвердить, что их контейнеры остановлены. После включения узла kubelet завершает их, и объекты удаляются. Поды обратно не переезжают: планировщик назначает узел только новым подам и не перераспределяет работающие, поэтому после восстановления нагрузка неравномерна до следующего обновления или перезапуска. С tolerationSeconds: 30 замены появляются примерно через 50 + 30 ≈ 80 с. Слишком малый допуск приводит к перезапуску всех подов узла при любом кратковременном сетевом сбое. Поды DaemonSet (kube-proxy, kindnet) имеют допуски без tolerationSeconds и никогда не выселяются.

Часть 9. Корректное завершение и гонка с EndpointSlice (продвинутая)

Задание

1. Отключите задержку завершения: kubectl set env deployment/echo SHUTDOWN_DELAY=0 и дождитесь окончания обновления. Теперь каждый под по SIGTERM сразу закрывает порт.
2. Запустите зонд и выполните 3–5 обновлений подряд, переключая образ между 1.0 и 2.0. Подсчитайте ошибки в итоговой строке зонда. Повторите то же с SHUTDOWN_DELAY=5.
3. Объясните разницу через две параллельные цепочки событий при удалении пода (тема 7, «Корректное завершение пода»). Почему ошибки появляются только в короткие окна и не при каждом обновлении?
4. Добавьте вместо задержки в приложении хук preStop с паузой 5 с (при SHUTDOWN_DELAY=0) и повторите опыт. Как влияет пауза preStop на terminationGracePeriodSeconds? Что произойдёт, если сделать паузу больше 30 с?

Что должно получиться

С SHUTDOWN_DELAY=0 в итоговой строке зонда появляются единичные ERR (обычно от 0 до нескольких на обновление; точное число зависит от скорости машины и момента), с задержкой 5 с ошибок нет. Ошибки возникают, если запрос отправлен по правилам kube-proxy, которые ещё указывают на завершившийся под. preStop с паузой даёт тот же эффект, что задержка в приложении, но время паузы входит в terminationGracePeriodSeconds: при паузе больше 30 с kubelet пошлёт SIGKILL раньше, чем приложение получит SIGTERM и успеет корректно завершиться. Если ошибок нет и при нулевой задержке, увеличьте частоту запросов, запустив два зонда параллельно.

Часть 10. Кластер без планировщика и без сервера API (продвинутая)

Задание

1. Остановите планировщик, переместив манифест его статического пода:

   minikube -p lab07 ssh -- sudo mv /etc/kubernetes/manifests/kube-scheduler.yaml /tmp/
   kubectl get pods -n kube-system | grep scheduler
   

2. Увеличьте replicas у echo на 2. В каком состоянии новые поды? Есть ли у них событие FailedScheduling? Чем это отличается от пода too-big из части 3? Удалите один старый под echo — заменит ли его ReplicaSet и запустится ли замена?

3. Верните манифест (sudo mv /tmp/kube-scheduler.yaml /etc/kubernetes/manifests/) и проследите, как быстро ожидающие поды получили узлы.

4. Без сервера API. Запустите зонд с хоста через Ingress (sh probe.sh http://$IP/ 120 ХОСТ_ВАРИАНТА) и остановите сервер API тем же способом (kube-apiserver.yaml). Что отвечает kubectl get pods? Продолжает ли работать зонд? Почему в этом опыте зонд нельзя запускать через kubectl exec? Через 60–90 с верните манифест и дождитесь ответа kubectl get nodes.

Что должно получиться

Без планировщика новые поды остаются в Pending с пустым NODE и без событий Scheduled и FailedScheduling: их просто никто не обрабатывает. ReplicaSet при этом работает — замена удалённому поду создаётся, но тоже остаётся Pending. После возврата манифеста kubelet запускает планировщик за несколько секунд, и ожидающие поды получают узлы. Без сервера API kubectl отвечает The connection to the server 192.168.49.2:8443 was refused, а зонд через Ingress продолжает получать ответы: Ingress-контроллер, kube-proxy и поды работают по последнему известному состоянию. Зонд через kubectl exec оборвался бы, потому что поток exec идёт через сервер API. Это наглядная иллюстрация тезиса темы 7: потеря плоскости управления останавливает управление, но не приложения.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Особенно полезно фиксировать время событий в частях 4, 7 и 8 — по ним видно, из каких задержек складывается реакция кластера. Выводы kubectl describe и строки зонда, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце сформулируйте несколько предложений собственных выводов: какие задержки и пороги кластера вы теперь можете предсказать и какие настройки стали бы менять в своём сервисе.

Контрольные вопросы

1. Почему kubectl apply завершается до того, как поды запущены? Какие компоненты и в каком порядке узнают о новом Deployment и как именно — опросом или подпиской?
2. Чем отличается реакция контроллера «на уровень» от реакции «на фронт»? Приведите пример, когда второй подход привёл бы к неверному числу реплик.
3. В кластере etcd пять членов. Сколько из них может отказать без потери записи? Что изменится, если добавить шестой? Почему два члена хуже одного?
4. Service создан, ошибок нет, но запросы к нему отвергаются. Назовите три возможные причины и команду, которая первой отличит их друг от друга.
5. Почему вероятности в правилах statistic mode random для четырёх подов равны 0,25, 0,33 и 0,5, а не 0,25 каждая? Почему балансировка Service не перераспределяет уже открытые соединения?
6. Под в Pending с сообщением Insufficient cpu, хотя kubectl top nodes показывает загрузку процессора 10 %. Объясните противоречие.
7. Чем различаются последствия провала readinessProbe и livenessProbe? Почему проверка базы данных в livenessProbe превращает кратковременный отказ базы в длительный отказ сервиса?
8. Для replicas: 10, maxSurge: 25 %, maxUnavailable: 25 % найдите максимальное число подов и минимальное число доступных во время обновления. Почему readinessProbe обязательна для обновления без простоя и почему её одной недостаточно?
9. Узел выключили в 12:00:00. Когда при настройках по умолчанию начнут работать замены его подов? Какие два параметра определяют это время и почему по умолчанию выбрано не 10 секунд?
10. HPA: три реплики, запрос процессора 200m, цель 60 %, средняя загрузка 170m. Сколько реплик будет после следующего цикла? Что изменится, если загрузка 125m?
11. Что продолжает работать и что перестаёт работать в кластере, у которого недоступен сервер API? Почему зонд через Ingress пережил остановку сервера API, а kubectl exec — нет?
12. Ingress создан, но curl по имени хоста возвращает 404, а Service работает. Какие объекты и компоненты нужно проверить и в каком порядке?