Kubernetes : commandes de base avec exemples pratiques

Introduction

Kubernetes est puissant, mais la majorité des opérations day‑2 se résument à un petit ensemble sûr de kubectl. Ce guide pratique de Kubernetes commands explique quoi exécuter, quand l'utiliser et comment éviter les mauvaises surprises. Vous allez :

Définir et vérifier le contexte et le namespace pour réduire les risques.
Inspecter les workloads et les nœuds avec des commandes en lecture seule d'abord.
Appliquer de petits changements révisables et vérifier les rollouts.
Déboguer avec logs, exec, port-forward, events et métriques.
Tout pratiquer dans un pilote local avant de toucher la production.

Tous les exemples utilisent un namespace non par défaut nommé demo pour plus de sécurité. Considérez cet article comme un mini Kubernetes cheat sheet axé sur les Kubernetes operations.

---

Vue d'ensemble du workflow

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

Cadrer explicitement le périmètre

Choisir le context et le namespace pour cibler chaque commande.
Commandes : kubectl config get-contexts, kubectl config use-context, kubectl config set-context --current --namespace=demo.

Inspecter l'état courant

Commandes : kubectl get, kubectl describe, kubectl get events --sort-by=.lastTimestamp.

Planifier un changement minimal

Préférer labels et sélecteurs de ressources ; éviter les jokers trop larges.
Un seul changement par apply pour simplifier un éventuel rollback.

Prévisualiser avant d'appliquer

Commandes : kubectl diff -f ..., kubectl apply --dry-run=server -f ....

Appliquer et vérifier

Commandes : kubectl apply -f ..., kubectl rollout status deploy/<name>, kubectl wait --for=condition=available.

Revenir en arrière si besoin

Commandes : kubectl rollout undo deploy/<name>.

Observer après le changement

Commandes : kubectl logs, kubectl top, kubectl get events, kubectl describe.

---

kubectl : essentiels

Cluster, context et namespace

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

# Lister et basculer de contexte
kubectl config get-contexts
kubectl config use-context <your-context>

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

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

Lister et filtrer les ressources

# Vue d'ensemble des ressources communes
kubectl get nodes
kubectl get ns
kubectl get deploy, ds, sts -A    # liste des workloads à l'échelle du cluster

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

# Filtrer via un sélecteur de labels
kubectl get pods -n demo -l app=web

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

Describe pour une inspection approfondie

kubectl describe pod -n demo <pod-name>
kubectl describe deploy -n demo <deploy-name>

Sorties JSON et JSONPath

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

# JSON formaté
kubectl get deploy -n demo web -o json | jq .   # si jq est installé

É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 retours arrière

Générer du YAML, puis appliquer

Privilégiez la génération de manifestes et leur application, plutôt que des mutations impératives. Les changements restent ainsi révisables et répétables.

# Option 1 : échafauder du YAML avec kubectl puis éditer localement
kubectl create deploy web \
  -n demo \
  --image=nginx:1.25 \
  --replicas=2 \
  --dry-run=client -o yaml > web-deploy.yaml

# Option 2 : écrire un Deployment + Service minimal (exemple ci-dessous)

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

Échelle temporaire :

kubectl scale deploy/web -n demo --replicas=3
kubectl get deploy/web -n demo -o jsonpath='{.spec.replicas}{"\n"}'

Patch d'un petit champ :

kubectl patch deploy/web -n demo \
  --type merge \
  -p '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":20}}}}'

Revenir en arrière en confiance

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

Suppressions sûres

Toujours cadrer les suppressions par type de ressource, namespace et labels.

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

# Supprimer via un sélecteur de labels (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

Logs

# Logs courants
kubectl logs -n demo deploy/web

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

# Inclure les logs précédents après un crash
kubectl logs -n demo $POD --previous

Exec et port-forward

# Ouvrir un shell dans un pod (à utiliser avec parcimonie)
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
# Puis tester en local
curl -I http://127.0.0.1:8080/

Événements, statut et readiness

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

Nœuds : cordon, drain, uncordon (à manier avec soin)

# Empêcher de nouveaux pods d'être planifiés sur un nœud
kubectl cordon <node-name>

# Évictions sûres (tenir compte des PodDisruptionBudgets)
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# Réautoriser la planification
kubectl uncordon <node-name>

Conseils :

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

---

Plan pilote local

Un bon pilote initial est étroit, mesurable et simple à inspecter en local avant 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 le namespace
kubectl create namespace demo
kubectl config set-context --current --namespace=demo

# 3) Déployer l'app 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 changement et 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 -n 20
kind delete cluster --name pilot

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

minikube start
kubectl config set-context --current --namespace=demo || 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 succès pour le pilote :

Les pods passent en 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 events et logs montrent clairement la séquence d'actions.

---

Conclusion

Maîtriser un ensemble compact de Kubernetes basic commands rend les Kubernetes operations quotidiennes prévisibles et sûres. Définissez toujours contexte et namespace, inspectez d'abord, prévisualisez les diffs, appliquez de petits changements, vérifiez les rollouts et observez les signaux du système. Prouvez votre flux avec un petit pilote local, puis conservez ces habitudes en environnements partagés.

Prochaines étapes :

Sauvegardez vos commandes courantes sous forme de scripts ou d'alias, scoppés par namespace.
Ajoutez des labels de façon cohérente pour des sélecteurs précis.
Entraînez‑vous chaque semaine aux rollouts et aux annulations sur un service non critique.

Outils connexes à explorer ensuite : Docker, Helm, GitLab CI/CD, Nginx, Ceph et Prometheus, qui s'intègrent fréquemment à vos Kubernetes examples et à votre pratique quotidienne.