Eso es lo que hago:

1. Implementar un conjunto con estado. El pod siempre saldrá con un error para provocar un pod fallido en el estado CrashLoopBackOff : kubectl apply -f error.yaml
2. Cambie error.yaml ( echo a => echo b ) y vuelva a implementar el conjunto con estado: kubectl apply -f error.yaml
3. El pod mantiene el estado de error y no se volverá a implementar inmediatamente, sino que esperará hasta que el pod se reinicie después de un tiempo.

Solicitud de estado del pod:

 $ kubectl get pod errordemo-0 NAME READY STATUS RESTARTS AGE errordemo-0 0/1 CrashLoopBackOff 15 59m

error.yaml

 apiVersion: apps/v1 kind: StatefulSet metadata: name: errordemo labels: app.kubernetes.io/name: errordemo spec: serviceName: errordemo replicas: 1 selector: matchLabels: app.kubernetes.io/name: errordemo template: metadata: labels: app.kubernetes.io/name: errordemo spec: containers: - name: demox image: busybox:1.28.2 command: ['sh', '-c', 'echo a; sleep 5; exit 1'] terminationGracePeriodSeconds: 1

Preguntas

¿Cómo puedo lograr una reimplementación inmediata incluso si el pod tiene un estado de error? Descubrí estas soluciones, pero me gustaría tener un solo comando para lograrlo (en la vida real, estoy usando helm y solo quiero llamar a helm upgrade para mis implementaciones):

• Mata a la vaina antes de la redistribución
• Reduzca la escala antes de volver a implementar
• Eliminar el statefulset antes de volver a implementar

¿Por qué Kubernetes no vuelve a implementar el módulo de inmediato?

• En mi ejemplo de demostración, tengo que esperar hasta que Kubernetes intente reiniciar el módulo después de esperar un tiempo.
• Un pod sin error (por ejemplo echo a; sleep 10000; ) se reiniciará inmediatamente. Es por eso que establecí terminationGracePeriodSeconds: 1
• Pero en mis implementaciones reales (donde uso helm) también encontré el caso de que las cápsulas nunca se vuelven a implementar. Desafortunadamente, no puedo reproducir este comportamiento en un ejemplo simple.