Mise à niveau et migration de pods en cours d'exécution dans Kubernetes : guide pratique

Apprenez à mettre à niveau et migrer des pods en cours d'exécution sur Kubernetes en toute sécurité grâce à des exemples pratiques : inventaire des versions, chemins de configuration, vérification, retour en arrière et récupération. Ce guide couvre kubectl debug, les conteneurs éphémères et les techniques de débogage en direct pour minimiser les perturbations.

Introduction

La mise à niveau et la migration de pods en cours d'exécution dans Kubernetes sont des opérations délicates qui exigent une planification minutieuse pour éviter les interruptions de service et les temps d'arrêt. Déboguer un pod en direct implique souvent d'attacher un conteneur de débogage ou d'utiliser kubectl exec pour inspecter l'environnement. Ce guide fournit des exemples pratiques pour mettre à niveau et migrer un pod en cours d'exécution, y compris comment utiliser kubectl debug pour créer une session de débogage sans perturber le conteneur de production. Nous couvrirons l'inventaire des versions, la configuration sécurisée, la vérification, les modes de défaillance, la récupération et une liste de contrôle opérationnelle. En suivant ces étapes, vous pouvez minimiser les risques et assurer une transition en douceur.

Inventaire des versions et de l'environnement

Avant d'apporter des modifications, établissez une image claire de votre environnement actuel. Cela inclut la version de Kubernetes, la configuration du pod et les dépendances de l'application. Connaître ces détails vous aide à planifier le chemin de mise à niveau et de migration.

Commencez par vérifier la version du serveur Kubernetes :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.24.0
Server Version: v1.24.0

Ensuite, listez les pods actuels et leurs images. Supposons que vous ayez un pod nommé myapp-pod dans l'espace de noms default :

kubectl get pod myapp-pod -o yaml

Cela affichera la spécification complète du pod. Notez le champ image sous containers. Par exemple :

containers:
- name: app
  image: myapp:1.0

Enregistrez la version de l'image. Vérifiez également les étiquettes et les sélecteurs du pod s'il est géré par un déploiement ou un StatefulSet :

kubectl get deployment myapp-deployment -o yaml

Si vous devez déboguer un pod en cours d'exécution, vous pouvez créer un conteneur de débogage en utilisant kubectl debug. Cela est utile pour inspecter le système de fichiers ou le réseau sans modifier le conteneur d'origine. Exemple :

kubectl debug myapp-pod -it --image=busybox --target=app

Cette commande attache un nouveau conteneur basé sur busybox au même pod, partageant l'espace de noms de processus si nécessaire. Vous pouvez ensuite exécuter des commandes à l'intérieur du conteneur de débogage pour examiner l'environnement. Par exemple, pour inspecter le système de fichiers du conteneur cible :

# À l'intérieur du conteneur de débogage
ls /proc/1/root

Ou pour vérifier la connectivité réseau :

# À l'intérieur du conteneur de débogage
wget -O- http://localhost:8080/health

Assurez-vous d'avoir les autorisations RBAC nécessaires pour effectuer ces opérations. Les autorisations minimales incluent généralement get, list, create et delete sur les pods et les déploiements. Un rôle minimal pour le débogage pourrait ressembler à :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-debugger
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "update", "patch"]

Chemin de configuration sécurisé

Lors de la mise à niveau ou de la migration d'un pod, utilisez une approche contrôlée et limitée. Évitez de modifier plusieurs paramètres à la fois. Au lieu de cela, apportez des modifications incrémentielles et testez chacune d'elles.

Pour une mise à niveau contrôlée, envisagez d'utiliser une nouvelle étiquette d'image. Par exemple, pour passer de myapp:1.0 à myapp:2.0, mettez à jour le déploiement :

kubectl set image deployment/myapp-deployment app=myapp:2.0

Cela déclenchera une mise à jour progressive. Pour surveiller le déploiement :

kubectl rollout status deployment/myapp-deployment

Sortie attendue :

Waiting for deployment "myapp-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "myapp-deployment" successfully rolled out

Si vous devez migrer un pod d'un nœud à un autre, vous pouvez utiliser un sélecteur de nœud ou des teintures/tolérations. Supposons que vous souhaitiez déplacer le pod vers un nœud avec l'étiquette disktype=ssd. Modifiez le déploiement avec un sélecteur de nœud :

kubectl patch deployment myapp-deployment -p '{"spec":{"template":{"spec":{"nodeSelector":{"disktype":"ssd"}}}}}'

Cela amènera le déploiement à créer de nouveaux pods sur les nœuds qui correspondent au sélecteur et à terminer les anciens pods. Pour assurer une migration en douceur, vous voudrez peut-être d'abord drainer l'ancien nœud :

kubectl drain <old-node> --ignore-daemonsets --delete-emptydir-data

Cela isole le nœud et évacue les pods. Ensuite, le planificateur place les pods sur d'autres nœuds. Après le drainage, vous pouvez réactiver le nœud si nécessaire :

kubectl uncordon <old-node>

Pour déboguer un pod en cours d'exécution pendant la migration, vous pouvez utiliser kubectl debug avec une copie du pod pour tester les modifications sans affecter le pod en direct. Exemple :

kubectl debug myapp-pod --copy-to=myapp-debug --image=myapp:2.0 -- sleep 1h

Cela crée un pod de débogage myapp-debug avec la nouvelle image mais ne sert pas le trafic. Vous pouvez ensuite inspecter le pod de débogage pour valider la nouvelle configuration. Pour vous attacher au pod de débogage :

kubectl exec -it myapp-debug -- sh

À l'intérieur, vous pouvez exécuter des vérifications spécifiques à l'application, comme vérifier la connectivité à la base de données ou examiner les fichiers de configuration.

Vérification et diagnostics

Après avoir appliqué les modifications, vérifiez que le pod fonctionne correctement. Vérifiez l'état du pod :

kubectl get pods

Recherchez le pod à l'état Running avec le bon nombre de redémarrages. Par exemple :

NAME                                READY   STATUS    RESTARTS   AGE
myapp-deployment-7f8c9d5b6-abcde   1/1     Running   0          2m

Inspectez les journaux pour vous assurer qu'il n'y a pas d'erreurs :

kubectl logs myapp-deployment-7f8c9d5b6-abcde

Si l'application expose un point de terminaison de santé, testez-le en utilisant kubectl exec :

kubectl exec myapp-deployment-7f8c9d5b6-abcde -- curl -f http://localhost:8080/health

Sortie attendue en cas de succès (exemple) :

{"status":"ok"}

Pour le débogage, vous pouvez vous attacher au pod en cours d'exécution avec kubectl debug. Cela peut aider à diagnostiquer des problèmes qui ne sont pas apparents uniquement à partir des journaux. Exemple :

kubectl debug myapp-deployment-7f8c9d5b6-abcde -it --image=nicolaka/netshoot --target=app

À l'intérieur du conteneur de débogage, vous pouvez exécuter des diagnostics réseau ou inspecter les variables d'environnement. Par exemple, pour vérifier la résolution DNS :

nslookup kubernetes.default

Ou pour afficher les variables d'environnement du processus cible :

cat /proc/1/environ | tr '\0' '\n'

De plus, vérifiez les événements du pod pour voir tout avertissement :

kubectl describe pod myapp-deployment-7f8c9d5b6-abcde

Regardez sous Events pour des messages comme FailedScheduling ou Liveness probe failed. Ceux-ci indiquent des problèmes qui nécessitent une attention.

Modes de défaillance et récupération

Même avec une planification minutieuse, les mises à niveau et les migrations peuvent échouer. Les modes de défaillance courants incluent :

• Erreurs d'extraction d'image : La nouvelle image peut ne pas exister ou les informations d'identification sont manquantes. Vérifiez avec kubectl describe pod et recherchez ErrImagePull ou ImagePullBackOff.
• CrashLoopBackOff : La nouvelle version plante au démarrage. Vérifiez les journaux pour identifier la cause.
• Échecs de planification : Si les sélecteurs de nœud ou les demandes de ressources ne peuvent pas être satisfaits, les pods restent Pending.
• Interruption de service : La mise à jour progressive peut être trop rapide, entraînant une perte temporaire de capacité.

Pour récupérer, vous pouvez revenir à une révision précédente d'un déploiement. Tout d'abord, vérifiez l'historique des déploiements :

kubectl rollout history deployment/myapp-deployment

Sortie attendue :

deployment.apps/myapp-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

Ensuite, revenez à la révision précédente :

kubectl rollout undo deployment/myapp-deployment

Cela revient à la révision 1. Surveillez le retour en arrière avec kubectl rollout status.

Si un pod est bloqué à l'état Terminating pendant le drainage du nœud, vous pouvez le supprimer de force :

kubectl delete pod myapp-pod --grace-period=0 --force

Mais soyez prudent avec la suppression forcée car elle peut laisser des ressources.

Pour déboguer un pod en échec, vous pouvez utiliser kubectl debug pour créer une copie du pod avec une commande ou une image différente afin de reproduire le problème. Par exemple, pour démarrer un pod de débogage qui remplace le point d'entrée par un shell :

kubectl debug myapp-pod --copy-to=myapp-debug --image=myapp:2.0 -- /bin/sh

Ayez toujours une sauvegarde de votre YAML de déploiement ou de StatefulSet afin de pouvoir restaurer rapidement la configuration précédente. Vous pouvez exporter la configuration actuelle avant les modifications :

kubectl get deployment myapp-deployment -o yaml > myapp-deployment-backup.yaml

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant, pendant et après la mise à niveau/migration :

Après avoir terminé les étapes, documentez les modifications et mettez à jour les procédures pertinentes. Par exemple, notez la nouvelle version de l'image, la date du changement et tout problème rencontré. Cela aide pour les audits futurs et le dépannage.

Conclusion

La mise à niveau et la migration de pods en cours d'exécution dans Kubernetes peuvent être effectuées en toute sécurité avec une planification appropriée et les bons outils. En utilisant kubectl debug, vous pouvez inspecter et tester les modifications sans affecter le trafic de production. Commencez toujours par un inventaire des versions, apportez des modifications de configuration limitées, vérifiez soigneusement et ayez un plan de retour en arrière. La liste de contrôle opérationnelle fournie vous aidera à répéter le processus de manière cohérente. N'oubliez pas de surveiller le déploiement et d'être prêt à annuler si quelque chose ne va pas. Avec ces pratiques, vous pouvez minimiser les temps d'arrêt et maintenir vos applications en bon état de fonctionnement.