Выкат Deployment деградировал с ProgressDeadlineExceeded — разберите застой.
Плавающее обновление застряло: kubectl rollout status завершается с ошибкой, а Deployment показывает ProgressDeadlineExceeded. Объясните, что значит это условие, почему сосуществуют старые и новые поды и как найти корневую причину.
$ kubectl rollout status deploy/api
Waiting for deployment "api" rollout to finish: 2 of 5 updated replicas are available...
error: deployment "api" exceeded its progress deadline
$ kubectl describe deploy api | sed -n '/Conditions/,/Events/p'
Type Status Reason
Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
$ kubectl get pods -l app=api
api-new-1 0/1 Running 0 6mДиагностируйте и исправьте.
ProgressDeadlineExceeded значит, что новый ReplicaSet не набрал Ready-подов за progressDeadlineSeconds; выкат застывает, сам не откатывается, а maxUnavailable держит старые поды. Опишите новый под — обычно readiness, ImagePull, ёмкость или PDB.
- ✗Ждать, что
ProgressDeadlineExceededсам откатит, а не застынет - ✗Не описывать новый под, чтобы понять, почему он не Ready
- ✗Упускать readiness, ImagePull, ёмкость и PDB как обычные причины
- →Как
maxUnavailableиmaxSurgeформируют, что остаётся доступным при застое? - →Когда
kubectl rollout undoуместнее, чем чинить новые поды вперёд?
Решение
1. Что значит условие
Progressing = False, ProgressDeadlineExceeded — контроллер Deployment ждал, но новый ReplicaSet не набрал нужного числа Ready-подов за progressDeadlineSeconds (по умолчанию 600s). Это застой, а не откат: Kubernetes сам назад не катит.
2. Почему старые и новые вместе
RollingUpdate соблюдает maxUnavailable/maxSurge: старые поды не удаляются, пока новые не станут Ready. Отсюда Available True (сервис жив на старых), но Progressing False (новые не поднялись).
3. Корневая причина — по новому поду
$ kubectl describe pod api-new-1 | sed -n '/Events/,$p'
Warning Unhealthy kubelet Readiness probe failed: HTTP 500 on /healthЧастые причины: readiness не проходит (как здесь), ImagePullBackOff, нет ёмкости (FailedScheduling), PDB не даёт вытеснить старые. Фикс: устранить причину у новых подов — выкат продолжится сам; либо kubectl rollout undo deploy/api.
