Код в мешке

🎓 Собеседование сисадмина. Выпуск #12: Kubernetes — то, что спрашивают в 2026 году

Коллеги! Продолжаем марафон. После выпуска про распределённые хранилища (Ceph, Longhorn) логичный следующий шаг — оркестрация. В 2026-м Kubernetes перестал быть "DevOps-штучкой" и стал стандартной частью инфраструктуры даже в небольших компаниях. А значит, сисадмин, который не понимает K8s, — это уже не сисадмин, это билет на понижение.

Три вопроса, на которых плывут даже те, кто "работает с кубером каждый день".

---

❓ Вопрос 1: «Pod завис в статусе CrashLoopBackOff. Ваши действия?»

❌ Ответ новичка: «Удалю pod и пересоздам, он же сам поднимется».

✅ Ответ инженера:
CrashLoopBackOff означает, что контейнер запускается, падает, Kubernetes пытается его поднять снова — и так по кругу. Задача: найти причину, а не перезапускать вслепую.

Алгоритм траблшутинга:


# Шаг 1 — Смотрим текущие логи
kubectl logs <pod-name> -n <namespace>

# Если контейнер упал слишком быстро — логи уже улетели.
# Берём логи предыдущего запуска:
kubectl logs <pod-name> -n <namespace> --previous

# Шаг 2 — Описание pod: ищем Reason в Last State
kubectl describe pod <pod-name> -n <namespace>
# Смотрим секцию "Last State" и "Events"
# Причины бывают разные:
#   OOMKilled     -> контейнер убит за превышение лимита памяти
#   Error (exit 1) -> приложение упало само (ошибка конфига/зависимость)
#   RunContainerError -> не может стартовать (нет образа, нет прав на том)

# Шаг 3 — Если OOMKilled: смотрим лимиты и правим манифест
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'
# Временно поднимаем memory limit, чтобы убедиться в диагнозе:
# resources.limits.memory: 512Mi -> 1Gi

# Шаг 4 — Проверяем ConfigMap и Secret: существуют ли они в этом namespace?
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>
# Если приложение не может найти конфиг — оно упадёт с exit code 1

Ключевая мысль: Удалить и пересоздать pod — это лечить симптом, не болезнь. Kubernetes и сам это делает. Ваша работа — понять, почему падает.

---

❓ Вопрос 2: «В чём разница между Liveness Probe и Readiness Probe? Что будет, если их перепутать?»

❌ Ответ новичка: «Оба проверяют здоровье контейнера. Liveness — жив ли, Readiness — готов ли».

✅ Ответ инженера:
Определение правильное, но поверхностное. Интервьюер ждёт понимания последствий.

Liveness Probe — отвечает на вопрос "не завис ли процесс?". Если проверка провалилась — Kubernetes убивает контейнер и перезапускает его. Используется, чтобы выйти из дедлоков и зависаний.

Readiness Probe — отвечает на вопрос "можно ли слать трафик?". Если проверка провалилась — pod убирается из балансировки Service, но не перезапускается. Используется при старте, когда приложение ещё прогревается (warm-up, загрузка кэша).

Что будет если перепутать:


# ПЛОХОЙ пример: Liveness смотрит на /ready (страница прогрева)
# При старте приложению нужно 30 секунд на инициализацию БД.
# Liveness видит 503 -> убивает контейнер -> перезапускает -> снова 503
# -> бесконечный CrashLoopBackOff на старте.

# ПРАВИЛЬНАЯ конфигурация:
livenessProbe:
  httpGet:
    path: /healthz      # Легкая проверка: "процесс жив?"
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready        # Тяжелая проверка: "готов принимать трафик?"
    port: 8080
  initialDelaySeconds: 20 # Даём время на прогрев
  periodSeconds: 5
  failureThreshold: 2

Pro-tip для собеса: Добавьте, что в 2026 году есть ещё Startup Probe — третий вид. Он запускается только при старте контейнера и блокирует Liveness/Readiness до тех пор, пока приложение не стартует успешно. Идеален для тяжёлых Java- и .NET-приложений с долгой инициализацией.

---

❓ Вопрос 3: «Kubernetes Secrets хранят пароли. Насколько они безопасны "из коробки"?»

❌ Ответ новичка: «Secrets зашифрованы, поэтому безопасны».

✅ Ответ инженера:
Это самая распространённая ошибка на собесах. Secrets "из коробки" — это НЕ шифрование.

5 views13:00