Dans cette conférence, le PDG d’Anynines, Julian Fisher, partage les défis de la gestion du cycle de vie d’un opérateur Kubernetes. Julian et son équipe ont comparé plusieurs outils qui pourraient aider à cela. La conférence couvre Carvel, Helm, OLM et Operator SDK, où les avantages et les inconvénients sont partagés pour chaque outil.
Julien Fisher 00:00
Super d’être ici à Valence. J’ai eu la chance d’avoir un de mes coéquipiers avec moi, Paul ici et, nous avons voyagé sur notre moto jusqu’à Valence, c’était une belle aventure, et un bon début pour, vous savez, commencer cette merveilleuse conférence. Il s’agit donc de la gestion du cycle de vie des opérateurs chez Anynines, nous faisons beaucoup, vous savez, de construction et d’automatisation de plates-formes de développement d’applications avec un fort accent sur l’automatisation des services de données.
Ainsi, nous automatisons les bases de données depuis près de 10 ans maintenant ; nous avons fait beaucoup d’automatisation et faisons beaucoup d’automatisation basée sur des machines virtuelles en utilisant BOSH de l’écosystème Cloud Foundry comme technologie d’automatisation, qui est également déclarative par nature et présente de nombreuses similitudes avec les opérateurs de bâtiments. Et dans le cadre de cela, nous savons que vous savez, la gestion du cycle de vie des opérateurs est très importante car les bases de données sont souvent utilisées pendant des années. Et cela signifie que vous devez guider ces instances de base de données tout au long du cycle de vie. Donc, dans cette conférence, nous aimerions, vous savez, avoir un bref aperçu de ce que cela signifie réellement de, vous savez, faire fonctionner des opérateurs pendant une période prolongée ? Et quels sont les outils potentiels qui pourraient nous aider à le faire ?
La première question est donc de savoir en quoi consiste la gestion du cycle de vie de l’opérateur, il y a de nombreuses facettes. Tout d’abord, si vous pensez à, vous savez, un opérateur plus compliqué, vous êtes susceptible d’avoir, vous savez, vos CRD, vos contrôleurs, vos contrôleurs d’admission, vous savez, tous ces éléments qui assemblent votre opérateur, y compris images de conteneurs, évidemment, et elles forment toutes une sorte de contrat. Ainsi, une certaine version d’un contrôleur est, vous savez, capable de concilier certaines versions de CRD et de webhook d’admission. Les contrôleurs efficaces ont également certaines contraintes de version. Et bien sûr, une grande partie de la magie se produit dans les images de conteneurs. Et ils ont aussi des contraintes de version. Si vous pensez aux bases de données et à leur cycle de vie, par exemple, Postgres, l’un de mes exemples préférés, nous avons des clients qui exécutent des applications pendant, disons, 10 ans, comment guidez-vous une instance de base de données, à travers son cycle de vie pendant une période aussi longue de temps? Et c’est, il est assez clair qu’à un moment donné, vous voulez enlever, disons, une certaine version de base de données, disons Postgres 9.4, vous voudriez juste, vous savez, encourager vos développeurs à migrer vers une version plus récente version. Alors, comment faites-vous cela avec Kubernetes ?
En construisant un opérateur, vous devez également mettre à niveau vos opérateurs de temps en temps, par exemple, pour rendre obsolète une certaine version de l’API. Et c’est essentiellement, vous savez, certaines des facettes lorsque vous souhaitez gérer un opérateur sur une longue période de temps. En particulier, l’un des sous-problèmes de la gestion des opérateurs est la gestion du cycle de vie de vos définitions de ressources personnalisées. Donc, si vous, par exemple, encore une fois, pensez à Postgres, alors vous auriez un CRD représentant en quelque sorte votre instance de base de données. Donc, si vous introduisez la première version, disons en tant que V1, alpha one, c’est la version API du CRD. Il est livré avec certaines fonctionnalités, par exemple, une certaine version de Postgres. Et à un moment donné, vous introduisez une version plus récente de ce CRD ? Eh bien, vous voulez faire de la nouvelle version par défaut, et plus de versions sont ajoutées, plus il devient probable que vous souhaitiez peut-être supprimer les versions héritées, vous savez, de votre cluster Kubernetes.
Maintenant, déprécier un CRD est possible, je pense, depuis Kubernetes, 1.9. Vous pouvez donc marquer un CID comme obsolète. Donc, si vous, disons, faites celui de Postgres V1, alpha one, vous obtenez un avertissement de dépréciation. Donc, la prochaine étape que vous pourriez faire est, vous savez, d’arrêter de servir cette version afin que vous puissiez plus créer des objets de cette version particulière.
Cependant, si vous envisagez, vous savez, une période de temps prolongée, à un moment donné, vous devez également migrer les objets qui ont déjà été créés. Disons que nous voulons que la V1 soit obsolète. Il n’est plus servi, mais il existe toujours des instances de service. Que faites-vous avec eux, vous devez les migrer, et il est étonnamment inconfortable de les migrer. Donc, là, il y a du travail supplémentaire que vous devez y mettre.
Si vous regardez le processus de mise à niveau d’un tel CRD, vous verrez que vous devrez, par exemple, mettre à niveau les CRD, l’objet stocké dans etcd, un peu, il existe un outil de migration pour le faire, mais il n’a pas été maintenu très bien, espérons-le, car il y aura des outils inhérents dans les futures versions de Kubernetes pour s’en occuper. Pour que vos anciennes instances de service V1 alpha one représentées comme ces entités dans Kubernetes, etcd puissent être mises à niveau plus facilement, vous pouvez le faire, vous savez, avec vos propres webhooks fournis personnalisés pour que cela fonctionne toujours. Et ce serait bien si ce serait plus simple.
Maintenant, chez Anynines, nous voulons construire plusieurs, vous savez, des opérateurs et de nombreuses autres extensions, c’est-à-dire qu’il est très probable que ces opérateurs seront déployés des centaines, des centaines de fois, dans des centaines de clusters par client. Donc, si vous pensez à cette ampleur, l’utilisation reconnaît qu’une intervention manuelle quelconque n’est pas souhaitable, c’est juste que cela prend trop de temps et fait perdre trop de temps aux précieux opérateurs de la plate-forme.
Donc, avant de creuser dans la création de votre propre outil de gestion du cycle de vie, il est logique d’examiner le paysage des outils et de penser à, vous savez, la technologie qui pourrait faire l’affaire pour vous. Eh bien, la première supposition, vous savez, dans nos recherches était Helm avec le léger sentiment que ce n’était peut-être pas le bon outil, mais parce que c’est certainement le plus populaire, c’était le premier que nous avons réellement considéré.
Voici donc quelques inconvénients. C’est, c’est très populaire, et vous savez, un peu mature parce que c’est déjà là depuis, vous savez, une longue période de temps, c’est plutôt facile à utiliser, vous fournit un mécanisme de modèle, de sorte que vous pouvez, vous savez , fournir à l’utilisateur final des variables qu’il peut choisir et nous fournir en tant que valeurs fournies par l’utilisateur. Il a également des crochets de graphique et des crochets de cycle de vie, de sorte que vous pouvez faire des choses, pré-installer et post-installer la pré-mise à niveau et la publication, l’installation. Il n’y a pas de composants côté serveur. Vous n’avez donc rien à installer dans le cluster Kubernetes pour faire fonctionner Helm. C’est purement piloté par CLI. Et bien sûr, il y a un large éventail d’intégrations. Donc, si vous, par exemple, prenez un outil CI/CD, tel qu’ArgoCD ou cross-plane, alors cross-plane a un objectif différent en conservant cette intégration de Helm disponible, comme c’est le cas avec de nombreux autres outils. Alors ça, c’est sympa.
Par contre, si vous pensez à la gestion du cycle de vie des opérateurs, vous verrez que notamment, la gestion du cycle de vie des CRD c’est pas vraiment, ce n’est pas vraiment bon. Et, vous savez, il y a des discussions à Helm, pour savoir si elles doivent être améliorées. Mais jusqu’à présent, il semble que Helm ne soit tout simplement pas censé se concentrer sur cela. Et donc, le choix de Helm dans ce but est, ce n’est peut-être pas le bon.
De plus, il est livré avec une gestion des dépendances limitée, si vous pensez, vous savez, à l’écriture d’opérateurs, vous savez, à grande échelle, donc nous en aurons plusieurs, par exemple, nous n’avons pas seulement l’opérateur créant l’instance de service, mais nous ont également des CRD, vous savez, pour représenter la liaison entre l’application et l’instance de service, nous appelons cette liaison de service provenant de la spécification de l’API Open Service Broker, ainsi que des CRD pour créer des sauvegardes et des sauvegardes planifiées.
Donc, vous savez, il est probable que certains de ces composants seront partagés dans une certaine mesure. Donc, tracer les dépendances pour installer, vous savez, un framework d’opérateur et avoir des composants partagés entre les opérateurs serait souhaitable. Donc, ces deux choses ne vont pas et sont des obstacles pour l’utilisation de Helm, du moins de notre point de vue.
Désormais, l’autre choix évident est le gestionnaire de cycle de vie de l’opérateur fourni avec le SDK de l’opérateur. Il a un composant côté serveur, ce n’est pas vraiment un problème, mais juste quelque chose qui doit être noté car le composant côté serveur doit également être installé et gérer un peu le cycle de vie. Il est conçu uniquement dans le but de gérer les opérateurs. Je veux dire, cela fait partie du SDK de l’opérateur, c’est assez évident. De plus, la façon dont vous installez un opérateur avec OLM consiste à créer une ressource personnalisée d’abonnement, ce qui vous donne également la possibilité de paramétrer un peu la création et l’abonnement. Mais il ne vous fournit pas les options de modèles telles que Helm, nous le faisons.
L’un des principaux avantages d’OLM est qu’il se soucie réellement de la gestion du cycle de vie des définitions de ressources personnalisées, en particulier de la gestion des mises à niveau. Il y a, il reste encore du travail manuel pour vous, mais cela vous aide en fait un peu plus. Et nous sommes autour de la conférence. Et ici, au moins pour aujourd’hui, et demain. Alors contactez-nous si vous avez d’autres questions à ce sujet.
Et une fois que vous avez utilisé l’OLM pour automatiser l’installation de l’opérateur, le SDK de l’opérateur vous aidera également à empaqueter le package OLM que vous avez créé. Eh bien, il y a quelques inconvénients. Je veux dire, ce n’est pas un gestionnaire de sauvegarde à usage général. Vous devez donc vous en tenir à ce que vous avez pour résoudre ce problème à l’échelle de la plate-forme avec plusieurs outils ou une combinaison d’outils. Il n’y a pas de mécanisme de template. Ainsi, certaines choses comme laisser un client déterminer les étiquettes à définir, etc. seront plus difficiles à mettre en œuvre. Il existe des solutions de contournement pour cela, mais ce n’est pas aussi confortable qu’un mécanisme de modèle.
Il n’y a pas de crochets de cycle de vie. Donc, rien de semblable aux crochets de graphique. Et la mise à niveau, les ressources personnalisées doivent encore être effectuées automatiquement. Il y a un certain support pour les mises à niveau, par exemple, la version d’état, et…