Configuración de la política de actualización de carga de trabajo
En aplicaciones reales, la actualización es una operación común. Deployment, StatefulSet o DaemonSet pueden admitir fácilmente la actualización de la aplicación.
Puede establecer diferentes políticas de actualización:
- Rolling upgrade: Los pods nuevos se crean gradualmente y luego los pods antiguos se eliminan. Esta es la política predeterminada.
- Replace upgrade: Los pods actuales se eliminan y luego se crean nuevos pods.
Parámetros de actualización
- Max. Surge (maxSurge)
Especifica el número máximo de pods que spec.replicas puede existir. El valor predeterminado es 25%. Por ejemplo, si spec.replicas se establece en 4, no pueden existir más de 5 pods durante el proceso de actualización, es decir, el paso de actualización es 1. El número absoluto se calcula a partir del porcentaje redondeando al alza. El valor también se puede establecer en un número absoluto.
Este parámetro solo es compatible con Deployments.
- Max. Unavailable Pods (maxUnavailable)
Especifica el número máximo de pods que pueden no estar disponibles durante el proceso de actualización. El valor predeterminado es 25%. Por ejemplo, si spec.replicas se establece en 4 existen al menos 3 pods durante el proceso de actualización, es decir, el paso de eliminación es 1. El valor también se puede establecer en un número absoluto.
Este parámetro solo es compatible con Deployments.
- Min. Ready Seconds (minReadySeconds)
Un pod se considera disponible solo cuando se excede el tiempo mínimo de preparación sin que se bloquee ninguno de sus contenedores. El valor predeterminado es 0 (el pod se considera disponible inmediatamente después de que está lista).
- Revision History Limit (revisionHistoryLimit)
Especifica el número de ReplicaSets antiguas que se conservarán para permitir la reversión. Estas ReplicaSets antiguas consumen recursos en etcd y llenan la salida de kubectl get rs. La configuración de cada revisión de Deployment se almacena en su ReplicaSets. Por lo tanto, una vez que se elimina la ReplicaSet antigua, se pierde la capacidad de volver a esa revisión de la Deployment. Por defecto, se mantendrán 10 ReplicaSets antiguas, pero el valor ideal depende de la frecuencia y estabilidad de las nuevas implementaciones.
- Max. Upgrade Duration (progressDeadlineSeconds)
Especifica el número de segundos que el sistema espera a que una Deployment progrese antes de informar de un error de progreso de Deployment. Se presenta como una condición con Type=Progressing, Status=False y Reason=ProgressDeadlineExceeded en el estado del recurso. El controlador de Deployment seguirá reintentando la Deployment. En el futuro, una vez que se implemente la reversión automática, el controlador de Deployment revertirá una Deployment tan pronto como observe dicha condición.
Si se especifica este parámetro, el valor de este parámetro debe ser mayor que el de .spec.minReadySeconds.
- Scale-In Time Window (terminationGracePeriodSeconds)
Tiempo de eliminación elegante. El valor predeterminado es de 30 segundos. Cuando se elimina un pod, se envía una señal SIGTERM y el sistema espera a que terminen las aplicaciones en el contenedor. Si la aplicación no termina dentro del tiempo especificado por terminationGracePeriodSeconds se envía una señal SIGKILL para terminar por la fuerza el pod.
Ejemplo de actualización
La Deployment se puede actualizar en un modo declarativo. Es decir, solo necesita modificar la definición de YAML de la Deployment. Por ejemplo, puede ejecutar el comando kubectl edit para cambiar la imagen de Deployment a nginx:alpine. Después de la modificación, consulte el ReplicaSet y el pod. El resultado de la consulta muestra que se crea un nuevo ReplicaSet y se vuelve a crear el pod.
$ kubectl edit deploy nginx $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-6f9f58dffd 2 2 2 1m nginx-7f98958cdf 0 0 0 48m $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m nginx-6f9f58dffd-tesqr 1/1 Running 0 1m
La Deployment puede usar los parámetros maxSurge y maxUnavailable para controlar la proporción de pods que se van a recrear durante la actualización, lo que es útil en muchos escenarios. La configuración es la siguiente:
spec:
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
En el ejemplo anterior, el valor de spec.replicas es de 2. Si maxSurge y maxUnavailable son el valor predeterminado 25%, maxSurge permite que existan un máximo de tres pods (2 x 1.25 = 2.5, redondeado a 3), y maxUnavailable no permite que no estén disponibles un máximo de dos pods (2 x 0.75 = 1.5, redondeado a 2). Es decir, durante el proceso de actualización, siempre habrá dos pods en ejecución. Cada vez que se crea un nuevo pod, se elimina un pod antiguo hasta que todos los pods sean nuevos.
Retroceso
El retroceso consiste en revertir una aplicación a la versión anterior cuando se produce un error durante la actualización. Una Deployment se puede volver fácilmente a la versión anterior.
Por ejemplo, si la imagen actualizada es defectuosa, puede ejecutar el comando kubectl rollout undo para revertir la Deployment.
$ kubectl rollout undo deployment nginx deployment.apps/nginx rolled back
Una Deployment se puede revertir fácilmente porque utiliza un ReplicaSet para controlar un pod. Después de la actualización, el ReplicaSet anterior todavía existe. La Deployment se revierte mediante el ReplicaSet anterior para volver a crear el pod. El parámetro revisionHistoryLimit puede restringir el número de ReplicaSets almacenados en una Deployment. El valor predeterminado es 10.
