Commandes kubectl de base avec exemples pratiques : guide d'implémentation pratique

Intro

Kubernetes est puissant, mais la plupart des opérations de jour 2 se résument à un petit ensemble sûr de commandes kubectl. Ce guide montre quoi exécuter, quand l'utiliser et comment éviter les surprises. Après lecture, vous serez capable de :

Définir et vérifier le contexte et l'espace de noms pour réduire le risque de cibler le mauvais cluster.
Inspecter les charges de travail et les nœuds avec des commandes en lecture seule avant d'apporter des modifications.
Appliquer de petites modifications révisables et vérifier que les déploiements se terminent correctement.
Déboguer les problèmes à l'aide des journaux, exec, port‑forward, événements et métriques.
Tout tester dans un cluster pilote local avant de toucher à la production.

Tous les exemples utilisent un espace de noms non par défaut appelé demo pour la sécurité.

---

Vue d'ensemble du workflow

Un workflow d'opérateur fiable garde les changements petits, visibles et réversibles.

1. Définir explicitement la portée

Choisissez le contexte et l'espace de noms pour que chaque commande soit ciblée :

kubectl config get-contexts
kubectl config use-context <votre-contexte>
kubectl config set-context --current --namespace=demo

2. Inspecter l'état actuel

kubectl get nodes
kubectl get deploy,sts,ds -n demo
kubectl get events -n demo --sort-by=.lastTimestamp

3. Planifier un changement minimal

Privilégiez les étiquettes et les sélecteurs de ressources ; évitez les jokers larges. Gardez un seul changement par apply pour faciliter le rollback.

4. Prévisualiser avant d'appliquer

kubectl diff -f web.yaml
kubectl apply --dry-run=server -f web.yaml

5. Appliquer et vérifier

kubectl apply -f web.yaml
kubectl rollout status deploy/web -n demo
kubectl wait --for=condition=available deploy/web -n demo --timeout=90s

6. Annuler si nécessaire

kubectl rollout undo deploy/web -n demo

7. Observer après le changement

kubectl logs -n demo deploy/web
kubectl top pods -n demo
kubectl get events -n demo --sort-by=.lastTimestamp | tail -20
kubectl describe deploy/web -n demo

---

Question rapide 1 sur 2

Quelles sous-commandes kubectl sont répertoriées comme courantes pour le dépannage dans le document de référence ?

Le passage de référence [3] mentionne spécifiquement ces quatre sous-commandes comme opérations courantes pour le dépannage.

Commandes kubectl essentielles

Cluster, contexte et espace de noms

# Afficher les points de terminaison de l'API server et infos des composants
kubectl cluster-info

# Lister et changer de contexte
kubectl config get-contexts
kubectl config use-context <votre-contexte>

# Créer et définir un espace de noms de travail sûr
kubectl create namespace demo
kubectl config set-context --current --namespace=demo

# Confirmer l'espace de noms dans le contexte courant
kubectl config view --minify --output 'jsonpath={..namespace}{"\n"}'

Lister et filtrer les ressources

# Ressources courantes en un coup d'œil
kubectl get nodes
kubectl get ns
kubectl get deploy,ds,sts -A  # liste cluster-wide des workloads

# Vues namespacées (par défaut sûr)
kubectl get all -n demo
kubectl get pods -n demo -o wide

# Filtrer par sélecteur d'étiquette
kubectl get pods -n demo -l app=web

# Trier et surveiller
kubectl get pods -n demo --sort-by=.metadata.name
kubectl get pods -n demo --watch

Décrire pour une inspection approfondie

kubectl describe pod -n demo <nom-du-pod>
kubectl describe deploy -n demo <nom-du-deployment>

Sortie JSON et JSONPath

# Obtenir un champ unique avec JSONPath
kubectl get svc -n demo web -o jsonpath='{.spec.clusterIP}{"\n"}'

# JSON pretty (nécessite jq)
kubectl get deploy -n demo web -o json | jq .

Événements et métriques

kubectl get events -n demo --sort-by=.lastTimestamp

# Métriques (nécessite metrics-server)
kubectl top nodes
kubectl top pods -n demo

---

Modifications sûres et rollbacks

Générer le YAML, puis appliquer

Privilégiez la génération de manifests et leur application, plutôt que la mutation impérative. Cela garde les changements révisables et reproductibles.

# Option 1 : générer un YAML avec kubectl et l'éditer localement
kubectl create deploy web \
  -n demo \
  --image=nginx:1.25 \
  --replicas=2 \
  --dry-run=client -o yaml > web-deploy.yaml

Exemple de Deployment et Service (enregistrer sous web.yaml) :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: demo
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "200m"
            memory: "128Mi"
          requests:
            cpu: "100m"
            memory: "64Mi"
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: demo
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  type: ClusterIP

Prévisualiser, appliquer et vérifier :

kubectl diff -f web.yaml
kubectl apply --dry-run=server -f web.yaml
kubectl apply -f web.yaml

kubectl rollout status deploy/web -n demo
kubectl get pods -n demo -l app=web -o wide
kubectl get svc -n demo web

Mises à jour sûres

# Mise à jour d'image
kubectl set image deploy/web -n demo web=nginx:1.25.3
kubectl rollout status deploy/web -n demo

# Mise à l'échelle temporaire
kubectl scale deploy/web -n demo --replicas=3
kubectl get deploy/web -n demo -o jsonpath='{.spec.replicas}{"\n"}'

# Patch d'un champ mineur
kubectl patch deploy/web -n demo \
  --type merge \
  -p '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":20}}}}'

Rollback en toute confiance

kubectl rollout history deploy/web -n demo
kubectl rollout undo deploy/web -n demo              # vers la révision précédente
kubectl rollout undo deploy/web -n demo --to-revision=1  # vers une révision spécifique

Suppressions sûres

Toujours limiter les suppressions par type de ressource, espace de noms et étiquettes.

# Supprimer uniquement le Deployment. Le Service reste.
kubectl delete deploy/web -n demo

# Supprimer par sélecteur d'étiquette (vérifier d'abord avec get)
kubectl get deploy -n demo -l app=web
kubectl delete deploy -n demo -l app=web

---

Observabilité et débogage

Journaux

# Journaux actuels du deployment (tous les pods)
kubectl logs -n demo deploy/web

# Suivre les journaux d'un pod unique
POD=$(kubectl get pods -n demo -l app=web -o jsonpath='{.items[0].metadata.name}')
kubectl logs -n demo $POD -f

# Inclure les journaux du conteneur précédent après un crash
kubectl logs -n demo $POD --previous

Exec et port‑forward

# Ouvrir un shell dans un pod (utiliser seulement si nécessaire)
kubectl exec -n demo -it $POD -- sh

# Rediriger le port local 8080 vers le port 80 du Service
kubectl port-forward -n demo svc/web 8080:80
# Tester localement
curl -I http://127.0.0.1:8080/

Événements, état et disponibilité

kubectl get events -n demo --sort-by=.lastTimestamp | tail -20
kubectl describe deploy/web -n demo
kubectl wait -n demo --for=condition=available deploy/web --timeout=90s

Nœuds : cordon, drain, uncordon (à utiliser avec précaution)

# Empêcher l'ordonnancement de nouveaux pods sur un nœud
kubectl cordon <nom-du-noeud>

# Évincer les pods en toute sécurité (tenir compte des PodDisruptionBudgets)
kubectl drain <nom-du-noeud> --ignore-daemonsets --delete-emptydir-data

# Réautoriser l'ordonnancement
kubectl uncordon <nom-du-noeud>

Conseils :

Communiquer l'impact avant un drain.
Surveiller kubectl get pods -A --watch pendant la maintenance.
Vérifier les DaemonSets et les PDB à l'avance.

---

Plan pilote local

Un bon premier pilote est étroit, mesurable et facile à inspecter localement avant le déploiement.

Option A : kind (nécessite Docker)

# 1) Créer un cluster local
kind create cluster --name pilot
kubectl config use-context kind-pilot

# 2) Préparer l'espace de noms
kubectl create namespace demo
kubectl config set-context --current --namespace=demo

# 3) Déployer l'application d'exemple
kubectl apply -f web.yaml
kubectl rollout status deploy/web -n demo

# 4) Valider
kubectl get pods -n demo -o wide
kubectl get svc -n demo web
kubectl port-forward -n demo svc/web 8080:80 &
curl -I http://127.0.0.1:8080/

# 5) Exercer un changement et un rollback
kubectl set image deploy/web -n demo web=nginx:1.25.3
kubectl rollout status deploy/web -n demo
kubectl rollout undo deploy/web -n demo

# 6) Mesurer et nettoyer
kubectl get events -n demo --sort-by=.lastTimestamp | tail -20
kind delete cluster --name pilot

Option B : minikube (si vous préférez)

minikube start
kubectl config set-context --current --namespace=demo 2>/dev/null || \
  (kubectl create namespace demo && kubectl config set-context --current --namespace=demo)
kubectl apply -f web.yaml
minikube service -n demo web --url

Critères de réussite du pilote :

Les pods deviennent Ready, le rollout se termine et curl renvoie HTTP 200.
Une petite mise à jour d'image se déploie et peut être annulée proprement.
Les événements et les journaux montrent clairement la séquence d'actions.

---

Conclusion

Maîtriser un ensemble compact de commandes kubectl rend les opérations Kubernetes quotidiennes prévisibles et sûres. Définissez toujours votre contexte et votre espace de noms, inspectez d'abord, prévisualisez les diffs, appliquez de petits changements, vérifiez les rollouts et observez les signaux du système. Validez votre flux avec un petit pilote local, puis reportez les mêmes habitudes dans les environnements partagés.

Étapes suivantes :

Enregistrez vos commandes courantes sous forme de scripts ou d'alias scopés par espace de noms.
Ajoutez des étiquettes de manière cohérente pour que les sélecteurs restent précis.
Entraînez‑vous aux rollouts et aux undo chaque semaine sur un service non critique.