Mastering Kubernetes Objets

Vous avez déjà appris les composants de base d'un cluster Kubernetes. Dans cette leçon, vous allez découvrir les objets Kubernetes et comment ils fonctionnent ensemble.

Les objets Kubernetes sont des entités qui sont rendues persistantes dans le cluster Kubernetes. Plus précisément, elles sont conservées dans le stockage à valeur clé etcd. Les objets Kubernetes peuvent représenter un large éventail de ressources différentes, telles que les modules, les services, les déploiements, etc.

Ces objets sont définis à l'aide du format YAML ou JSON et peuvent être gérés à l'aide de l'API Kubernetes RESTful, qui est exposée par le composant kube-apiserver du plan de contrôle Kubernetes. Cela signifie que vous pouvez créer, mettre à jour, supprimer et interroger des objets à l'aide de l'API.

Voici un exemple de demande d'extraction d'informations sur un objet Pod :

1
GET https://<kubernetes-cluster>.com/api/v1/namespaces/<namespace>/pods/<pod-name>

Chaque objet Kubernetes est défini dans un fichier de configuration au format YAML ou JSON. Le fichier de configuration contient la spécification de l'objet de manière déclarative. Cela vous permet de définir l'état souhaité de l'objet. Kubernetes vérifie alors de façon permanente si l'état réel de l'objet correspond à l'état souhaité. Si ce n'est pas le cas, Kubernetes tente de faire correspondre l'état réel à l'état souhaité. C'est ce que l'on appelle la boucle de rapprochement.

Un objet Kubernetes Pod simple est déclaré comme suit :

12345678
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
    containers:
    - name: my-container
      image: nginx:1.21.3

Découvrons les différentes parties de l'objet Pod :

• La zone apiVersion indique la version de l'API Kubernetes utilisée pour définir l'objet. Chaque objet peut avoir différentes versions d'API.
• Le champ kind indique le type de l'objet Kubernetes.
• La zone de métadonnées contient les métadonnées de l'objet.
• La zone Spécification contient la spécification de l'objet. La zone de spécification est différente pour chaque type d'objet. Par exemple, la zone Spécification d'un objet Pod contient la spécification des conteneurs qui font partie du pod.

Il s'agit des zones obligatoires d'un objet Kubernetes. Cependant, vous pouvez également ajouter des zones supplémentaires à l'objet.

L'objet décrit ci-dessus crée un Pod portant le nom my-pod qui contient un seul conteneur portant le nom my-container. Le conteneur utilise l'image nginx dans la version 1.21.3.

Il y a quelques objets de base que vous pouvez trouver dans presque tous les clusters de Kubernetes. Voir une synthèse des objets Kubernetes les plus importants :

Pods

Comme introduit précédemment, les pods sont les plus petites unités déployables dans Kubernetes et sont un enveloppeur mince autour d'un ou plusieurs conteneurs. Les modules sont toujours planifiés vers des nœuds. Les modules peuvent être créés, mis à jour et supprimés à l'aide de l'API Kubernetes.

L'exécution de plusieurs conteneurs dans un seul pod est un anti-motif. La raison principale est qu'il rend la mise à l'échelle et la mise à jour des conteneurs plus difficiles. Il est également plus difficile de gérer les conteneurs car ils sont étroitement couplés. Par exemple, un Pod exécute deux conteneurs, comme un serveur Web et une base de données. Si vous souhaitez mettre à l'échelle le serveur Web, vous devez également mettre à l'échelle la base de données, même si cela n'est pas nécessaire.

Cependant, il existe plusieurs scénarios courants dans lesquels il est judicieux d'exécuter plusieurs conteneurs dans un seul pod. Par exemple, si vous voulez exécuter un conteneur sidecar qui fournit des fonctionnalités supplémentaires au conteneur principal, telles que la journalisation, la surveillance ou le trafic proxy. Nous examinerons les injections de sidecar plus en détail plus tard, alors que nous regardons les mailles de service avec Istio.

Services

Les services regroupent un ensemble de modules et fournissent un point d'entrée stable pour y accéder. Le Service dans le diagramme suivant offre également des fonctionnalités d'équilibrage de charge qui répartissent le trafic entre plusieurs modules. Les modules sont regroupés à l'aide d'étiquettes et de sélecteurs, que nous examinerons plus tard.

Cela est particulièrement utile lorsqu'une application est mise à l'échelle pour s'exécuter sur plusieurs modules d'un cluster, car le service peut efficacement regrouper et fournir un point d'entrée stable pour y accéder.

Astuce

Un service Kubernetes expose les modules d'application en tant que service réseau avec un nom DNS et une adresse IP cohérents à l'intérieur d'un cluster Kubernetes. Pour exposer le service Kubernetes interne à Internet, vous devez créer la ressource personnalisée APIRule. Cette approche est similaire à la création d'itinéraires dans l'exécution Cloud Foundry. Vous en apprendrez plus sur l'exposition des services dans le chapitre Découverte des services à Kubernetes.

ReplicaSets

ReplicaSet est un ensemble de modules d'un type spécifique qui s'exécutent à l'échelle du cluster à tout moment. Le ReplicaSet garantit que le nombre souhaité de modules est toujours en cours d'exécution. Si un module est supprimé, le ReplicaSet crée un nouveau module pour le remplacer. Cette validation est effectuée dans la boucle de rapprochement, qui compare l'état souhaité (le nombre de modules) à l'état réel (le nombre de modules en cours d'exécution). Les ReplicaSets sont un bon moyen d'assurer la haute disponibilité des applications et d'utiliser les capacités d'auto-guérison de Kubernetes.

Remarque

Il est également important de savoir que le ReplicaSet ne possède pas les Pods. Au lieu de cela, il est responsable de s'assurer que le nombre souhaité de modules est en cours d'exécution. Si vous supprimez un module, le ReplicaSet crée un nouveau module pour le remplacer. Vous pouvez également supprimer le ReplicaSet sans supprimer les modules.

Déploiements

Les déploiements sont une abstraction de haut niveau en plus des ReplicaSets. Vous pouvez utiliser Déploiements pour définir de manière déclarative le statut souhaité de votre application. Cela inclut le nombre de répliques, les images du conteneur et d'autres configurations. Les déploiements gèrent les ReplicaSets et les ReplicaSets gèrent les Pods.

Avec Déploiements, vous pouvez déployer de nouvelles versions de votre application. Un tel déploiement est réalisé de manière très contrôlée. Le déploiement crée un ReplicaSet à côté de l'ancien. Ensuite, il lance un nouveau ReplicaSet et l'adapte au nombre de répliques souhaité. Une fois que le nouveau ReplicaSet est opérationnel, il commence à réduire l'ancien ReplicaSet. Cela garantit qu'au moins un ReplicaSet est toujours en cours d'exécution. C'est ce que l'on appelle une mise à jour continue et c'est une fonctionnalité puissante des Déploiements, car il s'agit d'un moyen sûr de déployer de nouvelles versions de vos applications sans temps d'arrêt (Déploiement Zero Downtime).

Astuce

Pour appliquer un déploiement dans Kyma, utilisez la commande kubectl apply -f deployment.yaml. Cette commande est similaire à la commande cf push dans l'exécution Cloud Foundry. Cependant, dans Kubernetes, le déploiement doit inclure des informations sur l’artefact (image Docker). La création et le stockage des artefacts ne sont pas requis dans l'exécution Cloud Foundry.

Remarque

Il existe de nombreux autres objets Kubernetes, dont certains seront abordés plus tard dans ce cours. Kubernetes est, en fait, également extensible. Vous pouvez définir vos objets personnalisés et étendre l'API Kubernetes à l'aide des CRD (Custom Resource Definitions).

Pour en savoir plus sur d'autres objets ou CRD, consultez la documentation officielle de Kubernetes.

Chaque objet Kubernetes peut être étiqueté avec des paires clé-valeur. Les étiquettes sont utilisées pour identifier les objets. Par exemple, vous pouvez étiqueter tous les modules d'une application particulière avec l'étiquette app: my-app.

Voici un exemple de la manière dont les services regroupent des modules. Les Services utilisent des sélecteurs d'étiquettes pour identifier les Modules qui doivent faire partie du Service. Un sélecteur d'étiquettes est une requête utilisée pour sélectionner des objets en fonction de leurs étiquettes. Par exemple, le sélecteur d'étiquettes app: my-app sélectionne tous les modules avec l'étiquette app: my-app.

Vous pouvez définir des étiquettes dans la section des métadonnées de la définition d'objet :

12345678910
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
    containers:
    - name: my-container
      image: nginx

Les annotations sont similaires aux étiquettes, mais, contrairement aux étiquettes, les annotations ne sont pas utilisées pour identifier, filtrer ou sélectionner des objets. Les annotations enrichissent l'objet avec des métadonnées sémantiques. En règle générale, différents outils utilisent des annotations pour stocker des détails supplémentaires sur l'objet.

Vous pouvez maintenant faire la distinction entre les différents objets Kubernetes et leur objectif. Vous savez également comment ils sont liés les uns aux autres et comment ils peuvent être étiquetés et regroupés dans des espaces noms.