‫Jusqu'ici, avec Kubernetes, nous n'avons pas vraiment parlé de stockage
‫ou de volumes.
‫Vous avez traité de cela avec Docker, puis
‫avec Compose, et Swarm et, dans une certaine mesure, c'est la
‫même chose à Kubernetes.
‫Vous avez des conteneurs, et nous supposons qu'ils sont apatrides,
‫ce qui signifie que lorsque vous jetez le conteneur,
‫tout ce qu'il contient s'en va.
‫Lorsque vous remplacez un conteneur par une mise à jour, ou que
‫vous modifiez quelque chose et que vous l'appliquez avec une application kubectl, vous perdez le conteneur, vous perdez
‫tout ce qu'il contient.
‫De toute évidence, Kubernetes, tout comme les autres
‫orchestrateurs, doit avoir un moyen de conserver
‫les données persistantes. C'est même plus que les volumes eux-mêmes.
‫Même les conteneurs et les déploiements peuvent être différents dans Kubernetes
‫avec ce qu'on appelle un StatefulSets.
‫Ce sont des ressources différentes
‫des déploiements.
‫Ils sont essentiellement conçus autour de bases de données et d'objets nécessitant beaucoup
‫plus de persistance, y compris le même nom,
‫les mêmes adresses IP, etc.
‫Nous n’avons pas eu cette opportunité avec
‫Swarm ou Docker.
‫Cela ne vous permettait pas vraiment de conserver
‫ces différents attributs entre les conteneurs.
‫StatefulSets est une nouvelle fonctionnalité de
‫Kubernetes qui existe depuis peu de temps.
‫C'est ce que vous examineriez si vous envisagiez
‫des bases de données ou un élément très sensible aux changements tels
‫que les noms, les adresses IP, les volumes et les
‫données persistantes. Un mot de prudence ici.
‫La raison pour laquelle nous n'entrerons pas
‫dans les détails, c'est que je ne recommande pas que
‫votre premier déploiement de Kubernetes implique
‫beaucoup de StatefulSets. En fait, idéalement, votre premier déploiement
‫d'un orchestrateur, de n'importe quel orchestrateur, qu'il s'agisse de Swarm
‫ou de Kubernetes, ne concerne que les personnes sans état et
‫vous savez, restez simple. Peut-être ne faites-vous que vos interfaces Web,
‫certaines API, certaines fonctionnalités de travail ou quelque chose qui ne comporte
‫pas de base de données. En fait, si vous pouvez utiliser des
‫bases de données en nuage, faites-le.
‫Je recommande toujours d'externaliser vos bases de données, sauf
‫si vous avez des exigences spécifiques que vous ne
‫pouvez pas éviter pour vous-même. Au début, l'orchestration était
‫réellement conçue pour que les conteneurs soient immuables,
‫distribués et remplaçables.
‫Cette idée d'adhérence à l'état dynamique va ajouter du travail,
‫de la complexité et beaucoup plus
‫de tests pour vous. Idéalement, à l'extérieur, vous n'avez pas
‫à vous soucier de cela.
‫Plus tard, une fois que vous serez beaucoup plus à l'aise avec tout ce qui
‫se passe autour de Kubernetes, vous pourrez revenir et dire:
‫maintenant, je veux examiner mes bases de données.
‫Ce n'est pas que vous ne devriez pas exécuter de bases de données dans des clusters.
‫C'est juste plus de travail. C'est plus difficile.
‫Les bases de données et le stockage persistant sont toujours plus difficiles et
‫nécessitent plus de détails. Voilà mon conseil professionnel.
‫Avec n'importe quel conteneur, vous pouvez ajouter un
‫volume très similaire à ce que vous avez fait
‫dans Swarm, Docker et Docker Compose. Vous pouvez simplement ajouter une déclaration de volume
‫dans le modèle dans spec. Si vous pensez au fichier YAML,
‫nous pouvons simplement y placer un volume comme vous le
‫souhaiteriez, et le format et les détails
‫exacts figurent dans les ressources. Contrairement à Docker
‫et Swarm où le volume correspond à un
‫conteneur, techniquement, il s’agit du pod. Il se connecte à chaque conteneur, ou à un seul conteneur,
‫dans le module si vous le lui dites.
‫Donc, vous le contrôlez au niveau du conteneur, mais sa persistance est au
‫niveau du pod. Il existe une
‫nouvelle fonctionnalité qui est les volumes persistants.
‫Cela fonctionne avec quelque chose d'autre appelé une réclamation.
‫L'idée intéressante avec ceci est que vous
‫l'utilisez, ou vous le définissez, en dehors
‫des pods. En gros, vous créez
‫cette ressource par vous-même, puis vous faites une réclamation contre
‫cette ressource dans les spécifications de votre pod.
‫La raison pour laquelle cela est plus intéressant est que
‫Kubernetes prend le contrôle de l'entreprise et que souvent
‫des personnes s'occupent du stockage, souvent tiers, qui n'est pas la même
‫équipe que Kubernetes.
‫Ce sont eux qui participeront à la gestion et à la
‫création de ces volumes persistants.
‫Ensuite, ce sont les déployeurs d'applications qui vont se dire:
‫hé, j'ai besoin
‫d'un volume de ce type. Donc, je vais réclamer SSD ou
‫nous aurons peut-être besoin de mémoire RAM, ou peut-être de NFS, ou
‫autre chose. Ce stockage
‫sera automatiquement fourni car l'équipe de stockage
‫l'a déjà configuré dans Kubernetes.
‫C'est un peu l'idée des volumes persistants.
‫Si vous avez simplement besoin d'un simple stockage temporaire
‫sur un seul serveur pour le pod, utilisez simplement l'attribut de
‫volumes standard.
‫Une dernière chose concerne
‫la création de plugins CSI. Dans l’historique de
‫Kubernetes, tout ce qui était du stockage tiers, qu’il
‫s’agisse d’un stockage en nuage ou d’un stockage tiers, ou de
‫quelque chose de personnalisé, tout élément de ce
‫type était ajouté dans l’arborescence.
‫Cela signifie qu'il a été ajouté aux fichiers binaires
‫de Kubernetes et livré avec Kubernetes.
‫Cela signifie que Kubernetes est arrivé avec un stockage
‫Amazon et Azure construit immédiatement.
‫C'était très pratique, mais cela a ajouté
‫beaucoup de défis.
‫La plupart d'entre elles étaient liées au fait que les
‫fournisseurs de stockage contribuaient maintenant au code de votre système dont vous n'aviez
‫probablement même pas besoin, car vous ne pouvez utiliser qu'un seul fournisseur de stockage, alors
‫pourquoi les avoir tous?
‫De plus, les fournisseurs de stockage ont ensuite dû contrôler leurs cycles de publication
‫autour du cycle de publication de Kubernetes, et ce modèle
‫n'était pas très flexible.
‫Ainsi, l'industrie s'est unie et, comme pour
‫le réseautage et avec Dockerfiles et les images elles-mêmes, il
‫a créé une norme. Cette norme est la CSI.
‫Cela signifie Interface de stockage de conteneur.
‫Cela va fournir des plugins maintenant pour que n'importe quel fournisseur de
‫stockage puisse créer un plugin que vous installeriez sur tous
‫les nœuds, ce qui serait différent en fonction du
‫plugin et de leurs instructions.
‫Ensuite, ils opéreront sur une API standard fournie par le CSI
‫afin que chacun de vos
‫conteneurs puisse utiliser ce plug-in pour accéder à leur stockage.
‫C'est un modèle bien meilleur et plus flexible.
‫C'est un peu l'avenir de Kubernetes, mais
‫c'est encore assez nouveau. Très souvent, dans des
‫exemples, et même vos fournisseurs de stockage peuvent recommander,
‫en fonction de leur maturité CSI, d’utiliser leur plug-in traditionnel,
‫intégré à Kubernetes et prêt à l’emploi.