Update French documentation for concept architecture

kubernetes · Sep 12, 2024 · 48766a9 · 48766a9
1 parent 7ba952a
commit 48766a9
Show file tree

Hide file tree

Showing 17 changed files with 1,578 additions and 374 deletions.
diff --git a/content/fr/docs/concepts/architecture/_index.md b/content/fr/docs/concepts/architecture/_index.md
@@ -1,5 +1,205 @@
 ---
-title: Architecture de Kubernetes
-description: Architecture Kubernetes
+title: "Architecture du cluster"
 weight: 30
+description: >
+  Les concepts architecturaux derrière Kubernetes.
 ---
+
+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. 
+Chaque cluster a besoin d'au moins un nœud de travail pour exécuter des Pods.
+
+Les nœuds de travail hébergent les Pods qui sont les composants de la charge de travail de l'application.
+Le plan de contrôle gère les nœuds de travail et les Pods du cluster. Dans les environnements de production,
+le plan de contrôle s'exécute généralement sur plusieurs ordinateurs et un cluster
+exécute généralement plusieurs nœuds, offrant une tolérance aux pannes et une haute disponibilité.
+
+Ce document décrit les différents composants nécessaires pour avoir un cluster Kubernetes complet et fonctionnel.
+
+{{< 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."
+title="Composants du cluster Kubernetes"
+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" >}}
+
+## Composants du plan de contrôle
+
+Les composants du plan de contrôle prennent des décisions globales sur le cluster (par exemple, la planification),
+ainsi que la détection et la réponse aux événements du cluster (par exemple, démarrer un nouveau
+{{< glossary_tooltip text="pod" term_id="pod">}} lorsque le champ `{{< glossary_tooltip text="replicas" term_id="replica" >}}` d'un déploiement
+n'est pas satisfait).
+
+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
+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.
+Consultez [Création de clusters hautement disponibles avec kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
+pour un exemple de configuration du plan de contrôle s'exécutant sur plusieurs machines.
+
+### kube-apiserver
+
+{{< glossary_definition term_id="kube-apiserver" length="all" >}}
+
+### etcd
+
+{{< glossary_definition term_id="etcd" length="all" >}}
+
+### kube-scheduler
+
+{{< glossary_definition term_id="kube-scheduler" length="all" >}}
+
+### kube-controller-manager
+
+{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
+
+Il existe de nombreux types de contrôleurs différents. Voici quelques exemples :
+
+- Contrôleur de nœuds : Responsable de la détection et de la réponse lorsque les nœuds tombent en panne.
+- 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.
+- Contrôleur EndpointSlice : Remplit les objets EndpointSlice (pour établir un lien entre les Services et les Pods).
+- Contrôleur ServiceAccount : Crée des comptes de service par défaut pour les nouveaux espaces de noms.
+
+Ce qui précède n'est pas une liste exhaustive.
+
+### cloud-controller-manager
+
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+
+Le cloud-controller-manager exécute uniquement des contrôleurs spécifiques à votre fournisseur de cloud.
+Si vous exécutez Kubernetes sur vos propres serveurs ou dans un environnement d'apprentissage sur votre
+propre PC, le cluster n'a pas de cloud-controller-manager.
+
+Comme pour kube-controller-manager, cloud-controller-manager combine plusieurs boucles de contrôle logiquement
+indépendantes en un seul binaire que vous exécutez en tant que processus unique. Vous pouvez mettre à l'échelle
+horizontalement (exécuter plusieurs copies) pour améliorer les performances ou pour aider à tolérer les pannes.
+
+Les contrôleurs suivants peuvent avoir des dépendances vis-à-vis du fournisseur de cloud :
+
+- Contrôleur de nœuds : Pour vérifier auprès du fournisseur de cloud si un nœud a été
+  supprimé dans le cloud après avoir cessé de répondre
+- Contrôleur de routage : Pour configurer les routes dans l'infrastructure cloud sous-jacente
+- Contrôleur de service : Pour créer, mettre à jour et supprimer des équilibreurs de charge du fournisseur de cloud
+
+## Composants du nœud
+
+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.
+
+### kubelet
+
+{{< glossary_definition term_id="kubelet" length="all" >}}
+
+### kube-proxy (optionnel) {#kube-proxy}
+
+{{< glossary_definition term_id="kube-proxy" length="all" >}}
+Si vous utilisez un [plugin réseau](#network-plugins) qui implémente le transfert de paquets pour les Services
+par lui-même, et fournissant un comportement équivalent à kube-proxy, alors vous n'avez pas besoin d'exécuter
+kube-proxy sur les nœuds de votre cluster.
+
+### Runtime de conteneur
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## Add-ons
+
+Les add-ons utilisent des ressources Kubernetes ({{< glossary_tooltip term_id="daemonset" >}},
+{{< glossary_tooltip term_id="deployment" >}}, etc.) pour implémenter des fonctionnalités de cluster.
+Étant donné qu'ils fournissent des fonctionnalités au niveau du cluster, les ressources des add-ons
+appartiennent à l'espace de noms `kube-system`.
+
+Certains add-ons sélectionnés sont décrits ci-dessous ; pour une liste étendue d'add-ons disponibles,
+veuillez consulter [Add-ons](/docs/concepts/cluster-administration/addons/).
+
+### DNS
+
+Bien que les autres add-ons ne soient pas strictement nécessaires, tous les clusters Kubernetes devraient avoir
+[DNS de cluster](/docs/concepts/services-networking/dns-pod-service/), car de nombreux exemples en dépendent.
+
+Le DNS de cluster est un serveur DNS, en plus des autres serveur(s) DNS de votre environnement,
+qui fournit des enregistrements DNS pour les services Kubernetes.
+
+Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS.
+
+### Interface utilisateur Web (Dashboard)
+
+[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur basée sur le web,
+générale, pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de résoudre les problèmes des applications
+en cours d'exécution dans le cluster, ainsi que du cluster lui-même.
+
+### Surveillance des ressources des conteneurs
+
+[Surveillance des ressources des conteneurs](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
+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.
+
+### Journalisation au niveau du cluster
+
+Un mécanisme de [journalisation au niveau du cluster](/docs/concepts/cluster-administration/logging/) est responsable
+de l'enregistrement des journaux des conteneurs dans un magasin de journaux central avec une interface de recherche/parcours.
+
+### Plugins réseau
+
+[Les plugins réseau](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins)
+sont des composants logiciels qui implémentent la spécification de l'interface réseau de conteneur (CNI).
+Ils sont responsables de l'allocation des adresses IP aux pods et de leur permettre de communiquer
+entre eux au sein du cluster.
+
+## Variations de l'architecture
+
+Bien que les composants principaux de Kubernetes restent cohérents, la manière dont ils sont déployés et
+gérés peut varier. Comprendre ces variations est crucial pour concevoir et maintenir
+des clusters Kubernetes répondant à des besoins opérationnels spécifiques.
+
+### Options de déploiement du plan de contrôle
+
+Les composants du plan de contrôle peuvent être déployés de plusieurs manières :
+
+Déploiement traditionnel
+: 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.
+
+Pods statiques
+: 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.
+  Il s'agit d'une approche courante utilisée par des outils tels que kubeadm.
+
+Auto-hébergé
+: 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
+  et des StatefulSets ou d'autres primitives Kubernetes.
+
+Services Kubernetes gérés
+: Les fournisseurs de cloud abstraient souvent le plan de contrôle, en gérant ses composants dans le cadre de leur offre de services.
+
+### Considérations pour le placement de la charge de travail
+
+Le placement des charges de travail, y compris les composants du plan de contrôle, peut varier en fonction de la taille du cluster,
+des exigences de performance et des politiques opérationnelles :
+
+- 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.
+- Les clusters de production plus importants dédient souvent des nœuds spécifiques aux composants du plan de contrôle,
+  les séparant des charges de travail des utilisateurs.
+- Certaines organisations exécutent des add-ons critiques ou des outils de surveillance sur les nœuds du plan de contrôle.
+
+### Outils de gestion de cluster
+
+Des outils tels que kubeadm, kops et Kubespray offrent différentes approches pour le déploiement et la gestion des clusters,
+chacun avec sa propre méthode de disposition et de gestion des composants.
+
+La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques,
+en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion.
+
+### Personnalisation et extensibilité
+
+L'architecture de Kubernetes permet une personnalisation significative :
+
+- 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.
+- Les serveurs API peuvent être étendus avec des CustomResourceDefinitions et une agrégation d'API.
+- Les fournisseurs de cloud peuvent s'intégrer profondément à Kubernetes en utilisant le cloud-controller-manager.
+
+La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques,
+en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion.
+
+## {{% heading "whatsnext" %}}
+
+En savoir plus sur les sujets suivants :
+
+- [Nœuds](/docs/concepts/architecture/nodes/) et
+  [leur communication](/docs/concepts/architecture/control-plane-node-communication/)
+  avec le plan de contrôle.
+- Les [contrôleurs](/docs/concepts/architecture/controller/) Kubernetes.
+- [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/), qui est l'ordonnanceur par défaut de Kubernetes.
+- La [documentation officielle](https://etcd.io/docs/) d'Etcd.
+- Plusieurs [runtimes de conteneurs](/docs/setup/production-environment/container-runtimes/) dans Kubernetes.
+- Intégration avec les fournisseurs de cloud en utilisant [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
+- Commandes [kubectl](/docs/reference/generated/kubectl/kubectl-commands).
diff --git a/content/fr/docs/concepts/architecture/cgroups.md b/content/fr/docs/concepts/architecture/cgroups.md
@@ -0,0 +1,131 @@
+---
+title: À propos de cgroup v2
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+Sur Linux, les {{< glossary_tooltip text="groupes de contrôle" term_id="cgroup" >}}
+limitent les ressources allouées aux processus.
+
+Le {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} et le
+runtime de conteneur sous-jacent doivent interagir avec les cgroups pour appliquer
+[la gestion des ressources pour les pods et les conteneurs](/docs/concepts/configuration/manage-resources-containers/), ce qui
+inclut les demandes et les limites de CPU/mémoire pour les charges de travail conteneurisées.
+
+Il existe deux versions de cgroups sur Linux : cgroup v1 et cgroup v2. cgroup v2 est
+la nouvelle génération de l'API `cgroup`.
+
+<!-- body -->
+
+
+## Qu'est-ce que cgroup v2 ? {#cgroup-v2}
+{{< feature-state for_k8s_version="v1.25" state="stable" >}}
+
+cgroup v2 est la prochaine version de l'API `cgroup` de Linux. cgroup v2 offre un
+système de contrôle unifié avec des capacités de gestion des ressources améliorées.
+
+
+cgroup v2 propose plusieurs améliorations par rapport à cgroup v1, telles que :
+
+- Conception d'une hiérarchie unifiée unique dans l'API
+- Délégation plus sûre des sous-arbres aux conteneurs
+- Nouvelles fonctionnalités telles que [Pressure Stall Information](https://www.kernel.org/doc/html/latest/accounting/psi.html)
+- Gestion améliorée de l'allocation des ressources et de l'isolation sur plusieurs ressources
+  - Comptabilité unifiée pour différents types d'allocations de mémoire (mémoire réseau, mémoire du noyau, etc.)
+  - Comptabilité des modifications de ressources non immédiates, telles que les écritures de cache de pages
+
+Certaines fonctionnalités de Kubernetes utilisent exclusivement cgroup v2 pour une 
+gestion des ressources et une isolation améliorées. Par exemple, la fonctionnalité
+[MemoryQoS](/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2) améliore la QoS de la mémoire
+et repose sur les primitives cgroup v2.
+
+
+## Utilisation de cgroup v2 {#using-cgroupv2}
+
+La manière recommandée d'utiliser cgroup v2 est d'utiliser une distribution Linux qui
+active et utilise cgroup v2 par défaut.
+
+Pour vérifier si votre distribution utilise cgroup v2, consultez [Identifier la version de cgroup sur les nœuds Linux](#check-cgroup-version).
+
+### Exigences
+
+cgroup v2 a les exigences suivantes :
+
+* La distribution OS active cgroup v2
+* La version du noyau Linux est 5.8 ou ultérieure
+* Le runtime de conteneur prend en charge cgroup v2. Par exemple :
+  * [containerd](https://containerd.io/) v1.4 et ultérieur
+  * [cri-o](https://cri-o.io/) v1.20 et ultérieur
+* Le kubelet et le runtime de conteneur sont configurés pour utiliser le [driver cgroup systemd](/docs/setup/production-environment/container-runtimes#systemd-cgroup-driver)
+
+### Prise en charge de cgroup v2 par les distributions Linux
+
+Pour une liste des distributions Linux qui utilisent cgroup v2, consultez la [documentation cgroup v2](https://github.com/opencontainers/runc/blob/main/docs/cgroup-v2.md)
+
+<!-- la liste doit être synchronisée avec https://github.com/opencontainers/runc/blob/main/docs/cgroup-v2.md -->
+* Container Optimized OS (depuis M97)
+* Ubuntu (depuis 21.10, 22.04+ recommandé)
+* Debian GNU/Linux (depuis Debian 11 bullseye)
+* Fedora (depuis 31)
+* Arch Linux (depuis avril 2021)
+* RHEL et les distributions similaires à RHEL (depuis 9)
+
+Pour vérifier si votre distribution utilise cgroup v2, consultez la
+documentation de votre distribution ou suivez les instructions de [Identifier la version de cgroup sur les nœuds Linux](#check-cgroup-version).
+
+Vous pouvez également activer manuellement cgroup v2 sur votre distribution Linux en modifiant
+les arguments de démarrage de la ligne de commande du noyau. Si votre distribution utilise GRUB,
+`systemd.unified_cgroup_hierarchy=1` doit être ajouté dans `GRUB_CMDLINE_LINUX`
+sous `/etc/default/grub`, suivi de `sudo update-grub`. 
+Cependant, l'approche recommandée est d'utiliser une distribution qui active déjà cgroup v2 par
+défaut.
+
+### Migration vers cgroup v2 {#migrating-cgroupv2}
+
+Pour migrer vers cgroup v2, assurez-vous de respecter les [exigences](#requirements), puis mettez à jour
+vers une version du noyau qui active cgroup v2 par défaut.
+
+Le kubelet détecte automatiquement si le système d'exploitation utilise cgroup v2 et
+agit en conséquence, sans nécessiter de configuration supplémentaire.
+
+Il ne devrait pas y avoir de différence perceptible dans l'expérience utilisateur lors du
+passage à cgroup v2, sauf si les utilisateurs accèdent directement au système de fichiers cgroup
+soit sur le nœud, soit depuis les conteneurs.
+
+cgroup v2 utilise une API différente de cgroup v1, donc si des
+applications accèdent directement au système de fichiers cgroup, elles doivent être
+mises à jour vers des versions plus récentes qui prennent en charge cgroup v2. Par exemple :
+
+* Certains agents de surveillance et de sécurité tiers peuvent dépendre du système de fichiers cgroup.
+ Mettez à jour ces agents vers des versions qui prennent en charge cgroup v2.
+* Si vous exécutez [cAdvisor](https://github.com/google/cadvisor) en tant que DaemonSet autonome 
+pour surveiller les pods et les conteneurs, mettez-le à jour vers la version 0.43.0 ou ultérieure.
+* Si vous déployez des applications Java, préférez utiliser des versions qui prennent en charge pleinement cgroup v2 :
+    * [OpenJDK / HotSpot](https://bugs.openjdk.org/browse/JDK-8230305) : jdk8u372, 11.0.16, 15 et ultérieures
+    * [IBM Semeru Runtimes](https://www.ibm.com/support/pages/apar/IJ46681) : 8.0.382.0, 11.0.20.0, 17.0.8.0 et ultérieures
+    * [IBM Java](https://www.ibm.com/support/pages/apar/IJ46681) : 8.0.8.6 et ultérieures
+* Si vous utilisez le package [uber-go/automaxprocs](https://github.com/uber-go/automaxprocs), assurez-vous
+  d'utiliser la version v1.5.1 ou supérieure.
+
+## Identifier la version de cgroup sur les nœuds Linux {#check-cgroup-version}
+
+La version de cgroup dépend de la distribution Linux utilisée et de la
+version de cgroup par défaut configurée sur le système d'exploitation. Pour vérifier quelle version de cgroup votre
+distribution utilise, exécutez la commande `stat -fc %T /sys/fs/cgroup/` sur
+le nœud :
+
+```shell
+stat -fc %T /sys/fs/cgroup/
+```
+
+Pour cgroup v2, la sortie est `cgroup2fs`.
+
+Pour cgroup v1, la sortie est `tmpfs.`
+
+## {{% heading "whatsnext" %}}
+
+- En savoir plus sur [cgroups](https://man7.org/linux/man-pages/man7/cgroups.7.html)
+- En savoir plus sur [le runtime de conteneur](/docs/concepts/architecture/cri)
+- En savoir plus sur [les drivers cgroup](/docs/setup/production-environment/container-runtimes#cgroup-drivers)