Name: Tremplin Numérique
Price range: $$$

Les termes Kubernetes « contrôleur » et « opérateur » font référence à deux modèles différents qui font passer un cluster dans un état souhaité. Les contrôleurs sont un concept établi tandis que les opérateurs ont émergé plus récemment pour décrire des contrôleurs spécifiques à une application.

Sommaire

La boucle de contrôle

Les clusters Kubernetes fonctionnent sur une boucle de contrôle. Vous définissez ce que le cluster doit faire en écrivant et en appliquant des manifestes YAML. Les contrôleurs à l’intérieur du cluster détectent les modifications demandées et prennent des mesures pour ajuster l’état. Cela se produit de manière asynchrone, une fois que vous avez soumis vos nouveaux manifestes.

Les contrôleurs sont chargés de surveiller les ressources du cluster, d’évaluer si elles ont divergé de l’état défini et d’effectuer les ajustements nécessaires pour les ramener à l’alignement. Ce sont des composants entièrement automatisés qui fonctionnent sans intervention.

Plusieurs types de contrôleurs existent au sein de l’écosystème. Certains agissent au niveau du cluster tandis que d’autres gèrent vos charges de travail. Les ressources Kubernetes quotidiennes que vous définissez dans vos manifestes peuvent être des contrôleurs : Deployment, ReplicaSet, et des exemples similaires répondent à la définition d’un contrôleur. Ils prennent en charge les objets imbriqués pour maintenir un nombre de répliques défini par l’utilisateur.

Qu’est-ce qu’un contrôleur ?

Un contrôleur est tout élément de votre cluster qui suit au moins un autre type de ressource Kubernetes. Les contrôleurs peuvent être passifs ou actifs. Un contrôleur actif effectuera lui-même les actions nécessaires ; les passifs communiqueront les modifications aux autres composants ou au serveur API du cluster.

Comme le rôle d’un contrôleur est volontairement abstrait, ils n’ont aucune fonctionnalité commune au-delà de leur surveillance d’objets spécifiques. Vous pourriez avoir un contrôleur qui supprime automatiquement les pods avec un eligible-for-autodelete annotation.

Dans Kubernetes, les contrôleurs ne sont qu’un modèle pour la mise en œuvre de la fonctionnalité de boucle de contrôle automatisée. Les contrôleurs individuels auront des objectifs et des caractéristiques uniques, mais ils surveilleront toujours les objets ou la configuration de votre cluster.

Et les opérateurs ?

Un opérateur est une forme spécialisée de contrôleur. Les opérateurs implémentent le modèle de contrôleur, ce qui signifie qu’ils déplacent le cluster vers un état défini, mais ils possèdent également des caractéristiques supplémentaires. Le terme a été inventé à l’origine par CoreOS, mais a maintenant été adopté plus largement par Kubernetes.

Les opérateurs sont adaptés à des applications spécifiques. Ils ajoutent des extensions d’API Kubernetes via des définitions de ressources personnalisées, créant de nouveaux types d’objets utilisés par l’application qu’ils gèrent.

Plusieurs applications communautaires populaires sont désormais livrées avec leurs propres opérateurs. Ceux-ci facilitent l’installation, la configuration et la maintenance du logiciel géré dans votre cluster. Il existe des opérateurs pour etcd, Fluentd, Prometheus et de nombreux autres projets critiques qui sont généralement lancés en clusters.

Ces charges de travail peuvent être complexes et constituées de plusieurs composants individuels. Ils sont susceptibles d’inclure une logique spécifique à l’application qui doit être gérée tout au long du cycle de vie de l’installation.

Le concept d’opérateur offre un moyen de surveiller ces applications en utilisant les mêmes principes que les contrôleurs classiques. Un opérateur est simplement un contrôleur spécialisé qui utilise des ressources personnalisées pour déplacer une application spécifique dans l’état défini par l’utilisateur correct.

Vous configurez généralement les opérateurs en fournissant des données de configuration dans une ressource personnalisée. L’opérateur utilise sa connaissance de l’application pour convertir ces données en actions spécifiques dans le cluster. Ces actions assembleront une installation fonctionnelle de l’application qui correspond à l’état défini dans la ressource de configuration.

A quoi servent les opérateurs ?

Comme les opérateurs sont spécifiques à un domaine, chacun inclura des fonctionnalités différentes. En général, vous pouvez vous attendre à ce qu’un opérateur offre certaines des fonctionnalités suivantes :

Surveillance et alerte automatiques – Les opérateurs savent généralement quand leurs applications ne fonctionnent pas correctement et génèrent des alertes appropriées.
Mises à niveau automatiques des versions au fil du temps – Les opérateurs sont souvent capables d’appliquer automatiquement des modifications de cluster pour installer de nouvelles mises à jour d’applications dès qu’elles sont disponibles. Cela réduit considérablement la charge de maintenance pour les équipes opérationnelles.
Installation de ressources personnalisées – Les opérateurs ajouteront les ressources personnalisées de l’application au serveur d’API Kubernetes, préparant le cluster à héberger la charge de travail.
Fournir une mise à l’échelle automatique – Un opérateur possédant des connaissances spécifiques au domaine peut reconnaître lorsque le nombre de réplicas configuré est trop faible pour servir confortablement le trafic actuel et lancer de nouvelles instances pour maintenir les performances.
La gestion du cycle de vie – Les opérateurs s’assurent que les nouvelles instances d’application se lancent dans un environnement où toutes les conditions préalables sont déjà remplies. Ils effectueront également tout nettoyage nécessaire après l’arrêt d’une réplique.
Gestion du stockage et sauvegardes – Certains opérateurs assistent la mise en place du stockage persistant. Comme ils comprennent leur application, ils peuvent également effectuer des sauvegardes avant d’appliquer une action potentiellement destructrice.

Assembler toutes ces fonctionnalités à partir de zéro avant de déployer une nouvelle charge de travail serait compliqué et difficile à maintenir. Les opérateurs vous permettent de lancer des systèmes complexes dans votre cluster à l’aide d’une stratégie approuvée par le fournisseur, autogérée et native de Kubernetes.

Les avantages des opérateurs peuvent être clairement observés dans certaines des applications qui les offrent. Le logiciel de contrôle de version GitLab est une pile complexe de composants, mais son opérateur fournit une mise à l’échelle automatique, des mises à niveau progressives et des sauvegardes entièrement automatisées, ainsi qu’une pile de visualisation métrique utilisant Prometheus et Grafana. Tout est prêt à être utilisé lorsque vous ajoutez l’opérateur à votre cluster.

Un autre opérateur est celui de MongoDB : il offre un moyen entièrement géré de provisionner le stockage, les bases de données, les utilisateurs et les paramètres Mongo à partir d’un seul ensemble de spécifications que vous définissez. L’opérateur configure ensuite votre cluster en conséquence pour prendre en charge la charge de travail de votre base de données.

Vous pouvez écrire vos propres opérateurs en créant un contrôleur à l’aide de l’une des bibliothèques clientes Kubernetes. Les opérateurs sont développés à l’aide de l’API REST Kubernetes pour interroger et interagir avec le cluster et ses objets.

Conclusion

Les contrôleurs et les opérateurs sont des termes Kubernetes pour décrire les composants du plan de contrôle qui surveillent les ressources et appliquent des actions pour modifier l’état du cluster. Alors que les contrôleurs sont concernés par les opérations au niveau de Kubernetes, les opérateurs possèdent une logique spécifique au domaine et sont adaptés aux applications individuelles.

Si vous utilisez un opérateur pour installer une application, cela signifie que vous ajoutez un composant qui surveillera cette installation, vérifiera qu’elle fonctionne normalement et automatisera les transitions d’état pour les mises à jour ou les changements de configuration. Bien que les chartes Helm aient déjà résolu le défi du déploiement d’une application et de ses dépendances, les opérateurs vont encore plus loin : ils sont fournis par le fournisseur de l’application, ont une connaissance approfondie des exigences de la charge de travail et conservent la responsabilité de l’installation tout au long de son cycle de vie.

Il est probable que les opérateurs continueront à gagner en visibilité à mesure que des applications avec état plus complexes commenceront à leur être proposées. L’automatisation de la maintenance, des tâches du « deuxième jour » et des mises à niveau contribue à réduire la charge des équipes d’exploitation étirées et permet aux nouveaux arrivants de se lancer plus facilement dans des déploiements prêts pour la production.