Liste de contrôle des opérations de production avec kubectl et exemples pratiques

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 :

kubectl version --short

Sortie attendue (exemple) :

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 :

kubectl get nodes -o wide

Sortie attendue (exemple) :

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   <none>        Ubuntu 22.04.2 LTS   5.15.0-76-generic   containerd://1.6.21
node-2   Ready    <none>          10d   v1.27.3   192.168.1.11   <none>        Ubuntu 22.04.2 LTS   5.15.0-76-generic   containerd://1.6.21
node-3   Ready    <none>          10d   v1.27.3   192.168.1.12   <none>        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 <nom-du-nœud>.

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 :

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 :

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 :

kubectl get events --all-namespaces --sort-by='.lastTimestamp'

Extrait de sortie attendu :

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 :

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 :

kubectl auth can-i create deployments.apps --namespace production

Sortie attendue :

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 :

kubectl create deployment test-nginx --image=nginx:1.25 --dry-run=client -o yaml

Sortie attendue :

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 :

kubectl diff -f deployment.yaml

Exemple de sortie :

--- 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 :

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 :

kubectl set image deployment/myapp myapp=nginx:1.25 -n production --record

Sortie attendue :

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 :

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 :

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 :

kubectl apply -f myapp-canary.yaml -n production

Sortie attendue :

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 :

kubectl get pods -n production

Sortie attendue :

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 :

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 :

kubectl describe pod myapp-7c9f8b6d-abcde -n production

Extrait de sortie attendu :

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 :

kubectl logs myapp-7c9f8b6d-abcde -n production

Pour les pods ayant plusieurs conteneurs, précisez le nom du conteneur avec -c :

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 :

kubectl logs -l app=myapp -n production --tail=20

Exemple de sortie :

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) :

kubectl top nodes
kubectl top pods -n production

Exemple de sortie pour les nœuds :

NAME     CPU(cores)   MEMORY(bytes)
node-1   120m         1.5Gi
node-2   90m          1.2Gi
node-3   80m          1.1Gi

Pour les pods :

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 :

kubectl exec myapp-7c9f8b6d-abcde -n production -- curl -s http://localhost:8080/healthz

Sortie attendue :

ok

Effectuer un test de connectivité depuis l'extérieur

Utilisez kubectl port-forward pour accéder à un service localement :

kubectl port-forward svc/myapp-service 8080:80 -n production

Sortie attendue :

Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

Ouvrez ensuite un navigateur ou utilisez curl pour tester :

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 :

kubectl get endpoints -n production

Sortie attendue :

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 :

kubectl describe pod myapp-7c9f8b6d-xyz12 -n production

Extrait de sortie attendu :

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 :

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 :

kubectl rollout history deployment/myapp -n production

Sortie attendue :

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

Pour revenir à la révision précédente :

kubectl rollout undo deployment/myapp -n production

Sortie attendue :

deployment.apps/myapp rolled back

Pour revenir à une révision spécifique :

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 :

kubectl rollout restart deployment/myapp -n production

Sortie attendue :

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 :

kubectl delete pod myapp-7c9f8b6d-xyz12 -n production --grace-period=0 --force

Sortie attendue :

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 :

kubectl describe node node-1 | grep -A5 "Conditions:"

Sortie attendue :

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 :

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) :

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 <espace-de-noms>. Responsable : développeur.
• [ ] Surveiller l'état du déploiement : kubectl rollout status deployment/myapp -n <espace-de-noms>. Responsable : développeur.
• [ ] Observer les nouveaux événements : kubectl get events -n <espace-de-noms> --watch. Responsable : développeur.

Après le changement

• [ ] Vérifier la santé des pods : kubectl get pods -n <espace-de-noms>. Responsable : développeur.
• [ ] Vérifier les journaux pour les erreurs : kubectl logs -l app=myapp -n <espace-de-noms> --tail=50. Responsable : développeur.
• [ ] Valider les points de terminaison des services : kubectl get endpoints -n <espace-de-noms>. 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 :

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 !