## Introduction Kubectl est l'outil en ligne de commande principal pour interagir avec les clusters Kubernetes en production. Que vous soyez développeur déployant des applications, consultant DevOps gérant l'infrastructure de clients ou membre d'une jeune pousse technique, disposer d'un ensemble structuré de procédures opérationnelles pour kubectl est indispensable. Une liste de contrôle des opérations de production contribue à garantir la cohérence, à réduire les erreurs humaines et à accélérer le dépannage. Cet article fournit une liste de contrôle pratique pour les opérations de production avec kubectl, avec des exemples concrets, des commandes et leurs sorties attendues. Nous aborderons l'inventaire des versions et de l'environnement, les pratiques de configuration sûres, la vérification et les diagnostics, les modes de défaillance et la reprise, les pièges courants, ainsi qu'une liste de contrôle des opérations reproductible. À la fin, vous disposerez d'une base solide pour gérer vos clusters Kubernetes en toute confiance et en toute sécurité. La valeur d'une liste de contrôle est double : elle encode les meilleures pratiques afin que quiconque dans l'équipe puisse effectuer les tâches correctement, et elle fournit une base pour l'automatisation et l'audit. À mesure que votre environnement grandit, la liste peut être étendue et adaptée à vos besoins spécifiques. ## Inventaire des versions et de l'environnement Avant d'effectuer toute modification, vous devez comprendre votre environnement. Cette section traite de la collecte des informations de version, de la topologie du cluster et des prérequis pour des opérations kubectl sûres. ### Vérifier la version de kubectl et celle du cluster Tout d'abord, vérifiez que votre version locale de kubectl est compatible avec la version de Kubernetes du cluster. La règle générale est que kubectl ne doit pas différer de plus d'une version mineure de celle du cluster. Utilisez les commandes suivantes : ```bash kubectl version --short ``` Sortie attendue (exemple) : ```text Client Version: v1.28.2 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.27.3 ``` Si la sortie montre un écart important entre les versions client et serveur, pensez à mettre à jour kubectl pour correspondre à la version mineure du cluster. Par exemple, si le serveur est en 1.27, utiliser kubectl 1.28 est acceptable, mais kubectl 1.30 pourrait ne pas être entièrement testé. ### Lister les nœuds et leur état Comprendre les nœuds de votre cluster est essentiel. Utilisez : ```bash kubectl get nodes -o wide ``` Sortie attendue (exemple) : ```text NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME node-1 Ready control-plane 10d v1.27.3 192.168.1.10 Ubuntu 22.04.2 LTS 5.15.0-76-generic containerd://1.6.21 node-2 Ready 10d v1.27.3 192.168.1.11 Ubuntu 22.04.2 LTS 5.15.0-76-generic containerd://1.6.21 node-3 Ready 10d v1.27.3 192.168.1.12 Ubuntu 22.04.2 LTS 5.15.0-76-generic containerd://1.6.21 ``` Recherchez tout nœud dont l'état est `NotReady` ou anormal. Si un nœud est `NotReady`, examinez-le avec `kubectl describe node `. ### Identifier les espaces de noms et les charges de travail Listez tous les espaces de noms et les ressources qu'ils contiennent pour comprendre ce qui s'exécute : ```bash kubectl get namespaces kubectl get all --all-namespaces ``` La seconde commande affiche les pods, services, déploiements, etc. dans tous les espaces de noms. Pour les grands clusters, vous pouvez vous concentrer sur des espaces de noms spécifiques. Par exemple, pour voir toutes les ressources dans l'espace de noms `production` : ```bash kubectl get all -n production ``` ### Vérifier les événements du cluster Les événements récents du cluster peuvent révéler des problèmes. Utilisez : ```bash kubectl get events --all-namespaces --sort-by='.lastTimestamp' ``` Extrait de sortie attendu : ```text NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE default 2m Normal Scheduled pod/myapp-7c9f8b6d-abcde Successfully assigned default/myapp-7c9f8b6d-abcde to node-2 default 2m Normal Pulling pod/myapp-7c9f8b6d-abcde Pulling image "nginx:1.25" default 1m Normal Pulled pod/myapp-7c9f8b6d-abcde Successfully pulled image "nginx:1.25" default 1m Normal Created pod/myapp-7c9f8b6d-abcde Created container nginx default 1m Normal Started pod/myapp-7c9f8b6d-abcde Started container nginx ``` Recherchez les événements de type `Warning`, qui peuvent indiquer des problèmes. Vous pouvez filtrer les avertissements avec : ```bash kubectl events --all-namespaces --types=Warning ``` ### Liste de contrôle des prérequis Avant d'effectuer toute tâche opérationnelle, assurez-vous des points suivants : - **Accès** : Vous disposez des autorisations RBAC nécessaires pour effectuer les actions prévues. Testez avec une simulation ou `kubectl auth can-i`. - **Contexte** : Vous utilisez le bon contexte kubeconfig. Vérifiez avec `kubectl config current-context`. - **Sauvegarde** : Pour toute opération destructive, assurez-vous d'avoir une sauvegarde ou un plan de restauration (voir Modes de défaillance et reprise). - **Fenêtre de maintenance** : Pour les changements susceptibles de causer des interruptions, planifiez-les pendant une fenêtre de maintenance et informez les parties prenantes. Exemple de vérification d'autorisation : ```bash kubectl auth can-i create deployments.apps --namespace production ``` Sortie attendue : ```text yes ``` Si la sortie est `no`, vous devrez peut-être demander des autorisations supplémentaires ou utiliser un autre compte. ## Chemin de configuration sûr Apporter des modifications de configuration en production exige de la prudence. Cette section décrit une approche sûre : utiliser la simulation, appliquer les changements de manière incrémentale et tirer parti du contrôle de version pour les manifestes. ### Utiliser la simulation pour valider les changements Testez toujours les modifications avec `--dry-run=client` ou `--dry-run=server` avant de les appliquer. Par exemple, pour tester la création d'un déploiement : ```bash kubectl create deployment test-nginx --image=nginx:1.25 --dry-run=client -o yaml ``` Sortie attendue : ```yaml apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: test-nginx name: test-nginx spec: replicas: 1 selector: matchLabels: app: test-nginx strategy: {} template: metadata: creationTimestamp: null labels: app: test-nginx spec: containers: - image: nginx:1.25 name: nginx resources: {} status: {} ``` Cela affiche le YAML généré sans réellement créer la ressource. Pour les modifications de ressources existantes, utilisez `kubectl apply --dry-run=client -f manifest.yaml` pour voir ce qui changerait. ### Utiliser apply avec diff Avant d'appliquer, utilisez `kubectl diff` pour voir les changements exacts qui seront apportés : ```bash kubectl diff -f deployment.yaml ``` Exemple de sortie : ```diff --- LIVE +++ MERGED @@ -6,6 +6,6 @@ app: myapp name: myapp spec: - replicas: 3 + replicas: 4 ``` Examinez le diff pour vous assurer que seuls les changements prévus sont effectués. Si le diff est vide, aucun changement ne sera appliqué. ### Utiliser les espaces de noms et les étiquettes pour l'organisation Appliquez les changements dans le bon espace de noms. Si ce n'est pas spécifié, kubectl utilise par défaut l'espace de noms `default`. Précisez toujours l'espace de noms explicitement pour éviter les erreurs : ```bash kubectl apply -f deployment.yaml -n production ``` Utilisez des étiquettes pour organiser les ressources et permettre des opérations ciblées. Par exemple, pour mettre à jour uniquement les pods ayant une étiquette spécifique : ```bash kubectl set image deployment/myapp myapp=nginx:1.25 -n production --record ``` Sortie attendue : ```text deployment.apps/myapp image updated ``` ### Utiliser le contrôle de version pour les manifestes Stockez tous les manifestes Kubernetes dans un système de contrôle de version (par exemple, Git). Cela fournit une piste d'audit, permet la revue de code et facilite le retour à un état antérieur connu et fonctionnel. Avant d'appliquer, assurez-vous que les manifestes sont à jour et relus par un pair. Utilisez un flux de travail de demande d'extraction, et envisagez d'utiliser `kubectl apply --prune` avec un ensemble d'étiquettes soigneusement géré pour nettoyer les ressources supprimées. ### Exemple : Mettre à jour l'image d'un déploiement avec un canari Pour les mises à jour critiques, utilisez une stratégie de déploiement canari. Au lieu de modifier directement le déploiement principal, créez un nouveau déploiement avec la nouvelle image et un petit nombre de réplicas, et utilisez un sélecteur de service pour répartir le trafic. Voici un exemple simplifié : - Créez un déploiement canari : ```bash kubectl create deployment myapp-canary --image=myapp:2.0 -n production --dry-run=client -o yaml > myapp-canary.yaml ``` - Modifiez le YAML pour ajouter une étiquette différente, par exemple `track: canary`, et définissez les réplicas à 1. Voici un exemple de manifeste : ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-canary namespace: production labels: app: myapp track: canary spec: replicas: 1 selector: matchLabels: app: myapp track: canary template: metadata: labels: app: myapp track: canary spec: containers: - name: myapp image: myapp:2.0 ports: - containerPort: 80 ``` - Appliquez-le : ```bash kubectl apply -f myapp-canary.yaml -n production ``` Sortie attendue : ```text deployment.apps/myapp-canary created ``` - Si le canari fonctionne bien, vous pouvez augmenter progressivement ses réplicas ou le promouvoir au déploiement principal en mettant à jour le sélecteur du service. Par exemple, pour acheminer 10 % du trafic vers le canari, ajustez le sélecteur du service pour inclure les deux versions ou utilisez un maillage de services comme Istio pour un contrôle plus fin. ## Vérification et diagnostics Après avoir apporté des modifications, vérifiez que tout fonctionne comme prévu et diagnostiquez efficacement les problèmes. Cette section fournit des commandes pour vérifier la santé des pods, les journaux et l'utilisation des ressources. ### Vérifier l'état et la disponibilité des pods Utilisez `kubectl get pods` pour voir l'état des pods dans un espace de noms : ```bash kubectl get pods -n production ``` Sortie attendue : ```text NAME READY STATUS RESTARTS AGE myapp-7c9f8b6d-abcde 1/1 Running 0 1m myapp-7c9f8b6d-xyz12 1/1 Running 0 1m myapp-canary-5d7f8b-1234 1/1 Running 0 30s ``` Repérez les pods qui ne sont pas en état `Running` ou qui ont un nombre élevé de redémarrages. Des redémarrages fréquents indiquent souvent des boucles de crash. Vérifiez avec : ```bash kubectl get pods -n production --field-selector=status.phase!=Running ``` Cela affiche tous les pods qui ne sont pas en phase Running. ### Décrire les pods pour des informations détaillées Utilisez `kubectl describe pod` pour obtenir des informations détaillées sur un pod, y compris les événements : ```bash kubectl describe pod myapp-7c9f8b6d-abcde -n production ``` Extrait de sortie attendu : ```text Name: myapp-7c9f8b6d-abcde Namespace: production ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m default-scheduler Successfully assigned production/myapp-7c9f8b6d-abcde to node-2 Normal Pulled 2m kubelet Container image "myapp:1.0" already present on machine Normal Created 2m kubelet Created container myapp Normal Started 2m kubelet Started container myapp ``` ### Consulter les journaux Pour afficher les journaux d'un pod : ```bash kubectl logs myapp-7c9f8b6d-abcde -n production ``` Pour les pods ayant plusieurs conteneurs, précisez le nom du conteneur avec `-c` : ```bash kubectl logs myapp-7c9f8b6d-abcde -n production -c myapp ``` Pour les journaux de tous les pods correspondant à une étiquette, vous pouvez utiliser un outil comme `stern` ou une simple boucle : ```bash kubectl logs -l app=myapp -n production --tail=20 ``` Exemple de sortie : ```text 192.168.1.25 - - [10/Oct/2024:12:00:00 +0000] "GET /healthz HTTP/1.1" 200 2 "-" "kube-probe/1.27" 192.168.1.26 - - [10/Oct/2024:12:00:00 +0000] "GET /api/data HTTP/1.1" 200 1234 "-" "Mozilla/5.0" ``` ### Surveiller l'utilisation des ressources Utilisez `kubectl top` pour voir l'utilisation des ressources des nœuds et des pods (nécessite metrics-server) : ```bash kubectl top nodes kubectl top pods -n production ``` Exemple de sortie pour les nœuds : ```text NAME CPU(cores) MEMORY(bytes) node-1 120m 1.5Gi node-2 90m 1.2Gi node-3 80m 1.1Gi ``` Pour les pods : ```text NAME CPU(cores) MEMORY(bytes) myapp-7c9f8b6d-abcde 10m 50Mi myapp-7c9f8b6d-xyz12 12m 55Mi ``` ### Exécuter des commandes de diagnostic dans un conteneur Si vous devez tester la connectivité ou effectuer d'autres vérifications dans un conteneur, utilisez `kubectl exec` : ```bash kubectl exec myapp-7c9f8b6d-abcde -n production -- curl -s http://localhost:8080/healthz ``` Sortie attendue : ```text ok ``` ### Effectuer un test de connectivité depuis l'extérieur Utilisez `kubectl port-forward` pour accéder à un service localement : ```bash kubectl port-forward svc/myapp-service 8080:80 -n production ``` Sortie attendue : ```text Forwarding from 127.0.0.1:8080 -> 80 Forwarding from [::1]:8080 -> 80 ``` Ouvrez ensuite un navigateur ou utilisez curl pour tester : ```bash curl http://localhost:8080 ``` ### Vérifier les points de terminaison des services Assurez-vous que les services ont des points de terminaison et qu'ils sont corrects : ```bash kubectl get endpoints -n production ``` Sortie attendue : ```text NAME ENDPOINTS AGE myapp-service 192.168.1.11:8080,192.168.1.12:8080 2d ``` Si la colonne ENDPOINTS est vide, le sélecteur du service peut ne correspondre à aucun pod. ## Modes de défaillance et reprise Même avec une planification minutieuse, des défaillances peuvent survenir. Cette section couvre les modes de défaillance courants et comment les corriger avec kubectl. ### Modes de défaillance courants - **Erreurs d'extraction d'image** : Les pods ne démarrent pas car l'image est manquante ou le registre est inaccessible. - **Erreurs de configuration** : YAML invalide, ConfigMaps ou Secrets manquants, ou variables d'environnement incorrectes. - **Épuisement des ressources** : CPU ou mémoire insuffisants entraînant l'éviction de pods ou des arrêts pour mémoire insuffisante (OOM). - **Problèmes de réseau** : Échecs de découverte de services, problèmes DNS ou mauvaises configurations des politiques réseau. - **Défaillances de nœuds** : Le nœud devient `NotReady` en raison de problèmes matériels ou système, provoquant le reprogrammation des pods. ### Diagnostiquer les erreurs d'extraction d'image Si un pod est en `ImagePullBackOff` ou `ErrImagePull`, vérifiez les événements : ```bash kubectl describe pod myapp-7c9f8b6d-xyz12 -n production ``` Extrait de sortie attendu : ```text Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 1m default-scheduler Successfully assigned production/myapp-7c9f8b6d-xyz12 to node-2 Warning Failed 1m kubelet Failed to pull image "myapp:2.0": rpc error: code = NotFound desc = failed to pull and unpack image "docker.io/library/myapp:2.0": failed to resolve reference "docker.io/library/myapp:2.0": not found Warning Failed 1m kubelet Error: ErrImagePull Normal BackOff 1m kubelet Back-off pulling image "myapp:2.0" ``` Dans ce cas, l'étiquette d'image `2.0` n'existe pas. Corrigez en modifiant l'étiquette d'image dans le déploiement et en appliquant le changement : ```bash kubectl set image deployment/myapp myapp=myapp:1.0 -n production ``` ### Restaurer un déploiement Si une nouvelle version de déploiement cause des problèmes, vous pouvez revenir à une révision précédente. Tout d'abord, vérifiez l'historique des déploiements : ```bash kubectl rollout history deployment/myapp -n production ``` Sortie attendue : ```text deployment.apps/myapp REVISION CHANGE-CAUSE 1 2 ``` Pour revenir à la révision précédente : ```bash kubectl rollout undo deployment/myapp -n production ``` Sortie attendue : ```text deployment.apps/myapp rolled back ``` Pour revenir à une révision spécifique : ```bash kubectl rollout undo deployment/myapp --to-revision=1 -n production ``` ### Redémarrer un déploiement Parfois, redémarrer les pods peut résoudre des problèmes temporaires. Utilisez la commande suivante : ```bash kubectl rollout restart deployment/myapp -n production ``` Sortie attendue : ```text deployment.apps/myapp restarted ``` ### Supprimer et recréer un pod bloqué Si un pod est bloqué en `Terminating` ou `CrashLoopBackOff`, vous pouvez forcer sa suppression : ```bash kubectl delete pod myapp-7c9f8b6d-xyz12 -n production --grace-period=0 --force ``` Sortie attendue : ```text warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "myapp-7c9f8b6d-xyz12" force deleted ``` ### Récupérer d'un épuisement des ressources Si des pods sont évincés ou tués en raison d'un manque de ressources, vérifiez la pression sur les ressources du nœud : ```bash kubectl describe node node-1 | grep -A5 "Conditions:" ``` Sortie attendue : ```text Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- MemoryPressure False Thu, 10 Oct 2024 12:00:00 +0000 Wed, 09 Oct 2024 12:00:00 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure False Thu, 10 Oct 2024 12:00:00 +0000 Wed, 09 Oct 2024 12:00:00 +0000 KubeletHasNoDiskPressure kubelet has sufficient disk space available PIDPressure False Thu, 10 Oct 2024 12:00:00 +0000 Wed, 09 Oct 2024 12:00:00 +0000 KubeletHasSufficientPID kubelet has sufficient PID available Ready True Thu, 10 Oct 2024 12:00:00 +0000 Wed, 09 Oct 2024 12:00:00 +0000 KubeletReady kubelet is posting ready status ``` S'il y a de la pression, vous devrez peut-être réduire l'échelle ou ajouter des nœuds. Pour vérifier l'utilisation et les limites des ressources des pods : ```bash kubectl top pods -n production --containers ``` Et examinez les demandes et limites de ressources dans les spécifications des pods. ### Sauvegarder et restaurer etcd Pour la reprise après sinistre, vous devez régulièrement sauvegarder la base de données etcd si vous gérez le plan de contrôle. Cela dépasse le cadre de kubectl mais reste essentiel. Pour les clusters managés (par exemple, EKS, GKE), utilisez les fonctions de snapshot du fournisseur cloud. Pour les clusters auto-gérés, utilisez `etcdctl snapshot`. Exemple de commande de snapshot etcd (sur un nœud du plan de contrôle) : ```bash ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key ``` Pour restaurer, utilisez `etcdctl snapshot restore` et suivez la procédure de restauration de votre cluster. ## Pièges courants et comment les éviter Dans les opérations quotidiennes avec kubectl, certaines erreurs reviennent souvent. Reconnaître ces pièges peut vous faire gagner des heures de débogage. ### Opérer sur le mauvais cluster ou espace de noms **Pourquoi cela arrive** : Plusieurs contextes kubeconfig avec des noms similaires, ou dépendance à l'espace de noms par défaut. **Comment éviter** : Précisez toujours explicitement l'espace de noms et vérifiez le contexte avant d'appliquer. Utilisez `kubectl config current-context` et `kubectl config get-contexts`. Envisagez des outils comme `kubectx` et `kubens` pour basculer rapidement de contexte et d'espace de noms, et configurez votre invite de shell pour afficher le contexte actuel. ### Oublier de simuler ou de diffuser **Pourquoi cela arrive** : Pression temporelle ou excès de confiance dans les manifestes. **Comment éviter** : Faites de `--dry-run=client` et `kubectl diff` des étapes obligatoires dans votre processus de changement. Vous pouvez même automatiser ces vérifications dans les pipelines CI/CD pour rejeter les applications directes non autorisées. ### Ne pas utiliser les étiquettes de manière cohérente **Pourquoi cela arrive** : Les étiquettes sont ajoutées de manière ponctuelle sans convention de nommage. **Comment éviter** : Définissez un schéma d'étiquettes pour votre organisation (par exemple, `app`, `tier`, `environment`, `owner`) et appliquez-le avec des politiques. Des outils comme OPA Gatekeeper ou Kyverno peuvent valider les étiquettes au moment de l'admission. ### Ignorer les événements et les journaux jusqu'à ce qu'une panne survienne **Pourquoi cela arrive** : Absence de surveillance proactive ou d'alertes. **Comment éviter** : Mettez en place une surveillance et des alertes pour les événements du cluster et les journaux des pods. Utilisez `kubectl get events --watch` pendant les changements, et intégrez des systèmes de surveillance comme Prometheus et Alertmanager. ### Appliquer des changements sans plan de retour en arrière **Pourquoi cela arrive** : Supposer qu'un changement est à faible risque. **Comment éviter** : Pour tout changement de déploiement, connaissez la commande de retour en arrière et testez-la en préproduction. Utilisez `kubectl rollout history` pour comprendre les révisions disponibles. Pour les changements de configuration, conservez une copie du manifeste précédent dans Git. ### Oublier de nettoyer les ressources **Pourquoi cela arrive** : Les anciennes ressources s'accumulent et peuvent causer de la confusion ou des fuites de ressources. **Comment éviter** : Examinez régulièrement les ressources inutilisées avec des outils comme `kubectl get all --all-namespaces --show-labels`, et supprimez les ReplicaSets orphelins, les Jobs terminés ou les ConfigMaps inutilisés. Envisagez d'utiliser `kubectl apply --prune` avec un sélecteur d'étiquettes pour supprimer les ressources absentes du manifeste, mais utilisez-le avec prudence. ## Liste de contrôle des opérations Cette section fournit une liste de contrôle reproductible pour les opérations kubectl courantes. Utilisez-la comme référence avant, pendant et après l'exécution des tâches. Attribuez un responsable pour chaque élément majeur pour garantir la responsabilisation. Par exemple, désignez un propriétaire de plateforme Kubernetes (une personne précise, comme « Priya Shah, responsable de l'ingénierie ») qui examine la santé du cluster chaque semaine et gère le processus de gestion des changements. ### Vérifications quotidiennes - [ ] Vérifier la santé du cluster : `kubectl get nodes` montre tous les nœuds `Ready`. Responsable : ingénieur d'astreinte, revu chaque matin. - [ ] Vérifier les événements anormaux : `kubectl get events --all-namespaces --sort-by='.lastTimestamp' | grep -i warning`. Responsable : ingénieur d'astreinte. - [ ] Surveiller l'utilisation des ressources : `kubectl top nodes` et `kubectl top pods` dans les espaces de noms critiques. Responsable : ingénieur d'astreinte. - [ ] Examiner les redémarrages de pods : `kubectl get pods --all-namespaces | awk '$4>0'` pour trouver les pods avec redémarrages. Responsable : ingénieur d'astreinte. ### Avant d'appliquer des changements - [ ] Confirmer le contexte actuel : `kubectl config current-context`. Responsable : développeur effectuant le changement. - [ ] Simuler le changement : `kubectl apply --dry-run=client -f manifest.yaml`. Responsable : développeur. - [ ] Diffuser le changement : `kubectl diff -f manifest.yaml`. Responsable : développeur. - [ ] S'assurer qu'une sauvegarde existe si le changement est destructif. Responsable : développeur et propriétaire de plateforme. - [ ] Planifier une fenêtre de maintenance si nécessaire. Responsable : propriétaire de plateforme, approuvé au moins 24 heures à l'avance. ### Pendant le changement - [ ] Appliquer le changement : `kubectl apply -f manifest.yaml -n `. Responsable : développeur. - [ ] Surveiller l'état du déploiement : `kubectl rollout status deployment/myapp -n `. Responsable : développeur. - [ ] Observer les nouveaux événements : `kubectl get events -n --watch`. Responsable : développeur. ### Après le changement - [ ] Vérifier la santé des pods : `kubectl get pods -n `. Responsable : développeur. - [ ] Vérifier les journaux pour les erreurs : `kubectl logs -l app=myapp -n --tail=50`. Responsable : développeur. - [ ] Valider les points de terminaison des services : `kubectl get endpoints -n `. Responsable : développeur. - [ ] Exécuter des tests de fumée (par exemple, curl sur le service via port-forward). Responsable : ingénieur QA ou développeur. ### Maintenance périodique - [ ] Mettre à jour les images vers les dernières versions stables après les tests. Responsable : propriétaire de plateforme, mensuellement. - [ ] Nettoyer les ressources inutilisées (par exemple, déploiements orphelins, anciens ReplicaSets). Responsable : propriétaire de plateforme, mensuellement. - [ ] Examiner et faire pivoter les secrets et certificats. Responsable : ingénieur sécurité, trimestriellement ou selon les besoins. - [ ] Effectuer les sauvegardes etcd si auto-géré. Responsable : propriétaire de plateforme, quotidien automatisé, vérifié chaque semaine. - [ ] Tester les procédures de reprise après sinistre. Responsable : propriétaire de plateforme, trimestriellement. ### Alias kubectl utiles Pour gagner du temps, ajoutez ces alias à votre profil shell : ```bash alias k='kubectl' alias kgp='kubectl get pods' alias kgn='kubectl get nodes' alias kgd='kubectl get deployments' alias kd='kubectl describe' alias kl='kubectl logs' ``` ## Conclusion Dans cet article, nous avons couvert une liste de contrôle complète des opérations de production avec kubectl, accompagnée d'exemples pratiques. Nous avons commencé par la collecte d'informations sur la version et l'environnement, puis abordé les chemins de configuration sûrs en utilisant la simulation, le diff et les déploiements canaris. Nous avons fourni des commandes de vérification et de diagnostic pour garantir que les changements fonctionnent correctement, et nous avons exploré les modes de défaillance courants et les étapes de reprise. Nous avons également mis en évidence les pièges courants et comment les éviter, et présenté une liste de contrôle des opérations reproductible pour les tâches quotidiennes et périodiques. En suivant cette liste de contrôle, vous pouvez réduire le risque d'incidents de production et améliorer la maturité opérationnelle de votre équipe. N'oubliez pas de toujours tester les changements dans un environnement de préproduction, d'utiliser le contrôle de version pour les manifestes et de documenter tout écart par rapport à la liste. À mesure que vous gagnez en expérience, vous pouvez adapter la liste à vos cas d'utilisation spécifiques et automatiser les tâches répétitives. Commencez par un pilote étroit et mesurable, comme le suggère la recherche : choisissez un petit changement, appliquez le chemin de configuration sûr et vérifiez avec des diagnostics avant de généraliser. Cette approche renforce la confiance et vous aide à affiner vos processus. Bon kubectl à tous !