Vue d ensemble

Vue d'ensemble

Cette page est la carte du wiki : pour chaque section, un résumé en quelques lignes et un lien direct. Elle sert à se repérer, à réviser ou à savoir où chercher une notion.

Tip

Débutant ? Suivez l'ordre : les fondations d'abord, puis les charges de travail, avant d'aborder la configuration, le réseau et enfin l'exploitation.

Les composants d'un cluster, en bref

Un cluster k8s réunit un plan de contrôle (« le cerveau ») et des noeuds de travail (« les bras »). Ses pièces principales :

• API server : la porte d'entrée du cluster — toutes les commandes passent par lui.
• etcd : la base de données clé-valeur qui stocke tout l'état du cluster.
• scheduler : choisit sur quel noeud placer chaque Pod.
• controller manager : les boucles de contrôle qui ramènent sans cesse le cluster vers l'état voulu.
• kubelet : l'agent de chaque noeud — il démarre et surveille les containers.
• kube-proxy : gère le réseau des Services sur chaque noeud.
• container runtime : le moteur qui exécute réellement les containers (containerd, CRI-O…).

→ Le détail est dans Les composants de k8s.

Les fondations

• Les containers : l'unité de base — une application empaquetée avec ses dépendances et isolée par le système d'exploitation.
• L'orchestration : le problème que résout k8s — décrire l'état souhaité et laisser la plateforme le maintenir, en continu.
• L'architecture de k8s : la vue d'ensemble d'un cluster — les noeuds, l'API server et leurs échanges.
• Les composants de k8s : le rôle précis de chaque pièce (etcd, scheduler, controller, kubelet, container runtime).
• Noeud maître vs noeud esclave : qui décide (le plan de contrôle) et qui exécute (les noeuds de travail).

L'organisation

• Les namespaces : découper un cluster en espaces de travail isolés, et le DNS interne qui les relie.

Les charges de travail

• Les pods : la plus petite unité déployable — un ou plusieurs containers qui partagent réseau, volumes et cycle de vie.
• Les sondes et le cycle de vie : les phases d'un Pod, sa restartPolicy, les sondes (liveness, readiness, startup) et l'arrêt gracieux.
• Les ReplicaSets : maintenir en permanence le bon nombre de Pods identiques.
• Les Deployments : piloter les ReplicaSets — mises à jour progressives et rollback. Le contrôleur le plus utilisé.
• Les Jobs : exécuter une tâche jusqu'à son terme, puis s'arrêter.
• Les CronJobs : lancer un Job de façon planifiée (comme cron).
• Les DaemonSets : garantir un Pod sur chaque noeud (agents de logs, de métriques, de réseau…).
• Les StatefulSets : des Pods à identité stable et démarrés dans l'ordre, adossés à du stockage.

La configuration et le stockage

• Les ConfigMaps et Secrets : sortir la configuration du code de l'image, et traiter à part les données sensibles.
• Les volumes persistants (PV & PVC) : conserver les données au-delà de la vie — éphémère — d'un Pod.

Le réseau

• Les Services : exposer un ensemble de Pods derrière une adresse et un nom stables (ClusterIP, NodePort, LoadBalancer).
• Les Ingress : router le trafic HTTP(S) entrant vers les bons Services, depuis un point d'entrée unique.
• Le Gateway API : le successeur de l'Ingress, plus expressif et réparti en rôles.

L'exploitation et les outils

• La mise à l'échelle : ajuster le nombre de Pods (HPA), leur taille (VPA) et le nombre de noeuds (Cluster Autoscaler).
• Le RBAC : autoriser — ou non — chaque sujet à agir sur chaque ressource.
• Helm : empaqueter et déployer des applications complètes sous forme de charts et de releases.
• kubectl : la ligne de commande pour tout piloter.

Et ensuite ?

Les sujets à venir : NetworkPolicy (la sécurité réseau), requests & limits / QoS (l'allocation des ressources) et Kustomize (la personnalisation des manifestes).