MiddleДебаггингИногдаЕщё не отвечали

Плавающее обновление застряло на 2 из 5 реплик, новые Pod не становятся Ready — разберитесь.

Выкат не двигается уже несколько минут. Ниже — что вы видите. Объясните, почему он застрял (учитывая, что maxUnavailable мал), и как это чинить — не удаляя пробу и не масштабируя вверх.

$ kubectl rollout status deploy/api
Waiting for deployment "api" rollout to finish: 2 out of 5 new replicas updated...

$ kubectl get pods -l app=api
NAME             READY   STATUS    RESTARTS   AGE
api-7d9c-aaaa    0/1     Running   0          4m
api-7d9c-bbbb    0/1     Running   0          4m
api-5f8b-cccc    1/1     Running   0          2d

$ kubectl describe pod api-7d9c-aaaa
Readiness probe failed: HTTP probe failed with statuscode: 503
Get "http://10.1.2.3:8080/ready": dial context ... connection refused

Дайте диагноз и фикс.

Новые Pod Running, но 0/1 Ready — их readiness-проба отдаёт 503, и Deployment не выводит больше старых Pod: maxUnavailable ограничивает выкат, и он застревает. Чините причину readiness (зависимость, неверный path/port или малую задержку), а не число реплик. Если приложение медленно прогревается, добавьте startupProbe.

✗Поднимать реплики или ресурсы вместо починки сбоя readiness
✗Удалять readiness-пробу, чтобы силой завершить выкат
✗Путать падающую readiness-пробу с ошибкой скачивания образа

→Когда верный фикс — startupProbe, а когда — больший initialDelaySeconds?
→Как maxUnavailable: 0 меняет поведение этого зависшего выката?

Решение

Симптом — не креш, а застрявший выкат: старые Pod живы (1/1), новые Running, но 0/1 Ready.

connection refused на /ready. Новые Pod не готовы, значит Deployment не имеет права снять больше старых — maxUnavailable держит доступность, и выкат замирает по проекту.

Читаем причину: describe показывает Readiness probe failed ... 503 и
Чиним реальную причину readiness, а не число реплик:

зависимость (БД, конфиг) недоступна → эндпоинт честно отдаёт 503;
неверный path/port/схема пробы;
приложение просто медленно стартует, а initialDelaySeconds мал.

приложение поднимается), а не «долить ресурсов»:

Для медленного старта — startupProbe (гейтит liveness/readiness, пока

startupProbe:
  httpGet: { path: /ready, port: 8080 }
  failureThreshold: 30
  periodSeconds: 5

Если новая версия сломана по сути — kubectl rollout undo deploy/api.

Открыть тему в роадмапе →

Плавающее обновление застряло на 2 из 5 реплик, новые Pod не становятся Ready — разберитесь.

$ kubectl rollout status deploy/api
Waiting for deployment "api" rollout to finish: 2 out of 5 new replicas updated...

$ kubectl get pods -l app=api
NAME             READY   STATUS    RESTARTS   AGE
api-7d9c-aaaa    0/1     Running   0          4m
api-7d9c-bbbb    0/1     Running   0          4m
api-5f8b-cccc    1/1     Running   0          2d

$ kubectl describe pod api-7d9c-aaaa
Readiness probe failed: HTTP probe failed with statuscode: 503
Get "http://10.1.2.3:8080/ready": dial context ... connection refused

Дайте диагноз и фикс.

Решение

Симптом — не креш, а застрявший выкат: старые Pod живы (1/1), новые Running, но 0/1 Ready.

Читаем причину: describe показывает Readiness probe failed ... 503 и

Чиним реальную причину readiness, а не число реплик:

зависимость (БД, конфиг) недоступна → эндпоинт честно отдаёт 503;

неверный path/port/схема пробы;

приложение просто медленно стартует, а initialDelaySeconds мал.

приложение поднимается), а не «долить ресурсов»:

Для медленного старта — startupProbe (гейтит liveness/readiness, пока

startupProbe: httpGet: { path: /ready, port: 8080 } failureThreshold: 30 periodSeconds: 5

Если новая версия сломана по сути — kubectl rollout undo deploy/api.