1 
2Si vous travaillez dans le monde du développement logiciel, vous avez certainement entendu parler de Kubernetes. Mais qu'est-ce que c'est exactement, et pourquoi est-il devenu la norme de facto pour la gestion des applications conteneurisées ? Ce guide vous emmènera des bases aux concepts fondamentaux, avec des exemples pratiques et des diagrammes pour vous aider à comprendre.
3 
4## Avant Kubernetes : Un peu d'histoire
5 
6Pour comprendre pourquoi Kubernetes est si révolutionnaire, faisons un pas en arrière.
7 
81.  **Déploiement traditionnel**: Au départ, les applications étaient exécutées sur des serveurs physiques. Cette approche était coûteuse, difficile à mettre à l'échelle et sujette aux conflits de ressources.
92.  **Déploiement virtualisé**: Puis sont venues les machines virtuelles (VM). Les VM ont permis d'exécuter plusieurs applications isolées sur le même matériel, améliorant l'utilisation des ressources et la sécurité. Cependant, chaque VM exécute un système d'exploitation complet, consommant beaucoup de ressources.
103.  **Déploiement conteneurisé**: Les conteneurs (comme Docker) sont l'évolution suivante. Ils partagent le même système d'exploitation hôte mais exécutent des processus isolés. Ils sont légers, rapides à démarrer et portables.
11 
12Les conteneurs ont résolu le problème de la portabilité mais en ont créé un autre : comment gérer des centaines (voire des milliers) de conteneurs dans un environnement de production ? Comment s'assurer qu'ils sont toujours en cours d'exécution, qu'ils peuvent communiquer entre eux et qu'ils s'adaptent à la charge ?
13 
14C'est là qu'intervient **Kubernetes**.
15 
16## Qu'est-ce que Kubernetes ?
17 
18Kubernetes (souvent abrégé en **K8s**) est une plateforme open-source pour l'orchestration de conteneurs. En termes simples, il automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Créé par Google et maintenant maintenu par la Cloud Native Computing Foundation (CNCF), Kubernetes est devenu l'outil de référence pour quiconque travaille avec des microservices à grande échelle.
19 
20## L'architecture d'un cluster Kubernetes
21 
22Un environnement Kubernetes est appelé un **cluster**. Un cluster est composé d'un ensemble de machines, appelées **nœuds**, qui exécutent nos applications. L'architecture est divisée en deux parties principales : le Control Plane et les Worker Nodes.
23 
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32 
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39 
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45 
46    A -- "Communique avec" --> E
47    A -- "Communique avec" --> J
48    User -- "kubectl" --> A
49    C -- "Attribue les Pods aux Nœuds" --> E
50    D -- "Maintient l'état" --> A
51    A -- "Sauvegarde/Lit l'état" --> B
52```
53 
54### Control Plane
55 
56Le Control Plane est le "cerveau" du cluster. Il prend des décisions globales (comme la planification) et détecte et répond aux événements du cluster. Ses principaux composants sont :
57 
58-   **API Server (`kube-apiserver`)**: C'est la passerelle du cluster. Il expose l'API Kubernetes, qui est utilisée par les utilisateurs (via `kubectl`), les composants du cluster et les outils externes pour communiquer.
59-   **etcd**: Une base de données clé-valeur cohérente et hautement disponible. Elle stocke toutes les données du cluster, représentant l'état souhaité et actuel du système.
60-   **Scheduler (`kube-scheduler`)**: Attribue les Pods nouvellement créés à un Worker Node disponible, en tenant compte des besoins en ressources, des politiques et d'autres contraintes.
61-   **Controller Manager (`kube-controller-manager`)**: Exécute les contrôleurs, qui sont des boucles de contrôle qui surveillent l'état du cluster et s'efforcent de l'amener à l'état souhaité. Par exemple, le `Node Controller` gère les nœuds, tandis que le `Replication Controller` s'assure que le bon nombre de Pods est en cours d'exécution.
62 
63### Worker Node
64 
65Les Worker Nodes sont les machines (physiques ou virtuelles) où les applications sont réellement exécutées. Chaque nœud est géré par le Control Plane et contient les composants suivants :
66 
67-   **Kubelet**: Un agent qui s'exécute sur chaque nœud. Il s'assure que les conteneurs décrits dans les Pods sont en cours d'exécution et en bonne santé.
68-   **Kube-proxy**: Un proxy réseau qui gère les règles réseau sur les nœuds. Il permet la communication réseau vers les Pods depuis des sessions réseau à l'intérieur ou à l'extérieur du cluster.
69-   **Container Runtime**: Le logiciel responsable de l'exécution des conteneurs. Docker est le plus célèbre, mais Kubernetes prend également en charge d'autres runtimes comme `containerd` et `CRI-O`.
70 
71## Objets fondamentaux de Kubernetes
72 
73Dans Kubernetes, tout est représenté par des **objets**. Ces objets sont des "enregistrements d'intention" : une fois que vous créez un objet, Kubernetes travaille constamment pour s'assurer qu'il existe et correspond à l'état souhaité.
74 
75Voici les plus importants :
76 
77### Pod
78 
79Le **Pod** est la plus petite unité d'exécution dans Kubernetes. Il représente un ou plusieurs conteneurs qui sont exécutés ensemble sur le même nœud, partageant des ressources comme le réseau et le stockage.
80 
81Généralement, vous n'exécutez qu'un seul conteneur par Pod, mais dans des scénarios avancés (comme les "conteneurs sidecar" pour la journalisation ou la surveillance), vous pouvez en avoir plusieurs.
82 
83Vous ne créez presque jamais de Pods directement. Vous utilisez des abstractions de plus haut niveau comme les Déploiements.
84 
85### Deployment
86 
87Un **Deployment** est l'objet que vous utiliserez le plus souvent. Il décrit l'état souhaité pour un groupe de Pods identiques. Le contrôleur de déploiement est responsable de :
88 
89-   Créer et gérer un **ReplicaSet** (un autre objet qui garantit qu'un nombre spécifique de répliques d'un Pod est toujours en cours d'exécution).
90-   **Mettre à l'échelle** le nombre de Pods à la hausse ou à la baisse.
91-   Gérer les **mises à jour** d'application de manière contrôlée (par ex., *Rolling Update*), sans temps d'arrêt.
92 
93Voici un exemple de fichier YAML pour un déploiement qui exécute 3 répliques d'un serveur NGINX :
94 
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117 
118### Service
119 
120Les Pods dans Kubernetes sont éphémères : ils peuvent être créés et détruits à tout moment. Chaque Pod a sa propre adresse IP, mais cette IP n'est pas stable. Alors, comment exposons-nous de manière fiable notre application ?
121 
122Avec un **Service**. Un Service est une abstraction qui définit un ensemble logique de Pods et une politique pour y accéder. Il fournit un **point d'accès stable** (une adresse IP virtuelle et un nom DNS) pour un groupe de Pods.
123 
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129 
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135 
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139 
140    Client -- "Requête vers nginx-service" --> A
141```
142 
143Le Service utilise un `selector` basé sur des `labels` pour trouver les Pods vers lesquels il doit acheminer le trafic.
144 
145Voici comment créer un Service pour notre déploiement NGINX :
146 
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Par défaut - expose le service uniquement à l'intérieur du cluster
161```
162 
163Il existe différents types de Services :
164- `ClusterIP` : Expose le service sur une IP interne au cluster (par défaut).
165- `NodePort` : Expose le service sur un port statique sur chaque Worker Node.
166- `LoadBalancer` : Crée un équilibreur de charge externe dans le fournisseur de cloud (par ex., AWS, GCP) et attribue une IP publique au service.
167 
168### Ingress
169 
170Un Service de type `LoadBalancer` est excellent, mais en créer un pour chaque service peut être coûteux. Pour exposer plusieurs services HTTP/HTTPS au monde extérieur, vous utilisez un **Ingress**.
171 
172Un Ingress agit comme un "routeur intelligent" pour le trafic externe. Il vous permet de définir des règles de routage basées sur l'hôte (par ex., `api.monsite.com`) ou le chemin (par ex., `monsite.com/api`).
173 
174```mermaid
175graph LR
176    User -- "monsite.com/api" --> Ingress
177    User -- "monsite.com/ui" --> Ingress
178 
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182 
183        ServiceA --> PodA1("Pod API 1")
184        ServiceA --> PodA2("Pod API 2")
185 
186        ServiceB --> PodB1("Pod UI 1")
187        ServiceB --> PodB2("Pod UI 2")
188    end
189```
190 
191Voici un exemple d'Ingress :
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: monsite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218 
219### Autres objets utiles
220 
221-   **Namespace**: Vous permet de créer des "clusters virtuels" à l'intérieur d'un cluster physique. Utile pour isoler des environnements (par ex., `development`, `staging`, `production`) ou des équipes.
222-   **ConfigMap et Secret**: Pour gérer les données de configuration et les secrets (comme les mots de passe ou les clés API) découplés de l'image du conteneur.
223-   **StatefulSet**: Similaire à un déploiement, mais spécifique aux applications avec état (comme les bases de données) qui nécessitent des identités réseau stables et un stockage persistant.
224-   **PersistentVolume (PV) et PersistentVolumeClaim (PVC)**: Pour gérer le stockage persistant dans le cluster.
225 
226## Conclusion
227 
228Kubernetes est un outil incroyablement puissant, mais sa courbe d'apprentissage peut être abrupte. Ce guide n'a fait qu'effleurer la surface, mais nous espérons qu'il vous a donné une solide-compréhension des concepts de base.
229 
230**Que faire maintenant ?**
231- **Expérimentez localement**: Installez [Minikube](https://minikube.sigs.k8s.io/docs/start/) ou [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) pour créer un cluster Kubernetes sur votre ordinateur.
232- **Utilisez `kubectl`**: Familiarisez-vous avec la commande `kubectl`, votre principal outil pour interagir avec le cluster. Essayez de créer le déploiement NGINX et le service de cet article.
233- **Explorez les tutoriels officiels**: La [documentation Kubernetes](https://kubernetes.io/docs/tutorials/) est une ressource fantastique pleine d'exemples.
234 
235L'orchestration de conteneurs est une compétence fondamentale dans le monde du cloud-native, et maîtriser Kubernetes vous ouvrira un monde de possibilités. Amusez-vous bien !