Concepts

• 1: Vue d'ensemble
• 1.1: Composants de Kubernetes
• 1.2: Objets dans Kubernetes
• 1.2.1: Kubernetes Object Management
• 1.2.2: Noms et identifiants d'objets
• 1.2.3: Labels et sélecteurs
• 1.2.4: Namespaces
• 1.2.5: Annotations
• 1.2.6: Sélecteurs de champs
• 1.2.7: Finalisateurs
• 1.2.8: Propriétaires et dépendants
• 1.2.9: labels recommandées
• 1.3: L'API Kubernetes
• 2: Architecture du cluster
• 2.1: Noeuds
• 2.2: Communication entre les nœuds et le plan de contrôle
• 2.3: Contrôleurs
• 2.4: Lease
• 2.5: Gestionnaire du contrôleur de cloud
• 2.6: À propos de cgroup v2
• 2.7: Interface de Runtime de Conteneur (CRI)
• 2.8: Collecte des déchets
• 2.9: Proxy de version mixte
• 3: Les conteneurs
• 3.1: Images
• 3.2: Classe d'exécution (Runtime Class)
• 3.3: L'environnement du conteneur
• 3.4: Hooks de cycle de vie de conteneurs
• 4: Workloads
• 4.1: Pods
• 4.1.1: Aperçu du Pod
• 4.1.2: Pods
• 4.1.3: Cycle de vie d'un Pod
• 4.1.4: Contraintes de propagation de topologie pour les Pods
• 4.1.5: Init Containers
• 4.2: Contrôleurs
• 4.2.1: ReplicaSet
• 4.2.2: Déploiements
• 4.2.3: StatefulSets
• 5: Services, Equilibreur de charge, et Réseau
• 5.1: EndpointSlices
• 5.2: Service
• 5.3: DNS pour les services et les pods
• 5.4: Ingress
• 6: Stockage
• 6.1: Volumes
• 6.2: Volumes persistants
• 7: Configuration
• 7.1: Secrets
• 8: Sécurité
• 9: Politiques
• 10: Administration d'un cluster
• 10.1: Vue d'ensemble de l'administration d'un cluster
• 10.2: Certificats
• 10.3: Architecture de Journalisation d'évènements (logging)
• 11: Extensions Kubernetes
• 11.1: Extensions de l'API Kubernetes
• 11.2: Extensions compute, stockage et réseau

1 - Vue d'ensemble

Cette page est une vue d'ensemble de Kubernetes.

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

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.
• 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

Jetons un coup d'œil à pourquoi Kubernetes est si utile en remontant dans le temps.

È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é.

A suivre

• Jetez un coup d'œil aux Composants Kubernetes
• Jetez un coup d'œil à L'API Kubernetes
• Jetez un coup d'œil à L'Architecture du Cluster
• Prêt à Commencer ?

1.1 - Composants de Kubernetes

Cette page fournit un aperçu général des composants essentiels qui constituent un cluster Kubernetes.

Composants principaux

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 :

Composants du plan de contrôle

Gèrent l'état global du cluster :

kube-apiserver

Le serveur principal qui expose l'API HTTP de Kubernetes

etcd

Un magasin de clés-valeurs cohérent et hautement disponible pour toutes les données du serveur API

kube-scheduler

Recherche les Pods qui ne sont pas encore liés à un nœud et attribue chaque Pod à un nœud approprié.

kube-controller-manager

Exécute des contrôleurs pour mettre en œuvre le comportement de l'API Kubernetes.

cloud-controller-manager (optionnel)

S'intègre aux fournisseurs de cloud sous-jacents.

Composants des nœuds

S'exécutent sur chaque nœud, maintiennent les pods en cours d'exécution et fournissent l'environnement d'exécution Kubernetes :

kubelet

Veille à ce que les Pods s'exécutent, y compris leurs conteneurs.

kube-proxy (optionnel)

Maintient les règles réseau sur les nœuds pour mettre en œuvre les Services.

Runtime de conteneur

Logiciel responsable de l'exécution des conteneurs. Lisez Runtimes de conteneurs pour en savoir plus.

Votre cluster peut nécessiter des logiciels supplémentaires sur chaque nœud ; par exemple, vous pouvez également exécuter systemd sur un nœud Linux pour superviser les composants locaux.

Extensions

Les extensions étendent les fonctionnalités de Kubernetes. Quelques exemples importants incluent :

DNS

Pour la résolution DNS à l'échelle du cluster

Interface utilisateur Web (Tableau de bord)

Pour la gestion du cluster via une interface web

Surveillance des ressources des conteneurs

Pour collecter et stocker les métriques des conteneurs

Journalisation au niveau du cluster

Pour enregistrer les journaux des conteneurs dans un référentiel de journaux centralisé

Flexibilité dans l'architecture

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.

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.

1.2 - Objets dans Kubernetes

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

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

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 plan de contrôle 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.

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 :

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

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 dans l'interface de ligne de commande kubectl, en passant le fichier .yaml en argument. Voici un exemple :

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

Validation des champs côté serveur

À partir de Kubernetes v1.25, le serveur API offre une validation des champs côté serveur 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.

A suivre

Si vous débutez avec Kubernetes, lisez-en plus sur les sujets suivants :

• Pods qui sont les objets Kubernetes de base les plus importants.
• Déploiement d'objets.
• Contrôleurs dans Kubernetes.
• kubectl et commandes kubectl.

La gestion des objets Kubernetes explique comment utiliser kubectl pour gérer les objets. Vous devrez peut-être installer 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

Pour approfondir vos connaissances sur les objets dans Kubernetes, lisez d'autres pages de cette section :

1.2.1 - Kubernetes Object Management

L'outil en ligne de commande kubectl prend en charge plusieurs façons différentes de créer et gérer des objets Kubernetes. Ce document donne un aperçu des différentes approches. Consultez le livre Kubectl pour plus de détails sur la gestion des objets avec Kubectl.

Management techniques

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 :

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 pour plus de détails sur les définitions d'objets.

Exemples

Créez les objets définis dans un fichier de configuration :

kubectl create -f nginx.yaml

Supprimez les objets définis dans deux fichiers de configuration :

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 :

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.

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 :

kubectl diff -f configs/
kubectl apply -f configs/

Traiter récursivement les répertoires :

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.

A suivre

• Gestion des objets Kubernetes en utilisant des commandes impératives
• Gestion impérative des objets Kubernetes en utilisant des fichiers de configuration
• Gestion déclarative des objets Kubernetes à l'aide de fichiers de configuration
• Gestion déclarative des objets Kubernetes en utilisant Kustomize
• Référence des commandes Kubectl
• Livre Kubectl
• Référence de l'API Kubernetes

1.2.2 - Noms et identifiants d'objets

Chaque objet dans votre cluster a un Nom qui est unique pour ce type de ressource. Chaque objet Kubernetes a également un UID 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, 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 et des annotations.

Noms

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.

Les noms doivent être uniques pour toutes les versions d'API 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.

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

Certains types de ressources nécessitent que leurs noms suivent la norme des labels DNS telle que définie dans RFC 1123. 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. 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

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.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

UIDs

Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.

Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires.

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.

A suivre

• Lisez à propos des labels et des annotations dans Kubernetes.
• Consultez le document de conception Identifiers and Names in Kubernetes.

1.2.3 - Labels et sélecteurs

Les labels sont des paires clé/valeur qui sont attachées aux objets 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é.

"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.

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 :

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, 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.

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".

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

kubectl get pods -l environment=production,tier=frontend

ou en utilisant des exigences basées sur un ensemble :

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 :

kubectl get pods -l 'environment in (production, qa)'

ou restreindre la correspondance négative via l'opérateur notin :

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 et les replicationcontrollers, utilisent également des sélecteurs de labels pour spécifier des ensembles d'autres ressources, telles que les 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 :

"selector": {
    "component" : "redis",
}

ou

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, Deployment, ReplicaSet et DaemonSet, prennent également en charge les exigences basées sur un ensemble.

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 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, aurait également besoin de distinguer chaque niveau. Le frontend pourrait avoir les labels suivants:

labels:
  app: guestbook
  tier: frontend

while the Redis master and replica would have different tier labels, and perhaps even an additional role label:

labels:
  app: guestbook
  tier: backend
  role: master

and

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 :

kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
kubectl get pods -Lapp -Ltier -Lrole

NAME                           READY  STATUS    RESTARTS   AGE   APP         TIER       ROLE
guestbook-fe-4nlpb             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-ght6d             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-jpy62             1/1    Running   0          1m    guestbook   frontend   <none>
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       <none>     <none>
my-nginx-o0ef1                 1/1    Running   0          29m   nginx       <none>     <none>

kubectl get pods -lapp=guestbook,role=replica

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 :

kubectl label pods -l app=nginx tier=fe

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 :

kubectl get pods -l app=nginx -L tier

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.

A suivre

• Apprenez comment ajouter un label à un nœud
• Trouvez des informations sur les labels, annotations et taints bien connus
• Consultez les labels recommandés
• Appliquez les normes de sécurité des pods avec des labels de namespace
• Lisez un blog sur l'écriture d'un contrôleur pour les labels de pod

1.2.4 - Namespaces

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 objets 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 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 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 diviser les ressources du cluster entre plusieurs utilisateurs (via des quotas de ressources).

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 labels pour distinguer les ressources dans le même namespace.

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 associés à chaque nœud. Les leases de nœud permettent au kubelet d'envoyer des contrôles 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.

Affichage des namespaces

Vous pouvez lister les namespaces actuels dans un cluster en utilisant :

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

Définir le namespace pour une requête

Pour définir le namespace pour une requête en cours, utilisez le drapeau --namespace.

Par exemple :

kubectl run nginx --image=nginx --namespace=<insérer-nom-du-namespace-ici>
kubectl get pods --namespace=<insérer-nom-du-namespace-ici>

Définir la préférence de namespace

Vous pouvez enregistrer de manière permanente le namespace pour toutes les commandes kubectl ultérieures dans ce contexte.

kubectl config set-context --current --namespace=<insérer-nom-du-namespace-ici>
# Validez-le
kubectl config view --minify | grep namespace:

Namespaces et DNS

Lorsque vous créez un Service, cela crée une entrée DNS correspondante. Cette entrée est de la forme <nom-du-service>.<nom-du-namespace>.svc.cluster.local, ce qui signifie que si un conteneur utilise uniquement <nom-du-service>, 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).

En conséquence, tous les noms de namespace doivent être valides DNS RFC 1123.

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 et les persistentVolumes, ne se trouvent dans aucun namespace.

Pour voir quelles ressources Kubernetes se trouvent ou ne se trouvent pas dans un namespace :

# Dans un namespace
kubectl api-resources --namespaced=true

# Pas dans un namespace
kubectl api-resources --namespaced=false

Étiquetage automatique

Le plan de contrôle de Kubernetes définit un label immuable kubernetes.io/metadata.name sur tous les namespaces. La valeur du label est le nom du namespace.

A suivre

• En savoir plus sur la création d'un nouveau namespace.
• En savoir plus sur la suppression d'un namespace.

1.2.5 - Annotations

Vous pouvez utiliser les annotations Kubernetes pour attacher des métadonnées non identifiantes arbitraires aux objets. 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 :

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

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, kubectl`, 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/ :

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

A suivre

• En savoir plus sur Les labels et les sélecteurs.
• Trouver Les labels, annotations et taints bien connus

1.2.6 - Sélecteurs de champs

Les sélecteurs de champs vous permettent de sélectionner des objets 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 est Running :

kubectl get pods --field-selector status.phase=Running

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 :

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

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 :

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

Sélecteurs enchaînés

Comme pour les 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 :

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 :

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

1.2.7 - Finalisateurs

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 contrôleurs 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 collecte des déchets 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.

Vous pouvez utiliser des finalisateurs pour contrôler la collecte des déchets des objets en alertant les contrôleurs 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.

Références de propriétaire, labels et finalisateurs

Comme les labels, les références de propriétaire décrivent les relations entre les objets dans Kubernetes, mais sont utilisées à une fin différente. Lorsqu'un contrôleur 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 Job 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.

A suivre

• Lisez Utilisation des finalisateurs pour contrôler la suppression sur le blog Kubernetes.

1.2.8 - Propriétaires et dépendants

Dans Kubernetes, certains objets sont propriétaires d'autres objets. Par exemple, un ReplicaSet 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 que certains ressources utilisent également. Par exemple, considérez un Service qui crée des objets EndpointSlice. Le Service utilise des label 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 UID dans le même namespace 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 contrôleur (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.

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 pour la ressource. Les Finalizer 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 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 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.

A suivre

• En savoir plus sur les finalisateurs Kubernetes.
• Apprendre sur la collecte des déchets.
• Lire la référence API pour les métadonnées d'objet.

1.2.9 - labels recommandées

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.

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.

Pour illustrer ces labels en action, considérez l'objet StatefulSet suivant :

# 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.

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.

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 :

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 :

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 :

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:

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.

1.3 - L'API Kubernetes

Le cœur du plan de contrôle de Kubernetes est le serveur API. 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 ou d'autres outils en ligne de commande, tels que 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 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 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 fournit des schémas (complets) OpenAPI v2.0 et 3.0 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

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 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/<group>/<version> (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.

Pour plus de détails sur les spécifications OpenAPI, consultez la documentation OpenAPI.

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 :

OpenAPI V3

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 :

{
    "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/<group>/<version>?hash=<hash>.

Reportez-vous au tableau ci-dessous pour les en-têtes de requête acceptés.

Une implémentation en Golang pour récupérer l'OpenAPI V3 est fournie dans le package k8s.io/client-go/openapi3.

Kubernetes 1.31 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 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 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 qui peuvent être activés ou désactivés.

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.

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.

Consultez la référence des versions d'API 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 vous permettent de définir de manière déclarative comment le serveur API doit fournir votre API de ressource choisie.
2. Vous pouvez également étendre l'API Kubernetes en implémentant une couche d'agrégation.

A suivre

• Apprenez comment étendre l'API Kubernetes en ajoutant votre propre CustomResourceDefinition.
• Contrôler l'accès à l'API Kubernetes 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.
• Apprenez ce qui constitue un changement compatible et comment modifier l'API à partir de Changements d'API.

2 - Architecture du cluster

Un cluster Kubernetes est composé d'un plan de contrôle et d'un ensemble de machines de travail, appelées nœuds, qui exécutent des applications conteneurisées. Chaque cluster a besoin d'au moins un nœud de travail pour exécuter des Pods.

Les nœuds de travail hébergent les Pods qui sont les composants de la charge de travail de l'application. Le plan de contrôle gère les nœuds de travail et les Pods du cluster. Dans les environnements de production, le plan de contrôle s'exécute généralement sur plusieurs ordinateurs et un cluster exécute généralement plusieurs nœuds, offrant une tolérance aux pannes et une haute disponibilité.

Ce document décrit les différents composants nécessaires pour avoir un cluster Kubernetes complet et fonctionnel.

Composants du plan de contrôle

Les composants du plan de contrôle prennent des décisions globales sur le cluster (par exemple, la planification), ainsi que la détection et la réponse aux événements du cluster (par exemple, démarrer un nouveau pod lorsque le champ replicas d'un déploiement n'est pas satisfait).

Les composants du plan de contrôle peuvent s'exécuter sur n'importe quelle machine du cluster. Cependant, pour simplifier, les scripts d'installation démarrent généralement tous les composants du plan de contrôle sur la même machine et n'exécutent pas de conteneurs utilisateur sur cette machine. Consultez Création de clusters hautement disponibles avec kubeadm pour un exemple de configuration du plan de contrôle s'exécutant sur plusieurs machines.

kube-apiserver

Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes.

Il est conçu pour une mise à l'échelle horizontale, ce qui veut dire qu'il met à l'échelle en déployant des instances supplémentaires. Voir Construire des Clusters en Haute Disponibilité.

etcd

Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster.

Si votre cluster Kubernetes utilise etcd comme mémoire de sauvegarde, assurez-vous d'avoir un plan de back up pour ces données.

Vous pouvez trouver plus d'informations à propos d'etcd dans la documentation officielle.

kube-scheduler

Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter.

Les facteurs pris en compte pour les décisions de planification (scheduling) comprennent les exigences individuelles et collectives en ressources, les contraintes matérielles/logicielles/politiques, les spécifications d'affinité et d'anti-affinité, la localité des données, les interférences entre charges de travail et les dates limites.

kube-controller-manager

Composant du master qui exécute les contrôleurs.

Logiquement, chaque contrôleur est un processus à part mais, pour réduire la complexité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus.

Il existe de nombreux types de contrôleurs différents. Voici quelques exemples :

• Contrôleur de nœuds : Responsable de la détection et de la réponse lorsque les nœuds tombent en panne.
• Contrôleur de tâches : Surveille les objets Job qui représentent des tâches ponctuelles, puis crée des Pods pour exécuter ces tâches jusqu'à leur achèvement.
• Contrôleur EndpointSlice : Remplit les objets EndpointSlice (pour établir un lien entre les Services et les Pods).
• Contrôleur ServiceAccount : Crée des comptes de service par défaut pour les nouveaux espaces de noms.

Ce qui précède n'est pas une liste exhaustive.

cloud-controller-manager

Le cloud-controller-manager exécute uniquement des contrôleurs spécifiques à votre fournisseur de cloud. Si vous exécutez Kubernetes sur vos propres serveurs ou dans un environnement d'apprentissage sur votre propre PC, le cluster n'a pas de cloud-controller-manager.

Comme pour kube-controller-manager, cloud-controller-manager combine plusieurs boucles de contrôle logiquement indépendantes en un seul binaire que vous exécutez en tant que processus unique. Vous pouvez mettre à l'échelle horizontalement (exécuter plusieurs copies) pour améliorer les performances ou pour aider à tolérer les pannes.

Les contrôleurs suivants peuvent avoir des dépendances vis-à-vis du fournisseur de cloud :

• Contrôleur de nœuds : Pour vérifier auprès du fournisseur de cloud si un nœud a été supprimé dans le cloud après avoir cessé de répondre
• Contrôleur de routage : Pour configurer les routes dans l'infrastructure cloud sous-jacente
• Contrôleur de service : Pour créer, mettre à jour et supprimer des équilibreurs de charge du fournisseur de cloud

Composants du nœud

Les composants du nœud s'exécutent sur chaque nœud, maintenant les Pods en cours d'exécution et fournissant l'environnement d'exécution Kubernetes.

kubelet

Un agent qui s'exécute sur chaque nœud du cluster. Il s'assure que les conteneurs fonctionnent dans un pod.

Le kubelet prend un ensemble de PodSpecs fournis par divers mécanismes et s'assure du fonctionnement et de la santé des conteneurs décrits dans ces PodSpecs. Le kubelet ne gère que les conteneurs créés par Kubernetes.

kube-proxy (optionnel)

kube-proxy est un proxy réseau qui s'exécute sur chaque nœud du cluster et implémente une partie du concept Kubernetes de Service.

kube-proxy maintient les règles réseau sur les nœuds. Ces règles réseau permettent une communication réseau vers les Pods depuis des sessions réseau à l'intérieur ou à l'extérieur du cluster.

kube-proxy utilise la couche de filtrage de paquets du système d'exploitation s'il y en a une et qu'elle est disponible. Sinon, kube-proxy transmet le trafic lui-même.

Runtime de conteneur

L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs.

Kubernetes est compatible avec plusieurs environnements d'exécution de conteneur: Docker, containerd, cri-o, rktlet ainsi que toute implémentation de Kubernetes CRI (Container Runtime Interface).

Add-ons

Les add-ons utilisent des ressources Kubernetes (DaemonSet, Déploiement, etc.) pour implémenter des fonctionnalités de cluster. Étant donné qu'ils fournissent des fonctionnalités au niveau du cluster, les ressources des add-ons appartiennent au namespace kube-system.

Certains add-ons sélectionnés sont décrits ci-dessous ; pour une liste étendue d'add-ons disponibles, veuillez consulter Add-ons.

DNS

Bien que les autres add-ons ne soient pas strictement nécessaires, tous les clusters Kubernetes devraient avoir DNS du cluster, car de nombreux exemples en dépendent.

Le DNS du cluster est un serveur DNS, en plus des autres serveur(s) DNS de votre environnement, qui fournit des enregistrements DNS pour les services Kubernetes.

Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS.

Interface utilisateur Web (Dashboard)

Dashboard est une interface utilisateur basée sur le web, générale, pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de résoudre les problèmes des applications en cours d'exécution dans le cluster, ainsi que du cluster lui-même.

Surveillance des ressources des conteneurs

Surveillance des ressources des conteneurs enregistre des métriques génériques de séries chronologiques sur les conteneurs dans une base de données centrale et fournit une interface utilisateur pour parcourir ces données.

Journalisation au niveau du cluster

Un mécanisme de journalisation au niveau du cluster est responsable de l'enregistrement des journaux des conteneurs dans un magasin de journaux central avec une interface de recherche/parcours.

Plugins réseau

Les plugins réseau sont des composants logiciels qui implémentent la spécification de l'interface réseau de conteneur (CNI). Ils sont responsables de l'allocation des adresses IP aux pods et de leur permettre de communiquer entre eux au sein du cluster.

Variations de l'architecture

Bien que les composants principaux de Kubernetes restent cohérents, la manière dont ils sont déployés et gérés peut varier. Comprendre ces variations est crucial pour concevoir et maintenir des clusters Kubernetes répondant à des besoins opérationnels spécifiques.

Options de déploiement du plan de contrôle

Les composants du plan de contrôle peuvent être déployés de plusieurs manières :

Déploiement traditionnel

Les composants du plan de contrôle s'exécutent directement sur des machines dédiées ou des machines virtuelles, souvent gérées en tant que services systemd.

Pods statiques

Les composants du plan de contrôle sont déployés en tant que Pods statiques, gérés par le kubelet sur des nœuds spécifiques. Il s'agit d'une approche courante utilisée par des outils tels que kubeadm.

Auto-hébergé

Le plan de contrôle s'exécute en tant que Pods au sein du cluster Kubernetes lui-même, gérés par des déploiements et des StatefulSets ou d'autres primitives Kubernetes.

Services Kubernetes gérés

Les fournisseurs de cloud abstraient souvent le plan de contrôle, en gérant ses composants dans le cadre de leur offre de services.

Considérations pour le placement de la charge de travail

Le placement des charges de travail, y compris les composants du plan de contrôle, peut varier en fonction de la taille du cluster, des exigences de performance et des politiques opérationnelles :

• Dans les clusters plus petits ou de développement, les composants du plan de contrôle et les charges de travail des utilisateurs peuvent s'exécuter sur les mêmes nœuds.
• Les clusters de production plus importants dédient souvent des nœuds spécifiques aux composants du plan de contrôle, les séparant des charges de travail des utilisateurs.
• Certaines organisations exécutent des add-ons critiques ou des outils de surveillance sur les nœuds du plan de contrôle.

Outils de gestion de cluster

Des outils tels que kubeadm, kops et Kubespray offrent différentes approches pour le déploiement et la gestion des clusters, chacun avec sa propre méthode de disposition et de gestion des composants.

La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques, en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion.

Personnalisation et extensibilité

L'architecture de Kubernetes permet une personnalisation significative :

• Des ordonnanceurs personnalisés peuvent être déployés pour travailler aux côtés de l'ordonnanceur Kubernetes par défaut ou pour le remplacer entièrement.
• Les serveurs API peuvent être étendus avec des CustomResourceDefinitions et une agrégation d'API.
• Les fournisseurs de cloud peuvent s'intégrer profondément à Kubernetes en utilisant le cloud-controller-manager.

La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques, en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion.

A suivre

En savoir plus sur les sujets suivants :

• Nœuds et leur communication avec le plan de contrôle.
• Les contrôleurs Kubernetes.
• kube-scheduler, qui est l'ordonnanceur par défaut de Kubernetes.
• La documentation officielle d'Etcd.
• Plusieurs runtimes de conteneurs dans Kubernetes.
• Intégration avec les fournisseurs de cloud en utilisant cloud-controller-manager.
• Commandes kubectl.

2.1 - Noeuds

Kubernetes exécute votre charge de travail en plaçant des conteneurs dans des Pods pour s'exécuter sur des nœuds. Un nœud peut être une machine virtuelle ou physique, selon le cluster. Chaque nœud est géré par le plan de contrôle et contient les services nécessaires pour exécuter Pods.

Typiquement, vous avez plusieurs nœuds dans un cluster ; dans un environnement d'apprentissage ou limité en ressources, vous pourriez n'avoir qu'un seul nœud.

Les composants sur un nœud incluent le kubelet, un runtime de conteneur, et le kube-proxy.

Gestion

Il existe deux principales façons d'ajouter des nœuds au serveur API :

1. Le kubelet sur un nœud s'enregistre automatiquement auprès du plan de contrôle.
2. Vous (ou un autre utilisateur humain) ajoutez manuellement un objet Nœud.

Après avoir créé un objet Nœud, ou lorsque le kubelet sur un nœud s'enregistre automatiquement, le plan de contrôle vérifie si le nouvel objet Nœud est valide. Par exemple, si vous essayez de créer un Nœud à partir du manifeste JSON suivant :

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes crée un objet Nœud en interne (la représentation). Kubernetes vérifie qu'un kubelet s'est enregistré auprès du serveur API correspondant au champ metadata.name du Nœud. Si le nœud est en bonne santé (c'est-à-dire que tous les services nécessaires sont en cours d'exécution), alors il est éligible pour exécuter un Pod. Sinon, ce nœud est ignoré pour toute activité du cluster jusqu'à ce qu'il redevienne en bonne santé.

Le nom d'un objet Nœud doit être un nom de sous-domaine DNS valide.

Unicité du nom du nœud

Le nom identifie un Nœud. Deux Nœuds ne peuvent pas avoir le même nom en même temps. Kubernetes suppose également qu'une ressource avec le même nom est le même objet. Dans le cas d'un Nœud, on suppose implicitement qu'une instance utilisant le même nom aura le même état (par exemple, les paramètres réseau, le contenu du disque racine) et les mêmes attributs tels que les étiquettes du nœud. Cela peut entraîner des incohérences si une instance a été modifiée sans changer son nom. Si le Nœud doit être remplacé ou mis à jour de manière significative, l'objet Nœud existant doit être supprimé du serveur API en premier lieu, puis ré-ajouté après la mise à jour.

Auto-enregistrement des nœuds

Lorsque le drapeau kubelet --register-node est vrai (par défaut), le kubelet tente de s'enregistrer auprès du serveur API. C'est le modèle préféré, utilisé par la plupart des distributions.

Pour l'auto-enregistrement, le kubelet est démarré avec les options suivantes :

• --kubeconfig - Chemin vers les informations d'identification pour s'authentifier auprès du serveur API.

• --cloud-provider - Comment communiquer avec un fournisseur de cloud pour lire les métadonnées à son sujet.

• --register-node - S'enregistrer automatiquement auprès du serveur API.

• --register-with-taints - Enregistrer le nœud avec la liste donnée de taints (séparées par des virgules <clé>=<valeur>:<effet>).

  Ne fait rien si register-node est faux.

• --node-ip - Liste facultative de adresses IP séparées par des virgules pour le nœud. Vous ne pouvez spécifier qu'une seule adresse pour chaque famille d'adresses. Par exemple, dans un cluster IPv4 à pile unique, vous définissez cette valeur comme l'adresse IPv4 que le kubelet doit utiliser pour le nœud. Consultez configurer une pile double IPv4/IPv6 pour plus de détails sur l'exécution d'un cluster à double pile.

  Si vous ne fournissez pas cet argument, le kubelet utilise l'adresse IPv4 par défaut du nœud, le cas échéant ; si le nœud n'a pas d'adresses IPv4, alors le kubelet utilise l'adresse IPv6 par défaut du nœud.

• --node-labels - Étiquettes à ajouter lors de l'enregistrement du nœud dans le cluster (voir les restrictions d'étiquettes appliquées par le plugin d'admission NodeRestriction).

• --node-status-update-frequency - Spécifie à quelle fréquence le kubelet envoie son état de nœud au serveur API.

Lorsque le mode d'autorisation du nœud et le plugin d'admission NodeRestriction sont activés, les kubelets sont autorisés uniquement à créer/modifier leur propre ressource Nœud.

Administration manuelle des nœuds

Vous pouvez créer et modifier des objets Nœud en utilisant kubectl.

Lorsque vous souhaitez créer manuellement des objets Nœud, définissez le drapeau kubelet --register-node=false.

Vous pouvez modifier des objets Nœud indépendamment du paramètre --register-node. Par exemple, vous pouvez définir des étiquettes sur un Nœud existant ou le marquer comme non planifiable.

Vous pouvez utiliser des étiquettes sur les Nœuds en conjonction avec des sélecteurs de nœuds sur les Pods pour contrôler la planification. Par exemple, vous pouvez restreindre un Pod à s'exécuter uniquement sur un sous-ensemble des nœuds disponibles.

Le marquage d'un nœud comme non planifiable empêche le planificateur de placer de nouveaux pods sur ce Nœud, mais n'affecte pas les Pods existants sur le Nœud. Cela est utile comme étape préparatoire avant un redémarrage du nœud ou une autre opération de maintenance.

Pour marquer un Nœud comme non planifiable, exécutez :

kubectl cordon $NOM_DU_NŒUD

Consultez Évacuation sécurisée d'un nœud pour plus de détails.

État du nœud

L'état d'un Nœud contient les informations suivantes :

• Adresses
• Conditions
• Capacité et Allocatable
• Info

Vous pouvez utiliser kubectl pour afficher l'état d'un Nœud et d'autres détails :

kubectl describe node <insérez-le-nom-du-nœud-ici>

Consultez État du nœud pour plus de détails.

Battements de cœur du nœud

Les battements de cœur, envoyés par les nœuds Kubernetes, aident votre cluster à déterminer la disponibilité de chaque nœud et à prendre des mesures en cas de détection de défaillances.

Pour les nœuds, il existe deux formes de battements de cœur :

• Mises à jour de l'.status d'un Nœud.
• Objets Lease dans le namespace kube-node-lease. Chaque Nœud a un objet Lease associé.

Contrôleur de nœud

Le contrôleur de nœud est un composant du plan de contrôle Kubernetes qui gère différents aspects des nœuds.

Le contrôleur de nœud a plusieurs rôles dans la vie d'un nœud. Le premier est d'attribuer un bloc CIDR au nœud lors de son enregistrement (si l'attribution CIDR est activée).

Le deuxième est de maintenir à jour la liste interne des nœuds du contrôleur de nœud avec la liste des machines disponibles du fournisseur de cloud. Lorsqu'il s'exécute dans un environnement cloud et chaque fois qu'un nœud est en mauvaise santé, le contrôleur de nœud demande au fournisseur de cloud si la VM pour ce nœud est toujours disponible. Si ce n'est pas le cas, le contrôleur de nœud supprime le nœud de sa liste de nœuds.

Le troisième est de surveiller la santé des nœuds. Le contrôleur de nœud est responsable de :

• Dans le cas où un nœud devient injoignable, mettre à jour la condition Ready dans le champ .status du Nœud. Dans ce cas, le contrôleur de nœud définit la condition Ready à Unknown.
• Si un nœud reste injoignable : déclencher l'éviction initiée par l'API pour tous les Pods sur le nœud injoignable. Par défaut, le contrôleur de nœud attend 5 minutes entre le marquage du nœud comme Unknown et la soumission de la première demande d'éviction.

Par défaut, le contrôleur de nœud vérifie l'état de chaque nœud toutes les 5 secondes. Cette période peut être configurée à l'aide du drapeau --node-monitor-period sur le composant kube-controller-manager.

Limites de taux sur l'éviction

Dans la plupart des cas, le contrôleur de nœud limite le taux d'éviction à --node-eviction-rate (par défaut 0,1) par seconde, ce qui signifie qu'il n'évacuera pas les pods de plus d'un nœud toutes les 10 secondes.

Le comportement d'éviction des nœuds change lorsqu'un nœud dans une zone de disponibilité donnée devient en mauvaise santé. Le contrôleur de nœud vérifie quel pourcentage de nœuds dans la zone sont en mauvaise santé (la condition Ready est Unknown ou False) en même temps :

• Si la fraction de nœuds en mauvaise santé est d'au moins --unhealthy-zone-threshold (par défaut 0,55), alors le taux d'éviction est réduit.
• Si le cluster est petit (c'est-à-dire qu'il a moins ou égal à --large-cluster-size-threshold nœuds - par défaut 50), alors les évictions sont arrêtées.
• Sinon, le taux d'éviction est réduit à --secondary-node-eviction-rate (par défaut 0,01) par seconde.

La raison pour laquelle ces politiques sont mises en œuvre par zone de disponibilité est que une zone de disponibilité peut être isolée du plan de contrôle tandis que les autres restent connectées. Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité du fournisseur de cloud, alors le mécanisme d'éviction ne prend pas en compte l'indisponibilité par zone.

Une raison clé de répartir vos nœuds sur plusieurs zones de disponibilité est de permettre le déplacement de la charge de travail vers des zones saines lorsque toute une zone est hors service. Par conséquent, si tous les nœuds d'une zone sont en mauvaise santé, alors le contrôleur de nœud évacue au taux normal de --node-eviction-rate. Le cas particulier est lorsque toutes les zones sont complètement en mauvaise santé (aucun des nœuds du cluster n'est en bonne santé). Dans un tel cas, le contrôleur de nœud suppose qu'il y a un problème de connectivité entre le plan de contrôle et les nœuds, et n'effectue aucune éviction. (S'il y a eu une panne et que certains nœuds réapparaissent, le contrôleur de nœud évacue les pods des nœuds restants qui sont en mauvaise santé ou injoignables).

Le contrôleur de nœud est également responsable de l'éviction des pods s'exécutant sur des nœuds avec des taints NoExecute, sauf si ces pods tolèrent cette taint. Le contrôleur de nœud ajoute également des taints correspondant aux problèmes du nœud, tels que le nœud injoignable ou non prêt. Cela signifie que le planificateur ne placera pas de Pods sur des nœuds en mauvaise santé.

Suivi de la capacité des ressources du nœud

Les objets Nœud suivent des informations sur la capacité des ressources du Nœud : par exemple, la quantité de mémoire disponible et le nombre de CPU. Les nœuds qui s'enregistrent automatiquement rapportent leur capacité lors de l'enregistrement. Si vous les ajoutez manuellement, alors vous devez définir les informations de capacité du nœud lors de son ajout. Les nœuds qui s'enregistrent automatiquement rapportent leur capacité lors de l'enregistrement. Si vous les ajoutez manuellement, alors vous devez définir les informations de capacité du nœud lors de son ajout.

Le planificateur Kubernetes s'assure qu'il y a suffisamment de ressources pour tous les Pods sur un Nœud. Le planificateur vérifie que la somme des demandes des conteneurs sur le nœud n'est pas supérieure à la capacité du nœud. Cette somme de demandes inclut tous les conteneurs gérés par le kubelet, mais exclut tout conteneur démarré directement par le runtime de conteneur, ainsi que tout processus s'exécutant en dehors du contrôle du kubelet.

Topologie du nœud

Si vous avez activé la fonctionnalité TopologyManager feature gate, alors le kubelet peut utiliser des indications de topologie lors de la prise de décision d'attribution des ressources. Consultez la section Contrôler les stratégies de gestion de la topologie sur un nœud pour plus d'informations.

Gestion de la mémoire swap

Pour activer la mémoire swap sur un nœud, la fonctionnalité NodeSwap doit être activée sur le kubelet (par défaut, elle est activée), et le drapeau de ligne de commande --fail-swap-on ou le paramètre de configuration failSwapOn setting doit être défini sur false. Pour permettre aux Pods d'utiliser la mémoire swap, swapBehavior ne doit pas être défini sur NoSwap (qui est le comportement par défaut) dans la configuration du kubelet.

Un utilisateur peut également configurer facultativement memorySwap.swapBehavior afin de spécifier comment un nœud utilisera la mémoire swap. Par exemple,

memorySwap:
  swapBehavior: LimitedSwap

• NoSwap (par défaut) : Les charges de travail Kubernetes n'utiliseront pas la mémoire swap.
• LimitedSwap : L'utilisation de la mémoire swap par les charges de travail Kubernetes est soumise à des limitations. Seuls les Pods de QoS Burstable sont autorisés à utiliser la mémoire swap.

Si la configuration pour memorySwap n'est pas spécifiée et que la fonctionnalité est activée, par défaut, le kubelet appliquera le même comportement que le paramètre NoSwap.

Avec LimitedSwap, les Pods qui ne relèvent pas de la classification QoS Burstable (c'est-à-dire les Pods QoS BestEffort/Guaranteed) sont interdits d'utiliser la mémoire swap. Pour maintenir les garanties de sécurité et de santé du nœud mentionnées ci-dessus, ces Pods ne sont pas autorisés à utiliser la mémoire swap lorsque LimitedSwap est en vigueur.

Avant de détailler le calcul de la limite d'échange, il est nécessaire de définir les termes suivants :

• nodeTotalMemory : La quantité totale de mémoire physique disponible sur le nœud.
• totalPodsSwapAvailable : La quantité totale de mémoire swap sur le nœud disponible pour une utilisation par les Pods (une partie de la mémoire swap peut être réservée à des fins système).
• containerMemoryRequest : La demande de mémoire du conteneur.

La limitation d'échange est configurée comme suit : (containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable.

Il est important de noter que, pour les conteneurs dans les Pods de QoS Burstable, il est possible de désactiver l'utilisation de l'échange en spécifiant des demandes de mémoire égales aux limites de mémoire. Les conteneurs configurés de cette manière n'auront pas accès à la mémoire swap.

L'échange est pris en charge uniquement avec cgroup v2, cgroup v1 n'est pas pris en charge.

Pour plus d'informations, et pour aider aux tests et fournir des commentaires, veuillez consulter l'article de blog sur Kubernetes 1.28 : NodeSwap passe en version Beta1, KEP-2400 et sa proposition de conception.

A suivre

En savoir plus sur les éléments suivants :

• Les composants qui composent un nœud.
• Définition de l'API pour le nœud.
• La section Nœud du document de conception de l'architecture.
• Arrêt du nœud en mode normal ou non normal.
• Mise à l'échelle automatique du cluster pour gérer le nombre et la taille des nœuds de votre cluster.
• Taints et Tolerations.
• Gestion des ressources du nœud.
• Gestion des ressources pour les nœuds Windows.

2.2 - Communication entre les nœuds et le plan de contrôle

Ce document répertorie les chemins de communication entre le serveur API et le cluster Kubernetes. L'objectif est de permettre aux utilisateurs de personnaliser leur installation pour renforcer la configuration réseau afin que le cluster puisse fonctionner sur un réseau non fiable (ou sur des adresses IP publiques complètement) fournies par un fournisseur de cloud.

Nœud vers le plan de contrôle

Kubernetes utilise un modèle d'API de type "hub-et-spoke". Toutes les utilisations de l'API à partir des nœuds (ou des pods qu'ils exécutent) se terminent au niveau du serveur API. Aucun des autres composants du plan de contrôle n'est conçu pour exposer des services distants. Le serveur API est configuré pour écouter les connexions distantes sur un port HTTPS sécurisé (généralement le port 443) avec une ou plusieurs formes d'authentification client activées. Une ou plusieurs formes d'autorisation devraient être activées, en particulier si les requêtes anonymes ou les jetons de compte de service sont autorisés.

Les nœuds doivent être provisionnés avec le certificat racine public pour le cluster afin qu'ils puissent se connecter de manière sécurisée au serveur API avec des informations d'identification client valides. Une bonne approche consiste à ce que les informations d'identification client fournies au kubelet soient sous la forme d'un certificat client. Consultez l'amorçage TLS du kubelet pour la provision automatisée des certificats client du kubelet.

Les pods qui souhaitent se connecter au serveur API peuvent le faire de manière sécurisée en utilisant un compte de service de sorte que Kubernetes injecte automatiquement le certificat racine public et un jeton d'accès valide dans le pod lors de son instanciation. Le service kubernetes (dans le namespace default) est configuré avec une adresse IP virtuelle qui est redirigée (via kube-proxy) vers le point de terminaison HTTPS du serveur API.

Les composants du plan de contrôle communiquent également avec le serveur API via le port sécurisé.

Par conséquent, le mode de fonctionnement par défaut des connexions des nœuds et des pods exécutés sur les nœuds vers le plan de contrôle est sécurisé par défaut et peut fonctionner sur des réseaux non fiables et/ou publics.

Plan de contrôle vers le nœud

Il existe deux chemins de communication principaux du plan de contrôle (le serveur API) vers les nœuds. Le premier est du serveur API au processus kubelet qui s'exécute sur chaque nœud du cluster. Le deuxième est du serveur API vers n'importe quel nœud, pod ou service via la fonctionnalité de proxy du serveur API.

Serveur API vers kubelet

Les connexions du serveur API au kubelet sont utilisées pour :

• Récupérer les journaux des pods.
• Se connecter (généralement via kubectl) aux pods en cours d'exécution.
• Fournir la fonctionnalité de transfert de port du kubelet.

Ces connexions se terminent au niveau du point de terminaison HTTPS du kubelet. Par défaut, le serveur API ne vérifie pas le certificat de service du kubelet, ce qui rend la connexion vulnérable aux attaques de l'homme du milieu et non sécurisée pour une utilisation sur des réseaux non fiables et/ou publics.

Pour vérifier cette connexion, utilisez le paramètre --kubelet-certificate-authority pour fournir au serveur API un ensemble de certificats racine à utiliser pour vérifier le certificat de service du kubelet.

Si cela n'est pas possible, utilisez le tunnel SSH entre le serveur API et le kubelet si nécessaire pour éviter de se connecter via un réseau non fiable ou public.

Enfin, l'authentification et/ou l'autorisation du kubelet devraient être activées pour sécuriser l'API du kubelet.

Serveur API vers les nœuds, les pods et les services

Les connexions du serveur API vers un nœud, un pod ou un service sont par défaut des connexions HTTP non sécurisées et ne sont donc ni authentifiées ni chiffrées. Elles peuvent être exécutées via une connexion HTTPS sécurisée en préfixant https: au nom du nœud, du pod ou du service dans l'URL de l'API, mais elles ne vérifieront pas le certificat fourni par le point de terminaison HTTPS ni ne fourniront des informations d'identification client. Ainsi, bien que la connexion soit chiffrée, elle ne garantira aucune intégrité. Ces connexions ne sont actuellement pas sûres pour une utilisation sur des réseaux non fiables ou publics.

Tunnels SSH

Kubernetes prend en charge les tunnels SSH pour protéger les chemins de communication du plan de contrôle vers les nœuds. Dans cette configuration, le serveur API initie un tunnel SSH vers chaque nœud du cluster (en se connectant à le serveur SSH qui écoute sur le port 22) et fait passer tout le trafic destiné à un kubelet, un nœud, un pod ou un service à travers le tunnel. Ce tunnel garantit que le trafic n'est pas exposé en dehors du réseau dans lequel les nœuds sont exécutés.

Service Konnectivity

En remplacement des tunnels SSH, le service Konnectivity fournit un proxy de niveau TCP pour la communication entre le plan de contrôle et le cluster. Le service Konnectivity se compose de deux parties : le serveur Konnectivity dans le réseau du plan de contrôle et les agents Konnectivity dans le réseau des nœuds. Les agents Konnectivity initient des connexions vers le serveur Konnectivity et maintiennent les connexions réseau. Après avoir activé le service Konnectivity, tout le trafic du plan de contrôle vers les nœuds passe par ces connexions.

Suivez la tâche du service Konnectivity pour configurer le service Konnectivity dans votre cluster.

A suivre

• En savoir plus sur les composants du plan de contrôle Kubernetes
• En savoir plus sur le modèle Hub et Spoke
• Apprenez comment sécuriser un cluster
• En savoir plus sur l'API Kubernetes
• Configurer le service Konnectivity
• Utiliser le transfert de port pour accéder aux applications dans un cluster
• Apprenez comment récupérer les journaux des pods, utiliser kubectl port-forward

2.3 - Contrôleurs

En robotique et automatisation, une boucle de contrôle est une boucle non terminante qui régule l'état d'un système.

Voici un exemple de boucle de contrôle : un thermostat dans une pièce.

Lorsque vous réglez la température, vous indiquez au thermostat votre état souhaité. La température réelle de la pièce est l' état actuel. Le thermostat agit pour rapprocher l'état actuel de l'état souhaité, en allumant ou éteignant l'équipement.

Modèle de contrôleur

Un contrôleur suit au moins un type de ressource Kubernetes. Ces objets ont un champ spec qui représente l'état souhaité. Les contrôleurs de cette ressource sont responsables de rapprocher l'état actuel de cet état souhaité.

Le contrôleur peut effectuer lui-même l'action ; plus couramment, dans Kubernetes, un contrôleur enverra des messages au serveur API qui ont des effets secondaires utiles. Vous verrez des exemples de cela ci-dessous.

Contrôle via le serveur API

Le contrôleur de Job est un exemple de contrôleur intégré à Kubernetes. Les contrôleurs intégrés gèrent l'état en interagissant avec le serveur API du cluster.

Job est une ressource Kubernetes qui exécute un Pod, ou peut-être plusieurs Pods, pour effectuer une tâche, puis s'arrête.

(Une fois planifiés, les objets Pod font partie de l' état souhaité pour un kubelet).

Lorsque le contrôleur de Job voit une nouvelle tâche, il s'assure que, quelque part dans votre cluster, les kubelets sur un ensemble de nœuds exécutent le bon nombre de Pods pour effectuer le travail. Le contrôleur de Job n'exécute aucun Pod ou conteneur lui-même. Au lieu de cela, le contrôleur de Job demande au serveur API de créer ou supprimer des Pods. D'autres composants du plan de contrôle agissent sur les nouvelles informations (il y a de nouveaux Pods à planifier et à exécuter), et finalement le travail est terminé.

Après avoir créé un nouveau Job, l'état souhaité est que ce Job soit terminé. Le contrôleur de Job rapproche l'état actuel de ce Job de votre état souhaité : en créant des Pods qui effectuent le travail que vous avez demandé pour ce Job, de sorte que le Job soit plus proche de l'achèvement.

Les contrôleurs mettent également à jour les objets qui les configurent. Par exemple : une fois le travail terminé pour un Job, le contrôleur de Job met à jour cet objet Job pour le marquer comme Terminé.

(C'est un peu comme certains thermostats éteignent une lumière pour indiquer que votre pièce est maintenant à la température que vous avez réglée).

Contrôle direct

Contrairement à Job, certains contrôleurs doivent apporter des modifications à des éléments en dehors de votre cluster.

Par exemple, si vous utilisez une boucle de contrôle pour vous assurer qu'il y a suffisamment de nœuds dans votre cluster, alors ce contrôleur a besoin de quelque chose en dehors du cluster actuel pour configurer de nouveaux nœuds lorsque cela est nécessaire.

Les contrôleurs qui interagissent avec un état externe trouvent leur état souhaité à partir du serveur API, puis communiquent directement avec un système externe pour rapprocher l'état actuel en ligne.

(Il existe en fait un contrôleur qui met à l'échelle horizontalement les nœuds de votre cluster.)

Le point important ici est que le contrôleur apporte certaines modifications pour atteindre votre état souhaité, puis rapporte l'état actuel à votre serveur API de cluster. D'autres boucles de contrôle peuvent observer ces données rapportées et prendre leurs propres mesures.

Dans l'exemple du thermostat, si la pièce est très froide, un autre contrôleur pourrait également allumer un radiateur de protection contre le gel. Avec les clusters Kubernetes, le plan de contrôle fonctionne indirectement avec des outils de gestion des adresses IP, des services de stockage, des API de fournisseurs de cloud et d'autres services en étendant Kubernetes pour les implémenter.

État souhaité par rapport à l'état actuel

Kubernetes adopte une vision nativement cloud des systèmes et est capable de gérer un changement constant.

Votre cluster peut changer à tout moment à mesure que le travail se déroule et que les boucles de contrôle corrigent automatiquement les défaillances. Cela signifie que, potentiellement, votre cluster n'atteint jamais un état stable.

Tant que les contrôleurs de votre cluster sont en cours d'exécution et capables de effectuer des modifications utiles, il n'importe pas si l'état global est stable ou non.

Conception

En tant que principe de sa conception, Kubernetes utilise de nombreux contrôleurs qui gèrent chacun un aspect particulier de l'état du cluster. Le plus souvent, une boucle de contrôle (contrôleur) utilise un type de ressource comme état souhaité et gère un autre type de ressource pour réaliser cet état souhaité. Par exemple, un contrôleur pour les Jobs suit les objets Job (pour découvrir un nouveau travail) et les objets Pod (pour exécuter les Jobs, puis voir quand le travail est terminé). Dans ce cas, quelque chose d'autre crée les Jobs, tandis que le contrôleur de Job crée les Pods.

Il est utile d'avoir des contrôleurs simples plutôt qu'un ensemble monolithique de boucles de contrôle interconnectées. Les contrôleurs peuvent échouer, c'est pourquoi Kubernetes est conçu pour le permettre.

Modes d'exécution des contrôleurs

Kubernetes est livré avec un ensemble de contrôleurs intégrés qui s'exécutent à l'intérieur du kube-controller-manager. Ces contrôleurs intégrés fournissent des comportements de base importants.

Le contrôleur de Déploiement et le contrôleur de Job sont des exemples de contrôleurs qui font partie de Kubernetes lui-même (contrôleurs "intégrés"). Kubernetes vous permet d'exécuter un plan de contrôle résilient, de sorte que si l'un des contrôleurs intégrés venait à échouer, une autre partie du plan de contrôle prendra en charge le travail.

Vous pouvez trouver des contrôleurs qui s'exécutent en dehors du plan de contrôle pour étendre Kubernetes. Ou, si vous le souhaitez, vous pouvez écrire vous-même un nouveau contrôleur. Vous pouvez exécuter votre propre contrôleur sous la forme d'un ensemble de Pods, ou en dehors de Kubernetes. Ce qui convient le mieux dépendra de ce que ce contrôleur particulier fait.

A suivre

• Lisez à propos du plan de contrôle Kubernetes
• Découvrez certains des objets Kubernetes de base
• En savoir plus sur l'API Kubernetes
• Si vous souhaitez écrire votre propre contrôleur, consultez les modèles d'extension Kubernetes et le référentiel sample-controller.

2.4 - Lease

Les systèmes distribués ont souvent besoin de Lease, qui fournissent un mécanisme pour verrouiller les ressources partagées et coordonner l'activité entre les membres d'un ensemble. Dans Kubernetes, le concept de bail est représenté par les objets Lease dans le groupe d'API coordination.k8s.io Groupe d'API, qui sont utilisés pour des fonctionnalités critiques du système telles que les battements de cœur des nœuds et l'élection du leader au niveau des composants.

Battements de cœur des nœuds

Kubernetes utilise l'API Lease pour communiquer les battements de cœur des nœuds kubelet au serveur API Kubernetes. Pour chaque Node, il existe un objet Lease avec un nom correspondant dans le namespace kube-node-lease. Sous le capot, chaque battement de cœur kubelet est une demande de mise à jour de cet objet Lease, mettant à jour le champ spec.renewTime pour le bail. Le plan de contrôle Kubernetes utilise le horodatage de ce champ pour déterminer la disponibilité de ce Node.

Consultez Objets de bail de nœud pour plus de détails.

Élection du leader

Kubernetes utilise également des Lease pour s'assurer qu'une seule instance d'un composant est en cours d'exécution à tout moment. Cela est utilisé par les composants du plan de contrôle tels que kube-controller-manager et kube-scheduler dans les configurations HA, où une seule instance du composant doit être en cours d'exécution activement tandis que les autres instances sont en attente.

Lisez élection coordonnée du leader pour en savoir plus sur la façon dont Kubernetes s'appuie sur l'API Lease pour sélectionner quelle instance de composant agit en tant que leader.

Identité du serveur API

À partir de Kubernetes v1.26, chaque kube-apiserver utilise l'API Lease pour publier son identité au reste du système. Bien que cela ne soit pas particulièrement utile en soi, cela fournit un mécanisme pour les clients afin de découvrir combien d'instances de kube-apiserver opèrent sur le plan de contrôle Kubernetes. L'existence des Lease kube-apiserver permet des fonctionnalités futures qui peuvent nécessiter une coordination entre chaque kube-apiserver.

Vous pouvez inspecter les Lease détenus par chaque kube-apiserver en vérifiant les objets de bail dans le namespace kube-system avec le nom kube-apiserver-<sha256-hash>. Alternativement, vous pouvez utiliser le sélecteur d'étiquettes apiserver.kubernetes.io/identity=kube-apiserver:

kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver

NOM                                         HOLDER                                                                           ÂGE
apiserver-07a5ea9b9b072c4a5f3d1c3702        apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05        5m33s
apiserver-7be9e061c59d368b3ddaf1376e        apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f        4m23s
apiserver-1dfef752bcb36637d2763d1868        apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e        4m43s

Le hachage SHA256 utilisé dans le nom du bail est basé sur le nom d'hôte du système d'exploitation tel que vu par ce serveur API. Chaque kube-apiserver devrait être configuré pour utiliser un nom d'hôte qui est unique dans le cluster. Les nouvelles instances de kube-apiserver qui utilisent le même nom d'hôte prendront le contrôle des Lease existants en utilisant une nouvelle identité de détenteur, au lieu d'instancier de nouveaux objets de bail. Vous pouvez vérifier le nom d'hôte utilisé par kube-apisever en vérifiant la valeur de l'étiquette kubernetes.io/hostname:

kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  creationTimestamp: "2023-07-02T13:16:48Z"
  labels:
    apiserver.kubernetes.io/identity: kube-apiserver
    kubernetes.io/hostname: master-1
  name: apiserver-07a5ea9b9b072c4a5f3d1c3702
  namespace: kube-system
  resourceVersion: "334899"
  uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1
spec:
  holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05
  leaseDurationSeconds: 3600
  renewTime: "2023-07-04T21:58:48.065888Z"

Les Lease expirés des kube-apiservers qui n'existent plus sont collectés par les nouveaux kube-apiservers après 1 heure.

Vous pouvez désactiver les Lease d'identité du serveur API en désactivant la fonctionnalité APIServerIdentity feature gate.

Charges de travail

Votre propre charge de travail peut définir son propre usage des Lease. Par exemple, vous pouvez exécuter un contrôleur personnalisé où un membre principal ou leader effectue des opérations que ses pairs ne font pas. Vous définissez un bail afin que les réplicas du contrôleur puissent sélectionner ou élire un leader, en utilisant l'API Kubernetes pour la coordination. Si vous utilisez un bail, il est bon de pratiquer de définir un nom pour le bail qui est clairement lié au produit ou au composant. Par exemple, si vous avez un composant nommé Example Foo, utilisez un bail nommé example-foo.

Si un opérateur de cluster ou un autre utilisateur final peut déployer plusieurs instances d'un composant, sélectionnez un préfixe de nom et choisissez un mécanisme (comme le hachage du nom du déploiement) pour éviter les collisions de noms pour les Lease.

Vous pouvez utiliser une autre approche tant qu'elle atteint le même résultat : les différents produits logiciels ne entrent pas en conflit les uns avec les autres.

2.5 - Gestionnaire du contrôleur de cloud

Les technologies d'infrastructure cloud vous permettent d'exécuter Kubernetes sur des clouds publics, privés et hybrides. Kubernetes croit en une infrastructure automatisée pilotée par API sans couplage étroit entre les composants.

Le gestionnaire du contrôleur de cloud est le Cloud Controller Manager est une fonctionnalité alpha de la version 1.8. Dans les prochaines versions, il deviendra le moyen privilégié pour l'intégration de Kubernetes à n'importe quel cloud.

Kubernetes v1.6 contient un nouveau binaire appelé cloud-controller-manager. Le cloud-controller-manager est un service qui intègre des boucles de contrôle propres au cloud. Ces boucles de contrôle spécifiques au cloud se trouvaient à l'origine dans le kube-controller-manager. Étant donné que les fournisseurs de cloud développent et mettent à jour leurs produits à un rythme différent de celui du projet Kubernetes, l'abstraction du code spécifique au fournisseur, au niveau du binaire cloud-controller-manager, permet aux fournisseurs de cloud d'évoluer indépendamment du code principal de Kubernetes.

Le gestionnaire du contrôleur de cloud est structuré à l'aide d'un mécanisme de plugin qui permet aux différents fournisseurs de cloud d'intégrer leurs plateformes à Kubernetes.

Conception

Le gestionnaire du contrôleur de cloud s'exécute dans le plan de contrôle en tant qu'ensemble répliqué de processus (généralement, ce sont des conteneurs dans des Pods). Chaque gestionnaire du contrôleur de cloud implémente plusieurs contrôleurs dans un seul processus.

Fonctions du gestionnaire du contrôleur de cloud

Les contrôleurs à l'intérieur du gestionnaire du contrôleur de cloud comprennent :

Contrôleur de nœud

Le contrôleur de nœud est responsable de la mise à jour des objets Nœud lorsque de nouveaux serveurs sont créés dans votre infrastructure cloud. Le contrôleur de nœud obtient des informations sur les hôtes en cours d'exécution dans votre tenancy avec le fournisseur de cloud. Le contrôleur de nœud effectue les fonctions suivantes :

1. Mettre à jour un objet Nœud avec l'identifiant unique du serveur obtenu à partir de l'API du fournisseur de cloud.
2. Annoter et étiqueter l'objet Nœud avec des informations spécifiques au cloud, telles que la région dans laquelle le nœud est déployé et les ressources (CPU, mémoire, etc.) dont il dispose.
3. Obtenir le nom d'hôte et les adresses réseau du nœud.
4. Vérifier la santé du nœud. Si un nœud devient non réactif, ce contrôleur vérifie auprès de l'API de votre fournisseur de cloud si le serveur a été désactivé / supprimé / terminé. Si le nœud a été supprimé du cloud, le contrôleur supprime l'objet Nœud de votre cluster Kubernetes.

Certaines implémentations de fournisseurs de cloud divisent cela en un contrôleur de nœud et un contrôleur de cycle de vie de nœud distinct.

Contrôleur de route

Le contrôleur de route est responsable de la configuration des routes dans le cloud de manière appropriée afin que les conteneurs sur différents nœuds de votre cluster Kubernetes puissent communiquer entre eux.

Selon le fournisseur de cloud, le contrôleur de route peut également allouer des blocs d'adresses IP pour le réseau de Pod.

Contrôleur de service

Les services s'intègrent aux composants d'infrastructure cloud tels que les équilibreurs de charge gérés, les adresses IP, le filtrage des paquets réseau et la vérification de l'état de la cible. Le contrôleur de service interagit avec les API de votre fournisseur de cloud pour configurer les équilibreurs de charge et autres composants d'infrastructure lorsque vous déclarez une ressource Service qui les nécessite.

Autorisation

Cette section détaille l'accès requis par le gestionnaire du contrôleur de cloud sur divers objets API pour effectuer ses opérations.

Contrôleur de nœud

Le contrôleur de nœud ne fonctionne qu'avec les objets Nœud. Il nécessite un accès complet pour lire et modifier les objets Nœud.

v1/Node :

• get
• list
• create
• update
• patch
• watch
• delete

Contrôleur de route

Le contrôleur de route écoute la création d'objets Nœud et configure les routes de manière appropriée. Il nécessite un accès Get aux objets Nœud.

v1/Node :

• get

Contrôleur de service

Le contrôleur de service surveille les événements de création, de mise à jour et de suppression des objets Service, puis configure les Endpoints pour ces Services de manière appropriée (pour les EndpointSlices, le kube-controller-manager les gère à la demande).

Pour accéder aux Services, il nécessite un accès list et watch. Pour mettre à jour les Services, il nécessite un accès patch et update.

Pour configurer les ressources Endpoints pour les Services, il nécessite un accès create, list, get, watch et update.

v1/Service :

• list
• get
• watch
• patch
• update

Autres

La mise en œuvre du cœur du gestionnaire du contrôleur de cloud nécessite un accès pour créer des objets Event et pour assurer un fonctionnement sécurisé, il nécessite un accès pour créer des comptes de service.

v1/Event :

• create
• patch
• update

v1/ServiceAccount :

• create

Le ClusterRole RBAC pour le gestionnaire du contrôleur de cloud ressemble à ceci :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - get
  - list
  - watch
  - update

A suivre

• Administration du gestionnaire du contrôleur de cloud contient des instructions sur l'exécution et la gestion du gestionnaire du contrôleur de cloud.

• Pour mettre à niveau un plan de contrôle haute disponibilité pour utiliser le gestionnaire du contrôleur de cloud, consultez Migrer le plan de contrôle répliqué pour utiliser le gestionnaire du contrôleur de cloud.

• Vous voulez savoir comment implémenter votre propre gestionnaire du contrôleur de cloud ou étendre un projet existant ?

  • Le gestionnaire du contrôleur de cloud utilise des interfaces Go, en particulier, l'interface CloudProvider définie dans cloud.go de kubernetes/cloud-provider pour permettre l'intégration de toutes les implémentations de cloud.
  • La mise en œuvre des contrôleurs partagés mis en évidence dans ce document (Nœud, Route et Service), ainsi que certaines structures de base avec l'interface cloudprovider partagée, font partie du cœur de Kubernetes. Les implémentations spécifiques aux fournisseurs de cloud se trouvent en dehors du cœur de Kubernetes et implémentent l'interface CloudProvider.
  • Pour plus d'informations sur le développement de plugins, consultez Développement du gestionnaire du contrôleur de cloud.

2.6 - À propos de cgroup v2

Sur Linux, les groupes de contrôle limitent les ressources allouées aux processus.

Le kubelet et le runtime de conteneur sous-jacent doivent interagir avec les cgroups pour appliquer la gestion des ressources pour les pods et les conteneurs, ce qui inclut les demandes et les limites de CPU/mémoire pour les charges de travail conteneurisées.

Il existe deux versions de cgroups sur Linux : cgroup v1 et cgroup v2. cgroup v2 est la nouvelle génération de l'API cgroup.

Qu'est-ce que cgroup v2 ?

cgroup v2 est la prochaine version de l'API cgroup de Linux. cgroup v2 offre un système de contrôle unifié avec des capacités de gestion des ressources améliorées.

cgroup v2 propose plusieurs améliorations par rapport à cgroup v1, telles que :

• Conception d'une hiérarchie unifiée unique dans l'API
• Délégation plus sûre des sous-arbres aux conteneurs
• Nouvelles fonctionnalités telles que Pressure Stall Information
• Gestion améliorée de l'allocation des ressources et de l'isolation sur plusieurs ressources
  • Comptabilité unifiée pour différents types d'allocations de mémoire (mémoire réseau, mémoire du noyau, etc.)
  • Comptabilité des modifications de ressources non immédiates, telles que les écritures de cache de pages

Certaines fonctionnalités de Kubernetes utilisent exclusivement cgroup v2 pour une gestion des ressources et une isolation améliorées. Par exemple, la fonctionnalité MemoryQoS améliore la QoS de la mémoire et repose sur les primitives cgroup v2.

Utilisation de cgroup v2

La manière recommandée d'utiliser cgroup v2 est d'utiliser une distribution Linux qui active et utilise cgroup v2 par défaut.

Pour vérifier si votre distribution utilise cgroup v2, consultez Identifier la version de cgroup sur les nœuds Linux.

Exigences

cgroup v2 a les exigences suivantes :

• La distribution OS active cgroup v2
• La version du noyau Linux est 5.8 ou ultérieure
• Le runtime de conteneur prend en charge cgroup v2. Par exemple :
  • containerd v1.4 et ultérieur
  • cri-o v1.20 et ultérieur
• Le kubelet et le runtime de conteneur sont configurés pour utiliser le driver cgroup systemd

Prise en charge de cgroup v2 par les distributions Linux

Pour une liste des distributions Linux qui utilisent cgroup v2, consultez la documentation cgroup v2

• Container Optimized OS (depuis M97)
• Ubuntu (depuis 21.10, 22.04+ recommandé)
• Debian GNU/Linux (depuis Debian 11 bullseye)
• Fedora (depuis 31)
• Arch Linux (depuis avril 2021)
• RHEL et les distributions similaires à RHEL (depuis 9)

Pour vérifier si votre distribution utilise cgroup v2, consultez la documentation de votre distribution ou suivez les instructions de Identifier la version de cgroup sur les nœuds Linux.

Vous pouvez également activer manuellement cgroup v2 sur votre distribution Linux en modifiant les arguments de démarrage de la ligne de commande du noyau. Si votre distribution utilise GRUB, systemd.unified_cgroup_hierarchy=1 doit être ajouté dans GRUB_CMDLINE_LINUX sous /etc/default/grub, suivi de sudo update-grub. Cependant, l'approche recommandée est d'utiliser une distribution qui active déjà cgroup v2 par défaut.

Migration vers cgroup v2

Pour migrer vers cgroup v2, assurez-vous de respecter les exigences, puis mettez à jour vers une version du noyau qui active cgroup v2 par défaut.

Le kubelet détecte automatiquement si le système d'exploitation utilise cgroup v2 et agit en conséquence, sans nécessiter de configuration supplémentaire.

Il ne devrait pas y avoir de différence perceptible dans l'expérience utilisateur lors du passage à cgroup v2, sauf si les utilisateurs accèdent directement au système de fichiers cgroup soit sur le nœud, soit depuis les conteneurs.

cgroup v2 utilise une API différente de cgroup v1, donc si des applications accèdent directement au système de fichiers cgroup, elles doivent être mises à jour vers des versions plus récentes qui prennent en charge cgroup v2. Par exemple :

• Certains agents de surveillance et de sécurité tiers peuvent dépendre du système de fichiers cgroup. Mettez à jour ces agents vers des versions qui prennent en charge cgroup v2.
• Si vous exécutez cAdvisor en tant que DaemonSet autonome pour surveiller les pods et les conteneurs, mettez-le à jour vers la version 0.43.0 ou ultérieure.
• Si vous déployez des applications Java, préférez utiliser des versions qui prennent en charge pleinement cgroup v2 :
  • OpenJDK / HotSpot : jdk8u372, 11.0.16, 15 et ultérieures
  • IBM Semeru Runtimes : 8.0.382.0, 11.0.20.0, 17.0.8.0 et ultérieures
  • IBM Java : 8.0.8.6 et ultérieures
• Si vous utilisez le package uber-go/automaxprocs, assurez-vous d'utiliser la version v1.5.1 ou supérieure.

Identifier la version de cgroup sur les nœuds Linux

La version de cgroup dépend de la distribution Linux utilisée et de la version de cgroup par défaut configurée sur le système d'exploitation. Pour vérifier quelle version de cgroup votre distribution utilise, exécutez la commande stat -fc %T /sys/fs/cgroup/ sur le nœud :

stat -fc %T /sys/fs/cgroup/

Pour cgroup v2, la sortie est cgroup2fs.

Pour cgroup v1, la sortie est tmpfs.

A suivre

• En savoir plus sur cgroups
• En savoir plus sur le runtime de conteneur
• En savoir plus sur les drivers cgroup

2.7 - Interface de Runtime de Conteneur (CRI)

Le CRI (Container Runtime Interface) est une interface de plugin qui permet au kubelet d'utiliser une grande variété de runtimes de conteneurs, sans avoir besoin de recompiler les composants du cluster.

Vous avez besoin d'un runtime de conteneur fonctionnel sur chaque nœud de votre cluster, afin que le kubelet puisse lancer Pods et leurs conteneurs.

L'Interface de Runtime de Conteneur (CRI) est le protocole principal pour la communication entre le kubelet et le Runtime de Conteneur.

L'Interface du Runtime de Conteneur (CRI) de Kubernetes définit le protocole principal gRPC pour la communication entre les composants du nœud kubelet et le runtime de conteneur.

L'API

Le kubelet agit en tant que client lorsqu'il se connecte au runtime de conteneur via gRPC. Les points de terminaison du service de runtime et d'image doivent être disponibles dans le runtime de conteneur, ce qui peut être configuré séparément dans le kubelet en utilisant les indicateurs de ligne de commande --image-service-endpoint (voir la référence des options du kubelet).

Pour Kubernetes v1.31, le kubelet préfère utiliser CRI v1. Si un runtime de conteneur ne prend pas en charge v1 de CRI, alors le kubelet essaie de négocier toute version plus ancienne prise en charge. Le kubelet de v1.31 peut également négocier CRI v1alpha2, mais cette version est considérée comme obsolète. Si le kubelet ne peut pas négocier une version de CRI prise en charge, le kubelet abandonne et ne s'enregistre pas en tant que nœud.

Mise à niveau

Lors de la mise à niveau de Kubernetes, le kubelet essaie de sélectionner automatiquement la dernière version de CRI lors du redémarrage du composant. Si cela échoue, alors le fallback aura lieu comme mentionné ci-dessus. Si une nouvelle connexion gRPC était nécessaire car le runtime de conteneur a été mis à niveau, alors le runtime de conteneur doit également prendre en charge la version initialement sélectionnée, sinon la reconnexion est censée échouer. Cela nécessite un redémarrage du kubelet.

A suivre

• En savoir plus sur la définition du protocole CRI ici

2.8 - Collecte des déchets

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. Cela permet le nettoyage des ressources suivantes :

• Pods terminés
• Jobs terminés
• Objets sans références de propriétaire
• Conteneurs et images inutilisés
• PersistentVolumes provisionnés dynamiquement avec une politique de récupération de classe de stockage Delete
• CertificateSigningRequests (CSRs) obsolètes ou expirés
• Nodes supprimés dans les scénarios suivants :
  • Sur un cloud lorsque le cluster utilise un gestionnaire de contrôleur cloud
  • Sur site lorsque le cluster utilise un addon similaire à un gestionnaire de cloud
• Objets de bail de nœud

Propriétaires et dépendants

De nombreux objets dans Kubernetes sont liés les uns aux autres par le biais de références de propriétaire. Les références de propriétaire indiquent au plan de contrôle quels objets dépendent des autres. Kubernetes utilise les références de propriétaire pour permettre au plan de contrôle et aux autres clients de l'API de nettoyer les ressources associées avant de supprimer un objet. Dans la plupart des cas, Kubernetes gère automatiquement les références de propriétaire.

La propriété est différente du mécanisme étiquettes et sélecteurs que certains ressources utilisent également. Par exemple, considérez un Service qui crée des objets EndpointSlice. Le Service utilise des étiquettes pour permettre au plan de contrôle de déterminer quels objets EndpointSlice sont utilisés pour ce Service. En plus des étiquettes, chaque EndpointSlice géré au nom d'un Service a une référence de propriétaire. Les références de propriétaire aident les différentes parties de Kubernetes à éviter d'interférer avec les objets qu'elles ne contrôlent pas.

Suppression en cascade

Kubernetes vérifie et supprime les objets qui n'ont plus de références de propriétaire, comme les pods laissés derrière lors de la suppression d'un ReplicaSet. Lorsque vous supprimez un objet, vous pouvez contrôler si Kubernetes supprime automatiquement les objets dépendants, dans un processus appelé suppression en cascade. Il existe deux types de suppression en cascade, comme suit :

• Suppression en cascade en premier plan
• Suppression en cascade en arrière-plan

Vous pouvez également contrôler comment et quand la collecte des déchets supprime les ressources qui ont des références de propriétaire en utilisant les finalizers Kubernetes.

Suppression en cascade en premier plan

Dans la suppression en cascade en premier plan, l'objet propriétaire que vous supprimez entre d'abord dans un état de suppression en cours. Dans cet état, les actions suivantes se produisent sur l'objet propriétaire :

• Le serveur API Kubernetes définit le champ metadata.deletionTimestamp de l'objet sur l'heure à laquelle l'objet a été marqué pour suppression.
• Le serveur API Kubernetes définit également le champ metadata.finalizers sur foregroundDeletion.
• L'objet reste visible via l'API Kubernetes jusqu'à ce que le processus de suppression soit terminé.

Après que l'objet propriétaire entre dans l'état de suppression en cours, le contrôleur supprime les dépendants. Après avoir supprimé tous les objets dépendants, le contrôleur supprime l'objet propriétaire. À ce stade, l'objet n'est plus visible dans l'API Kubernetes.

Pendant la suppression en cascade en premier plan, seuls les dépendants qui bloquent la suppression du propriétaire sont ceux qui ont le champ ownerReference.blockOwnerDeletion=true. Consultez Utiliser la suppression en cascade en premier plan pour en savoir plus.

Suppression en cascade en arrière-plan

Dans la suppression en cascade en arrière-plan, le serveur API Kubernetes supprime immédiatement l'objet propriétaire et le contrôleur nettoie les objets dépendants en arrière-plan. Par défaut, Kubernetes utilise la suppression en cascade en arrière-plan, sauf si vous utilisez manuellement la suppression en premier plan ou choisissez d'abandonner les objets dépendants.

Consultez Utiliser la suppression en cascade en arrière-plan pour en savoir plus.

Dépendants orphelins

Lorsque Kubernetes supprime un objet propriétaire, les dépendants laissés derrière sont appelés objets orphelins. Par défaut, Kubernetes supprime les objets dépendants. Pour apprendre comment outrepasser ce comportement, consultez Supprimer les objets propriétaires et les dépendants orphelins.

Collecte des déchets des conteneurs et des images inutilisés

Le kubelet effectue la collecte des déchets sur les images inutilisées toutes les deux minutes et sur les conteneurs inutilisés toutes les minutes. Vous devez éviter d'utiliser des outils de collecte des déchets externes, car ils peuvent perturber le comportement du kubelet et supprimer des conteneurs qui devraient exister.

Pour configurer les options de collecte des déchets des conteneurs et des images inutilisés, ajustez le kubelet en utilisant un fichier de configuration et modifiez les paramètres liés à la collecte des déchets en utilisant le type de ressource KubeletConfiguration.

Cycle de vie des images de conteneur

Kubernetes gère le cycle de vie de toutes les images via son gestionnaire d'images, qui fait partie du kubelet, en collaboration avec cadvisor. Le kubelet prend en compte les limites d'utilisation du disque suivantes lors de la prise de décision de collecte des déchets :

• HighThresholdPercent
• LowThresholdPercent

Une utilisation du disque supérieure à la valeur configurée de HighThresholdPercent déclenche la collecte des déchets, qui supprime les images dans l'ordre en fonction de leur dernière utilisation, en commençant par les plus anciennes en premier. Le kubelet supprime les images jusqu'à ce que l'utilisation du disque atteigne la valeur LowThresholdPercent.

Collecte des déchets pour les images de conteneur inutilisées

En tant que fonctionnalité bêta, vous pouvez spécifier la durée maximale pendant laquelle une image locale peut rester inutilisée, indépendamment de l'utilisation du disque. Il s'agit d'un paramètre du kubelet que vous configurez pour chaque nœud.

Pour configurer le paramètre, activez la fonctionnalité ImageMaximumGCAge feature gate pour le kubelet, et définissez également une valeur pour le champ imageMaximumGCAge dans le fichier de configuration du kubelet.

La valeur est spécifiée en tant que durée Kubernetes ; Les unités de temps valides pour le champ imageMaximumGCAge dans le fichier de configuration du kubelet sont :

• "ns" pour les nanosecondes
• "us" ou "µs" pour les microsecondes
• "ms" pour les millisecondes
• "s" pour les secondes
• "m" pour les minutes
• "h" pour les heures

Par exemple, vous pouvez définir le champ de configuration sur 12h45m, ce qui signifie 12 heures et 45 minutes.

Collecte des déchets des conteneurs

Le kubelet collecte les conteneurs inutilisés en fonction des variables suivantes, que vous pouvez définir :

• MinAge : l'âge minimum auquel le kubelet peut collecter les conteneurs. Désactivez en définissant sur 0.
• MaxPerPodContainer : le nombre maximum de conteneurs inactifs que chaque Pod peut avoir. Désactivez en définissant sur une valeur inférieure à 0.
• MaxContainers : le nombre maximum de conteneurs inactifs que le cluster peut avoir. Désactivez en définissant sur une valeur inférieure à 0.

En plus de ces variables, le kubelet collecte les conteneurs non identifiés et supprimés, généralement en commençant par les plus anciens.

MaxPerPodContainer et MaxContainers peuvent potentiellement entrer en conflit les uns avec les autres dans des situations où le maintien du nombre maximum de conteneurs par Pod (MaxPerPodContainer) dépasserait le total autorisé de conteneurs inactifs globaux (MaxContainers). Dans cette situation, le kubelet ajuste MaxPerPodContainer pour résoudre le conflit. Le pire des cas serait de réduire MaxPerPodContainer à 1 et d'évacuer les conteneurs les plus anciens. De plus, les conteneurs appartenant à des pods qui ont été supprimés sont supprimés une fois qu'ils sont plus anciens que MinAge.

Configuration de la collecte des déchets

Vous pouvez ajuster la collecte des déchets des ressources en configurant des options spécifiques aux contrôleurs qui gèrent ces ressources. Les pages suivantes vous montrent comment configurer la collecte des déchets :

• Configuration de la suppression en cascade des objets Kubernetes
• Configuration du nettoyage des Jobs terminés

A suivre

• En savoir plus sur la propriété des objets Kubernetes.
• En savoir plus sur les finalizers Kubernetes.
• Découvrez le contrôleur TTL qui nettoie les Jobs terminés.

2.9 - Proxy de version mixte

Kubernetes 1.31 inclut une fonctionnalité alpha qui permet à un Serveur API de faire proxy des demandes de ressources vers d'autres serveurs API pairs. Cela est utile lorsqu'il y a plusieurs serveurs API exécutant différentes versions de Kubernetes dans un même cluster (par exemple, pendant un déploiement à long terme vers une nouvelle version de Kubernetes).

Cela permet aux administrateurs de cluster de configurer des clusters hautement disponibles qui peuvent être mis à niveau plus en toute sécurité, en redirigeant les demandes de ressources (effectuées pendant la mise à niveau) vers le kube-apiserver correct. Ce proxy empêche les utilisateurs de voir des erreurs 404 Not Found inattendues qui découlent du processus de mise à niveau.

Ce mécanisme est appelé le Proxy de Version Mixte.

Activation du Proxy de Version Mixte

Assurez-vous que la fonctionnalité UnknownVersionInteroperabilityProxy feature gate est activée lorsque vous démarrez le Serveur API :

kube-apiserver \
--feature-gates=UnknownVersionInteroperabilityProxy=true \
# arguments de ligne de commande requis pour cette fonctionnalité
--peer-ca-file=<chemin vers le certificat CA de kube-apiserver>
--proxy-client-cert-file=<chemin vers le certificat proxy de l'agrégateur>,
--proxy-client-key-file=<chemin vers la clé proxy de l'agrégateur>,
--requestheader-client-ca-file=<chemin vers le certificat CA de l'agrégateur>,
# requestheader-allowed-names peut être laissé vide pour autoriser n'importe quel nom commun
--requestheader-allowed-names=<noms communs valides pour vérifier le certificat client du proxy>,

# indicateurs facultatifs pour cette fonctionnalité
--peer-advertise-ip=`IP de ce kube-apiserver qui doit être utilisée par les pairs pour faire proxy des demandes`
--peer-advertise-port=`port de ce kube-apiserver qui doit être utilisé par les pairs pour faire proxy des demandes`

# ...et d'autres indicateurs comme d'habitude

Transport et authentification du proxy entre les serveurs API

• Le kube-apiserver source réutilise les indicateurs d'authentification client du serveur API existant --proxy-client-cert-file et --proxy-client-key-file pour présenter son identité qui sera vérifiée par son pair (le kube-apiserver de destination). Le serveur API de destination vérifie cette connexion pair en fonction de la configuration que vous spécifiez en utilisant l'argument de ligne de commande --requestheader-client-ca-file.

• Pour authentifier les certificats de service du serveur de destination, vous devez configurer un ensemble de certificats d'autorité de certification en spécifiant l'argument de ligne de commande --peer-ca-file au serveur API source.

Configuration pour la connectivité des serveurs API pairs

Pour définir l'emplacement réseau d'un kube-apiserver que les pairs utiliseront pour faire proxy des demandes, utilisez les arguments de ligne de commande --peer-advertise-ip et --peer-advertise-port pour kube-apiserver ou spécifiez ces champs dans le fichier de configuration du serveur API. Si ces indicateurs ne sont pas spécifiés, les pairs utiliseront la valeur de --advertise-address ou --bind-address comme argument de ligne de commande pour le kube-apiserver. Si ceux-ci ne sont pas définis non plus, l'interface par défaut de l'hôte est utilisée.

Proxy de version mixte

Lorsque vous activez le proxy de version mixte, la couche d'agrégation charge un filtre spécial qui effectue les opérations suivantes :

• Lorsqu'une demande de ressource atteint un serveur API qui ne peut pas servir cette API (soit parce qu'il s'agit d'une version antérieure à l'introduction de l'API, soit parce que l'API est désactivée sur le serveur API), le serveur API tente d'envoyer la demande à un serveur API pair qui peut servir l'API demandée. Il le fait en identifiant les groupes d'API / versions / ressources que le serveur local ne reconnaît pas, et essaie de faire proxy de ces demandes vers un serveur API pair capable de traiter la demande.
• Si le serveur API pair ne parvient pas à répondre, le serveur API source répond avec une erreur 503 ("Service Unavailable").

Comment cela fonctionne en interne

Lorsqu'un serveur API reçoit une demande de ressource, il vérifie d'abord quels serveurs API peuvent servir la ressource demandée. Cette vérification se fait en utilisant l'API interne StorageVersion.

• Si la ressource est connue du serveur API qui a reçu la demande (par exemple, GET /api/v1/pods/quelque-pod), la demande est traitée localement.

• S'il n'y a pas d'objet StorageVersion interne trouvé pour la ressource demandée (par exemple, GET /my-api/v1/my-resource) et que l'APIService configuré spécifie le proxy vers un serveur API d'extension, ce proxy se fait en suivant le flux habituel flow pour les API d'extension.

• Si un objet StorageVersion interne valide est trouvé pour la ressource demandée (par exemple, GET /batch/v1/jobs) et que le serveur API qui essaie de traiter la demande (le serveur API de traitement) a l'API batch désactivée, alors le serveur API de traitement récupère les serveurs API pairs qui servent le groupe d'API / version / ressource pertinent (api/v1/batch dans ce cas) en utilisant les informations de l'objet StorageVersion récupéré. Le serveur API de traitement fait ensuite proxy de la demande vers l'un des serveurs kube-apiservers pairs correspondants qui sont conscients de la ressource demandée.

  • S'il n'y a aucun pair connu pour ce groupe d'API / version / ressource, le serveur API de traitement transmet la demande à sa propre chaîne de traitement qui devrait finalement renvoyer une réponse 404 ("Not Found").

  • Si le serveur API de traitement a identifié et sélectionné un serveur API pair, mais que ce pair échoue à répondre (pour des raisons telles que des problèmes de connectivité réseau ou une course de données entre la demande étant reçue et un contrôleur enregistrant les informations du pair dans le plan de contrôle), alors le serveur de traitement API répond avec une erreur 503 ("Service Unavailable").

3 - Les conteneurs

3.1 - Images

Vous créez une image Docker et la poussez dans un registre avant de la référencer depuis un pod Kubernetes.

La propriété image d'un conteneur utilise la même syntaxe que la commande docker, y compris pour les registres privés et les tags.

Mettre à jour des images

La politique de récupération par défaut est IfNotPresent, Kubelet ne récupère alors pas une image si elle est déjà présente sur le nœud. Si vous voulez forcer une récupération à chaque fois, vous pouvez faire une des actions suivantes :

• définissez imagePullPolicy du conteneur à Always.
• omettez imagePullPolicy et utilisez :latest comme tag pour l'image à utiliser.
• omettez imagePullPolicy et le tag de l'image à utiliser.
• activez l'admission controller AlwaysPullImages.

Notez que vous devez éviter d'utiliser le tag :latest, voir Bonnes pratiques pour la configuration pour plus d'informations.

Créer des images multi-architecture à partir de manifestes

La CLI Docker prend maintenant en charge la commande docker manifest avec des sous-commandes comme create, annotate et push. Ces commandes peuvent être utilisées pour construire et pousser les manifestes. Vous pouvez utiliser docker manifest inspect pour voir le manifeste.

Vous pouvez voir la documentation Docker ici : https://docs.docker.com/edge/engine/reference/commandline/manifest/

Voici comment nous l'utilisons dans notre outil de build: https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=

Ces commandes se basent et sont implémentées purement sur la CLI Docker. Vous devrez soit éditer $HOME/.docker/config.json et définir la clé experimental à enabled ou vous pouvez simplement définir la variable d'environnement DOCKER_CLI_EXPERIMENTAL à enabled lorsque vous appelez les commandes de la CLI.

Si vous avez des problèmes en téléchargeant des manifestes viciés, nettoyez les anciens manifestes dans $HOME/.docker/manifests pour recommencer de zéro.

Pour Kubernetes, nous avons historiquement utilisé des images avec des suffixes -$(ARCH). Pour une rétrocompatibilité, veuillez générer les anciennes images avec des suffixes. Par exemple, l'image pause qui a le manifeste pour toutes les architetures et l'image pause-amd64 qui est rétrocompatible pour d'anciennes configurations ou des fichiers YAML qui auraient codé en dur les images avec des suffixes.

Utiliser un registre privé

Les registres privés peuvent demander des clés pour pouvoir lire leurs images.

Ces certificats peuvent être fournis de différentes manières :

• En utilisant la Google Container Registry
  • par cluster
  • automatiqueent configuré dans Google Compute Engine ou Google Kubernetes Engine
  • tous les pods peuvent lire le registre privé du projet
• En utilisant Amazon Elastic Container Registry (ECR)
  • utilise les rôles et politiques IAM pour contrôler l'accès aux dépôts ECR
  • rafraîchit automatiquement les certificats de login ECR
• En utilisant Oracle Cloud Infrastructure Registry (OCIR)
  • utilise les rôles et politiques IAM pour contrôler l'accès aux dépôts OCIR
• En utilisant Azure Container Registry (ACR)
• En utilisant IBM Cloud Container Registry
  • utilise les rôles et politiques IAM pour contrôler l'accès à l'IBM Cloud Container Registry
• En configurant les nœuds pour s'authentifier auprès d'un registre privé
  • tous les pods peuvent lire les registres privés configurés
  • nécessite la configuration des nœuds par un administrateur du cluster
• En utilisant des images pré-chargées
  • tous les pods peuvent utiliser toutes les images mises en cache sur un nœud
  • nécessite l'accès root à tous les nœuds pour la mise en place
• En spécifiant ImagePullSecrets dans un Pod
  • seuls les pods fournissant ses propres clés peuvent accéder au registre privé

Chaque option est décrite plus en détails ci-dessous.

Utiliser la Google Container Registry

Kubernetes prend en charge nativement la Google Container Registry (GCR), lorsqu'il s'exécute dans Google Compute Engine (GCE). Si vous exécutez votre cluster dans GCE ou Google Kubernetes Engine, utilisez simplement le nom complet de l'image (par ex. gcr.io/my_project/image:tag).

Tous les pods dans un cluster auront un accès en lecture aux images dans le registre.

Kubelet va s'authentifier auprès de GCR en utilisant le compte de service Google de l'instance. Le compte de service dans l'instance aura un https://www.googleapis.com/auth/devstorage.read_only, afin qu'il puisse récupérer depuis le GCR du projet mais qu'il ne puisse pas pousser une image.

Utiliser Amazon Elastic Container Registry

Kubernetes prend en charge nativement Amazon Elastic Container Registry, lorsque les nœuds sont des instances de AWS EC2.

Utilisez simplement le nom complet de l'image (par ex. ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag) dans la définition du Pod.

Tous les utilisateurs du cluster qui peuvent créer des pods auront la possibilité d'exécuter des pods qui utilisent n'importe quelle image du registre ECR.

Kubelet va aller chercher et rafraîchir périodiquement les certificats ECR. Les permissions suivantes sont requises par kubelet :

• ecr:GetAuthorizationToken
• ecr:BatchCheckLayerAvailability
• ecr:GetDownloadUrlForLayer
• ecr:GetRepositoryPolicy
• ecr:DescribeRepositories
• ecr:ListImages
• ecr:BatchGetImage

Exigences :

• Vous devez utiliser kubelet version v1.2.0 ou ultérieure. (exécutez par ex. /usr/bin/kubelet --version=true).
• Si vos nœuds sont dans une région différente de votre registre, vous devez utiliser la version v1.3.0 ou ultérieure.
• ECR doit être disponible dans votre région.

Dépannage :

• Vérifiez toutes les exigences ci-dessus.
• Copiez les certificats de $REGION (par ex. us-west-2) sur votre poste de travail. Connectez-vous en SSH sur l'hôte et exécutez Docker manuellement avec ces certificats. Est-ce que ça marche ?
• Vérifiez que kubelet s'exécute avec --cloud-provider=aws.
• Augmentez la verbosité des logs de kubelet à au moins 3 et recherchez dans les logs de kubelet (par exemple avec journalctl -u kubelet) des lignes similaires à :

• • aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API
• • aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com

Utiliser Azure Container Registry (ACR)

En utilisant Azure Container Registry vous pouvez vous authentifier en utilisant soit un utilisateur admin soit un service principal. Dans les deux cas, l'authentification est faite via l'authentification standard de Docker. Ces instructions assument l'outil en ligne de commande azure-cli.

Vous devez d'abord créer un registre et générer des certificats, la documentation complète pour cela peut être touvée dans la documentation de Azure container registry.

Une fois votre registre de conteneurs créé, vous utiliserez les certificats suivants pour vous connecter :

• DOCKER_USER : service principal ou utilisateur admin
• DOCKER_PASSWORD: mot de passe du service principal ou utilisateur admin
• DOCKER_REGISTRY_SERVER: ${un-nom-de-registre}.azurecr.io
• DOCKER_EMAIL: ${une-adresse-email}

Une fois que vous avez défini ces variables, vous pouvez configurer un Secret Kubernetes et l'utiliser pour déployer un Pod.

Utiliser IBM Cloud Container Registry

IBM Cloud Container Registry fournit un registre d'images multi-tenant privé que vous pouvez utiliser pour stocker et partager de manière sécurisée vos images. Par défaut, les images de votre registre privé sont scannées par le Vulnerability Advisor intégré pour détecter des failles de sécurité et des vulnérabilités potentielles. Les utilisateurs de votre compte IBM Cloud peuvent accéder à vos images, ou vous pouvez des rôles et politiques IAM pour fournir l'accès aux namespaces de l'IBM Cloud Container Registry.

Pour installer le plugin du CLI de IBM Cloud Container Registry et créer un namespace pour vos images, voir Débuter avec IBM Cloud Container Registry.

Si vous utilisez le même compte et la même région, vous pouvez déployer des images stockées dans IBM Cloud Container Registry vers la namespace default de votre cluster IBM Cloud Kubernetes Service sans configuration supplémentaire, voir Construire des conteneurs à partir d'images. Pour les autres options de configuration, voir Comprendre comment autoriser votre cluster à télécharger des images depuis un registre.

Configurer les nœuds pour s'authentifier auprès d'un registre privé

Docker stocke les clés pour les regisres privés dans le fichier $HOME/.dockercfg ou $HOME/.docker/config.json. Si vous placez le même fichier dans un des chemins de recherche ci-dessous, kubelet l'utilise comme fournisseur de clés lorsque les images sont récupérées.

• {--root-dir:-/var/lib/kubelet}/config.json
• {cwd of kubelet}/config.json
• ${HOME}/.docker/config.json
• /.docker/config.json
• {--root-dir:-/var/lib/kubelet}/.dockercfg
• {cwd of kubelet}/.dockercfg
• ${HOME}/.dockercfg
• /.dockercfg

Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent un registre privé. Dans cet exemple, exécutez-les sur votre poste de travail :

1. Exécutez docker login [server] pour chaque jeu de certificats que vous désirez utiliser. Ceci met à jour $HOME/.docker/config.json.
2. Examinez $HOME/.docker/config.json dans un éditeur pour vous assurer qu'il contient uniquement les certificats que vous désirez utiliser.
3. Récupérez la liste de vos nœuds, par exemple :
   • si vous voulez connaître les noms : nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')
   • si vous voulez connaître les IPs : nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')
4. Copiez votre fichier .docker/config.json local dans un des chemins de recherche ci-dessus.
   • par exemple : for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done

Vérifiez en créant un pod utilisant une image privée, par ex. :

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: test-image-privee-1
spec:
  containers:
    - name: utilise-image-privee
      image: $NOM_IMAGE_PRIVEE
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF

pod/test-image-privee-1 created

Si tout fonctionne, alors, après quelques instants, vous pouvez exécuter :

kubectl logs test-image-privee-1

et voir que la commande affiche :

SUCCESS

Si vous suspectez que la commande a échouée, vous pouvez exécuter :

kubectl describe pods/test-image-privee-1 | grep 'Failed'

En cas d'échec, l'affichage sera similaire à :

  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found

Vous devez vous assurer que tous les nœuds du cluster ont le même fichier .docker/config.json. Dans le cas contraire, les pods vont s'exécuter sur certains nœuds et échouer sur d'autres. Par exemple, si vous utilisez l'autoscaling des nœuds, alors chaque modèle d'instance doit inclure le fichier .docker/config.json ou monter un disque le contenant.

Tous les pods auront un accès en lecture aux images d'un registre privé dès que les clés du registre privé sont ajoutées au fichier .docker/config.json.

Images pré-chargées

Par défaut, kubelet essaiera de récupérer chaque image depuis le registre spécifié. Cependant, si la propriété imagePullPolicy du conteneur est IfNotPresent ou Never, alors une image locale est utilisée (respectivement de préférence ou exclusivement).

Si vous désirez vous reposer sur des images pré-chargées pour éviter l'authentification à un registre, vous devez vous assurer que tous les nœuds du cluster ont les mêmes images pré-chargées.

Ceci peut être utilisé pour pré-charger certaines images pour gagner du temps, ou comme une alternative à l'authentification à un registre privé.

Tous les pods auront un accès en lecture aux images pré-chargées.

Spécifier ImagePullSecrets dans un Pod

Kubernetes permet de spécifier des clés de registre dans un pod.

Créer un Secret avec une config Docker

Exécutez la commande suivante, en substituant les valeurs en majuscule :

kubectl create secret docker-registry <name> --docker-server=SERVEUR_REGISTRE_DOCKER --docker-username=UTILISATEUR_DOCKER --docker-password=MOT_DE_PASSE_DOCKER --docker-email=EMAIL_DOCKER
secret/myregistrykey created.

Si vous avez déjà un fichier de clés Docker, alors, plutôt que d'utiliser la commande ci-dessus, vous pouvez importer le fichier de clés comme un Secret Kubernetes. Créer un Secret basé sur des clés Docker existantes explique comment s'y prendre. Ceci est particulièrement utile si vous utilisez plusieurs registres privés, kubectl create secret docker-registry créant un Secret ne fonctionnant qu'avec un seul registre privé.

Se référer à un imagePullSecrets dans un Pod

Vous pouvez maintenant créer des pods qui référencent ce secret en ajoutant une section imagePullSecrets dans la définition du pod.

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey
EOF

cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

Ceci doit être fait pour chaque pod utilisant un registre privé.

Cependant, la définition de ce champ peut être automatisé en définissant imagePullSecrets dans une ressource serviceAccount. Voyez Ajouter un ImagePullSecrets à un Service Account pour des instructions détaillées.

Vous pouvez utiliser cette méthode en conjonction avec un .docker/config.json par nœud. Les certificats seront alors regroupés. Cette approche fonctionnera dans Google Kubernetes Engine.

Cas d'utilisation

Il y a plusieurs solutions pour configurer des registres privés. Voici quelques cas d'utilisation classiques et des propositions de solutions.

1. Cluster exécutant uniquement des images non propriétaires (par ex. open-source). Inutile de protéger les images.
   • Utilisez des images publiques dans le Hub Docker.
     • Pas de configuration requise.
     • Dans GCE/Google Kubernetes Engine, un miroir local est automatiquement utilisé pour améliorer la vitesse et la disponibilité.
2. Cluster exécutant quelques images propriétaires qui doivent être protégées de l'extérieur de l'entreprise, mais visibles pour tous les utilisteurs du cluster.
   • Utilisez un registre Docker hébergé privé.
     • Il peut être hébergé sur le Hub Docker, ou ailleurs.
     • Configurez manuellement .docker/config.json sur caque nœud comme décrit ci-dessus.
   • Ou, utilisez un registre privé interne derrière votre pare-feu avec un accès ouvert en lecture.
     • Aucune configuration Kubernetes n'est nécessaire.
   • Ou, dans GCE/Google Kubernetes Engine, utilisez le Google Container Registry du projet.
     • Cela fonctionnera mieux pour l'autoscaling du cluster que la configuration manuelle des nœuds.
   • Ou, dans un cluster où le changement de la configuration des nœuds est difficile, utilisez imagePullSecrets.
3. Cluster avec des images propriétaires, dont quelques-unes nécessitent un contrôle d'accès plus strict.
   • Assurez-vous que l'admission controller AlwaysPullImages est actif. Autrement, tous les Pods ont potentiellement accès à toutes les images.
   • Déplacez les données sensibles dans une ressource "Secret", plutôt que de les intégrer dans une image.
4. Un cluster multi-tenant où chaque tenant doit avoir son propre registre privé.
   • Assurez-vous que l'admission controller AlwaysPullImages est actif. Autrement, tous les Pods ont potentiellement accès à toutes les images.
   • Utilisez un registre privé nécessitant l'autorisation.
   • Générez des certificats de registre pour chaque tenant, placez-les dans des secrets, et placez ces secrets dans les namespaces de chaque tenant. pod - Le tenant ajoute ce secret dans les imagePullSecrets de chaque pod.

Si vous devez accéder à plusieurs registres, vous pouvez créer un secret pour chaque registre. Kubelet va fusionner tous les imagePullSecrets dans un unique .docker/config.json virtuel.

3.2 - Classe d'exécution (Runtime Class)

Cette page décrit la ressource RuntimeClass et le mécanisme de sélection d'exécution (runtime).

Runtime Class

La RuntimeClass est une fonctionnalité alpha permettant de sélectionner la configuration d'exécution du conteneur à utiliser pour exécuter les conteneurs d'un pod.

Installation

En tant que nouvelle fonctionnalité alpha, certaines étapes de configuration supplémentaires doivent être suivies pour utiliser la RuntimeClass:

1. Activer la fonctionnalité RuntimeClass (sur les apiservers et les kubelets, nécessite la version 1.12+)
2. Installer la RuntimeClass CRD
3. Configurer l'implémentation CRI sur les nœuds (dépend du runtime)
4. Créer les ressources RuntimeClass correspondantes

1. Activer RuntimeClass feature gate (portail de fonctionnalité)

Voir Feature Gates pour une explication sur l'activation des feature gates. La RuntimeClass feature gate doit être activée sur les API servers et les kubelets.

2. Installer la CRD RuntimeClass

La RuntimeClass CustomResourceDefinition (CRD) se trouve dans le répertoire addons du dépôt Git Kubernetes: kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml

Installer la CRD avec kubectl apply -f runtimeclass_crd.yaml.

3. Configurer l'implémentation CRI sur les nœuds

Les configurations à sélectionner avec RuntimeClass dépendent de l'implémentation CRI. Consultez la documentation correspondante pour votre implémentation CRI pour savoir comment le configurer. Comme c'est une fonctionnalité alpha, tous les CRI ne prennent pas encore en charge plusieurs RuntimeClasses.

Les configurations ont un nom RuntimeHandler correspondant , référencé par la RuntimeClass. Le RuntimeHandler doit être un sous-domaine DNS valide selon la norme RFC 1123 (alphanumériques + - et . caractères).

4. Créer les ressources RuntimeClass correspondantes

Les configurations effectuées à l'étape 3 doivent chacune avoir un nom RuntimeHandler associé, qui identifie la configuration. Pour chaque RuntimeHandler (et optionellement les handlers vides ""), créez un objet RuntimeClass correspondant.

La ressource RuntimeClass ne contient actuellement que 2 champs significatifs: le nom RuntimeClass (metadata.name) et le RuntimeHandler (spec.runtimeHandler). la définition de l'objet ressemble à ceci:

apiVersion: node.k8s.io/v1alpha1  # La RuntimeClass est définie dans le groupe d'API node.k8s.io
kind: RuntimeClass
metadata:
  name: myclass  # Le nom avec lequel la RuntimeClass sera référencée
  # La RuntimeClass est une ressource non cantonnées à un namespace
spec:
  runtimeHandler: myconfiguration  # Le nom de la configuration CRI correspondante

Usage

Une fois que les RuntimeClasses sont configurées pour le cluster, leur utilisation est très simple. Spécifiez runtimeClassName dans la spécficiation du pod. Par exemple:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

Cela indiquera à la kubelet d'utiliser la RuntimeClass spécifiée pour exécuter ce pod. Si la RuntimeClass n'existe pas, ou si la CRI ne peut pas exécuter le handler correspondant, le pod passera finalement à l'état failed. Recherchez l'événement correspondant pour un message d'erreur.

Si aucun runtimeClassName n'est spécifié, le RuntimeHandler par défault sera utilisé, qui équivaut au comportement lorsque la fonctionnalité RuntimeClass est désactivée.

3.3 - L'environnement du conteneur

Cette page décrit les ressources disponibles pour les conteneurs dans l'environnement de conteneur.

L'environnement du conteneur

L’environnement Kubernetes conteneur fournit plusieurs ressources importantes aux conteneurs:

• Un système de fichier, qui est une combinaison d'une image et un ou plusieurs volumes.
• Informations sur le conteneur lui-même.
• Informations sur les autres objets du cluster.

Informations sur le conteneur

Le nom d'hôte d'un conteneur est le nom du pod dans lequel le conteneur est en cours d'exécution. Il est disponible via la commande hostname ou gethostname dans libc.

Le nom du pod et le namespace sont disponibles en tant que variables d'environnement via l'API downward.

Les variables d'environnement définies par l'utilisateur à partir de la définition de pod sont également disponibles pour le conteneur, de même que toutes les variables d'environnement spécifiées de manière statique dans l'image Docker.

Informations sur le cluster

Une liste de tous les services en cours d'exécution lors de la création d'un conteneur est disponible pour ce conteneur en tant que variables d'environnement. Ces variables d'environnement correspondent à la syntaxe des liens Docker.

Pour un service nommé foo qui correspond à un conteneur bar, les variables suivantes sont définies:

FOO_SERVICE_HOST=<l'hôte sur lequel le service est exécuté>
FOO_SERVICE_PORT=<le port sur lequel le service fonctionne>

Les services ont des adresses IP dédiées et sont disponibles pour le conteneur avec le DNS, si le module DNS est activé. 

A suivre

• En savoir plus sur les hooks du cycle de vie d'un conteneur.
• Acquérir une expérience pratique en attachant les handlers aux événements du cycle de vie du conteneur.

3.4 - Hooks de cycle de vie de conteneurs

Cette page décrit comment un conteneur pris en charge par kubelet peut utiliser le framework de Hooks de cycle de vie de conteneurs pour exécuter du code déclenché par des événements durant son cycle de vie.

Aperçu

De manière similaire à quantité de frameworks de langages de programmation qui ont des hooks de cycle de vie de composants, comme Angular, Kubernetes fournit aux conteneurs des hooks de cycle de vie. Les hooks permettent à un conteneur d'être au courant d'événements durant son cycle de vie et d'exécuter du code implémenté dans un handler lorsque le hook de cycle de vie correspondant est exécuté.

Hooks de conteneurs

Il existe deux hooks exposés aux conteneurs :

PostStart

Ce hook s'exécute immédiatement après qu'un conteneur soit créé. Cependant, il n'y a aucune garantie que le hook s'exécute avant l'ENTRYPOINT du conteneur. Aucun paramètre n'est passé au handler.

PreStop

Ce hook est appelé immédiatement avant qu'un conteneur se termine, en raison d'un appel à l'API ou d'un événement comme un échec de la liveness probe, un droit de préemption, un conflit de ressources ou autres. Un appel au hook preStop échoue si le conteneur est déjà dans l'état terminé ou complété. Il est bloquant, ce qui veut dire qu'il est synchrone, et doit donc se terminer avant que l'appel pour supprimer le conteneur soit envoyé. Aucun paramètre n'est passé au handler.

Une description plus précise du comportement de l'arrêt peut être trouvé dans Arrêt de Pods.

Implémentation d'un handler de hook

Les conteneurs peuvent accéder à un hook en implémentant et enregistrant un handler pour ce hook. Il existe deux types de handlers de hook pouvant être implémentés pour des conteneurs :

• Exec - Exécute une commande donnée, comme pre-stop.sh, dans les cgroups et namespaces du conteneur. Les ressources consommées par la commande sont comptabilisées pour le conteneur.
• HTTP - Exécute une requête HTTP sur un endpoint spécifique du conteneur.

Exécution d'un handler de hook

Lorsqu'un hook de cycle de vie de conteneur est appelé, le système de gestion de Kubernetes exécute le handler dans le conteneur enregistré pour ce hook.

Les appels aux handlers de hook sont synchrones dans le contexte du pod contenant le conteneur. Ceci veut dire que pour un hook PostStart, bien que l'ENTRYPOINT du conteneur et le hook soient lancés de manière asynchrone, si le hook prend trop de temps à s'exécuter ou se bloque, le conteneur ne peut pas atteindre l'état running.

Le comportement est similaire pour un hook PreStop. Si le hook se bloque durant l'exécution, la phase du Pod reste en état Terminating et le hook est tué après terminationGracePeriodSeconds que le pod se termine. Si un hook PostStart ou PreStop échoue, le conteneur est tué.

Les utilisateurs doivent rendre leurs handlers de hook aussi légers que possible. Il existe des cas, cependant, où de longues commandes ont un intérêt, comme pour enregistrer un état avant de stopper un conteneur.

Garanties de déclenchement d'un hook

La politique de déclenchement d'un hook est au moins une fois, ce qui veut dire qu'un hook peut être déclenché plus d'une fois pour un événement donné, comme PostStart ou PreStop. Il appartient à l'implémentation du hook de prendre en compte correctement ce comportement.

En général, un seul déclenchement est fait. Si, par exemple, un récepteur de hook HTTP est hors service et ne peut pas prendre en charge du trafic, il n'y a aucune tentative de renvoi. Dans quelques rares cas, cependant, un double envoi peut se produire. Par exemple, si kubelet redémarre au milieu d'un déclenchement de hook, le hook pourrait être re-déclenché après que kubelet redémarre.

Débugger des handlers de hook

Les logs pour un handler de hook ne sont pas exposés dans les événements du Pod. Si un handler échoue pour une raison particulière, il envoie un événement. Pour PostStart, c'est l'événement FailedPostStartHook et pour PreStop, c'est l'événement FailedPreStopHook. Vous pouvez voir ces événements en exécutant kubectl describe pod <pod_name>. Voici un exemple d'affichage d'événements lors de l'exécution de cette commande :

Events:
  FirstSeen  LastSeen  Count  From                                                   SubObjectPath          Type      Reason               Message
  ---------  --------  -----  ----                                                   -------------          --------  ------               -------
  1m         1m        1      {default-scheduler }                                                          Normal    Scheduled            Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulling              pulling image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Created              Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulled               Successfully pulled image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Started              Started container with docker id 5c6a256a2567
  38s        38s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
  37s        37s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
  38s        37s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                         Warning   FailedSync           Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
  1m         22s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Warning   FailedPostStartHook

A suivre

• En savoir plus sur l'Environnement d'un conteneur.
• Entraînez-vous à attacher des handlers de conteneurs à des événements de cycle de vie.

4 - Workloads

Un workload (charge de travail) est une application fonctionnant sur Kubernetes. Que votre workload soit un composant unique ou un agrégat de composants, sur Kubernetes celui-ci fonctionnera dans une série de pods. Dans Kubernetes, un Pod represente un ensemble de conteneur (containers) en fonctionnement sur votre cluster.

Les pods Kubernetes ont un cycle de vie définit (defined lifecycle). Par exemple, quand un pod est en fonction sur votre cluster et qu’une panne critique survient sur le noeud (node) où se situe ce pod, tous les pods du noeud seront en échec. Kubernetes traite ce niveau d’échec comme un état final : Vous devez créer un nouveau Pod pour retrouver l’état initial même si le noeud redevient sain.

Cependant, pour vous simplifier la vie, vous n’avez pas a gérer chaque Pod directement. Vous pouvez utiliser une ressource workload qui gère votre groupe de pods à votre place. Ces ressources configurent des controleurs (controllers) qui s’assurent que le bon nombre et le bon type de pod soit en fonction pour égaler l’état que vous avez spécifié.

Kubernetes fournit plusieurs ressources workload pré-faites :

• Deployment et ReplicaSet (qui remplacent l’ancienne ressource ReplicationController)). Le Deployment (déploiement) est une bonne approche pour manager une application stateless sur votre cluster, tous les Pods d’un Deployment sont interchangeables et peuvent être remplacés si besoin.
• Le StatefulSet vous permet de lancer un ou plusieurs Pods en relation qui garde plus ou moins la trace de leurs état. Par exemple si votre workload enregistre des données de façon persistente, vous pouvez lancer un StatefulSet qui fera le lien entre les Pods et un volume persistent (PersistentVolume). Votre code, présent dans les Pods du StatefulSet, peut répliquer des données dans les autres Pods qui sont dans le même StatefulSet, pour améliorer la résilience global.
• Le DaemonSet permet de définir les Pods qui effectuent des actions sur le noeud local. Ceux-ci peuvent être fondamental aux opérations de votre cluster, comme un outil d’aide réseau, ou peuvent faire part d’un module complémentaire (add-on). Pour chaque nouveau noeud ajouté au cluster, le controle plane organise l'ajout d'un Pod pour ce DaemonSet sur le nouveau noeud.
• Les Job et CronJob sont des taches lancées jusqu’à accomplissement puis s’arrêtent. Les Jobs réprésentent une tâche ponctuelle, les CronJob sont des tâches récurrentes planifiés.

Dans l’écosystème étendu de Kubernetes, vous pouvez trouver des ressources workload de fournisseurs tiers qui offrent des fonctionnalités supplémentaires. L’utilisation d’un CustomResourceDefinition permet d’ajouter une ressource workload d’un fournisseur tiers si vous souhaitez rajouter une fonctionnalité ou un comportement spécifique qui ne fait pas partie du noyau de Kubernetes. Par exemple, si vous voulez lancer un groupe de Pods pour votre application mais que vous devez arrêter leurs fonctionnement tant qu’ils ne sont pas tous disponibles, alors vous pouvez implémenter ou installer une extension qui permet cette fonctionnalité.

A suivre

Vous pouvez continuer la lecture des ressources, vous pouvez aussi apprendre à connaitre les taches qui leurs sont liées :

• Lancer une application stateless en utilisant un Deployment.
• Lancer une application statefull, soit comme instance unique ou alors comme un ensemble répliqué.
• Lancer une tâche automatisée avec un CronJob.

Pour en apprendre plus sur les méchanismes de Kubernetes, de séparation du code et de la configuration, allez voir Configuration.

Il y a deux concepts supportés qui fournissent un contexte sur le sujet : comment Kubernetes gère les pods pour les applications :

• Le ramasse-miettes, fait le ménage dans votre cluster après qu’une de vos ressource soit supprimé.
• Le temps de vie d’un controlleur éteint supprime les Jobs une fois qu’un temps définit soit passé après son accomplissement.

Une fois que votre application est lancée, vous souhaitez peut etre la rendre disponible sur internet comme un Service ou comme une application web uniquement en utilsant un Ingress.

4.1 - Pods

4.1.1 - Aperçu du Pod

Cette page fournit un aperçu du Pod, l'objet déployable le plus petit dans le modèle d'objets Kubernetes.

Comprendre les Pods

Un Pod est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre cluster.

Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une identité réseau (adresse IP) unique, ainsi que des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : une instance unique d'une application dans Kubernetes, qui peut consister soit en un unique container soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources.

Docker est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres runtimes de conteneurs.

Les Pods dans un cluster Kubernetes peuvent être utilisés de deux manières différentes :

• les Pods exécutant un conteneur unique. Le modèle "un-conteneur-par-Pod" est le cas d'utilisation Kubernetes le plus courant ; dans ce cas, vous pouvez voir un Pod comme un wrapper autour d'un conteneur unique, et Kubernetes gère les Pods plutôt que directement les conteneurs.
• les Pods exécutant plusieurs conteneurs devant travailler ensemble. Un Pod peut encapsuler une application composée de plusieurs conteneurs co-localisés qui sont étroitement liés et qui doivent partager des ressources. Ces conteneurs co-localisés pourraient former une unique unité de service cohésive--un conteneur servant des fichiers d'un volume partagé au public, alors qu'un conteneur "sidecar" séparé rafraîchit ou met à jour ces fichiers. Le Pod enveloppe ensemble ces conteneurs et ressources de stockage en une entité maniable de base.

Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (pour fournir plus de ressources au global en exécutant plus d'instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle typiquement de réplication. Des Pods répliqués sont en général créés et gérés en tant que groupe par une ressource de charge de travail et son _contrôleur_. Voir Pods et contrôleurs pour plus d'informations.

Comment les Pods gèrent plusieurs conteneurs

Les Pods sont conçus pour supporter plusieurs process coopérants (sous forme de conteneurs) qui forment une unité de service cohésive. Les conteneurs d'un même Pod sont automatiquement co-localisés et co-programmés sur la même machine physique ou virtuelle dans le cluster. Ces conteneurs peuvent partager des ressources et dépendances, communiquer entre eux, et coordonner quand et comment ils sont arrêtés.

Notez que grouper plusieurs conteneurs co-localisés et co-gérés dans un unique Pod est un cas d'utilisation relativement avancé. Vous devez utiliser ce pattern seulement dans des instances spécifiques dans lesquelles vos conteneurs sont étroitement liés. Par exemple, vous pourriez avoir un conteneur qui agit comme un serveur web pour des fichiers contenus dans un volume partagé, et un conteneur "sidecar" séparé qui met à jour ces fichiers depuis une source externe, comme dans le diagramme suivant :

Certains Pods ont des init containers en plus d'app containers. Les Init containers s'exécutent et terminent avant que les conteneurs d'application soient démarrés.

Les Pods fournissent deux types de ressources partagées pour leurs conteneurs : réseau et stockage.

Réseau

Chaque Pod se voit assigner une adresse IP unique pour chaque famille d'adresses. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs à l'intérieur d'un Pod peuvent communiquer entre eux en utilisant localhost. Lorsque les conteneurs dans un Pod communiquent avec des entités en dehors du Pod, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports).

Stockage

Un Pod peut spécifier un jeu de volumes de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir Volumes pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod.

Travailler avec des Pods

Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un _contrôleur_), il est programmé pour s'exécuter sur un dans votre cluster. Le Pod reste sur ce nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit expulsé par manque de ressources, ou le nœud soit en échec.

Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un contrôleur, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un contrôleur.

Pods et contrôleurs

Vous pouvez utiliser des ressources de charges de travail pour créer et gérer plusieurs Pods pour vous. Un contrôleur pour la ressource gère la réplication, le plan de déploiement et la guérison automatique en cas de problèmes du Pod. Par exemple, si un noeud est en échec, un contrôleur note que les Pods de ce noeud ont arrêté de fonctionner et créent des Pods pour les remplacer. L'ordonnanceur place le Pod de remplacement sur un noeud en fonctionnement.

Voici quelques exemples de ressources de charges de travail qui gèrent un ou plusieurs Pods :

• Deployment
• StatefulSet
• DaemonSet

Templates de Pod

Les Templates de Pod sont des spécifications pour créer des Pods, et sont inclus dans les ressources de charges de travail comme les Deployments, les Jobs et les DaemonSets.

Chaque contrôleur pour une ressource de charges de travail utilise le template de pod à l'intérieur de l'objet pour créer les Pods. Le template de pod fait partie de l'état désiré de la ressource de charges de travail que vous avez utilisé pour exécuter votre application.

L'exemple ci-dessous est un manifest pour un Job simple avec un template qui démarre un conteneur. Le conteneur dans ce Pod affiche un message puis se met en pause.

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # Ceci est un template de pod
    spec:
      containers:
      - name: hello
        image: busybox
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # Le template de pod se termine ici

Modifier le template de pod ou changer pour un nouvau template de pod n'a pas d'effet sur les pods déjà existants. Les Pods ne reçoivent pas une mise à jour du template directement ; au lieu de cela, un nouveau Pod est créé pour correspondre au nouveau template de pod.

Par exemple, un contrôleur de Deployment s'assure que les Pods en cours d'exécution correspondent au template de pod en cours. Si le template est mis à jour, le contrôleur doit supprimer les pods existants et créer de nouveaux Pods avec le nouveau template. Chaque contrôleur de charges de travail implémente ses propres règles pour gérer les changements du template de Pod.

Sur les noeuds, le kubelet n'observe ou ne gère pas directement les détails concernant les templates de pods et leurs mises à jours ; ces détails sont abstraits. Cette abstraction et cette séparation des préoccupations simplifie la sémantique du système, et rend possible l'extension du comportement du cluster sans changer le code existant.

A suivre

• En savoir plus sur les Pods
• The Distributed System Toolkit: Patterns for Composite Containers explique les dispositions courantes pour des Pods avec plusieurs conteneurs
• En savoir plus sur le comportement des Pods :
  • Terminaison d'un Pod
  • Cycle de vie d'un Pod

4.1.2 - Pods

Les Pods sont les plus petites unités informatiques déployables qui peuvent être créées et gérées dans Kubernetes.

Qu'est-ce qu'un pod ?

Un pod (terme anglo-saxon décrivant un groupe de baleines ou une gousse de pois) est un groupe d'un ou plusieurs conteneurs (comme des conteneurs Docker), ayant du stockage/réseau partagé, et une spécification sur la manière d'exécuter ces conteneurs. Les éléments d'un pod sont toujours co-localisés et co-ordonnancés, et s'exécutent dans un contexte partagé. Un pod modélise un "hôte logique" spécifique à une application - il contient un ou plusieurs conteneurs applicatifs qui sont étroitement liés — dans un monde pré-conteneurs, être exécuté sur la même machine physique ou virtuelle signifierait être exécuté sur le même hôte logique.

Bien que Kubernetes prenne en charge d'autres runtimes de conteneurs que Docker, Docker est le runtime le plus connu, et cela aide à décrire des pods en termes Docker.

Le contexte partagé d'un pod est un ensemble de namespaces Linux, cgroups, et potentiellement d'autres facettes d'isolation - les mêmes choses qui isolent un conteneur Docker. Dans le contexte d'un pod, les applications individuelles peuvent se voir appliquer d'autres sous-isolations.

Les conteneurs d'un pod partagent une adresse IP et un espace de ports, et peuvent communiquer via localhost. Ils peuvent aussi communiquer entre eux en utilisant des communications inter-process standard comme les sémaphores SystemV ou la mémoire partagée POSIX. Les conteneurs appartenant à des pods distincts ont des adresses IP distinctes et ne peuvent pas communiquer par IPC sans configuration spécifique. Ces conteneurs communiquent en général entre eux via les adresses IP de leurs pods.

Les applications à l'intérieur d'un pod ont aussi accès à des volumes partagés, qui sont définis dans le cadre d'un pod et sont mis à disposition pour être montés dans le système de fichiers de chaque application.

En terme de concepts Docker, un pod est modélisé par un groupe de conteneurs Docker ayant des namespaces et des volumes partagés.

Tout comme des conteneurs applicatifs individuels, les pods sont considérés comme des entités relativement éphémères (plutôt que durables). Comme discuté dans Cycle de vie d'un pod, les pods sont créés, des ID uniques (UID) leurs sont assignés, et ils sont ordonnancés sur des nœuds où il restent jusqu'à leur arrêt (selon la politique de redémarrage) ou suppression. Si un nœud meurt, les pods ordonnancés sur ce nœud sont programmés pour être terminés, après un délai d'attente. Un pod donné (défini par un UID) n'est pas "re-ordonnancé" sur un nouveau nœud ; par contre, il peut être remplacé par un pod identique, ayant le même nom si désiré, mais avec un nouvel UID (voir replication controller pour plus de détails).

Lorsque quelque chose, comme un volume, a le même cycle de vie qu'un pod, il existe aussi longtemps que le pod (avec l'UID donné) existe. Si ce pod est supprimé pour une quelconque raison, même si un remplaçant identique est recréé, la chose liée (par ex. le volume) est aussi détruite et créée à nouveau.

Un pod multi-conteneurs contenant un extracteur de fichiers et un serveur web utilisant un volume persistant comme espace de stockage partagé entre les conteneurs.

Intérêts des pods

Gestion

Les pods fournissent une unité de service cohérente afin d'avoir un modèle coopératif entre plusieurs processus. Ils simplifient le déploiement et la gestion d'applications en fournissant une abstraction de plus haut niveau que l'ensemble des applications les constituant. Les pods servent d'unité de déploiement, de mise à l'échelle horizontale, et de réplication. La co-localisation (co-ordonnancement), la fin partagée (par ex. l'arrêt), la réplication coordonnée, le partage de ressources et la gestion des dépendances sont traités automatiquement pour les conteneurs dans un pod.

Partage de ressources et communication

Les pods permettent le partage de ressources et la communication entre ses constituants.

Les applications dans un pod utilisent toutes le même réseau (même adresse IP et espace de ports) et peuvent donc "se trouver" entre elles et communiquer en utilisant localhost. À cause de cela, les applications dans un pod doivent coordonner leurs usages de ports. Chaque pod a une adresse IP dans un réseau plat partagé ayant un accès complet aux autres hôtes et pods à travers le réseau.

Le nom d'hôte est défini avec le nom du pod pour les conteneurs applicatifs à l'intérieur du pod. Plus de détails sur le réseau.

En plus de définir les conteneurs applicatifs s'exécutant dans le pod, le pod spécifie un ensemble de volumes de stockage partagés. Les volumes permettent aux données de survivre aux redémarrages de conteneurs et d'être partagés entre les applications d'un même pod.

Cas d'utilisation de pods

Des pods peuvent être utilisés pour héberger verticalement des piles applicatives intégrées (par ex. LAMP), mais leur principal intérêt est la mise en place de programmes auxiliaires co-localisés et co-gérés, comme :

• systèmes de gestion de contenu, chargeurs de fichiers et de données, gestionnaires de cache local, etc.
• sauvegarde de log et checkpoint, compression, rotation, prise d'instantanés, etc.
• data change watchers, log tailers, adaptateurs de logs et monitoring, éditeurs d'événements, etc.
• proxies, bridges et adaptateurs
• contrôleurs, gestionnaires, configurateurs et gestionnaires de mise à jour

Des pods individuels ne sont pas destinés à exécuter plusieurs instances de la même application, en général.

Pour une explication plus détaillée, voir The Distributed System ToolKit: Patterns for Composite Containers.

Alternatives envisagées

Pourquoi ne pas simplement exécuter plusieurs programmes dans un unique conteneur (Docker) ?

1. Transparence. Rendre les conteneurs à l'intérieur du pod visibles par l'infrastucture permet à l'infrastucture de fournir des services à ces conteneurs, comme la gestion des processus et le monitoring des ressources. Ceci apporte un certain nombre de facilités aux utilisateurs.
2. Découpler les dépendances logicielles. Les conteneurs individuels peuvent être versionnés, reconstruits et redéployés de manière indépendante. Kubernetes pourrait même un jour prendre en charge la mise à jour à chaud de conteneurs individuels.
3. Facilité d'utilisation. Les utilisateurs n'ont pas besoin d'exécuter leur propre gestionnaire de processus, de se soucier de la propagation de signaux et de codes de sortie, etc.
4. Efficacité. L'infrastructure prenant plus de responsabilités, les conteneurs peuvent être plus légers.

Pourquoi ne pas prendre en charge le co-ordonnancement de conteneurs basé sur les affinités ?

Cette approche pourrait fournir la co-localisation, mais ne fournirait pas la plupart des bénéfices des pods, comme le partage de ressources, IPC, la garantie d'une fin partagée et une gestion simplifiée.

Durabilité des pods (ou manque de)

Les pods ne doivent pas être considérés comme des entités durables. Ils ne survivent pas à des erreurs d'ordonnancement, à un nœud en échec ou à d'autres expulsions, suite à un manque de ressources ou une mise en maintenance d'un nœud.

En général, les utilisateurs n'ont pas à créer directement des pods. Ils doivent presque toujours utiliser des contrôleurs, même pour des singletons, comme par exemple des Deployments. Les contrôleurs fournissent l'auto-guérison à l'échelle du cluster, ainsi que la réplication et la gestion des déploiements (rollout). Les contrôleurs comme StatefulSet peuvent aussi prendre en charge des pods avec état (stateful).

L'utilisation d'APIs collectives comme principale primitive exposée à l'utilisateur est courante dans les systèmes d'ordonnancement de clusters, comme Borg, Marathon, Aurora, et Tupperware.

Un Pod est exposé en tant que primitive afin de faciliter :

• la connexion du scheduler et du contrôleur
• la possibilité d'opérations au niveau du pod sans besoin de passer par des APIs au niveau du contrôleur
• le découplage du cycle de fin d'un pod de celui d'un contrôleur, comme pour l'amorçage (bootstrapping)
• le découplage des contrôleurs et des services — le contrôleur d'endpoints examine uniquement des pods
• la composition claire des fonctionnalités niveau Kubelet et des fonctionnalités niveau cluster — concrètement, Kubelet est le "contrôleur de pods"
• les applications hautement disponibles, qui attendront que les pods soient remplacés avant leur arrêt et au moins avant leur suppression, comme dans les cas d'éviction programmée ou de pré-chargement d'image.

Arrêt de pods

Les pods représentant des processus s'exécutant sur des nœuds d'un cluster, il est important de permettre à ces processus de se terminer proprement lorsqu'ils ne sont plus nécessaires (plutôt que d'être violemment tués avec un signal KILL et n'avoir aucune chance de libérer ses ressources). Les utilisateurs doivent pouvoir demander une suppression et savoir quand les processus se terminent, mais aussi être capable de s'assurer que la suppression est réellement effective. Lorsqu'un utilisateur demande la suppression d'un pod, le système enregistre le délai de grâce prévu avant que le pod puisse être tué de force, et qu'un signal TERM soit envoyé au processus principal de chaque conteneur. Une fois la période de grâce expirée, le signal KILL est envoyé à ces processus, et le pod est alors supprimé de l'API server. Si Kubelet ou le gestionnaire de conteneurs est redémarré lors de l'attente de l'arrêt des processus, l'arrêt sera réessayé avec la période de grâce complète.

Un exemple de déroulement :

1. Un utilisateur envoie une commande pour supprimer un Pod, avec une période de grâce par défaut (30s)
2. Le Pod dans l'API server est mis à jour avec le temps au delà duquel le Pod est considéré "mort" ainsi que la période de grâce.
3. Le Pod est affiché comme "Terminating" dans les listes des commandes client
4. (en même temps que 3) Lorsque Kubelet voit qu'un Pod a été marqué "Terminating", le temps ayant été mis en 2, il commence le processus de suppression du pod.
   1. Si un des conteneurs du Pod a défini un preStop hook, il est exécuté à l'intérieur du conteneur. Si le preStop hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire une seule fois. Vous devez modifier terminationGracePeriodSeconds si le hook preStop a besoin de plus de temps pour se terminer.
   2. Le signal TERM est envoyé aux conteneurs. Notez que tous les conteneurs du Pod ne recevront pas le signal TERM en même temps et il peut être nécessaire de définir des preStop hook si l'ordre d'arrêt est important.
5. (en même temps que 3) Le Pod est supprimé des listes d'endpoints des services, et n'est plus considéré comme faisant partie des pods en cours d'exécution pour les contrôleurs de réplication. Les Pods s'arrêtant lentement ne peuvent pas continuer à servir du trafic, les load balancers (comme le service proxy) les supprimant de leurs rotations.
6. Lorsque la période de grâce expire, les processus s'exécutant toujours dans le Pod sont tués avec SIGKILL.
7. Kubelet va supprimer le Pod dans l'API server en indiquant une période de grâce de 0 (suppression immédiate). Le Pod disparaît de l'API et n'est plus visible par le client.

Par défaut, toutes les suppressions ont une période de grâce de 30 secondes. La commande kubectl delete prend en charge l'option --grace-period=<secondes> permettant à l'utilisateur de spécifier sa propre valeur. La valeur 0 force la suppression du pod. Avec kubectl version >= 1.5, vous devez spécifier un flag supplémentaire --force avec --grace-period=0 pour pouvoir forcer la suppression.

Suppression forcée de pods

La suppression forcée d'un pod est définie comme la suppression immédiate d'un pod de l'état du cluster et d'etcd. Lorqu'une suppression forcée est effectuée, l'apiserver n'attend pas la confirmation de kubelet que le pod a été terminé sur le nœud sur lequel il s'exécutait. Il supprime le pod de l'API immédiatement pour qu'un nouveau pod puisse être créé avec le même nom. Sur le nœud, les pods devant se terminer immédiatement se verront donner une courte période de grâce avant d'être tués de force.

Les suppressions forcées peuvent être potentiellement dangereuses pour certains pods et doivent être effectuées avec précaution. Dans le cas de pods d'un StatefulSet, veuillez vous référer à la documentation pour supprimer des Pods d'un StatefulSet.

Mode privilégié pour les conteneurs d'un pod

Depuis Kubernetes v1.1, tout conteneur d'un pod peut activer le mode privilégié, en utilisant le flag privileged du SecurityContext de la spec du conteneur. Ceci est utile pour les conteneurs voulant utiliser les capacités de Linux comme manipuler la pile réseau ou accéder aux périphériques. Les processus dans un tel conteneur ont pratiquement les mêmes privilèges que les processus en dehors d'un conteneur. En mode privilégié, il doit être plus facile d'écrire des plugins réseau et volume en tant que pods séparés ne devant pas être compilés dans kubelet.

Si le master exécute Kubernetes v1.1 ou supérieur, et les nœuds exécutent une version antérieure à v1.1, les nouveaux pods privilégiés seront acceptés par l'api-server, mais ne seront pas lancés. Il resteront en état "pending". Si l'utilisateur appelle kubectl describe pod FooPodName, l'utilisateur peut voir la raison pour laquelle le pod est en état "pending". La table d'événements dans la sortie de la commande "describe" indiquera : Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'

Si le master exécute une version antérieure à v1.1, les pods privilégiés ne peuvent alors pas être créés. Si l'utilisateur tente de créer un pod ayant un conteneur privilégié, l'utilisateur obtiendra l'erreur suivante : The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

Objet de l'API

Le Pod est une ressource au plus haut niveau dans l'API REST Kubernetes. Plus de détails sur l'objet de l'API peuvent être trouvés à : Objet de l'API Pod.

Lorsque vous créez un manifest pour un objet Pod, soyez certain que le nom spécifié est un nom de sous-domaine DNS valide.

4.1.3 - Cycle de vie d'un Pod

Cette page décrit le cycle de vie d'un Pod.

Phase du Pod

Le champ status d'un Pod est un objet PodStatus, contenant un champ phase.

La phase d'un Pod est un résumé simple et de haut niveau de l'étape à laquelle le Pod se trouve dans son cycle de vie. La phase n'est pas faite pour être un cumul complet d'observations de l'état du conteneur ou du Pod, ni pour être une machine à état compréhensible.

Le nombre et la signification des valeurs de phase d'un pod sont soigneusement gardés. Hormis ce qui est documenté ici, rien ne doit être supposé sur des Pods ayant une valeur de phase donnée.

Voici les valeurs possibles pour phase :

Conditions du Pod

Un Pod a un PodStatus, qui contient un tableau de PodConditions à travers lesquelles le Pod est ou non passé. Chaque élément du tableau de PodCondition a six champs possibles :

• Le champ lastProbeTime fournit un timestamp auquel la condition du Pod a été sondée pour la dernière fois.

• Le champ lastTransitionTime fournit un timestamp auquel le Pod a changé de statut pour la dernière fois.

• Le champ message est un message lisible indiquant les détails de la transition.

• Le champ reason est une raison unique, en un seul mot et en CamelCase de la transition vers la dernière condition.

• Le champ status est une chaîne de caractères avec les valeurs possibles "True", "False", et "Unknown".

• Le champ type est une chaîne de caractères ayant une des valeurs suivantes :

  • PodScheduled : le Pod a été affecté à un nœud ;
  • Ready : le Pod est prêt à servir des requêtes et doit être rajouté aux équilibreurs de charge de tous les Services correspondants ;
  • Initialized : tous les init containers ont démarré correctement ;
  • ContainersReady : tous les conteneurs du Pod sont prêts.

Sondes du Conteneur

Une Sonde (Probe) est un diagnostic exécuté périodiquement par kubelet sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un Handler implémenté par le Conteneur. Il existe trois types de handlers :

• ExecAction: Exécute la commande spécifiée à l'intérieur du Conteneur. Le diagnostic est considéré réussi si la commande se termine avec un code de retour de 0.

• TCPSocketAction: Exécute un contrôle TCP sur l'adresse IP du Conteneur et sur un port spécifié. Le diagnostic est considéré réussi si le port est ouvert.

• HTTPGetAction: Exécute une requête HTTP Get sur l'adresse IP du Conteneur et sur un port et un chemin spécifiés. Le diagnostic est considéré réussi si la réponse a un code de retour supérieur ou égal à 200 et inférieur à 400.

Chaque sonde a un résultat parmi ces trois :

• Success: Le Conteneur a réussi le diagnostic.
• Failure: Le Conteneur a échoué au diagnostic.
• Unknown: L'exécution du diagnostic a échoué, et donc aucune action ne peut être prise.

kubelet peut optionnellement exécuter et réagir à trois types de sondes sur des conteneurs en cours d'exécution :

• livenessProbe : Indique si le Conteneur est en cours d'exécution. Si la liveness probe échoue, kubelet tue le Conteneur et le Conteneur est soumis à sa politique de redémarrage (restart policy). Si un Conteneur ne fournit pas de liveness probe, l'état par défaut est Success.

• readinessProbe : Indique si le Conteneur est prêt à servir des requêtes. Si la readiness probe échoue, le contrôleur de points de terminaison (Endpoints) retire l'adresse IP du Pod des points de terminaison de tous les Services correspodant au Pod. L'état par défaut avant le délai initial est Failure. Si le Conteneur ne fournit pas de readiness probe, l'état par défaut est Success.

• startupProbe: Indique si l'application à l'intérieur du conteneur a démarré. Toutes les autres probes sont désactivées si une starup probe est fournie, jusqu'à ce qu'elle réponde avec succès. Si la startup probe échoue, le kubelet tue le conteneur, et le conteneur est assujetti à sa politique de redémarrage. Si un conteneur ne fournit pas de startup probe, l'état par défaut est Success.

Quand devez-vous utiliser une liveness probe ?

Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il rencontre un problème ou devient inopérant, vous n'avez pas forcément besoin d'une liveness probe ; kubelet va automatiquement exécuter l'action correcte en accord avec la politique de redémarrage (restartPolicy) du Pod.

Si vous désirez que votre Conteneur soit tué et redémarré si une sonde échoue, alors spécifiez une liveness probe et indiquez une valeur pour restartPolicy à Always ou OnFailure.

Quand devez-vous utiliser une readiness probe ?

Si vous voulez commencer à envoyer du trafic à un Pod seulement lorsqu'une sonde réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être la même que la liveness probe, mais l'existence de la readiness probe dans la spec veut dire que le Pod va démarrer sans recevoir aucun trafic et va commencer à recevoir du trafic après que la sonde réussisse. Si votre Conteneur doit charger une grande quantité de données, des fichiers de configuration ou exécuter des migrations au démarrage, spécifiez une readiness probe.

Si vous désirez que le Conteneur soit capable de se mettre en maintenance tout seul, vous pouvez spécifier une readiness probe qui vérifie un point de terminaison spécifique au readiness et différent de la liveness probe.

Notez que si vous voulez uniquement être capable de dérouter les requêtes lorsque le Pod est supprimé, vous n'avez pas forcément besoin d'une readiness probe; lors de sa suppression, le Pod se met automatiquement dans un état non prêt, que la readiness probe existe ou non. Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s'arrêtent.

Quand devez-vous utiliser une startup probe ?

Si votre conteneur démarre habituellement en plus de initialDelaySeconds + failureThreshold × periodSeconds, vous devriez spécifier une startup probe qui vérifie le même point de terminaison que la liveness probe. La valeur par défaut pour periodSeconds est 30s. Vous devriez alors mettre sa valeur failureThreshold suffisamment haute pour permettre au conteneur de démarrer, sans changer les valeurs par défaut de la liveness probe. Ceci aide à se protéger de deadlocks.

Pour plus d'informations sur la manière de mettre en place une liveness, readiness ou startup probe, voir Configurer des Liveness, Readiness et Startup Probes.

Statut d'un Pod et d'un Conteneur

Pour des informations détaillées sur le statut d'un Pod et d'un Conteneur, voir PodStatus et ContainerStatus. Notez que l'information rapportée comme statut d'un Pod dépend du ContainerState actuel.

États d'un Conteneur

Une fois que le Pod est assigné à un nœud par le scheduler, kubelet commence à créer les conteneurs en utilisant le runtime de conteneurs. Il existe trois états possibles pour les conteneurs : en attente (Waiting), en cours d'exécution (Running) et terminé (Terminated). Pour vérifier l'état d'un conteneur, vous pouvez utiliser kubectl describe pod [POD_NAME]. L'état est affiché pour chaque conteneur du Pod.

• Waiting : état du conteneur par défaut. Si le conteneur n'est pas dans un état Running ou Terminated, il est dans l'état Waiting. Un conteneur dans l'état Waiting exécute les opérations nécessaires, comme télécharger les images, appliquer des Secrets, etc. À côté de cet état, un message et une raison sur l'état sont affichés pour vous fournir plus d'informations.

  ...
    State:          Waiting
     Reason:       ErrImagePull
  ...
  

• Running : Indique que le conteneur s'exécute sans problème. Le hook postStart (s'il existe) est exécuté avant que le conteneur entre dans l'état Running. Cet état affiche aussi le moment auquel le conteneur est entré dans l'état Running.

  ...
     State:          Running
      Started:      Wed, 30 Jan 2019 16:46:38 +0530
  ...
  

• Terminated: Indique que le conteneur a terminé son exécution et s'est arrêté. Un conteneur entre dans cet état lorsqu'il s'est exécuté avec succès ou lorsqu'il a échoué pour une raison quelconque. De plus, une raison et un code de retour sont affichés, ainsi que les moments de démarrage et d'arrêt du conteneur. Avant qu'un conteneur entre dans l'état Terminated, le hook preStop est exécuté (s'il existe).

  ...
     State:          Terminated
       Reason:       Completed
       Exit Code:    0
       Started:      Wed, 30 Jan 2019 11:45:26 +0530
       Finished:     Wed, 30 Jan 2019 11:45:26 +0530
   ...
  

Pod readiness

Votre application peut injecter des données dans PodStatus.

Pod readiness. Pour utiliser cette fonctionnalité, remplissez readinessGates dans le PodSpec avec une liste de conditions supplémentaires que le kubelet évalue pour la disponibilité du Pod.

Les Readiness gates sont déterminées par l'état courant des champs status.condition du Pod. Si Kubernetes ne peut pas trouver une telle condition dans le champs status.conditions d'un Pod, the statut de la condition est mise par défaut à "False".

Voici un exemple :

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready  # une PodCondition intégrée
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"   # une PodCondition supplémentaire
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

Les conditions du Pod que vous ajoutez doivent avoir des noms qui sont conformes au format des étiquettes de Kubernetes.

Statut de la disponibilité d'un Pod

La commande kubectl patch ne peut pas patcher le statut d'un objet. Pour renseigner ces status.conditions pour le pod, les applications et operators doivent utiliser l'action PATCH. Vous pouvez utiliser une bibliothèque client Kubernetes pour écrire du code qui renseigne les conditions particulières pour la disponibilité dun Pod.

Pour un Pod utilisant des conditions particulières, ce Pod est considéré prêt seulement lorsque les deux déclarations ci-dessous sont vraies :

• Tous les conteneurs du Pod sont prêts.
• Toutes les conditions spécifiées dans ReadinessGates sont True.

Lorsque les conteneurs d'un Pod sont prêts mais qu'au moins une condition particulière est manquante ou False, le kubelet renseigne la condition du Pod à ContainersReady.

Politique de redémarrage

La structure PodSpec a un champ restartPolicy avec comme valeur possible Always, OnFailure et Never. La valeur par défaut est Always. restartPolicy s'applique à tous les Conteneurs du Pod. restartPolicy s'applique seulement aux redémarrages des Conteneurs par kubelet sur le même nœud. Des conteneurs terminés qui sont redémarrés par kubelet sont redémarrés avec un délai exponentiel (10s, 20s, 40s ...) plafonné à cinq minutes, qui est réinitialisé après dix minutes d'exécution normale. Comme discuté dans le document sur les Pods, une fois attaché à un nœud, un Pod ne sera jamais rattaché à un autre nœud.

Durée de vie d'un Pod

En général, les Pods restent jusqu'à ce qu'un humain ou un process de contrôleur les supprime explicitement.

Le plan de contrôle nettoie les Pods terminés (avec une phase à Succeeded ou Failed), lorsque le nombre de Pods excède le seuil configuré (determiné par terminated-pod-gc-threshold dans le kube-controller-manager). Ceci empêche une fuite de ressources lorsque les Pods sont créés et supprimés au fil du temps.

Il y a différents types de ressources pour créer des Pods :

• Utilisez un Déploiement, ReplicaSet ou StatefulSet pour les Pods qui ne sont pas censés terminer, par exemple des serveurs web.

• Utilisez un Job pour les Pods qui sont censés se terminer une fois leur tâche accomplie. Les Jobs sont appropriés seulement pour des Pods ayant restartPolicy égal à OnFailure ou Never.

• Utilisez un DaemonSet pour les Pods qui doivent s'exécuter sur chaque noeud éligible.

Toutes les ressources de charges de travail contiennent une PodSpec. Il est recommandé de créer la ressource de charges de travail appropriée et laisser le contrôleur de la ressource créer les Pods pour vous, plutôt que de créer directement les Pods vous-même.

Si un nœud meurt ou est déconnecté du reste du cluster, Kubernetes applique une politique pour mettre la phase de tous les Pods du nœud perdu à Failed.

Exemples

Exemple avancé de liveness probe

Les Liveness probes sont exécutées par kubelet, toutes les requêtes sont donc faites dans l'espace réseau de kubelet.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    livenessProbe:
      httpGet:
        # lorsque "host" n'est pas défini, "PodIP" sera utilisé
        # host: my-host
        # lorsque "scheme" n'est pas défini, "HTTP" sera utilisé. "HTTP" et "HTTPS" sont les seules valeurs possibles
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

Exemples d'états

• Un Pod est en cours d'exécution et a un Conteneur. Le conteneur se termine avec succès.

  • Écriture d'un événement de complétion.
  • Si restartPolicy est :
    • Always : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • OnFailure : la phase du Pod passe à Succeeded.
    • Never : la phase du Pod passe à Succeeded.

• Un Pod est en cours d'exécution et a un Conteneur. Le conteneur se termine en erreur.

  • Écriture d'un événement d'échec.
  • Si restartPolicy est :
    • Always : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • OnFailure : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • Never : la phase du Pod passe à Failed.

• Un Pod est en cours d'exécution et a deux Conteneurs. Le conteneur 1 termine en erreur.

  • Écriture d'un événement d'échec.
  • Si restartPolicy est :
    • Always : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • OnFailure : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • Never : Le Conteneur n'est pas redémarré ; la phase du Pod reste à Running.
  • Si Container 1 est arrêté, et Conteneur 2 se termine :
    • Écriture d'un événement d'échec.
    • Si restartPolicy est :
      • Always : Redémarrage du Conteneur ; la phase du Pod reste à Running.
      • OnFailure : Redémarrage du Conteneur ; la phase du Pod reste à Running.
      • Never : la phase du Pod passe à Failed.

• Un Pod est en cours d'exécution et a un Conteneur. Le Conteneur n'a plus assez de mémoire.

  • Le Conteneur se termine en erreur.
  • Écriture d'un événement OOM.
  • Si restartPolicy est :
    • Always : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • OnFailure : Redémarrage du Conteneur ; la phase du Pod reste à Running.
    • Never : Écriture d'un événement d'erreur ; la phase du Pod passe à Failed.

• Le Pod est en cours d'exécution, et un disque meurt.

  • Tous les conteneurs sont tués.
  • Écriture d'un événement approprié.
  • La phase du Pod devient Failed.
  • Si le Pod s'exécute sous un contrôleur, le Pod est recréé ailleurs.

• Le Pod est en cours d'exécution et son nœud est segmenté.

  • Le contrôleur de Nœud attend un certain temps.
  • Le contrôleur de Nœud passe la phase du Pod à Failed.
  • Si le Pod s'exécute sous un contrôleur, le Pod est recréé ailleurs.

A suivre

• Apprenez par la pratique attacher des handlers à des événements de cycle de vie d'un conteneur.

• Apprenez par la pratique configurer des liveness, readiness et startup probes.

• En apprendre plus sur les hooks de cycle de vie d'un Conteneur.

4.1.4 - Contraintes de propagation de topologie pour les Pods

Vous pouvez utiliser des contraintes de propagation de topologie pour contrôler comment les Pods sont propagés à travers votre cluster parmi les domaines de défaillance comme les régions, zones, noeuds et autres domaines de topologie définis par l'utilisateur. Ceci peut aider à mettre en place de la haute disponibilité et à utiliser efficacement les ressources.

Conditions préalables

Autoriser la Feature Gate

La feature gate EvenPodsSpread doit être autorisée pour l'API Server et le scheduler.

Labels de noeuds

Les contraintes de propagation de topologie reposent sur les labels de noeuds pour identifier le ou les domaines de topologie dans lesquels se trouve chacun des noeuds. Par exemple, un noeud pourrait avoir les labels: node=node1,zone=us-east-1a,region=us-east-1

Supposons que vous ayez un cluster de 4 noeuds ayant les labels suivants:

NAME    STATUS   ROLES    AGE     VERSION   LABELS
node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB

Une vue logique du cluster est celle-ci :

+---------------+---------------+
|     zoneA     |     zoneB     |
+-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+

Plutôt que d'appliquer des labels manuellement, vous pouvez aussi réutiliser les labels réputés qui sont créés et renseignés automatiquement dans la plupart des clusters.

Contraintes de propagation pour les Pods

API

Le champ pod.spec.topologySpreadConstraints est introduit dans 1.16 comme suit :

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer>
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>

Vous pouvez définir une ou plusieurs topologySpreadConstraint pour indiquer au kube-scheduler comment placer chaque nouveau Pod par rapport aux Pods déjà existants dans votre cluster. Les champs sont :

• maxSkew décrit le degré avec lequel les Pods peuvent être inégalement distribués. C'est la différence maximale permise entre le nombre de Pods correspondants entre deux quelconques domaines de topologie d'un type donné. Il doit être supérieur à zéro.
• topologyKey est la clé des labels de noeuds. Si deux noeuds sont étiquettés avec cette clé et ont des valeurs égales pour ce label, le scheduler considère les deux noeuds dans la même topologie. Le scheduler essaie de placer un nombre équilibré de Pods dans chaque domaine de topologie.
• whenUnsatisfiable indique comment traiter un Pod qui ne satisfait pas les contraintes de propagation :
  • DoNotSchedule (défaut) indique au scheduler de ne pas le programmer.
  • ScheduleAnyway indique au scheduler de le programmer, tout en priorisant les noeuds minimisant le biais (skew).
• labelSelector est utilisé pour touver les Pods correspondants. Les Pods correspondants à ce sélecteur de labels sont comptés pour déterminer le nombre de Pods dans leurs domaines de topologie correspodants. Voir Sélecteurs de labels pour plus de détails.

Vous pouvez en savoir plus sur ces champ en exécutant kubectl explain Pod.spec.topologySpreadConstraints.

Exemple : Une TopologySpreadConstraint

Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquettés foo:bar sont placés sur node1, node2 et node3 respectivement (P représente un Pod) :

+---------------+---------------+
|     zoneA     |     zoneB     |
+-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+
|   P   |   P   |   P   |       |
+-------+-------+-------+-------+

Si nous voulons qu'un nouveau Pod soit uniformément réparti avec les Pods existants à travers les zones, la spec peut être :

pods/topology-spread-constraints/one-constraint.yaml

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

topologyKey: zone implique que la distribution uniforme sera uniquement appliquée pour les noeuds ayant le label "zone:<any value>" présent. whenUnsatisfiable: DoNotSchedule indique au scheduler de laisser le Pod dans l'état Pending si le Pod entrant ne peut pas satisfaire la contrainte.

Si le scheduler plaçait ce Pod entrant dans "zoneA", la distribution des Pods deviendrait [3, 1], et le biais serait de 2 (3 - 1) - ce qui va à l'encontre de maxSkew: 1. Dans cet exemple, le Pod entrant peut uniquement être placé dans "zoneB":

+---------------+---------------+      +---------------+---------------+
|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
+-------+-------+-------+-------+      +-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+      +-------+-------+-------+-------+
|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
+-------+-------+-------+-------+      +-------+-------+-------+-------+

Vous pouvez ajuster la spec du Pod pour pour répondre à divers types d'exigences :

• Changez maxSkew pour une valeur plus grande comme "2" pour que le Pod entrant puisse aussi être placé dans la "zoneA".
• Changez topologyKey pour "node" pour distribuer les Pods uniformément à travers les noeuds et non plus les zones. Dans l'exemple ci-dessus, si maxSkew reste à "1", le Pod entrant peut être uniquement placé dans "node4".
• Changez whenUnsatisfiable: DoNotSchedule en whenUnsatisfiable: ScheduleAnyway pour s'assurer que le Pod est toujours programmable (en supposant que les autres APIs de scheduling soient satisfaites). Cependant, il sera de préférence placé dans la topologie de domaine ayant le moins de Pods correspondants. (Prenez note que cette préférence est normalisée conjointement avec d'autres priorités de scheduling interne comme le ratio d'usage de ressources, etc.)

Example: Plusieurs TopologySpreadConstraints

Cela s'appuie sur l'exemple précédent. Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquetés foo:bar sont placés sur node1, node2 et node3 respectivement (P représente un Pod):

+---------------+---------------+
|     zoneA     |     zoneB     |
+-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+
|   P   |   P   |   P   |       |
+-------+-------+-------+-------+

Vous pouvez utiliser 2 TopologySpreadConstraints pour contrôler la répartition des Pods aussi bien dans les zones que dans les noeuds :

pods/topology-spread-constraints/two-constraints.yaml

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Dans ce cas, pour satisfaire la première contrainte, le Pod entrant peut uniquement être placé dans "zoneB" ; alors que pour satisfaire la seconde contrainte, le Pod entrant peut uniquement être placé dans "node4". Le résultat étant l'intersection des résultats des 2 contraintes, l'unique option possible est de placer le Pod entrant dans "node4".

Plusieurs contraintes peuvent entraîner des conflits. Supposons que vous ayez un cluster de 3 noeuds couvrant 2 zones :

+---------------+-------+
|     zoneA     | zoneB |
+-------+-------+-------+
| node1 | node2 | node3 |
+-------+-------+-------+
|  P P  |   P   |  P P  |
+-------+-------+-------+

Si vous appliquez "two-constraints.yaml" à ce cluster, vous noterez que "mypod" reste dans l'état Pending. Cela parce que : pour satisfaire la première contrainte, "mypod" peut uniquement être placé dans "zoneB"; alors que pour satisfaire la seconde contrainte, "mypod" peut uniquement être placé sur "node2". Ainsi, le résultat de l'intersection entre "zoneB" et "node2" ne retourne rien.

Pour surmonter cette situation, vous pouvez soit augmenter maxSkew, soit modifier une des contraintes pour qu'elle utilise whenUnsatisfiable: ScheduleAnyway.

Conventions

Il existe quelques conventions implicites qu'il est intéressant de noter ici :

• Seuls le Pods du même espace de noms que le Pod entrant peuvent être des candidats pour la correspondance.

• Les noeuds sans label topologySpreadConstraints[*].topologyKey seront ignorés. Cela induit que :

  1. les Pods localisés sur ces noeuds n'impactent pas le calcul de maxSkew - dans l'exemple ci-dessus, supposons que "node1" n'a pas de label "zone", alors les 2 Pods ne seront pas comptés, et le Pod entrant sera placé dans "zoneA".
  2. le Pod entrant n'a aucune chance d'être programmé sur ce type de noeuds - dans l'exemple ci-dessus, supposons qu'un "node5" portant un label {zone-typo: zoneC} joigne le cluster ; il sera ignoré, en raison de l'absence de label "zone".

• Faites attention à ce qui arrive lorsque le topologySpreadConstraints[*].labelSelector du Pod entrant ne correspond pas à ses propres labels. Dans l'exemple ci-dessus, si nous supprimons les labels du Pod entrant, il sera toujours placé dans "zoneB" car les contraintes sont toujours satisfaites. Cependant, après le placement, le degré de déséquilibre du cluster reste inchangé - zoneA contient toujours 2 Pods ayant le label {foo:bar}, et zoneB contient 1 Pod cayant le label {foo:bar}. Si ce n'est pas ce que vous attendez, nous recommandons que topologySpreadConstraints[*].labelSelector du workload corresponde à ses propres labels.

• Si le Pod entrant a défini spec.nodeSelector ou spec.affinity.nodeAffinity, les noeuds non correspondants seront ignorés.

  Supposons que vous ayez un cluster de 5 noeuds allant de zoneA à zoneC :

  +---------------+---------------+-------+
  |     zoneA     |     zoneB     | zoneC |
  +-------+-------+-------+-------+-------+
  | node1 | node2 | node3 | node4 | node5 |
  +-------+-------+-------+-------+-------+
  |   P   |   P   |   P   |       |       |
  +-------+-------+-------+-------+-------+
  

  et vous savez que "zoneC" doit être exclue. Dans ce cas, vous pouvez écrire le yaml ci-dessous, pour que "mypod" soit placé dans "zoneB" plutôt que dans "zoneC". spec.nodeSelector est pris en compte de la même manière.

  pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml

  kind: Pod
    apiVersion: v1
    metadata:
      name: mypod
      labels:
        foo: bar
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            foo: bar
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: zone
                operator: NotIn
                values:
                - zoneC
      containers:
      - name: pause
        image: registry.k8s.io/pause:3.1
    

Contraintes par défaut au niveau du cluster

Il est possible de définir des contraintes de propagation de topologie par défaut pour un cluster. Les contraintes de propagation de topologie sont appliquées à un Pod si et seulement si :

• Il ne définit aucune contrainte dans son .spec.topologySpreadConstraints.
• Il appartient à un service, replication controller, replica set ou stateful set.

Les contraintes par défaut peuvent être définies comme arguments du plugin PodTopologySpread dans un profil de scheduling. Les contraintes sont spécifiées avec la même API ci-dessus, à l'exception que labelSelector doit être vide. Les sélecteurs sont calculés à partir des services, replication controllers, replica sets ou stateful sets auxquels le Pod appartient.

Un exemple de configuration pourrait ressembler à :

apiVersion: kubescheduler.config.k8s.io/v1alpha2
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
  - pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: topology.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway

Comparaison avec PodAffinity/PodAntiAffinity

Dans Kubernetes, les directives relatives aux "Affinités" contrôlent comment les Pods sont programmés - plus regroupés ou plus dispersés.

• Pour PodAffinity, vous pouvez essayer de regrouper un certain nombre de Pods dans des domaines de topologie qualifiés,
• Pour PodAntiAffinity, seulement un Pod peut être programmé dans un domaine de topologie unique.

La fonctionnalité "EvenPodsSpread" fournit des options flexibles pour distribuer des Pods uniformément sur différents domaines de topologie - pour mettre en place de la haute disponibilité ou réduire les coûts. Cela peut aussi aider au rolling update des charges de travail et à la mise à l'échelle de réplicas. Voir Motivations pour plus de détails.

Limitations connues

En version 1.18, pour laquelle cette fonctionnalité est en Beta, il y a quelques limitations connues :

• Réduire un Déploiement peut résulter en une distrubution désiquilibrée des Pods.
• Les Pods correspondants sur des noeuds taintés sont respectés. Voir Issue 80921

4.1.5 - Init Containers

Cette page fournit une vue d'ensemble des conteneurs d'initialisation (init containers) : des conteneurs spécialisés qui s'exécutent avant les conteneurs d'application dans un Pod. Les init containers peuvent contenir des utilitaires ou des scripts d'installation qui ne sont pas présents dans une image d'application.

Vous pouvez spécifier des init containers dans la spécification du Pod à côté du tableau containers (qui décrit les conteneurs d'application)

Comprendre les init containers

Un Pod peut avoir plusieurs conteneurs exécutant des applications mais peut aussi avoir un ou plusieurs init containers, qui sont exécutés avant que les conteneurs d'application ne démarrent.

Les init containers se comportent comme les conteneurs réguliers, avec quelques différences :

• Les init containers s'exécutent toujours jusqu'à la complétion.
• Chaque init container doit se terminer avec succès avant que le prochain ne démarre.

Si le init container d'un Pod échoue, Kubernetes redémarre le Pod à répétition jusqu'à ce que le init container se termine avec succès. Cependant, si le Pod a une restartPolicy à "Never", Kubernetes ne redémarre pas le Pod.

Afin de spécifier un init container pour un Pod, il faut ajouter le champ initContainers dans la spécification du Pod, comme un tableau d'objets de type Container, au même niveau que le tableau d'applications containers. Le statut des init containers est retourné dans le champ .status.initContainerStatuses comme un tableau des statuts du conteneur (comparable au champ .status.containerStatuses).

Différences avec les conteneurs réguliers

Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application incluant les limites de ressources, les volumes et les paramètres de sécurité. Cependant, les demandes de ressources pour un init container sont gérées différemment des limites de ressources, tel que documenté dans Ressources.

De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs s'exécutent jusqu'au bout avant que le Pod soit prêt.

Si l'on spécifie plusieurs init containers pour un Pod, Kubelet exécute chaque init container de manière séquentielle. Chaque init container doit se terminer avec succès avant que le prochain ne puisse s'exécuter. Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise les conteneurs d'application pour le Pod et les exécute comme d'habitude.

Utiliser les init containers

Puisque les init containers ont des images séparées des conteneurs d'application, ils apportent certains avantages pour du code de mise en route :

• Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé qui ne sont pas présents dans une image d'application. Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (FROM) seulement pour utiliser un outil comme sed, awk, python, ou dig pendant l'installation.
• Les init containers peuvent exécuter en toute sécurité des utilitaires qui rendraient moins sécurisée une image de conteneur d'application.
• Les rôles "builder" et "deployer" d'une image d'application peuvent travailler indépendamment sans qu'il n'y ait besoin de créer conjointement une seule image d'application.
• Les init containers peuvent s'exécuter avec une vue du système de fichiers différente de celle des conteneurs d'application dans le même Pod. Par conséquent, on peut leur donner accès aux Secrets, auxquels les conteneurs d'application n'ont pas accès.
• Puisque les init containers s'exécutent jusqu'à la complétion avant qu'un conteneur d'application ne démarre, les init containers offrent un mécanisme pour bloquer ou retarder le démarrage d'un conteneur d'application tant qu'un ensemble de préconditions n'est pas respecté. Une fois que les préconditions sont respectées, tous les conteneurs d'application dans un Pod peuvent démarrer en parallèle.

Exemples

Voici plusieurs idées pour utiliser les init containers :

• Attendre qu'un Service soit créé, en utilisant une commande shell d'une ligne telle que :

  for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1
  

• Enregistrer ce Pod à un serveur distant depuis l'API downward avec une commande telle que :

  curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
  

• Attendre un certain temps avant de démarrer le conteneur d'application avec une commande telle que :

  sleep 60
  

• Cloner un dépôt Git dans un Volume

• Placer des valeurs dans un fichier de configuration et exécuter un outil de templating pour générer dynamiquement un fichier de configuration pour le conteneur d'application principal. Par exemple, placer la valeur POD_IP dans une configuration et générer le fichier de configuration de l'application principale en utilisant Jinja.

Les init containers en utilisation

Cet exemple définit un simple Pod possédant deux init containers. Le premier attend myservice et le second attend mydb. Une fois que les deux init containers terminent leur exécution, le Pod exécute le conteneur d'application décrit dans sa section spec.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo "L''app s''exécute!" && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo en attente de myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo en attente de mydb; sleep 2; done"]

Les fichiers YAML suivants résument les services mydb et myservice :

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

Vous pouvez démarrer ce Pod en exécutant :

kubectl apply -f myapp.yaml

pod/myapp-pod created

Et vérifier son statut avec :

kubectl get -f myapp.yaml

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

ou pour plus de détails :

kubectl describe -f myapp.yaml

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app.kubernetes.io/name=MyApp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634

Pour voir les logs des init containers dans ce Pod, exécuter :

kubectl logs myapp-pod -c init-myservice # Inspecter le premier init container
kubectl logs myapp-pod -c init-mydb      # Inspecter le second init container

À ce stade, ces init containers attendent de découvrir les services nommés mydb et myservice.

Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services :

---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

Pour créer les services mydb et myservice :

kubectl apply -f services.yaml

service/myservice created
service/mydb created

Vous verrez ensuite que ces init containers se terminent et que le Pod myapp-pod évolue vers l'état "Running" (en exécution) :

kubectl get -f myapp.yaml

NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

Cet exemple simple devrait suffire à vous inspirer pour créer vos propres init containers. A suivre contient un lien vers un exemple plus détaillé.

Comportement détaillé

Pendant le démarrage d'un Pod, chaque init container démarre en ordre, après que le réseau et les volumes ont été initialisés. Chaque conteneur doit se terminer avec succès avant que le prochain ne démarre. Si un conteneur n'arrive pas à démarrer à cause d'un problème d'exécution ou se termine avec un échec, il est redémarré selon la restartPolicy du Pod. Toutefois, si la restartPolicy du Pod est configurée à "Always", les init containers utilisent la restartPolicy "OnFailure".

Un Pod ne peut pas être Ready tant que tous les init containers ne se sont pas exécutés avec succès. Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise est dans l'état Pending mais devrait avoir une condition Initialized configurée à "true".

Si le Pod redémarre ou est redémarré, tous les init containers doivent s'exécuter à nouveau.

Les changements aux spec d'un init containers sont limités au champ image du conteneur. Changer le champ image d'un init container équivaut à redémarrer le Pod.

Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés, leur code doit être idempotent. En particulier, le code qui écrit dans des fichiers sur EmptyDirs devrait être préparé à la possibilité qu'un fichier de sortie existe déjà.

Les init containers ont tous les champs d'un conteneur d'application. Cependant, Kubernetes interdit l'utilisation de readinessProbe parce que les init containers ne peuvent pas définir une "readiness" distincte de la complétion. Ceci est appliqué lors de la validation.

L'utilisation de activeDeadlineSeconds sur le Pod et livenessProbe sur le conteneur permet d'empêcher les init containers d'échouer tout le temps. La deadline active inclut les init containers.

Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation est générée pour tout conteneur partageant un nom avec un autre.

Ressources

Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources :

• La plus haute requête ou limite particulière de ressource définie pour tous les init containers est la limite/requête d'initialisation effective
• La limite/requête effective d'un Pod pour une ressource est la plus haute parmis :
  • la somme de toutes les requêtes/limites des conteneurs d'application pour une ressource
  • la limite/requête d'initialisation effective pour une ressource
• Le Scheduling est effectué sur la base des requêtes/limites effectives, ce qui signifie que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le cycle de vie du Pod.
• La QoS (qualité de service) tierce de la QoS tierce effective d'un Pod est la QoS tierce aussi bien pour les init containers que pour les conteneurs d'application.

Les quotas et limites sont appliqués sur la base de la requête/limite effective d'un Pod.

Les groupes de contrôle au niveau du Pod (cgroups) sont basés sur la requête/limite effective de Pod, la même que celle du scheduler.

Raisons du redémarrage d'un Pod

Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes :

• Un utilisateur met à jour les spécifications du Pod, ce qui cause le changement de l'image de l'init container. Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le redémarrage du conteneur d'application.
• Le conteneur d'infrastructure Pod est redémarré. Ceci est peu commun et serait effectué par une personne ayant un accès root aux nœuds.
• Tous les conteneurs dans un Pod sont terminés tandis que restartPolicy est configurée à "Always", ce qui force le redémarrage, et l'enregistrement de complétion du init container a été perdu à cause d'une opération de garbage collection (récupération de mémoire).

A suivre

• Lire à propos de la création d'un Pod ayant un init container
• Apprendre à debugger les init containers

4.2 - Contrôleurs

4.2.1 - ReplicaSet

Un ReplicaSet (ensemble de réplicas en français) a pour but de maintenir un ensemble stable de Pods à un moment donné. Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods.

Comment un ReplicaSet fonctionne

Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder, un nombre de replicas indiquant le nombre de Pods qu'il doit maintenir et un modèle de Pod spécifiant les données que les nouveaux Pods que le replicatSet va créer jusqu'au nombre de replicas demandé.

Un ReplicaSet va atteindre son objectif en créant et supprimant des Pods pour atteindre le nombre de réplicas désirés. Quand un ReplicaSet a besoin de créer de nouveaux Pods, il utilise alors son Pod template.

Le lien d'un ReplicaSet à ses Pods est fait par le champ metadata.ownerReferences, qui spécifie la ressource de l'objet par lequel il est détenu. Tous les Pods acquis par un ReplicaSet ont leurs propres informations d'identification de leur Replicaset, avec leur propre champ ownerReferences. C'est par ce lien que le ReplicaSet connait l'état des Pods qu'il maintient et agit en fonction de ces derniers.

Un ReplicaSet identifie des nouveaux Pods à acquérir en utilisant son selecteur. Si il y a un Pod qui n'a pas de OwnerReference ou que OwnerReference n'est pas un controller et qu'il correspond à un sélecteur de ReplicaSet, il va immédiatement être acquis par ce ReplicaSet.

Quand utiliser un ReplicaSet ?

Un ReplicaSet garantit qu’un nombre spécifié de réplicas de Pod soient exécutés à un moment donné. Cependant, un Deployment est un concept de plus haut niveau qui gère les ReplicaSets et fournit des mises à jour déclaratives aux Pods ainsi que de nombreuses autres fonctionnalités utiles. Par conséquent, nous vous recommandons d’utiliser des Deployments au lieu d’utiliser directement des ReplicaSets, sauf si vous avez besoin d'une orchestration personnalisée des mises à jour ou si vous n'avez pas besoin de mises à jour.

Cela signifie qu'il est possible que vous n'ayez jamais besoin de manipuler des objets ReplicaSet : utilisez plutôt un déploiement et définissez votre application dans la section spec.

Exemple

controllers/frontend.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

Enregistrer ce manifeste dans frontend.yaml et le soumettre à un cluster Kubernetes va créer le ReplicaSet défini et les pods qu’il gère.

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Vous pouvez ensuite récupérer les ReplicaSets actuellement déployés :

kubectl get rs

Et voir le frontend que vous avez créé :

NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       6s

Vous pouvez également vérifier l'état du ReplicaSet :

kubectl describe rs/frontend

Et vous verrez une sortie similaire à :

Name:		frontend
Namespace:	default
Selector:	tier=frontend,tier in (frontend)
Labels:		app=guestbook
		tier=frontend
Annotations:	<none>
Replicas:	3 current / 3 desired
Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       app=guestbook
                tier=frontend
  Containers:
   php-redis:
    Image:      gcr.io/google_samples/gb-frontend:v3
    Port:       80/TCP
    Requests:
      cpu:      100m
      memory:   100Mi
    Environment:
      GET_HOSTS_FROM:   dns
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
  ---------    --------    -----    ----                -------------    --------    ------            -------
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-qhloh
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-dnjpy
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-9si5l

Et enfin, vous pourrez afficher les Pods déployés :

kubectl get Pods

Vous devriez voir des informations sur les Pods avec une sortie similaire à :

NAME             READY     STATUS    RESTARTS   AGE
frontend-9si5l   1/1       Running   0          1m
frontend-dnjpy   1/1       Running   0          1m
frontend-qhloh   1/1       Running   0          1m

Vous pouvez également vérifier que la OwnerReference de ces pods est définie sur le frontend ReplicaSet. Pour ce faire, récupérez le yaml de l’un des pods :

kubectl get pods frontend-9si5l -o yaml

La sortie sera similaire à celle-ci, avec les informations de l'interface ReplicaSet frontend définies dans le champ ownerReferences des métadonnées:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2019-01-31T17:20:41Z
  generateName: frontend-
  labels:
    tier: frontend
  name: frontend-9si5l
  namespace: default
  ownerReferences:
  - apiVersion: extensions/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: frontend
    uid: 892a2330-257c-11e9-aecd-025000000001
...

Acquisitions de Pod en dehors du template

Bien que vous puissiez créer des pods manuellement sans problème, il est fortement recommandé de s’assurer que ces pods n'ont pas de labels correspondant au sélecteur de l’un de vos ReplicaSets. Car un ReplicaSet n’est pas limité à posséder les pods spécifiés par son modèle - il peut acquérir d’autres pods de la manière spécifiée dans les sections précédentes.

Prenez l'exemple précédent de ReplicaSet, ainsi que les pods spécifiés dans le manifeste suivant :

pods/pod-rs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    tier: frontend
spec:
  containers:
  - name: hello1
    image: gcr.io/google-samples/hello-app:2.0

---

apiVersion: v1
kind: Pod
metadata:
  name: pod2
  labels:
    tier: frontend
spec:
  containers:
  - name: hello2
    image: gcr.io/google-samples/hello-app:1.0

Ces pods n’ayant pas de contrôleur (ni d’objet) en tant que référence propriétaire, ils correspondent au sélecteur de du ReplicaSet frontend, ils seront donc immédiatement acquis par ce ReplicaSet.

Supposons que vous créiez les pods une fois le ReplicaSet frontend déployé et qui a déjà déployé ses replicas de Pods initiaux afin de remplir son exigence de nombre de replicas :

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

Les nouveaux pods seront acquis par le ReplicaSet, puis immédiatement terminés car le ReplicaSet dépasserait alors le compte désiré.

En récupérant les pods :

kubectl get Pods

La sortie montre que les nouveaux pods sont soit déjà terminés, soit en voie de l'être :

NAME             READY   STATUS        RESTARTS   AGE
frontend-9si5l   1/1     Running       0          1m
frontend-dnjpy   1/1     Running       0          1m
frontend-qhloh   1/1     Running       0          1m
pod2             0/1     Terminating   0          4s

Cependant, si vous créez d'abord les pods :

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

Et puis créez le ReplicaSet :

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Vous verrez que le ReplicaSet a acquis les pods et n'a créé que les nouveaux Pods manquants, conformément à ses spécifications, jusqu'au nombre souhaité de Pods. En récupérant les Pods :

kubectl get Pods

La sortie va donner :

NAME             READY   STATUS    RESTARTS   AGE
frontend-pxj4r   1/1     Running   0          5s
pod1             1/1     Running   0          13s
pod2             1/1     Running   0          13s

De cette manière, un ReplicaSet peut avoir un ensemble de Pods hétérogène.

Écrire un manifest de ReplicaSet

Comme avec tous les autres objets API Kubernetes, un ReplicaSet a besoin des champs apiVersion, kind et metadata. Pour ReplicaSets, l'attribut kind est toujours ReplicaSet.

Dans Kubernetes 1.9, la version de l'API apps/v1 pour le type ReplicaSet est la version actuelle et activée par défaut. La version de l'API apps/v1beta2 est obsolète.

Reportez-vous aux premières lignes de l'exemple frontend.yaml pour obtenir des conseils.

Un ReplicaSet a également besoin de .spec section.

Pod Template

L'attribut .spec.template est un modèle de pod qui requiert d'avoir des labels. Dans notre exemple frontend.yaml, nous avons un label : tier: frontend. Il faut faire attention à ne pas avoir des selecteurs que d'autres controllers utilisent, afin d'éviter que le ReplicaSet n'adopte ce pod.

Pour le champ restart policy, .spec.template.spec.restartPolicy, la seule valeur autorisée est Always, qui est la valeur par défaut.

Sélecteur de Pod

Le champ .spec.selector est un label selector. Tel que discuté précédemment, ce sont les labels utilisés pour identifier les Pods potentiels à acquérir. Dans notre exemple avec frontend.yaml, le sélecteur était :

matchLabels:
	tier: frontend

Dans le ReplicaSet, .spec.template.metadata.labels doit correspondre à spec.selector, ou sinon il sera rejeté par l'API.

Replicas

Vous pouvez spécifier le nombre de pods à exécuter simultanément en définissant .spec.replicas. Le ReplicaSet va créer/supprimer ses pods pour correspondre à ce nombre.

Si vous ne spécifiez pas .spec.replicas, la valeur par défaut est 1.

Travailler avec des ReplicaSets

Suppression d'un ReplicaSet et de ses pods

Pour supprimer un ReplicaSet et tous ses pods, utilisez kubectl delete. The Garbage collector supprime automatiquement tous les pods associés par défaut.

Lors de l’utilisation de l’API REST ou de la bibliothèque client-go, vous devez définir propagationPolicy sur Background ou Foreground dans l'option -d. Par exemple :

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
> -H "Content-Type: application/json"

Supprimer juste un ReplicaSet

Vous pouvez supprimer un ReplicaSet sans affecter ses pods à l’aide de kubectl delete avec l'option --cascade=orphan. Lorsque vous utilisez l'API REST ou la bibliothèque client-go, vous devez définir propagationPolicy sur Orphan. Par exemple :

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
> -H "Content-Type: application/json"

Une fois l’original supprimé, vous pouvez créer un nouveau ReplicaSet pour le remplacer. Tant que l'ancien et le nouveau .spec.selector sont identiques, le nouveau adoptera les anciens Pods. Cependant, le ReplicaSet ne fera aucun effort pour que les pods existants correspondent à un nouveau Pod template. Pour mettre à jour les Pods à une nouvelle spec de manière contrôlée, utilisez un Deployment, car les ReplicaSets ne supportent pas de rolling update directement.

Isoler les pods d'un ReplicaSet

Vous pouvez supprimer les pods d'un ReplicaSet en modifiant leurs labels. Cette technique peut être utilisée pour enlever les pods pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés (en supposant que le nombre de réplicas n’est pas également modifié).

Scaling d'un ReplicaSet

Un ReplicaSet peut facilement être scalé en mettant simplement à jour le champ .spec.replicas. Le contrôleur ReplicaSet garantit que le nombre souhaité de pods avec un sélecteur de label correspondant soient disponibles et opérationnels.

ReplicaSet en tant que Horizontal Pod Autoscaler Target

Un ReplicaSet peut également être une cible pour Horizontal Pod Autoscalers (HPA). Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible le ReplicaSet que nous avons créé dans l'exemple précédent.

controllers/hpa-rs.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    kind: ReplicaSet
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Enregistrer ce manifeste dans hpa-rs.yaml et le soumettre à un cluster Kubernetes devrait créer le HPA défini qui scale automatiquement le ReplicaSet cible en fonction de l'utilisation du processeur des pods répliqués.

kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml

Vous pouvez aussi utiliser la commande kubectl autoscale pour accomplir la même chose. (et c'est plus facile !)

kubectl autoscale rs frontend --max=10

Alternatives au ReplicaSet

Deployment (recommandé)

Le Deployment est un object qui peut posséder les ReplicaSets et les mettres à jour ainsi que leurs Pods de façon déclarative, côté serveur et avec des rolling updates.

Alors que les ReplicaSets peuvent être utilisés indépendamment, ils sont principalement utilisés aujourd'hui par Deployments comme mécanisme pour orchestrer la création, suppresion et mises à jour des Pods. Lorsque vous utilisez des Deployments, vous n’aurez plus à vous soucier de la gestion des ReplicaSets ainsi créés. Les déploiements possèdent et gèrent leurs ReplicaSets. C'est pourquoi il est recommandé d’utiliser les déploiements lorsque vous voulez des ReplicaSets.

Pods nus

Contrairement au cas où un utilisateur a créé directement des pods, un ReplicaSet remplace les pods supprimés ou terminés pour quelque raison que ce soit, par exemple en cas de défaillance d'un nœud ou de maintenance de nœud perturbateur, telle qu'une mise à jour kernel. Pour cette raison, nous vous recommandons d'utiliser un ReplicaSet même si votre application ne nécessite qu'un seul pod. Pensez-y de la même manière qu’un superviseur de processus, mais il supervise plusieurs pods sur plusieurs nœuds au lieu de processus individuels sur un seul nœud. Un ReplicaSet délègue les redémarrages de conteneurs locaux à un agent du nœud (par exemple, Kubelet ou Docker).

Job

Utilisez un Job au lieu d'un ReplicaSet pour les pods qui doivent se terminer seuls (c'est à dire des batch jobs).

DaemonSet

Utilisez un DaemonSet au lieu d’un ReplicaSet pour les pods qui fournissent une fonction au niveau du noeud, comme le monitoring ou la gestion des logs de ce noeud. Ces pods ont une durée de vie qui est liée durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont sûrs de se terminer lorsque la machine est prête à être redémarrée/arrêtée.

ReplicationController

Les ReplicaSets sont les successeurs de ReplicationControllers. Les deux servent le même objectif et se comportent de la même manière, à la différence près que ReplicationController ne prend pas en charge les les exigences de sélecteur décrites dans le labels user guide. En tant que tels, les ReplicaSets sont préférés aux ReplicationControllers.

4.2.2 - Déploiements

Un Deployment (déploiement en français) fournit des mises à jour déclaratives pour Pods et ReplicaSets.

Vous décrivez un état désiré dans un déploiement et le controlleur déploiement change l'état réel à l'état souhaité à un rythme contrôlé. Vous pouvez définir des Deployments pour créer de nouveaux ReplicaSets, ou pour supprimer des déploiements existants et adopter toutes leurs ressources avec de nouveaux déploiements.

Cas d'utilisation

Voici des cas d'utilisation typiques pour les déploiements:

• Créer un déploiement pour déployer un ReplicaSet. Le ReplicaSet crée des pods en arrière-plan. Vérifiez l'état du déploiement pour voir s'il réussit ou non.
• Déclarez le nouvel état des Pods en mettant à jour le PodTemplateSpec du déploiement. Un nouveau ReplicaSet est créé et le déploiement gère le déplacement des pods de l'ancien ReplicaSet vers le nouveau à un rythme contrôlé. Chaque nouveau ReplicaSet met à jour la révision du déploiement.
• Revenir à une révision de déploiement antérieure si l'état actuel du déploiement n'est pas stable. Chaque restauration met à jour la révision du déploiement.
• Augmentez le déploiement pour traiter plus de charge.
• Suspendre le déploiement d'appliquer plusieurs correctifs à son PodTemplateSpec, puis de le reprendre pour démarrer un nouveau déploiement.
• Utiliser l'état du déploiement comme indicateur qu'un déploiement est bloqué.
• Nettoyer les anciens ReplicaSets dont vous n'avez plus besoin.

Création d'un déploiement

Voici un exemple de déploiement. Il crée un ReplicaSet pour faire apparaître trois pods nginx: