Деплой и инфра
K8s objects: тест с выбором ответа
Суть Синтез всего юнита K8s objects в формате выбора — reconciliation, иерархия объектов, селекторы Service, probes, ConfigMap/Secret и requests против limits.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих через весь юнит. Каждый — это решение, которое вы принимаете при написании манифеста или разборе сломанного раската: не определение для заучивания, а сценарий отказа, который нужно разобрать в продакшен-условиях.
Цель
Проверьте, что вы связываете воедино reconciliation loop, иерархию Pod→ReplicaSet→Deployment, селекторы Service, семантику probes, поведение ConfigMap/Secret и requests против limits — синтез, к которому вёл урок.
Викторина
Completed
Узел перезагружается и уносит с собой 3 из 5 подов Deployment. Никто не запускает никаких команд. Что восстанавливает количество и каков механизм?
Heads-up Reconciliation инкрементна: контроллер создаёт только 3 недостающих пода до desired count. Он не сносит и не перестраивает Deployment или его ReplicaSet.
Heads-up Это императивное мышление. Desired state (replicas: 5) уже хранится в кластере; контроллер навязывает его вечно без участия человека — в этом весь смысл декларативной оркестрации.
Heads-up Liveness перезапускает зависший контейнер на месте на живом узле. Замена подов, потерянных вместе с мёртвым узлом, — это reconciliation количества в ReplicaSet, что не зависит от probes.
Викторина
Completed
Джуниор запускает kubectl run debug --image=busybox для разового пода, и тот работает днями. Почему это всё равно неверно для всего, что должно оставаться поднятым?
Heads-up Голые Pod получают обычный Pod IP и полный доступ к сети. Проблема чисто в жизненном цикле: их никто не reconcile, поэтому они не переживают потерю узла или вытеснение.
Heads-up kubectl run по умолчанию не отключён; admission policy может его ограничить, но фундаментальная проблема в том, что у получившегося Pod нет владеющего контроллера для пересоздания.
Heads-up Голый Pod с подходящими метками попадает в endpoints Service как любой другой. Изъян — в долговечности, а не в выбираемости.
Викторина
Completed
Deployment задаёт selector app=web, и Service тоже выбирает app=web. Позже создаётся второй Deployment, чьи поды тоже несут app=web. Что происходит с трафиком?
Heads-up Селекторы никогда не ошибаются при пересечении; Kubernetes просто перечисляет каждый подходящий Pod IP в объекте Endpoints. Пересекающиеся метки — частый источник случайного смешения трафика, а не жёсткий отказ.
Heads-up Порядок создания не важен. Селектор вычисляется по текущим меткам подов на каждом reconcile; любой под с app=web — endpoint независимо от того, какой Deployment его породил.
Heads-up Такой Service не перечисляет поды или IP — он выбирает динамически по метке. Жёстко прописанные Pod IP ломались бы при каждом перезапуске, ради чего и существуют селекторы.
Викторина
Completed
Приложению нужно ~25с на прогрев (загрузка config + прогрев пула) до готовности обслуживать, и спустя часы оно иногда зависает. Команда добавляет только это: ```yaml livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 ``` Раскаты всё ещё дают всплески 500. Почему и чего не хватает?
Heads-up 30с покрывают прогрев в 25с, а всплески 500 на раскате происходят всё равно. Реальный пробел в том, что liveness вообще не гейтит трафик — для удержания пода вне Service до готовности нужен readiness probe.
Heads-up Путь в порядке. Даже корректный liveness-путь не чинит всплески 500 на раскате, потому что liveness перезапускает поды — он не решает членство в endpoints. Это делает readiness.
Heads-up Они различны: liveness перезапускает зависший под, readiness выводит ещё-не-обслуживающий под из ротации Service. Использование liveness там, где нужен readiness, — классический отказ раската.
Викторина
Completed
Вы обновляете ConfigMap, потребляемый как env-переменные работающим Deployment: ```yaml envFrom: - configMapRef: { name: app-config } ``` Новое значение не доходит до подов даже спустя часы. Корневая причина и стандартное исправление?
Heads-up Объект ConfigMap обновился. Проблема в распространении: env читаются один раз при старте контейнера и не обновляются, поэтому работающие поды держат старые значения до перезапуска.
Heads-up Ни у ConfigMap, ни у Secret env не делают hot-reload; оба заморожены при старте. Rollout restart работает, но команды автоматизируют это, хешируя config в аннотацию, чтобы сам apply триггерил раскат.
Heads-up envFrom полностью поддерживается. Смонтированные томом ConfigMap со временем обновляют проецируемые файлы, но env никогда не обновляются — и даже файлы не перезапускают процесс, так что приложения должны их перечитывать.
Викторина
Completed
Чувствительный к задержкам сервис задаёт: ```yaml resources: requests: { cpu: 250m, memory: 256Mi } limits: { cpu: 500m, memory: 256Mi } ``` Под нагрузкой видны периодические всплески задержек и редкий OOMKill. Каковы два разных механизма и какая ручка опаснее?
Heads-up Память несжимаема — её нельзя троттлить. Превышение memory limit вызывает OOMKill, а не замедление. Троттлится только CPU через квоту CFS.
Heads-up Requests — для планирования и гарантированной доли, они не троттлят. Лимит CPU задаёт потолок троттлинга; лимит памяти задаёт потолок OOM. Requests напрямую не влияют ни на один потолок.
Heads-up Равные request/limit для памяти дают класс QoS Guaranteed — обычно желательный. OOMKill приходит от фактического потребления сверх limit, а не от совпадения значений; исправление — больший limit или меньшее потребление памяти.
Итог
Сквозная линия юнита — одна модель: вы объявляете desired state, и контроллеры вечно reconcile actual к нему — поэтому Deployment самовосстанавливается, а голый Pod нет. Иерархия добавляет по одной задаче на слой (Pod гоняет контейнеры, ReplicaSet держит count, Deployment катит и откатывает), Service выбирают поды по метке в набор Endpoints без понятия о владении, probes делятся на readiness (гейтит трафик) и liveness (перезапускает), изменения ConfigMap/Secret никогда не катят автоматически, а ресурсы делятся на CPU (троттлится, сжимаем) и память (OOMKill, несжимаема). Каждый продакшен-отказ здесь сводится к одной из этих семантик.