Cours Kubernetes — architecture, objets, volumes, sondes, mises à jour, RBAC et kubectl en lecture

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. décrire le plan de contrôle et les nœuds d'un cluster, et le rôle de chaque composant ;
2. distinguer Pod, Deployment, Service, Ingress, ConfigMap, Secret et espace de noms (Namespace) ;
3. expliquer les labels et les sélecteurs, ciment des objets entre eux ;
4. décrire un volume persistant, sa demande (PVC) et sa classe de stockage ;
5. configurer des sondes (probes), des requêtes et des limites de ressources ;
6. décrire une mise à jour progressive et savoir revenir en arrière ;
7. appliquer une sécurité de base : RBAC, Pod Security, NetworkPolicy, et savoir que les Secrets ne sont pas chiffrés par défaut ;
8. utiliser kubectl en lecture d'abord, vérifier le contexte avant toute action et prévisualiser avant d'appliquer ;
9. situer cluster local jetable (kind, minikube) et services gérés (renvoi vers la section Cloud).

Prérequis

• Cours « Docker » : image, conteneur, registre, port publié.
• Notions de réseau IP, de ligne de commande et de YAML (indentation par espaces, listes et dictionnaires).
• Aucun cluster n'est requis pour lire. Pour pratiquer : un cluster local jetable créé pour l'occasion (chapitre 10), jamais un cluster de travail ou de production.

Parcours et chapitres

1. Architecture : plan de contrôle et nœuds

D'après la page « Kubernetes Components » (v1.37), un cluster se compose d'un plan de contrôle et de nœuds qui exécutent les charges de travail.

Idée clé : on déclare un état souhaité (« trois copies de cette application ») et des contrôleurs travaillent sans cesse à le réaliser. On ne démarre pas un conteneur « à la main » : on modifie un objet dans l'API.

Des extensions (addons) complètent le cluster : DNS du cluster, tableau de bord web, supervision, journalisation centralisée. Elles sont facultatives mais le DNS est, en pratique, attendu (détail non vérifié ici).

2. kubectl : contextes, kubeconfig et lecture d'abord

kubectl parle à l'API d'un cluster. Il sait quel cluster, quel utilisateur et quel espace de noms grâce à un contexte, lu dans le fichier kubeconfig (par défaut sous ~/.kube/). Une erreur classique : exécuter une commande sur le mauvais cluster.

Étape 1 — savoir où l'on est (toujours avant le reste)

kubectl config current-contextkubectl config get-contexts

• Contexte : poste de travail avec kubectl installé (version de Stéphane inconnue) et un kubeconfig existant.
• Droits : lecture du fichier kubeconfig local ; aucun appel au cluster.
• Effet : lecture seule, affiche le contexte actif puis la liste des contextes.
• Vérification : le contexte actif est bien celui du cluster d'essai ; sinon s'arrêter.
• Retour arrière : sans objet (kubectl config use-context <CONTEXTE> change le contexte actif : action à effet local, hors lecture pure).

Étape 2 — lire l'état du cluster

kubectl get nodeskubectl get pods --all-namespaceskubectl get pods -n <ESPACE-DE-NOMS> -o widekubectl describe pod <NOM> -n <ESPACE-DE-NOMS>kubectl logs <NOM> -n <ESPACE-DE-NOMS>kubectl api-resourceskubectl explain pods

• Contexte : cluster d'essai joignable, contexte vérifié à l'étape 1. Syntaxes d'après la page « kubectl Quick Reference » ; les options exactes dépendent de la version de kubectl (non vérifié).
• Droits : permissions de lecture sur les objets visés. Une erreur Forbidden est normale avec un rôle restreint : ne pas élargir le rôle « pour faire marcher » (chapitre 9).
• Effet : lecture seule. -o wide ajoute des colonnes, -o yaml affiche l'objet complet, -n choisit l'espace de noms, -A (ou --all-namespaces) les prend tous. Attention : -o yaml sur un Secret affiche ses valeurs encodées (chapitre 6) ; kubectl logs peut contenir des données applicatives.
• Vérification : la liste des nœuds montre l'état Ready ; les Pods système apparaissent dans leur propre espace de noms.
• Retour arrière : sans objet.

Étape 3 — prévisualiser avant tout changement

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kubectl apply --dry-run=client -f deploiement.yamlkubectl diff -f deploiement.yaml

• Contexte : un fichier YAML relu ; contexte vérifié. --dry-run=client est présenté par la page « Quick Reference » ; kubectl diff aussi. Le mode --dry-run=server existe mais n'a pas été relu : non vérifié.
• Droits : diff interroge le cluster (droits de lecture) ; --dry-run=client ne le contacte pas pour valider le fichier (comportement exact non vérifié).
• Effet : aucune modification du cluster ; diff montre ce qui changerait.
• Vérification : la sortie correspond à ce qu'on attend modifier, et à rien d'autre.
• Retour arrière : sans objet.

3. Pod, labels, sélecteurs et espaces de noms

• Un Pod est la plus petite unité déployable : un ou plusieurs conteneurs qui partagent réseau et volumes. Un Pod est éphémère : on le remplace, on ne le répare pas. On ne crée presque jamais un Pod seul : un Deployment le fait.
• Un label est une paire clé-valeur posée sur un objet (app: web). Un sélecteur retrouve les objets portant certains labels. Le Deployment sélectionne ses Pods, le Service ses Pods cibles, une NetworkPolicy ses Pods protégés : tout repose sur les labels.
• Un espace de noms (Namespace) découpe un cluster en zones logiques de noms, de droits (RBAC) et de quotas. Ce n'est pas une frontière de sécurité réseau à lui seul : sans NetworkPolicy, les Pods de tous les espaces se joignent (chapitre 9).

4. Deployment et mises à jour progressives

Un Deployment (page « Deployments ») décrit l'état souhaité d'un ensemble de Pods identiques : image, nombre de copies, modèle de Pod. Il crée et gère des ReplicaSets (à ne pas manipuler directement). Chaque modification du modèle de Pod (par exemple l'image) crée un nouveau ReplicaSet et une nouvelle révision.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-demo
  labels:
    app: web-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-demo
  template:
    metadata:
      labels:
        app: web-demo
    spec:
      containers:
        - name: web
          image: nginx:<ETIQUETTE-PRECISE>
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi

Points lus sur la page officielle :

• spec.selector doit correspondre aux labels du modèle de Pod et est immuable après la création ;
• la stratégie par défaut est RollingUpdate : les Pods sont remplacés progressivement, bornés par maxUnavailable (Pods indisponibles au maximum) et maxSurge (Pods en surplus au maximum). Leurs valeurs par défaut sont non relevées ici ;
• kubectl rollout status, kubectl rollout history et kubectl rollout undo suivent et annulent une mise à jour.

Conseil de pratique : donner une étiquette d'image précise (<ETIQUETTE-PRECISE>), pas latest, pour qu'une mise à jour et un retour arrière signifient quelque chose (recommandation de bon sens, non relue sur la page).

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kubectl apply -f deploiement.yaml

• Contexte : cluster d'essai jetable ; contexte vérifié (chapitre 2) ; fichier relu, prévisualisé par kubectl apply --dry-run=client -f deploiement.yaml et kubectl diff -f deploiement.yaml ; image pointée vers un registre de confiance, étiquette remplacée.
• Droits : créer et modifier des Deployments dans l'espace de noms visé.
• Effet : crée ou modifie l'objet ; les Pods sont créés, l'image téléchargée (réseau, disque des nœuds) et la mise à jour progressive démarre si le Deployment existait.
• Vérification : kubectl rollout status deployment/web-demo puis kubectl get pods -l app=web-demo.
• Retour arrière : kubectl rollout undo deployment/web-demo revient à la révision précédente ; pour retirer l'application : voir ci-dessous.

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kubectl rollout undo deployment/web-demo

• Contexte : le Deployment d'essai, après une mise à jour qui se passe mal (Pods en erreur).
• Droits : modifier les Deployments de l'espace de noms.
• Effet : rétablit le modèle de Pod de la révision précédente (nouvelle mise à jour progressive) ; un retour à une révision précise s'écrit avec --to-revision=<N> (page « Deployments »).
• Vérification : kubectl rollout status deployment/web-demo puis kubectl rollout history deployment/web-demo.
• Retour arrière : la révision annulée reste dans l'historique ; le nombre de révisions conservées est non vérifié.

Attention, effet notable. Cette commande peut supprimer ou retirer des éléments. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kubectl delete -f deploiement.yaml

• Contexte : cluster d'essai ; le fichier contient exactement les objets à retirer (relire avant).
• Droits : supprimer les objets désignés.
• Effet : supprime le Deployment et, par cascade, ses ReplicaSets et ses Pods ; le service est interrompu. Les volumes persistants liés à des PVC ne sont pas détruits par cette commande tant que les PVC existent (chapitre 7).
• Vérification : kubectl get deployments,pods -l app=web-demo ne renvoie plus rien.
• Retour arrière : aucun direct : recréer avec kubectl apply -f deploiement.yaml (les données des Pods sans volume persistant sont perdues).

5. Service et Ingress : exposer les Pods

• Un Service donne un point d'accès stable (nom DNS et adresse) à un ensemble de Pods choisis par sélecteur, alors que les Pods vont et viennent. Types (page « Service ») : ClusterIP (par défaut, interne au cluster), NodePort (un port sur chaque nœud), LoadBalancer (équilibreur externe, fourni par l'environnement) et ExternalName (alias DNS).
• Un Service tient ses EndpointSlices à jour d'après les Pods qui correspondent au sélecteur et sont prêts (rôle de la sonde de disponibilité, chapitre 8).

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

• Un Ingress décrit des règles HTTP/HTTPS (nom d'hôte, chemin) vers des Services. Il n'a aucun effet sans un contrôleur Ingress installé dans le cluster. Selon la page officielle consultée, le projet Kubernetes recommande l'API Gateway plutôt qu'Ingress ; l'API Ingress est gelée (stable, mais sans évolution). Pour un nouveau projet, se renseigner sur Gateway API (non étudiée en détail ici).

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo
spec:
  ingressClassName: <CLASSE-DU-CONTROLEUR>
  rules:
    - host: web.example.test
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-demo
                port:
                  number: 80

6. ConfigMap et Secret

• Une ConfigMap stocke de la configuration non confidentielle (paires clé-valeur ou fichiers) injectée dans les Pods en variables d'environnement ou en fichiers. Changer la configuration n'oblige pas à reconstruire l'image.
• Un Secret est destiné aux données sensibles (mots de passe, jetons, certificats). Attention : par défaut, les Secrets sont stockés non chiffrés dans etcd : la page officielle le dit sans ambiguïté, et leurs valeurs ne sont que encodées en base64, ce qui n'est pas du chiffrement. Qui a accès à l'API ou à etcd peut les lire, et quiconque peut créer un Pod dans un espace de noms peut y lire les Secrets de cet espace (y compris via un Deployment).

Mesures recommandées par la page « Secrets » (à au moins mettre en œuvre) :

1. activer le chiffrement au repos des Secrets ;
2. règles RBAC au moindre privilège (qui peut lire, créer, modifier) ;
3. ne monter un Secret que dans les conteneurs qui en ont besoin ;
4. envisager un gestionnaire de secrets externe (pilote CSI de stockage de secrets, coffre).

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kubectl create secret generic demo-secret --from-file=cle=<CHEMIN-FICHIER-LOCAL> -n <ESPACE-DE-NOMS>

• Contexte : cluster d'essai ; le fichier local contient une valeur factice ; ne pas utiliser --from-literal avec une vraie valeur. Syntaxe à confirmer dans l'aide de la version installée (kubectl create secret generic --help) : non vérifié.
• Droits : créer des Secrets dans l'espace de noms visé.
• Effet : crée un Secret dans etcd (non chiffré tant que le chiffrement au repos n'est pas activé).
• Vérification : kubectl get secret demo-secret -n <ESPACE-DE-NOMS> (ne pas ajouter -o yaml : il afficherait la valeur encodée).
• Retour arrière : kubectl delete secret demo-secret -n <ESPACE-DE-NOMS> après vérification du nom.

7. Volumes persistants

Un conteneur perd ses fichiers quand il est remplacé. Pour des données durables (page « Persistent Volumes ») :

• Cycle : provisionnement (statique ou dynamique), liaison PVC-PV (un pour un), utilisation par un Pod, récupération à la suppression du PVC.
• Politique de récupération (persistentVolumeReclaimPolicy) : Retain (le PV est conservé pour un nettoyage manuel) ou Delete (le PV et, selon le pilote, les données sont supprimés) ; Recycle est obsolète.
• Modes d'accès : ReadWriteOnce (lecture-écriture par un seul nœud), ReadOnlyMany, ReadWriteMany, ReadWriteOncePod (un seul Pod). Lesquels sont possibles dépend du pilote de stockage (non vérifié pour le stockage de Stéphane).

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: donnees-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

8. Sondes, requêtes et limites de ressources

Sondes (page « Configure Liveness, Readiness and Startup Probes ») :

Méthodes : httpGet (succès pour un code 200 à 399), tcpSocket, exec (commande dans le conteneur) et grpc. Champs : initialDelaySeconds (défaut 0), periodSeconds (défaut 10), timeoutSeconds, failureThreshold (défaut 3), successThreshold (défaut 1).

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

Ressources (page « Resource Management for Pods and Containers ») :

• requests : quantité garantie, utilisée par le scheduler pour placer le Pod ;
• limits : plafond appliqué par le kubelet et le runtime. Dépasser la limite de CPU entraîne un bridage (throttling) ; dépasser la limite de mémoire peut faire tuer le conteneur (OOM, statut OOMKilled), le noyau agissant quand il détecte une pression mémoire ;
• unités : cpu: 500m = 0,5 cœur (1 cœur = 1000 m) ; memory: 128Mi (mébioctets, Gi pour gibioctets) ;
• sans requests, le placement ne tient pas compte des besoins réels ; sans limits, un Pod peut consommer tout ce que le nœud lui laisse. Les classes de QoS qui en découlent ne sont pas détaillées ici.

9. Sécurité de base : RBAC, Pod Security, NetworkPolicy

RBAC (page « Using RBAC Authorization »). Quatre objets de l'API rbac.authorization.k8s.io :

Principes lus : les permissions sont purement additives (pas de règle « interdire ») ; elles sont accordées par des bindings à des utilisateurs, groupes ou comptes de service ; on ne peut pas créer un rôle accordant plus que ce qu'on possède déjà (prévention de l'escalade).

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: <ESPACE-DE-NOMS>
  name: lecteur-de-pods
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Pod Security (pages « Pod Security Standards » et « Pod Security Admission »). Trois profils :

Le contrôleur d'admission les applique par labels d'espace de noms : pod-security.kubernetes.io/enforce (refuse), .../audit (journalise), .../warn (avertit). Démarrer par warn et audit pour mesurer l'impact avant enforce.

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kubectl label namespace <ESPACE-DE-NOMS> pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/audit=restricted

• Contexte : espace de noms d'essai ; contexte vérifié ; mode warn et audit (n'empêche rien), forme de la commande d'après la page « Pod Security Standards ».
• Droits : modifier les labels d'un Namespace (droit d'administration).
• Effet : modifie l'espace de noms : les futurs Pods non conformes produiront un avertissement et une trace d'audit. Passer à enforce bloquerait la création de Pods non conformes : à tester avant.
• Vérification : kubectl get namespace <ESPACE-DE-NOMS> --show-labels.
• Retour arrière : retirer le label avec kubectl label namespace <ESPACE-DE-NOMS> pod-security.kubernetes.io/warn- (le tiret final retire un label : forme à confirmer dans l'aide de kubectl label).

NetworkPolicy (page « Network Policies ») :

• par défaut, les Pods sont non isolés : tout le trafic est permis, dans les deux sens ;
• une NetworkPolicy qui sélectionne un Pod l'isole dans les directions visées (ingress, egress) : seul ce qu'elle autorise passe ; les règles de plusieurs politiques s'additionnent ;
• elle n'a aucun effet si le plugin réseau du cluster ne la gère pas (la page cite Calico, Cilium, Antrea) ; vérifier avant de croire un espace protégé.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: refus-entrant-par-defaut
  namespace: <ESPACE-DE-NOMS>
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Autres réflexes (sans preuve dans les pages lues, à vérifier) : images de confiance et à étiquette fixe, conteneurs sans droits root, comptes de service dédiés, mises à jour régulières de Kubernetes, accès à l'API non exposé à Internet.

10. Cluster local jetable et services gérés

En local (mention). Pour s'exercer sans toucher à un cluster réel, on crée un cluster d'essai qu'on détruit ensuite :

• kind (« Kubernetes IN Docker ») : des nœuds sous forme de conteneurs ; il détecte Docker, Podman ou nerdctl ; kind create cluster, kind get clusters, kind delete cluster ; il écrit un contexte dans ~/.kube/config (page consultée : version stable v0.33.0) ;
• minikube : cluster local « pour apprendre et développer » ; prérequis relevés : 2 CPU ou plus, 2 Go de mémoire libre, 20 Go de disque, un gestionnaire de conteneurs ou de machines virtuelles ; minikube start, minikube stop, minikube delete --all.

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

kind create cluster --name essai-jetable

• Contexte : poste avec Docker démarré et kind installé (l'installation modifie le poste et n'est pas détaillée ici ; ne jamais exécuter un script téléchargé et redirigé vers un interpréteur sans l'avoir lu). L'option --name est non vérifiée sur la page lue (qui montre kind create cluster) : confirmer avec kind create cluster --help.
• Droits : utilisateur ayant accès au démon Docker.
• Effet : télécharge une image de nœud et crée un cluster (conteneurs) ; ajoute un contexte dans le kubeconfig de l'utilisateur et peut le rendre actif.
• Vérification : kubectl config current-context puis kubectl get nodes.
• Retour arrière : kind delete cluster --name essai-jetable supprime le cluster ; vérifier ensuite le kubeconfig (kubectl config get-contexts).

Services gérés (renvoi). Les fournisseurs proposent un plan de contrôle géré : EKS (Amazon), AKS (Azure), GKE (Google Cloud), OKE (Oracle). Le fournisseur opère alors le plan de contrôle ; le client garde la responsabilité de ses charges, de ses accès et de ses coûts. Les offres, versions prises en charge et tarifs changent et ne sont pas repris ici (non vérifié) : voir la section Cloud de la bibliothèque (cours AWS, Azure, Google Cloud, Oracle Cloud et « Concepts du cloud » pour la responsabilité partagée).

11. Nettoyage et bonnes habitudes

Ordre conseillé en fin d'exercice sur un cluster d'essai :

1. supprimer les objets créés (kubectl delete -f <fichier> après relecture, un fichier à la fois) ;
2. vérifier PVC et volumes restants (kubectl get pvc,pv) ;
3. supprimer le cluster local (kind delete cluster, minikube delete) ;
4. retirer le contexte devenu inutile du kubeconfig ;
5. ne jamais conserver un kubeconfig d'un cluster réel sur un poste partagé.

Bonnes habitudes : contexte vérifié avant toute commande ; lecture, puis prévisualisation (--dry-run, diff), puis application ; fichiers YAML versionnés sans valeur secrète ; un espace de noms par application ; requêtes et limites sur chaque conteneur ; sondes réglées avec prudence ; RBAC au moindre privilège.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule, sauf mention d'un cluster local jetable.

1. Schéma. Redessiner le cluster et suivre ce qui se passe quand on demande trois copies d'une application (API, etcd, scheduler, controllers, kubelet).
2. Contexte. Écrire la séquence de lecture à lancer avant toute action et ce qui doit faire arrêter.
3. Labels. Un Service ne répond pas : lister trois vérifications sur les labels et les points de terminaison.
4. YAML. Compléter à la main un Deployment à deux copies avec requêtes, limites et sonde de disponibilité.
5. Mise à jour. Décrire une mise à jour progressive avec maxSurge et maxUnavailable valant chacun 1 sur quatre copies (nombre de Pods en service à chaque étape) : à vérifier ensuite sur un cluster jetable.
6. Secret. Expliquer pourquoi un fichier YAML de Secret ne doit jamais être versionné, et citer deux mesures de protection officielles.
7. RBAC. Écrire en français le rôle de lecture seule d'un stagiaire (verbes, ressources, espace de noms).
8. Sécurité. Choisir un profil Pod Security pour un espace de noms et justifier le passage par warn avant enforce.
9. Cluster jetable (facultatif). Créer un cluster local, appliquer le Deployment du chapitre 4 après prévisualisation, observer rollout status, rollout undo, puis tout supprimer.

Critères de réussite

• Nommer les composants du plan de contrôle et des nœuds et leur rôle.
• Savoir que les Secrets sont non chiffrés par défaut et qu'un kubeconfig est un secret.
• Prévisualiser (--dry-run, diff) avant d'appliquer, et vérifier le contexte avant tout.
• Expliquer sondes, requêtes et limites, et le risque d'une liveness agressive.
• Savoir qu'une NetworkPolicy exige un plugin qui la gère.
• Dire ce qui n'a pas été vérifié.