Les opérateurs Kubernetes

Mise à jour : 24/03/2025

Dans le monde de Kubernetes, gérer des applications complexes peut vite devenir fastidieux. C’est là qu’interviennent les opérateurs : ils permettent d’automatiser les tâches courantes comme l’installation, les mises à jour ou encore la sauvegarde. En s’appuyant sur les mécanismes natifs de Kubernetes, les opérateurs offrent une façon élégante et déclarative de gérer le cycle de vie d’une application.

Pourquoi utiliser et développer des opérateurs ?

À première vue, Kubernetes offre déjà tout ce qu’il faut pour déployer et gérer des applications : des Deployments, des Services, des ConfigMaps, des Volumes, etc. Alors pourquoi ajouter des opérateurs ? C’est une bonne question.

Gérer la complexité avec élégance

Dès qu’une application dépasse un certain niveau de complexité — par exemple, une base de données avec des sauvegardes régulières, une réplication, un système de restauration automatique —, les ressources standard de Kubernetes montrent vite leurs limites. À mon avis, c’est ici que les opérateurs brillent : ils permettent d’automatiser l’ensemble du cycle de vie d’une application, et pas seulement son déploiement initial.

Par exemple, un opérateur PostgreSQL peut :

déployer automatiquement un cluster PostgreSQL,
gérer les sauvegardes quotidiennes,
restaurer une instance en cas d’erreur,
appliquer des mises à jour sans interruption de service.

Tout cela sans intervention manuelle. On écrit une fois la logique métier, et Kubernetes, via l’opérateur, l’exécute à notre place.

Apporter de l’intelligence à Kubernetes

Un opérateur agit comme un administrateur système embarqué dans le cluster. Il observe l’état des ressources, détecte les écarts, et agit pour les corriger. C’est le principe du control loop cher à Kubernetes, appliqué à des cas plus spécifiques.

C’est pourquoi développer un opérateur permet de formaliser l’expertise humaine sous forme de code. Ce n’est plus juste une question de scripting, c’est une façon d’enseigner à Kubernetes comment gérer votre application, comme le ferait un expert humain.

Réduire les erreurs et gagner du temps

Avec un opérateur bien conçu, je peux :

réduire les erreurs humaines (fautes de frappe, oublis de configuration),
éviter les interventions manuelles en production,
gagner un temps précieux sur les tâches répétitives.

Et surtout, je rends le système plus prévisible et standardisé, ce qui est clé en production.

Favoriser la portabilité et la reproductibilité

Un autre avantage, c’est que les opérateurs permettent de standardiser les déploiements. Une fois que j’ai défini mes besoins dans un fichier YAML, l’opérateur s’occupe du reste, que ce soit en développement, en préprod ou en prod. Pas besoin d’avoir des procédures manuelles différentes selon les environnements.

Bref, si vous gérez des applications complexes, ou si vous souhaitez automatiser des comportements métier spécifiques dans Kubernetes, alors les opérateurs sont un excellent levier. Et les développer n’est pas aussi compliqué qu’il y paraît, surtout avec les bons outils.

Concepts clés des opérateurs Kubernetes

Avant de développer ou même utiliser un opérateur, il est essentiel de comprendre quelques concepts fondamentaux. À mon sens, ce sont les briques qui permettent à Kubernetes de gérer les applications comme s’il s’agissait de ressources natives. Voici donc les notions à connaître.

Custom Resource Definitions (CRD)

Une CRD, ou définition de ressource personnalisée, permet d’ajouter un nouveau type d’objet à Kubernetes. Par défaut, Kubernetes connaît les Pods, les Services, les Deployments… mais avec une CRD, je peux créer un objet de type PostgresCluster ou RedisCache, par exemple.

C’est ce mécanisme qui rend possible l’extension de l’API Kubernetes. Une fois la CRD déployée, je peux manipuler ces nouveaux objets comme s’ils étaient natifs, avec des commandes comme :

kubectl get postgresclusters
kubectl describe rediscache my-cache

Le contrôleur

Le contrôleur, c’est le cerveau de l’opérateur. Il est chargé d’observer l’état actuel des ressources (CRD ou autres) et de prendre des décisions pour atteindre l’état désiré. Il fonctionne en boucle :

Il lit l’état réel dans le cluster.
Il compare avec l’état souhaité (défini dans la ressource).
Il agit (crée, modifie, supprime des objets) pour corriger les écarts.

Cette boucle est souvent appelée control loop, et elle est au cœur du modèle déclaratif de Kubernetes.

Les Finalizers

Les finalizers sont utilisés pour différer la suppression d’un objet tant que certaines actions n’ont pas été complétées. C’est utile dans le cadre d’un opérateur qui doit effectuer un nettoyage avant la suppression d’une ressource.

Par exemple : si je supprime un objet BackupJob, l’opérateur peut attendre d’avoir supprimé les fichiers de sauvegarde associés avant de laisser Kubernetes effacer l’objet.

Status (champ `.status` dans les CRDs)

Les objets CRD peuvent avoir un champ status mis à jour par le contrôleur pour refléter l’état actuel de la ressource. Cela permet à l’utilisateur ou aux autres composants de connaître :

si l’application est prête,
si une erreur s’est produite,
la dernière opération effectuée, etc.

C’est un outil précieux pour le suivi et le débogage.

status:
  phase: Running
  lastBackup: "2025-03-23T22:00:00Z"

Webhooks

Certains opérateurs intègrent des webhooks d’admission :

MutatingWebhook : pour modifier une ressource avant qu’elle soit enregistrée,
ValidatingWebhook : pour refuser ou valider une ressource avant sa création.

Ces mécanismes permettent d’ajouter des règles métier avancées ou d’enrichir les objets automatiquement.

RBAC (Role-Based Access Control)

Un opérateur agit au nom de l’API Kubernetes, donc il doit avoir les droits nécessaires. Pour cela, on lui attribue des roles et rolebindings, afin de définir précisément ce qu’il peut faire.

Par exemple, un opérateur de base de données pourra avoir accès aux Pods, Secrets, ConfigMaps, etc., mais uniquement dans son namespace.

Events Kubernetes

Les opérateurs peuvent générer des événements Kubernetes visibles via kubectl describe. C’est un bon moyen de suivre les actions prises par l’opérateur ou de détecter les erreurs.

Où trouver des opérateurs Kubernetes ?

Si tu veux intégrer un opérateur dans ton cluster Kubernetes, bonne nouvelle : il existe déjà un grand nombre d’opérateurs prêts à l’emploi, développés par la communauté ou par les éditeurs d’outils eux-mêmes. Voici où je les cherche généralement.

OperatorHub.io

C’est la référence officielle pour trouver des opérateurs Kubernetes. OperatorHub.io ↗ répertorie des centaines d’opérateurs classés par catégories :

bases de données (PostgreSQL, MongoDB…),
monitoring (Prometheus, Grafana…),
sécurité (OPA Gatekeeper, Falco…),
et bien plus encore.

Chaque fiche contient la description, la documentation, les CRDs utilisées, et le lien vers le code source. C’est très utile pour se faire une idée de la qualité du projet.

Helm charts avec logique d’opérateur intégrée

Certains projets utilisent Helm pour déployer une logique d’opérateur simplifiée. Ce n’est pas tout à fait la même chose, mais cela peut suffire pour des cas simples. Tu peux en trouver sur ArtifactHub.io ↗, qui référence des Helm charts, des opérateurs et d’autres packages Kubernetes.

GitHub

Beaucoup d’opérateurs sont disponibles directement sur GitHub. Par exemple :

L’avantage ici, c’est que je peux lire le code source, voir les issues ouvertes, et même contribuer si besoin.

Et pourquoi développer son propre opérateur ?

C’est tentant de se contenter d’un opérateur prêt à l’emploi. Pourtant, il y a un risque réel à installer un outil qu’on ne maîtrise pas : celui d’introduire des vulnérabilités dans son cluster.

On parle ici de supply chain attacks : un attaquant modifie le code d’un projet open-source, puis patiemment attend que quelqu’un l’installe en production. Et là, l’accès est gagné.

Développer son propre opérateur, c’est :

comprendre exactement ce que fait l’outil,
limiter les dépendances externes,
adapter le comportement à ses besoins métiers,
et surtout, avoir la main sur la sécurité.

Même si ça prend plus de temps, je pense que c’est un bon investissement à long terme — au moins pour les opérateurs critiques.

Développer ses propres opérateurs Kubernetes

Développer son propre opérateur peut sembler ambitieux au premier abord, mais avec les bons outils et un peu de méthode, c’est tout à fait à la portée d’un administrateur système motivé. Et surtout, comme je le disais précédemment, c’est une excellente manière de maîtriser ce que fait votre infrastructure, de bout en bout.

Pourquoi écrire son propre opérateur ?

Voici ce que je gagne en écrivant mon propre opérateur :

Contrôle total : je décide de la logique métier, des validations, de la gestion des erreurs.
Adaptation au contexte : je peux intégrer mes outils maison, mes process, mes workflows spécifiques.
Sécurité : pas de dépendance à du code externe potentiellement vulnérable.
Compétence renforcée : comprendre en profondeur le modèle de Kubernetes, c’est un vrai plus professionnellement.

Bref, c’est un bon moyen d’automatiser intelligemment tout ce qui vous fait perdre du temps au quotidien.

Les outils pour démarrer

Il existe plusieurs frameworks pour créer des opérateurs. Les deux plus utilisés sont :

Operator SDK (Red Hat) :

C’est le plus populaire. Il permet de créer un opérateur en Go, Ansible ou Helm. Très bien documenté, il structure tout votre projet.

operator-sdk init --domain=monapp.local --repo=github.com/moi/mon-operator

Ensuite, je peux créer mes API personnalisées et écrire la logique dans les contrôleurs.

Kubebuilder (SIG API Machinery) :

C’est l’outil utilisé par Kubernetes lui-même pour développer ses contrôleurs internes. Un peu plus bas niveau que l’Operator SDK, mais très robuste.

kubebuilder init --domain monapp.local --repo github.com/moi/mon-operator

Kubebuilder et Operator SDK partagent des fondations communes, donc il est facile de passer de l’un à l’autre si besoin.

Les étapes clés de développement

Définir une CRD : c’est le type de ressource que l’opérateur va gérer (ex : BackupJob, RedisCluster…).
Écrire un contrôleur : c’est ici que je décris la logique pour passer de l’état réel à l’état souhaité.
Gérer le champ status : très utile pour informer l’utilisateur de l’état de la ressource.
Ajouter des finalizers : si je veux gérer le nettoyage propre des ressources.
Packager et déployer l’opérateur : souvent sous forme de container, que je déploie ensuite via un Deployment Kubernetes.

Exemples d’automatisation

Voici des cas concrets que j’ai vus ou mis en place avec des opérateurs faits maison :

Redémarrer automatiquement un service si un certificat TLS est renouvelé.
Déployer une application à partir d’un dépôt Git spécifique (GitOps simplifié).
Générer des Secrets dynamiques à partir d’un coffre-fort interne.

Conclusion

Comme tu l’as sûrement compris, les opérateurs Kubernetes sont un outil puissant pour automatiser la gestion d’applications complexes. On a survolé ensemble leurs avantages, les concepts clés, où les trouver, et pourquoi il est pertinent — voire stratégique — de développer ses propres opérateurs. Cela permet non seulement d’automatiser intelligemment tes opérations, mais aussi de garder la main sur ton code, un enjeu essentiel face aux risques de la supply chain.

Mais soyons honnêtes : on n’a fait qu’effleurer le sujet. Le développement d’opérateurs, surtout en production, demande une vraie réflexion et un peu de pratique. C’est pourquoi je prévois de te proposer, dans les prochains guides, des tutoriels concrets pour développer des opérateurs :

en Ansible, pour une approche simple et accessible aux sysadmins,
en Go, pour les cas où la performance et la finesse du contrôle sont prioritaires.

Ces guides t’accompagneront pas à pas, avec des exemples réels et des explications claires. Il va falloir que j’avance dans la rédaction de cette formation, mais je te promets du contenu solide et pratique.

Alors, prêt à passer à l’étape suivante et créer ton propre opérateur ? On attaque ça très bientôt !