Sin reinicios ni interrupciones: actualiza recursos de pods con In-Place Resizing

La funcionalidad InPlacePodVerticalScaling viene habilitada por defecto en clusters con la versión v1.33. Puedes activarla explícitamente en un cluster de minikube con el siguiente comando, o habilitar este feature gate en tu cluster de Kubernetes administrado si aún no está activo por defecto.

minikube start --feature-gates=InPlacePodVerticalScaling=true

Vamos a desplegar un pod de muestra en el cluster. El nuevo restartPolicy en el spec del pod le da al usuario el control sobre cómo se manejan sus contenedores cuando se redimensionan los recursos.

En la siguiente configuración de pod de ejemplo para recursos de memoria, el resizePolicy indica que los cambios en la asignación de memoria requieren reiniciar el contenedor, mientras que para los recursos de CPU no hace falta reiniciar durante el redimensionamiento.

Que un contenedor se reinicie o no depende de si la aplicación puede usar el recurso actualizado sin reinicio. Por ejemplo, si el uso de memoria de una aplicación es crítico para su funcionamiento, reiniciar el contenedor cuando cambia la memoria asegura que la aplicación arranque con la cantidad correcta. Este paso ayuda a prevenir posibles problemas o fallos.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    resizePolicy:
    - resourceName: "memory"
      restartPolicy: "RestartContainer"
    - resourceName: "cpu"
      restartPolicy: "NotRequired"
    resources:
      limits:
        cpu: "300m"
        memory: "1Gi"
      requests:
        cpu: "100m"
        memory: "500Mi"
EOF

Espera a que el pod pase a estado running y revisa su configuración. Se agregó un nuevo campo allocatedResources dentro de containerStatuses en el status del pod, que refleja los recursos del nodo asignados actualmente a los contenedores.

Además, se sumó un nuevo campo resources al status del contenedor, que refleja las requests y limits reales configurados en los contenedores en ejecución, según lo que reporta el container runtime.

Redimensionamiento de CPU

Ajustemos los recursos de CPU del pod con el siguiente comando patch y observemos la operación de redimensionamiento. Ahora, los recursos de un Pod deben modificarse a través del subrecurso resize; las versiones de kubectl v1.32+ admiten este argumento.

kubectl patch pod nginx --subresource resize --patch '{"spec": {"containers": [{"name":"nginx", "resources":{"requests": {"cpu" :"300m"},"limits": {"cpu" :"500m"}}}]}}'

El estado de una operación de redimensionamiento se expone mediante dos condiciones del Pod:

• PodResizePending: indica que Kubelet no puede aplicar el redimensionamiento de inmediato (por ejemplo, reason: Deferred si no es posible temporalmente, o reason: Infeasible si es imposible en el nodo).
• PodResizeInProgress: indica que el redimensionamiento fue aceptado y se está aplicando. Los errores que surjan en esta fase se reportan en el mensaje de esta condición con reason: Error.

La comunidad mejoró el Pod Lifecycle Event Generator (PLEG) de Kubelet, lo que le permite responder y completar redimensionamientos con mayor rapidez en beta. Aun así, en ocasiones el redimensionamiento de un pod puede toparse con una condición de carrera frente a otras actualizaciones del pod. Esto puede demorar la activación del redimensionamiento y hacer que los recursos actualizados del contenedor tarden un poco en reflejarse en el status del pod.

Redimensionamiento de memoria

Sigamos con los ajustes del recurso Memory; el contenedor se reiniciará según el restartPolicy.

kubectl patch pod nginx --subresource resize --patch '{"spec": {"containers": [{"name":"nginx", "resources":{"requests": {"memory" :"700Mi"}}}]}}'

La captura muestra la finalización exitosa de la operación de redimensionamiento y el reinicio del contenedor 🚀.