|
1 | 1 | --- |
2 | | -title: Architecture de Kubernetes |
3 | | -description: Architecture Kubernetes |
| 2 | +title: "Architecture du cluster" |
4 | 3 | weight: 30 |
| 4 | +description: > |
| 5 | + Les concepts architecturaux derrière Kubernetes. |
5 | 6 | --- |
| 7 | + |
| 8 | +Un cluster Kubernetes est composé d'un plan de contrôle et d'un ensemble de machines de travail, appelées nœuds, qui exécutent des applications conteneurisées. |
| 9 | +Chaque cluster a besoin d'au moins un nœud de travail pour exécuter des Pods. |
| 10 | + |
| 11 | +Les nœuds de travail hébergent les Pods qui sont les composants de la charge de travail de l'application. |
| 12 | +Le plan de contrôle gère les nœuds de travail et les Pods du cluster. Dans les environnements de production, |
| 13 | +le plan de contrôle s'exécute généralement sur plusieurs ordinateurs et un cluster |
| 14 | +exécute généralement plusieurs nœuds, offrant une tolérance aux pannes et une haute disponibilité. |
| 15 | + |
| 16 | +Ce document décrit les différents composants nécessaires pour avoir un cluster Kubernetes complet et fonctionnel. |
| 17 | + |
| 18 | +{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="Le plan de contrôle (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) et plusieurs nœuds. Chaque nœud exécute un kubelet et kube-proxy." |
| 19 | +title="Composants du cluster Kubernetes" |
| 20 | +caption="**Remarque :** Ce diagramme présente une architecture de référence d'exemple pour un cluster Kubernetes. La répartition réelle des composants peut varier en fonction des configurations et des exigences spécifiques du cluster." class="diagram-large" >}} |
| 21 | + |
| 22 | +## Composants du plan de contrôle |
| 23 | + |
| 24 | +Les composants du plan de contrôle prennent des décisions globales sur le cluster (par exemple, la planification), |
| 25 | +ainsi que la détection et la réponse aux événements du cluster (par exemple, démarrer un nouveau |
| 26 | +{{< glossary_tooltip text="pod" term_id="pod">}} lorsque le champ `{{< glossary_tooltip text="replicas" term_id="replica" >}}` d'un déploiement |
| 27 | +n'est pas satisfait). |
| 28 | + |
| 29 | +Les composants du plan de contrôle peuvent s'exécuter sur n'importe quelle machine du cluster. Cependant, pour simplifier, les scripts d'installation |
| 30 | +démarrent généralement tous les composants du plan de contrôle sur la même machine et n'exécutent pas de conteneurs utilisateur sur cette machine. |
| 31 | +Consultez [Création de clusters hautement disponibles avec kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) |
| 32 | +pour un exemple de configuration du plan de contrôle s'exécutant sur plusieurs machines. |
| 33 | + |
| 34 | +### kube-apiserver |
| 35 | + |
| 36 | +{{< glossary_definition term_id="kube-apiserver" length="all" >}} |
| 37 | + |
| 38 | +### etcd |
| 39 | + |
| 40 | +{{< glossary_definition term_id="etcd" length="all" >}} |
| 41 | + |
| 42 | +### kube-scheduler |
| 43 | + |
| 44 | +{{< glossary_definition term_id="kube-scheduler" length="all" >}} |
| 45 | + |
| 46 | +### kube-controller-manager |
| 47 | + |
| 48 | +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} |
| 49 | + |
| 50 | +Il existe de nombreux types de contrôleurs différents. Voici quelques exemples : |
| 51 | + |
| 52 | +- Contrôleur de nœuds : Responsable de la détection et de la réponse lorsque les nœuds tombent en panne. |
| 53 | +- Contrôleur de tâches : Surveille les objets Job qui représentent des tâches ponctuelles, puis crée des Pods pour exécuter ces tâches jusqu'à leur achèvement. |
| 54 | +- Contrôleur EndpointSlice : Remplit les objets EndpointSlice (pour établir un lien entre les Services et les Pods). |
| 55 | +- Contrôleur ServiceAccount : Crée des comptes de service par défaut pour les nouveaux espaces de noms. |
| 56 | + |
| 57 | +Ce qui précède n'est pas une liste exhaustive. |
| 58 | + |
| 59 | +### cloud-controller-manager |
| 60 | + |
| 61 | +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} |
| 62 | + |
| 63 | +Le cloud-controller-manager exécute uniquement des contrôleurs spécifiques à votre fournisseur de cloud. |
| 64 | +Si vous exécutez Kubernetes sur vos propres serveurs ou dans un environnement d'apprentissage sur votre |
| 65 | +propre PC, le cluster n'a pas de cloud-controller-manager. |
| 66 | + |
| 67 | +Comme pour kube-controller-manager, cloud-controller-manager combine plusieurs boucles de contrôle logiquement |
| 68 | +indépendantes en un seul binaire que vous exécutez en tant que processus unique. Vous pouvez mettre à l'échelle |
| 69 | +horizontalement (exécuter plusieurs copies) pour améliorer les performances ou pour aider à tolérer les pannes. |
| 70 | + |
| 71 | +Les contrôleurs suivants peuvent avoir des dépendances vis-à-vis du fournisseur de cloud : |
| 72 | + |
| 73 | +- Contrôleur de nœuds : Pour vérifier auprès du fournisseur de cloud si un nœud a été |
| 74 | + supprimé dans le cloud après avoir cessé de répondre |
| 75 | +- Contrôleur de routage : Pour configurer les routes dans l'infrastructure cloud sous-jacente |
| 76 | +- Contrôleur de service : Pour créer, mettre à jour et supprimer des équilibreurs de charge du fournisseur de cloud |
| 77 | + |
| 78 | +## Composants du nœud |
| 79 | + |
| 80 | +Les composants du nœud s'exécutent sur chaque nœud, maintenant les Pods en cours d'exécution et fournissant l'environnement d'exécution Kubernetes. |
| 81 | + |
| 82 | +### kubelet |
| 83 | + |
| 84 | +{{< glossary_definition term_id="kubelet" length="all" >}} |
| 85 | + |
| 86 | +### kube-proxy (optionnel) {#kube-proxy} |
| 87 | + |
| 88 | +{{< glossary_definition term_id="kube-proxy" length="all" >}} |
| 89 | +Si vous utilisez un [plugin réseau](#network-plugins) qui implémente le transfert de paquets pour les Services |
| 90 | +par lui-même, et fournissant un comportement équivalent à kube-proxy, alors vous n'avez pas besoin d'exécuter |
| 91 | +kube-proxy sur les nœuds de votre cluster. |
| 92 | + |
| 93 | +### Runtime de conteneur |
| 94 | + |
| 95 | +{{< glossary_definition term_id="container-runtime" length="all" >}} |
| 96 | + |
| 97 | +## Add-ons |
| 98 | + |
| 99 | +Les add-ons utilisent des ressources Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, |
| 100 | +{{< glossary_tooltip term_id="deployment" >}}, etc.) pour implémenter des fonctionnalités de cluster. |
| 101 | +Étant donné qu'ils fournissent des fonctionnalités au niveau du cluster, les ressources des add-ons |
| 102 | +appartiennent à l'espace de noms `kube-system`. |
| 103 | + |
| 104 | +Certains add-ons sélectionnés sont décrits ci-dessous ; pour une liste étendue d'add-ons disponibles, |
| 105 | +veuillez consulter [Add-ons](/docs/concepts/cluster-administration/addons/). |
| 106 | + |
| 107 | +### DNS |
| 108 | + |
| 109 | +Bien que les autres add-ons ne soient pas strictement nécessaires, tous les clusters Kubernetes devraient avoir |
| 110 | +[DNS de cluster](/docs/concepts/services-networking/dns-pod-service/), car de nombreux exemples en dépendent. |
| 111 | + |
| 112 | +Le DNS de cluster est un serveur DNS, en plus des autres serveur(s) DNS de votre environnement, |
| 113 | +qui fournit des enregistrements DNS pour les services Kubernetes. |
| 114 | + |
| 115 | +Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS. |
| 116 | + |
| 117 | +### Interface utilisateur Web (Dashboard) |
| 118 | + |
| 119 | +[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur basée sur le web, |
| 120 | +générale, pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de résoudre les problèmes des applications |
| 121 | +en cours d'exécution dans le cluster, ainsi que du cluster lui-même. |
| 122 | + |
| 123 | +### Surveillance des ressources des conteneurs |
| 124 | + |
| 125 | +[Surveillance des ressources des conteneurs](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) |
| 126 | +enregistre des métriques génériques de séries chronologiques sur les conteneurs dans une base de données centrale et fournit une interface utilisateur pour parcourir ces données. |
| 127 | + |
| 128 | +### Journalisation au niveau du cluster |
| 129 | + |
| 130 | +Un mécanisme de [journalisation au niveau du cluster](/docs/concepts/cluster-administration/logging/) est responsable |
| 131 | +de l'enregistrement des journaux des conteneurs dans un magasin de journaux central avec une interface de recherche/parcours. |
| 132 | + |
| 133 | +### Plugins réseau |
| 134 | + |
| 135 | +[Les plugins réseau](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins) |
| 136 | +sont des composants logiciels qui implémentent la spécification de l'interface réseau de conteneur (CNI). |
| 137 | +Ils sont responsables de l'allocation des adresses IP aux pods et de leur permettre de communiquer |
| 138 | +entre eux au sein du cluster. |
| 139 | + |
| 140 | +## Variations de l'architecture |
| 141 | + |
| 142 | +Bien que les composants principaux de Kubernetes restent cohérents, la manière dont ils sont déployés et |
| 143 | +gérés peut varier. Comprendre ces variations est crucial pour concevoir et maintenir |
| 144 | +des clusters Kubernetes répondant à des besoins opérationnels spécifiques. |
| 145 | + |
| 146 | +### Options de déploiement du plan de contrôle |
| 147 | + |
| 148 | +Les composants du plan de contrôle peuvent être déployés de plusieurs manières : |
| 149 | + |
| 150 | +Déploiement traditionnel |
| 151 | +: Les composants du plan de contrôle s'exécutent directement sur des machines dédiées ou des machines virtuelles, souvent gérées en tant que services systemd. |
| 152 | + |
| 153 | +Pods statiques |
| 154 | +: Les composants du plan de contrôle sont déployés en tant que Pods statiques, gérés par le kubelet sur des nœuds spécifiques. |
| 155 | + Il s'agit d'une approche courante utilisée par des outils tels que kubeadm. |
| 156 | + |
| 157 | +Auto-hébergé |
| 158 | +: Le plan de contrôle s'exécute en tant que Pods au sein du cluster Kubernetes lui-même, gérés par des déploiements |
| 159 | + et des StatefulSets ou d'autres primitives Kubernetes. |
| 160 | + |
| 161 | +Services Kubernetes gérés |
| 162 | +: Les fournisseurs de cloud abstraient souvent le plan de contrôle, en gérant ses composants dans le cadre de leur offre de services. |
| 163 | + |
| 164 | +### Considérations pour le placement de la charge de travail |
| 165 | + |
| 166 | +Le placement des charges de travail, y compris les composants du plan de contrôle, peut varier en fonction de la taille du cluster, |
| 167 | +des exigences de performance et des politiques opérationnelles : |
| 168 | + |
| 169 | +- Dans les clusters plus petits ou de développement, les composants du plan de contrôle et les charges de travail des utilisateurs peuvent s'exécuter sur les mêmes nœuds. |
| 170 | +- Les clusters de production plus importants dédient souvent des nœuds spécifiques aux composants du plan de contrôle, |
| 171 | + les séparant des charges de travail des utilisateurs. |
| 172 | +- Certaines organisations exécutent des add-ons critiques ou des outils de surveillance sur les nœuds du plan de contrôle. |
| 173 | + |
| 174 | +### Outils de gestion de cluster |
| 175 | + |
| 176 | +Des outils tels que kubeadm, kops et Kubespray offrent différentes approches pour le déploiement et la gestion des clusters, |
| 177 | +chacun avec sa propre méthode de disposition et de gestion des composants. |
| 178 | + |
| 179 | +La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques, |
| 180 | +en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion. |
| 181 | + |
| 182 | +### Personnalisation et extensibilité |
| 183 | + |
| 184 | +L'architecture de Kubernetes permet une personnalisation significative : |
| 185 | + |
| 186 | +- Des ordonnanceurs personnalisés peuvent être déployés pour travailler aux côtés de l'ordonnanceur Kubernetes par défaut ou pour le remplacer entièrement. |
| 187 | +- Les serveurs API peuvent être étendus avec des CustomResourceDefinitions et une agrégation d'API. |
| 188 | +- Les fournisseurs de cloud peuvent s'intégrer profondément à Kubernetes en utilisant le cloud-controller-manager. |
| 189 | + |
| 190 | +La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques, |
| 191 | +en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion. |
| 192 | + |
| 193 | +## {{% heading "whatsnext" %}} |
| 194 | + |
| 195 | +En savoir plus sur les sujets suivants : |
| 196 | + |
| 197 | +- [Nœuds](/docs/concepts/architecture/nodes/) et |
| 198 | + [leur communication](/docs/concepts/architecture/control-plane-node-communication/) |
| 199 | + avec le plan de contrôle. |
| 200 | +- Les [contrôleurs](/docs/concepts/architecture/controller/) Kubernetes. |
| 201 | +- [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/), qui est l'ordonnanceur par défaut de Kubernetes. |
| 202 | +- La [documentation officielle](https://etcd.io/docs/) d'Etcd. |
| 203 | +- Plusieurs [runtimes de conteneurs](/docs/setup/production-environment/container-runtimes/) dans Kubernetes. |
| 204 | +- Intégration avec les fournisseurs de cloud en utilisant [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/). |
| 205 | +- Commandes [kubectl](/docs/reference/generated/kubectl/kubectl-commands). |
0 commit comments