Kubernetes · Bases

Qu'est-ce que Kubernetes ? 01

Un orchestrateur déclaratif de conteneurs

Tu écris ce que tu veux (3 replicas de mon API, exposées en HTTPS) ; Kubernetes fait tourner, redémarre, scale, réseau, route — en continu.

Déclaratif : tu décris l'état désiré dans du YAML, pas la suite d'actions à exécuter.
Self-healing : un pod qui crash est recréé, un node qui tombe voit ses pods replanifiés ailleurs.
Scalable : tu passes de 1 à 100 replicas avec kubectl scale (ou l'autoscaler).
Portable : même API sur AWS, GCP, Azure, bare-metal, dev local (kind, minikube).
API centrée : tout est une ressource stockée dans etcd, manipulée via l'API Server.

Fig. 01 · Le modèle déclaratif

Architecture 02

Control plane + nodes

Le control plane est le cerveau (décide). Les nodes sont les bras (exécutent). Un cluster = 1+ control plane + N nodes.

Fig. 02 · Architecture — Control plane (cyan) · Nodes (rose) · Pods (vert)

API SERVER

Porte d'entrée

ETCD

Source de vérité

SCHEDULER

Place les pods

CONTROLLER-MGR

Réconcilie

KUBELET

Agent par node

KUBE-PROXY

Routage L4

Boucle de réconciliation 03

Le pattern fondamental

Un controller est une boucle : lire desired, lire actual, agir pour combler l'écart. Tout Kubernetes est ça.

Chaque type d'objet (Deployment, Service, Node…) a son controller.
La boucle tourne en continu — c'est pour ça qu'on parle de self-healing.
Tu peux écrire ton propre controller (operator pattern) pour gérer des CRDs.

Fig. 03 · Reconciliation loop

Pod 04

L'unité atomique

Un pod = 1+ conteneurs qui partagent le même réseau (localhost, IP) et les mêmes volumes. On déploie rarement des pods directement.

Éphémère : une IP, un hostname, ça meurt et c'est remplacé — ne te lie pas à une IP de pod.
Co-localisation : les conteneurs d'un pod sont toujours sur le même node.
Multi-container surtout pour des sidecars (log, proxy, init).

Fig. 04 · Pod = conteneurs + net + volumes partagés

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports: [{ containerPort: 80 }]

Deployment & ReplicaSet 05

Gérer N replicas

Un Deployment pilote un ReplicaSet qui maintient N pods identiques. C'est ce qu'on utilise pour 95 % des apps stateless.

Rolling update : le Deployment crée un nouveau RS, scale up le neuf, scale down l'ancien.
Rollback : kubectl rollout undo — le RS précédent est encore là.
Scale : replicas: N suffit — le RS s'en charge.

Fig. 05 · Deployment → ReplicaSet → Pods

apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:                    # ← pod template
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: nginx:1.27

Service 06

Un endpoint stable pour des pods volatils

Les pods vont et viennent, leurs IPs changent. Un Service donne une IP/DNS fixe qui load-balance vers les pods matchés par son selector.

ClusterIP (défaut) : accessible uniquement depuis le cluster.
NodePort : expose sur un port de chaque node (30000–32767).
LoadBalancer : demande un LB au cloud provider (AWS ELB, GCP LB…).
Headless (clusterIP: None) : pour du DNS direct pod par pod (StatefulSet).
DNS interne : svc.namespace.svc.cluster.local — le nom du service résout automatiquement.

Fig. 06 · Service (selector) → Endpoints → Pods

Ingress 07

HTTP routing · hostname & path

Le Service expose en L4 (IP:port). L'Ingress route en L7 selon l'hôte et le chemin — un seul LB cloud suffit pour N apps. Il te faut un Ingress Controller (nginx, Traefik, HAProxy…).

Fig. 07 · Ingress → Services → Pods (L7 routing par host/path)

ConfigMap & Secret 08

Séparer la config du code

ConfigMap pour les valeurs non-sensibles, Secret pour les creds (base64, chiffrés au repos si configuré). Injection en env ou en volume.

Même image, configs différentes par environnement.
Monter en volume = hot-reload possible ; en env = fixé au démarrage.
Secrets ne sont pas chiffrés par défaut — activer encryption-config sur l'API Server.

envFrom:
  - configMapRef: { name: app-config }
  - secretRef:    { name: db-creds }

volumeMounts:
  - name: tls
    mountPath: /etc/tls
    readOnly: true
volumes:
  - name: tls
    secret: { secretName: tls-cert }

Volume · PV · PVC 09

Persistance hors du pod

Un emptyDir disparaît avec le pod. Pour survivre, un pod réclame un PVC qui se bind à un PV provisionné par une StorageClass.

Fig. 09 · Pod → PVC → PV ← StorageClass

RWO : 1 node à la fois · ROX : lecture multi-nodes · RWX : r/w multi-nodes.
En dynamique : la StorageClass crée le PV automatiquement quand le PVC est posé.

Namespace 10

Isolation logique

Un cluster, plusieurs namespaces pour partitionner — par équipe, par env, par app. Les noms de ressources sont uniques par namespace.

Fig. 10 · Un cluster, trois namespaces

Support le RBAC, les quotas, les NetworkPolicies, les LimitRanges.
N'isole pas réseau par défaut — il faut des NetworkPolicies.
Ressources cluster-scoped (Node, PV, StorageClass) ne sont pas dans un ns.

Labels & Selectors 11

Le tissu conjonctif

Les labels sont des tags key=value posés sur des objets. Les selectors piochent des objets par match de labels. Presque tout lien dans k8s passe par là.

Deployment sélectionne ses pods · Service sélectionne ses endpoints · NetworkPolicy sélectionne ses cibles.
Bonne pratique : app=, env=, version=, tier=.
Les annotations sont différentes : métadonnées non-sélectionnables (pour outils, docs).

# Filtrer
kubectl get po -l 'app=web,env=prod'
kubectl get po -l 'env in (prod,stg)'
kubectl get po -l '!canary'

# Le selector d'un Service
selector:
  app: web
  tier: frontend

Probes & Ressources 12

Santé + quotas

Trois probes pour la santé, deux champs pour les ressources. C'est ce qui sépare un pod qui crash silencieusement d'un pod que k8s sait gérer.

livenessProbe : le pod est-il vivant ? (échec → redémarrage)
readinessProbe : prêt à recevoir du trafic ? (échec → retiré du Service)
startupProbe : démarrage lent — désactive les autres tant qu'elle n'est pas OK.
requests : réservation (utilisée par le scheduler).
limits : plafond (dépassement CPU → throttle · mémoire → OOMKill).

resources:
  requests: { cpu: 100m, memory: 128Mi }
  limits:   { cpu: 500m, memory: 512Mi }

livenessProbe:
  httpGet:   { path: /healthz, port: 8080 }
  periodSeconds: 10

readinessProbe:
  httpGet:   { path: /ready, port: 8080 }
  initialDelaySeconds: 5

Autres workloads 13

Au-delà du Deployment

STATEFULSET

Pods avec identité stable

DAEMONSET

1 pod par node

JOB

Run-to-completion

CRONJOB

Job planifié (cron)

StatefulSet — bases de données, Kafka, etc. Chaque pod a un nom ordonné (db-0, db-1…) et un PVC par pod.
DaemonSet — agents par node : Fluent Bit, node-exporter, CNI, CSI driver.
Job — tâche one-shot (migrations, batchs). completions et parallelism configurables.
CronJob — génère un Job à une expression cron (0 2 * * *).