mail

Un sujet intéressant qui fait surface depuis quelques temps dans la communauté est lié au fait que les opérateurs Kubernetes viennent avec leur lot de difficultés qui les rendent difficiles à coder et à utiliser. Cet article résume les préoccupations derrière cette idée. Vous trouverez comment et quand les éviter ainsi que des approches alternatives que vous pourrez utiliser. Peut-être que le meilleur opérateur est celui que l'on n'utilise pas.

Nous sommes victimes de la mode ! Après avoir appris ce qu'étaient les opérateurs, nous les utilisons de plus en plus. Nous nous mettons même à en développer. Alors quand quelqu'un vous rappelle que le meilleur opérateur est celui que l'on utilise pas, c'est intéressant de l'écouter. Je ne peux pas être plus d'accord avec les articles suivants When Not to Write a Kubernetes Operator, When to Use, and When to Avoid, the Operator Pattern ou la video de Joe Thompson, de HashiCorp Stop Writing Operators.

Cet article résume les alternatives, les challenges et les bénéfices des opérateurs.

Pas besoin d'opérateur

Les opérateurs sont des composants packagés qui s'appuient sur des CRDs et des contrôleurs pour automatiser les opérations d'applications tiers comme une base de données MySQL. Ce que l'on ne dit pas et, pourtant est très vrai s'agissant d'opérateurs, est que :

  • Si votre application a été contruite pour tirer parti de Kubernetes, vous n'avez sans doute pas besoin d'opérateur ;
  • Si les composants que vous gérez sont en dehors de Kubernetes, it est très probable que vous pouvez également les gérer sans utiliser d'opérateur, en dehors de Kubernetes ;
  • Si votre application est stateless ou si elle peut se resynchroniser d'elle-même en cas de perte d'une partie de son état... vous n'avez pas besoin d'opérateur ;
  • Si vous comptez utiliser plusieurs milliers de composants, vous ne voudrez sans doute pas vous appuyer sur des CRDS et etcd, pas plus que sur des opérateurs ;
  • Selon la manière dont vous envisagez de redémarrer vos applications en cas d'incident, vous voudrez externaliser l'état de votre application en dehors de votre cluster et ne pas vous appuyer sur un opérateur ;
  • Il existe des modèles plus légers que les opérateurs, y compris des abstractions de plus haut niveau comme kudo

Considérez que ne pas utiliser d'opérateur est la meilleure solution, avant même de réfléchir à l'utilisation d'un opérateur.

Des opérateurs difficiles à développer

Si, malgré ce que vous venez de lire, vous considérez toujours écrire un opérateur, pensez-y à 2 fois. Ecrire un opérateur est difficile :

  • Vous voudrez être expérimenté pour développer un opérateur. Vous voudrez maitriser le framework, l'outillage et Kubernetes. Par exemple, ne commencez pas à développer un opérateur dans un langage que vous ne maitrisez pas.
  • Vous devez connaître très bien l'application que vous voulez opérer. Dans le cas contraire, il y a de bonnes chances que vous vous preniez les pieds dans le tapis avec elle à un moment. La moindre des choses est que vous essayez de bénéficier du support des équipes de développement. Elles pourraient très bien avoir envie de supporter Kubernetes par elles-mêmes.
  • Vous devrez comprendre les problèmes que vous traiter, les limites. Vous devez les avoir gérés manuellement, vous être trompés et connaitre les pièges.
  • Vous ne devez pas écrire un opérateur pour une application qui n'est pas mature.
  • Vous ne devez pas écrire un opérateur quand le jeu n'en vaut pas la chandelle. Le problème doit être fréquent et ne doit pas être trop difficile à automatiser.
  • Vous voudrez garder votre code minimal et éviter d'avoir à modifier votre opérateur à chaque évolution de l'application qui est opérée.
  • Les opérateurs ont besoin de privilèges ce qui augmente la surface d'attaque et ajoute un challenge à l'équipe de sécurité.
  • Les opérateurs doivent eux-mêmes être opérés.

Le code est une dette et personne ne devrait considérer utiliser un opérateur à la légère.

Opérateurs ou pas ?

Ne vous y trompez pas, les opérateurs sont des outils puissants et très utiles. Il y a des cas dans lesquels ils n'ont pas d'égaux. Le premier d'entreux-eux est, à mon avis, le fait que c'est la meilleure façon de comprendre comment Kubernetes fonctionne. C'est également la meilleure façon d'adapter une application qui utilise un état et n'a pas été développée pour Kubernetes sur Kubernetes. Les opérateurs sont de bonnes solutions pour intégrer, temporairement, des nouvelles fonctionnalités de Kubernetes. Ils permettent également de supporter d'anciennes versions de Kubernetes.

Il y a pléthore d'outils de gestion pour adresser vos besoins, comme ceux qui implémentent des approches GitOps. Vous pouvez trouver des modèles simples. Vous pouvez également aussi bien vouloir intégrer directement Kubernetes plutôt que de vous appuyer sur un composant externe comme un opérateur. Les opérateurs ne doivent pas être la première idée à mettre sur la table quand on développe des solutions Kubernetes. Ceci est mon point.