Manifests Kubernetes : produire, valider et corriger vite (CKAD)

Produire des manifests Kubernetes rapidement, c’est savoir générer un squelette avec kubectl, le compléter avec les bons champs, et valider avant d’appliquer. Ce guide vous donne les réflexes CKAD : kubectl explain, --dry-run=client -o yaml, correction rapide, et validation côté serveur.

Objectif CKAD

La CKAD évalue votre capacité à produire, corriger et valider des manifests rapidement. Ce guide vous apprend à itérer vite sous pression d’examen.

Ce que vous allez apprendre

• Workflow examen : générer → compléter → valider → appliquer
• Deux approches : génération assistée vs écriture manuelle
• Namespace et contexte : éviter les erreurs de cible
• Snippets fréquents : resources, probes, command, envFrom
• Correction rapide : kubectl edit, kubectl patch
• Validation complète : --dry-run=client, --dry-run=server, kubectl diff

Prérequis

• Un cluster Kubernetes fonctionnel : K3s, Kind, ou Minikube
• kubectl installé et configuré
• Connaissance de base de la syntaxe YAML

Workflow CKAD : produire vite

En examen, chaque seconde compte. Voici le workflow le plus efficace :

1. Configurer le namespace de travail

   kubectl create namespace ckad
   kubectl config set-context --current --namespace=ckad

   En changeant le namespace courant, vous évitez de répéter -n à chaque commande.

2. Générer un squelette

   kubectl create deployment web --image=nginx:stable --dry-run=client -o yaml > web.yaml

3. Compléter le manifest

   vim web.yaml

   Ajoutez les champs manquants : resources, probes, labels…

4. Valider avant application

   kubectl apply --dry-run=client -f web.yaml
   kubectl diff -f web.yaml  # si la ressource existe déjà

5. Appliquer et vérifier

   kubectl apply -f web.yaml
   kubectl get all
   kubectl describe deploy web

Réflexe examen

En CKAD, beaucoup d’erreurs viennent d’un mauvais namespace. Vérifiez toujours où vous travaillez avec kubectl config get-contexts.

Deux approches pour produire un manifest

Génération assistée par kubectl

Utile pour : gagner du temps, éviter les erreurs de base, partir d’un squelette valide.

kubectl create deployment web --image=nginx:stable --dry-run=client -o yaml > web.yaml

Le YAML généré est un squelette. Vous devez presque toujours l’ajuster : labels, ports, resources, probes…

Écriture manuelle

Utile pour : comprendre la structure, corriger un YAML existant, maîtriser les champs importants.

Quand vous connaissez bien la structure, vous pouvez écrire directement. Mais en examen, la génération assistée reste plus rapide.

Stratégie recommandée

En CKAD, la méthode la plus efficace : générer un squelette avec --dry-run=client -o yaml, puis compléter manuellement les champs manquants.

Structure d’un Manifest Kubernetes

Kubernetes utilise un langage déclaratif : vous décrivez l’état souhaité, et Kubernetes se charge de l’atteindre. Chaque manifest YAML suit une structure commune avec quatre champs obligatoires.

Les quatre champs essentiels

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: ckad
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
    - containerPort: 80

Champ	Description	Exemples
apiVersion	Version de l’API Kubernetes	v1, apps/v1, networking.k8s.io/v1
kind	Type de ressource	Pod, Deployment, Service, ConfigMap
metadata	Identité de l’objet	name, namespace, labels, annotations
spec	Spécification détaillée	Varie selon le kind

Glissez pour voir

Cohérence des labels

Les labels sont des paires clé-valeur qui permettent de sélectionner des ressources. Un Service trouve ses Pods via un selector qui matche les labels. Utilisez la même convention partout (ex: app: nginx).

Namespace et contexte courant

Créer et utiliser un namespace

# Créer le namespace
kubectl create namespace monprojet

# Définir comme namespace courant
kubectl config set-context --current --namespace=monprojet

# Vérifier le contexte actuel
kubectl config get-contexts

Pourquoi c’est important

Problème	Conséquence	Solution
Oublier -n	Ressource créée dans default	Changer le namespace courant
Mauvais namespace	Ressource introuvable	kubectl get pods -A pour chercher
ConfigMap/Secret ailleurs	not found au démarrage du Pod	Créer dans le même namespace

Glissez pour voir

Réflexe CKAD

Changer le namespace courant fait gagner du temps et évite les erreurs. Faites-le systématiquement au début de chaque question.

Explorer l’API avec kubectl

Découvrir les ressources disponibles

kubectl api-resources | head -15

NAME                  SHORTNAMES   APIVERSION                 NAMESPACED   KIND
configmaps            cm           v1                         true         ConfigMap
namespaces            ns           v1                         false        Namespace
pods                  po           v1                         true         Pod
secrets                            v1                         true         Secret
services              svc          v1                         true         Service
deployments           deploy       apps/v1                    true         Deployment

Cette commande liste tous les types de ressources avec leur abréviation, leur apiVersion et si elles sont namespacées.

Explorer la structure avec kubectl explain

kubectl explain documente chaque champ directement depuis le cluster :

kubectl explain pod.spec.containers

KIND:       Pod
VERSION:    v1

FIELD: containers <[]Container>

DESCRIPTION:
    List of containers belonging to the pod.

FIELDS:
  args  <[]string>
  command       <[]string>
  env   <[]EnvVar>
  image <string>
  name  <string> -required-
  ports <[]ContainerPort>
  resources     <ResourceRequirements>
  ...

Commande puissante

kubectl explain --recursive affiche tous les champs d’un coup. Très utile pour trouver rapidement où placer une option.

kubectl explain deployment.spec --recursive | grep -A5 strategy

Générer des manifests avec —dry-run

Au lieu d’écrire un YAML de zéro, générez-le avec --dry-run=client -o yaml :

Pod

kubectl run web --image=nginx:stable --dry-run=client -o yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: web
  name: web
spec:
  containers:
  - image: nginx:stable
    name: web
  restartPolicy: Always

Deployment

kubectl create deployment web --image=nginx:stable --replicas=3 \
  --dry-run=client -o yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx:stable
        name: nginx

Service

kubectl expose deployment web --port=80 --target-port=80 \
  --dry-run=client -o yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: web

Note : kubectl expose récupère automatiquement les labels du Deployment. C’est plus fiable que kubectl create service qui utilise son propre label.

ConfigMap

kubectl create configmap app-config --from-literal=APP_ENV=production \
  --dry-run=client -o yaml

apiVersion: v1
data:
  APP_ENV: production
kind: ConfigMap
metadata:
  name: app-config

Secret

kubectl create secret generic db-creds --from-literal=password=secret \
  --dry-run=client -o yaml

apiVersion: v1
data:
  password: c2VjcmV0
kind: Secret
metadata:
  name: db-creds

Attention aux sélecteurs générés

Le YAML généré par kubectl create service ajoute souvent un selector qui ne correspond pas à vos Pods. Préférez kubectl expose ou ajustez manuellement le selector après génération.

Snippets fréquents (à connaître par cœur)

Ces champs reviennent constamment en CKAD. Gardez-les en mémoire.

command et args

containers:
- name: app
  image: busybox:1.36
  command: ["sh", "-c"]
  args: ["echo hello && sleep 3600"]

Variables d’environnement simples

env:
- name: APP_ENV
  value: production
- name: APP_DEBUG
  value: "false"

envFrom (injecter toute une ConfigMap)

envFrom:
- configMapRef:
    name: app-config

resources (requests et limits)

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

Unités

• CPU : 100m = 0,1 core, 1 = 1 core
• Mémoire : 128Mi = 128 mebibytes, 1Gi = 1 gibibyte

readinessProbe et livenessProbe

readinessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10

livenessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20

ports

ports:
- containerPort: 80
  name: http
- containerPort: 443
  name: https

volumeMounts et volumes (ConfigMap)

containers:
- name: app
  image: nginx:stable
  volumeMounts:
  - name: config-volume
    mountPath: /etc/config
volumes:
- name: config-volume
  configMap:
    name: app-config

Créer un Pod

Un Pod est l’unité de base dans Kubernetes. Il exécute un ou plusieurs conteneurs.

Manifest complet

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: ckad
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

kubectl apply -f pod.yaml
kubectl get pods -l app=nginx --show-labels

NAME   READY   STATUS    RESTARTS   AGE   LABELS
web    1/1     Running   0          19s   app=nginx

Créer un Deployment

Un Deployment gère un ensemble de Pods identiques et permet les mises à jour progressives.

Manifest avec 3 réplicas

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: ckad
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:stable
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"

kubectl apply -f deployment.yaml
kubectl get deployment

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    3/3     3            3           10s

Règle d'or

Le selector.matchLabels doit matcher exactement les labels du template.metadata.labels. Sinon le Deployment ne trouvera pas ses Pods.

Créer un Service

Un Service expose un ensemble de Pods sur le réseau.

Types de Services

Type	Usage	Accessibilité
ClusterIP	Trafic interne	Dans le cluster uniquement
NodePort	Tests, accès externe simple	<NodeIP>:<nodePort>
LoadBalancer	Production cloud	IP externe via load balancer

Glissez pour voir

Service ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: ckad
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Exposer un Deployment existant

La méthode la plus rapide pour créer un Service cohérent :

kubectl expose deployment web --port=80 --target-port=80

Le selector est automatiquement aligné avec les labels du Deployment.

Créer une ConfigMap

Une ConfigMap stocke des configurations non sensibles.

ConfigMap avec clés/valeurs et fichier

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: ckad
data:
  APP_ENV: production
  APP_DEBUG: "false"
  config.json: |
    {
      "database": "postgres",
      "port": 5432
    }

Utilisation avec envFrom

apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: ckad
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ["sleep", "3600"]
    envFrom:
    - configMapRef:
        name: app-config

Toutes les clés de la ConfigMap deviennent des variables d’environnement.

Créer un Secret

Un Secret stocke des données sensibles. Utilisez stringData pour écrire en clair dans le manifest.

Secret avec stringData

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: ckad
type: Opaque
stringData:
  username: admin
  password: S3cr3tP@ssw0rd!

Sécurité des Secrets

Le champ data est encodé en base64, ce qui n’est pas un mécanisme de chiffrement. La protection réelle dépend :

• Du contrôle d’accès (RBAC) sur les Secrets
• Du chiffrement au repos dans etcd (à configurer côté cluster)
• De solutions comme Sealed Secrets pour le stockage en Git

Utilisation dans un Pod

apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: ckad
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ["sleep", "3600"]
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: username
    - name: DB_PASS
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: password

Variable vs Volume

Les secrets en variables d’environnement sont pratiques mais plus exposés (visibles dans /proc, logs…). Le montage en volume est souvent préférable pour les données très sensibles.

Multi-document YAML

Regroupez plusieurs ressources liées dans un seul fichier avec --- :

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: ckad
data:
  APP_ENV: production
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: ckad
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx:stable
        envFrom:
        - configMapRef:
            name: app-config
---
apiVersion: v1
kind: Service
metadata:
  name: app
  namespace: ckad
spec:
  selector:
    app: myapp
  ports:
  - port: 80

kubectl apply -f app-stack.yaml

Toutes les ressources sont créées en une seule commande.

Corriger rapidement une ressource existante

kubectl edit (modification interactive)

kubectl edit deployment web

Ouvre le manifest dans votre éditeur. Les changements sont appliqués à la sauvegarde.

kubectl patch (modification ciblée)

# Changer le nombre de réplicas
kubectl patch deployment web --type merge -p '{"spec":{"replicas":5}}'

# Changer l'image
kubectl patch deployment web --type merge \
  -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.25"}]}}}}'

kubectl set (raccourcis courants)

# Changer l'image
kubectl set image deployment/web nginx=nginx:1.25

# Changer les resources
kubectl set resources deployment/web -c=nginx --limits=cpu=500m,memory=256Mi

Quand utiliser quoi

Situation	Commande
Modification complexe	kubectl edit
Un seul champ	kubectl patch ou kubectl set
Changer l’image	kubectl set image

Glissez pour voir

Valider avant d’appliquer

Validation côté client

kubectl apply --dry-run=client -f mon-manifest.yaml

Vérifie la syntaxe YAML et la structure de base. Rapide mais limité.

Validation côté serveur

kubectl apply --dry-run=server -f mon-manifest.yaml

Envoie le manifest à l’API server pour validation complète :

• Vérifie les admission controllers
• Détecte les champs inconnus
• Valide les contraintes (quotas, policies…)

Voir les changements avec kubectl diff

kubectl diff -f mon-manifest.yaml

Compare le manifest local avec la ressource existante :

replicas: 3
replicas: 5

Réflexe validation

Avant d’appliquer en examen :

1. --dry-run=client pour la syntaxe
2. kubectl diff si la ressource existe déjà
3. Puis kubectl apply

Erreurs qui font perdre du temps en CKAD

Erreur	Conséquence	Solution
Oublier le namespace	Ressource dans default	Changer le namespace courant
Mauvais label Service/Pod	Service sans Endpoints	Aligner les selectors
port vs targetPort inversés	Connexion impossible	port = Service, targetPort = conteneur
Indentation YAML incorrecte	Erreur de parsing	Utiliser 2 espaces, pas de tabs
Modifier selector d’un Deployment	Erreur “immutable”	Supprimer et recréer
Champ au mauvais niveau	Champ ignoré	kubectl explain pour vérifier
ConfigMap dans un autre namespace	not found	Même namespace que le Pod

Glissez pour voir

Exemple de piège : selector immutable

# Impossible de modifier le selector d'un Deployment existant
kubectl patch deployment web --type merge -p '{"spec":{"selector":{"matchLabels":{"app":"newapp"}}}}'
# Erreur: spec.selector is immutable

Solution : supprimer et recréer le Deployment.

kubectl delete deployment web
kubectl apply -f web.yaml  # avec le nouveau selector

Checklist de validation

Avant chaque kubectl apply :

• Namespace : suis-je dans le bon namespace ?
• Labels : sont-ils cohérents entre Deployment, Pod et Service ?
• Image : nom et tag corrects ?
• Ports : port et targetPort alignés ?
• Resources : requests ≤ limits ?
• Probes : path et port corrects ?
• Volumes : même nom entre volumes et volumeMounts ?

Tableau récapitulatif

Ressource	Rôle	Champs clés
Pod	Exécuter des conteneurs	containers[].image, ports, resources
Deployment	Gérer des réplicas	replicas, selector, template
Service	Exposer des Pods	selector, ports, type
ConfigMap	Configuration non sensible	data (clé/valeur ou fichier)
Secret	Données sensibles	stringData (écriture) ou data (base64)

Glissez pour voir

Commandes de référence rapide

# Explorer l'API
kubectl api-resources
kubectl explain deployment.spec.template.spec.containers

# Générer des manifests
kubectl create deployment web --image=nginx --dry-run=client -o yaml > web.yaml
kubectl expose deployment web --port=80 --dry-run=client -o yaml > svc.yaml

# Valider
kubectl apply --dry-run=client -f manifest.yaml
kubectl apply --dry-run=server -f manifest.yaml
kubectl diff -f manifest.yaml

# Corriger rapidement
kubectl edit deployment web
kubectl patch deployment web --type merge -p '{"spec":{"replicas":5}}'
kubectl set image deployment/web nginx=nginx:1.25

# Débugger
kubectl get pods -A  # tous les namespaces
kubectl describe pod web
kubectl logs web
kubectl exec -it web -- sh

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Workflow examen : namespace → générer → compléter → valider → appliquer
2. kubectl explain documente chaque champ depuis le cluster
3. --dry-run=client -o yaml génère un squelette à compléter
4. kubectl expose crée un Service avec les bons labels automatiquement
5. Labels cohérents entre Deployment, Pod template et Service selector
6. --dry-run=server valide contre l’API et les admission controllers
7. kubectl edit et kubectl patch pour corriger rapidement
8. Multi-document YAML (---) pour regrouper les ressources liées
9. Namespace courant : le changer évite les erreurs de cible
10. stringData dans les Secrets évite l’encodage base64 manuel

Prochaines étapes

Pods Kubernetes Comprendre le cycle de vie et les phases des Pods

Deployments Mises à jour progressives et stratégies de rollout

Services Exposer vos applications avec ClusterIP, NodePort et LoadBalancer

ConfigMaps Externaliser la configuration de vos applications

Secrets Gérer les données sensibles dans Kubernetes

×

📖 Voir la documentation →