Les Operators dans Kubernetes

Kubernetes est une plateforme open source permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs  . Avec l’introduction des définitions de ressources personnalisées (CRD) dans la version 1.7, la plateforme est devenue extensible. Les administrateurs peuvent définir leurs propres types de ressources qui, elles, fournissent un schéma plus spécifique. Cela ne signifie pas nécessairement plus de lignes de YAML 😉 !

Cependant, les CRD ne sont qu’un moyen de spécifier une configuration. Le cluster a toujours besoin de contrôleurs pour surveiller son état et adapter la ressource pour correspondre à la configuration.C’est dans ce contexte que s’inscrivent les Operators.

Qu’est ce qu’un Operator ?

Un operator est essentiellement un contrôleur personnalisé. Il s’appuie sur les ressources de Kubernetes et le concept de contrôleur.

Qu’est ce alors un contrôleur ?

Un contrôleur est un concept de base dans Kubernetes et est implémenté comme une boucle logicielle qui s’exécute en continu sur les nœuds maîtres Kubernetes. Les objets sont des ressources bien connues comme les pods, les Deployment Config, l ou les DaemonSet.

Les operators appliquent ce modèle au niveau des applications et sont en fait des contrôleurs spécifiques à l’application. 

Les operators se connectent à l’API maître Kubernetes et surveillent les événements pertinents en introduisant de nouveaux types d’objets via les CRD (Custom Resource Definitions). Ces derniers  comparent constamment l’état souhaité avec l’état réel. 

L’operator recherche ces définitions de ressources personnalisées, ou événements, et commence à parcourir sa boucle chaque fois que de tels objets apparaissent, sont mis à jour ou sont supprimés. 

Les operators sont installés par l’administrateur du cluster mais sont conçus pour aider l’utilisateur final. La façon dont les operators s’intègrent à Kubernetes permet aux utilisateurs: de continuer à utiliser les outils kubectl et à gérer des logiciels potentiellement complexes.

Le Framework operator

Le Framework Operator est un projet open source qui fournit des outils Kubernetes permettant aux développeurs d’accélérer le développement et le déploiement d’un operator à l’exécution. Par exemple les clients MySQL peuvent utiliser l’operator de kubernetes, MySQL Operator, pour déployer et gérer leur cluster MySQL à partir de l’API Kubernetes, sans avoir à les configurer manuellement. Il permettra aux utilisateurs de créer et de gérer des clusters MySQL en utilisant un format de configuration déclaratif simple ainsi que de faire des tâches opérationnelles courantes telles que la sauvegarde de bases de données et la restauration à partir d’une sauvegarde existante.

 Le Framework Operator repose sur trois piliers:

  • Le SDK

Le Kit de développement logiciel ou SDK ( Software Development Kit) fournit les outils pour créer, tester et empaqueter des operators. Le SDK supprime une grande partie du code standard qui est normalement requis pour s’intégrer à l’API Kubernetes. . Les principales pratiques et les modèles de code partagés entre les operators sont inclus dans le SDK pour aider à éviter les efforts de duplication comme le décrit la figure ci-après.

1- Le code est dans un premier temps testé localement.

2-Si le code fonctionne normalement en 1, il est testé dans un cluster kubernetes. Ces deux premières étapes seront repris en boucle jusqu’à l’obtention du résultat escompté.

3-Le code peut enfin être partagé dans le SDK. On a ainsi le manifest file et l’image de l’operator.

Le SDK encourage ainsi les courts cycles de développement et de test itératifs avec des outils qui permettent une validation de base de l’operator et un conditionnement automatisé pour le déploiement à l’aide de Operator Lifecycle Manager.

 

  • Operator Lifecycle Manager

Operator Lifecycle Manager (OLM) facilite la gestion des operators sur un cluster Kubernetes. Les operators qui fournissent des applications populaires en tant que service vont constituer des charges de travail de longue durée avec, potentiellement, de nombreuses autorisations sur le cluster.

Avec OLM, les administrateurs peuvent contrôler quels operators sont disponibles dans quels espaces de noms et qui peut interagir avec les operators en cours d’exécution. 

La figure ci-dessous décrit le fonctionnement de l’OLM.

1- L’operator Manifest est stocké dans un cluster catalog.

2- L’ Operator Lifecycle Manager décide de quel(s) operator(s) installer ou mettre à jour et gère leur cycle de vie sur chaque espace de nom (cluster).

  • Operator Metering

L’Operator Metering est un outil de facturation et de rapport pour fournir des comptes sur la façon dont les ressources sont utilisées dans un cluster. Ces ressources concernent principalement le CPU et la mémoire du cluster. L’Operator Metering peut aussi ếtre utilisé  pour calculer le coût IaaS ou des mesures personnalisées, comme les licences.

Operator Metering permet aux équipes opérationnelles de Kubernetes d’être en mesure d’associer le coût de leur infrastructure sous-jacente aux applications exécutées sur leurs clusters Kubernetes de manière cohérente, dans n’importe quel environnement, que ce soit sur une infrastructure de cloud public ou sur site.

 

Les operators simplifient la configuration et la gestion car Kubernetes devient un aspect crucial de la portabilité pour les services informatiques et d’ingénierie. De plus, ils prennent en charge un temps de disponibilité plus élevé et une main-d’œuvre opérationnelle réduite avec une correction automatique de la dérive de configuration d’où le terme NoOps (No Operations). Notion qui pourrait faire peur à certains car inhérente à l’automatisation des tâches et l’abstraction des infrastructures. Mais son objectif reste d’automatiser complètement le déploiement, la surveillance et la gestion des applications et de l’infrastructure sur laquelle elles s’exécutent 😇.

Halima GAYE
Halima GAYEIngénieur Cloud & DevOps