Explication des ressources Kubernetes –

Kubernetes n’est pas connu pour être accessible. Pour maîtriser Kubernetes, vous devez comprendre comment ses abstractions s’emboîtent. Kubernetes est fourni avec des dizaines de types de ressources que vous pouvez utiliser dans vos applications. Regardons les rôles des ressources les plus fréquemment utilisées.

Pods

S’il y a un terme Kubernetes à apprendre, c’est « Pod ». Les pods sont l’unité de calcul fondamentale utilisée par Kubernetes. Ils hébergent vos conteneurs en cours d’exécution. Pour cette raison, il est courant de comparer un pod à une instance d’un conteneur Docker.

Cette ressemblance n’est pas exacte, car un seul pod Kubernetes peut contenir plusieurs conteneurs. Les pods sont mieux perçus comme un «groupe» de conteneurs ayant un contexte d’exécution partagé. L’environnement du Pod est isolé; les environnements de conteneurs individuels à l’intérieur sont en outre sous-isolés.

Les conteneurs d’un pod sont toujours planifiés sur le même nœud Kubernetes. Ils fonctionneront sur la même machine physique et pourront partager le stockage et les ressources réseau.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image:latest

Le manifeste ci-dessus créerait manuellement un seul pod. Le pod exécuterait un conteneur en utilisant le my-image:latest image.

Vous ne gérez normalement pas les pods directement dans Kubernetes. Les pods sont créés suite à l’ajout d’autres ressources, comme un déploiement (voir ci-dessous). Vous devez traiter vos pods comme des unités éphémères. Kubernetes contrôle le pod et peut le replanifier sur un autre nœud si les ressources du cluster sont limitées.

Ensembles de répliques

Ensembles de répliques (généralement écrits comme ReplicaSets, sans espace) sont une autre couche d’abstraction au-dessus des pods. Les ReplicaSets garantissent qu’il y aura un nombre spécifique de pods identiques en cours d’exécution à un moment donné.

Lorsque vous utilisez des ReplicaSets, vous devez appliquer un nombre minimum de pods pour votre application. Vous spécifiez le nombre de pods à exécuter simultanément. Kubernetes planifie ensuite suffisamment de pods pour répondre à la disponibilité minimale que vous définissez. N’oubliez pas que chaque pod peut être composé de plusieurs conteneurs en cours d’exécution, selon la configuration de votre application.

Lorsqu’un pod est créé par un ReplicaSet, Kubernetes met à jour le pod metadata.ownerReferences champ pour inclure l’identité du ReplicaSet. Le ReplicaSet peut ensuite établir les pods qu’il contrôle, afin de savoir si l’objectif de disponibilité minimale a été atteint.

Les ReplicaSets ont un replicas champ qui définit le nombre de pods à exécuter. Modifiez cette valeur et appliquez le manifeste ReplicaSet mis à jour à votre cluster pour que Kubernetes replanifie vos pods pour qu’ils correspondent au nouveau nombre de réplicas.

Ce détail met en évidence un point important concernant les ReplicaSets: Kubernetes garantit uniquement le nombre de pods en cours d’exécution. finalement correspond au nombre de réplicas que vous avez spécifié. Si vous modifiez le nombre de réplicas, il y aura une période pendant laquelle plus ou moins de pods sont en cours d’exécution que ce que votre manifeste indique. Le ReplicaSet créera ou supprimera des pods jusqu’à ce que le nombre souhaité soit opérationnel.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
  labels:
    my-label: my-value
spec:
  replicas: 3
  selector:
    matchLabels:
      my-label: my-value
  template:
    metadata:
      labels:
        my-label: my-value
    spec:
      containers:
        - name: app-container
          image: my-image:latest

Le manifeste ci-dessus exécuterait trois répliques du my-image:latest image de conteneur à l’aide d’un ReplicaSet. Vous pouvez modifier le nombre de répliques en mettant à jour la valeur dans le manifeste et en la réappliquant (kubectl apply -f my-manifest.yml).

Déploiements

Bien que les ReplicaSets facilitent le travail avec les pods, ils sont également rarement utilisés directement. Déploiements sont une abstraction au sommet des ReplicaSets. Vous créez généralement un déploiement lors de l’ajout d’une nouvelle charge de travail dans un cluster.

Les ressources de déploiement permettent des mises à jour déclaratives des pods et des ReplicaSets. Ils vous permettent d’effectuer des mises à jour progressives des ReplicaSets, où les pods sont replanifiés sans interruption de service. Les pods et les ReplicaSets sont remplacés individuellement, ce qui permet aux anciennes et nouvelles versions de coexister brièvement.

Le besoin de déploiements est né de l’approche historique de Kubernetes en matière de réplicas. Les ReplicaSets ont évolué à partir des contrôleurs de réplication. Les contrôleurs de réplication offraient des fonctionnalités similaires aux ReplicaSets, mais avec une prise en charge de la mise à l’échelle intégrée.

Cependant, les contrôleurs de réplication n’offraient pas de mise à l’échelle déclarative. Vous deviez utiliser manuellement kubectl rolling-update pour mettre à l’échelle les répliques sans temps d’arrêt. Cela était en contradiction avec l’approche déclarative basée sur les manifestes des autres ressources Kubernetes.

Par rapport aux ReplicaSets, le principal avantage des déploiements est leur prise en charge des mises à jour progressives. La modification du nombre de répliques dans un ReplicaSet ne garantit pas qu’un nombre de pods restera dans un état donné pendant le déploiement. Avec un déploiement, vous pouvez être sûr que votre application continuera à gérer le trafic, même si le déploiement n’est pas encore terminé.

Aujourd’hui, Kubernetes conseille d’utiliser les déploiements pour représenter vos charges de travail. Vos déploiements seront exécutés et mis à l’échelle automatiquement les ReplicaSets; ReplicaSets gérera à son tour vos pods. Vous pouvez effectuer une mise à jour progressive d’un déploiement en mettant à jour le replicas champ dans son manifeste. Kubernetes s’assurera alors que votre application reste disponible tout au long du changement, permettant aux nouveaux et anciens pods de coexister temporairement.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    my-label: my-value
spec:
  replicas: 3
  selector:
    matchLabels:
      my-label: my-value
  template:
    metadata:
      labels:
        my-label: my-value
    spec:
      containers:
        - name: app-container
          image: my-image:latest

Le manifeste ci-dessus créerait un déploiement composé de trois réplicas, chacun exécutant le my-image:latest image du conteneur. Changer le replicas value déclencherait une mise à jour continue des ReplicaSets et des pods sous-jacents.

Autres types de ressources

Les trois types de ressources que nous avons examinés sont les objets les plus courants que vous rencontrerez lorsque vous travaillez avec Kubernetes. Ils permettent de configurer les charges de travail de votre application et de gérer vos conteneurs.

Vous devrez utiliser d’autres types de types de ressources au fur et à mesure que vous travaillerez davantage avec Kubernetes. ConfigMaps et Secrets vous permettent d’injecter la configuration dans vos pods, leur permettant d’accéder à des valeurs extérieures. Les volumes et les volumes persistants fournissent aux pods un système de fichiers inscriptible partagé qui peut être utilisé pour stocker des données, au lieu du stockage éphémère par défaut qui est perdu lorsque le pod se ferme.

Un autre ensemble de ressources permet de gérer les options de mise en réseau de votre charge de travail. Les services vous permettent d’exposer un ensemble de pods en tant que service réseau unique avec une seule adresse IP. Les entrées vous permettent d’exposer des services en externe. Ils acheminent le trafic vers votre cluster vers un service de destination en fonction d’attributs tels que le nom d’hôte, le port et le chemin d’URL.

Enfin, il existe des méta-ressources qui décrivent votre cluster. Les espaces de noms sont utilisés pour isoler les charges de travail individuelles, évitant ainsi les collisions de noms. Vous devez généralement créer un nouvel espace de noms pour chacune de vos charges de travail indépendantes. Les nœuds sont une sorte de ressource qui représente les machines physiques exécutant vos pods. Chaque nœud hébergera généralement plusieurs pods. Kubernetes détermine comment planifier les charges de travail en fonction de la disponibilité de chaque nœud et des contraintes que vous appliquez.

Vous pouvez afficher la liste complète des ressources de votre cluster en exécutant kubectl api-resources. En plus des ressources intégrées, les charges de travail peuvent ajouter leurs propres définitions de ressources personnalisées (CRD) qui vous permettent de créer de nouveaux types d’objets. Kubernetes fournit automatiquement des points de terminaison d’API pour les définitions de ressources personnalisées.

Conclusion

Apprendre Kubernetes signifie se familiariser avec de nouvelles abstractions et terminologies. Bien que cela donne une large surface d’API, chaque objet Kubernetes a un objectif relativement restreint.

Vous pourrez souvent vous en tenir aux abstractions de haut niveau telles que les déploiements. Vous ne devriez pas avoir besoin de micro-gérer les types de ressources fondamentales, comme les pods, sauf si vous avez des exigences complexes qui ne peuvent pas être résolues avec les déploiements et les ReplicaSets seuls.