kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update French documentation for concept architecture

pull/47898/head
Christophe Gasmi 2024-09-12 17:07:22 +02:00
parent 7ba952a4e0
commit 48766a92ac
17 changed files with 1611 additions and 407 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

204
content/fr/docs/concepts/architecture/_index.md
View File

@ -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).

131
content/fr/docs/concepts/architecture/cgroups.md Normal file
View File

@ -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)

264
content/fr/docs/concepts/architecture/cloud-controller.md
View File

@ -1,184 +1,145 @@
---
title: Concepts sous-jacents au Cloud Controller Manager
title: Gestionnaire du contrôleur de cloud
content_type: concept
weight: 30
weight: 40
---
<!-- overview -->
Le concept de cloud controller manager (CCM) (ne pas confondre avec le binaire) a été créé à l'origine pour permettre au code de fournisseur spécifique de cloud et au noyau Kubernetes d'évoluer indépendamment les uns des autres.
Le gestionnaire de contrôleur de cloud fonctionne aux côtés d'autres composants principaux, tels que le gestionnaire de contrôleur Kubernetes, le serveur d'API et le planificateur.
Il peut également être démarré en tant qu’addon Kubernetes, auquel cas il s’exécute sur Kubernetes.
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
La conception du gestionnaire de contrôleur de cloud repose sur un mécanisme de plugin qui permet aux nouveaux fournisseurs de cloud de s'intégrer facilement à Kubernetes à l'aide de plugins.
Des plans sont en place pour intégrer de nouveaux fournisseurs de cloud sur Kubernetes et pour migrer les fournisseurs de cloud de l'ancien modèle vers le nouveau modèle CCM.
Ce document discute des concepts derrière le cloud controller manager et donne des détails sur ses fonctions associées.
Voici l'architecture d'un cluster Kubernetes sans le cloud controller manager:
![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
Les technologies d'infrastructure cloud vous permettent d'exécuter Kubernetes sur des clouds publics, privés et hybrides.
Kubernetes croit en une infrastructure automatisée pilotée par API sans couplage
étroit entre les composants.
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Le gestionnaire du contrôleur de cloud est">}}
Le gestionnaire du contrôleur de cloud est structuré à l'aide d'un mécanisme de plugin
qui permet aux différents fournisseurs de cloud d'intégrer leurs plateformes à Kubernetes.
<!-- body -->
## Conception
Dans le diagramme précédent, Kubernetes et le fournisseur de cloud sont intégrés via plusieurs composants différents:
![Composants de Kubernetes](/images/docs/components-of-kubernetes.svg)
* Kubelet
* Kubernetes controller manager
* Kubernetes API server
Le gestionnaire du contrôleur de cloud s'exécute dans le plan de contrôle en tant qu'ensemble répliqué de processus
(généralement, ce sont des conteneurs dans des Pods). Chaque gestionnaire du contrôleur de cloud implémente
plusieurs {{< glossary_tooltip text="contrôleurs" term_id="controller" >}}
dans un seul processus.
Le CCM consolide toute la logique dépendante du cloud des trois composants précédents pour créer un point d’intégration unique avec le cloud.
La nouvelle architecture avec le CCM se présente comme suit:
![CCM Kube Arch](/images/docs/post-ccm-arch.png)
## Composants du CCM
Le CCM rompt certaines fonctionnalités du Kubernetes Controller Manager (KCM) et les exécute en tant que processus séparé.
Plus précisément, il sépare les contrôleurs du KCM qui dépendent du cloud.
Le KCM comporte les boucles de contrôle dépendant du cloud suivantes:
* Contrôleur de nœud
* Contrôleur de volume
* Contrôleur de route
* Contrôleur de service
Dans la version 1.9, le CCM exécute les contrôleurs suivants de la liste précédente:
* Contrôleur de nœud
* Contrôleur de route
* Contrôleur de service
{{< note >}}
Le contrôleur de volume a été délibérément choisi pour ne pas faire partie de CCM.
En raison de la complexité du processus et des efforts déployés pour supprimer la logique de volume spécifique au fournisseur, il a été décidé que le contrôleur de volume ne serait pas déplacé vers CCM.
Vous pouvez également exécuter le gestionnaire du contrôleur de cloud en tant que
{{< glossary_tooltip text="addon" term_id="addons" >}} Kubernetes plutôt que
de le faire partie du plan de contrôle.
{{< /note >}}
Le plan initial de prise en charge des volumes à l'aide de CCM consistait à utiliser des volumes Flex pour prendre en charge des volumes pouvant être connectés.
Cependant, un effort concurrentiel appelé CSI est prévu pour remplacer Flex.
## Fonctions du gestionnaire du contrôleur de cloud {#fonctions-du-ccm}
Compte tenu de cette dynamique, nous avons décidé d'avoir une mesure de transition intermédiaire jusqu'à ce que le CSI soit prêt.
## Fonctions du CCM
Le CCM hérite ses fonctions des composants de Kubernetes qui dépendent d'un fournisseur de cloud.
Cette section est structurée en fonction de ces composants.
### 1. Kubernetes controller manager
La majorité des fonctions du CCM sont dérivées du KCM.
Comme indiqué dans la section précédente, le CCM exécute les boucles de contrôle suivantes:
* Contrôleur de nœud
* Contrôleur de route
* Contrôleur de service
#### Contrôleur de nœud
Le contrôleur de noeud est responsable de l'initialisation d'un noeud en obtenant des informations sur les noeuds s'exécutant dans le cluster auprès du fournisseur de cloud.
Le contrôleur de noeud exécute les fonctions suivantes:
1. Il initialise le nœud avec des labels de zone/région spécifiques au cloud.
2. Il initialise le nœud avec des détails d'instance spécifiques au cloud, tels que le type et la taille de l'instance.
3. Il obtient les adresses réseau et le nom d'hôte du nœud.
4. Si un nœud ne répond plus, le controlleur vérifie avec le cloud pour voir s'il a été supprimé du cloud.
Si le nœud a été supprimé du cloud, le controlleur supprime l'objet Kubernetes Node.
#### Contrôleur de route
Le contrôleur de route est responsable de la configuration appropriée des itinéraires dans le cloud afin que les conteneurs situés sur différents nœuds du cluster Kubernetes puissent communiquer entre eux.
Le contrôleur de route ne s'applique qu'aux clusters Google Compute Engine.
#### Contrôleur de service
Le contrôleur de service est chargé d'écouter les événements de création, de mise à jour et de suppression de service.
En fonction de l'état actuel des services dans Kubernetes, il configure les équilibreurs de charge dans le cloud (tels que ELB, Google LB ou Oracle Cloud Infrastructure LB) pour refléter l'état des services dans Kubernetes.
De plus, cela garantit que les services de base des services pour les load balancers dans le cloud sont à jour.
### 2. Kubelet
Le contrôleur de noeud contient les fonctionnalités du kubelet dépendant du cloud.
Avant l'introduction du CCM, la sous-unité était responsable de l'initialisation d'un nœud avec des détails spécifiques au cloud, tels que les adresses IP, les étiquettes de région / zone et les informations de type d'instance.
L’introduction du CCM a déplacé cette opération d’initialisation du kubelet vers le CCM.
Dans ce nouveau modèle, le kubelet initialise un nœud sans informations spécifiques au cloud.
Cependant, il ajoute un marquage au nœud nouvellement créé, qui rend le nœud non planifiable jusqu'à ce que le CCM initialise le nœud avec des informations spécifiques au cloud.
Il supprime ensuite ce marquage.
## Mécanisme de plugin
Le cloud controller manager utilise des interfaces Go pour autoriser la mise en œuvre d'implémentations depuis n'importe quel cloud.
Plus précisément, il utilise l'interface CloudProvider définie [ici](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
La mise en œuvre des quatre contrôleurs partagés soulignés ci-dessus, ainsi que certaines configurations ainsi que l'interface partagée du fournisseur de cloud, resteront dans le noyau Kubernetes.
Les implémentations spécifiques aux fournisseurs de cloud seront construites en dehors du noyau et implémenteront les interfaces définies dans le noyau.
Pour plus d’informations sur le développement de plugins, consultez [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
## Autorisation
Cette section détaille les accès requis par le CCM sur divers objets API pour effectuer ses opérations.
Les contrôleurs à l'intérieur du gestionnaire du contrôleur de cloud comprennent :
### Contrôleur de nœud
Le contrôleur de noeud ne fonctionne qu'avec les objets de noeud.
Il nécessite un accès complet aux objets Node via get, list, create, update, patch, watch et delete.
Le contrôleur de nœud est responsable de la mise à jour des objets {{< glossary_tooltip text="Nœud" term_id="node" >}}
lorsque de nouveaux serveurs sont créés dans votre infrastructure cloud. Le contrôleur de nœud obtient des informations sur les
hôtes en cours d'exécution dans votre tenancy avec le fournisseur de cloud. Le contrôleur de nœud effectue les fonctions suivantes :
v1/Node:
1. Mettre à jour un objet Nœud avec l'identifiant unique du serveur obtenu à partir de l'API du fournisseur de cloud.
1. Annoter et étiqueter l'objet Nœud avec des informations spécifiques au cloud, telles que la région dans laquelle le nœud
est déployé et les ressources (CPU, mémoire, etc.) dont il dispose.
1. Obtenir le nom d'hôte et les adresses réseau du nœud.
1. Vérifier la santé du nœud. Si un nœud devient non réactif, ce contrôleur vérifie
auprès de l'API de votre fournisseur de cloud si le serveur a été désactivé / supprimé / terminé.
Si le nœud a été supprimé du cloud, le contrôleur supprime l'objet Nœud
de votre cluster Kubernetes.
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
Certaines implémentations de fournisseurs de cloud divisent cela en un contrôleur de nœud
et un contrôleur de cycle de vie de nœud distinct.
### Contrôleur de route
Le contrôleur de route écoute les évenements de création d'objet Node et configure les routes de manière appropriée.
Cela nécessite un accès get aux objets Node.
Le contrôleur de route est responsable de la configuration des routes dans le cloud
de manière appropriée afin que les conteneurs sur différents nœuds de votre cluster Kubernetes
puissent communiquer entre eux.
v1/Node:
Selon le fournisseur de cloud, le contrôleur de route peut également allouer des blocs
d'adresses IP pour le réseau de Pod.
- Get
### Contrôleur de service
### Contrôleur de Service
{{< glossary_tooltip text="Les services" term_id="service" >}} s'intègrent aux composants d'infrastructure cloud tels que les équilibreurs de charge gérés, les adresses IP, le filtrage des paquets réseau
et la vérification de l'état de la cible. Le contrôleur de service interagit avec les API de votre
fournisseur de cloud pour configurer les équilibreurs de charge et autres composants
d'infrastructure
lorsque vous déclarez une ressource Service qui les nécessite.
Le contrôleur de service écoute les évenements de création, suppression et mises à jour des objets Service et configure les endpoints pour ces Services de manière appropriée.
## Autorisation
Pour accéder aux Services, il faut les accès list et watch.
Pour mettre à jour les Services, il faut les accès patch et update.
Cette section détaille l'accès requis par le gestionnaire du contrôleur de cloud
sur divers objets API pour effectuer ses opérations.
Pour configurer des points de terminaison pour les services, vous devez avoir accès au create, list, get, watch, et update.
### Contrôleur de nœud {#autorisation-contrôleur-de-nœud}
v1/Service:
Le contrôleur de nœud ne fonctionne qu'avec les objets Nœud. Il nécessite un accès complet
pour lire et modifier les objets Nœud.
- List
- Get
- Watch
- Patch
- Update
`v1/Node` :
### Autres
- get
- list
- create
- update
- patch
- watch
- delete
La mise en œuvre du CCM nécessite un accès pour créer des événements, et pour garantir un fonctionnement sécurisé, un accès est nécessaire pour créer ServiceAccounts.
### Contrôleur de route {#autorisation-contrôleur-de-route}
v1/Event:
Le contrôleur de route écoute la création d'objets Nœud et configure
les routes de manière appropriée. Il nécessite un accès Get aux objets Nœud.
- Create
- Patch
- Update
`v1/Node` :
v1/ServiceAccount:
- get
- Create
### Contrôleur de service {#autorisation-contrôleur-de-service}
Le ClusterRole RBAC pour le CCM ressemble à ceci:
Le contrôleur de service surveille les événements de création, de mise à jour et de suppression des objets Service, puis
configure les Endpoints pour ces Services de manière appropriée (pour les EndpointSlices, le
kube-controller-manager les gère à la demande).
Pour accéder aux Services, il nécessite un accès **list** et **watch**. Pour mettre à jour les Services, il nécessite
un accès **patch** et **update**.
Pour configurer les ressources Endpoints pour les Services, il nécessite un accès **create**, **list**,
**get**, **watch** et **update**.
`v1/Service` :
- list
- get
- watch
- patch
- update
### Autres {#autorisation-divers}
La mise en œuvre du cœur du gestionnaire du contrôleur de cloud nécessite un accès pour créer des objets Event
et pour assurer un fonctionnement sécurisé, il nécessite un accès pour créer des comptes de service.
`v1/Event` :
- create
- patch
- update
`v1/ServiceAccount` :
- create
Le ClusterRole {{< glossary_tooltip term_id="rbac" text="RBAC" >}} pour le gestionnaire du
contrôleur de cloud ressemble à ceci :
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@ -242,21 +203,24 @@ rules:
- update
```
## Implémentations des fournisseurs de cloud
Les fournisseurs de cloud suivants ont implémenté leur CCM:
## {{% heading "whatsnext" %}}
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
* [Scaleway](https://github.com/scaleway/scaleway-cloud-controller-manager)
* [Administration du gestionnaire du contrôleur de cloud](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
contient des instructions sur l'exécution et la gestion du gestionnaire du contrôleur de cloud.
## Administration de cluster
Des instructions complètes pour la configuration et l'exécution du CCM sont fournies [ici](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
* Pour mettre à niveau un plan de contrôle haute disponibilité pour utiliser le gestionnaire du contrôleur de cloud, consultez
[Migrer le plan de contrôle répliqué pour utiliser le gestionnaire du contrôleur de cloud](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
* Vous voulez savoir comment implémenter votre propre gestionnaire du contrôleur de cloud ou étendre un projet existant ?
- Le gestionnaire du contrôleur de cloud utilise des interfaces Go, en particulier, l'interface `CloudProvider` définie dans
[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)
de [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider) pour permettre
l'intégration de toutes les implémentations de cloud.
- La mise en œuvre des contrôleurs partagés mis en évidence dans ce document (Nœud, Route et Service),
ainsi que certaines structures de base avec l'interface cloudprovider partagée, font partie du cœur de Kubernetes.
Les implémentations spécifiques aux fournisseurs de cloud se trouvent en dehors du cœur de Kubernetes et implémentent
l'interface `CloudProvider`.
- Pour plus d'informations sur le développement de plugins,
consultez [Développement du gestionnaire du contrôleur de cloud](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).

126
content/fr/docs/concepts/architecture/control-plane-node-communication.md Normal file
View File

@ -0,0 +1,126 @@
---
title: Communication entre les nœuds et le plan de contrôle
content_type: concept
weight: 20
aliases:
- communication-noeud-plan-controle
---
<!-- overview -->
Ce document répertorie les chemins de communication entre le {{< glossary_tooltip term_id="kube-apiserver" text="serveur API" >}}
et le {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}} Kubernetes.
L'objectif est de permettre aux utilisateurs de personnaliser leur installation pour renforcer la configuration réseau
afin que le cluster puisse fonctionner sur un réseau non fiable (ou sur des adresses IP publiques complètement)
fournies par un fournisseur de cloud.
<!-- body -->
## Nœud vers le plan de contrôle
Kubernetes utilise un modèle d'API de type "hub-et-spoke". Toutes les utilisations de l'API à partir des nœuds (ou des pods qu'ils exécutent)
se terminent au niveau du serveur API. Aucun des autres composants du plan de contrôle n'est conçu pour exposer
des services distants. Le serveur API est configuré pour écouter les connexions distantes sur un port HTTPS sécurisé
(généralement le port 443) avec une ou plusieurs formes d'authentification
[client](/docs/reference/access-authn-authz/authentication/) activées.
Une ou plusieurs formes d'[autorisation](/docs/reference/access-authn-authz/authorization/) devraient être
activées, en particulier si les [requêtes anonymes](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
ou les [jetons de compte de service](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
sont autorisés.
Les nœuds doivent être provisionnés avec le {{< glossary_tooltip text="certificat" term_id="certificate" >}} racine public pour le cluster afin qu'ils puissent
se connecter de manière sécurisée au serveur API avec des informations d'identification client valides. Une bonne approche consiste à ce que les
informations d'identification client fournies au kubelet soient sous la forme d'un certificat client. Consultez
[l'amorçage TLS du kubelet](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
pour la provision automatisée des certificats client du kubelet.
Les {{< glossary_tooltip text="pods" term_id="pod" >}} qui souhaitent se connecter au serveur API peuvent le faire de manière sécurisée en utilisant un compte de service de sorte
que Kubernetes injecte automatiquement le certificat racine public et un jeton d'accès valide
dans le pod lors de son instanciation.
Le service `kubernetes` (dans l'espace de noms `default`) est configuré avec une adresse IP virtuelle qui est
redirigée (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) vers le point de terminaison HTTPS du serveur API.
Les composants du plan de contrôle communiquent également avec le serveur API via le port sécurisé.
Par conséquent, le mode de fonctionnement par défaut des connexions des nœuds et des pods exécutés sur les
nœuds vers le plan de contrôle est sécurisé par défaut et peut fonctionner sur des
réseaux non fiables et/ou publics.
## Plan de contrôle vers le nœud
Il existe deux chemins de communication principaux du plan de contrôle (le serveur API) vers les nœuds.
Le premier est du serveur API au processus {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} qui s'exécute sur chaque nœud du cluster.
Le deuxième est du serveur API vers n'importe quel nœud, pod ou service via la fonctionnalité de _proxy_ du serveur API.
### Serveur API vers kubelet
Les connexions du serveur API au kubelet sont utilisées pour :
* Récupérer les journaux des pods.
* Se connecter (généralement via `kubectl`) aux pods en cours d'exécution.
* Fournir la fonctionnalité de transfert de port du kubelet.
Ces connexions se terminent au niveau du point de terminaison HTTPS du kubelet. Par défaut, le serveur API ne vérifie pas
le certificat de service du kubelet, ce qui rend la connexion vulnérable aux
attaques de l'homme du milieu et **non sécurisée** pour une utilisation
sur des réseaux non fiables et/ou publics.
Pour vérifier cette connexion, utilisez le paramètre `--kubelet-certificate-authority`
pour fournir au serveur API un ensemble de certificats racine à utiliser pour vérifier le certificat de service du kubelet.
Si cela n'est pas possible, utilisez le [tunnel SSH](#tunnels-ssh) entre le serveur API et le kubelet si
nécessaire pour éviter de se connecter via un
réseau non fiable ou public.
Enfin, l'[authentification et/ou l'autorisation du kubelet](/docs/reference/access-authn-authz/kubelet-authn-authz/)
devraient être activées pour sécuriser l'API du kubelet.
### Serveur API vers les nœuds, les pods et les services
Les connexions du serveur API vers un nœud, un pod ou un service sont par défaut des connexions HTTP non sécurisées
et ne sont donc ni authentifiées ni chiffrées. Elles peuvent être exécutées via une connexion HTTPS sécurisée
en préfixant `https:` au nom du nœud, du pod ou du service dans l'URL de l'API, mais elles ne vérifieront pas
le certificat fourni par le point de terminaison HTTPS ni ne fourniront des informations d'identification client. Ainsi,
bien que la connexion soit chiffrée, elle ne garantira aucune intégrité. Ces
connexions **ne sont actuellement pas sûres** pour une utilisation sur des réseaux non fiables ou publics.
### Tunnels SSH
Kubernetes prend en charge les [tunnels SSH](https://www.ssh.com/academy/ssh/tunneling) pour protéger les chemins de communication du plan de contrôle vers les nœuds. Dans cette
configuration, le serveur API initie un tunnel SSH vers chaque nœud du cluster (en se connectant à
le serveur SSH qui écoute sur le port 22) et fait passer tout le trafic destiné à un kubelet, un nœud, un pod ou
un service à travers le tunnel.
Ce tunnel garantit que le trafic n'est pas exposé en dehors du réseau dans lequel les nœuds sont
exécutés.
{{< note >}}
Les tunnels SSH sont actuellement obsolètes, vous ne devriez donc pas choisir de les utiliser à moins de savoir ce que vous
faites. Le service [Konnectivity](#service-konnectivity) est un remplacement pour ce
canal de communication.
{{< /note >}}
### Service Konnectivity
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
En remplacement des tunnels SSH, le service Konnectivity fournit un proxy de niveau TCP pour la
communication entre le plan de contrôle et le cluster. Le service Konnectivity se compose de deux parties : le
serveur Konnectivity dans le réseau du plan de contrôle et les agents Konnectivity dans le réseau des nœuds.
Les agents Konnectivity initient des connexions vers le serveur Konnectivity et maintiennent
les connexions réseau.
Après avoir activé le service Konnectivity, tout le trafic du plan de contrôle vers les nœuds passe
par ces connexions.
Suivez la [tâche du service Konnectivity](/docs/tasks/extend-kubernetes/setup-konnectivity/) pour configurer
le service Konnectivity dans votre cluster.
## {{% heading "whatsnext" %}}
* En savoir plus sur les [composants du plan de contrôle Kubernetes](/docs/concepts/architecture/#control-plane-components)
* En savoir plus sur le [modèle Hub et Spoke](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors)
* Apprenez comment [sécuriser un cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
* En savoir plus sur l'[API Kubernetes](/fr/docs/concepts/overview/kubernetes-api/)
* [Configurer le service Konnectivity](/docs/tasks/extend-kubernetes/setup-konnectivity/)
* [Utiliser le transfert de port pour accéder aux applications dans un cluster](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* Apprenez comment [récupérer les journaux des pods](/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs), [utiliser kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod)

170
content/fr/docs/concepts/architecture/controller.md Normal file
View File

@ -0,0 +1,170 @@
---
title: Contrôleurs
content_type: concept
weight: 30
---
<!-- overview -->
En robotique et automatisation, une _boucle de contrôle_ est
une boucle non terminante qui régule l'état d'un système.
Voici un exemple de boucle de contrôle : un thermostat dans une pièce.
Lorsque vous réglez la température, vous indiquez au thermostat
votre *état souhaité*. La température réelle de la pièce est l'
*état actuel*. Le thermostat agit pour rapprocher l'état actuel
de l'état souhaité, en allumant ou éteignant l'équipement.
{{< glossary_definition term_id="controller" length="short">}}
<!-- body -->
## Modèle de contrôleur
Un contrôleur suit au moins un type de ressource Kubernetes.
Ces {{< glossary_tooltip text="objets" term_id="object" >}}
ont un champ spec qui représente l'état souhaité. Les
contrôleurs de cette ressource sont responsables de rapprocher l'état
actuel de cet état souhaité.
Le contrôleur peut effectuer lui-même l'action ; plus couramment, dans Kubernetes,
un contrôleur enverra des messages au
{{< glossary_tooltip text="serveur API" term_id="kube-apiserver" >}} qui ont
des effets secondaires utiles. Vous verrez des exemples de cela ci-dessous.
{{< comment >}}
Certains contrôleurs intégrés, tels que le contrôleur de namespace, agissent sur des objets
qui n'ont pas de spécification.
Pour simplifier, cette page n'explique pas ce détail.
{{< /comment >}}
### Contrôle via le serveur API
Le contrôleur de {{< glossary_tooltip term_id="job" >}} est un exemple de contrôleur
intégré à Kubernetes. Les contrôleurs intégrés gèrent l'état en
interagissant avec le serveur API du cluster.
Job est une ressource Kubernetes qui exécute un
{{< glossary_tooltip term_id="pod" >}}, ou peut-être plusieurs Pods, pour effectuer
une tâche, puis s'arrête.
(Une fois [planifiés](/docs/concepts/scheduling-eviction/), les objets Pod font partie de l'
état souhaité pour un kubelet).
Lorsque le contrôleur de Job voit une nouvelle tâche, il s'assure que, quelque part
dans votre cluster, les kubelets sur un ensemble de nœuds exécutent le bon
nombre de Pods pour effectuer le travail.
Le contrôleur de Job n'exécute aucun Pod ou conteneur
lui-même. Au lieu de cela, le contrôleur de Job demande au serveur API de créer ou supprimer
des Pods.
D'autres composants du
{{< glossary_tooltip text="plan de contrôle" term_id="control-plane" >}}
agissent sur les nouvelles informations (il y a de nouveaux Pods à planifier et à exécuter),
et finalement le travail est terminé.
Après avoir créé un nouveau Job, l'état souhaité est que ce Job soit terminé.
Le contrôleur de Job rapproche l'état actuel de ce Job de votre
état souhaité : en créant des Pods qui effectuent le travail que vous avez demandé pour ce Job, de sorte que
le Job soit plus proche de l'achèvement.
Les contrôleurs mettent également à jour les objets qui les configurent.
Par exemple : une fois le travail terminé pour un Job, le contrôleur de Job
met à jour cet objet Job pour le marquer comme `Terminé`.
(C'est un peu comme certains thermostats éteignent une lumière pour
indiquer que votre pièce est maintenant à la température que vous avez réglée).
### Contrôle direct
Contrairement à Job, certains contrôleurs doivent apporter des modifications à
des éléments en dehors de votre cluster.
Par exemple, si vous utilisez une boucle de contrôle pour vous assurer qu'il y a
suffisamment de {{< glossary_tooltip text="nœuds" term_id="node" >}}
dans votre cluster, alors ce contrôleur a besoin de quelque chose en dehors du
cluster actuel pour configurer de nouveaux nœuds lorsque cela est nécessaire.
Les contrôleurs qui interagissent avec un état externe trouvent leur état souhaité à partir
du serveur API, puis communiquent directement avec un système externe pour rapprocher
l'état actuel en ligne.
(Il existe en fait un [contrôleur](https://github.com/kubernetes/autoscaler/)
qui met à l'échelle horizontalement les nœuds de votre cluster.)
Le point important ici est que le contrôleur apporte certaines modifications pour atteindre
votre état souhaité, puis rapporte l'état actuel à votre serveur API de cluster.
D'autres boucles de contrôle peuvent observer ces données rapportées et prendre leurs propres mesures.
Dans l'exemple du thermostat, si la pièce est très froide, un autre contrôleur
pourrait également allumer un radiateur de protection contre le gel. Avec les clusters Kubernetes, le plan de contrôle
fonctionne indirectement avec des outils de gestion des adresses IP, des services de stockage,
des API de fournisseurs de cloud et d'autres services en
[étendant Kubernetes](/docs/concepts/extend-kubernetes/) pour les implémenter.
## État souhaité par rapport à l'état actuel {#desired-vs-current}
Kubernetes adopte une vision nativement cloud des systèmes et est capable de gérer
un changement constant.
Votre cluster peut changer à tout moment à mesure que le travail se déroule et que
les boucles de contrôle corrigent automatiquement les défaillances. Cela signifie que,
potentiellement, votre cluster n'atteint jamais un état stable.
Tant que les contrôleurs de votre cluster sont en cours d'exécution et capables de
effectuer des modifications utiles, il n'importe pas si l'état global est stable ou non.
## Conception
En tant que principe de sa conception, Kubernetes utilise de nombreux contrôleurs qui gèrent chacun
un aspect particulier de l'état du cluster. Le plus souvent, une boucle de contrôle
(contrôleur) utilise un type de ressource comme état souhaité et gère un autre type
de ressource pour réaliser cet état souhaité. Par exemple,
un contrôleur pour les Jobs suit les objets Job (pour découvrir un nouveau travail) et les objets Pod
(pour exécuter les Jobs, puis voir quand le travail est terminé). Dans ce cas,
quelque chose d'autre crée les Jobs, tandis que le contrôleur de Job crée les Pods.
Il est utile d'avoir des contrôleurs simples plutôt qu'un ensemble monolithique de
boucles de contrôle interconnectées. Les contrôleurs peuvent échouer,
c'est pourquoi Kubernetes est conçu pour le permettre.
{{< note >}}
Il peut y avoir plusieurs contrôleurs qui créent ou mettent à jour le même type d'objet.
En coulisses, les contrôleurs Kubernetes s'assurent qu'ils ne prêtent attention qu'aux ressources
liées à leur ressource de contrôle.
Par exemple, vous pouvez avoir des Déploiements et des Jobs ; ceux-ci créent tous deux des Pods.
Le contrôleur de Job ne supprime pas les Pods créés par votre Déploiement,
car il existe des informations ({{< glossary_tooltip term_id="label" text="étiquettes" >}})
que les contrôleurs peuvent utiliser pour distinguer ces Pods.
{{< /note >}}
## Modes d'exécution des contrôleurs {#running-controllers}
Kubernetes est livré avec un ensemble de contrôleurs intégrés qui s'exécutent à l'intérieur
du {{< glossary_tooltip term_id="kube-controller-manager" >}}. Ces
contrôleurs intégrés fournissent des comportements de base importants.
Le contrôleur de Déploiement et le contrôleur de Job sont des exemples de contrôleurs qui
font partie de Kubernetes lui-même (contrôleurs "intégrés").
Kubernetes vous permet d'exécuter un plan de contrôle résilient, de sorte que si l'un des contrôleurs intégrés
venait à échouer, une autre partie du plan de contrôle prendra en charge le travail.
Vous pouvez trouver des contrôleurs qui s'exécutent en dehors du plan de contrôle pour étendre Kubernetes.
Ou, si vous le souhaitez, vous pouvez écrire vous-même un nouveau contrôleur.
Vous pouvez exécuter votre propre contrôleur sous la forme d'un ensemble de Pods, ou en dehors de Kubernetes.
Ce qui convient le mieux dépendra de ce que ce contrôleur particulier fait.
## {{% heading "whatsnext" %}}
* Lisez à propos du [plan de contrôle Kubernetes](/fr/docs/concepts/architecture/#control-plane-components)
* Découvrez certains des [objets Kubernetes de base](/fr/docs/concepts/overview/working-with-objects/)
* En savoir plus sur l'[API Kubernetes](/fr/docs/concepts/overview/kubernetes-api/)
* Si vous souhaitez écrire votre propre contrôleur, consultez
les [modèles d'extension Kubernetes](/docs/concepts/extend-kubernetes/#extension-patterns)
et le référentiel [sample-controller](https://github.com/kubernetes/sample-controller).

50
content/fr/docs/concepts/architecture/cri.md Normal file
View File

@ -0,0 +1,50 @@
---
title: Interface de Runtime de Conteneur (CRI)
content_type: concept
weight: 60
---
<!-- overview -->
Le CRI (Container Runtime Interface) est une interface de plugin qui permet au kubelet d'utiliser
une grande variété de runtimes de conteneurs, sans avoir besoin de recompiler les composants du cluster.
Vous avez besoin d'un
{{<glossary_tooltip text="runtime de conteneur" term_id="container-runtime">}} fonctionnel
sur chaque nœud de votre cluster, afin que le
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} puisse lancer
{{< glossary_tooltip text="Pods" term_id="pod" >}} et leurs conteneurs.
{{< glossary_definition prepend="L'Interface de Runtime de Conteneur (CRI) est" term_id="container-runtime-interface" length="all" >}}
<!-- body -->
## L'API {#api}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
Le kubelet agit en tant que client lorsqu'il se connecte au runtime de conteneur via gRPC.
Les points de terminaison du service de runtime et d'image doivent être disponibles
dans le runtime de conteneur, ce qui peut être configuré séparément dans le kubelet
en utilisant les indicateurs de ligne de commande `--image-service-endpoint` (voir la [référence des options du kubelet](/docs/reference/command-line-tools-reference/kubelet)).
Pour Kubernetes v{{< skew currentVersion >}}, le kubelet préfère utiliser CRI `v1`.
Si un runtime de conteneur ne prend pas en charge `v1` de CRI, alors le kubelet essaie de
négocier toute version plus ancienne prise en charge.
Le kubelet de v{{< skew currentVersion >}} peut également négocier CRI `v1alpha2`, mais
cette version est considérée comme obsolète.
Si le kubelet ne peut pas négocier une version de CRI prise en charge, le kubelet abandonne
et ne s'enregistre pas en tant que nœud.
## Mise à niveau
Lors de la mise à niveau de Kubernetes, le kubelet essaie de sélectionner automatiquement la
dernière version de CRI lors du redémarrage du composant. Si cela échoue, alors le fallback
aura lieu comme mentionné ci-dessus. Si une nouvelle connexion gRPC était nécessaire car le
runtime de conteneur a été mis à niveau, alors le runtime de conteneur doit également
prendre en charge la version initialement sélectionnée, sinon la reconnexion est censée échouer. Cela
nécessite un redémarrage du kubelet.
## {{% heading "whatsnext" %}}
- En savoir plus sur la définition du protocole CRI [ici](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)

198
content/fr/docs/concepts/architecture/garbage-collection.md Normal file
View File

@ -0,0 +1,198 @@
---
title: Collecte des déchets
content_type: concept
weight: 70
---
<!-- overview -->
{{<glossary_definition term_id="garbage-collection" length="short">}} Cela permet le nettoyage des ressources suivantes :
* [Pods terminés](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
* [Jobs terminés](/docs/concepts/workloads/controllers/ttlafterfinished/)
* [Objets sans références de propriétaire](#owners-dependents)
* [Conteneurs et images inutilisés](#containers-images)
* [PersistentVolumes provisionnés dynamiquement avec une politique de récupération de classe de stockage Delete](/docs/concepts/storage/persistent-volumes/#delete)
* [CertificateSigningRequests (CSRs) obsolètes ou expirés](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
* {{<glossary_tooltip text="Nodes" term_id="node">}} supprimés dans les scénarios suivants :
* Sur un cloud lorsque le cluster utilise un [gestionnaire de contrôleur cloud](/fr/docs/concepts/architecture/cloud-controller/)
* Sur site lorsque le cluster utilise un addon similaire à un gestionnaire de cloud
* [Objets de bail de nœud](/fr/docs/concepts/architecture/nodes/#heartbeats)
## Propriétaires et dépendants {#owners-dependents}
De nombreux objets dans Kubernetes sont liés les uns aux autres par le biais de [*références de propriétaire*](/fr/docs/concepts/overview/working-with-objects/owners-dependents/).
Les références de propriétaire indiquent au plan de contrôle quels objets dépendent des autres.
Kubernetes utilise les références de propriétaire pour permettre au plan de contrôle et aux autres clients de l'API
de nettoyer les ressources associées avant de supprimer un objet. Dans la plupart des cas, Kubernetes gère automatiquement les références de propriétaire.
La propriété est différente du mécanisme [étiquettes et sélecteurs](/fr/docs/concepts/overview/working-with-objects/labels/)
que certains ressources utilisent également. Par exemple, considérez un
{{<glossary_tooltip text="Service" term_id="service">}} qui crée des objets `EndpointSlice`.
Le Service utilise des *étiquettes* pour permettre au plan de contrôle de
déterminer quels objets `EndpointSlice` sont utilisés pour ce Service. En plus
des étiquettes, chaque `EndpointSlice` géré au nom d'un Service a
une référence de propriétaire. Les références de propriétaire aident les différentes parties de Kubernetes à éviter
d'interférer avec les objets qu'elles ne contrôlent pas.
{{< note >}}
Les références de propriétaire entre namespaces sont interdites par conception.
Les dépendants dans un namespace peuvent spécifier des propriétaires à portée de cluster ou à portée de namespace.
Un propriétaire à portée de namespace **doit** exister dans le même namespace que le dépendant.
S'il n'existe pas, la référence de propriétaire est considérée comme absente et le dépendant
est susceptible d'être supprimé une fois que tous les propriétaires sont vérifiés comme absents.
Les dépendants à portée de cluster ne peuvent spécifier que des propriétaires à portée de cluster.
À partir de la version 1.20, si un dépendant à portée de cluster spécifie un type à portée de namespace en tant que propriétaire,
il est considéré comme ayant une référence de propriétaire non résoluble et ne peut pas être collecté par le garbage collector.
À partir de la version 1.20, si le garbage collector détecte une référence de propriétaire non valide entre namespaces,
ou un dépendant à portée de cluster avec une référence de propriétaire faisant référence à un type à portée de namespace, un événement d'avertissement
avec une raison de `OwnerRefInvalidNamespace` et un `involvedObject` du dépendant non valide est signalé.
Vous pouvez vérifier ce type d'événement en exécutant
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
{{< /note >}}
## Suppression en cascade {#cascading-deletion}
Kubernetes vérifie et supprime les objets qui n'ont plus de références de propriétaire,
comme les pods laissés derrière lors de la suppression d'un ReplicaSet. Lorsque vous
supprimez un objet, vous pouvez contrôler si Kubernetes supprime automatiquement les objets dépendants,
dans un processus appelé *suppression en cascade*. Il existe
deux types de suppression en cascade, comme suit :
* Suppression en cascade en premier plan
* Suppression en cascade en arrière-plan
Vous pouvez également contrôler comment et quand la collecte des déchets supprime les ressources qui ont
des références de propriétaire en utilisant les {{<glossary_tooltip text="finalizers" term_id="finalizer">}} Kubernetes.
### Suppression en cascade en premier plan {#foreground-deletion}
Dans la suppression en cascade en premier plan, l'objet propriétaire que vous supprimez entre d'abord dans
un état de *suppression en cours*. Dans cet état, les actions suivantes se produisent sur
l'objet propriétaire :
* Le serveur API Kubernetes définit le champ `metadata.deletionTimestamp` de l'objet sur l'heure à laquelle l'objet a été marqué pour suppression.
* Le serveur API Kubernetes définit également le champ `metadata.finalizers` sur `foregroundDeletion`.
* L'objet reste visible via l'API Kubernetes jusqu'à ce que le processus de suppression soit terminé.
Après que l'objet propriétaire entre dans l'état de suppression en cours, le contrôleur supprime les dépendants. Après avoir supprimé tous les objets dépendants, le contrôleur
supprime l'objet propriétaire. À ce stade, l'objet n'est plus visible dans
l'API Kubernetes.
Pendant la suppression en cascade en premier plan, seuls les dépendants qui bloquent la suppression du propriétaire sont ceux qui ont le champ `ownerReference.blockOwnerDeletion=true`.
Consultez [Utiliser la suppression en cascade en premier plan](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
pour en savoir plus.
### Suppression en cascade en arrière-plan {#background-deletion}
Dans la suppression en cascade en arrière-plan, le serveur API Kubernetes supprime immédiatement l'objet propriétaire et le contrôleur nettoie les objets dépendants en
arrière-plan. Par défaut, Kubernetes utilise la suppression en cascade en arrière-plan, sauf si
vous utilisez manuellement la suppression en premier plan ou choisissez d'abandonner les objets dépendants.
Consultez [Utiliser la suppression en cascade en arrière-plan](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
pour en savoir plus.
### Dépendants orphelins
Lorsque Kubernetes supprime un objet propriétaire, les dépendants laissés derrière sont appelés
objets *orphelins*. Par défaut, Kubernetes supprime les objets dépendants. Pour apprendre comment
outrepasser ce comportement, consultez [Supprimer les objets propriétaires et les dépendants orphelins](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
## Collecte des déchets des conteneurs et des images inutilisés {#containers-images}
Le {{<glossary_tooltip text="kubelet" term_id="kubelet">}} effectue la collecte des déchets
sur les images inutilisées toutes les deux minutes et sur les conteneurs inutilisés toutes les
minutes. Vous devez éviter d'utiliser des outils de collecte des déchets externes, car ils peuvent
perturber le comportement du kubelet et supprimer des conteneurs qui devraient exister.
Pour configurer les options de collecte des déchets des conteneurs et des images inutilisés, ajustez le
kubelet en utilisant un [fichier de configuration](/docs/tasks/administer-cluster/kubelet-config-file/)
et modifiez les paramètres liés à la collecte des déchets en utilisant le
type de ressource [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
### Cycle de vie des images de conteneur
Kubernetes gère le cycle de vie de toutes les images via son *gestionnaire d'images*,
qui fait partie du kubelet, en collaboration avec
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}. Le kubelet
prend en compte les limites d'utilisation du disque suivantes lors de la prise de décision de collecte des déchets :
* `HighThresholdPercent`
* `LowThresholdPercent`
Une utilisation du disque supérieure à la valeur configurée de `HighThresholdPercent` déclenche la collecte des déchets, qui supprime les images dans l'ordre en fonction de leur dernière utilisation,
en commençant par les plus anciennes en premier. Le kubelet supprime les images
jusqu'à ce que l'utilisation du disque atteigne la valeur `LowThresholdPercent`.
#### Collecte des déchets pour les images de conteneur inutilisées {#image-maximum-age-gc}
{{< feature-state feature_gate_name="ImageMaximumGCAge" >}}
En tant que fonctionnalité bêta, vous pouvez spécifier la durée maximale pendant laquelle une image locale peut rester inutilisée,
indépendamment de l'utilisation du disque. Il s'agit d'un paramètre du kubelet que vous configurez pour chaque nœud.
Pour configurer le paramètre, activez la fonctionnalité `ImageMaximumGCAge`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) pour le kubelet,
et définissez également une valeur pour le champ `imageMaximumGCAge` dans le fichier de configuration du kubelet.
La valeur est spécifiée en tant que _durée_ Kubernetes ;
Les unités de temps valides pour le champ `imageMaximumGCAge` dans le fichier de configuration du kubelet sont :
- "ns" pour les nanosecondes
- "us" ou "µs" pour les microsecondes
- "ms" pour les millisecondes
- "s" pour les secondes
- "m" pour les minutes
- "h" pour les heures
Par exemple, vous pouvez définir le champ de configuration sur `12h45m`,
ce qui signifie 12 heures et 45 minutes.
{{< note >}}
Cette fonctionnalité ne suit pas l'utilisation des images entre les redémarrages du kubelet. Si le kubelet
est redémarré, l'âge de l'image suivi est réinitialisé, ce qui fait que le kubelet attend la durée complète
`imageMaximumGCAge` avant de qualifier les images pour la collecte des déchets
en fonction de l'âge de l'image.
{{< /note>}}
### Collecte des déchets des conteneurs {#container-image-garbage-collection}
Le kubelet collecte les conteneurs inutilisés en fonction des variables suivantes, que vous pouvez définir :
* `MinAge` : l'âge minimum auquel le kubelet peut collecter les
conteneurs. Désactivez en définissant sur `0`.
* `MaxPerPodContainer` : le nombre maximum de conteneurs inactifs que chaque Pod
peut avoir. Désactivez en définissant sur une valeur inférieure à `0`.
* `MaxContainers` : le nombre maximum de conteneurs inactifs que le cluster peut avoir.
Désactivez en définissant sur une valeur inférieure à `0`.
En plus de ces variables, le kubelet collecte les conteneurs non identifiés et
supprimés, généralement en commençant par les plus anciens.
`MaxPerPodContainer` et `MaxContainers` peuvent potentiellement entrer en conflit les uns avec les autres
dans des situations où le maintien du nombre maximum de conteneurs par Pod
(`MaxPerPodContainer`) dépasserait le total autorisé de conteneurs inactifs globaux (`MaxContainers`). Dans cette situation, le kubelet ajuste
`MaxPerPodContainer` pour résoudre le conflit. Le pire des cas serait de
réduire `MaxPerPodContainer` à `1` et d'évacuer les conteneurs les plus anciens.
De plus, les conteneurs appartenant à des pods qui ont été supprimés sont supprimés une fois
qu'ils sont plus anciens que `MinAge`.
{{<note>}}
Le kubelet ne collecte que les conteneurs qu'il gère.
{{</note>}}
## Configuration de la collecte des déchets {#configuring-gc}
Vous pouvez ajuster la collecte des déchets des ressources en configurant des options spécifiques aux
contrôleurs qui gèrent ces ressources. Les pages suivantes vous montrent comment
configurer la collecte des déchets :
* [Configuration de la suppression en cascade des objets Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/)
* [Configuration du nettoyage des Jobs terminés](/docs/concepts/workloads/controllers/ttlafterfinished/)
## {{% heading "whatsnext" %}}
* En savoir plus sur [la propriété des objets Kubernetes](/fr/docs/concepts/overview/working-with-objects/owners-dependents/).
* En savoir plus sur les [finalizers Kubernetes](/fr/docs/concepts/overview/working-with-objects/finalizers/).
* Découvrez le [contrôleur TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) qui nettoie les Jobs terminés.

111
content/fr/docs/concepts/architecture/leases.md Normal file
View File

@ -0,0 +1,111 @@
---
title: Lease
api_metadata:
- apiVersion: "coordination.k8s.io/v1"
kind: "Lease"
content_type: concept
weight: 30
---
<!-- overview -->
Les systèmes distribués ont souvent besoin de _Lease_, qui fournissent un mécanisme pour verrouiller les ressources partagées
et coordonner l'activité entre les membres d'un ensemble.
Dans Kubernetes, le concept de bail est représenté par les objets [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
dans le groupe d'API `coordination.k8s.io` {{< glossary_tooltip text="Groupe d'API" term_id="api-group" >}},
qui sont utilisés pour des fonctionnalités critiques du système telles que les battements de cœur des nœuds et l'élection du leader au niveau des composants.
<!-- body -->
## Battements de cœur des nœuds {#node-heart-beats}
Kubernetes utilise l'API Lease pour communiquer les battements de cœur des nœuds kubelet au serveur API Kubernetes.
Pour chaque `Node`, il existe un objet `Lease` avec un nom correspondant dans l'espace de noms `kube-node-lease`.
Sous le capot, chaque battement de cœur kubelet est une demande de **mise à jour** de cet objet `Lease`, mettant à jour
le champ `spec.renewTime` pour le bail. Le plan de contrôle Kubernetes utilise le horodatage de ce champ
pour déterminer la disponibilité de ce `Node`.
Consultez [Objets de bail de nœud](/docs/concepts/architecture/nodes/#node-heartbeats) pour plus de détails.
## Élection du leader
Kubernetes utilise également des Lease pour s'assurer qu'une seule instance d'un composant est en cours d'exécution à tout moment.
Cela est utilisé par les composants du plan de contrôle tels que `kube-controller-manager` et `kube-scheduler` dans
les configurations HA, où une seule instance du composant doit être en cours d'exécution activement tandis que les autres
instances sont en attente.
Lisez [élection coordonnée du leader](/docs/concepts/cluster-administration/coordinated-leader-election)
pour en savoir plus sur la façon dont Kubernetes s'appuie sur l'API Lease pour sélectionner quelle instance de composant
agit en tant que leader.
## Identité du serveur API
{{< feature-state feature_gate_name="APIServerIdentity" >}}
À partir de Kubernetes v1.26, chaque `kube-apiserver` utilise l'API Lease pour publier son identité au reste du système.
Bien que cela ne soit pas particulièrement utile en soi, cela fournit un mécanisme pour les clients afin de
découvrir combien d'instances de `kube-apiserver` opèrent sur le plan de contrôle Kubernetes.
L'existence des Lease kube-apiserver permet des fonctionnalités futures qui peuvent nécessiter une coordination entre
chaque kube-apiserver.
Vous pouvez inspecter les Lease détenus par chaque kube-apiserver en vérifiant les objets de bail dans l'espace de noms `kube-system`
avec le nom `kube-apiserver-<sha256-hash>`. Alternativement, vous pouvez utiliser le sélecteur d'étiquettes `apiserver.kubernetes.io/identity=kube-apiserver`:
```shell
kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver
```
```
NOM HOLDER ÂGE
apiserver-07a5ea9b9b072c4a5f3d1c3702 apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05 5m33s
apiserver-7be9e061c59d368b3ddaf1376e apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s
apiserver-1dfef752bcb36637d2763d1868 apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s
```
Le hachage SHA256 utilisé dans le nom du bail est basé sur le nom d'hôte du système d'exploitation tel que vu par ce serveur API. Chaque kube-apiserver devrait être
configuré pour utiliser un nom d'hôte qui est unique dans le cluster. Les nouvelles instances de kube-apiserver qui utilisent le même nom d'hôte
prendront le contrôle des Lease existants en utilisant une nouvelle identité de détenteur, au lieu d'instancier de nouveaux objets de bail. Vous pouvez vérifier le
nom d'hôte utilisé par kube-apisever en vérifiant la valeur de l'étiquette `kubernetes.io/hostname`:
```shell
kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml
```
```yaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
creationTimestamp: "2023-07-02T13:16:48Z"
labels:
apiserver.kubernetes.io/identity: kube-apiserver
kubernetes.io/hostname: master-1
name: apiserver-07a5ea9b9b072c4a5f3d1c3702
namespace: kube-system
resourceVersion: "334899"
uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1
spec:
holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05
leaseDurationSeconds: 3600
renewTime: "2023-07-04T21:58:48.065888Z"
```
Les Lease expirés des kube-apiservers qui n'existent plus sont collectés par les nouveaux kube-apiservers après 1 heure.
Vous pouvez désactiver les Lease d'identité du serveur API en désactivant la fonctionnalité `APIServerIdentity`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
## Charges de travail {#custom-workload}
Votre propre charge de travail peut définir son propre usage des Lease. Par exemple, vous pouvez exécuter un
{{< glossary_tooltip term_id="controller" text="contrôleur" >}} personnalisé où un membre principal ou leader
effectue des opérations que ses pairs ne font pas. Vous définissez un bail afin que les réplicas du contrôleur puissent sélectionner
ou élire un leader, en utilisant l'API Kubernetes pour la coordination.
Si vous utilisez un bail, il est bon de pratiquer de définir un nom pour le bail qui est clairement lié au
produit ou au composant. Par exemple, si vous avez un composant nommé Example Foo, utilisez un bail nommé
`example-foo`.
Si un opérateur de cluster ou un autre utilisateur final peut déployer plusieurs instances d'un composant, sélectionnez un préfixe de nom
et choisissez un mécanisme (comme le hachage du nom du déploiement) pour éviter les collisions de noms
pour les Lease.
Vous pouvez utiliser une autre approche tant qu'elle atteint le même résultat : les différents produits logiciels ne
entrent pas en conflit les uns avec les autres.

75
content/fr/docs/concepts/architecture/master-node-communication.md
View File

@ -1,75 +0,0 @@
---
title: Communication Master-Node
content_type: concept
description: Communication Master-Node Kubernetes
weight: 20
---
<!-- overview -->
Ce document répertorie les canaux de communication entre l'API du noeud maître (apiserver of master node en anglais) et le reste du cluster Kubernetes.
L'objectif est de permettre aux utilisateurs de personnaliser leur installation afin de sécuriser la configuration réseau, de sorte que le cluster puisse être exécuté sur un réseau non approuvé (ou sur des adresses IP entièrement publiques d'un fournisseur de cloud).
<!-- body -->
## Communication du Cluster vers le Master
Tous les canaux de communication du cluster au master se terminent à l'apiserver (aucun des autres composants principaux n'est conçu pour exposer des services distants).
Dans un déploiement typique, l'apiserver est configuré pour écouter les connexions distantes sur un port HTTPS sécurisé (443) avec un ou plusieurs types d'[authentification](/docs/reference/access-authn-authz/authentication/) client.
Une ou plusieurs formes d'[autorisation](/docs/reference/access-authn-authz/authorization/) devraient être activées, notamment si les [requêtes anonymes](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ou [jeton de compte de service](/docs/reference/access-authn-authz/authentication/#service-account-tokens) sont autorisés.
Le certificat racine public du cluster doit être configuré pour que les nœuds puissent se connecter en toute sécurité à l'apiserver avec des informations d'identification client valides.
Par exemple, dans un déploiement GKE par défaut, les informations d'identification client fournies au kubelet sont sous la forme d'un certificat client.
Consultez [amorçage TLS de kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) pour le provisioning automatisé des certificats de client Kubelet.
Les pods qui souhaitent se connecter à l'apiserver peuvent le faire de manière sécurisée en utilisant un compte de service afin que Kubernetes injecte automatiquement le certificat racine public et un jeton de support valide dans le pod lorsqu'il est instancié.
Le service `kubernetes` (dans tous les namespaces) est configuré avec une adresse IP virtuelle redirigée (via kube-proxy) vers le point de terminaison HTTPS sur l'apiserver.
Les composants du master communiquent également avec l'apiserver du cluster via le port sécurisé.
Par conséquent, le mode de fonctionnement par défaut pour les connexions du cluster (nœuds et pods s'exécutant sur les nœuds) au master est sécurisé par défaut et peut s'exécuter sur des réseaux non sécurisés et/ou publics.
## Communication du Master vers le Cluster
Il existe deux voies de communication principales du master (apiserver) au cluster.
La première est du processus apiserver au processus kubelet qui s'exécute sur chaque nœud du cluster.
La seconde part de l'apiserver vers n'importe quel nœud, pod ou service via la fonctionnalité proxy de l'apiserver.
### Communication de l'apiserver vers le kubelet
Les connexions de l'apiserver au kubelet sont utilisées pour:
* Récupérer les logs des pods.
* S'attacher (via kubectl) à des pods en cours d'exécution.
* Fournir la fonctionnalité de transfert de port du kubelet.
Ces connexions se terminent au point de terminaison HTTPS du kubelet.
Par défaut, l'apiserver ne vérifie pas le certificat du kubelet, ce qui rend la connexion sujette aux attaques de type "man-in-the-middle", et **non sûre** sur des réseaux non approuvés et/ou publics.
Pour vérifier cette connexion, utilisez l'argument `--kubelet-certificate-authority` pour fournir à l'apiserver un ensemble de certificats racine à utiliser pour vérifier le certificat du kubelet.
Si ce n'est pas possible, utilisez [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) entre l'apiserver et le kubelet si nécessaire pour éviter la connexion sur un réseau non sécurisé ou public.
Finalement, l'[authentification et/ou autorisation du Kubelet](/docs/admin/kubelet-authentication-authorization/) devrait être activée pour sécuriser l'API kubelet.
### apiserver vers nodes, pods et services
Les connexions de l'apiserver à un nœud, à un pod ou à un service sont définies par défaut en connexions HTTP.
Elles ne sont donc ni authentifiées ni chiffrées.
Elles peuvent être exécutées sur une connexion HTTPS sécurisée en préfixant `https:` au nom du nœud, du pod ou du service dans l'URL de l'API.
Cependant ils ne valideront pas le certificat fourni par le point de terminaison HTTPS ni ne fourniront les informations d'identification du client.
De plus, aucune garantie d'intégrité n'est fournie.
Ces connexions **ne sont actuellement pas sûres** pour fonctionner sur des réseaux non sécurisés et/ou publics.
### SSH Tunnels
Kubernetes prend en charge les tunnels SSH pour protéger les communications master -> cluster.
Dans cette configuration, l'apiserver initie un tunnel SSH vers chaque nœud du cluster (en se connectant au serveur ssh sur le port 22) et transmet tout le trafic destiné à un kubelet, un nœud, un pod ou un service via un tunnel.
Ce tunnel garantit que le trafic n'est pas exposé en dehors du réseau dans lequel les nœuds sont en cours d'exécution.
Les tunnels SSH étant actuellement obsolètes, vous ne devriez pas choisir de les utiliser à moins de savoir ce que vous faites.
Un remplacement pour ce canal de communication est en cours de conception.

110
content/fr/docs/concepts/architecture/mixed-version-proxy.md Normal file
View File

@ -0,0 +1,110 @@
---
reviewers:
title: Proxy de version mixte
content_type: concept
weight: 220
---
<!-- overview -->
{{< feature-state feature_gate_name="UnknownVersionInteroperabilityProxy" >}}
Kubernetes {{< skew currentVersion >}} inclut une fonctionnalité alpha qui permet à un
{{< glossary_tooltip text="Serveur API" term_id="kube-apiserver" >}}
de faire proxy des demandes de ressources vers d'autres serveurs API _pairs_. Cela est utile lorsqu'il y a plusieurs
serveurs API exécutant différentes versions de Kubernetes dans un même cluster
(par exemple, pendant un déploiement à long terme vers une nouvelle version de Kubernetes).
Cela permet aux administrateurs de cluster de configurer des clusters hautement disponibles qui peuvent être mis à niveau
plus en toute sécurité, en redirigeant les demandes de ressources (effectuées pendant la mise à niveau) vers le kube-apiserver correct.
Ce proxy empêche les utilisateurs de voir des erreurs 404 Not Found inattendues qui découlent
du processus de mise à niveau.
Ce mécanisme est appelé le _Proxy de Version Mixte_.
## Activation du Proxy de Version Mixte
Assurez-vous que la fonctionnalité `UnknownVersionInteroperabilityProxy` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
est activée lorsque vous démarrez le {{< glossary_tooltip text="Serveur API" term_id="kube-apiserver" >}} :
```shell
kube-apiserver \
--feature-gates=UnknownVersionInteroperabilityProxy=true \
# arguments de ligne de commande requis pour cette fonctionnalité
--peer-ca-file=<chemin vers le certificat CA de kube-apiserver>
--proxy-client-cert-file=<chemin vers le certificat proxy de l'agrégateur>,
--proxy-client-key-file=<chemin vers la clé proxy de l'agrégateur>,
--requestheader-client-ca-file=<chemin vers le certificat CA de l'agrégateur>,
# requestheader-allowed-names peut être laissé vide pour autoriser n'importe quel nom commun
--requestheader-allowed-names=<noms communs valides pour vérifier le certificat client du proxy>,
# indicateurs facultatifs pour cette fonctionnalité
--peer-advertise-ip=`IP de ce kube-apiserver qui doit être utilisée par les pairs pour faire proxy des demandes`
--peer-advertise-port=`port de ce kube-apiserver qui doit être utilisé par les pairs pour faire proxy des demandes`
# ...et d'autres indicateurs comme d'habitude
```
### Transport et authentification du proxy entre les serveurs API {#transport-and-authn}
* Le kube-apiserver source réutilise les
[indicateurs d'authentification client du serveur API existant](/docs/tasks/extend-kubernetes/configure-aggregation-layer/#kubernetes-apiserver-client-authentication)
`--proxy-client-cert-file` et `--proxy-client-key-file` pour présenter son identité qui
sera vérifiée par son pair (le kube-apiserver de destination). Le serveur API de destination
vérifie cette connexion pair en fonction de la configuration que vous spécifiez en utilisant l'argument de ligne de commande
`--requestheader-client-ca-file`.
* Pour authentifier les certificats de service du serveur de destination, vous devez configurer un ensemble de certificats
d'autorité de certification en spécifiant l'argument de ligne de commande `--peer-ca-file` au serveur API **source**.
### Configuration pour la connectivité des serveurs API pairs
Pour définir l'emplacement réseau d'un kube-apiserver que les pairs utiliseront pour faire proxy des demandes, utilisez les
arguments de ligne de commande `--peer-advertise-ip` et `--peer-advertise-port` pour kube-apiserver ou spécifiez
ces champs dans le fichier de configuration du serveur API.
Si ces indicateurs ne sont pas spécifiés, les pairs utiliseront la valeur de `--advertise-address` ou
`--bind-address` comme argument de ligne de commande pour le kube-apiserver.
Si ceux-ci ne sont pas définis non plus, l'interface par défaut de l'hôte est utilisée.
## Proxy de version mixte
Lorsque vous activez le proxy de version mixte, la [couche d'agrégation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
charge un filtre spécial qui effectue les opérations suivantes :
* Lorsqu'une demande de ressource atteint un serveur API qui ne peut pas servir cette API
(soit parce qu'il s'agit d'une version antérieure à l'introduction de l'API, soit parce que l'API est désactivée sur le serveur API),
le serveur API tente d'envoyer la demande à un serveur API pair qui peut servir l'API demandée.
Il le fait en identifiant les groupes d'API / versions / ressources que le serveur local ne reconnaît pas,
et essaie de faire proxy de ces demandes vers un serveur API pair capable de traiter la demande.
* Si le serveur API pair ne parvient pas à répondre, le serveur API source répond avec une erreur 503 ("Service Unavailable").
### Comment cela fonctionne en interne
Lorsqu'un serveur API reçoit une demande de ressource, il vérifie d'abord quels serveurs API peuvent
servir la ressource demandée. Cette vérification se fait en utilisant l'API interne
[`StorageVersion`](/docs/reference/generated/kubernetes-api/v{{< skew currentVersion >}}/#storageversioncondition-v1alpha1-internal-apiserver-k8s-io).
* Si la ressource est connue du serveur API qui a reçu la demande
(par exemple, `GET /api/v1/pods/quelque-pod`), la demande est traitée localement.
* S'il n'y a pas d'objet `StorageVersion` interne trouvé pour la ressource demandée
(par exemple, `GET /my-api/v1/my-resource`) et que l'APIService configuré spécifie le proxy
vers un serveur API d'extension, ce proxy se fait en suivant le flux habituel
[flow](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) pour les API d'extension.
* Si un objet `StorageVersion` interne valide est trouvé pour la ressource demandée
(par exemple, `GET /batch/v1/jobs`) et que le serveur API qui essaie de traiter la demande
(le serveur API de traitement) a l'API `batch` désactivée, alors le serveur API de traitement
récupère les serveurs API pairs qui servent le groupe d'API / version / ressource pertinent
(`api/v1/batch` dans ce cas) en utilisant les informations de l'objet `StorageVersion` récupéré.
Le serveur API de traitement fait ensuite proxy de la demande vers l'un des serveurs kube-apiservers pairs correspondants
qui sont conscients de la ressource demandée.
* S'il n'y a aucun pair connu pour ce groupe d'API / version / ressource, le serveur API de traitement
transmet la demande à sa propre chaîne de traitement qui devrait finalement renvoyer une réponse 404 ("Not Found").
* Si le serveur API de traitement a identifié et sélectionné un serveur API pair, mais que ce pair échoue
à répondre (pour des raisons telles que des problèmes de connectivité réseau ou une course de données entre la demande
étant reçue et un contrôleur enregistrant les informations du pair dans le plan de contrôle), alors le serveur de traitement
API répond avec une erreur 503 ("Service Unavailable").

456
content/fr/docs/concepts/architecture/nodes.md
View File

@ -1,107 +1,43 @@
---
reviewers:
- sieben
title: Noeuds
description: Concept Noeud Kubernetes
api_metadata:
- apiVersion: "v1"
kind: "Node"
content_type: concept
weight: 10
---
<!-- overview -->
Un nœud est une machine de travail dans Kubernetes, connue auparavant sous le nom de `minion`.
Un nœud peut être une machine virtuelle ou une machine physique, selon le cluster.
Chaque nœud contient les services nécessaires à l'exécution de [pods](/docs/concepts/workloads/pods/pod/) et est géré par les composants du master.
Les services sur un nœud incluent le [container runtime](/docs/concepts/overview/components/#node-components), kubelet et kube-proxy.
Consultez la section [Le Nœud Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) dans le document de conception de l'architecture pour plus de détails.
Kubernetes exécute votre {{< glossary_tooltip text="charge de travail" term_id="workload" >}}
en plaçant des conteneurs dans des Pods pour s'exécuter sur des _nœuds_.
Un nœud peut être une machine virtuelle ou physique, selon le cluster. Chaque nœud
est géré par le
{{< glossary_tooltip text="plan de contrôle" term_id="control-plane" >}}
et contient les services nécessaires pour exécuter
{{< glossary_tooltip text="Pods" term_id="pod" >}}.
Typiquement, vous avez plusieurs nœuds dans un cluster ; dans un environnement d'apprentissage ou limité en ressources,
vous pourriez n'avoir qu'un seul nœud.
Les [composants](/docs/concepts/architecture/#node-components) sur un nœud incluent le
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, un
{{< glossary_tooltip text="runtime de conteneur" term_id="container-runtime" >}}, et le
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
<!-- body -->
## Statut du nœud
Le statut d'un nœud contient les informations suivantes:
* [Addresses](#addresses)
* [Condition](#condition)
* [Capacity](#capacity)
* [Info](#info)
Chaque section est décrite en détail ci-dessous.
### Adresses
L'utilisation de ces champs varie en fonction de votre fournisseur de cloud ou de votre configuration physique.
* HostName: Le nom d'hôte tel que rapporté par le noyau du nœud. Peut être remplacé via le paramètre kubelet `--hostname-override`.
* ExternalIP: En règle générale, l'adresse IP du nœud pouvant être routé en externe (disponible de l'extérieur du cluster).
* InternalIP: En règle générale, l'adresse IP du nœud pouvant être routé uniquement dans le cluster.
### Condition
Le champ `conditions` décrit le statut de tous les nœuds `Running`.
| Node Condition | Description |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `OutOfDisk` | `True` si l'espace disponible sur le nœud est insuffisant pour l'ajout de nouveaux pods, sinon `False` |
| `Ready` | `True` si le noeud est sain et prêt à accepter des pods, `False` si le noeud n'est pas sain et n'accepte pas de pods, et `Unknown` si le contrôleur de noeud n'a pas reçu d'information du noeud depuis `node-monitor-grace-period` (la valeur par défaut est de 40 secondes) |
| `MemoryPressure` | `True` s'il existe une pression sur la mémoire du noeud, c'est-à-dire si la mémoire du noeud est faible; autrement `False` |
| `PIDPressure` | `True` s'il existe une pression sur le nombre de processus, c'est-à-dire s'il y a trop de processus sur le nœud; autrement `False` |
| `DiskPressure` | `True` s'il existe une pression sur la taille du disque, c'est-à-dire si la capacité du disque est faible; autrement `False` |
| `NetworkUnavailable` | `True` si le réseau pour le noeud n'est pas correctement configuré, sinon `False` |
La condition de noeud est représentée sous la forme d'un objet JSON.
Par exemple, la réponse suivante décrit un nœud sain.
```json
"conditions": [
{
"type": "Ready",
"status": "True"
}
]
```
Si le statut de l'état Ready reste `Unknown` ou `False` plus longtemps que `pod-eviction-timeout`, un argument est passé au [kube-controller-manager](/docs/admin/kube-controller-manager/) et les pods sur le nœud sont programmés pour être supprimés par le contrôleur du nœud.
Le délai d’expulsion par défaut est de **cinq minutes**..
Dans certains cas, lorsque le nœud est inaccessible, l'apiserver est incapable de communiquer avec le kubelet sur le nœud.
La décision de supprimer les pods ne peut pas être communiquée au kublet tant que la communication avec l'apiserver n'est pas rétablie.
Entre-temps, les pods dont la suppression est planifiée peuvent continuer à s'exécuter sur le nœud inaccessible.
Dans les versions de Kubernetes antérieures à 1.5, le contrôleur de noeud [forcait la suppression](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) de ces pods inaccessibles de l'apiserver.
Toutefois, dans la version 1.5 et ultérieure, le contrôleur de noeud ne force pas la suppression des pods tant qu'il n'est pas confirmé qu'ils ont cessé de fonctionner dans le cluster.
Vous pouvez voir que les pods en cours d'exécution sur un nœud inaccessible sont dans l'état `Terminating` ou` Unknown`.
Dans les cas où Kubernetes ne peut pas déduire de l'infrastructure sous-jacente si un nœud a définitivement quitté un cluster, l'administrateur du cluster peut avoir besoin de supprimer l'objet nœud à la main.
La suppression de l'objet nœud de Kubernetes entraîne la suppression de tous les objets Pod exécutés sur le nœud de l'apiserver et libère leurs noms.
Dans la version 1.12, la fonctionnalité `TaintNodesByCondition` est promue en version bêta, ce qui permet au contrôleur de cycle de vie du nœud de créer automatiquement des [marquages](/docs/concepts/configuration/taint-and-toleration/) (taints en anglais) qui représentent des conditions.
De même, l'ordonnanceur ignore les conditions lors de la prise en compte d'un nœud; au lieu de cela, il regarde les taints du nœud et les tolérances d'un pod.
Les utilisateurs peuvent désormais choisir entre l'ancien modèle de planification et un nouveau modèle de planification plus flexible.
Un pod qui n’a aucune tolérance est programmé selon l’ancien modèle.
Mais un pod qui tolère les taints d'un nœud particulier peut être programmé sur ce nœud.
{{< caution >}}
L'activation de cette fonctionnalité crée un léger délai entre le moment où une condition est observée et le moment où une taint est créée.
Ce délai est généralement inférieur à une seconde, mais il peut augmenter le nombre de pods programmés avec succès mais rejetés par le kubelet.
{{< /caution >}}
### Capacité
Décrit les ressources disponibles sur le nœud: CPU, mémoire et nombre maximal de pods pouvant être planifiés sur le nœud.
### Info
Informations générales sur le noeud, telles que la version du noyau, la version de Kubernetes (versions de kubelet et kube-proxy), la version de Docker (si utilisée), le nom du système d'exploitation.
Les informations sont collectées par Kubelet à partir du noeud.
## Gestion
Contrairement aux [pods](/docs/concepts/workloads/pods/) et aux [services](/docs/concepts/services-networking/service/), un nœud n'est pas créé de manière inhérente par Kubernetes: il est créé de manière externe par un cloud tel que Google Compute Engine, ou bien il existe dans votre pool de machines physiques ou virtuelles.
Ainsi, lorsque Kubernetes crée un nœud, il crée un objet qui représente le nœud.
Après la création, Kubernetes vérifie si le nœud est valide ou non.
Par exemple, si vous essayez de créer un nœud à partir du contenu suivant:
Il existe deux principales façons d'ajouter des nœuds au
{{< glossary_tooltip text="serveur API" term_id="kube-apiserver" >}} :
1. Le kubelet sur un nœud s'enregistre automatiquement auprès du plan de contrôle.
2. Vous (ou un autre utilisateur humain) ajoutez manuellement un objet Nœud.
Après avoir créé un {{< glossary_tooltip text="objet" term_id="object" >}} Nœud,
ou lorsque le kubelet sur un nœud s'enregistre automatiquement, le plan de contrôle vérifie si le nouvel objet Nœud
est valide. Par exemple, si vous essayez de créer un Nœud à partir du manifeste JSON suivant :
```json
{
@ -116,119 +52,279 @@ Par exemple, si vous essayez de créer un nœud à partir du contenu suivant:
}
```
Kubernetes crée un objet noeud en interne (la représentation) et valide le noeud en vérifiant son intégrité en fonction du champ `metadata.name`.
Si le nœud est valide, c'est-à-dire si tous les services nécessaires sont en cours d'exécution, il est éligible pour exécuter un pod.
Sinon, il est ignoré pour toute activité de cluster jusqu'à ce qu'il devienne valide.
Kubernetes crée un objet Nœud en interne (la représentation). Kubernetes vérifie
qu'un kubelet s'est enregistré auprès du serveur API correspondant au champ `metadata.name`
du Nœud. Si le nœud est en bonne santé (c'est-à-dire que tous les services nécessaires sont en cours d'exécution),
alors il est éligible pour exécuter un Pod. Sinon, ce nœud est ignoré pour toute activité du cluster
jusqu'à ce qu'il redevienne en bonne santé.
{{< note >}}
Kubernetes conserve l'objet pour le nœud non valide et vérifie s'il devient valide.
Vous devez explicitement supprimer l'objet Node pour arrêter ce processus.
Kubernetes conserve l'objet pour le Nœud invalide et continue de vérifier s'il devient en bonne santé.
Vous, ou un {{< glossary_tooltip term_id="controller" text="contrôleur">}}, devez explicitement
supprimer l'objet Nœud pour arrêter cette vérification de santé.
{{< /note >}}
Actuellement, trois composants interagissent avec l'interface de noeud Kubernetes: le contrôleur de noeud, kubelet et kubectl.
Le nom d'un objet Nœud doit être un
[nom de sous-domaine DNS valide](/fr/docs/concepts/overview/working-with-objects/names#noms-de-sous-domaine-dns).
### Contrôleur de nœud
### Unicité du nom du nœud
Le contrôleur de noeud (node controller en anglais) est un composant du master Kubernetes qui gère divers aspects des noeuds.
Le contrôleur de nœud a plusieurs rôles dans la vie d'un nœud.
La première consiste à affecter un bloc CIDR au nœud lorsqu’il est enregistré (si l’affectation CIDR est activée).
La seconde consiste à tenir à jour la liste interne des nœuds du contrôleur de nœud avec la liste des machines disponibles du fournisseur de cloud.
Lorsqu'il s'exécute dans un environnement de cloud, chaque fois qu'un nœud est en mauvaise santé, le contrôleur de nœud demande au fournisseur de cloud si la machine virtuelle de ce nœud est toujours disponible.
Sinon, le contrôleur de nœud supprime le nœud de sa liste de nœuds.
La troisième est la surveillance de la santé des nœuds.
Le contrôleur de noeud est responsable de la mise à jour de la condition NodeReady de NodeStatus vers ConditionUnknown lorsqu'un noeud devient inaccessible (le contrôleur de noeud cesse de recevoir des heartbeats pour une raison quelconque, par exemple en raison d'une panne du noeud), puis de l'éviction ultérieure de tous les pods du noeud. (en utilisant une terminaison propre) si le nœud continue d’être inaccessible.
(Les délais d'attente par défaut sont de 40 secondes pour commencer à signaler ConditionUnknown et de 5 minutes après cela pour commencer à expulser les pods.)
Le contrôleur de nœud vérifie l'état de chaque nœud toutes les `--node-monitor-period` secondes.
Dans les versions de Kubernetes antérieures à 1.13, NodeStatus correspond au heartbeat du nœud.
À partir de Kubernetes 1.13, la fonctionnalité de bail de nœud (node lease en anglais) est introduite en tant que fonctionnalité alpha (feature gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
Lorsque la fonction de node lease est activée, chaque noeud a un objet `Lease` associé dans le namespace `kube-node-lease` qui est renouvelé périodiquement par le noeud, et NodeStatus et le node lease sont traités comme des heartbeat du noeud.
Les node leases sont renouvelés fréquemment lorsque NodeStatus est signalé de nœud à master uniquement lorsque des modifications ont été apportées ou que suffisamment de temps s'est écoulé (la valeur par défaut est 1 minute, ce qui est plus long que le délai par défaut de 40 secondes pour les nœuds inaccessibles).
Étant donné qu'un node lease est beaucoup plus léger qu'un NodeStatus, cette fonctionnalité rends le heartbeat d'un nœud nettement moins coûteux, tant du point de vue de l'évolutivité que des performances.
Dans Kubernetes 1.4, nous avons mis à jour la logique du contrôleur de noeud afin de mieux gérer les cas où un grand nombre de noeuds rencontrent des difficultés pour atteindre le master (par exemple parce que le master a un problème de réseau).
À partir de la version 1.4, le contrôleur de noeud examine l’état de tous les noeuds du cluster lorsqu’il prend une décision concernant l’éviction des pods.
Dans la plupart des cas, le contrôleur de noeud limite le taux d’expulsion à `--node-eviction-rate` (0,1 par défaut) par seconde, ce qui signifie qu’il n’expulsera pas les pods de plus d’un nœud toutes les 10 secondes.
Le comportement d'éviction de noeud change lorsqu'un noeud d'une zone de disponibilité donnée devient défaillant.
Le contrôleur de nœud vérifie quel pourcentage de nœuds de la zone est défaillant (la condition NodeReady est ConditionUnknown ou ConditionFalse) en même temps.
Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à `--large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
Ces stratégies sont implémentées par zone de disponibilité car une zone de disponibilité peut être partitionnée à partir du master, tandis que les autres restent connectées.
Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité de fournisseur de cloud, il n'existe qu'une seule zone de disponibilité (la totalité du cluster).
L'une des principales raisons de la répartition de vos nœuds entre les zones de disponibilité est de pouvoir déplacer la charge de travail vers des zones saines lorsqu'une zone entière tombe en panne.
Par conséquent, si tous les nœuds d’une zone sont défaillants, le contrôleur de nœud expulse à la vitesse normale `--node-eviction-rate`.
Le cas pathologique se produit lorsque toutes les zones sont complètement défaillantes (c'est-à-dire qu'il n'y a pas de nœuds sains dans le cluster).
Dans ce cas, le contrôleur de noeud suppose qu'il existe un problème de connectivité au master et arrête toutes les expulsions jusqu'à ce que la connectivité soit restaurée.
À partir de Kubernetes 1.6, NodeController est également responsable de l'expulsion des pods s'exécutant sur des noeuds avec des marques `NoExecute`, lorsque les pods ne tolèrent pas ces marques.
De plus, en tant que fonctionnalité alpha désactivée par défaut, NodeController est responsable de l'ajout de marques correspondant aux problèmes de noeud tels que les noeuds inaccessibles ou non prêts.
Voir [cette documentation](/docs/concepts/configuration/taint-and-toleration/) pour plus de détails sur les marques `NoExecute` et cette fonctionnalité alpha.
À partir de la version 1.8, le contrôleur de noeud peut être chargé de créer des tâches représentant les conditions de noeud.
Ceci est une fonctionnalité alpha de la version 1.8.
Le [nom](/fr/docs/concepts/overview/working-with-objects/names#noms) identifie un Nœud. Deux Nœuds
ne peuvent pas avoir le même nom en même temps. Kubernetes suppose également qu'une ressource avec le même
nom est le même objet. Dans le cas d'un Nœud, on suppose implicitement qu'une instance utilisant le
même nom aura le même état (par exemple, les paramètres réseau, le contenu du disque racine) et les mêmes attributs tels que
les étiquettes du nœud. Cela peut entraîner des incohérences si une instance a été modifiée sans changer son nom.
Si le Nœud doit être remplacé ou mis à jour de manière significative, l'objet Nœud existant doit être
supprimé du serveur API en premier lieu, puis ré-ajouté après la mise à jour.
### Auto-enregistrement des nœuds
Lorsque l'indicateur de kubelet `--register-node` est à true (valeur par défaut), le kubelet tente de s'enregistrer auprès du serveur d'API.
C'est le modèle préféré, utilisé par la plupart des distributions Linux.
Lorsque le drapeau kubelet `--register-node` est vrai (par défaut), le kubelet tente de
s'enregistrer auprès du serveur API. C'est le modèle préféré, utilisé par la plupart des distributions.
Pour l'auto-enregistrement (self-registration en anglais), le kubelet est lancé avec les options suivantes:
Pour l'auto-enregistrement, le kubelet est démarré avec les options suivantes :
- `--kubeconfig` - Chemin d'accès aux informations d'identification pour s'authentifier auprès de l'apiserver.
- `--cloud-provider` - Comment lire les métadonnées d'un fournisseur de cloud sur lui-même.
- `--register-node` - Enregistrement automatique avec le serveur API.
- `--register-with-taints` - Enregistrez le noeud avec la liste donnée de marques (séparés par des virgules `<key>=<value>:<effect>`). Sans effet si `register-node` est à false.
- `--node-ip` - Adresse IP du noeud.
- `--node-labels` - Labels à ajouter lors de l’enregistrement du noeud dans le cluster (voir Restrictions des labels appliquées par le [plugin NodeRestriction admission](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) dans les versions 1.13+).
- `--node-status-update-frequency` - Spécifie la fréquence à laquelle kubelet publie le statut de nœud sur master.
- `--kubeconfig` - Chemin vers les informations d'identification pour s'authentifier auprès du serveur API.
- `--cloud-provider` - Comment communiquer avec un {{< glossary_tooltip text="fournisseur de cloud" term_id="cloud-provider" >}}
pour lire les métadonnées à son sujet.
- `--register-node` - S'enregistrer automatiquement auprès du serveur API.
- `--register-with-taints` - Enregistrer le nœud avec la liste donnée de
{{< glossary_tooltip text="taints" term_id="taint" >}} (séparées par des virgules `<clé>=<valeur>:<effet>`).
Quand le mode [autorisation de nœud](/docs/reference/access-authn-authz/node/) et [plugin NodeRestriction admission](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) sont activés, les kubelets sont uniquement autorisés à créer / modifier leur propre ressource de noeud.
Ne fait rien si `register-node` est faux.
- `--node-ip` - Liste facultative de adresses IP séparées par des virgules pour le nœud.
Vous ne pouvez spécifier qu'une seule adresse pour chaque famille d'adresses.
Par exemple, dans un cluster IPv4 à pile unique, vous définissez cette valeur comme l'adresse IPv4 que le
kubelet doit utiliser pour le nœud.
Consultez [configurer une pile double IPv4/IPv6](/docs/concepts/services-networking/dual-stack/#configure-ipv4-ipv6-dual-stack)
pour plus de détails sur l'exécution d'un cluster à double pile.
#### Administration manuelle de noeuds
Si vous ne fournissez pas cet argument, le kubelet utilise l'adresse IPv4 par défaut du nœud, le cas échéant ;
si le nœud n'a pas d'adresses IPv4, alors le kubelet utilise l'adresse IPv6 par défaut du nœud.
- `--node-labels` - {{< glossary_tooltip text="Étiquettes" term_id="label" >}} à ajouter lors de l'enregistrement du nœud
dans le cluster (voir les restrictions d'étiquettes appliquées par le
[plugin d'admission NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
- `--node-status-update-frequency` - Spécifie à quelle fréquence le kubelet envoie son état de nœud au serveur API.
Un administrateur de cluster peut créer et modifier des objets de nœud.
Si l'administrateur souhaite créer des objets de noeud manuellement, définissez l'argument de kubelet: `--register-node=false`.
L'administrateur peut modifier les ressources du nœud (quel que soit le réglage de `--register-node`).
Les modifications comprennent la définition de labels sur le nœud et son marquage comme non programmable.
Les étiquettes sur les nœuds peuvent être utilisées avec les sélecteurs de nœuds sur les pods pour contrôler la planification. Par exemple, pour contraindre un pod à ne pouvoir s'exécuter que sur un sous-ensemble de nœuds.
Marquer un nœud comme non planifiable empêche la planification de nouveaux pods sur ce nœud, mais n'affecte pas les pods existants sur le nœud.
Ceci est utile comme étape préparatoire avant le redémarrage d'un nœud, etc. Par exemple, pour marquer un nœud comme non programmable, exécutez la commande suivante:
```shell
kubectl cordon $NODENAME
```
Lorsque le [mode d'autorisation du nœud](/docs/reference/access-authn-authz/node/) et
[le plugin d'admission NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
sont activés, les kubelets sont autorisés uniquement à créer/modifier leur propre ressource Nœud.
{{< note >}}
Les pods créés par un contrôleur DaemonSet contournent le planificateur Kubernetes et ne respectent pas l'attribut unschedulable sur un nœud.
Cela suppose que les démons appartiennent à la machine même si celle-ci est en cours de vidage des applications pendant qu'elle se prépare au redémarrage.
Comme mentionné dans la section [Unicité du nom du nœud](#node-name-uniqueness),
lorsque la configuration du nœud doit être mise à jour, il est recommandé de ré-enregistrer
le nœud auprès du serveur API. Par exemple, si le kubelet est redémarré avec
un nouvel ensemble de `--node-labels`, mais le même nom de Nœud est utilisé, le changement ne sera
pas pris en compte, car les étiquettes sont uniquement définies (ou modifiées) lors de l'enregistrement du Nœud auprès du serveur API.
Les Pods déjà planifiés sur le Nœud peuvent se comporter de manière incorrecte ou causer des problèmes si la configuration du Nœud
est modifiée lors du redémarrage du kubelet. Par exemple, un Pod déjà en cours d'exécution
peut être affecté par les nouvelles étiquettes attribuées au Nœud, tandis que d'autres
Pods, incompatibles avec ce Pod, seront planifiés en fonction de cette nouvelle
étiquette. La ré-enregistrement du Nœud garantit que tous les Pods seront évacués et correctement
re-planifiés.
{{< /note >}}
### Capacité de nœud
### Administration manuelle des nœuds
La capacité du nœud (nombre de CPU et quantité de mémoire) fait partie de l’objet Node.
Normalement, les nœuds s'enregistrent et indiquent leur capacité lors de la création de l'objet Node.
Si vous faites une [administration manuelle de nœud](#manual-node-administration), alors vous devez définir la capacité du nœud lors de l'ajout d'un nœud.
Vous pouvez créer et modifier des objets Nœud en utilisant
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}.
Le scheduler Kubernetes veille à ce qu'il y ait suffisamment de ressources pour tous les pods d'un noeud.
Il vérifie que la somme des demandes des conteneurs sur le nœud n'est pas supérieure à la capacité du nœud.
Cela inclut tous les conteneurs lancés par le kubelet, mais pas les conteneurs lancés directement par le [conteneur runtime](/docs/concepts/overview/components/#noeud-composants), ni aucun processus exécuté en dehors des conteneurs.
Lorsque vous souhaitez créer manuellement des objets Nœud, définissez le drapeau kubelet `--register-node=false`.
Si vous souhaitez réserver explicitement des ressources pour des processus autres que Pod, suivez ce tutoriel pour: [réserver des ressources pour les démons système](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
Vous pouvez modifier des objets Nœud indépendamment du paramètre `--register-node`.
Par exemple, vous pouvez définir des étiquettes sur un Nœud existant ou le marquer comme non planifiable.
## API Object
Vous pouvez utiliser des étiquettes sur les Nœuds en conjonction avec des sélecteurs de nœuds sur les Pods pour contrôler
la planification. Par exemple, vous pouvez restreindre un Pod à s'exécuter uniquement sur
un sous-ensemble des nœuds disponibles.
L'objet Node est une ressource de niveau supérieur dans l'API REST de Kubernetes.
Plus de détails sur l'objet API peuvent être trouvés à l'adresse suivante: [Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
Le marquage d'un nœud comme non planifiable empêche le planificateur de placer de nouveaux pods sur
ce Nœud, mais n'affecte pas les Pods existants sur le Nœud. Cela est utile comme
étape préparatoire avant un redémarrage du nœud ou une autre opération de maintenance.
Pour marquer un Nœud comme non planifiable, exécutez :
```shell
kubectl cordon $NOM_DU_NŒUD
```
Consultez [Évacuation sécurisée d'un nœud](/docs/tasks/administer-cluster/safely-drain-node/)
pour plus de détails.
{{< note >}}
Les Pods faisant partie d'un {{< glossary_tooltip term_id="daemonset" >}} tolèrent
le fait d'être exécutés sur un Nœud non planifiable. Les DaemonSets fournissent généralement des services locaux au nœud
qui doivent s'exécuter sur le Nœud même s'il est vidé des applications de charge de travail.
{{< /note >}}
## État du nœud
L'état d'un Nœud contient les informations suivantes :
* [Adresses](/docs/reference/node/node-status/#addresses)
* [Conditions](/docs/reference/node/node-status/#condition)
* [Capacité et Allocatable](/docs/reference/node/node-status/#capacity)
* [Info](/docs/reference/node/node-status/#info)
Vous pouvez utiliser `kubectl` pour afficher l'état d'un Nœud et d'autres détails :
```shell
kubectl describe node <insérez-le-nom-du-nœud-ici>
```
Consultez [État du nœud](/docs/reference/node/node-status/) pour plus de détails.
## Battements de cœur du nœud
Les battements de cœur, envoyés par les nœuds Kubernetes, aident votre cluster à déterminer
la disponibilité de chaque nœud et à prendre des mesures en cas de détection de défaillances.
Pour les nœuds, il existe deux formes de battements de cœur :
* Mises à jour de l'[`.status`](/docs/reference/node/node-status/) d'un Nœud.
* Objets [Lease](/docs/concepts/architecture/leases/)
dans l'espace de noms `kube-node-lease`.
Chaque Nœud a un objet Lease associé.
## Contrôleur de nœud
Le {{< glossary_tooltip text="contrôleur" term_id="controller" >}} de nœud est un
composant du plan de contrôle Kubernetes qui gère différents aspects des nœuds.
Le contrôleur de nœud a plusieurs rôles dans la vie d'un nœud. Le premier est d'attribuer un
bloc CIDR au nœud lors de son enregistrement (si l'attribution CIDR est activée).
Le deuxième est de maintenir à jour la liste interne des nœuds du contrôleur de nœud avec
la liste des machines disponibles du fournisseur de cloud. Lorsqu'il s'exécute dans un environnement cloud
et chaque fois qu'un nœud est en mauvaise santé, le contrôleur de nœud demande au fournisseur de cloud si la VM pour ce nœud est toujours disponible.
Si ce n'est pas le cas, le contrôleur de nœud supprime le nœud de sa liste de nœuds.
Le troisième est de surveiller la santé des nœuds. Le contrôleur de nœud est
responsable de :
- Dans le cas où un nœud devient injoignable, mettre à jour la condition `Ready`
dans le champ `.status` du Nœud. Dans ce cas, le contrôleur de nœud définit la
condition `Ready` à `Unknown`.
- Si un nœud reste injoignable : déclencher
[l'éviction initiée par l'API](/docs/concepts/scheduling-eviction/api-eviction/)
pour tous les Pods sur le nœud injoignable. Par défaut, le contrôleur de nœud
attend 5 minutes entre le marquage du nœud comme `Unknown` et la soumission
de la première demande d'éviction.
Par défaut, le contrôleur de nœud vérifie l'état de chaque nœud toutes les 5 secondes.
Cette période peut être configurée à l'aide du drapeau `--node-monitor-period` sur le
composant `kube-controller-manager`.
### Limites de taux sur l'éviction
Dans la plupart des cas, le contrôleur de nœud limite le taux d'éviction à
`--node-eviction-rate` (par défaut 0,1) par seconde, ce qui signifie qu'il n'évacuera pas les pods
de plus d'un nœud toutes les 10 secondes.
Le comportement d'éviction des nœuds change lorsqu'un nœud dans une zone de disponibilité donnée
devient en mauvaise santé. Le contrôleur de nœud vérifie quel pourcentage de nœuds dans la zone
sont en mauvaise santé (la condition `Ready` est `Unknown` ou `False`) en même temps :
- Si la fraction de nœuds en mauvaise santé est d'au moins `--unhealthy-zone-threshold`
(par défaut 0,55), alors le taux d'éviction est réduit.
- Si le cluster est petit (c'est-à-dire qu'il a moins ou égal à
`--large-cluster-size-threshold` nœuds - par défaut 50), alors les évictions sont arrêtées.
- Sinon, le taux d'éviction est réduit à `--secondary-node-eviction-rate`
(par défaut 0,01) par seconde.
La raison pour laquelle ces politiques sont mises en œuvre par zone de disponibilité est que
une zone de disponibilité peut être isolée du plan de contrôle tandis que les autres restent
connectées. Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité du fournisseur de cloud,
alors le mécanisme d'éviction ne prend pas en compte l'indisponibilité par zone.
Une raison clé de répartir vos nœuds sur plusieurs zones de disponibilité est de permettre
le déplacement de la charge de travail vers des zones saines lorsque toute une zone est hors service.
Par conséquent, si tous les nœuds d'une zone sont en mauvaise santé, alors le contrôleur de nœud évacue au
taux normal de `--node-eviction-rate`. Le cas particulier est lorsque toutes les zones sont
complètement en mauvaise santé (aucun des nœuds du cluster n'est en bonne santé). Dans un tel
cas, le contrôleur de nœud suppose qu'il y a un problème de connectivité
entre le plan de contrôle et les nœuds, et n'effectue aucune éviction.
(S'il y a eu une panne et que certains nœuds réapparaissent, le contrôleur de nœud évacue les pods
des nœuds restants qui sont en mauvaise santé ou injoignables).
Le contrôleur de nœud est également responsable de l'éviction des pods s'exécutant sur des nœuds avec
des {{< glossary_tooltip text="taints" term_id="taint" >}} `NoExecute`, sauf si ces pods tolèrent cette taint.
Le contrôleur de nœud ajoute également des {{< glossary_tooltip text="taints" term_id="taint" >}}
correspondant aux problèmes du nœud, tels que le nœud injoignable ou non prêt. Cela signifie
que le planificateur ne placera pas de Pods sur des nœuds en mauvaise santé.
## Suivi de la capacité des ressources du nœud {#node-capacity}
Les objets Nœud suivent des informations sur la capacité des ressources du Nœud : par exemple, la quantité
de mémoire disponible et le nombre de CPU.
Les nœuds qui [s'enregistrent automatiquement](#auto-enregistrement-des-nœuds) rapportent leur capacité lors de
l'enregistrement. Si vous les ajoutez [manuellement](#administration-manuelle-des-nœuds), alors
vous devez définir les informations de capacité du nœud lors de son ajout.
Les nœuds qui [s'enregistrent automatiquement](#auto-enregistrement-des-nœuds) rapportent leur capacité lors de l'enregistrement. Si vous les ajoutez [manuellement](#administration-manuelle-des-nœuds), alors vous devez définir les informations de capacité du nœud lors de son ajout.
Le planificateur Kubernetes s'assure qu'il y a suffisamment de ressources pour tous les Pods sur un Nœud. Le planificateur vérifie que la somme des demandes des conteneurs sur le nœud n'est pas supérieure à la capacité du nœud. Cette somme de demandes inclut tous les conteneurs gérés par le kubelet, mais exclut tout conteneur démarré directement par le runtime de conteneur, ainsi que tout processus s'exécutant en dehors du contrôle du kubelet.
{{< note >}}
Si vous souhaitez réserver explicitement des ressources pour des processus non-Pod, consultez la section [Réserver des ressources pour les démons système](/fr/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
{{< /note >}}
## Topologie du nœud
{{< feature-state feature_gate_name="TopologyManager" >}}
Si vous avez activé la fonctionnalité `TopologyManager` [feature gate](/fr/docs/reference/command-line-tools-reference/feature-gates/), alors le kubelet peut utiliser des indications de topologie lors de la prise de décision d'attribution des ressources. Consultez la section [Contrôler les stratégies de gestion de la topologie sur un nœud](/fr/docs/tasks/administer-cluster/topology-manager/) pour plus d'informations.
## Gestion de la mémoire swap {#swap-memory}
{{< feature-state feature_gate_name="NodeSwap" >}}
Pour activer la mémoire swap sur un nœud, la fonctionnalité `NodeSwap` doit être activée sur le kubelet (par défaut, elle est activée), et le drapeau de ligne de commande `--fail-swap-on` ou le paramètre de configuration `failSwapOn` [setting](/fr/docs/reference/config-api/kubelet-config.v1beta1/) doit être défini sur false. Pour permettre aux Pods d'utiliser la mémoire swap, `swapBehavior` ne doit pas être défini sur `NoSwap` (qui est le comportement par défaut) dans la configuration du kubelet.
{{< warning >}}
Lorsque la fonctionnalité de mémoire swap est activée, les données Kubernetes telles que le contenu des objets Secret qui ont été écrits dans tmpfs peuvent maintenant être échangées sur le disque.
{{< /warning >}}
Un utilisateur peut également configurer facultativement `memorySwap.swapBehavior` afin de spécifier comment un nœud utilisera la mémoire swap. Par exemple,
```yaml
memorySwap:
swapBehavior: LimitedSwap
```
- `NoSwap` (par défaut) : Les charges de travail Kubernetes n'utiliseront pas la mémoire swap.
- `LimitedSwap` : L'utilisation de la mémoire swap par les charges de travail Kubernetes est soumise à des limitations. Seuls les Pods de QoS Burstable sont autorisés à utiliser la mémoire swap.
Si la configuration pour `memorySwap` n'est pas spécifiée et que la fonctionnalité est activée, par défaut, le kubelet appliquera le même comportement que le paramètre `NoSwap`.
Avec `LimitedSwap`, les Pods qui ne relèvent pas de la classification QoS Burstable (c'est-à-dire les Pods QoS `BestEffort`/`Guaranteed`) sont interdits d'utiliser la mémoire swap. Pour maintenir les garanties de sécurité et de santé du nœud mentionnées ci-dessus, ces Pods ne sont pas autorisés à utiliser la mémoire swap lorsque `LimitedSwap` est en vigueur.
Avant de détailler le calcul de la limite d'échange, il est nécessaire de définir les termes suivants :
* `nodeTotalMemory` : La quantité totale de mémoire physique disponible sur le nœud.
* `totalPodsSwapAvailable` : La quantité totale de mémoire swap sur le nœud disponible pour une utilisation par les Pods (une partie de la mémoire swap peut être réservée à des fins système).
* `containerMemoryRequest` : La demande de mémoire du conteneur.
La limitation d'échange est configurée comme suit :
`(containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable`.
Il est important de noter que, pour les conteneurs dans les Pods de QoS Burstable, il est possible de désactiver l'utilisation de l'échange en spécifiant des demandes de mémoire égales aux limites de mémoire. Les conteneurs configurés de cette manière n'auront pas accès à la mémoire swap.
L'échange est pris en charge uniquement avec **cgroup v2**, cgroup v1 n'est pas pris en charge.
Pour plus d'informations, et pour aider aux tests et fournir des commentaires, veuillez consulter l'article de blog sur [Kubernetes 1.28 : NodeSwap passe en version Beta1](/fr/blog/2023/08/24/swap-linux-beta/), [KEP-2400](https://github.com/kubernetes/enhancements/issues/4128) et sa [proposition de conception](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md).
## {{% heading "whatsnext" %}}
En savoir plus sur les éléments suivants :
* [Les composants](/fr/docs/concepts/architecture/#node-components) qui composent un nœud.
* [Définition de l'API pour le nœud](/fr/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
* La section [Nœud](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) du document de conception de l'architecture.
* [Arrêt du nœud en mode normal ou non normal](/fr/docs/concepts/cluster-administration/node-shutdown/).
* [Mise à l'échelle automatique du cluster](/fr/docs/concepts/cluster-administration/cluster-autoscaling/) pour gérer le nombre et la taille des nœuds de votre cluster.
* [Taints et Tolerations](/fr/docs/concepts/scheduling-eviction/taint-and-toleration/).
* [Gestion des ressources du nœud](/fr/docs/concepts/policy/node-resource-managers/).
* [Gestion des ressources pour les nœuds Windows](/fr/docs/concepts/configuration/windows-resource-management/).

20
content/fr/docs/reference/glossary/api-group.md Normal file
View File

@ -0,0 +1,20 @@
---
title: Groupe d'API
id: api-group
date: 2024-09-12
full_link: /fr/docs/concepts/overview/kubernetes-api/#groupes-d-api-et-versioning
short_description: >
Un ensemble de chemins liés dans l'API Kubernetes.
aka:
tags:
- fundamental
- architecture
---
Un ensemble de chemins liés dans l'API Kubernetes.
<!--more-->
Vous pouvez activer ou désactiver chaque groupe d'API en modifiant la configuration de votre serveur API. Vous pouvez également désactiver ou activer des chemins vers des ressources spécifiques. Le groupe d'API facilite l'extension de l'API Kubernetes. Le groupe d'API est spécifié dans un chemin REST et dans le champ `apiVersion` d'un objet sérialisé.
* Lire [Groupe d'API](/fr/docs/concepts/overview/kubernetes-api/#groupes-d-api-et-versioning) pour plus d'informations.

17
content/fr/docs/reference/glossary/cadvisor.md Normal file
View File

@ -0,0 +1,17 @@
---
titre: cAdvisor
id: cadvisor
date: 2024-09-12
full_link: https://github.com/google/cadvisor/
short_description: >
Outil qui permet de comprendre l'utilisation des ressources et les caractéristiques de performance des conteneurs
aka:
tags:
- tool
---
cAdvisor (Container Advisor) offre aux utilisateurs de conteneurs une compréhension de l'utilisation des ressources et des caractéristiques de performance de leurs {{< glossary_tooltip text="conteneurs" term_id="container" >}} en cours d'exécution.
<!--more-->
C'est un démon en cours d'exécution qui collecte, agrège, traite et exporte des informations sur les conteneurs en cours d'exécution. Plus précisément, pour chaque conteneur, il conserve les paramètres d'isolation des ressources, l'historique de l'utilisation des ressources, les histogrammes de l'utilisation complète des ressources historiques et les statistiques réseau. Ces données sont exportées par conteneur et à l'échelle de la machine.

19
content/fr/docs/reference/glossary/kubernetes-api.md Normal file
View File

@ -0,0 +1,19 @@
---
title: API Kubernetes
id: kubernetes-api
date: 2024-09-12
full_link: /fr/docs/concepts/overview/kubernetes-api/
short_description: >
L'application qui offre les fonctionnalités de Kubernetes via une interface RESTful et stocke l'état du cluster.
aka:
tags:
- fundamental
- architecture
---
L'application qui offre les fonctionnalités de Kubernetes via une interface RESTful et stocke l'état du cluster.
<!--more-->
Les ressources Kubernetes et les "enregistrements d'intention" sont tous stockés sous forme d'objets API et modifiés via des appels RESTful à l'API. L'API permet de gérer la configuration de manière déclarative. Les utilisateurs peuvent interagir directement avec l'API Kubernetes ou via des outils tels que `kubectl`. L'API principale de Kubernetes est flexible et peut également être étendue pour prendre en charge des ressources personnalisées.

20
content/fr/docs/reference/glossary/node.md Normal file
View File

@ -0,0 +1,20 @@
---
titre: Node
id: node
date: 2024-09-12
full_link: /fr/docs/concepts/architecture/nodes/
short_description: >
Un nœud est une machine de travail dans Kubernetes.
alias:
tags:
- fundamental
---
Un nœud est une machine de travail dans Kubernetes.
<!--more-->
Un nœud de travail peut être une machine virtuelle ou physique, selon le cluster. Il dispose de démons ou de services locaux nécessaires pour exécuter les {{< glossary_tooltip text="Pods" term_id="pod" >}} et est géré par le plan de contrôle. Les démons sur un nœud comprennent {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, et un moteur d'exécution de conteneur implémentant le {{< glossary_tooltip text="CRI" term_id="cri" >}} tel que {{< glossary_tooltip term_id="docker" >}}.
Dans les premières versions de Kubernetes, les nœuds étaient appelés "Minions".

20
content/fr/docs/reference/glossary/rbac.md Normal file
View File

@ -0,0 +1,20 @@
---
titre: RBAC (Contrôle d'accès basé sur les rôles)
id: rbac
date: 2024-09-12
full_link: /docs/reference/access-authn-authz/rbac/
short_description: >
Gère les décisions d'autorisation, permettant aux administrateurs de configurer dynamiquement les politiques d'accès via l'API Kubernetes.
aka:
tags:
- security
- fundamental
---
Gère les décisions d'autorisation, permettant aux administrateurs de configurer dynamiquement les politiques d'accès via l'{{< glossary_tooltip text="API Kubernetes" term_id="kubernetes-api" >}}.
<!--more-->
RBAC utilise des *rôles*, qui contiennent des règles de permission, et des *rôles de liaison*, qui accordent les permissions définies dans un rôle à un ensemble d'utilisateurs.

27
content/fr/docs/reference/glossary/replica.md Normal file
View File

@ -0,0 +1,27 @@
---
title: Replica
id: replica
date: 2024-09-12
full_link:
short_description: >
Les replicas sont des copies de pods, assurant la disponibilité, la scalabilité et la tolérance aux pannes en maintenant des instances identiques.
aka:
tags:
- fondamental
- charge de travail
---
Une copie ou un duplicata d'un {{< glossary_tooltip text="Pod" term_id="pod" >}} ou
d'un ensemble de pods. Les `replicas` garantissent une disponibilité élevée, une scalabilité et une tolérance aux pannes
en maintenant plusieurs instances identiques d'un pod.
<!--more-->
Les `replicas` sont couramment utilisées dans Kubernetes pour atteindre l'état et la fiabilité souhaités de l'application.
Elles permettent de mettre à l'échelle et de distribuer la charge de travail sur plusieurs nœuds d'un cluster.
En définissant le nombre de `replicas` dans un déploiement ou un ReplicaSet, Kubernetes garantit que
le nombre spécifié d'instances est en cours d'exécution, ajustant automatiquement le compte selon les besoins.
La gestion des `replicas` permet un équilibrage de charge efficace, des mises à jour progressives et
des capacités d'auto-guérison dans un cluster Kubernetes.