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

Быстрый и рекомендуемый способ

kubectl rollout restart deployment/<deployment-name> -n <namespace>

Что делает: обновляет аннотацию в spec.template.metadata, что воспринимается как изменение PodTemplate — Kubernetes создаёт новые ReplicaSet/Pods и последовательно заменяет старые в соответствии со стратегией развёртывания (rolling update). Безопасно для production, если у вас корректно настроены readinessProbe, maxUnavailable/maxSurge.

Через патч (аналогично предыдущему, вручную меняем шаблон Pod)

# Bash — добавляет метку с текущим временем в шаблон Pod

kubectl patch deployment my-deploy -n production \\
\-p "{\\"spec\\":{\\"template\\":{\\"metadata\\":{\\"annotations\\":{\\"restartedAt\\":\\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\\"}}}}}" --type=merge

Когда полезно: если нужен более тонкий контроль, или kubectl rollout restart недоступен. Результат тот же — изменение шаблона запускает обновление.

Масштабирование «вручную» (scale down → scale up)

# Узнать текущие реплики

kubectl get deployment my-deploy -n production -o jsonpath='{.spec.replicas}'

# Сохранив число, уменьшить/увеличить:

kubectl scale deployment my-deploy -n production --replicas=0

# затем вернуть предыдущее значение, например 3

kubectl scale deployment my-deploy -n production --replicas=3

Минусы/плюсы: простой метод, но при уменьшении до 0 вы вызовете простой сервиса. Подходит для не-критичных окружений или когда хотите полностью перезапустить все Pod.

Удаление конкретного Pod (контроллер сам создаст новый)

kubectl delete pod <pod-name> -n <namespace>

Что происходит: Deployment (ReplicaSet) заметит недостачу реплик и создаст новый Pod с тем же шаблоном. Можно удалять отдельные Pod для быстрого «перезапуска» одного инстанса. Не удаляйте все Pod одновременно, если это приведёт к простою.

Дополнительно: удалить по меткам (несколько Pod):

kubectl delete pods -l app=myapp -n production

Осторожно: удаление всех Pod одним махом может привести к потере доступности.

Агрессивное принудительное завершение (обычно не нужно)

kubectl delete pod <pod-name> --grace-period=0 --force -n <namespace>

Использовать только если Pod “завис” и не завершается корректно. Это убирает корректную остановку (postStop и т.д.), может привести к потерям данных.

Проверка статуса обновления и отладки

kubectl rollout status deployment/my-deploy -n production
kubectl rollout history deployment/my-deploy -n production
kubectl get pods -n production -l app=myapp
kubectl get pods -n production -w -l app=myapp # следить в реальном времени
kubectl describe pod <pod-name> -n production # увидеть события и причины рестартов

Важные замечания

• Большинство способов просто изменяют шаблон Pod или удаляют существующий Pod; Deployment/ReplicaSet затем создает новый Pod по шаблону.

• kubectl rollout restart аккуратно уважает стратегию развёртывания (не убьёт все Pod сразу при правильной конфигурации).

• Перед перезапуском убедитесь, что у вас настроены readinessProbe и livenessProbe, чтобы новые pod не попадали в трафик до готовности.

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

• Если операция «застряла», посмотрите kubectl describe deployment и kubectl describe rs, а также логи проблемных Pod.

Полезные команды для быстрого выполнения

kubectl rollout restart deployment/my-deploy -n production
kubectl rollout status deployment/my-deploy -n production
kubectl delete pod my-deploy-abcdef123 -n production
kubectl get pods -n production -l app=myapp -o wide