diff --git a/content/fr/_index.html b/content/fr/_index.html index 11cbcc140a..4e1fa8f6d4 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -10,7 +10,7 @@ sitemap: {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} -### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. +### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/" >}}) est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Les conteneurs qui composent une application sont regroupés dans des unités logiques pour en faciliter la gestion et la découverte. Kubernetes s’appuie sur [15 années d’expérience dans la gestion de charges de travail de production (workloads) chez Google](http://queue.acm.org/detail.cfm?id=2898444), associé aux meilleures idées et pratiques de la communauté. {{% /blocks/feature %}} diff --git a/content/fr/docs/concepts/_index.md b/content/fr/docs/concepts/_index.md index 8819065e27..8197a585b3 100644 --- a/content/fr/docs/concepts/_index.md +++ b/content/fr/docs/concepts/_index.md @@ -40,7 +40,7 @@ Les objets de base de Kubernetes incluent: * [Pod](/docs/concepts/workloads/pods/pod-overview/) * [Service](/docs/concepts/services-networking/service/) * [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) +* [Namespace](/fr/docs/concepts/overview/working-with-objects/namespaces/) En outre, Kubernetes contient un certain nombre d'abstractions de niveau supérieur appelées Contrôleurs. Les contrôleurs s'appuient sur les objets de base et fournissent des fonctionnalités supplémentaires. @@ -79,7 +79,7 @@ Le master node Kubernetes contrôle chaque noeud; vous interagirez rarement dire #### Metadonnées des objets Kubernetes -* [Annotations](/docs/concepts/overview/working-with-objects/annotations/) +* [Annotations](/fr/docs/concepts/overview/working-with-objects/annotations/) diff --git a/content/fr/docs/concepts/overview/_index.md b/content/fr/docs/concepts/overview/_index.md index 77ee0cc100..a2d729a8c9 100644 --- a/content/fr/docs/concepts/overview/_index.md +++ b/content/fr/docs/concepts/overview/_index.md @@ -1,5 +1,110 @@ --- title: Vue d'ensemble -description: Vue d'ensemble Kubernetes +description: > + Kubernetes est une plateforme open source portable et extensible pour gérer les charges de travail et les services conteneurisés, qui facilite à la fois la configuration déclarative et l'automatisation. Il dispose d'un écosystème vaste et en pleine croissance. Les services, le support et les outils Kubernetes sont largement disponibles. +content_type: concept weight: 20 +card: + name: concepts + weight: 10 + anchors: + - anchor: "#pourquoi-vous-avez-besoin-de-kubernetes-et-ce-quil-peut-faire" + title: Pourquoi Kubernetes ? +no_list: true --- + + +Cette page est une vue d'ensemble de Kubernetes. + + + + +Kubernetes est une plateforme open source portable et extensible pour gérer les charges de travail et les services conteneurisés, qui facilite à la fois la configuration déclarative et l'automatisation. Il dispose d'un écosystème vaste et en pleine croissance. Les services, le support et les outils Kubernetes sont largement disponibles. + +Le nom Kubernetes provient du grec, signifiant timonier ou pilote. K8s comme abréviation résulte du comptage des huit lettres entre le "K" et le "s". Google a open-sourcé le projet Kubernetes en 2014. Kubernetes combine [plus de 15 ans d'expérience de Google](/blog/2015/04/borg-predecessor-to-kubernetes/) dans l'exécution de charges de travail en production à grande échelle avec les meilleures idées et pratiques de la communauté. + +## Pourquoi vous avez besoin de Kubernetes et ce qu'il peut faire {#pourquoi-vous-avez-besoin-de-kubernetes-et-ce-quil-peut-faire} + +Les conteneurs sont un bon moyen de regrouper et d'exécuter vos applications. Dans un environnement de production, vous devez gérer les conteneurs qui exécutent les applications et vous assurer qu'il n'y a pas de temps d'arrêt. Par exemple, si un conteneur tombe en panne, un autre conteneur doit démarrer. Ne serait-il pas plus facile si ce comportement était géré par un système ? + +C'est là que Kubernetes vient à la rescousse ! Kubernetes vous fournit un cadre pour exécuter des systèmes distribués de manière résiliente. Il prend en charge la mise à l'échelle et le basculement pour votre application, fournit des modèles de déploiement, et plus encore. Par exemple : Kubernetes peut facilement gérer un déploiement canari pour votre système. + +Kubernetes vous fournit : + +* **Découverte de services et équilibrage de charge** + Kubernetes peut exposer un conteneur en utilisant le nom DNS ou en utilisant leur propre adresse IP. Si le trafic vers un conteneur est élevé, Kubernetes est capable d'équilibrer la charge et de distribuer le trafic réseau afin que le déploiement soit stable. +* **Orchestration du stockage** + Kubernetes vous permet de monter automatiquement un système de stockage de votre choix, tel que des stockages locaux, des fournisseurs de cloud public, et plus encore. +* **Déploiements et retours en arrière automatisés** + Vous pouvez décrire l'état souhaité pour vos conteneurs déployés en utilisant Kubernetes, et il peut changer l'état actuel pour l'état souhaité à un rythme contrôlé. Par exemple, vous pouvez automatiser Kubernetes pour créer de nouveaux conteneurs pour votre déploiement, supprimer les conteneurs existants et adopter toutes leurs ressources pour le nouveau conteneur. +* **Emballage automatique des conteneurs** + Vous fournissez à Kubernetes un cluster de nœuds qu'il peut utiliser pour exécuter des tâches conteneurisées. Vous dites à Kubernetes combien de CPU et de mémoire (RAM) chaque conteneur a besoin. Kubernetes peut ajuster les conteneurs sur vos nœuds pour faire le meilleur usage de vos ressources. +* **Auto-guérison** + Kubernetes redémarre les conteneurs qui échouent, remplace les conteneurs, tue les conteneurs qui ne répondent pas à votre vérification de santé définie par l'utilisateur, et ne les annonce pas aux clients tant qu'ils ne sont pas prêts à servir. +* **Gestion des secrets et de la configuration** + Kubernetes vous permet de stocker et de gérer des informations sensibles, telles que des mots de passe, des jetons OAuth et des clés SSH. Vous pouvez déployer et mettre à jour des secrets et la configuration de l'application sans reconstruire vos images de conteneur, et sans exposer les secrets dans votre configuration de pile. +* **Exécution par lots** + En plus des services, Kubernetes peut gérer vos charges de travail par lots et CI, en remplaçant les conteneurs qui échouent, si désiré. +* **Mise à l'échelle horizontale** + Mettez à l'échelle votre application vers le haut et vers le bas avec une simple commande, avec une interface utilisateur, ou automatiquement en fonction de l'utilisation du CPU. +* **Double pile IPv4/IPv6** + Allocation d'adresses IPv4 et IPv6 aux Pods et Services +* **Conçu pour l'extensibilité** + Ajoutez des fonctionnalités à votre cluster Kubernetes sans changer le code source en amont. + +## Ce que Kubernetes n'est pas + +Kubernetes n'est pas un système PaaS (Platform as a Service) traditionnel et tout compris. Étant donné que Kubernetes fonctionne au niveau des conteneurs plutôt qu'au niveau du matériel, il fournit certaines fonctionnalités généralement applicables communes aux offres PaaS, telles que le déploiement, la mise à l'échelle, l'équilibrage de charge, et permet aux utilisateurs d'intégrer leurs solutions de journalisation, de surveillance et d'alerte. Cependant, Kubernetes n'est pas monolithique, et ces solutions par défaut sont optionnelles et plugables. Kubernetes fournit les blocs de construction pour créer des plateformes de développement, mais préserve le choix et la flexibilité de l'utilisateur là où c'est important. + +Kubernetes : + +* Ne limite pas les types d'applications prises en charge. Kubernetes vise à prendre en charge une variété extrêmement diversifiée de charges de travail, y compris les charges de travail sans état, avec état et de traitement de données. Si une application peut fonctionner dans un conteneur, elle devrait bien fonctionner sur Kubernetes. +* Ne déploie pas de code source et ne construit pas votre application. Les workflows d'intégration continue, de livraison et de déploiement (CI/CD) sont déterminés par les cultures et les préférences des organisations ainsi que par les exigences techniques. +* Ne fournit pas de services au niveau de l'application, tels que des middleware (par exemple, des bus de messages), des frameworks de traitement de données (par exemple, Spark), des bases de données (par exemple, MySQL), des caches, ni des systèmes de stockage de cluster (par exemple, Ceph) en tant que services intégrés. De tels composants peuvent fonctionner sur Kubernetes, et/ou peuvent être accessibles par des applications fonctionnant sur Kubernetes via des mécanismes portables, tels que le [Open Service Broker](https://openservicebrokerapi.org/). +* Ne dicte pas de solutions de journalisation, de surveillance ou d'alerte. Il fournit certaines intégrations comme preuve de concept, et des mécanismes pour collecter et exporter des métriques. +* Ne fournit ni n'adopte de langage/système de configuration complet (par exemple, Jsonnet). Il fournit une API déclarative qui peut être ciblée par des formes arbitraires de spécifications déclaratives. +* Ne fournit ni n'adopte de systèmes complets de configuration, de maintenance, de gestion ou d'auto-guérison des machines. +* De plus, Kubernetes n'est pas un simple système d'orchestration. En fait, il élimine le besoin d'orchestration. La définition technique de l'orchestration est l'exécution d'un workflow défini : d'abord faire A, puis B, puis C. En revanche, Kubernetes comprend un ensemble de processus de contrôle indépendants et composables qui conduisent continuellement l'état actuel vers l'état souhaité fourni. Peu importe comment vous passez de A à C. Le contrôle centralisé n'est pas non plus requis. Cela se traduit par un système plus facile à utiliser et plus puissant, robuste, résilient et extensible. + +## Contexte historique de Kubernetes {#retour-dans-le-temps} + +Jetons un coup d'œil à pourquoi Kubernetes est si utile en remontant dans le temps. + +![Évolution du déploiement](/images/docs/Container_Evolution.svg) + +**Ère du déploiement traditionnel :** + +Au début, les organisations exécutaient des applications sur des serveurs physiques. Il n'y avait aucun moyen de définir des limites de ressources pour les applications dans un serveur physique, et cela causait des problèmes d'allocation de ressources. Par exemple, si plusieurs applications s'exécutent sur un serveur physique, il peut y avoir des instances où une application prendrait la plupart des ressources, et par conséquent, les autres applications sous-performeraient. Une solution à cela serait d'exécuter chaque application sur un serveur physique différent. Mais cela ne se généralisait pas car les ressources étaient sous-utilisées, et il était coûteux pour les organisations de maintenir de nombreux serveurs physiques. + +**Ère du déploiement virtualisé :** + +En guise de solution, la virtualisation a été introduite. Elle permet d'exécuter plusieurs machines virtuelles (VM) sur le CPU d'un seul serveur physique. La virtualisation permet aux applications d'être isolées entre les VM et fournit un niveau de sécurité car les informations d'une application ne peuvent pas être librement accessibles par une autre application. + +La virtualisation permet une meilleure utilisation des ressources dans un serveur physique et permet une meilleure évolutivité car une application peut être ajoutée ou mise à jour facilement, réduit les coûts matériels, et bien plus encore. Avec la virtualisation, vous pouvez présenter un ensemble de ressources physiques comme un cluster de machines virtuelles jetables. + +Chaque VM est une machine complète exécutant tous les composants, y compris son propre système d'exploitation, sur le matériel virtualisé. + +**Ère du déploiement de conteneurs :** + +Les conteneurs sont similaires aux VM, mais ils ont des propriétés d'isolation assouplies pour partager le système d'exploitation (OS) entre les applications. Par conséquent, les conteneurs sont considérés comme légers. Similaire à une VM, un conteneur a son propre système de fichiers, part de CPU, mémoire, espace de processus, et plus encore. Comme ils sont découplés de l'infrastructure sous-jacente, ils sont portables à travers les clouds et les distributions OS. + +Les conteneurs sont devenus populaires car ils offrent des avantages supplémentaires, tels que : + +* Création et déploiement d'applications agiles : facilité et efficacité accrues de la création d'images de conteneurs par rapport à l'utilisation d'images VM. +* Développement, intégration et déploiement continus : permet une construction et un déploiement fiables et fréquents d'images de conteneurs avec des retours en arrière rapides et efficaces (en raison de l'immutabilité des images). +* Séparation des préoccupations Dev et Ops : créer des images de conteneurs d'application au moment de la construction/libération plutôt qu'au moment du déploiement, découplant ainsi les applications de l'infrastructure. +* Observabilité : non seulement surface les informations et métriques au niveau de l'OS, mais aussi la santé de l'application et d'autres signaux. +* Cohérence environnementale entre le développement, les tests et la production : fonctionne de la même manière sur un ordinateur portable que dans le cloud. +* Portabilité des clouds et des distributions OS : fonctionne sur Ubuntu, RHEL, CoreOS, sur site, sur les principaux clouds publics, et partout ailleurs. +* Gestion centrée sur les applications : élève le niveau d'abstraction de l'exécution d'un OS sur du matériel virtuel à l'exécution d'une application sur un OS utilisant des ressources logiques. +* Micro-services distribués, élastiques et libérés, faiblement couplés : les applications sont divisées en morceaux plus petits et indépendants et peuvent être déployées et gérées dynamiquement – pas une pile monolithique fonctionnant sur une grande machine à usage unique. +* Isolation des ressources : performance d'application prévisible. +* Utilisation des ressources : haute efficacité et densité. + + +## {{% heading "whatsnext" %}} + +* Jetez un coup d'œil aux [Composants Kubernetes](/fr/docs/concepts/overview/components/) +* Jetez un coup d'œil à [L'API Kubernetes](/fr/docs/concepts/overview/kubernetes-api/) +* Jetez un coup d'œil à [L'Architecture du Cluster](/docs/concepts/architecture/) +* Prêt à [Commencer](/docs/setup/) ? \ No newline at end of file diff --git a/content/fr/docs/concepts/overview/components.md b/content/fr/docs/concepts/overview/components.md index 8adc32f78e..129b9ec97a 100644 --- a/content/fr/docs/concepts/overview/components.md +++ b/content/fr/docs/concepts/overview/components.md @@ -1,129 +1,88 @@ --- title: Composants de Kubernetes content_type: concept -weight: 20 +description: > + Un aperçu des principaux composants qui constituent un cluster Kubernetes. +weight: 10 card: + title: Composants d'un cluster name: concepts weight: 20 --- -Ce document résume les divers composants binaires requis pour livrer -un cluster Kubernetes fonctionnel. +Cette page fournit un aperçu général des composants essentiels qui constituent un cluster Kubernetes. + +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Composants de Kubernetes" caption="Les composants d'un cluster Kubernetes" class="diagram-large" clicktozoom="true" >}} -## Composants Master -Les composants Master fournissent le plan de contrôle (control plane) du cluster. -Les composants Master prennent des décisions globales à propos du cluster (par exemple, la planification (scheduling)). -Ils détectent et répondent aux événements du cluster (par exemple, démarrer un nouveau {{< glossary_tooltip text="Pod" term_id="pod">}} lorsque le champ `replicas` d'un déploiement n'est pas satisfait). +## Composants principaux -Les composants Master peuvent être exécutés sur n'importe quelle machine du cluster. Toutefois, -par soucis de simplicité, les scripts de mise en route démarrent typiquement tous les composants master sur la -même machine et n'exécutent pas de conteneurs utilisateur sur cette machine. -Voir [Construire des Clusters en Haute Disponibilité](/docs/admin/high-availability/) pour une configuration d'exemple en multi-master-VM. +Un cluster Kubernetes est composé d'un plan de contrôle et d'un ou plusieurs nœuds de travail. +Voici un bref aperçu des principaux composants : -### kube-apiserver +### Composants du plan de contrôle -{{< glossary_definition term_id="kube-apiserver" length="all" >}} +Gèrent l'état global du cluster : -### etcd +[kube-apiserver](/docs/concepts/architecture/#kube-apiserver) +: Le serveur principal qui expose l'API HTTP de Kubernetes -{{< glossary_definition term_id="etcd" length="all" >}} +[etcd](/docs/concepts/architecture/#etcd) +: Un magasin de clés-valeurs cohérent et hautement disponible pour toutes les données du serveur API -### kube-scheduler +[kube-scheduler](/docs/concepts/architecture/#kube-scheduler) +: Recherche les Pods qui ne sont pas encore liés à un nœud et attribue chaque Pod à un nœud approprié. -{{< glossary_definition term_id="kube-scheduler" length="all" >}} +[kube-controller-manager](/docs/concepts/architecture/#kube-controller-manager) +: Exécute des {{< glossary_tooltip text="contrôleurs" term_id="controller" >}} pour mettre en œuvre le comportement de l'API Kubernetes. -### kube-controller-manager +[cloud-controller-manager](/docs/concepts/architecture/#cloud-controller-manager) (optionnel) +: S'intègre aux fournisseurs de cloud sous-jacents. -{{< glossary_definition term_id="kube-controller-manager" length="all" >}} +### Composants des nœuds -Ces contrôleurs incluent : +S'exécutent sur chaque nœud, maintiennent les pods en cours d'exécution et fournissent l'environnement d'exécution Kubernetes : - * Node Controller : Responsable de détecter et apporter une réponse lorsqu'un nœud tombe en panne. - * Replication Controller : Responsable de maintenir le bon nombre de pods pour chaque objet - ReplicationController dans le système. - * Endpoints Controller : Remplit les objets Endpoints (c'est-à-dire joint les Services et Pods). - * Service Account & Token Controllers : Créent des comptes par défaut et des jetons d'accès à l'API - pour les nouveaux namespaces. +[kubelet](/docs/concepts/architecture/#kubelet) +: Veille à ce que les Pods s'exécutent, y compris leurs conteneurs. -### cloud-controller-manager +[kube-proxy](/docs/concepts/architecture/#kube-proxy) (optionnel) +: Maintient les règles réseau sur les nœuds pour mettre en œuvre les {{< glossary_tooltip text="Services" term_id="service" >}}. -Le [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) exécute les contrôleurs -qui interagissent avec les fournisseurs cloud sous-jacents. Le binaire du cloud-controller-manager est une -fonctionnalité alpha introduite dans la version 1.6 de Kubernetes. +[Runtime de conteneur](/docs/concepts/architecture/#container-runtime) +: Logiciel responsable de l'exécution des conteneurs. Lisez + [Runtimes de conteneurs](/docs/setup/production-environment/container-runtimes/) pour en savoir plus. -Le cloud-controller-manager exécute seulement les boucles spécifiques des fournisseurs cloud. -Vous devez désactiver ces boucles de contrôleurs dans le kube-controller-manager. -Vous pouvez désactiver les boucles de contrôleurs en définissant la valeur du flag `--cloud-provider` à `external` lors du démarrage du kube-controller-manager. +{{% thirdparty-content single="true" %}} -Le cloud-controller-manager permet au code du fournisseur cloud et au code de Kubernetes d'évoluer indépendamment l'un de l'autre. -Dans des versions antérieures, le code de base de Kubernetes dépendait du code spécifique du fournisseur cloud pour la fonctionnalité. Dans des versions ultérieures, le code spécifique des fournisseurs cloud devrait être maintenu par les fournisseurs cloud eux-mêmes et lié au cloud-controller-manager lors de l'exécution de Kubernetes. +Votre cluster peut nécessiter des logiciels supplémentaires sur chaque nœud ; par exemple, vous pouvez également +exécuter [systemd](https://systemd.io/) sur un nœud Linux pour superviser les composants locaux. -Les contrôleurs suivants ont des dépendances vers des fournisseurs cloud : +## Extensions - * Node Controller : Pour vérifier le fournisseur de cloud afin de déterminer si un nœud a été supprimé dans le cloud après avoir cessé de répondre - * Route Controller : Pour mettre en place des routes dans l'infrastructure cloud sous-jacente - * Service Controller : Pour créer, mettre à jour et supprimer les load balancers des fournisseurs cloud - * Volume Controller : Pour créer, attacher et monter des Volumes, et interagir avec le fournisseur cloud pour orchestrer les volumes. +Les extensions étendent les fonctionnalités de Kubernetes. Quelques exemples importants incluent : -## Composants de nœud +[DNS](/docs/concepts/architecture/#dns) +: Pour la résolution DNS à l'échelle du cluster -Les composants de nœud (Node components) s'exécutent sur chaque nœud, en maintenant les pods en exécution -et en fournissant l'environnement d'exécution Kubernetes. +[Interface utilisateur Web](/docs/concepts/architecture/#web-ui-dashboard) (Tableau de bord) +: Pour la gestion du cluster via une interface web -### kubelet +[Surveillance des ressources des conteneurs](/docs/concepts/architecture/#container-resource-monitoring) +: Pour collecter et stocker les métriques des conteneurs -{{< glossary_definition term_id="kubelet" length="all" >}} +[Journalisation au niveau du cluster](/docs/concepts/architecture/#cluster-level-logging) +: Pour enregistrer les journaux des conteneurs dans un référentiel de journaux centralisé -### kube-proxy +## Flexibilité dans l'architecture -{{< glossary_definition term_id="kube-proxy" length="all" >}} +Kubernetes permet une flexibilité dans la façon dont ces composants sont déployés et gérés. +L'architecture peut être adaptée à différents besoins, des environnements de développement réduits +aux déploiements de production à grande échelle. -### Container Runtime - -{{< glossary_definition term_id="container-runtime" length="all" >}} - -## Addons - -Les addons utilisent les ressources Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) -pour implémenter des fonctionnalités cluster. Comme ces derniers fournissent des fonctionnalités au niveau -du cluster, les ressources dans des namespaces pour les addons appartiennent au namespace `kube-system`. - -Les addons sélectionnés sont décrits ci-dessous. Pour une liste étendue des addons disponibles, voir la page -[Addons](/docs/concepts/cluster-administration/addons/). - -### DNS - -Tandis que les autres addons ne sont pas strictement requis, tous les clusters Kubernetes devraient avoir un -[DNS cluster](/fr/docs/concepts/services-networking/dns-pod-service/) car de nombreux exemples en dépendent. - -Le DNS Cluster est un serveur DNS, en plus des autres serveurs DNS dans votre environnement, qui sert -les 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) - -Le [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur web à but général pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de dépanner aussi bien des -applications s'exécutant dans le cluster que le cluster lui-même. - -### La surveillance des ressources de conteneur - -[La surveillance des ressources de conteneur](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) enregistre des métriques chronologiques génériques à propos des conteneurs dans une base de données centrale et -fournit une interface utilisateur pour parcourir ces données. - -### Le logging au niveau cluster - -Un mécanisme de [logging au niveau cluster](/docs/concepts/cluster-administration/logging/) est chargé -de sauvegarder les logs des conteneurs dans un magasin de logs central avec une interface de recherche/navigation. - - -## {{% heading "whatsnext" %}} - -* En savoir plus sur les [Nœuds](/fr/docs/concepts/architecture/nodes/) -* En savoir plus sur [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) -* Lire la [documentation officielle d'etcd](https://etcd.io/docs/) +Pour plus d'informations détaillées sur chaque composant et les différentes façons de configurer votre +architecture de cluster, consultez la page [Architecture du cluster](/docs/concepts/architecture/). diff --git a/content/fr/docs/concepts/overview/kubernetes-api.md b/content/fr/docs/concepts/overview/kubernetes-api.md new file mode 100644 index 0000000000..60ea6bad41 --- /dev/null +++ b/content/fr/docs/concepts/overview/kubernetes-api.md @@ -0,0 +1,343 @@ +--- +title: L'API Kubernetes +content_type: concept +weight: 40 +description: > + L'API Kubernetes vous permet d'interroger et de manipuler l'état des objets dans Kubernetes. + Le cœur du plan de contrôle de Kubernetes est le serveur API et l'API HTTP qu'il expose. Les utilisateurs, les différentes parties de votre cluster et les composants externes communiquent tous entre eux via le serveur API. +card: + name: concepts + weight: 30 +--- + + + +Le cœur du {{< glossary_tooltip text="plan de contrôle" term_id="control-plane" >}} de Kubernetes +est le {{< glossary_tooltip text="serveur API" term_id="kube-apiserver" >}}. Le serveur API +expose une API HTTP qui permet aux utilisateurs finaux, aux différentes parties de votre cluster et +aux composants externes de communiquer entre eux. + +L'API Kubernetes vous permet d'interroger et de manipuler l'état des objets API dans Kubernetes +(par exemple : Pods, Namespaces, ConfigMaps et Events). + +La plupart des opérations peuvent être effectuées via l'interface de ligne de commande [kubectl](/docs/reference/kubectl/) +ou d'autres outils en ligne de commande, tels que +[kubeadm](/docs/reference/setup-tools/kubeadm/), qui utilisent à leur tour l'API. +Cependant, vous pouvez également accéder à l'API directement en utilisant des appels REST. Kubernetes +fournit un ensemble de [bibliothèques clientes](/docs/reference/using-api/client-libraries/) +pour ceux qui souhaitent écrire des applications utilisant l'API Kubernetes. + +Chaque cluster Kubernetes publie la spécification des API qu'il sert. +Il existe deux mécanismes que Kubernetes utilise pour publier ces spécifications d'API ; les deux sont utiles +pour permettre une interopérabilité automatique. Par exemple, l'outil `kubectl` récupère et met en cache l'API +spécification pour activer l'auto-complétion en ligne de commande et d'autres fonctionnalités. +Les deux mécanismes pris en charge sont les suivants : + +- [L'API Discovery](#discovery-api) fournit des informations sur les API Kubernetes : + noms des API, ressources, versions et opérations prises en charge. Il s'agit d'un terme spécifique à Kubernetes car il s'agit d'une API distincte de l'API OpenAPI de Kubernetes. + Il est destiné à être un bref résumé des ressources disponibles et il ne détaille pas + le schéma spécifique des ressources. Pour des références sur les schémas de ressources, + veuillez vous référer au document OpenAPI. + +- Le [document OpenAPI de Kubernetes](#openapi-interface-definition) fournit des schémas (complets) + [OpenAPI v2.0 et 3.0](https://www.openapis.org/) pour tous les points d'extrémité de l'API Kubernetes. + L'OpenAPI v3 est la méthode préférée pour accéder à l'OpenAPI car il + offre une vue plus complète et précise de l'API. Il inclut tous les chemins d'API disponibles, + ainsi que toutes les ressources consommées et produites pour chaque opération + sur chaque point d'extrémité. Il inclut également les composants d'extensibilité pris en charge par un cluster. + Les données sont une spécification complète et sont significativement plus grandes que celles de l'API Discovery. + +## API Discovery + +Kubernetes publie une liste de toutes les versions de groupe et de toutes les ressources prises en charge via +l'API Discovery. Cela inclut les éléments suivants pour chaque ressource : + +- Nom +- Portée du cluster ou du namespace +- URL de l'endpoint et verbes pris en charge +- Noms alternatifs +- Groupe, version, type + +L'API est disponible sous forme agrégée et non agrégée. La découverte agrégée +propose deux endpoints tandis que la découverte non agrégée propose un +endpoint distinct pour chaque version de groupe. + +### Découverte agrégée + +{{< feature-state feature_gate_name="AggregatedDiscoveryEndpoint" >}} + +Kubernetes propose une prise en charge stable de la _découverte agrégée_, publiant +toutes les ressources prises en charge par un cluster via deux endpoints (`/api` et +`/apis`). En demandant cela, +l'endpoint réduit considérablement le nombre de requêtes envoyées pour récupérer les +données de découverte du cluster. Vous pouvez accéder aux données en +demandant les endpoints respectifs avec un en-tête `Accept` indiquant +la ressource de découverte agrégée : +`Accept: application/json;v=v2;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList`. + +Sans indiquer le type de ressource à l'aide de l'en-tête `Accept`, la réponse par défaut +pour les endpoints `/api` et `/apis` est un document de découverte non agrégé. + +Le [document de découverte](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json) +pour les ressources intégrées peut être trouvé dans le référentiel GitHub de Kubernetes. +Ce document GitHub peut être utilisé comme référence pour l'ensemble de base des ressources disponibles +si un cluster Kubernetes n'est pas disponible pour la requête. + +L'endpoint prend également en charge l'ETag et l'encodage protobuf. + +### Découverte non agrégée + +Sans agrégation de découverte, la découverte est publiée par niveaux, avec les endpoints racine +publiant les informations de découverte pour les documents en aval. + +Une liste de toutes les versions de groupe prises en charge par un cluster est publiée à +les endpoints `/api` et `/apis`. Exemple : + +``` +{ + "kind": "APIGroupList", + "apiVersion": "v1", + "groups": [ + { + "name": "apiregistration.k8s.io", + "versions": [ + { + "groupVersion": "apiregistration.k8s.io/v1", + "version": "v1" + } + ], + "preferredVersion": { + "groupVersion": "apiregistration.k8s.io/v1", + "version": "v1" + } + }, + { + "name": "apps", + "versions": [ + { + "groupVersion": "apps/v1", + "version": "v1" + } + ], + "preferredVersion": { + "groupVersion": "apps/v1", + "version": "v1" + } + }, + ... +} +``` + +Des requêtes supplémentaires sont nécessaires pour obtenir le document de découverte pour chaque version de groupe à +`/apis//` (par exemple : +`/apis/rbac.authorization.k8s.io/v1alpha1`), qui annonce la liste des +ressources servies sous une version de groupe particulière. Ces endpoints sont utilisés par +kubectl pour récupérer la liste des ressources prises en charge par un cluster. + + + + + +## Définition de l'interface OpenAPI + +Pour plus de détails sur les spécifications OpenAPI, consultez la [documentation OpenAPI](https://www.openapis.org/). + +Kubernetes prend en charge à la fois OpenAPI v2.0 et OpenAPI v3.0. OpenAPI v3 est +la méthode préférée pour accéder à l'OpenAPI car elle offre une représentation plus complète +(sans perte) des ressources Kubernetes. En raison des limitations de la version 2 d'OpenAPI, certains champs sont supprimés de l'OpenAPI publié, y compris mais sans s'y limiter `default`, `nullable`, `oneOf`. +### OpenAPI V2 + +Le serveur API Kubernetes sert une spécification OpenAPI v2 agrégée via +l'endpoint `/openapi/v2`. Vous pouvez demander le format de réponse en utilisant +les en-têtes de requête comme suit : + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Valeurs valides des en-têtes de requête pour les requêtes OpenAPI v2
En-têteValeurs possiblesNotes
Accept-Encodinggzipne pas fournir cet en-tête est également acceptable
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufprincipalement pour une utilisation intra-cluster
application/jsonpar défaut
*sert application/json
+ + +### OpenAPI V3 + +{{< feature-state feature_gate_name="OpenAPIV3" >}} + +Kubernetes prend en charge la publication d'une description de ses API en tant qu'OpenAPI v3. + +Un endpoint de découverte `/openapi/v3` est fourni pour voir une liste de tous les +groupes/versions disponibles. Cet endpoint ne renvoie que du JSON. Ces +groupes/versions sont fournis dans le format suivant : + +```yaml +{ + "paths": { + ..., + "api/v1": { + "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF" + }, + "apis/admissionregistration.k8s.io/v1": { + "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597" + }, + .... + } +} +``` + + +Les URLs relatives pointent vers des descriptions OpenAPI immuables, afin +d'améliorer la mise en cache côté client. Les en-têtes de mise en cache HTTP appropriés +sont également définis par le serveur API à cette fin (`Expires` à 1 an dans +le futur, et `Cache-Control` à `immutable`). Lorsqu'une URL obsolète est +utilisée, le serveur API renvoie une redirection vers la nouvelle URL. + +Le serveur API Kubernetes publie une spécification OpenAPI v3 par version de groupe Kubernetes à l'endpoint `/openapi/v3/apis//?hash=`. + +Reportez-vous au tableau ci-dessous pour les en-têtes de requête acceptés. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Valeurs valides des en-têtes de requête pour les requêtes OpenAPI v3
En-têteValeurs possiblesNotes
Accept-Encodinggzipne pas fournir cet en-tête est également acceptable
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobufprincipalement pour une utilisation intra-cluster
application/jsonpar défaut
*sert application/json
+ +Une implémentation en Golang pour récupérer l'OpenAPI V3 est fournie dans le package +[`k8s.io/client-go/openapi3`](https://pkg.go.dev/k8s.io/client-go/openapi3). + +Kubernetes {{< skew currentVersion >}} publie +OpenAPI v2.0 et v3.0 ; il n'y a pas de plans pour prendre en charge la version 3.1 dans un avenir proche. + +### Sérialisation Protobuf + +Kubernetes implémente un format de sérialisation alternatif basé sur Protobuf qui +est principalement destiné à la communication intra-cluster. Pour plus d'informations +sur ce format, consultez la proposition de conception [Kubernetes Protobuf serialization](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) +et les fichiers de langage de définition d'interface (IDL) pour chaque schéma situés dans les packages Go +qui définissent les objets de l'API. + +## Persistance + +Kubernetes stocke l'état sérialisé des objets en les écrivant dans +{{< glossary_tooltip term_id="etcd" >}}. + +## Groupes d'API et versioning + +Pour faciliter l'élimination de champs ou la restructuration des représentations de ressources, +Kubernetes prend en charge plusieurs versions d'API, chacune à un chemin d'API différent, tel que `/api/v1` ou `/apis/rbac.authorization.k8s.io/v1alpha1`. + +Le versioning est effectué au niveau de l'API plutôt qu'au niveau de la ressource ou du champ +pour garantir que l'API présente une vue claire et cohérente des ressources et du comportement du système, et pour permettre de contrôler l'accès aux API en fin de vie et/ou expérimentales. + +Pour faciliter l'évolution et l'extension de son API, Kubernetes implémente +[des groupes d'API](/docs/reference/using-api/#api-groups) qui peuvent être +[activés ou désactivés](/docs/reference/using-api/#enabling-or-disabling). + +Les ressources de l'API sont distinguées par leur groupe d'API, leur type de ressource, leur namepaces +(pour les ressources avec namespace) et leur nom. Le serveur API gère la conversion entre +les versions d'API de manière transparente : toutes les différentes versions sont en réalité des représentations +des mêmes données persistées. Le serveur API peut servir les mêmes données sous plusieurs versions d'API. + +Par exemple, supposons qu'il existe deux versions d'API, `v1` et `v1beta1`, pour la même +ressource. Si vous avez initialement créé un objet en utilisant la version `v1beta1` de son +API, vous pouvez ensuite lire, mettre à jour ou supprimer cet objet en utilisant soit la version `v1beta1` +soit la version `v1` de l'API, jusqu'à ce que la version `v1beta1` soit dépréciée et supprimée. +À ce moment-là, vous pouvez continuer à accéder et à modifier l'objet en utilisant l'API `v1`. + +### Changements d'API + +Tout système qui réussit doit évoluer et changer à mesure que de nouveaux cas d'utilisation émergent ou que les cas d'utilisation existants changent. +Par conséquent, Kubernetes a conçu l'API Kubernetes pour changer et évoluer en permanence. +Le projet Kubernetes vise à _ne pas_ rompre la compatibilité avec les clients existants et à maintenir cette +compatibilité pendant une certaine période afin que d'autres projets aient l'opportunité de s'adapter. + +En général, de nouvelles ressources d'API et de nouveaux champs de ressources peuvent être ajoutés souvent et fréquemment. +L'élimination de ressources ou de champs nécessite de suivre la +[politique de dépréciation de l'API](/docs/reference/using-api/deprecation-policy/). + +Kubernetes s'engage fermement à maintenir la compatibilité avec les API Kubernetes officielles +une fois qu'elles atteignent la disponibilité générale (GA), généralement à la version d'API `v1`. De plus, +Kubernetes maintient la compatibilité avec les données persistées via les versions d'API _beta_ des API Kubernetes officielles, +et garantit que les données peuvent être converties et accessibles via les versions d'API GA lorsque la fonctionnalité devient stable. + +Si vous adoptez une version d'API beta, vous devrez passer à une version d'API beta ou stable ultérieure +une fois que l'API aura été promue. Le meilleur moment pour le faire est pendant la période de dépréciation de l'API beta, +car les objets sont accessibles simultanément via les deux versions d'API. Une fois que l'API beta a terminé sa +The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that +La compatibilité est un élément essentiel dans l'évolution de l'API Kubernetes. De nouvelles ressources et de nouveaux champs peuvent être ajoutés fréquemment, tandis que la suppression de ressources ou de champs nécessite de suivre la politique de dépréciation de l'API. + +{{< note >}} +Bien que Kubernetes vise également à maintenir la compatibilité des versions _alpha_ des API, dans certaines circonstances, cela n'est pas possible. Si vous utilisez des versions d'API alpha, consultez les notes de version de Kubernetes lors de la mise à niveau de votre cluster, au cas où l'API aurait changé de manière incompatible, ce qui nécessite la suppression de tous les objets alpha existants avant la mise à niveau. +{{< /note >}} + +Consultez la [référence des versions d'API](/docs/reference/using-api/#api-versioning) +pour plus de détails sur les définitions de niveau de version d'API. + +## Extension d'API + +L'API Kubernetes peut être étendue de deux manières : + +1. Les [ressources personnalisées](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + vous permettent de définir de manière déclarative comment le serveur API doit fournir votre API de ressource choisie. +1. Vous pouvez également étendre l'API Kubernetes en implémentant une + [couche d'agrégation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). + +## {{% heading "whatsnext" %}} + +- Apprenez comment étendre l'API Kubernetes en ajoutant votre propre + [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). +- [Contrôler l'accès à l'API Kubernetes](/docs/concepts/security/controlling-access/) décrit + comment le cluster gère l'authentification et l'autorisation pour l'accès à l'API. +- Apprenez-en davantage sur les points de terminaison de l'API, les types de ressources et les exemples en lisant + [Référence de l'API](/docs/reference/kubernetes-api/). +- Apprenez ce qui constitue un changement compatible et comment modifier l'API à partir de + [Changements d'API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). + diff --git a/content/fr/docs/concepts/overview/what-is-kubernetes.md b/content/fr/docs/concepts/overview/what-is-kubernetes.md deleted file mode 100644 index 25945b43ab..0000000000 --- a/content/fr/docs/concepts/overview/what-is-kubernetes.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Qu'est-ce-que Kubernetes ? -description: Description de Kubernetes -content_type: concept -weight: 10 -card: - name: concepts - weight: 10 ---- - - -Cette page est une vue d'ensemble de Kubernetes. - - - -Kubernetes est une plate-forme open-source extensible et portable pour la gestion de charges de travail (workloads) et de services conteneurisés. -Elle favorise à la fois l'écriture de configuration déclarative (declarative configuration) et l'automatisation. -C'est un large écosystème en rapide expansion. -Les services, le support et les outils Kubernetes sont largement disponibles. - -Google a rendu open-source le projet Kubernetes en 2014. -Le développement de Kubernetes est basé sur une [décennie et demie d’expérience de Google avec la gestion de la charge et de la mise à l'échelle (scale) en production](https://research.google.com/pubs/pub43438.html), associée aux meilleures idées et pratiques de la communauté. - -## Pourquoi ai-je besoin de Kubernetes et que peut-il faire ? - -Kubernetes a un certain nombre de fonctionnalités. Il peut être considéré comme: - -- une plate-forme de conteneurs -- une plate-forme de microservices -- une plate-forme cloud portable -et beaucoup plus. - -Kubernetes fournit un environnement de gestion **focalisé sur le conteneur** (container-centric). -Il orchestre les ressources machines (computing), la mise en réseau et l’infrastructure de stockage sur les workloads des utilisateurs. -Cela permet de se rapprocher de la simplicité des Platform as a Service (PaaS) avec la flexibilité des solutions d'Infrastructure as a Service (IaaS), tout en gardant de la portabilité entre les différents fournisseurs d'infrastructures (providers). - -## Comment Kubernetes est-il une plate-forme ? - -Même si Kubernetes fournit de nombreuses fonctionnalités, il existe toujours de nouveaux scénarios qui bénéficieraient de fonctionnalités complémentaires. -Ces workflows spécifiques à une application permettent d'accélérer la vitesse de développement. -Si l'orchestration fournie de base est acceptable pour commencer, il est souvent nécessaire d'avoir une automatisation robuste lorsque l'on doit la faire évoluer. -C'est pourquoi Kubernetes a également été conçu pour servir de plate-forme et favoriser la construction d’un écosystème de composants et d’outils facilitant le déploiement, la mise à l’échelle et la gestion des applications. - -[Les Labels](/docs/concepts/overview/working-with-objects/labels/) permettent aux utilisateurs d'organiser leurs ressources comme ils/elles le souhaitent. -[Les Annotations](/docs/concepts/overview/working-with-objects/annotations/) autorisent les utilisateurs à définir des informations personnalisées sur les ressources pour faciliter leurs workflows et fournissent un moyen simple aux outils de gérer la vérification d'un état (checkpoint state). - -De plus, le [plan de contrôle Kubernetes (control -plane)](/docs/concepts/overview/components/) est construit sur les mêmes [APIs](/docs/reference/using-api/api-overview/) que celles accessibles aux développeurs et utilisateurs. -Les utilisateurs peuvent écrire leurs propres contrôleurs (controllers), tels que les [ordonnanceurs (schedulers)](https://github.com/kubernetes/community/blob/master/contributors/devel/scheduler.md), -avec [leurs propres APIs](/docs/concepts/api-extension/custom-resources/) qui peuvent être utilisés par un [outil en ligne de commande](/docs/user-guide/kubectl-overview/). - -Ce choix de [conception](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) a permis de construire un ensemble d'autres systèmes par dessus Kubernetes. - -## Ce que Kubernetes n'est pas - -Kubernetes n’est pas une solution PaaS (Platform as a Service). -Kubernetes opérant au niveau des conteneurs plutôt qu'au niveau du matériel, il fournit une partie des fonctionnalités des offres PaaS, telles que le déploiement, la mise à l'échelle, l'équilibrage de charge (load balancing), la journalisation (logging) et la surveillance (monitoring). -Cependant, Kubernetes n'est pas monolithique. -Ces implémentations par défaut sont optionnelles et interchangeables. Kubernetes fournit les bases permettant de construire des plates-formes orientées développeurs, en laissant la possibilité à l'utilisateur de faire ses propres choix. - -Kubernetes: - -- Ne limite pas les types d'applications supportées. Kubernetes prend en charge des workloads extrêmement diverses, dont des applications stateless, stateful ou orientées traitement de données (data-processing). -Si l'application peut fonctionner dans un conteneur, elle devrait fonctionner correctement sur Kubernetes. -- Ne déploie pas de code source et ne build pas d'application non plus. Les workflows d'Intégration Continue, de Livraison Continue et de Déploiement Continu (CI/CD) sont réalisés en fonction de la culture d'entreprise, des préférences ou des pré-requis techniques. -- Ne fournit pas nativement de services au niveau applicatif tels que des middlewares (e.g., message buses), des frameworks de traitement de données (par exemple, Spark), des bases de données (e.g., mysql), caches, ou systèmes de stockage clusterisés (e.g., Ceph). -Ces composants peuvent être lancés dans Kubernetes et/ou être accessibles à des applications tournant dans Kubernetes via des mécaniques d'intermédiation tel que Open Service Broker. -- N'impose pas de solutions de logging, monitoring, ou alerting. -Kubernetes fournit quelques intégrations primaires et des mécanismes de collecte et export de métriques. -- Ne fournit ou n'impose pas un langage/système de configuration (e.g., [jsonnet](https://github.com/google/jsonnet)). -Il fournit une API déclarative qui peut être ciblée par n'importe quelle forme de spécifications déclaratives. -- Ne fournit ou n'adopte aucune mécanique de configuration des machines, de maintenance, de gestion ou de contrôle de la santé des systèmes. - -De plus, Kubernetes n'est pas vraiment un _système d'orchestration_. En réalité, il élimine le besoin d'orchestration. -Techniquement, l'_orchestration_ se définit par l'exécution d'un workflow spécifié : premièrement faire A, puis B, puis C. -Kubernetes quant à lui est composé d'un ensemble de processus de contrôle qui pilotent l'état courant vers l'état désiré. -Peu importe comment on arrive du point A au point C. -Un contrôle centralisé n'est pas non plus requis. -Cela aboutit à un système plus simple à utiliser et plus puissant, robuste, résiliant et extensible. - -## Pourquoi les conteneurs ? - -Vous cherchez des raisons d'utiliser des conteneurs ? - -![Pourquoi les conteneurs ?](/images/docs/why_containers.svg) - -L'_ancienne façon (old way)_ de déployer des applications consistait à installer les applications sur un hôte en utilisant les systèmes de gestions de paquets natifs. -Cela avait pour principale inconvénient de lier fortement les exécutables, la configuration, les librairies et le cycle de vie de chacun avec l'OS. -Il est bien entendu possible de construire une image de machine virtuelle (VM) immuable pour arriver à produire des publications (rollouts) ou retours arrières (rollbacks), mais les VMs sont lourdes et non-portables. - -La _nouvelle façon (new way)_ consiste à déployer des conteneurs basés sur une virtualisation au niveau du système d'opération (operation-system-level) plutôt que de la virtualisation hardware. -Ces conteneurs sont isolés les uns des autres et de l'hôte : -ils ont leurs propres systèmes de fichiers, ne peuvent voir que leurs propres processus et leur usage des ressources peut être contraint. -Ils sont aussi plus faciles à construire que des VMs, et vu qu'ils sont décorrélés de l'infrastructure sous-jacente et du système de fichiers de l'hôte, ils sont aussi portables entre les différents fournisseurs de Cloud et les OS. - -Étant donné que les conteneurs sont petits et rapides, une application peut être packagée dans chaque image de conteneurs. -Cette relation application-image tout-en-un permet de bénéficier de tous les bénéfices des conteneurs. Avec les conteneurs, des images immuables de conteneurs peuvent être créées au moment du build/release plutôt qu'au déploiement, vu que chaque application ne dépend pas du reste de la stack applicative et n'est pas liée à l'environnement de production. -La génération d'images de conteneurs au moment du build permet d'obtenir un environnement constant qui peut être déployé tant en développement qu'en production. De la même manière, les conteneurs sont bien plus transparents que les VMs, ce qui facilite le monitoring et le management. -Cela est particulièrement vrai lorsque le cycle de vie des conteneurs est géré par l'infrastructure plutôt que caché par un gestionnaire de processus à l'intérieur du conteneur. Avec une application par conteneur, gérer ces conteneurs équivaut à gérer le déploiement de son application. - -Résumé des bénéfices des conteneurs : - -- **Création et déploiement agile d'applications** : - Augmente la simplicité et l'efficacité de la création d'images par rapport à l'utilisation d'images de VM. -- **Développement, intégration et déploiement Continus**: - Fournit un processus pour construire et déployer fréquemment et de façon fiable avec la capacité de faire des rollbacks rapides et simples (grâce à l'immuabilité de l'image). -- **Séparation des besoins entre Dev et Ops**: - Création d'images applicatives au moment du build plutôt qu'au déploiement, tout en séparant l'application de l'infrastructure. -- **Observabilité** - Informations venant non seulement du système d'exploitation sous-jacent mais aussi des signaux propres de l'application. -- **Consistance entre les environnements de développement, tests et production**: - Fonctionne de la même manière que ce soit sur un poste local que chez un fournisseur d'hébergement / dans le Cloud. -- **Portabilité entre Cloud et distribution système**: - Fonctionne sur Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, et n'importe où. -- **Gestion centrée Application**: - Bascule le niveau d'abstraction d'une virtualisation hardware liée à l'OS à une logique de ressources orientée application. -- **[Micro-services](https://martinfowler.com/articles/microservices.html) faiblement couplés, distribués, élastiques**: - Les applications sont séparées en petits morceaux indépendants et peuvent être déployées et gérées dynamiquement -- pas une stack monolithique dans une seule machine à tout faire. -- **Isolation des ressources**: - Performances de l'application prédictibles. -- **Utilisation des ressources**: - Haute efficacité et densité. - -## Qu'est-ce-que Kubernetes signifie ? K8s ? - -Le nom **Kubernetes** tire son origine du grec ancien, signifiant _capitaine_ ou _pilote_ et est la racine de _gouverneur_ et [cybernetic](http://www.etymonline.com/index.php?term=cybernetics). _K8s_ est l'abbréviation dérivée par le remplacement des 8 lettres "ubernete" par "8". - - - -## {{% heading "whatsnext" %}} - -* Prêt à [commencer](/docs/setup/) ? -* Pour plus de détails, voir la [documentation Kubernetes](/docs/home/). - diff --git a/content/fr/docs/concepts/overview/working-with-objects/_index.md b/content/fr/docs/concepts/overview/working-with-objects/_index.md index 097323efc3..8dd99ed1ae 100644 --- a/content/fr/docs/concepts/overview/working-with-objects/_index.md +++ b/content/fr/docs/concepts/overview/working-with-objects/_index.md @@ -1,4 +1,175 @@ --- -title: Utilisation des objets Kubernetes -weight: 40 +title: Objets dans Kubernetes +content_type: concept +weight: 30 +description: > + Les objets Kubernetes sont des entités persistantes dans le système Kubernetes. + Kubernetes utilise ces entités pour représenter l'état de votre cluster. + Apprenez le modèle d'objet Kubernetes et comment travailler avec ces objets. +simple_list: true +card: + name: concepts + weight: 40 --- + + + +Cette page explique comment les objets Kubernetes sont représentés dans l'API Kubernetes et comment vous pouvez +les exprimer au format `.yaml`. + + + +## Comprendre les objets Kubernetes {#kubernetes-objects} + +Les *objets Kubernetes* sont des entités persistantes dans le système Kubernetes. Kubernetes utilise ces +entités pour représenter l'état de votre cluster. Plus précisément, ils peuvent décrire : + +* Les applications conteneurisées en cours d'exécution (et sur quels nœuds) +* Les ressources disponibles pour ces applications +* Les politiques régissant le comportement de ces applications, telles que les politiques de redémarrage, de mise à niveau et de tolérance aux pannes + +Un objet Kubernetes est un "enregistrement d'intention" - une fois que vous avez créé l'objet, le système Kubernetes +travaillera constamment pour s'assurer que l'objet existe. En créant un objet, vous indiquez essentiellement +au système Kubernetes à quoi vous voulez que la charge de travail de votre cluster ressemble ; +c'est *l'état souhaité* de votre cluster. + +Pour travailler avec les objets Kubernetes - que ce soit pour les créer, les modifier ou les supprimer - vous devrez utiliser l' +[API Kubernetes](/fr/docs/concepts/overview/kubernetes-api/). Lorsque vous utilisez l'interface de ligne de commande `kubectl`, par exemple, +l'interface CLI effectue les appels d'API Kubernetes nécessaires pour vous. +Vous pouvez également utiliser l'API Kubernetes directement dans vos propres programmes en utilisant l'une des +[Librairies clientes](/docs/reference/using-api/client-libraries/). + +### Spécification de l'objet et état + +Presque tous les objets Kubernetes incluent deux champs d'objet imbriqués qui régissent +la configuration de l'objet : la *`spec`* de l'objet et le *`status`* de l'objet. +Pour les objets qui ont une `spec`, vous devez la définir lors de la création de l'objet, +en fournissant une description des caractéristiques que vous souhaitez que la ressource ait : +son _état souhaité_. + +Le `status` décrit l'_état actuel_ de l'objet, fourni et mis à jour +par le système Kubernetes et ses composants. Le +{{< glossary_tooltip text="plan de contrôle" term_id="control-plane" >}} Kubernetes +gère continuellement et activement l'état réel de chaque objet pour le faire correspondre à l'état souhaité que vous +avez fourni. + +Par exemple : dans Kubernetes, un Déploiement est un objet qui peut représenter une +application en cours d'exécution sur votre cluster. Lorsque vous créez le Déploiement, vous +pouvez définir la `spec` du Déploiement pour spécifier que vous souhaitez que trois répliques de +l'application soient en cours d'exécution. Le système Kubernetes lit la `spec` du Déploiement +et démarre trois instances de votre application souhaitée - mettant à jour +le statut pour correspondre à votre spécification. Si l'une de ces instances venait à échouer +(un changement d'état), le système Kubernetes réagit à la différence +entre la spécification et le statut en effectuant une correction - dans ce cas, en démarrant +une instance de remplacement. + +Pour plus d'informations sur la spécification de l'objet, l'état et les métadonnées, consultez la +[Convention de l'API Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). + +### Description d'un objet Kubernetes + +Lorsque vous créez un objet dans Kubernetes, vous devez fournir la spécification de l'objet qui décrit son +état souhaité, ainsi que des informations de base sur l'objet (comme un nom). Lorsque vous utilisez +l'API Kubernetes pour créer l'objet (directement ou via `kubectl`), cette requête API doit +inclure ces informations au format JSON dans le corps de la requête. +Le plus souvent, vous fournissez les informations à `kubectl` dans un fichier appelé _manifeste_. +Par convention, les manifestes sont en YAML (vous pouvez également utiliser le format JSON). +Des outils tels que `kubectl` convertissent les informations d'un manifeste en JSON ou dans un autre format de sérialisation +pris en charge lors de l'envoi de la requête API via HTTP. + +Voici un exemple de manifeste montrant les champs requis et la spécification de l'objet pour un +Déploiement Kubernetes : + +{{% code_sample file="application/deployment.yaml" %}} + +Une façon de créer un Déploiement en utilisant un fichier manifeste comme celui ci-dessus est d'utiliser la +commande [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) dans l'interface +de ligne de commande `kubectl`, en passant le fichier `.yaml` en argument. Voici un exemple : + +```shell +kubectl apply -f https://k8s.io/examples/application/deployment.yaml +``` + +La sortie est similaire à ceci : + +``` +deployment.apps/nginx-deployment created +``` + +### Champs requis + +Dans le manifeste (fichier YAML ou JSON) de l'objet Kubernetes que vous souhaitez créer, vous devrez définir des valeurs pour +les champs suivants : + +* `apiVersion` - La version de l'API Kubernetes que vous utilisez pour créer cet objet +* `kind` - Le type d'objet que vous souhaitez créer +* `metadata` - Des données qui aident à identifier de manière unique l'objet, y compris une chaîne `name`, un `UID` et éventuellement un `namespace` facultatif +* `spec` - L'état souhaité de l'objet + +Le format précis de la `spec` de l'objet est différent pour chaque objet Kubernetes et contient +des champs imbriqués spécifiques à cet objet. La [Référence de l'API Kubernetes](/docs/reference/kubernetes-api/) +peut vous aider à trouver le format de spécification pour tous les objets que vous pouvez créer avec Kubernetes. + +Par exemple, consultez le champ [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) +pour la référence de l'API Pod. +Pour chaque Pod, le champ `.spec` spécifie le pod et son état souhaité (comme le nom de l'image du conteneur pour +chaque conteneur dans ce pod). +Un autre exemple de spécification d'objet est le +champ [`spec`](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec) +pour l'API StatefulSet. Pour StatefulSet, le champ `.spec` spécifie le StatefulSet et +son état souhaité. +Dans le `.spec` d'un StatefulSet se trouve un [modèle](/docs/concepts/workloads/pods/#pod-templates) +pour les objets Pod. Ce modèle décrit les Pods que le contrôleur StatefulSet va créer afin de +satisfaire la spécification du StatefulSet. +Différents types d'objets peuvent également avoir différents `.status` ; encore une fois, les pages de référence de l'API +détailent la structure de ce champ `.status` et son contenu pour chaque type d'objet différent. + +{{< note >}} +Consultez les [Meilleures pratiques de configuration](/docs/concepts/configuration/overview/) pour des +informations supplémentaires sur l'écriture de fichiers de configuration YAML. +{{< /note >}} + +## Validation des champs côté serveur + +À partir de Kubernetes v1.25, le serveur API offre une validation des champs côté serveur +[field validation](/docs/reference/using-api/api-concepts/#field-validation) +qui détecte les champs non reconnus ou en double dans un objet. Il offre toutes les fonctionnalités +de `kubectl --validate` côté serveur. + +L'outil `kubectl` utilise le drapeau `--validate` pour définir le niveau de validation des champs. Il accepte les +valeurs `ignore`, `warn` et `strict`, tout en acceptant également les valeurs `true` (équivalent à `strict`) +et `false` (équivalent à `ignore`). Le paramètre de validation par défaut pour `kubectl` est `--validate=true`. + +`Strict` +: Validation stricte des champs, erreurs en cas d'échec de la validation + +`Warn` +: La validation des champs est effectuée, mais les erreurs sont exposées sous forme d'avertissements plutôt que de refuser la requête + +`Ignore` +: Aucune validation des champs côté serveur n'est effectuée + +Lorsque `kubectl` ne peut pas se connecter à un serveur API prenant en charge la validation des champs, il bascule +vers une validation côté client. Les versions de Kubernetes 1.27 et ultérieures offrent toujours une validation des champs ; +les versions antérieures de Kubernetes peuvent ne pas l'offrir. Si votre cluster est plus ancien que v1.27, consultez la documentation +de votre version de Kubernetes. + +## {{% heading "whatsnext" %}} + +Si vous débutez avec Kubernetes, lisez-en plus sur les sujets suivants : + +* [Pods](/docs/concepts/workloads/pods/) qui sont les objets Kubernetes de base les plus importants. +* [Déploiement](/docs/concepts/workloads/controllers/deployment/) d'objets. +* [Contrôleurs](/docs/concepts/architecture/controller/) dans Kubernetes. +* [kubectl](/docs/reference/kubectl/) et [commandes kubectl](/docs/reference/generated/kubectl/kubectl-commands). + +La gestion des objets Kubernetes +explique comment utiliser `kubectl` pour gérer les objets. +Vous devrez peut-être [installer kubectl](/docs/tasks/tools/#kubectl) si vous ne l'avez pas déjà disponible. + +Pour en savoir plus sur l'API Kubernetes en général, visitez : + +* [Vue d'ensemble de l'API Kubernetes](/docs/reference/using-api/) + +Pour approfondir vos connaissances sur les objets dans Kubernetes, lisez d'autres pages de cette section : + diff --git a/content/fr/docs/concepts/overview/working-with-objects/annotations.md b/content/fr/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000..f2f5de0aac --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,78 @@ +--- +title: Annotations +content_type: concept +weight: 60 +--- + + +Vous pouvez utiliser les annotations Kubernetes pour attacher des métadonnées non identifiantes arbitraires aux {{< glossary_tooltip text="objets" term_id="object" >}}. +Les clients tels que les outils et les bibliothèques peuvent récupérer ces métadonnées. + + +## Attacher des métadonnées aux objets + +Vous pouvez utiliser des labels ou des annotations pour attacher des métadonnées aux objets Kubernetes. Les labels peuvent être utilisées pour sélectionner des objets et trouver des collections d'objets qui satisfont certaines conditions. En revanche, les annotations ne sont pas utilisées pour identifier et sélectionner des objets. Les métadonnées dans une annotation peuvent être petites ou grandes, structurées ou non structurées, et peuvent inclure des caractères non autorisés par les labels. Il est possible d'utiliser des labels ainsi que des annotations dans les métadonnées du même objet. + +Les annotations, comme les labels, sont des cartes clé/valeur : + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +{{< note >}} Les clés et les valeurs dans la carte doivent être des chaînes de caractères. En d'autres termes, vous ne pouvez pas utiliser des types numériques, booléens, listes ou autres pour les clés ou les valeurs. {{< /note >}} + +Voici quelques exemples d'informations qui pourraient être enregistrées dans les annotations : + +* Champs gérés par une couche de configuration déclarative. Attacher ces champs en tant qu'annotations les distingue des valeurs par défaut définies par les clients ou les serveurs, et des champs générés automatiquement et des champs définis par des systèmes de dimensionnement ou de mise à l'échelle automatique. + +* Informations de build, de version ou d'image comme les horodatages, les identifiants de version, les branches git, les numéros de PR, les hachages d'image et l'adresse du registre. + +* Pointeurs vers des dépôts de journalisation, de surveillance, d'analyse ou d'audit. + +* Informations sur la bibliothèque cliente ou l'outil qui peuvent être utilisées à des fins de débogage : par exemple, nom, version et informations de build. + +* Informations de provenance de l'utilisateur ou de l'outil/système, telles que les URL d'objets connexes provenant d'autres composants de l'écosystème. + +* Métadonnées d'outil de déploiement léger : par exemple, configuration ou points de contrôle. + +* Numéros de téléphone ou de pager des personnes responsables, ou entrées d'annuaire spécifiant où ces informations peuvent être trouvées, comme un site web d'équipe. + +* Directives de l'utilisateur final aux implémentations pour modifier le comportement ou activer des fonctionnalités non standard. + +Au lieu d'utiliser des annotations, vous pourriez stocker ce type d'informations dans une base de données ou un annuaire externe, mais cela rendrait beaucoup plus difficile la production de bibliothèques clientes et d'outils partagés pour le déploiement, la gestion, l'introspection, etc. + +## Syntaxe et jeu de caractères + +Les _Annotations_ sont des paires clé/valeur. Les clés d'annotation valides ont deux segments : un préfixe optionnel et un nom, séparés par une barre oblique (`/`). Le segment de nom est requis et doit comporter 63 caractères ou moins, commencer et se terminer par un caractère alphanumérique (`[a-z0-9A-Z]`) avec des tirets (`-`), des underscores (`_`), des points (`.`), et des alphanumériques entre. Le préfixe est optionnel. S'il est spécifié, le préfixe doit être un sous-domaine DNS : une série de labels DNS séparées par des points (`.`), ne dépassant pas 253 caractères au total, suivie d'une barre oblique (`/`). + +Si le préfixe est omis, la clé d'annotation est présumée être privée pour l'utilisateur. Les composants système automatisés (par exemple, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubect`l`, ou autre automatisation tierce) qui ajoutent des annotations aux objets des utilisateurs finaux doivent spécifier un préfixe. + +Les préfixes `kubernetes.io/` et `k8s.io/` sont réservés aux composants de base de Kubernetes. + +Par exemple, voici un manifeste pour un Pod qui a l'annotation `imageregistry: https://hub.docker.com/` : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: annotations-demo + annotations: + imageregistry: "https://hub.docker.com/" +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +## {{% heading "whatsnext" %}} + +- En savoir plus sur [Les labels et les sélecteurs](/fr/docs/concepts/overview/working-with-objects/labels/). +- Trouver [Les labels, annotations et taints bien connus](/docs/reference/labels-annotations-taints/) + diff --git a/content/fr/docs/concepts/overview/working-with-objects/common-labels.md b/content/fr/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000..4b1fa2ff42 --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,152 @@ +--- +title: labels recommandées +content_type: concept +weight: 100 +--- + + +Vous pouvez visualiser et gérer les objets Kubernetes avec plus d'outils que kubectl et le tableau de bord. Un ensemble commun de labels permet aux outils de fonctionner de manière interopérable, en décrivant les objets de manière commune que tous les outils peuvent comprendre. + +En plus de prendre en charge les outils, les labels recommandées décrivent les applications de manière à pouvoir être interrogées. + + + +Les métadonnées sont organisées autour du concept d'une _application_. Kubernetes n'est pas une plateforme en tant que service (PaaS) et n'a pas de notion formelle d'une application. Au lieu de cela, les applications sont informelles et décrites avec des métadonnées. La définition de ce qu'une application contient est vague. + +{{< note >}} +Ce sont des labels recommandées. Elles facilitent la gestion des applications mais ne sont pas requises pour les outils principaux. +{{< /note >}} + +Les labels et annotations partagées ont un préfixe commun : `app.kubernetes.io`. Les labels sans préfixe sont privées aux utilisateurs. Le préfixe partagé garantit que les labels partagées n'interfèrent pas avec les labels personnalisées des utilisateurs. + + +## labels + +Afin de tirer pleinement parti de l'utilisation de ces labels, elles doivent être appliquées à chaque objet de ressource. + +| Clé | Description | Exemple | Type | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | Le nom de l'application | `mysql` | string | +| `app.kubernetes.io/instance` | Un nom unique identifiant l'instance d'une application | `mysql-abcxyz` | string | +| `app.kubernetes.io/version` | La version actuelle de l'application (par exemple, un [SemVer 1.0](https://semver.org/spec/v1.0.0.html), un hachage de révision, etc.) | `5.7.21` | string | +| `app.kubernetes.io/component` | Le composant au sein de l'architecture | `database` | string | +| `app.kubernetes.io/part-of` | Le nom d'une application de niveau supérieur dont celle-ci fait partie | `wordpress` | string | +| `app.kubernetes.io/managed-by` | L'outil utilisé pour gérer le fonctionnement d'une application | `Helm` | string | + +Pour illustrer ces labels en action, considérez l'objet {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} suivant : + +```yaml +# Ceci est un extrait +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxyz + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: Helm +``` + +## Applications et instances d'applications + +Une application peut être installée une ou plusieurs fois dans un cluster Kubernetes et, dans certains cas, dans le même namespace. Par exemple, WordPress peut être installé plusieurs fois où différents sites Web sont différentes installations de WordPress. + +Le nom d'une application et le nom de l'instance sont enregistrés séparément. Par exemple, WordPress a un `app.kubernetes.io/name` de `wordpress` tandis qu'il a un nom d'instance, représenté par `app.kubernetes.io/instance` avec une valeur de `wordpress-abcxyz`. Cela permet d'identifier l'application et l'instance de l'application. Chaque instance d'une application doit avoir un nom unique. + +## Exemples + +Pour illustrer les différentes façons d'utiliser ces labels, les exemples suivants ont une complexité variable. + +### Un service simple sans état + +Considérez le cas d'un service simple sans état déployé à l'aide d'objets `Deployment` et `Service`. Les deux extraits suivants représentent comment les labels pourraient être utilisées dans leur forme la plus simple. + +Le `Deployment` est utilisé pour superviser les pods exécutant l'application elle-même. +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxyz +... +``` +Le `Service` est utilisé pour exposer l'application. +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxyz +... +``` +### Application Web avec une base de données + +Considérez une application légèrement plus complexe : une application web (WordPress) utilisant une base de données (MySQL), installée à l'aide de Helm. Les extraits suivants illustrent le début des objets utilisés pour déployer cette application. + +Le début du `Deployment` suivant est utilisé pour WordPress : + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxyz + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` +Le `Service` est utilisé pour exposer WordPress : + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxyz + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +MySQL est exposé en tant que `StatefulSet` avec des métadonnées à la fois pour lui-même et pour l'application plus large à laquelle il appartient : + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxyz + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` +Le `Service` est utilisé pour exposer MySQL en tant que partie de WordPress: + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxyz + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +Avec le `StatefulSet` MySQL et le `Service`, vous remarquerez que des informations sur à la fois MySQL et WordPress, l'application plus large, sont incluses. diff --git a/content/fr/docs/concepts/overview/working-with-objects/field-selectors.md b/content/fr/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000..2dfd2019c7 --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,73 @@ +--- +title: Sélecteurs de champs +content_type: concept +weight: 70 +--- + +Les _sélecteurs de champs_ vous permettent de sélectionner des {{< glossary_tooltip text="objets" term_id="object" >}} Kubernetes en fonction de la valeur d'un ou plusieurs champs de ressources. Voici quelques exemples de requêtes de sélecteurs de champs : + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +Cette commande `kubectl` sélectionne tous les Pods pour lesquels la valeur du champ [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) est `Running` : + +```shell +kubectl get pods --field-selector status.phase=Running +``` + +{{}} +Les sélecteurs de champs sont essentiellement des *filtres* de ressources. Par défaut, aucun sélecteur/filtre n'est appliqué, ce qui signifie que toutes les ressources du type spécifié sont sélectionnées. Cela rend les requêtes `kubectl get pods` et `kubectl get pods --field-selector ""` équivalentes. +{{}} + +## Champs pris en charge + +Les sélecteurs de champs pris en charge varient en fonction du type de ressource Kubernetes. Tous les types de ressources prennent en charge les champs `metadata.name` et `metadata.namespace`. L'utilisation de sélecteurs de champs non pris en charge génère une erreur. Par exemple : + +```shell +kubectl get ingress --field-selector foo.bar=baz +``` +``` +Erreur du serveur (BadRequest) : Impossible de trouver des "ingresses" correspondant au sélecteur de labels "", au sélecteur de champs "foo.bar=baz" : "foo.bar" n'est pas un sélecteur de champ connu : seuls "metadata.name", "metadata.namespace" +``` + +### Liste des champs pris en charge + +| Kind | Champs | +| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Pod | `spec.nodeName`
`spec.restartPolicy`
`spec.schedulerName`
`spec.serviceAccountName`
`spec.hostNetwork`
`status.phase`
`status.podIP`
`status.nominatedNodeName` | +| Event | `involvedObject.kind`
`involvedObject.namespace`
`involvedObject.name`
`involvedObject.uid`
`involvedObject.apiVersion`
`involvedObject.resourceVersion`
`involvedObject.fieldPath`
`reason`
`reportingComponent`
`source`
`type` | +| Secret | `type` | +| Namespace | `status.phase` | +| ReplicaSet | `status.replicas` | +| ReplicationController | `status.replicas` | +| Job | `status.successful` | +| Node | `spec.unschedulable` | +| CertificateSigningRequest | `spec.signerName` | + +## Opérateurs pris en charge + +Vous pouvez utiliser les opérateurs `=`, `==` et `!=` avec les sélecteurs de champs (`=` et `==` signifient la même chose). Cette commande `kubectl`, par exemple, sélectionne tous les services Kubernetes qui ne sont pas dans le namespace `default` : + +```shell +kubectl get services --all-namespaces --field-selector metadata.namespace!=default +``` +{{}} +Les opérateurs basés sur les ensembles (`in`, `notin`, `exists`) ne sont pas pris en charge pour les sélecteurs de champs. +{{}} + +## Sélecteurs enchaînés + +Comme pour les [labels](/fr/docs/concepts/overview/working-with-objects/labels) et autres sélecteurs, les sélecteurs de champs peuvent être enchaînés ensemble sous forme d'une liste séparée par des virgules. Cette commande `kubectl` sélectionne tous les Pods pour lesquels le champ `status.phase` n'est pas égal à `Running` et le champ `spec.restartPolicy` est égal à `Always` : + +```shell +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## Types de ressources multiples + +Vous pouvez utiliser des sélecteurs de champs sur plusieurs types de ressources. Cette commande `kubectl` sélectionne tous les Statefulsets et Services qui ne sont pas dans le namespace `default` : + +```shell +kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default +``` diff --git a/content/fr/docs/concepts/overview/working-with-objects/finalizers.md b/content/fr/docs/concepts/overview/working-with-objects/finalizers.md new file mode 100644 index 0000000000..f83b9dfbb4 --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/finalizers.md @@ -0,0 +1,96 @@ +--- +title: Finalisateurs +content_type: concept +weight: 80 +--- + + + +{{}} + +Vous pouvez utiliser des finalisateurs pour contrôler la {{}} +des {{< glossary_tooltip text="objets" term_id="object" >}} en alertant les {{}} +d'effectuer des tâches de nettoyage spécifiques avant de supprimer la ressource cible. + +Les finalisateurs ne spécifient généralement pas le code à exécuter. Au lieu de cela, ils sont +généralement des listes de clés sur une ressource spécifique similaires aux annotations. +Kubernetes spécifie automatiquement certains finalisateurs, mais vous pouvez également spécifier +les vôtres. + +## Comment fonctionnent les finalisateurs + +Lorsque vous créez une ressource à l'aide d'un fichier de manifeste, vous pouvez spécifier des finalisateurs dans +le champ `metadata.finalizers`. Lorsque vous tentez de supprimer la ressource, le +serveur API traitant la demande de suppression remarque les valeurs dans le champ `finalizers` +et effectue les opérations suivantes : + + * Modifie l'objet pour ajouter un champ `metadata.deletionTimestamp` avec l'heure de début de la suppression. + * Empêche la suppression de l'objet tant que tous les éléments sont supprimés de son champ `metadata.finalizers` + * Renvoie un code d'état `202` (HTTP "Accepté") + +Le contrôleur gérant ce finaliseur remarque la mise à jour de l'objet en définissant le +`metadata.deletionTimestamp`, indiquant que la suppression de l'objet a été demandée. +Le contrôleur tente ensuite de satisfaire les exigences des finalisateurs +spécifiés pour cette ressource. Chaque fois qu'une condition de finaliseur est satisfaite, le +contrôleur supprime cette clé du champ `finalizers` de la ressource. Lorsque le +champ `finalizers` est vidé, un objet avec un champ `deletionTimestamp` défini +est automatiquement supprimé. Vous pouvez également utiliser des finalisateurs pour empêcher la suppression de ressources non gérées. + +Un exemple courant de finaliseur est `kubernetes.io/pv-protection`, qui empêche +la suppression accidentelle des objets `PersistentVolume`. Lorsqu'un objet `PersistentVolume` +est utilisé par un Pod, Kubernetes ajoute le finaliseur `pv-protection`. Si vous +essayez de supprimer le `PersistentVolume`, il passe à l'état `Terminating`, mais le +contrôleur ne peut pas le supprimer car le finaliseur existe. Lorsque le Pod cesse +d'utiliser le `PersistentVolume`, Kubernetes supprime le finaliseur `pv-protection`, +et le contrôleur supprime le volume. + +{{< note >}} +* Lorsque vous `DELETE` un objet, Kubernetes ajoute le timestamp de suppression pour cet objet, puis +commence immédiatement à restreindre les modifications du champ `.metadata.finalizers` pour l'objet qui est +maintenant en attente de suppression. Vous pouvez supprimer les finalisateurs existants (supprimer une entrée de la liste des `finalizers`) +mais vous ne pouvez pas ajouter un nouveau finaliseur. Vous ne pouvez pas non plus modifier le `deletionTimestamp` d'un +objet une fois qu'il est défini. + +* Après que la suppression a été demandée, vous ne pouvez pas ressusciter cet objet. La seule solution est de le supprimer et de créer un nouvel objet similaire. +{{< /note >}} + +## Références de propriétaire, labels et finalisateurs {#owners-labels-finalizers} + +Comme les {{}}, +[les références de propriétaire](/docs/concepts/overview/working-with-objects/owners-dependents/) +décrivent les relations entre les objets dans Kubernetes, mais sont utilisées à +une fin différente. Lorsqu'un +{{}} gère des objets +comme des Pods, il utilise des labels pour suivre les modifications apportées à des groupes d'objets liés. Par +exemple, lorsqu'un {{}} crée un ou +plusieurs Pods, le contrôleur de Job applique des labels à ces pods et suit les modifications apportées à +tous les Pods du cluster ayant le même label. + +Le contrôleur de Job ajoute également des *références de propriétaire* à ces Pods, pointant vers le +Job qui a créé les Pods. Si vous supprimez le Job pendant que ces Pods sont en cours d'exécution, +Kubernetes utilise les références de propriétaire (pas les labels) pour déterminer quels Pods dans le +cluster ont besoin d'un nettoyage. + +Kubernetes traite également les finalisateurs lorsqu'il identifie des références de propriétaire sur une +ressource destinée à la suppression. + +Dans certaines situations, les finalisateurs peuvent bloquer la suppression d'objets dépendants, +ce qui peut entraîner le maintien de l'objet propriétaire ciblé pendant +plus longtemps que prévu sans être entièrement supprimé. Dans ces situations, vous +devriez vérifier les finalisateurs et les références de propriétaire sur l'objet propriétaire cible et les objets dépendants +pour résoudre le problème. + +{{< note >}} +Dans les cas où les objets restent bloqués dans un état de suppression, évitez de supprimer manuellement +les finalisateurs pour permettre la poursuite de la suppression. Les finalisateurs sont généralement ajoutés +aux ressources pour une raison, donc les supprimer de force peut entraîner des problèmes dans +votre cluster. Cela ne doit être fait que lorsque le but du finaliseur est +compris et est accompli d'une autre manière (par exemple, nettoyage manuel +de certains objets dépendants). +{{< /note >}} + +## {{% heading "whatsnext" %}} + +* Lisez [Utilisation des finalisateurs pour contrôler la suppression](/blog/2021/05/14/using-finalizers-to-control-deletion/) + sur le blog Kubernetes. + diff --git a/content/fr/docs/concepts/overview/working-with-objects/labels.md b/content/fr/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..9d1c0da733 --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,346 @@ +--- +title: Labels et sélecteurs +content_type: concept +weight: 40 +--- + + + +Les _labels_ sont des paires clé/valeur qui sont attachées aux +{{< glossary_tooltip text="objets" term_id="object" >}} tels que les Pods. +Les labels sont destinées à être utilisées pour spécifier des attributs d'identification des objets +qui sont significatifs et pertinents pour les utilisateurs, mais n'impliquent pas directement de sémantique +au système principal. Les labels peuvent être utilisées pour organiser et sélectionner des sous-ensembles d'objets. +Les labels peuvent être attachées aux objets lors de leur création et ultérieurement +ajoutées et modifiées à tout moment. Chaque objet peut avoir un ensemble de labels clé/valeur +définies. Chaque clé doit être unique pour un objet donné. + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +Les labels permettent des requêtes et des surveillances efficaces et sont idéaux pour une utilisation dans les interfaces utilisateur (UI) et les interfaces en ligne de commande (CLI). Les informations non identifiantes doivent être enregistrées à l'aide des [annotations](/fr/docs/concepts/overview/working-with-objects/annotations/). + + + +## Motivation + +Les labels permettent aux utilisateurs de mapper leurs propres structures organisationnelles sur les objets système de manière lâchement couplée, sans nécessiter aux clients de stocker ces mappings. + +Les déploiements de services et les pipelines de traitement par lots sont souvent des entités multidimensionnelles (par exemple, plusieurs partitions ou déploiements, plusieurs pistes de version, plusieurs niveaux, plusieurs micro-services par niveau). La gestion nécessite souvent des opérations transversales, ce qui rompt l'encapsulation des représentations strictement hiérarchiques, en particulier les hiérarchies rigides déterminées par l'infrastructure plutôt que par les utilisateurs. + +Exemples de labels : + +* `"release" : "stable"`, `"release" : "canary"` +* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` +* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` +* `"partition" : "customerA"`, `"partition" : "customerB"` +* `"track" : "daily"`, `"track" : "weekly"` + +Voici des exemples de _label_ couramment utilisées; vous êtes libre de développer vos propres conventions. Gardez à l'esprit que la clé du _label_ doit être unique pour un objet donné. + +## Syntaxe et jeu de caractères + +Les labels sont des paires clé/valeur. Les clés de label valides ont deux segments : un préfixe facultatif et un nom, séparés par une barre oblique (`/`). Le segment du nom est requis et ne doit pas dépasser 63 caractères, en commençant et en terminant par un caractère alphanumérique (`[a-z0-9A-Z]`) avec des tirets (`-`), des traits de soulignement (`_`), des points (`.`) et des caractères alphanumériques entre eux. Le préfixe est facultatif. S'il est spécifié, le préfixe doit être un sous-domaine DNS : une série de labels DNS séparées par des points (`.`), ne dépassant pas 253 caractères au total, suivi d'une barre oblique (`/`). + +Si le préfixe est omis, la clé du label est considérée comme privée pour l'utilisateur. Les composants système automatisés (par exemple, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` ou d'autres automatisations tierces) qui ajoutent des labels aux objets des utilisateurs finaux doivent spécifier un préfixe. + +Les préfixes `kubernetes.io/` et `k8s.io/` sont réservés pour les composants principaux de Kubernetes. + +Valeur de label valide : + +* doit comporter 63 caractères ou moins (peut être vide), +* sauf s'il est vide, doit commencer et se terminer par un caractère alphanumérique (`[a-z0-9A-Z]`), +* peut contenir des tirets (`-`), des traits de soulignement (`_`), des points (`.`) et des caractères alphanumériques entre eux. + +Par exemple, voici un manifeste pour un Pod qui a deux labels `environment: production` et `app: nginx` : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +## Sélecteurs de labels + +Contrairement aux [noms et UIDs](/fr/docs/concepts/overview/working-with-objects/names/), les labels ne garantissent pas l'unicité. En général, nous nous attendons à ce que de nombreux objets portent les mêmes label(s). + +Via un _sélecteur de label_, le client/utilisateur peut identifier un ensemble d'objets. +Le sélecteur de label est le principe de regroupement central dans Kubernetes. + +L'API prend actuellement en charge deux types de sélecteurs : _basés sur l'égalité_ et _basés sur un ensemble_. +Un sélecteur de label peut être composé de plusieurs _exigences_ séparées par des virgules. +Dans le cas de plusieurs exigences, toutes doivent être satisfaites, donc le séparateur de virgule +agit comme un opérateur logique _ET_ (`&&`). + +La signification des sélecteurs vides ou non spécifiés dépend du contexte, +et les types d'API qui utilisent des sélecteurs doivent documenter leur validité et leur signification. + +{{< note >}} +Pour certains types d'API, tels que les ReplicaSets, les sélecteurs de labels de deux instances ne doivent pas se chevaucher dans un namespace, sinon le contrôleur peut considérer cela comme des instructions contradictoires et échouer à déterminer combien de répliques doivent être présentes. +{{< /note >}} + +{{< caution >}} +Pour les conditions basées sur l'égalité et les conditions basées sur un ensemble, il n'y a pas d'opérateur logique _OU_ (`||`). +Assurez-vous que vos déclarations de filtre sont structurées en conséquence. +{{< /caution >}} +### Exigence basée sur l'égalité + +Les exigences basées sur l'égalité ou l'inégalité permettent de filtrer par clés et valeurs de label. +Les objets correspondants doivent satisfaire toutes les contraintes de label spécifiées, bien qu'ils puissent également avoir des labels supplémentaires. Trois types d'opérateurs sont admis : `=`, `==`, `!=`. +Les deux premiers représentent l'égalité (et sont synonymes), tandis que le dernier représente l'inégalité. +Par exemple : + +``` +environment = production +tier != frontend +``` +Le premier sélectionne toutes les ressources avec une clé égale à `environment` et une valeur égale à `production`. +Le second sélectionne toutes les ressources avec une clé égale à `tier` et une valeur différente de `frontend`, +ainsi que toutes les ressources sans labels avec la clé `tier`. On peut filtrer les ressources en `production` +en excluant `frontend` en utilisant l'opérateur virgule : `environment=production,tier!=frontend` + +Un scénario d'utilisation pour une exigence de label basée sur l'égalité est de spécifier des critères de sélection de nœud pour les Pods. Par exemple, le Pod d'exemple ci-dessous sélectionne les nœuds où le label "accelerator" existe et est définie sur "nvidia-tesla-p100". + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "registry.k8s.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` +### Exigence basée sur un ensemble + +Les exigences basées sur un ensemble permettent de filtrer les clés en fonction d'un ensemble de valeurs. +Trois types d'opérateurs sont pris en charge : `in`, `notin` et `exists` (uniquement l'identifiant de clé). +Par exemple : + +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +- Le premier exemple sélectionne toutes les ressources avec une clé égale à `environment` et une valeur égale à `production` ou `qa`. +- Le deuxième exemple sélectionne toutes les ressources avec une clé égale à `tier` et des valeurs autres que `frontend` et `backend`, ainsi que toutes les ressources sans labels avec la clé `tier`. +- Le troisième exemple sélectionne toutes les ressources incluant un label avec la clé `partition`; aucune valeur n'est vérifiée. +- Le quatrième exemple sélectionne toutes les ressources sans un label avec la clé `partition`; aucune valeur n'est vérifiée. + +De même, le séparateur virgule agit comme un opérateur _ET_. Ainsi, pour filtrer les ressources avec une clé `partition` (peu importe la valeur) et avec `environment` différent de `qa`, vous pouvez utiliser `partition,environment notin (qa)`. Le sélecteur de label basé sur un ensemble est une forme générale d'égalité, car `environment=production` est équivalent à `environment in (production)`; de même pour `!=` et `notin`. + +Les exigences basées sur un ensemble peuvent être mélangées avec des exigences basées sur l'égalité. Par exemple: `partition in (customerA, customerB),environment!=qa`. + + +## API + +### Filtrage LIST et WATCH + +Pour les opérations **list** et **watch**, vous pouvez spécifier des sélecteurs de labels pour filtrer les ensembles d'objets retournés ; vous spécifiez le filtre à l'aide d'un paramètre de requête. +(Pour en savoir plus en détail sur les watches dans Kubernetes, lisez [détection efficace des changements](/fr/docs/reference/using-api/api-concepts/#efficient-detection-of-changes)). +Les deux types d'exigences sont autorisés +(présentés ici tels qu'ils apparaîtraient dans une chaîne de requête d'URL) : + +* exigences basées sur l'égalité : `?labelSelector=environment%3Dproduction,tier%3Dfrontend` +* exigences basées sur un ensemble : `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +Les deux styles de sélecteurs de labels peuvent être utilisés pour lister ou surveiller des ressources via un client REST. +Par exemple, en ciblant `apiserver` avec `kubectl` et en utilisant une exigence basée sur l'égalité, on peut écrire : + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +ou en utilisant des exigences basées sur un ensemble : + +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +Comme déjà mentionné, les exigences basées sur un ensemble sont plus expressives. +Par exemple, elles peuvent implémenter l'opérateur _OU_ sur les valeurs : + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +ou restreindre la correspondance négative via l'opérateur _notin_ : + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` +### Définir des références dans les objets API + +Certains objets Kubernetes, tels que les [`services`](/fr/docs/concepts/services-networking/service/) et les [`replicationcontrollers`](/fr/docs/concepts/workloads/controllers/replicationcontroller/), utilisent également des sélecteurs de labels pour spécifier des ensembles d'autres ressources, telles que les [pods](/fr/docs/concepts/workloads/pods/). + +#### Service et ReplicationController + +L'ensemble des pods ciblés par un `service` est défini avec un sélecteur de labels. +De même, la population de pods qu'un `replicationcontroller` doit gérer est également définie avec un sélecteur de labels. + +Les sélecteurs de labels pour ces deux objets sont définis dans des fichiers `json` ou `yaml` en utilisant des maps, +et seules les exigences basées sur l'égalité sont prises en charge : + +```json +"selector": { + "component" : "redis", +} +``` + +ou + +```yaml +selector: + component: redis +``` + +Ce sélecteur (respectivement au format `json` ou `yaml`) est équivalent à `component=redis` ou `component in (redis)`. + +#### Ressources prenant en charge les exigences basées sur un ensemble + +Les nouvelles ressources, telles que [`Job`](/fr/docs/concepts/workloads/controllers/job/), +[`Deployment`](/fr/docs/concepts/workloads/controllers/deployment/), +[`ReplicaSet`](/fr/docs/concepts/workloads/controllers/replicaset/) et +[`DaemonSet`](/fr/docs/concepts/workloads/controllers/daemonset/), +prennent également en charge les exigences basées sur un ensemble. + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - { key: tier, operator: In, values: [cache] } + - { key: environment, operator: NotIn, values: [dev] } +``` + +`matchLabels` est une carte de paires `{clé, valeur}`. Une seule paire `{clé, valeur}` dans la carte `matchLabels` est équivalente à un élément de `matchExpressions`, dont le champ `key` est "clé", l'opérateur est "In" et le tableau `values` contient uniquement "valeur". `matchExpressions` est une liste d'exigences de sélecteur de pod. Les opérateurs valides incluent In, NotIn, Exists et DoesNotExist. Les ensembles de valeurs doivent être non vides dans le cas de In et NotIn. Toutes les exigences, à la fois de `matchLabels` et de `matchExpressions`, sont combinées avec un ET -- elles doivent toutes être satisfaites pour correspondre. + + +#### Sélection de jeux de nœuds + +Un cas d'utilisation pour la sélection basée sur les labels est de restreindre l'ensemble des nœuds sur lesquels un pod peut être planifié. Consultez la documentation sur la [sélection de nœuds](/fr/docs/concepts/scheduling-eviction/assign-pod-node/) pour plus d'informations. + +## Utilisation efficace des labels + +Vous pouvez appliquer un seul label à n'importe quelle ressource, mais ce n'est pas toujours la meilleure pratique. Il existe de nombreux scénarios où plusieurs labels doivent être utilisés pour distinguer des ensembles de ressources les uns des autres. + +Par exemple, différentes applications utiliseraient des valeurs différentes pour le label `app`, mais une application multi-niveaux, telle que l'exemple [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/), aurait également besoin de distinguer chaque niveau. Le frontend pourrait avoir les labels suivants: + +```yaml +labels: + app: guestbook + tier: frontend +``` + +while the Redis master and replica would have different `tier` labels, and perhaps even an +additional `role` label: + +```yaml +labels: + app: guestbook + tier: backend + role: master +``` + +and + +```yaml +labels: + app: guestbook + tier: backend + role: replica +``` +Les labels permettent de découper les ressources selon n'importe quelle dimension spécifiée par un label : + +```shell +kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml +kubectl get pods -Lapp -Ltier -Lrole +``` + +```none +NAME READY STATUS RESTARTS AGE APP TIER ROLE +guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend +guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend +guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend +guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master +guestbook-redis-replica-2q2yf 1/1 Running 0 1m guestbook backend replica +guestbook-redis-replica-qgazl 1/1 Running 0 1m guestbook backend replica +my-nginx-divi2 1/1 Running 0 29m nginx +my-nginx-o0ef1 1/1 Running 0 29m nginx +``` + +```shell +kubectl get pods -lapp=guestbook,role=replica +``` + +```none +NAME READY STATUS RESTARTS AGE +guestbook-redis-replica-2q2yf 1/1 Running 0 3m +guestbook-redis-replica-qgazl 1/1 Running 0 3m +``` + +## Mise à jour des labels + +Parfois, vous souhaiterez renommer les pods existants et d'autres ressources avant de créer de nouvelles ressources. Cela peut être fait avec `kubectl label`. +Par exemple, si vous souhaitez étiqueter tous vos pods NGINX en tant que niveau frontend, exécutez : + +```shell +kubectl label pods -l app=nginx tier=fe +``` + +```none +pod/my-nginx-2035384211-j5fhi labeled +pod/my-nginx-2035384211-u2c7e labeled +pod/my-nginx-2035384211-u3t6x labeled +``` + +Ce premier filtre tous les pods avec le label "app=nginx", puis les labels avec "tier=fe". +Pour voir les pods que vous avez étiquetés, exécutez : + +```shell +kubectl get pods -l app=nginx -L tier +``` + +```none +NAME READY STATUS RESTARTS AGE TIER +my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe +my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe +my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe +``` + +Cela affiche tous les pods "app=nginx", avec une colonne de label supplémentaire pour le niveau des pods (spécifié avec `-L` ou `--label-columns`). + +Pour plus d'informations, veuillez consulter [kubectl label](/fr/docs/reference/generated/kubectl/kubectl-commands/#label). + + +## {{% heading "whatsnext" %}} + +- Apprenez comment [ajouter un label à un nœud](/fr/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) +- Trouvez des informations sur les [labels, annotations et taints bien connus](/fr/docs/reference/labels-annotations-taints/) +- Consultez les [labels recommandés](/fr/docs/concepts/overview/working-with-objects/common-labels/) +- [Appliquez les normes de sécurité des pods avec des labels de namespace](/fr/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) +- Lisez un blog sur [l'écriture d'un contrôleur pour les labels de pod](/fr/blog/2021/06/21/writing-a-controller-for-pod-labels/) + diff --git a/content/fr/docs/concepts/overview/working-with-objects/names.md b/content/fr/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000..1d8cb8533b --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,109 @@ +--- +title: Noms et identifiants d'objets +content_type: concept +weight: 30 +--- + + + +Chaque {{< glossary_tooltip text="objet" term_id="object" >}} dans votre cluster a un [_Nom_](#names) qui est unique pour ce type de ressource. +Chaque objet Kubernetes a également un [_UID_](#uids) qui est unique dans l'ensemble de votre cluster. + +Par exemple, vous ne pouvez avoir qu'un seul Pod nommé `myapp-1234` dans le même [namespace](/fr/docs/concepts/overview/working-with-objects/namespaces/), mais vous pouvez avoir un Pod et un Déploiement qui sont chacun nommés `myapp-1234`. + +Pour les attributs fournis par l'utilisateur qui ne sont pas uniques, Kubernetes fournit des [labels](/fr/docs/concepts/overview/working-with-objects/labels/) et des [annotations](/fr/docs/concepts/overview/working-with-objects/annotations/). + + + +## Noms + +{{< glossary_definition term_id="name" length="all" >}} + +**Les noms doivent être uniques pour toutes les [versions d'API](/fr/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) +de la même ressource. Les ressources API sont distinguées par leur groupe API, leur type de ressource, leur label +(pour les ressources avec label) et leur nom. En d'autres termes, la version de l'API est sans importance dans ce contexte.** + +{{}} +Dans les cas où les objets représentent une entité physique, comme un Noeud représentant un hôte physique, lorsque l'hôte est recréé sous le même nom sans supprimer et recréer le Noeud, Kubernetes considère le nouvel hôte comme l'ancien, ce qui peut entraîner des incohérences. +{{}} + +Voici quatre types de contraintes de nom couramment utilisées pour les ressources. + +### Noms de sous-domaine DNS + +La plupart des types de ressources nécessitent un nom qui peut être utilisé comme un sous-domaine DNS +tel que défini dans [RFC 1123](https://tools.ietf.org/html/rfc1123). +Cela signifie que le nom doit : + +- ne pas contenir plus de 253 caractères +- contenir uniquement des caractères alphanumériques minuscules, '-' ou '.' +- commencer par un caractère alphanumérique +- se terminer par un caractère alphanumérique + +### Noms de label RFC 1123 {#dns-label-names} + +Certains types de ressources nécessitent que leurs noms suivent la norme des labels DNS +telle que définie dans [RFC 1123](https://tools.ietf.org/html/rfc1123). +Cela signifie que le nom doit : + +- contenir au maximum 63 caractères +- contenir uniquement des caractères alphanumériques minuscules ou '-' +- commencer par un caractère alphanumérique +- se terminer par un caractère alphanumérique + +### Noms de label RFC 1035 + +Certains types de ressources nécessitent que leurs noms suivent la norme des labels DNS +telle que définie dans [RFC 1035](https://tools.ietf.org/html/rfc1035). +Cela signifie que le nom doit : + +- contenir au maximum 63 caractères +- contenir uniquement des caractères alphanumériques minuscules ou '-' +- commencer par un caractère alphabétique +- se terminer par un caractère alphanumérique + +{{}} +La seule différence entre les normes des labels RFC 1035 et RFC 1123 +est que les labels RFC 1123 sont autorisées à +commencer par un chiffre, tandis que les labels RFC 1035 ne peuvent commencer +qu'avec une lettre alphabétique minuscule. +{{}} + +### Noms de segment de chemin + +Certains types de ressources nécessitent que leurs noms puissent être encodés en toute sécurité en tant que +segment de chemin. En d'autres termes, le nom ne peut pas être "." ou ".." et le nom ne peut +pas contenir "/" ou "%". + +Voici un exemple de manifeste pour un Pod nommé `nginx-demo`. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx-demo +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +{{}} +Certains types de ressources ont des restrictions supplémentaires sur leurs noms. +{{}} + +## UIDs + +{{< glossary_definition term_id="uid" length="all" >}} + +Les UIDs Kubernetes sont des identifiants universellement uniques (également connus sous le nom d'UUID). +Les UUID sont normalisés selon ISO/IEC 9834-8 et ITU-T X.667. + + +## {{% heading "whatsnext" %}} + +* Lisez à propos des [labels](/fr/docs/concepts/overview/working-with-objects/labels/) et des [annotations](/fr/docs/concepts/overview/working-with-objects/annotations/) dans Kubernetes. +* Consultez le document de conception [Identifiers and Names in Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md). + diff --git a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md index 87aae45e7a..4381984491 100644 --- a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md @@ -1,44 +1,60 @@ --- title: Namespaces +api_metadata: +- apiVersion: "v1" + kind: "Namespace" content_type: concept -weight: 30 +weight: 45 --- -Kubernetes prend en charge plusieurs clusters virtuels présents sur le même cluster physique. -Ces clusters virtuels sont appelés namespaces (espaces de nommage en français). +Dans Kubernetes, les _namespaces_ (espace de nommage en français) fournissent un mécanisme pour isoler des groupes de ressources au sein d'un seul cluster. Les noms des ressources doivent être uniques dans un namespace, mais pas à travers les namespaces. La portée basée sur les namespaces s'applique uniquement aux {{< glossary_tooltip text="objets" term_id="object" >}} dans les namespaces _(par exemple, les déploiements, les services, etc.)_ et non aux objets à l'échelle du cluster _(par exemple, StorageClass, Nodes, PersistentVolumes, etc.)_. ## Quand utiliser plusieurs namespaces -Les namespaces sont destinés à être utilisés dans les environnements ayant de nombreux utilisateurs répartis en plusieurs équipes ou projets. Pour les clusters de quelques dizaines d'utilisateurs, vous n'avez pas -besoin d'utiliser de namespaces. Commencez à utiliser des namespaces lorsque vous avez -besoin des fonctionnalités qu'ils fournissent. +Les _Namespaces_ sont destinés à être utilisés dans des environnements avec de nombreux utilisateurs répartis sur plusieurs équipes ou projets. Pour les clusters avec quelques dizaines d'utilisateurs, vous n'avez pas besoin de créer ou de penser aux namespaces. Commencez à utiliser les namespaces lorsque vous avez besoin des fonctionnalités qu'ils offrent. -Les namespaces sont des groupes de noms. Ils fournissent un modèle d'isolation de nommage des ressources. Les noms des ressources doivent être uniques dans un namespace, -mais pas dans l'ensemble des namespaces. Les namespaces ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut se trouver que dans un seul namespace. +Les namespaces fournissent une portée pour les noms. Les noms des ressources doivent être uniques dans un namespace, mais pas à travers les namespaces. Les namespaces ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut être présente que dans un seul namespace. -Les namespaces sont un moyen de répartir les ressources d'un cluster entre plusieurs utilisateurs (via [quota de ressources](/docs/concepts/policy/resource-quotas/)). +Les namespaces sont un moyen de diviser les ressources du cluster entre plusieurs utilisateurs (via des [quotas de ressources](/docs/concepts/policy/resource-quotas/)). -Dans les futures versions de Kubernetes, les objets du même namespace auront les mêmes -stratégies de contrôle d'accès par défaut. - -Il n'est pas nécessaire d'utiliser plusieurs namespaces juste pour séparer des ressources légèrement différentes, telles que les versions du même logiciel: utiliser les [labels](/docs/user-guide/labels) pour distinguer les -ressources dans le même namespace. - -## Utilisation des namespaces - -La création et la suppression des namespaces sont décrites dans la [Documentation du guide d'administration pour les namespaces](/docs/admin/namespaces). +Il n'est pas nécessaire d'utiliser plusieurs namespaces pour séparer légèrement différentes ressources, telles que différentes versions du même logiciel : utilisez des {{< glossary_tooltip text="labels" term_id="label" >}} pour distinguer les ressources dans le même namespace. {{< note >}} -Évitez de créer des namespaces avec le préfixe `kube-`, car il est réservé aux namespaces système de Kubernetes. +Pour un cluster de production, envisagez de ne pas utiliser le namespace `default`. Au lieu de cela, créez d'autres namespaces et utilisez-les. +{{< /note >}} + +## namespaces initiaux + +Kubernetes démarre avec quatre namespaces initiaux : + +`default` +: Kubernetes inclut ce namespace afin que vous puissiez commencer à utiliser votre nouveau cluster sans avoir à créer d'namespace. + +`kube-node-lease` +: ce namespace contient des objets [Lease](/docs/concepts/architecture/leases/) associés à chaque nœud. Les leases de nœud permettent au kubelet d'envoyer des [contrôles](/docs/concepts/architecture/nodes/#node-heartbeats) afin que le plan de contrôle puisse détecter une défaillance du nœud. + +`kube-public` +: ce namespace est lisible par *tous* les clients (y compris ceux qui ne sont pas authentifiés). ce namespace est principalement réservé à l'utilisation du cluster, au cas où certaines ressources devraient être visibles et lisibles publiquement dans l'ensemble du cluster. L'aspect public de ce namespace est seulement une convention, pas une exigence. + +`kube-system` +: Le namespace pour les objets créés par le système Kubernetes. + + +## Travailler avec les namespaces + +La création et la suppression des namespaces sont décrites dans la documentation du guide d'administration pour les namespaces. + +{{< note >}} + Évitez de créer des namespaces avec le préfixe `kube-`, car il est réservé aux namespaces système de Kubernetes. {{< /note >}} ### Affichage des namespaces -Dans un cluster vous pouvez lister les namespaces actuels à l'aide de : +Vous pouvez lister les namespaces actuels dans un cluster en utilisant : ```shell kubectl get namespace @@ -52,50 +68,58 @@ kube-public Active 1d kube-system Active 1d ``` -Kubernetes démarre avec quatre namespaces initiaux: +### Définir le namespace pour une requête -- `default` Le namespace par défaut pour les objets sans mention d'autre namespace -- `kube-system` Le namespace pour les objets créés par Kubernetes lui-même -- `kube-public` Ce namespace est créé automatiquement et est visible par tous les utilisateurs (y compris ceux qui ne sont pas authentifiés). Ce namespace est principalement réservé à l'utilisation du cluster, au cas où certaines ressources devraient être disponibles publiquement dans l'ensemble du cluster. L'aspect public de ce namespace n'est qu'une convention, pas une exigence. -- `kube-node-lease` Ce namespace contient les objets de bail associés à chaque nœud, ce qui améliore les performances des pulsations du nœud à mesure que le cluster évolue. +Pour définir le namespace pour une requête en cours, utilisez le drapeau `--namespace`. -### Définition du namespaces pour une requête - -Pour définir le namespace pour une requête en cours, utilisez l'indicateur `--namespace`. - -Par exemple: +Par exemple : ```shell -kubectl run nginx --image=nginx --namespace= -kubectl get pods --namespace= +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= ``` +### Définir la préférence de namespace -### Spécifier un namespace - -Vous pouvez enregistrer de manière permanente le namespace à utiliser pour toutes les commandes kubectl à suivre. +Vous pouvez enregistrer de manière permanente le namespace pour toutes les commandes kubectl ultérieures dans ce contexte. ```shell -kubectl config set-context --current --namespace= +kubectl config set-context --current --namespace= # Validez-le kubectl config view --minify | grep namespace: ``` ## Namespaces et DNS -Lorsque vous créez un [Service](/fr/docs/concepts/services-networking/service/), il crée une [entrée DNS](/fr/docs/concepts/services-networking/dns-pod-service/) correspondante. -Cette entrée est de la forme `..svc.cluster.local`, ce qui signifie -que si un conteneur utilise simplement ``, il résoudra le service qui -est local à son namespace. Ceci est utile pour utiliser la même configuration pour -plusieurs namespaces tels que le Développement, la Qualification et la Production. Si vous voulez naviguer -entre plusieurs namespaces, vous devez utiliser le nom de domaine complet (FQDN ou nom de domaine complètement qualifié en français). +Lorsque vous créez un [Service](/fr/docs/concepts/services-networking/service/), +cela crée une [entrée DNS correspondante](/docs/concepts/services-networking/dns-pod-service/). +Cette entrée est de la forme `..svc.cluster.local`, ce qui signifie +que si un conteneur utilise uniquement ``, il résoudra vers le service +qui est local à un namespace. Cela est utile pour utiliser la même configuration à travers +plusieurs namespaces tels que Développement, Staging et Production. Si vous souhaitez accéder +à travers les namespaces, vous devez utiliser le nom de domaine complet (FQDN). -## Tous les objets ne se trouvent pas dans un namespace +En conséquence, tous les noms de namespace doivent être valides + [DNS RFC 1123](/fr/docs/concepts/overview/working-with-objects/names/#dns-label-names). -La plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication et autres) sont -dans des namespaces. Cependant, les ressources de type namespace ne sont pas elles-mêmes dans un namespace. -Et les ressources de bas niveau, telles que les [nœuds](/docs/admin/node) et les volumes persistants, ne se trouvent dans aucun namespace. +{{< warning >}} +En créant des namespaces avec le même nom que des [domaines de premier niveau publics](https://data.iana.org/TLD/tlds-alpha-by-domain.txt), les Services dans ces +espaces de noms peuvent avoir des noms DNS courts qui se chevauchent avec des enregistrements DNS publics. +Les charges de travail de n'importe quel namespace effectuant une recherche DNS sans un [point final](https://datatracker.ietf.org/doc/html/rfc1034#page-8) seront +redirigées vers ces services, prenant le pas sur les DNS publics. -Pour voir quelles ressources Kubernetes sont et ne sont pas dans un namespace: +Pour atténuer cela, limitez les privilèges de création de namespaces aux utilisateurs de confiance. Si +nécessaire, vous pouvez également configurer des contrôles de sécurité tiers, tels que des +[admission +webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/), +pour bloquer la création de tout namespace avec le nom de [TLDs publics](https://data.iana.org/TLD/tlds-alpha-by-domain.txt). +{{< /warning >}} + + +## Tous les objets ne sont pas dans un namespace + +La plupart des ressources Kubernetes (par exemple, les pods, les services, les contrôleurs de réplication, et autres) se trouvent dans des namespaces. Cependant, les ressources de namespace elles-mêmes ne se trouvent pas dans un namespace. Et les ressources de bas niveau, telles que les [nœuds](/docs/concepts/architecture/nodes/) et les [persistentVolumes](/docs/concepts/storage/persistent-volumes/), ne se trouvent dans aucun namespace. + +Pour voir quelles ressources Kubernetes se trouvent ou ne se trouvent pas dans un namespace : ```shell # Dans un namespace @@ -105,7 +129,18 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` + +## Étiquetage automatique + +{{< feature-state for_k8s_version="1.22" state="stable" >}} + +Le plan de contrôle de Kubernetes définit un {{< glossary_tooltip text="label" term_id="label" >}} immuable `kubernetes.io/metadata.name` sur tous les namespaces. +La valeur du label est le nom du namespace. + + ## {{% heading "whatsnext" %}} -- En savoir plus sur [créer un nouveau namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). -- En savoir plus sur [suppression d'un namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). +* En savoir plus sur [la création d'un nouveau namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). +* En savoir plus sur [la suppression d'un namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). + + diff --git a/content/fr/docs/concepts/overview/working-with-objects/object-management.md b/content/fr/docs/concepts/overview/working-with-objects/object-management.md new file mode 100644 index 0000000000..e5286ef2af --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/object-management.md @@ -0,0 +1,178 @@ +--- +title: Kubernetes Object Management +content_type: concept +weight: 20 +--- + + +L'outil en ligne de commande `kubectl` prend en charge plusieurs façons différentes de créer et gérer des {{< glossary_tooltip text="objets" term_id="object" >}} Kubernetes. +Ce document donne un aperçu des différentes approches. +Consultez le [livre Kubectl](https://kubectl.docs.kubernetes.io) pour plus de détails +sur la gestion des objets avec Kubectl. + + + +## Management techniques + +{{< warning >}} +Un objet Kubernetes doit être géré en utilisant une seule technique. Mélanger et combiner des techniques pour le même objet entraîne un comportement indéfini. +{{< /warning >}} + +| Technique de gestion | Opère sur | Environnement recommandé | Operateurs supportés | Courbe d'apprentissage | +|----------------------------------|----------------------|------------------------|---------------------|-----------------------| +| Commandes impératives | Objets en direct | Projets de développement | 1+ | La plus basse | +| Configuration impérative d'objet | Fichiers individuels | Projets de production | 1 | Modérée | +| Configuration déclarative d'objet| Répertoires de fichiers | Projets de production | 1+ | La plus élevée | + + +## Commandes impératives + +Lors de l'utilisation de commandes impératives, un utilisateur opère directement sur des objets +en direct dans un cluster. +L'utilisateur fournit les opérations à la commande `kubectl` en tant qu'arguments ou indicateurs. + +C'est la méthode recommandée pour commencer ou exécuter une tâche ponctuelle dans un cluster. +Étant donné que cette technique opère directement sur des objets en direct, +elle ne fournit aucune historique des configurations précédentes. + +### Exemples + +Exécutez une instance du conteneur nginx en créant un objet Deployment : + +```sh +kubectl create deployment nginx --image nginx +``` +### Compromis + +Avantages par rapport à la configuration d'objet : + +- Les commandes sont exprimées par un seul mot d'action. +- Les commandes ne nécessitent qu'une seule étape pour apporter des modifications au cluster. + +Inconvénients par rapport à la configuration d'objet : + +- Les commandes ne s'intègrent pas aux processus de révision des modifications. +- Les commandes ne fournissent pas de piste d'audit associée aux modifications. +- Les commandes ne fournissent pas de source d'enregistrement, sauf ce qui est en direct. +- Les commandes ne fournissent pas de modèle pour créer de nouveaux objets. + + +## Configuration impérative d'objet + +Dans la configuration impérative d'objet, la commande kubectl spécifie +l'opération (créer, remplacer, etc.), des indicateurs facultatifs et au moins +un nom de fichier. Le fichier spécifié doit contenir une définition complète +de l'objet au format YAML ou JSON. + +Consultez la [référence de l'API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +pour plus de détails sur les définitions d'objets. + +{{< warning >}} +La commande impérative `replace` remplace la spécification existante +par celle nouvellement fournie, en supprimant toutes les modifications +apportées à l'objet qui ne figurent pas dans le fichier de configuration. +Cette approche ne doit pas être utilisée avec des types de ressources +dont les spécifications sont mises à jour indépendamment du fichier de configuration. +Par exemple, les services de type `LoadBalancer` ont leur champ `externalIPs` mis à jour indépendamment de la configuration par le cluster. +{{< /warning >}} + +### Exemples + +Créez les objets définis dans un fichier de configuration : + +```sh +kubectl create -f nginx.yaml +``` + +Supprimez les objets définis dans deux fichiers de configuration : + +```sh +kubectl delete -f nginx.yaml -f redis.yaml +``` + +Mettre à jour les objets définis dans un fichier de configuration +en écrasant la configuration en direct : + +```sh +kubectl replace -f nginx.yaml +``` + +### Compromis + +Avantages par rapport aux commandes impératives : + +- La configuration d'objet peut être stockée dans un système de contrôle de source tel que Git. +- La configuration d'objet peut s'intégrer à des processus tels que la révision des modifications avant la validation et les pistes d'audit. +- La configuration d'objet fournit un modèle pour créer de nouveaux objets. + +Inconvénients par rapport aux commandes impératives : + +- La configuration d'objet nécessite une compréhension de base du schéma de l'objet. +- La configuration d'objet nécessite une étape supplémentaire consistant à rédiger un fichier YAML. + +Avantages par rapport à la configuration d'objet déclarative : + +- Le comportement de la configuration d'objet impérative est plus simple et plus facile à comprendre. +- À partir de la version 1.5 de Kubernetes, la configuration d'objet impérative est plus mature. + +Inconvénients par rapport à la configuration d'objet déclarative : + +- La configuration d'objet impérative fonctionne mieux sur des fichiers, pas sur des répertoires. +- Les mises à jour des objets en direct doivent être reflétées dans les fichiers de configuration, sinon elles seront perdues lors du prochain remplacement. + +## Configuration déclarative d'objet + +Lors de l'utilisation de la configuration déclarative d'objet, un utilisateur opère +sur des fichiers de configuration d'objet stockés localement, +mais l'utilisateur ne définit pas les opérations à effectuer sur les fichiers. +Les opérations de création, de mise à jour et de suppression sont automatiquement détectées par `kubectl` pour chaque objet. +Cela permet de travailler sur des répertoires, où différentes opérations peuvent être nécessaires pour différents objets. + +{{< note >}} +La configuration déclarative d'objet conserve les modifications apportées par d'autres, +même si les modifications ne sont pas fusionnées dans le fichier de configuration de l'objet. +Cela est possible en utilisant l'opération d'API `patch` pour écrire uniquement les différences +observées, au lieu d'utiliser l'opération d'API `replace` pour remplacer l'ensemble de la configuration +de l'objet. +{{< /note >}} + +### Exemples + +Traitez tous les fichiers de configuration d'objet dans le répertoire `configs` et créez ou +appliquez les modifications aux objets en direct. Vous pouvez d'abord utiliser `diff` pour voir quelles modifications vont être +apportées, puis appliquer les modifications : + +```sh +kubectl diff -f configs/ +kubectl apply -f configs/ +``` + +Traiter récursivement les répertoires : + +```sh +kubectl diff -R -f configs/ +kubectl apply -R -f configs/ +``` + +### Compromis + +Avantages par rapport à la configuration impérative d'objet : + +- Les modifications apportées directement aux objets en direct sont conservées, même si elles ne sont pas fusionnées dans les fichiers de configuration. +- La configuration déclarative d'objet offre une meilleure prise en charge pour travailler sur des répertoires et détecte automatiquement les types d'opérations (création, patch, suppression) par objet. + +Inconvénients par rapport à la configuration impérative d'objet : + +- La configuration déclarative d'objet est plus difficile à déboguer et à comprendre lorsque les résultats sont inattendus. +- Les mises à jour partielles à l'aide de diffs créent des opérations de fusion et de patch complexes. + +## {{% heading "whatsnext" %}} + +- [Gestion des objets Kubernetes en utilisant des commandes impératives](/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [Gestion impérative des objets Kubernetes en utilisant des fichiers de configuration](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [Gestion déclarative des objets Kubernetes à l'aide de fichiers de configuration](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [Gestion déclarative des objets Kubernetes en utilisant Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [Référence des commandes Kubectl](/docs/reference/generated/kubectl/kubectl-commands/) +- [Livre Kubectl](https://kubectl.docs.kubernetes.io) +- [Référence de l'API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/fr/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/fr/docs/concepts/overview/working-with-objects/owners-dependents.md new file mode 100644 index 0000000000..66a6b710ec --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -0,0 +1,89 @@ +--- +title: Propriétaires et dépendants +content_type: concept +weight: 90 +--- + + + +Dans Kubernetes, certains {{< glossary_tooltip text="objets" term_id="object" >}} sont +*propriétaires* d'autres objets. Par exemple, un +{{}} est le propriétaire +d'un ensemble de Pods. Ces objets dépendants sont les *dépendants* de leur propriétaire. + +La propriété est différente du mécanisme [labels et sélecteurs](/fr/docs/concepts/overview/working-with-objects/labels/) +que certains ressources utilisent également. Par exemple, considérez un Service qui +crée des objets `EndpointSlice`. Le Service utilise des {{}} pour permettre au plan de contrôle de +déterminer quels objets `EndpointSlice` sont utilisés pour ce Service. En plus +des labels, 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 différentes parties de Kubernetes à éviter +d'interférer avec des objets qu'elles ne contrôlent pas. + +## Références de propriétaire dans les spécifications d'objet + +Les objets dépendants ont un champ `metadata.ownerReferences` qui référence leur +objet propriétaire. Une référence de propriétaire valide est composée du nom de l'objet et d'un {{}} +dans le même {{}} que l'objet dépendant. Kubernetes définit automatiquement la valeur de +ce champ pour les objets qui sont des dépendants d'autres objets comme +ReplicaSets, DaemonSets, Deployments, Jobs et CronJobs, et ReplicationControllers. +Vous pouvez également configurer ces relations manuellement en modifiant la valeur de +ce champ. Cependant, vous n'avez généralement pas besoin de le faire et pouvez permettre à Kubernetes de +gérer automatiquement les relations. + +Les objets dépendants ont également un champ `ownerReferences.blockOwnerDeletion` qui +prend une valeur booléenne et contrôle si des dépendants spécifiques peuvent bloquer la suppression +de leur objet propriétaire par la collecte des déchets. Kubernetes définit automatiquement ce +champ à `true` si un {{}} +(par exemple, le contrôleur de déploiement) définit la valeur du champ +`metadata.ownerReferences`. Vous pouvez également définir manuellement la valeur du +champ `blockOwnerDeletion` pour contrôler quels dépendants bloquent la collecte des déchets. + +Un contrôleur d'admission Kubernetes contrôle l'accès utilisateur pour modifier ce champ pour +les ressources dépendantes, en fonction des autorisations de suppression du propriétaire. Ce contrôle +empêche les utilisateurs non autorisés de retarder la suppression de l'objet propriétaire. + +{{< note >}} +Les références de propriétaire entre espaces de noms 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 la collecte des déchets. + +À partir de la version 1.20, si le collecteur de déchets détecte une référence de propriétaire invalide entre espaces de noms, +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 invalide est signalé. +Vous pouvez vérifier ce type d'événement en exécutant +`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. +{{< /note >}} + +## Propriété et finalisateurs + +Lorsque vous demandez à Kubernetes de supprimer une ressource, le serveur API permet au +contrôleur de gestion de traiter toutes les [règles de finalisation](/fr/docs/concepts/overview/working-with-objects/finalizers/) +pour la ressource. Les {{}} +empêchent la suppression accidentelle de ressources dont votre cluster peut encore avoir besoin +pour fonctionner correctement. Par exemple, si vous essayez de supprimer un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) qui est encore +utilisé par un Pod, la suppression ne se produit pas immédiatement car le +`PersistentVolume` a le finaliseur `kubernetes.io/pv-protection`. +Au lieu de cela, le [volume](/docs/concepts/storage/volumes/) reste dans l'état `Terminating` jusqu'à ce que Kubernetes supprime +le finaliseur, ce qui se produit uniquement après que le `PersistentVolume` n'est plus +lié à un Pod. + +Kubernetes ajoute également des finalisateurs à une ressource propriétaire lorsque vous utilisez soit +la suppression en premier plan ou la suppression en cascade des orphelins](/docs/concepts/architecture/garbage-collection/#cascading-deletion). +Dans la suppression en premier plan, il ajoute le finaliseur `foreground` de sorte que le +contrôleur doit supprimer les ressources dépendantes qui ont également +`ownerReferences.blockOwnerDeletion=true` avant de supprimer le propriétaire. Si vous +spécifiez une politique de suppression des orphelins, Kubernetes ajoute le finaliseur `orphan` de sorte +que le contrôleur ignore les ressources dépendantes après avoir supprimé l'objet propriétaire. + +## {{% heading "whatsnext" %}} + +* En savoir plus sur les [finalisateurs Kubernetes](/fr/docs/concepts/overview/working-with-objects/finalizers/). +* Apprendre sur la [collecte des déchets](/docs/concepts/architecture/garbage-collection). +* Lire la référence API pour [les métadonnées d'objet](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). + diff --git a/content/fr/docs/reference/glossary/finalizer.md b/content/fr/docs/reference/glossary/finalizer.md new file mode 100644 index 0000000000..837fa06f91 --- /dev/null +++ b/content/fr/docs/reference/glossary/finalizer.md @@ -0,0 +1,30 @@ +--- +title: Finalizer +id: finalizer +date: 2024-09-02 +full_link: /docs/concepts/overview/working-with-objects/finalizers/ +short_description: > + Une clé du namespace qui indique à Kubernetes d'attendre que certaines conditions soient remplies + avant de supprimer complètement un objet marqué pour la suppression. +aka: +tags: +- fundamental +- operation +--- +Les finalizers sont des clés des namespaces qui indiquent à Kubernetes d'attendre que certaines +conditions soient remplies avant de supprimer complètement les ressources marquées pour la suppression. +Les finalizers alertent les {{}} pour nettoyer les ressources appartenant à l'objet supprimé. + + + +Lorsque vous demandez à Kubernetes de supprimer un objet qui a des finalizers spécifiés, +l'API Kubernetes marque l'objet pour la suppression en remplissant le champ `.metadata.deletionTimestamp`, +et renvoie un code d'état `202` (HTTP "Accepté"). L'objet cible reste dans un état de terminaison pendant que le +plan de contrôle, ou d'autres composants, effectuent les actions définies par les finalizers. +Une fois ces actions terminées, le contrôleur supprime les finalizers pertinents +de l'objet cible. Lorsque le champ `metadata.finalizers` est vide, +Kubernetes considère la suppression comme terminée et supprime l'objet. + +Vous pouvez utiliser des finalizers pour contrôler la {{}} +des ressources. Par exemple, vous pouvez définir un finalizer pour nettoyer les ressources ou +l'infrastructure associée avant que le contrôleur ne supprime la ressource cible. diff --git a/content/fr/docs/reference/glossary/garbage-collection.md b/content/fr/docs/reference/glossary/garbage-collection.md new file mode 100644 index 0000000000..70c424ba68 --- /dev/null +++ b/content/fr/docs/reference/glossary/garbage-collection.md @@ -0,0 +1,20 @@ +--- +title: Garbage Collection +id: garbage-collection +date: 2024-09-02 +full_link: /docs/concepts/architecture/garbage-collection/ +short_description: > + Le Garbage collection est un terme générique désignant les différents mécanismes utilisés par Kubernetes pour nettoyer les ressources du cluster. + +aka: +tags: +- fundamental +- operation +--- + +Le Garbage collection est un terme générique désignant les différents mécanismes utilisés par Kubernetes pour nettoyer les ressources du cluster. + + + +Kubernetes utilise la collecte des déchets pour nettoyer les ressources telles que les [conteneurs et images inutilisés](/docs/concepts/architecture/garbage-collection/#containers-images), les [Pods en échec](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), les objets possédés par la ressource ciblée, les [Jobs terminés](/docs/concepts/workloads/controllers/ttlafterfinished/) et les ressources qui ont expiré ou échoué. + diff --git a/content/fr/docs/reference/glossary/name.md b/content/fr/docs/reference/glossary/name.md new file mode 100644 index 0000000000..06e6a569f8 --- /dev/null +++ b/content/fr/docs/reference/glossary/name.md @@ -0,0 +1,19 @@ +--- +title: Name +id: name +date: 2024-09-02 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + Un texte fourni par le client qui fait référence à un objet dans une URL de ressource, comme `/api/v1/pods/some-name`. + +aka: +tags: +- fundamental +--- +Un texte fourni par le client qui fait référence à un objet dans une URL de ressource, comme `/api/v1/pods/some-name`. + + + +Seul un objet d'un certain type peut avoir un nom donné à la fois. Cependant, si vous supprimez l'objet, vous pouvez créer un nouvel objet avec le même nom. + +