Forzar un despliegue de k8s/helm a recrear pods
En algunos casos al actualizar un pod que tiene un PVC adjunto que no permite ReadWriteMany
, kubernetes empieza a crear el nuevo pod pero como no puede adjuntarlo al PVC ya que el pod que queremos actualizar ya está adjunto a a dicho PVC, el nuevo pod se queda en estado ContainerCreating
.
Esto puede ocurrir por estar utilizando una estrategia de despliegue RollingUpgrade
. En los casos en que un pequeño tiempo de "down-time" no es un problema, podemos resolver este problema mediante el uso de la estrategia Recreate
.
Para ello, en Helm el valor de updateStrategy
debe cambiarse de:
updateStrategy:
type: RollingUpdate
rollingUpdate: {}
a:
updateStrategy:
type: Recreate
rollingUpdate: null
En cambio, en un manifesto de despliegue de kubernetes, en lugar de cambiar la clave updateStrategy
, debemos cambiar la clave strategy
como se puede ver en el siguiente ejemplo:
strategy:
type: RollingUpdate
rollingUpdate: {}
to:
strategy:
type: Recreate
rollingUpdate: null
Tenga en cuenta que si el valor de rollingUpdate
no se actualiza a null
, se producirá el siguiente error:
Error: UPGRADE FAILED: cannot patch "helm-deployment-example" with kind Deployment: Deployment.apps "helm-deployment-example" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
Tenga en cuenta también que hasta la versión helm 2, el argumento
--recreate-pods
también se podía utilizar para lograr el mismo resultado, pero a partir de la versión 3, ha quedado obsoleta.