Redimensionnez vos pods à chaud, sans redémarrage ni interruption

La fonctionnalité InPlacePodVerticalScaling est activée par défaut dans les clusters en v1.33. Vous pouvez l'activer explicitement dans un cluster minikube via la commande suivante, ou activer la feature gate correspondante dans votre cluster Kubernetes managé si elle ne l'est pas déjà.

minikube start --feature-gates=InPlacePodVerticalScaling=true

Déployons un pod d'exemple sur le cluster. La nouvelle restartPolicy dans la spec du pod permet de contrôler la manière dont les conteneurs sont gérés lors d'un redimensionnement de ressources.

Dans la configuration ci-dessous, la resizePolicy indique que toute modification de l'allocation mémoire impose un redémarrage du conteneur, alors qu'aucun redémarrage n'est requis pour les ressources CPU.

Le choix de redémarrer ou non un conteneur dépend de la capacité de l'application à exploiter la nouvelle ressource sans redémarrage. Par exemple, si la consommation mémoire est critique pour le bon fonctionnement de l'application, redémarrer le conteneur lors d'un changement de mémoire garantit qu'elle démarre avec la bonne quantité allouée. C'est une précaution qui évite bien des problèmes ou dysfonctionnements.

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

Attendez que le pod passe à l'état running, puis examinez sa configuration. Un nouveau champ allocatedResources apparaît dans containerStatuses au sein du statut du pod : il reflète les ressources de nœud actuellement allouées aux conteneurs.

Un autre champ, resources, a également été ajouté au statut du conteneur. Il reflète les requests et limits effectivement configurés sur les conteneurs en cours d'exécution, tels que remontés par le runtime de conteneurs.

Redimensionnement CPU

Ajustons les ressources CPU du pod avec la commande patch suivante et observons l'opération. La modification des ressources d'un pod passe désormais obligatoirement par la sous-ressource resize ; les versions kubectl v1.32+ prennent cet argument en charge.

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

Le statut d'une opération de redimensionnement est désormais exposé via deux conditions de pod :

• PodResizePending : indique que Kubelet ne peut pas appliquer le redimensionnement immédiatement (par ex. reason: Deferred en cas d'impossibilité temporaire, reason: Infeasible si l'opération est impossible sur le nœud).
• PodResizeInProgress : indique que le redimensionnement est accepté et en cours d'application. Les erreurs rencontrées durant cette phase sont désormais remontées dans le message de cette condition avec reason: Error.

La communauté a amélioré le Pod Lifecycle Event Generator (PLEG) de Kubelet, ce qui lui permet de réagir et de finaliser les redimensionnements plus vite en bêta. Cela dit, le redimensionnement d'un pod peut parfois entrer en concurrence avec d'autres mises à jour de pods. Résultat : un certain délai avant l'activation du redimensionnement et la mise à jour des ressources du conteneur dans le statut du pod.

Redimensionnement mémoire

Poursuivons avec les ajustements de la ressource Memory ; le conteneur sera redémarré conformément à la restartPolicy.

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

La capture d'écran montre l'opération de redimensionnement réussie et le redémarrage du conteneur 🚀.