Architecture d'un cluster Kubernetes

Introduction

Dans ce laboratoire (lab), nous allons explorer l'architecture de Kubernetes, une puissante plateforme d'orchestration de conteneurs. Nous examinerons les composants clés qui constituent un cluster Kubernetes et apprendrons comment ils interagissent pour gérer les applications conteneurisées. Ce laboratoire est conçu pour les débutants, offrant une introduction pratique à l'architecture de Kubernetes.

Explorer les composants du plan de contrôle

Commençons par démarrer un cluster Kubernetes en utilisant Minikube et examinons les composants du plan de contrôle.

Tout d'abord, ouvrez votre terminal. Vous devriez être par défaut dans le répertoire /home/labex/project. Sinon, naviguez jusqu'à cet emplacement :

cd ~/project

Maintenant, démarrez Minikube avec la commande suivante :

minikube start

Cette commande initialise un cluster Kubernetes mono - noeud sur votre machine locale. Cela peut prendre quelques minutes pour être terminé. Ne vous inquiétez pas si vous voyez beaucoup de sorties – c'est normal.

Une fois que Minikube a démarré, explorons les composants du plan de contrôle. Le plan de contrôle est le cerveau de Kubernetes, chargé de gérer l'état global du cluster. Pour vérifier l'état de ces composants, exécutez :

kubectl get componentstatuses

Vous devriez voir une sortie similaire à celle - ci :

NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}

Analysons ce que chaque composant fait :

Le planificateur (scheduler) : Ce composant surveille les Pods nouvellement créés sans nœud assigné et sélectionne un nœud pour qu'ils s'exécutent dessus.
Le gestionnaire de contrôleurs (controller manager) : Il exécute des processus de contrôleurs qui régulent l'état du système. Par exemple, le contrôleur de réplication s'assure que le bon nombre de réplicas de Pods est en cours d'exécution.
etcd : C'est un magasin clé - valeur distribué qui sert de magasin de données de base pour tous les données du cluster Kubernetes.

Si tous les composants affichent "Healthy", votre plan de contrôle fonctionne correctement. Si vous voyez des erreurs, il peut être utile de redémarrer Minikube avec minikube delete suivi de minikube start.

Examen des composants des nœuds

Maintenant que nous avons examiné le plan de contrôle, examinons les composants des nœuds. Dans Kubernetes, les nœuds sont les machines de travail qui exécutent vos applications. Imaginez - les comme les muscles de votre cluster, chargés de lourds travaux d'exécution de conteneurs.

Pour voir les nœuds de votre cluster, exécutez :

kubectl get nodes

Vous devriez voir une sortie similaire à celle - ci :

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    control plane   10m   v1.20.0

Cette sortie montre que nous avons un nœud nommé "minikube" qui est à la fois un nœud maître (plan de contrôle) et un nœud de travail, car nous utilisons un cluster mono - nœud. Dans un environnement de production, vous auriez généralement plusieurs nœuds, avec des nœuds maîtres et des nœuds de travail distincts.

Le statut "Ready" signifie que le nœud est en bonne santé et prêt à accepter des Pods.

Pour obtenir des informations plus détaillées sur le nœud, utilisez :

kubectl describe node minikube

Cette commande fournit une foule d'informations sur le nœud. Ne vous inquiétez pas si cela semble écrasant – analysons quelques sections clés :

Conditions du nœud (Node Conditions) : Elles montrent l'état de diverses conditions du nœud (par exemple, Ready, DiskPressure, MemoryPressure).
Capacité (Capacity) : Elle montre les ressources totales disponibles sur le nœud (CPU et mémoire).
Allocable : Elle montre les ressources disponibles pour les Pods à utiliser.
Informations système (System Info) : Elle fournit des informations sur le système d'exploitation du nœud, la version du noyau et le runtime de conteneur.

Les composants clés des nœuds, que vous ne verrez pas directement mais qui s'exécutent sur le nœud, incluent :

kubelet : C'est l'agent principal du nœud. Il surveille les Pods qui lui ont été assignés et s'assure qu'ils sont en cours d'exécution.
kube - proxy : Il maintient les règles réseau sur le nœud, permettant la communication réseau avec vos Pods depuis l'intérieur ou l'extérieur de votre cluster.

Création et examen d'un Pod

Avant de plonger dans le sujet, comprenons comment le YAML fonctionne dans Kubernetes :

graph TB
    A[YAML Config File] -->|Déclare l'état souhaité| B[Kubernetes API]
    B -->|Crée/Gère| C[Conteneurs en cours d'exécution]
    D[kubectl CLI] -->|Lit| A

Les fichiers YAML dans Kubernetes agissent comme de l'"Infrastructure as Code" :

Imaginez - le comme une "carte" qui indique à Kubernetes ce que vous voulez
Décrit l'état souhaité de votre système dans un format lisible par l'homme
Peut être géré par un système de contrôle de version pour la collaboration d'équipe

Créons notre premier fichier YAML. Créez simple-pod.yaml :

nano ~/project/simple-pod.yaml

Ajoutez le contenu suivant :

## --- Début du fichier YAML ---
## 1. Indiquez à Kubernetes quelle version de l'API utiliser
apiVersion: v1
## 2. Déclarez le type de ressource que vous voulez créer
kind: Pod
## 3. Définissez les métadonnées de cette ressource
metadata:
  name: nginx-pod ## Nom du Pod
  labels: ## Les étiquettes nous aident à trouver et organiser les Pods
    app: nginx
## 4. Définissez ce que le Pod doit contenir
spec:
  containers: ## Un Pod peut exécuter un ou plusieurs conteneurs
    - name: nginx ## Nom du conteneur
      image: nginx:latest ## Quelle image de conteneur utiliser
      ports: ## Quels ports exposer
        - containerPort: 80 ## Nginx utilise le port 80 par défaut

La structure du fichier YAML est comme un arbre :

Pod (racine)
├── metadata (branche)
│   ├── name (feuille)
│   └── labels (feuille)
└── spec (branche)
    └── containers (branche)
        └── - name, image, ports (feuilles)

Créez le Pod :

kubectl apply -f simple-pod.yaml ## -f signifie lire à partir d'un fichier

Cette commande va :

Lire votre fichier YAML
L'envoyer à l'API Kubernetes
Kubernetes va travailler pour atteindre l'état que vous avez décrit

Vérifiez la création du Pod :

kubectl get pods

Vous devriez voir :

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          30s

Le "1/1" sous READY signifie qu'un conteneur sur un dans le Pod est prêt. "Running" sous STATUS signifie que votre première configuration YAML a fonctionné!

💡 Conseils pro :

L'indentation dans le YAML est cruciale - utilisez des espaces, pas des tabulations

Utilisez kubectl explain pod pour voir la documentation des champs

Ajoutez toujours des commentaires pour une meilleure maintenabilité

Pour obtenir des informations détaillées sur le pod :

kubectl describe pod nginx-pod

Cette commande fournit beaucoup d'informations, notamment :

Le nœud sur lequel le Pod s'exécute
L'adresse IP du Pod
Les conteneurs dans le Pod
Les événements récents liés au Pod

Ces informations sont cruciales pour le débogage et la compréhension de l'état de votre application.

Création d'un Service

Maintenant que nous avons un pod en cours d'exécution, créons un Service pour l'exposer. Dans Kubernetes, un Service est une abstraction qui définit un ensemble logique de Pods et une politique d'accès à ceux - ci. Imaginez - le comme un moyen d'exposer votre application au réseau, soit à l'intérieur du cluster, soit en externe.

Créez un fichier nommé nginx-service.yaml dans votre répertoire de projet :

nano ~/project/nginx-service.yaml

Ajoutez le contenu suivant au fichier :

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

Analysons ce fichier YAML :

selector : Cela détermine quels Pods le Service enverra le trafic. Dans ce cas, il sélectionnera tous les Pods ayant l'étiquette app: nginx.
ports : Cela spécifie quels ports le Service doit utiliser.
type: NodePort : Cela signifie que le Service sera accessible sur un port de chaque nœud de votre cluster.

Enregistrez le fichier et quittez l'éditeur.

Maintenant, créez le service en exécutant :

kubectl apply -f nginx-service.yaml

Pour vérifier l'état de votre service, utilisez :

kubectl get services

Vous devriez voir une sortie similaire à celle - ci :

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1h
nginx-service   NodePort    10.110.126.65   <none>        80:30080/TCP   30s

La ligne nginx-service montre que votre service a été créé. Le 80:30080/TCP sous PORT(S) signifie que le port 80 à l'intérieur du cluster est mappé au port 30080 sur le nœud.

Pour obtenir des informations plus détaillées sur le service, utilisez :

kubectl describe service nginx-service

Cette commande fournit des informations sur le type de service, les adresses IP, les ports et les points d'accès (endpoints). Les points d'accès sont les adresses IP des Pods auxquels le Service envoie le trafic.

Accès à l'application

Maintenant que nous avons un pod exécutant notre application et un service l'exposant, accédons à l'application. Cette étape vous montrera comment tous les composants que nous avons configurés fonctionnent ensemble pour rendre votre application accessible.

Tout d'abord, nous devons découvrir l'URL que Minikube a attribuée à notre service :

minikube service nginx-service --url

Cette commande affichera une URL, qui devrait ressembler à http://192.168.64.2:30080. L'adresse IP peut être différente sur votre machine.

Pour accéder à l'application, vous pouvez utiliser la commande curl suivie de l'URL :

curl $(minikube service nginx-service --url)

Cela devrait renvoyer le code HTML de la page d'accueil par défaut de Nginx. Si vous voyez une sortie HTML commençant par <!DOCTYPE html>, félicitations! Vous avez réussi à accéder à votre application.

Analysons ce qui vient de se passer :

Votre demande a d'abord atteint le service NodePort que nous avons créé.
Le service a ensuite transféré la demande au pod exécutant le conteneur Nginx.
Le conteneur Nginx a traité la demande et a renvoyé la page d'accueil par défaut.

Cela démontre comment Kubernetes abstrait l'infrastructure sous - jacente, vous permettant de vous concentrer sur votre application plutôt que de vous soucier de la machine spécifique sur laquelle elle s'exécute.

Résumé

Dans ce laboratoire, nous avons exploré l'architecture de Kubernetes en examinant ses composants clés et leurs interactions. Nous avons démarré un cluster Kubernetes à l'aide de Minikube, inspecté le plan de contrôle et les composants des nœuds, créé un pod pour exécuter une application, exposé l'application à l'aide d'un service et, enfin, accédé à l'application.

graph TB
    subgraph Control Plane
        API[API Server]
        CM[Controller Manager]
        SCH[Scheduler]
        ETCD[etcd]
        API --> ETCD
        API --> CM
        API --> SCH
    end

    subgraph Worker Node
        KL[kubelet]
        KP[kube-proxy]
        CR[Container Runtime]

        subgraph Workloads
            POD1[Pod]
            POD2[Pod]
        end

        SVC[Service]

        KL --> CR
        POD1 --> CR
        POD2 --> CR
        KP --> SVC
        SVC --> POD1
        SVC --> POD2
    end

    API --> KL
    Client[External Client] --> SVC

Nous avons appris sur :

Les composants du plan de contrôle tels que le serveur API, le planificateur (scheduler) et le gestionnaire de contrôleurs (controller manager)
Les composants des nœuds tels que kubelet et kube - proxy
Les Pods comme les plus petites unités déployables dans Kubernetes
Les Services comme moyen d'exposer des applications

Cette expérience pratique fournit une solide base pour comprendre l'architecture de Kubernetes. N'oubliez pas que Kubernetes est un système complexe avec de nombreux éléments en mouvement, et il est normal de ne pas tout comprendre dès le départ. Au fur et à mesure que vous continuerez à travailler avec Kubernetes, ces concepts deviendront plus familiers et plus intuitifs.

Les prochaines étapes de votre parcours avec Kubernetes pourraient inclure l'apprentissage des Déploiements (Deployments) pour gérer plusieurs réplicas de votre application, des ConfigMaps et des Secrets pour gérer la configuration, et des Volumes Persistants (Persistent Volumes) pour le stockage de données. Continuez à explorer et bon codage avec Kubernetes!