DevOps 413

Если вы никогда не админили куб 🖼️ - вы, скорее всего, никогда не сталкивались с зеркальными подами. Но даже если админили - есть ряд объектов, с которыми вы не взаимодействовали напрямую. Я собрала свой список неочевидных абстракций, с которыми вы могли не сталкиваться или сталкивались, но не знаете, что это. 1️⃣. Finalizer

Это поле в метаданных любого ресурса. Пока оно не пустое - Kubernetes не удалит объект, даже если вы уже выполнили kubectl delete. Он просто висит в статусе Terminating и ждёт дополнительного события. Встречается в операторах и CRD - контроллер должен сначала почистить внешние ресурсы, и только потом разрешить удаление. Часто при мне начинающие инженеры спотыкались об него и ломали голову почему откат helm релиза завис 😅

2️⃣. Ephemeral container

Временный контейнер, который можно добавить в уже запущенный под без его перезапуска командой kubectl debug. Используется только для отладки - особенно когда основной образ собран на distroless и внутри нет ни bash, ни curl, вообще ничего. Добавляешь эфемерный контейнер с нужными инструментами, дебажишь, после удаляем. 3️⃣. Pause container Первый контейнер, который создаётся в каждом поде без исключения еще до старта основного. Он держит network и PID namespace для всех остальных контейнеров в поде. Именно поэтому все контейнеры в поде видят один и тот же localhost. Его можно увидеть в crictl ps как pause.

4️⃣. Sidecar container

Начиная с Kubernetes 1.29 - это уже не паттерн, а отдельный тип контейнера в поде (initContainer с restartPolicy: Always, init контейнер в отличие от Sidecar запускается только при старте пода один раз). Он стартует до основных контейнеров и живёт столько же, сколько под. Раньше так называли просто контейнер-компаньон рядом с основным - агент логов или рестарт сервис.

5️⃣. Static pod

По сути это контейнер, которым управляет kubeletнапрямую, читая манифест из директории на ноде и минуя контроллеры и kube-scheduler. И никакого управления через kube-api: вы не можете его удалить командой kubectl delete. Именно так, например, запущен kube-apiserver, что позволяет повысить его отказоустойчивость.

6️⃣. Mirror pod

Когда kubelet запускает static pod, он создаёт в API-сервере его "зеркальную" копию - mirror pod. Это readonly-представление: вы видите его через kubectl get pods. Если удалить такой под, то пропадет сам объект kube-api, но фактически контейнер статик пода будет продолжать работать.

7️⃣. PDB (Pod Disruption Budget)

Объект, который используется не так часто, как deployment. Он говорит кластеру: "не трогай больше N подов одновременно". Срабатывает при запланированных эвикциях (дрейн ноды, rolling update). Без PDB при kubectl drain все реплики вашего приложения могут упасть одновременно. С PDB - кластер подождёт, пока где-то поднимется новый под, и только потом продолжит.

8️⃣. Lease

Объект в группе coordination.k8s.io, механизм распределённой блокировки. Используется для leader election - когда у вас несколько реплик контроллера, но активно работать должна только одна. Именно через Lease kube-controller-manager и kube-scheduler выбирают лидера. Ещё kubelet обновляет свой Lease каждые несколько секунд - это его heartbeat, по которому API-сервер понимает, что нода жива.

9️⃣. EndpointSlice

Замена старому объекту Endpoint. Хранит маппинг сервиса на IP-адреса конкретных подов, но разбитый на слайсы по 100 записей. Появился потому, что в больших кластерах один Endpoints на сервис с тысячами подов - это огромный объект, который при каждом изменении перегружает etcd и сеть. EndpointSlice решает эту проблему. Когда трафик идёт не туда - идёте проверять именно его.

1️⃣0️⃣. SubjectAccessReview

API-объект для проверки RBAC-прав. Отправляешь запрос: "может ли пользователь X выполнить действие Y на ресурсе Z?" - получаешь yes/no. Именно это делает kubectl auth can-i под капотом. Полезно знать при написании операторов или admission webhook-ов, которым нужно самим проверять права перед тем, как что-то сделать.

Сколько пунктов из 10 тебе приходилось дебажить?) Мне семь 😅