Introduction
Un schéma pour comprendre
Voici un schéma trouvé sur internet qui explique présente les différents composants de Kubernetes
Architecture de Kubernetes
Concept | Description |
---|---|
Cluster | Un ensemble de machines (nœuds) qui exécutent les applications conteneurisées. |
Node (Nœud) | Une machine (physique ou virtuelle) qui fait partie du cluster. Il existe deux types : Control Plane (Plan de contrôle) et Worker Node (Nœud de travail). |
Control Plane | Responsable de la gestion et de l’orchestration des conteneurs dans le cluster. |
Worker Node | Exécute les applications sous forme de pods. |
Pod | L’unité de base en Kubernetes. Un pod contient un ou plusieurs conteneurs qui partagent le même réseau et le même stockage. |
Namespace | Un moyen de segmenter les ressources Kubernetes pour différents projets ou équipes. |
Composants du Plan de Contrôle
Composant | Description |
---|---|
API Server | Interface principale de Kubernetes qui reçoit les commandes des utilisateurs et gère les interactions avec les autres composants. |
Scheduler | Assigne les pods aux nœuds en fonction des ressources disponibles. |
Controller Manager | Gère les différents contrôleurs, comme la gestion des pods en panne, le scaling automatique et la détection des nœuds inactifs. |
etcd | Base de données distribuée qui stocke l’état du cluster et les configurations Kubernetes. |
Composants du Worker Node
Composant | Description |
---|---|
Kubelet | Agent qui assure que les pods sont lancés et exécutés correctement sur le nœud de travail. Il surveille la santé des conteneurs et redémarre les conteneurs en cas de besoin. |
Kube Proxy | Gère le réseau sur le nœud en établissant des règles de routage pour les connexions réseau entre les services et les pods, permettant ainsi l’accès aux services du cluster. |
Termes Kubernetes
Terme | Description |
---|---|
Deployment | Objet Kubernetes permettant de gérer le déploiement et la mise à jour des pods de manière déclarative. |
Service (SVC) | Expose un ensemble de pods via une adresse IP stable, utile pour le load balancing et la découverte de services. |
Ingress | Gère l’accès HTTP/HTTPS vers les services Kubernetes depuis l’extérieur du cluster. |
ConfigMap & Secret | Stockent respectivement des configurations non sensibles (ConfigMap) et des informations sensibles comme des mots de passe (Secret). |
Persistent Volume (PV) & Persistent Volume Claim (PVC) | Gestion du stockage persistant pour les applications, permettant aux pods d’accéder à des volumes de stockage même après leur suppression ou redéploiement. |
Différences principales entre HPA et VPA (Horizontal/Vertical Pod Autoscaler)
HPA (Horizontal) : Le HPA ajuste le nombre de réplicas des Pods en fonction de la charge, mais ne touche pas aux ressources allouées par Pod.
VPA (Vertical) : Le VPA ajuste les ressources individuelles (CPU, mémoire) de chaque Pod, sans changer leur nombre. Cela est particulièrement utile pour les applications dont les besoins en ressources peuvent fluctuer fortement.
Cas d’utilisation typiques :
HPA : Convient aux applications qui ont une charge variable et qui nécessitent un nombre dynamique de réplicas. Par exemple, des services web où le nombre d’utilisateurs peut varier en fonction de l’heure de la journée ou de la charge réseau.
VPA : Utilisé pour des applications où les besoins en ressources peuvent changer au fil du temps, comme les bases de données ou les services de calcul intensif, qui peuvent avoir besoin de plus de mémoire ou de CPU à certains moments.
Les services
Type de service | Accessibilité | Cas d’utilisation |
---|---|---|
ClusterIP | Interne au cluster | Applications internes, point d’accès unique |
NodePort | Interne et externe | Tests, accès limité, accès direct aux pods |
LoadBalancer | Externe (via load balancer) | Applications publiques, Haute disponibilité |
ExternalName | Externe (via DNS) | Services externes, Migration de trafic |
Init Container & Sidecar Container
Init Container : Un conteneur qui s’exécute avant les conteneurs principaux d’un pod. Il est utilisé pour des tâches de préparation comme télécharger des fichiers ou initialiser des configurations. Il doit se terminer avant que le pod ne démarre.
Sidecar Container : Un conteneur qui tourne aux côtés du conteneur principal pour ajouter des fonctionnalités comme la gestion des logs, le monitoring ou le proxying réseau. Il reste actif pendant toute la durée de vie du pod.