Sommaire
Nous aborderons dans cet article, le rôle de l’opérateur dans un environnement Kubernetes, nous approfondirons dans cet article leurs fonctionnements, quelques exemples d’utilisation et l’ensemble des bénéfices que cet outil peut vous apporter.
Nous vous présenterons également un site répertoriant une grande quantité d’opérateurs pour des usages divers et variés.
Enfin, nous aborderons la question visant à (re)connaître le moment où développer votre propre opérateur pourrait se révéler intéressant, ainsi que des ressources vous permettant de vous lancer dans cette aventure.
Les opérateurs Kubernetes
Un opérateur est un outil permettant de packager, déployer, ainsi que de maintenir une application déployée sur Kubernetes. Ce n’est ni plus ni moins qu’une extension qui permet d’automatiser un certain nombre de tâches qu’un SRE (Site Reliability Engineering) pourrait être amené à faire régulièrement dans un environnement plus complexe qu’un simple pod sans état.
Autrement dit, nous pouvons dire qu’un opérateur n’est autre qu’un contrôleur personnalisé, contrairement à un replicaSet qui est un contrôleur natif.
Notons bien que contrairement à Helm, l’opérateur ne se contente pas de packager et de déployer, il est également chargé de maintenir nos applications en bonne santé, tout en effectuant des opérations de maintenance dont elle aurait besoin.
Comment fonctionne un opérateur Kubernetes ?
Comme dit supra, un opérateur est une extension du control plane et de l’API. Dans sa forme la plus simple, un opérateur va ajouter un “endpoint” à l’API Kubernetes via une “custom resource” (CR) avec laquelle vous pourrez désormais communiquer à travers la commande kubectl (ex : kubectl get mycr ), ainsi qu’un composant dans le “control plane” vous permettant de monitorer et de maintenir ces nouvelles ressources spécifiques. À noter également que le scope d’un opérateur peut diverger selon votre besoin. Vous pouvez le configurer pour qu’il gère vos ressources dans un namespace en particulier, ou sur l’ensemble de votre cluster.
Fonctionnement d’un opérateur - Source : cncf.io
Exemple de fonctionnement dans un cluster de base de données
Il est tout à fait possible de gérer son propre cluster soi-même via un ensemble d’outils nécessaires au bon fonctionnement de votre cluster de base de données. La force d’un opérateur, dans ce cas de figure, vise à remplacer les étapes laborieuses, telles que la configuration, la gestion des pannes, le scaling, ou même la gestion des sauvegardes.
Dans cet exemple, nous allons approfondir le rôle de l’opérateur à travers l’opérateur MySQL développé par Oracle.
Voyons d’abord comment fonctionne aujourd’hui un cluster MySQL classique déployé sur plusieurs hosts.
Comme vous pouvez le voir sur le schéma ci-dessous, nous avons besoin :
- De 3 machines/VM afin de constituer un cluster
- L’installation d’un plugin appelé Group Replication
- L’installation de MySQL Routers permettant de gérer le trafic entre vos back-ends et vos bases de données.
- L’installation de MySQL Shell permettant de communiquer et de scripter des commandes en SQL.
- La configuration associée à sa mise en place
Fonctionnement d’un cluster de base de données MySQL -Source : percona.com
Vous l’aurez compris, un cluster de base de données MySQL InnoDB devient un véritable défi à installer dans un environnement Kubernetes sans un administrateur de base de données aguerri et un Ops Kubernetes ayant de solides connaissances pour maintenir et avoir une telle architecture dans un cluster .
Maintenant, prenons le cas où vous devez renouveler cette opération pour différentes équipes dans différents environnements, et qu’à chaque fois vous devez en prévoir la maintenance. C’est dans ce cas précis que l’opérateur intervient.
L’opérateur MySQL
À partir d’un Helm chart, nous allons pouvoir déployer l’opérateur MySQL dans notre cluster Kubernetes.
Une fois l’opérateur installé, celui-ci va prendre en charge un certain nombre de tâches plus ou moins laborieuses pour vous accompagner dans la configuration de vos clusters MySQL InnoDB.
Concrètement, voici ce que l’opérateur va prendre en charge, une fois que vous aurez créé la ressource liée à votre cluster MySQL.
- L’opérateur va configurer et faire l’initialisation du StatefulSet, en attachant un sidecar conteneur rattaché à chaque instance qui compose votre cluster. Ce conteneur va créer la configuration locale de chaque serveur (Utilisateurs, mots de passe, etc.)
- L’opérateur crée également un déploiement “MySQL Routers” pour la gestion du trafic destiné à votre cluster.
- De plus, l’opérateur va s’occuper de générer automatiquement pour chaque cluster MySQL détecté, un ConfigMap vous permettant de configurer chaque instance de votre cluster.
- L’opérateur crée aussi un certain nombre de secrets, vous permettant de :
- Vous connecter à vos instances
- Stocker vos credentials pour vous connecter sur des stockages externes qui accueilleront vos sauvegardes
- Définir l’endroit où se trouve votre stockage externe
- Définir la fréquence à laquelle vous souhaitez faire vos sauvegardes
- etc
Voici un récapitulatif du fonctionnement de notre opérateur MySQL au travers d’un schéma :
Fonctionnement de l’opérateur MySQL - Source : mysql.com
Autre exemple du fonctionnement d’un opérateur
Lorsque que l’on travaille sur des environnements de production, nous avons tous eu, un jour ou l’autre, le besoin d’utiliser des certificats TLS afin de chiffrer et de sécuriser les communications avec vos applications. À première vue, la difficulté est tout à fait acceptable, cela dit, des opérations basiques telles que générer un certificat ou leur renouvellement, peuvent devenir un véritable calvaire au fur et à mesure que votre SI s’agrandit.
L’opérateur cert-manager va dans notre cas faciliter la création, le renouvellement, s’assurer de sa validité auprès de différentes autorités de certifications ACME (let’s Encrypt), Hashicorp Vault, Venafi, etc. Afin de les mettre à disposition auprès de vos applications sur Kubernetes au travers de vos différents services ou de votre ingress via différents secrets contenant vos certificats TLS.
Fonctionnement de l’opérateur cert-manager - Source : banzaicloud.com
Où trouver des opérateurs ?
Dans le cas où vous auriez besoin d’un opérateur pour une tâche en particulier, sachez que vous pourrez trouver une offre conséquente sur le site operatorhub qui se trouve être un site lancé initialement par Red Hat et le trio Microsoft, Amazon et Google. Ce site a pour but de rassembler les différents opérateurs qui ont été développés pour des technologies relativement communes.
Une notion importante à considérer lorsque vous choisirez un opérateur, est son niveau de capacité que vous pourrez retrouver sur la page de chacun d’entre eux et s’appuyant sur le schéma ci-dessous : 
Comme vous pouvez le constater, le degré d’automatisation d’un opérateur peut aller de la simple installation à la gestion complète d’un déploiement comprenant les upgrades, les sauvegardes, le monitoring, le scaling et l’auto-remédiation.
Si vous souhaitez plus d’informations à ce sujet ainsi que l’exhaustivité de ce qu’englobe chaque niveau, vous pouvez vous rendre sur le site operator framework .
Avez-vous besoin de développer votre propre opérateur ?
Avant d’aborder la partie sur la création de votre propre opérateur, il peut être intéressant
d’étudier au préalable la pertinence de développer votre propre opérateur.
Voici quelques cas de figures où le développement de votre propre opérateur pourrait se révéler intéressant :
- Votre SI est composé de plusieurs clusters Kubernetes, et la répétition des configurations se révèlera vite chronophage avec un risque accru d’avoir des configurations différentes à terme.
- Votre application sera amenée à être utilisée par des utilisateurs externes, où la complexité de mise en œuvre et de maintenance pourrait se révéler être un frein à l’adoption de votre application.
- Votre équipe a les compétences en développement et le temps nécessaire pour maintenir l’opérateur au fil des évolutions de votre application et de vos infrastructures.
En revanche, si l’unique intérêt de votre opérateur est de déployer une application sans aucune tâche de maintenance ou de configurations post-déploiement, mieux vaut rester sur des solutions plus appropriées telles que Helm ou Kustomize.
Créer son propre opérateur
Si vous êtes maintenant convaincu(e) des bénéfices à développer votre opérateur, ou si vous souhaitez simplement approfondir leur fonctionnement à travers le développement de votre opérateur, voici différents projets vous permettant de vous lancer.
Les 3 premiers SDK (Software Development Kit) que nous présenterons ont une couche d’abstraction assez forte.
- Operator SDK (Helm, Ansible, Go)
- KUDO (YAML)
- shell-operator (Go)
Si vous souhaitez développer un opérateur en ayant moins d’abstraction, les 3 projets ci-dessous devraient pouvoir répondre à vos attentes. Avec une attention particulière pour Kubebuilder, qui pourra interagir nativement en Go et vous permettant d’améliorer votre compréhension du fonctionnement des API Kubernetes.
- Kubebuilder (Go)
- Java Operator SDK (Java)
- Kubernetes Operator Pythonic Framework (Python)
Maintenant que vous avez un point de départ pour vous lancer, rappelons quelques bonnes pratiques auxquelles vous devez faire attention lors du développement de votre opérateur :
- Un opérateur doit être opérationnel avec un déploiement unique
- Un opérateur nécessite de créer une nouvelle Custom Resource unique à son utilisation
- Éviter de réécrire du code qui existe déjà dans le fonctionnement standard de Kubernetes
- Veillez à ce que la suppression de votre opérateur n’affecte pas les ressources qui en dépendent
- Un opérateur doit être capable de fonctionner sur vos ressources quelle que soit leur version
- Un opérateur doit être capable de faire des upgrades de manière progressive et capable de revenir en arrière en cas de problème
- Il est primordial d’avoir des tests concernant votre opérateur, celui-ci étant amené à jouer un rôle prépondérant dans la maintenance de votre application, l’impact d’un dysfonctionnement pouvant être critique selon votre infrastructure.
Conclusion
Nous voici à la fin de notre article sur les opérateurs, et nous espérons qu’à présent, vous avez une idée un peu plus précise du fonctionnement de ceux-ci. Comme vous l’aurez vu tout au long de cet article, les opérateurs sont des outils de plus en plus prisés pour automatiser des tâches répétitives à l’intérieur de vos clusters Kubernetes.
Ce besoin d’automatisation répond à un objectif-clé des SRE visant à faire croître vos applications, sans avoir à faire grandir vos équipes en conséquence pour garantir la fiabilité de vos applications.
En parlant de SRE, découvrez la conférence sur le sujet de Henri Gomez, Cloud Advisor chez WeScale (ex Lead SRE @Doctolib et ex Lead SRE @Saagie)
ALLEZ PLUS LOIN SUR KUBERNETES
-
Formation KubernetesAppropriez-vous les technologies de conteneurs et les notions Kubernetes pour une utilisation nominale.
Je découvre les fondamentaux
-
Cloud NativeComment construire votre infrastructure Cloud Native ?
Je télécharge le livre
-
Les conteneurs
Comment implémenter et exploiter au mieux les Conteneurs ?
Je télécharge le livre
