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 :