Composants principaux d'un cluster Kubernetes

Kubernetes est une plateforme open source pour gérer des charges de travail et des services conteneurisés qui facilite la configuration déclarative et l’automatisation. Le nom Kubernetes provient du grec, signifiant barreur ou pilote. Il est portable ainsi qu’extensible et possède un écosystème en pleine croissance. Les services et outils de Kubernetes sont largement disponibles.

Dans cet article, nous allons passer en revue une vue d’ensemble des principaux composants de Kubernetes, de ce dont chaque conteneur est composé, à la manière dont un conteneur dans un pod est déployé et programmé sur chacun des travailleurs. Il est crucial de comprendre tous les détails du cluster Kubernetes afin de pouvoir déployer et concevoir une solution basée sur Kubernetes en tant qu’orchestrateur pour des applications conteneurisées.

Voici un bref aperçu des sujets que nous allons aborder dans cet article :

• Composants du panneau de contrôle
• Composants des travailleurs Kubernetes
• Pods comme éléments de base
• Services Kubernetes, équilibreurs de charge et contrôleurs Ingress
• Déploiements Kubernetes et ensembles de démons
• Stockage persistant dans Kubernetes

Le plan de contrôle Kubernetes

Les nœuds maîtres Kubernetes sont l’endroit où résident les services principaux du plan de contrôle ; tous les services n’ont pas besoin de résider sur le même nœud ; cependant, pour des raisons de centralisation et de praticité, ils sont souvent déployés de cette manière. Cela soulève évidemment des questions de disponibilité des services ; cependant, elles peuvent facilement être surmontées en ayant plusieurs nœuds et en fournissant des demandes d’équilibrage de charge pour obtenir un ensemble de nœuds maîtres hautement disponibles.

Les nœuds maîtres sont composés de quatre services de base :

• Le kube-apiserver
• Le kube-scheduler
• Le kube-controller-manager
• La base de données etcd

Les nœuds maîtres peuvent fonctionner sur des serveurs physiques, des machines virtuelles, ou un cloud privé ou public, mais il n’est pas recommandé d’exécuter des charges de travail de conteneurs sur eux. Nous en verrons plus à ce sujet plus tard.

Le diagramme suivant montre les composants des nœuds maîtres Kubernetes :

Le kube-apiserver

Le serveur API est ce qui relie tout ensemble. C’est l’API REST frontend du cluster qui reçoit des manifestes pour créer, mettre à jour et supprimer des objets API tels que des services, des pods, Ingress, et d’autres.

Le kube-apiserver est le seul service avec lequel nous devrions communiquer ; c’est également le seul qui écrit et communique avec la base de données etcd pour enregistrer l’état du cluster. Avec la commande kubectl, nous enverrons des commandes pour interagir avec lui. Cela sera notre couteau suisse en ce qui concerne Kubernetes.

Le kube-controller-manager

Le démon kube-controller-manager, en résumé, est un ensemble de boucles de contrôle infinies qui sont livrées pour la simplicité dans un seul binaire. Il surveille l’état désiré défini du cluster et s’assure qu’il est réalisé et satisfait en déplaçant tous les éléments nécessaires pour y parvenir. Le kube-controller-manager n’est pas qu’un seul contrôleur ; il contient plusieurs boucles différentes qui surveillent différents composants dans le cluster. Certains d’entre eux sont le contrôleur de service, le contrôleur de namespace, le contrôleur de compte de service, et bien d’autres. Vous pouvez trouver chaque contrôleur et sa définition dans le dépôt GitHub de Kubernetes : https://github.com/kubernetes/kubernetes/tree/master/pkg/controller.

Le kube-scheduler

Le kube-scheduler programme vos nouveaux pods créés sur des nœuds avec suffisamment d’espace pour satisfaire les besoins en ressources des pods. Il écoute essentiellement le kube-apiserver et le kube-controller-manager pour les nouveaux pods créés qui sont mis dans une file d’attente et ensuite programmés sur un nœud disponible par le planificateur. La définition du kube-scheduler peut être trouvée ici : https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler.

En plus des ressources de calcul, le kube-scheduler lit également les règles d’affinité et d’anti-affinité des nœuds pour déterminer si un nœud peut ou ne peut pas exécuter ce pod.

La base de données etcd

La base de données etcd est un magasin clé-valeur très fiable et cohérent utilisé pour stocker l’état du cluster Kubernetes. Elle contient l’état actuel des pods sur lesquels le nœud fonctionne, combien de nœuds le cluster a actuellement, quel est l’état de ces nœuds, combien de répliques de déploiement sont en cours d’exécution, les noms des services, et d’autres.

Comme nous l’avons mentionné précédemment, seul le kube-apiserver communique avec la base de données etcd. Si le kube-controller-manager a besoin de vérifier l’état du cluster, il passera par le serveur API afin d’obtenir l’état de la base de données etcd, au lieu d’interroger directement le magasin etcd. Il en va de même pour le kube-scheduler si le planificateur doit faire savoir qu’un pod a été arrêté ou attribué à un autre nœud ; il informera le serveur API, et le serveur API stockera l’état actuel dans la base de données etcd.

Avec etcd, nous avons couvert tous les principaux composants de nos nœuds maîtres Kubernetes afin que nous soyons prêts à gérer notre cluster. Mais un cluster n’est pas seulement composé de maîtres ; nous avons encore besoin des nœuds qui effectueront le travail lourd en exécutant nos applications.

Nœuds de travail Kubernetes

Les nœuds de travail qui effectuent cette tâche dans Kubernetes sont simplement appelés nœuds. Auparavant, vers 2014, ils étaient appelés minions, mais ce terme a ensuite été remplacé par simplement nœuds, car le nom était confus avec les terminologies de Salt et faisait penser aux gens que Salt jouait un rôle majeur dans Kubernetes.

Ces nœuds sont le seul endroit où vous exécuterez des charges de travail, car il n’est pas recommandé d’avoir des conteneurs ou des charges sur les nœuds maîtres, car ils doivent être disponibles pour gérer l’ensemble du cluster. Les nœuds sont très simples en termes de composants ; ils n’ont besoin que de trois services pour remplir leur tâche :

• Kubelet
• Kube-proxy
• Runtime de conteneur

Explorons ces trois composants un peu plus en profondeur.

Le kubelet

Le kubelet est un composant Kubernetes de bas niveau et l’un des plus importants après le kube-apiserver ; ces deux composants sont essentiels pour le provisionnement de pods/conteneurs dans le cluster. Le kubelet est un service qui s’exécute sur les nœuds Kubernetes et écoute le serveur API pour la création de pods. Le kubelet est uniquement chargé de démarrer/arrêter et de s’assurer que les conteneurs dans les pods sont sains ; le kubelet ne pourra pas gérer des conteneurs qui n’ont pas été créés par lui.

Le kubelet atteint ses objectifs en parlant au runtime de conteneur via l’interface de runtime de conteneur (CRI). La CRI fournit une possibilité de branchement au kubelet via un client gRPC, capable de communiquer avec différents runtimes de conteneurs. Comme nous l’avons mentionné précédemment, Kubernetes prend en charge plusieurs runtimes de conteneurs pour déployer des conteneurs, et c’est ainsi qu’il parvient à un tel support diversifié pour différents moteurs.

Vous pouvez consulter le code source du kubelet via https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet.

Le kube-proxy

Le kube-proxy est un service qui réside sur chaque nœud du cluster et est celui qui rend possibles les communications entre les pods, les conteneurs et les nœuds. Ce service surveille le kube-apiserver pour les changements sur les services définis (un service est une sorte d’équilibreur de charge logique dans Kubernetes ; nous approfondirons les services plus tard dans cet article) et maintient le réseau à jour via des règles iptables qui redirigent le trafic vers les points de terminaison corrects. Kube-proxy configure également des règles dans iptables qui effectuent un équilibrage de charge aléatoire entre les pods derrière un service.

Voici un exemple d’une règle iptables créée par le kube-proxy :

-A KUBE-SERVICES -d 10.0.162.61/32 -p tcp -m comment –comment “default/example: n’a pas de points de terminaison” -m tcp –dport 80 -j REJECT –reject-with icmp-port-unreachable

Notez qu’il s’agit d’un service sans points de terminaison (aucun pod derrière lui).

Runtime de conteneur

Pour pouvoir démarrer des conteneurs, nous avons besoin d’un runtime de conteneur. C’est le moteur de base qui créera les conteneurs dans le noyau des nœuds pour que nos pods s’exécutent. Le kubelet communiquera avec ce runtime et démarrera ou arrêtera nos conteneurs à la demande.

Actuellement, Kubernetes prend en charge tout runtime de conteneur conforme à l’OCI, tel que Docker, rkt, runc, runsc, etc.

Vous pouvez vous référer à https://github.com/opencontainers/runtime-spec pour en savoir plus sur toutes les spécifications de la page Git-Hub de l’OCI.

Maintenant que nous avons exploré tous les composants principaux qui forment un cluster, examinons ce qui peut être fait avec eux et comment Kubernetes va nous aider à orchestrer et gérer nos applications conteneurisées.

Objets Kubernetes

Les objets Kubernetes sont exactement cela : ce sont des objets ou abstractions logiques persistants qui représenteront l’état de votre cluster. Vous êtes celui qui doit dire à Kubernetes quel est l’état désiré de cet objet afin qu’il puisse travailler pour le maintenir et s’assurer que l’objet existe.

Pour créer un objet, il doit avoir deux choses : un état et sa spécification. L’état est fourni par Kubernetes, et c’est l’état actuel de l’objet. Kubernetes gérera et mettra à jour cet état au besoin pour être en accord avec votre état désiré. Le champ spécification, en revanche, est ce que vous fournissez à Kubernetes, et c’est ce que vous lui dites pour décrire l’objet que vous désirez. Par exemple, l’image que vous voulez que le conteneur exécute, le nombre de conteneurs de cette image que vous souhaitez exécuter, etc.

Chaque objet a des champs de spécification spécifiques pour le type de tâche qu’il effectue, et vous fournirez ces spécifications dans un fichier YAML qui est envoyé au kube-apiserver avec kubectl, qui le transforme en JSON et l’envoie comme une requête API. Nous approfondirons chaque objet et ses champs de spécification plus tard dans cet article.

Voici un exemple d’un YAML qui a été envoyé à kubectl :

cat << EOF | kubectl create -f -kind: ServiceapiVersion: v1metadata: Name: frontend-servicespec: selector: web: frontend ports: - protocol: TCP port: 80 targetPort: 9256EOF

Les champs de base de la définition de l’objet sont les tout premiers, et ceux-ci ne varieront pas d’un objet à l’autre et sont très explicites. Jetons un coup d’œil rapide à eux :

• kind : Le champ kind indique à Kubernetes quel type d’objet vous définissez : un pod, un service, un déploiement, etc.
• apiVersion : Étant donné que Kubernetes prend en charge plusieurs versions d’API, nous devons spécifier un chemin d’API REST auquel nous voulons envoyer notre définition.
• metadata : C’est un champ imbriqué, ce qui signifie que vous avez plusieurs sous-champs dans metadata, où vous écrirez des définitions de base telles que le nom de votre objet, l’assignation à un namespace spécifique, et également taguer une étiquette pour relier votre objet à d’autres objets Kubernetes.

Ainsi, nous avons maintenant parcouru les champs les plus utilisés et leur contenu ; vous pouvez en savoir plus sur les conventions API de Kubernetes à https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md

Certains des champs de l’objet peuvent être modifiés après la création de l’objet, mais cela dépendra de l’objet et du champ que vous souhaitez modifier.

Voici une courte liste des divers objets Kubernetes que vous pouvez créer :

• Pod
• Volume
• Service
• Déploiement
• Ingress
• Secret
• ConfigMap

Et il y en a beaucoup d’autres.

Examinons de plus près chacun de ces éléments.

Pods – la base de Kubernetes

Les pods sont les objets les plus basiques dans Kubernetes et aussi les plus importants. Tout tourne autour d’eux ; nous pouvons dire que Kubernetes est pour les pods ! Tous les autres objets sont là pour les servir, et toutes les tâches qu’ils effectuent visent à faire en sorte que les pods atteignent votre état désiré.

Alors, qu’est-ce qu’un pod et pourquoi les pods sont-ils si importants ?

Un pod est un objet logique qui exécute un ou plusieurs conteneurs ensemble sur le même espace de noms réseau, la même communication inter-processus (IPC), et, parfois, selon la version de Kubernetes, le même espace de noms ID de processus (PID). C’est parce qu’ils sont ceux qui vont exécuter nos conteneurs et donc seront au centre de l’attention. L’objectif principal de Kubernetes est d’être un orchestrateur de conteneurs, et avec les pods, nous rendons l’orchestration possible.

Comme nous l’avons mentionné précédemment, les conteneurs dans le même pod vivent dans une “bulle” où ils peuvent communiquer entre eux via localhost, car ils sont locaux les uns aux autres. Un conteneur dans un pod a la même adresse IP que l’autre conteneur car ils partagent un espace de noms réseau, mais dans la plupart des cas, vous exécuterez sur une base un à un, c’est-à-dire un seul conteneur par pod. Plusieurs conteneurs par pod ne sont utilisés que dans des scénarios très spécifiques, comme lorsque une application nécessite un auxiliaire tel qu’un pousseur de données ou un proxy qui doit communiquer de manière rapide et résiliente avec l’application principale.

La manière dont vous définissez un pod est la même que pour tout autre objet Kubernetes : via un YAML qui contient toutes les spécifications et définitions du pod :

kind: PodapiVersion: v1metadata:name: hello-podlabels: hello: podspec: containers: - name: hello-container image: alpine args: - echo - “Hello World”

Examinons les définitions de base du pod nécessaires sous le champ spécification pour créer notre pod :

• Containers : Un conteneur est un tableau ; par conséquent, nous avons un ensemble de plusieurs sous-champs sous celui-ci. En gros, c’est ce qui définit les conteneurs qui vont s’exécuter sur le pod. Nous pouvons spécifier un nom pour le conteneur, l’image dont il va être dérivé, et les arguments ou la commande que nous avons besoin qu’il exécute. La différence entre les arguments et les commandes est la même que la différence entre CMD et ENTRYPOINT. Prenez note que tous les champs que nous venons de parcourir sont pour le tableau des conteneurs. Ils ne font pas directement partie de la spécification du pod.
• restartPolicy : Ce champ est exactement cela : il indique à Kubernetes quoi faire avec un conteneur, et il s’applique à tous les conteneurs dans le pod en cas de code de sortie zéro ou non zéro. Vous pouvez choisir entre les options, Never, OnFailure ou Always. Always sera la valeur par défaut si une restartPolicy n’est pas définie.

Ce sont les spécifications les plus basiques que vous allez déclarer sur un pod ; d’autres spécifications nécessiteront que vous ayez un peu plus de connaissances sur la façon de les utiliser et comment elles interagissent avec divers autres objets Kubernetes. Nous les reverrons plus tard dans cet article ; certaines d’entre elles sont les suivantes :

• Volume
• Env
• Ports
• dnsPolicy
• initContainers
• nodeSelector
• Limites et demandes de ressources

Pour voir les pods qui sont actuellement en cours d’exécution dans votre cluster, vous pouvez exécuter kubectl get pods :

dsala@MININT-IB3HUA8:~$ kubectl get podsNAME READY STATUS RESTARTS AGEbusybox 1/1 Running 120 5d

Alternativement, vous pouvez exécuter kubectl describe pods sans spécifier de pod. Cela imprimera une description de chaque pod en cours d’exécution dans le cluster. Dans ce cas, ce ne sera que le pod busybox, car c’est le seul qui fonctionne actuellement :

dsala@MININT-IB3HUA8:~$ kubectl describe podsName: busyboxNamespace: defaultPriority: 0PriorityClassName: Node: aks-agentpool-10515745-2/10.240.0.6Start Time: Wed, 19 Sep 2018 14:23:30 -0600Labels: Annotations: Status: RunningIP: 10.244.1.7Containers: busybox:[…] (Sortie tronquée pour lisibilité)Events:Type Reason Age From Message—- —— —- —- ——-Normal Pulled 45s (x121 over 5d) kubelet, aks-agentpool-10515745-2 Container image “busybox” already present on machineNormal Created 44s (x121 over 5d) kubelet, aks-agentpool-10515745-2 Created containerNormal Started 44s (x121 over 5d) kubelet, aks-agentpool-10515745-2 Started container

Les pods sont mortels. Une fois qu’il meurt ou est supprimé, il ne peut pas être récupéré. Son IP et les conteneurs qui s’exécutaient dessus seront partis ; ils sont totalement éphémères. Les données sur les pods qui sont montées en tant que volume peuvent ou non survivre, selon la façon dont vous les avez configurées. Si nos pods meurent et que nous les perdons, comment pouvons-nous garantir que tous nos microservices fonctionnent ? Eh bien, les déploiements sont la réponse.

Déploiements

Les pods à eux seuls ne sont pas très utiles car il n’est pas très efficace d’avoir plus d’une seule instance de notre application exécutée dans un seul pod. Provisionner des centaines de copies de notre application sur différents pods sans avoir une méthode pour les rechercher toutes deviendra rapidement ingérable.

C’est là que les déploiements entrent en jeu. Avec les déploiements, nous pouvons gérer nos pods avec un contrôleur. Cela nous permet non seulement de décider combien nous voulons exécuter, mais nous pouvons également gérer les mises à jour en changeant la version de l’image ou l’image elle-même que nos conteneurs exécutent. Les déploiements sont ce avec quoi vous travaillerez la plupart du temps. Avec les déploiements ainsi que les pods et tout autre objet que nous avons mentionné précédemment, ils ont leur propre définition dans un fichier YAML :

apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: deployment: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

Commençons à explorer leur définition.

Au début du YAML, nous avons des champs plus généraux, tels que apiVersion, kind et metadata. Mais sous spec, c’est là que nous trouverons les options spécifiques pour cet objet API.

Sous spec, nous pouvons ajouter les champs suivants :

Selector : Avec le champ Selector, le déploiement saura quels pods cibler lorsque des changements sont appliqués. Il y a deux champs que vous utiliserez sous le sélecteur : matchLabels et matchExpressions. Avec matchLabels, le sélecteur utilisera les étiquettes des pods (paires clé/valeur). Il est important de noter que toutes les étiquettes que vous spécifiez ici seront ANDées. Cela signifie que le pod devra avoir toutes les étiquettes que vous spécifiez sous matchLabels.

Replicas : Cela indiquera le nombre de pods que le déploiement doit maintenir en cours d’exécution via le contrôleur de réplication ; par exemple, si vous spécifiez trois répliques, et qu’un des pods meurt, le contrôleur de réplication surveillera la spécification des répliques comme état désiré et informera le planificateur de programmer un nouveau pod, car l’état actuel est maintenant 2 puisque le pod est mort.

RevisionHistoryLimit : Chaque fois que vous apportez un changement au déploiement, ce changement est enregistré comme une révision du déploiement, que vous pouvez ensuite soit annuler à cet état précédent, soit garder un enregistrement de ce qui a été changé. Vous pouvez consulter votre historique avec kubectl rollout history deployment/. Avec revisionHistoryLimit, vous pouvez définir un nombre indiquant combien d’enregistrements vous souhaitez conserver.

Strategy : Cela vous permettra de décider comment vous souhaitez gérer toute mise à jour ou mise à l’échelle horizontale des pods. Pour écraser la valeur par défaut, qui est rollingUpdate, vous devez écrire la clé type, où vous pouvez choisir entre deux valeurs : recreate ou rollingUpdate.

Alors que recreate est un moyen rapide de mettre à jour votre déploiement, il supprimera tous les pods et les remplacera par de nouveaux, mais cela impliquera que vous devrez prendre en compte qu’un temps d’arrêt du système sera en place pour ce type de stratégie. Le rollingUpdate, en revanche, est plus fluide et plus lent et est idéal pour les applications à état qui peuvent rééquilibrer leurs données. Le rollingUpdate ouvre la porte à deux autres champs, qui sont maxSurge et maxUnavailable.

Le premier sera combien de pods au-dessus du nombre total que vous souhaitez lors de la mise à jour ; par exemple, un déploiement avec 100 pods et un maxSurge de 20 % augmentera jusqu’à un maximum de 120 pods lors de la mise à jour. La prochaine option vous permettra de sélectionner combien de pods en pourcentage vous êtes prêt à tuer afin de les remplacer par de nouveaux dans un scénario de 100 pods. Dans les cas où il y a 20 % maxUnavailable, seuls 20 pods seront tués et remplacés par de nouveaux avant de continuer à remplacer le reste du déploiement.

Template : C’est juste un champ de spécification de pod imbriqué où vous incluez toutes les spécifications et métadonnées des pods que le déploiement va gérer.

Nous avons vu qu’avec les déploiements, nous gérons nos pods, et ils nous aident à les maintenir dans un état que nous désirons. Tous ces pods sont toujours dans quelque chose appelé le réseau du cluster, qui est un réseau fermé dans lequel seuls les composants du cluster Kubernetes peuvent communiquer entre eux, ayant même leur propre ensemble de plages IP. Comment communiquons-nous avec nos pods de l’extérieur ? Comment atteignons-nous notre application ? C’est là que les services entrent en jeu.

Services :

Le nom service ne décrit pas entièrement ce que font réellement les services dans Kubernetes. Les services Kubernetes sont ce qui achemine le trafic vers nos pods. Nous pouvons dire que les services sont ce qui lie les pods ensemble.

Imaginons que nous avons une application typique de type frontend/backend où nous avons nos pods frontend parlant à nos pods backend via les adresses IP des pods. Si un pod dans le backend meurt, nous perdons la communication avec notre backend. Ce n’est pas seulement parce que le nouveau pod n’aura pas la même adresse IP que le pod qui est mort, mais maintenant nous devons également reconfigurer notre application pour utiliser la nouvelle adresse IP. Ce problème et des problèmes similaires sont résolus avec des services.

Un service est un objet logique qui indique au kube-proxy de créer des règles iptables basées sur les pods qui se trouvent derrière le service. Les services configurent leurs points de terminaison, qui est la manière dont les pods derrière un service sont appelés, de la même manière que les déploiements savent quels pods contrôler, le champ sélecteur, et les étiquettes des pods.

Ce diagramme vous montre comment les services utilisent des étiquettes pour gérer le trafic :

Les services ne feront pas seulement créer des règles pour acheminer le trafic par kube-proxy ; ils déclencheront également quelque chose appelé kube-dns.

Kube-dns est un ensemble de pods avec des conteneurs SkyDNS qui s’exécutent sur le cluster et fournissent un serveur DNS et un renvoyeur, qui créera des enregistrements pour les services et parfois pour les pods pour faciliter l’utilisation. Chaque fois que vous créez un service, un enregistrement DNS pointant vers l’adresse IP interne du cluster du service sera créé sous la forme service-name.namespace.svc.cluster.local. Vous pouvez en savoir plus sur les spécifications DNS de Kubernetes ici : https://github.com/kubernetes/dns/blob/master/docs/specification.md.

Revenons à notre exemple, nous n’aurons désormais qu’à configurer notre application pour parler au nom de domaine entièrement qualifié (FQDN) du service afin de communiquer avec nos pods backend. De cette manière, peu importe quelle adresse IP les pods et services ont. Si un pod derrière le service meurt, le service s’occupera de tout en utilisant l’enregistrement A, car nous pourrons dire à notre frontend de router tout le trafic vers my-svc. La logique du service s’occupera de tout le reste.

Il existe plusieurs types de services que vous pouvez créer chaque fois que vous déclarez l’objet à créer dans Kubernetes. Passons en revue chacun d’eux pour voir lequel sera le mieux adapté au type de travail dont nous avons besoin :

ClusterIP : C’est le service par défaut. Chaque fois que vous créez un service ClusterIP, il créera un service avec une adresse IP interne au cluster qui ne sera routable qu’à l’intérieur du cluster Kubernetes. Ce type est idéal pour les pods qui n’ont besoin de communiquer qu’entre eux et non de sortir du cluster.

NodePort : Lorsque vous créez ce type de service, par défaut, un port aléatoire de 30000 à 32767 sera alloué pour rediriger le trafic vers les pods de point de terminaison du service. Vous pouvez remplacer ce comportement en spécifiant un port de nœud dans le tableau des ports. Une fois cela défini, vous pourrez accéder à vos pods via :. Cela est utile pour accéder à vos pods depuis l’extérieur du cluster via l’adresse IP du nœud.

LoadBalancer : La plupart du temps, vous exécuterez Kubernetes sur un fournisseur de cloud. Le type LoadBalancer est idéal pour ces situations, car vous pourrez allouer des adresses IP publiques à votre service via l’API de votre fournisseur de cloud. C’est le service idéal lorsque vous souhaitez communiquer avec vos pods depuis l’extérieur de votre cluster. Avec LoadBalancer, vous pourrez non seulement allouer une adresse IP publique, mais également, en utilisant Azure, allouer une adresse IP privée de votre réseau privé virtuel. Ainsi, vous pouvez parler à vos pods depuis Internet ou en interne sur votre sous-réseau privé.

Examinons la définition YAML d’un service :

apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app: front-end type: NodePort ports: - name: http port: 80 targetPort: 8080 nodePort: 30024 protocol: TCP

Le YAML d’un service est très simple, et les spécifications varieront en fonction du type de service que vous créez. Mais la chose la plus importante à prendre en compte est les définitions de port. Examinons ces éléments :

• port : C’est le port du service qui est exposé
• targetPort : C’est le port sur les pods vers lequel le service envoie le trafic
• nodePort : C’est le port qui sera exposé

Bien que nous comprenions maintenant comment nous pouvons communiquer avec les pods dans notre cluster, nous devons encore comprendre comment nous allons gérer le problème de la perte de nos données chaque fois qu’un pod est terminé. C’est là que les Volumes Persistants (PV) entrent en jeu.

Kubernetes et stockage persistant

Le stockage persistant dans le monde des conteneurs est un problème sérieux. Le seul stockage qui est persistant à travers les exécutions de conteneurs est les couches de l’image, et elles sont en lecture seule. La couche où le conteneur s’exécute est en lecture/écriture, mais toutes les données dans cette couche sont supprimées une fois que le conteneur s’arrête. Avec les pods, c’est la même chose. Lorsque un conteneur meurt, les données écrites dessus sont perdues.

Kubernetes a un ensemble d’objets pour gérer le stockage à travers les pods. Le premier dont nous allons discuter est les volumes.

Volumes

Les volumes résolvent l’un des plus grands problèmes en matière de stockage persistant. Tout d’abord, les volumes ne sont pas réellement des objets, mais une définition de la spécification d’un pod. Lorsque vous créez un pod, vous pouvez définir un volume sous le champ spécification du pod. Les conteneurs dans ce pod pourront monter le volume sur leur espace de noms de montage, et le volume sera disponible à travers les redémarrages ou les pannes de conteneurs. Les volumes sont liés aux pods, cependant, et si le pod est supprimé, le volume disparaîtra également. La persistance des données sur le volume est une autre histoire ; la persistance des données dépendra de l’arrière-plan de ce volume.

Kubernetes prend en charge plusieurs types de volumes ou sources de volumes et comment ils sont appelés dans les spécifications API, qui vont des mappages de systèmes de fichiers du nœud local, des disques virtuels des fournisseurs de cloud, et des volumes basés sur du stockage défini par logiciel. Les montages de systèmes de fichiers locaux sont les plus courants que vous verrez en ce qui concerne les volumes réguliers. Il est important de noter que l’inconvénient de l’utilisation du système de fichiers local du nœud est que les données ne seront pas disponibles à travers tous les nœuds du cluster, mais seulement sur ce nœud où le pod a été programmé.

Examinons comment un pod avec un volume est défini en YAML :

apiVersion: v1kind: Podmetadata: name: test-pdspec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: path: /data type: Directory

Notez qu’il y a un champ appelé volumes sous spec et qu’il y a ensuite un autre appelé volumeMounts.

Le premier champ (volumes) est où vous définissez le volume que vous souhaitez créer pour ce pod. Ce champ nécessitera toujours un nom et ensuite une source de volume. Selon la source, les exigences seront différentes. Dans cet exemple, la source serait hostPath, qui est le système de fichiers local d’un nœud. hostPath prend en charge plusieurs types de mappages, allant des répertoires, fichiers, dispositifs de bloc, et même des sockets Unix.

Sous le deuxième champ, volumeMounts, nous avons mountPath, qui est où vous définissez le chemin à l’intérieur du conteneur où vous souhaitez monter votre volume. Le paramètre name est comment vous spécifiez au pod quel volume utiliser. Cela est important car vous pouvez avoir plusieurs types de volumes définis sous volumes, et le nom sera le seul moyen pour le pod de savoir lequel

Vous pouvez en savoir plus sur les différents types de volumes ici https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes et dans le document de référence API Kubernetes ( https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#volume-v1-core).

Avoir des volumes qui meurent avec les pods n’est pas idéal. Nous avons besoin d’un stockage qui persiste, et c’est ainsi que le besoin de PVs est apparu.

Volumes Persistants, Requêtes de Volumes Persistants, et Classes de Stockage

La principale différence entre les volumes et les PVs est que, contrairement aux volumes, les PVs sont en fait des objets API Kubernetes, vous pouvez donc les gérer individuellement comme des entités séparées, et donc ils persistent même après qu’un pod soit supprimé.

Vous vous demandez peut-être pourquoi cette sous-section a PV, volumes persistants requêtes (PVCs), et classes de stockage toutes mélangées. C’est parce que tous dépendent les uns des autres, et il est crucial de comprendre comment ils interagissent entre eux pour provisionner du stockage pour nos pods.

Commençons par les PVs et les PVCs. Comme les volumes, les PVs ont une source de stockage, donc le même mécanisme que les volumes s’applique ici. Vous aurez soit un cluster de stockage défini par logiciel fournissant un numéro d’unité logique (LUN), un fournisseur de cloud donnant des disques virtuels, ou même un système de fichiers local au nœud Kubernetes, mais ici, au lieu d’être appelés sources de volume, ils sont appelés types de volumes persistants à la place.

Les PVs sont à peu près comme des LUNs dans un tableau de stockage : vous les créez, mais sans mappage ; ce sont juste un tas de stockage alloué en attente d’être utilisé. Les PVCs sont comme des mappages de LUN : ils sont soutenus ou liés à un PV et sont également ce que vous définissez réellement, reliez, et rendez disponible au pod qu’il peut ensuite utiliser pour ses conteneurs.

La manière dont vous utilisez les PVCs sur les pods est exactement la même que pour les volumes normaux. Vous avez deux champs : un pour spécifier quel PVC vous souhaitez utiliser, et l’autre pour indiquer au pod sur quel conteneur utiliser ce PVC.

Le YAML pour une définition d’objet API PVC devrait avoir le code suivant :

apiVersion: v1kind: PersistentVolumeClaimmetadata: name: gluster-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi

Le YAML pour le pod devrait avoir le code suivant :

kind: PodapiVersion: v1metadata: name: mypodspec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: “/mnt/gluster” name: volume volumes: - name: volume persistentVolumeClaim: claimName: gluster-pvc

Lorsqu’un administrateur Kubernetes crée un PVC, il y a deux manières dont cette demande est satisfaite :

• Statique : Plusieurs PVs ont déjà été créés, et lorsque un utilisateur crée un PVC, tout PV disponible qui peut satisfaire les exigences sera lié à ce PVC.
• Dynamique : Certains types de PV peuvent créer des PVs basés sur les définitions de PVC. Lorsque le PVC est créé, le type de PV créera dynamiquement un objet PV et allouera le stockage dans l’arrière-plan ; c’est le provisionnement dynamique. Le hic avec le provisionnement dynamique est que vous avez besoin d’un troisième type d’objet de stockage Kubernetes, appelé classe de stockage.

Les classes de stockage sont comme une manière de classer votre stockage. Vous pouvez créer une classe qui provisionne des volumes de stockage lents, ou une autre avec des disques SSD hyper-rapides. Cependant, les classes de stockage sont un peu plus complexes que de simplement classer. Comme nous l’avons mentionné dans les deux manières de créer des PVC, les classes de stockage sont ce qui rend le provisionnement dynamique possible. Lorsque vous travaillez dans un environnement cloud, vous ne voulez pas créer manuellement chaque disque d’arrière-plan pour chaque PV. Les classes de stockage mettront en place quelque chose appelé provisionneur, qui invoque le plug-in de volume nécessaire pour communiquer avec l’API de votre fournisseur de cloud. Chaque provisionneur a ses propres paramètres afin qu’il puisse communiquer avec le fournisseur de cloud ou de stockage spécifié.

Vous pouvez provisionner des classes de stockage de la manière suivante ; voici un exemple d’une classe de stockage utilisant Azure-disk comme provisionneur de disque :

kind: StorageClassapiVersion: storage.k8s.io/v1metadata: name: my-storage-classprovisioner: kubernetes.io/azure-diskparameters: storageaccounttype: Standard_LRS kind: Shared

Chaque provisionneur de classe de stockage et type de PV aura des exigences et des paramètres différents, tout comme les volumes, et nous avons déjà eu un aperçu général de leur fonctionnement et de leur utilisation. Apprendre sur des classes de stockage spécifiques et des types de PV dépendra de votre environnement ; vous pouvez en savoir plus sur chacun d’eux en cliquant sur les liens suivants :

• https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner
• https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

Dans cet article, nous avons appris ce qu’est Kubernetes, ses composants, et quels sont les avantages de l’utilisation de l’orchestration. Avec cela, identifier chacun des objets API Kubernetes, leur but et leurs cas d’utilisation devrait être facile. Vous devriez maintenant être capable de comprendre comment les nœuds maîtres contrôlent le cluster et la planification des conteneurs dans les nœuds de travail.

Si vous avez trouvé cet article utile, ‘ Hands-On Linux for Architects ’ devrait vous être utile. Avec ce livre, vous couvrirez tout, des composants et fonctionnalités Linux au support matériel et logiciel, ce qui vous aidera à mettre en œuvre et à ajuster des solutions basées sur Linux efficaces. Vous serez guidé à travers un aperçu de la méthodologie de conception Linux et des concepts fondamentaux de la conception d’une solution. Si vous êtes un administrateur système Linux, un ingénieur de support Linux, un ingénieur DevOps, un consultant Linux ou toute personne cherchant à apprendre ou à élargir ses connaissances en architecture, ce livre est pour vous.