Formation DevOps | Formation kubernetes​ : A - Architecture Kubernetes

www.itgalaxy.io

Architecture de Kubernetes

Kubernetes se découpe en deux parties :

• Le control plane :

Le plan de contrôle contient les composants Kubernetes qui contrôlent le cluster  (ses « cerveaux ») , ainsi que des données sur l'état et la configuration du cluster. 

Ces principaux composants de Kubernetes s'assurent que suffisamment de conteneurs peuvent fonctionner avec les ressources nécessaires.

• Les workers :

 Les workers sont les machines, sur lesquelles Kubernetes place des pods à exécuter , peuvent etres machines virtuelles ou physiques .


Les composants du controle plane :

Un plan de contrôle Kubernetes est le plan de contrôle pour un cluster Kubernetes. Ses composants sont les suivants :

• kube-apiserver : Comme son nom l’indique, le serveur d’API expose l’API Kubernetes, qui est la centrale de communication. Les communications externes via l’interface de ligne de commande (CLI) kubectl ou d’autres interfaces utilisateur (IU) passent par le serveur kube-apiserver, tout comme toutes les communications entre les plans de contrôle et les nœuds.

• Etcd : Base de donnee clé-valeur dans lequel toutes les données relatives au cluster sont stockées. etcd est hautement disponible et cohérent, car tous ses accès s’effectuent via le serveur d’API. Les informations contenues dans etcd sont généralement au format YAML lisible par l’utilisateur.

• kube-scheduler : lorsqu’un nouveau pod est créé, ce composant l’affecte à un nœud pour exécution en fonction des besoins en ressources, des règles et des spécifications d’« affinité » concernant la géolocalisation et les interférences avec d’autres charges de travail.

• kube-controller-manager : basé sur une boucle qui controlle en permanence l’état des resources et essaie de le corriger s’il n’est plus conforme .

Prérequis master : minimum de 3 nœuds maîtres par cluster.

Kubernetes conserve toutes les données critiques dans etcd, qui en utilise la majorité pour réparer en cas de panne. Une instance d’etcd s’exécute sur chaque nœud maître. Trois est le nombre minimum d’etcds que l’on souhaite soutenir dans un cluster de niveau production. Par conséquent, trois est le nombre minimum de maîtres par cluster.

Les composants installées sur les workers :



Un cluster Kubernetes requiert au moins un nœud de calcul, mais en général il en contient un grand nombre.

• kubelet : chaque nœud est associé à un agent appelé kubelet. Il garantit que le conteneur fonctionne correctement.

• kube-proxy : proxy réseau sur chaque nœud qui gère les nœuds de réseau et permet la communication entre les pods et les sessions réseau, à l’intérieur ou à l’extérieur du cluster .

• container runtime : logiciel responsable de l’exécution des applications conteneurisées. Même si Docker est le plus populaire, Kubernetes prend en charge tout runtime compatible avec l’interface Kubernetes CRI (Container Runtime Interface).



Architecture avec un seul node pour le controle plane et des workers



Architecture plusieurs node pour le controle plane avec workers



Combien de nœuds un cluster doit-il avoir ?

• Il n’y a pas de contrainte particulière (pas besoin d’avoir un nombre impair de nœuds pour le quorum)

• Un cluster peut avoir zéro nœud (mais il ne pourra alors démarrer aucun pod)

• Pour les tests et le développement, avoir un seul nœud est très bien

• Pour la production, assurez-vous d’avoir une capacité supplémentaire (afin que votre charge de travail reste adaptée si vous perdez un nœud ou un groupe de nœuds)

• Kubernetes est testé avec jusqu’à 5 000 nœuds (cependant, exécuter un cluster de cette taille nécessite beaucoup de réglages)

Faut-il vraiment exécuter Docker ?

Non!

• Le Docker Engine était l’option par défaut pour exécuter des conteneurs avec Kubernetes

• La prise en charge de Docker (en particulier : dockershim) a été supprimée dans Kubernetes 1.24

• Nous pouvons exploiter d’autres environnements d’exécution enfichables via l’interface Container Runtime

• On pourrait aussi utiliser rkt (“Rocket”) de CoreOS (obsolète)

Certains environnements d’exécution disponibles via CRI

• containerd
• maintenu par Docker, IBM et la communauté
• utilisé par Docker Engine, microk8s, k3s, GKE ; également autonome
• est livré avec sa propre CLI, ctr

• CRI-O :
• maintenu par Red Hat, SUSE et la communauté
• utilisé par OpenShift et Kubic
• conçu spécifiquement comme un runtime minimal pour Kubernetes

• Et plus

je vous ai préparé un training complet sur les Containers Runtime




1. Nous contactez

2. Infra as a Service

  • Description: Infrastructure cloud évolutive et sécurisée
  • Links:

3. Projets Développeurs

4. Développeurs

5. Formations Complètes

6. Marketplace

7. Blogs

This website is powered by ItGalaxy.io