Kubernetes

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

Эта тема проходит весь стек в том порядке, в котором его прощупывают на собеседовании. Начинаем с базовых объектов и цикла управления, поднимаемся через контроллеры нагрузок, которые владеют вашими подами, затем разбираем, как поды размещаются, соединяются, получают хранилище и запираются, — и заканчиваем набором сигнатур отказов, к которому тянешься, когда всё ломается в три часа ночи.

Карта темы

• Базовые объекты и цикл согласования — Pod как эфемерная единица планирования, Deployment → ReplicaSet → Pod, декларативное согласование, VIP у Service и компоненты control plane.
• Ворклоады — Deployment против StatefulSet, DaemonSet и Job/CronJob, плавающие обновления и откат, пробы, requests против limits и QoS.
• Планирование и ресурсы — фильтрация/оценка узлов, taints, которые отталкивают, против affinity, который притягивает, распределение по топологии, priority/preemption и бюджеты нарушений.
• Сеть — маршрутизируемый IP на каждый под, типы Service, kube-proxy, Ingress, CNI, CoreDNS и NetworkPolicy.
• Хранилище — треугольник PV/PVC/StorageClass, access modes на уровне узла, reclaim policy и тома StatefulSet.
• Безопасность — RBAC по минимуму прав, токены ServiceAccount, Pod Security Standards, SecurityContext и почему Secret — это не шифрование.
• Диагностика — набор сигнатур отказов: CrashLoopBackOff, ImagePullBackOff, Pending, OOMKilled, 503 от Ingress и зависшие выкаты.

Частые ошибки и ловушки

Значение для собеседований

Kubernetes — это место, где собеседование по DevOps перестаёт проверять память и начинает проверять вашу модель распределённой системы управления. Кандидат, который говорит «я объявляю желаемое состояние, а контроллеры его согласуют», отвечает на десяток уточнений разом; тот, кто перечисляет команды, спотыкается на первом «почему».

Что обычно проверяют:

• Почему Pod — единица планирования и что пересоздаёт его при падении.
• Откуда берётся стабильный адрес и как Service находит свои поды.
• Что на самом деле делает плавающее обновление и как его откатить.
• Как прочитать Pending, CrashLoopBackOff и OOMKilled из kubectl describe/logs.

Типичный неверный ответ: «Kubernetes перезапустит мой под при падении». Голый под никогда не переносится на другой узел — контроллер (Deployment, StatefulSet, DaemonSet) замечает недостачу и создаёт замену. В этом различии и весь смысл модели объектов.