Probes и лимиты ресурсов

Три probe, отвечающие на три разных вопроса

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

Kubernetes не считает запущенный контейнер работающим. Он спрашивает, раз за разом, через probes — и тип probe решает, что произойдёт, когда ответ «нет». Путаница между ними — главный источник самонанесённых аварий в этом уроке.

Readiness спрашивает может ли этот под обслуживать трафик прямо сейчас? Когда она падает, Kubernetes убирает под из endpoints’ов Service — трафик к нему прекращается, — но контейнер не рестартит. Под остаётся живым, просто вне ротации, и возвращается в момент, когда readiness снова проходит. Это гейт для роллаутов (новый под не получает трафик, пока реально не готов) и для временной перегрузки (под под давлением GC может сбросить трафик, не умирая). Сделай readiness отражающей реальную готовность: приложение забиндило порт, прогнало миграции и подтвердило, что критичные зависимости достижимы.

Liveness спрашивает жив ли ещё этот контейнер, или он завис? Когда она падает (за порогом), Kubernetes рестартит контейнер. Она существует ради одной задачи: восстановление из неустранимых состояний — дедлок, event loop, который перестал крутиться, утечка памяти, подвесившая процесс. Liveness — это кувалда. Если медленное-но-здоровое приложение или временный сбой зависимости её триггерит, ты получаешь тот самый restart loop из хука.

Startup спрашивает закончил ли этот контейнер загрузку? Она бежит первой; пока она падает, liveness и readiness probes полностью придержаны. Как только startup прошла один раз, она больше не запускается, и две другие берут управление. Это правильный щит для медленно стартующих приложений — старых JVM, всего с долгим прогревом, — чтобы держать liveness агрессивной для рантайм-сбоев, не давая ей убивать приложение во время старта.

containers:
- name: api
  image: registry.example.com/api:1.4.0
  startupProbe:            # щит старта: до 30 × 10s = 5 мин на оживление
    httpGet: { path: /healthz, port: 8080 }
    periodSeconds: 10
    failureThreshold: 30
  readinessProbe:          # гейт трафика; падение убирает из Service, без рестарта
    httpGet: { path: /ready, port: 8080 }
    periodSeconds: 5
    failureThreshold: 3
  livenessProbe:           # рестарт, если завис; падение убивает + рестартит контейнер
    httpGet: { path: /healthz, port: 8080 }
    periodSeconds: 10
    failureThreshold: 3

requests и limits: планирование против жёсткого потолка

У ресурсов два числа на контейнер, и они делают совершенно разную работу.

requests — это то, что поду гарантировано, и то, что планировщик использует для размещения: Kubernetes поставит под только на ноду, у которой свободно как минимум requests.cpu и requests.memory (суммарно по ноде). Это резервирование, а не потолок. Ставь requests на типичное, устойчивое потребление контейнера.

limits — это жёсткий потолок, который контейнер не может превысить в рантайме, — и то, что происходит при попытке, люди понимают неправильно, потому что CPU и память ведут себя противоположно:

• CPU сверх лимита → throttling, не убийство. CPU сжимаемый. Превысишь limits.cpu — и CFS-планировщик ядра (Completely Fair Scheduler — планировщик процессорного времени Linux) просто даёт контейнеру меньше тайм-слотов; приложение продолжает работать, но становится медленным. Заниженный CPU-лимит проявляется как загадочная латентность, а не как падения.
• Память сверх лимита → OOMKilled. Память несжимаема — нельзя дать процессу «меньше» RAM, чем он уже выделил. Превысишь limits.memory — и OOM-киллер ядра завершает контейнер с кодом выхода 137; ты видишь OOMKilled и рестарт. Заниженный лимит памяти проявляется как падения, а не как медлительность.

resources:
  requests:        # гарантия + планирование — ставь ≈ типичное потребление
    cpu: "250m"
    memory: "256Mi"
  limits:          # жёсткий потолок — защищает ноду от убежавшего контейнера
    cpu: "1"       # сверху → throttling CFS (медленно, не убит)
    memory: "512Mi"  # сверху → OOMKilled (выход 137, контейнер рестартит)

Правило сеньора: ставь requests ≈ типичное, чтобы планировщик честно паковал ноду, и ставь limits достаточно высоко, чтобы поглотить всплески, но достаточно низко, чтобы защитить ноду. Дальше следи за двумя сигналами сбоя — повторяющийся OOMKilled означает, что лимит памяти слишком низок (или есть утечка); устойчивый CPU throttling означает, что CPU-лимит слишком низок. Настраивай по реальным метрикам, а не по догадкам.

QoS-классы решают, кто умрёт первым

Соотношение requests и limits тихо назначает каждому поду класс качества обслуживания (QoS), и этот класс задаёт порядок вытеснения, когда у ноды кончается память:

• Guaranteed — у каждого контейнера requests == limits и по CPU, и по памяти. Вытесняется последним. Используй для критичных по латентности, stateful-нагрузок.
• Burstable — задан хотя бы один request, но не равный limits (частый случай). Вытесняется после BestEffort, в порядке того, насколько он вышел за свои requests.
• BestEffort — никаких requests и limits вообще. Первый на вытеснение, первый на OOM-kill под давлением ноды. Годится только для одноразовой batch-работы.

Все три класса вместе означают, что судьбу pod-а решает не только планировщик — OOM-киллер ядра тоже, и он использует класс, чтобы выбрать, кто умрёт первым. Без явных requests и limits ты случайно получаешь BestEffort, что делает твой pod первой жертвой при всплеске «шумного соседа».