Практика Kubernetes: от Pending до рабочего релиза

Вы задеплоили приложение, но адрес не открывается. Можно начать менять Service, перезапускать Pod и переустанавливать ingress-контроллер. А можно сначала выяснить, до какого места вообще дошёл запуск. Эта подборка устроена по второму принципу: от появления процесса до выпуска новой версии. Выберите этап, на котором остановилось ваше приложение, и переходите к разбору конкретного симптома.

Как работать с подборкой

Для упражнений подойдёт отдельный учебный кластер и маленький HTTP-сервис, который вы уже умеете собирать в Docker. Сохраните рабочие манифесты в Git. Меняйте одну настройку за раз и записывайте, что изменилось в состоянии ресурсов. Так после упражнения останется понятный способ диагностики, а не только исправленный YAML.

Ниже — статьи с объяснениями и примерами. Практические эксперименты выполняются в вашем учебном окружении; это не встроенный автоматический экзамен.

1. Контейнер ещё не начал работать

Здесь важно различить три события: Pod создан, место для него найдено, образ скачан. У каждого сбоя свой источник сведений. Начните с событий и причины ожидания, прежде чем менять конфигурацию приложения.

• Pod завис в Pending: как читать события и найти нехватку ресурсов
• ImagePullBackOff: проверяем имя образа, доступ к registry и imagePullSecrets
• PVC остался Pending: StorageClass, provisioner и WaitForFirstConsumer

2. Процесс запущен, но запрос не проходит

Проверьте путь запроса по частям: процесс, выбранные Service endpoints, порт, внешний вход. Отдельно разберите DNS и сетевые правила. Полезное упражнение — намеренно испортить selector и объяснить, почему живой Pod не делает Service доступным.

• Service в Kubernetes не отвечает: проверяем selector и EndpointSlice
• Ingress возвращает 502: проверяем путь от контроллера до приложения
• DNS в Kubernetes отвечает медленно: проверяем CoreDNS, search и ndots
• NetworkPolicy закрыла исходящий трафик: как сохранить DNS и нужные подключения

3. Приложение работает нестабильно

Лимит памяти, ограничение CPU и неудачная проверка готовности дают разные симптомы. Для каждого случая сопоставьте настройки, состояние контейнера и поведение приложения. Не пытайтесь вылечить все три случая одним увеличением ресурсов.

• OOMKilled в Kubernetes: отделяем лимит контейнера от нехватки памяти узла
• CPU throttling в Kubernetes: почему приложение тормозит при свободном CPU
• Readiness, liveness и startup: почему перезапуск мешает приложению запуститься

4. Изменения должны доходить предсказуемо

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

• ConfigMap обновился, а приложение видит старое значение: env, volume и перезапуск
• RollingUpdate: как maxSurge и maxUnavailable влияют на доступность и ресурсы
• Job в Kubernetes выполняется повторно: backoffLimit, restartPolicy и побочные действия
• Drain узла остановился на PodDisruptionBudget: как разобраться в ограничении
• Forbidden в Kubernetes: проверяем ServiceAccount, Role и RoleBinding

Соберите результат в одну рабочую процедуру

Соберите небольшой отчёт по своему сервису: как проверить доступность новой версии, где искать причину неготовности, как заметить нехватку ресурсов и что делать при неудачном обновлении. Если каждый ответ подкреплён наблюдением из кластера, вы уже можете обсуждать релиз предметно.

Продолжить обучение

Для последовательной работы с кластером посмотрите программу курса Kubernetes с нуля до PRO. На странице курса — программа, условия доступа и покупки. Сопоставьте их со своей ближайшей рабочей задачей.

Если пока не хватает базы или нужен соседний инструмент, выберите другой маршрут в путеводителе по практике DevOps.