Préparer un cluster Kubernetes est-il simple et pratique ? Nous annonçons l'addon-operator

Après shell-operator nous vous proposons son grand frère — addon-operator. Il s'agit d'un projet Open Source utilisé pour installer dans le cluster Kubernetes des composants système qui peuvent être appelés collectivement — des compléments.

Pourquoi avoir des compléments du tout ?

Il n'est un secret pour personne que Kubernetes n'est pas un produit tout-en-un prêt à l'emploi, et la construction d'un cluster « mature » nécessite divers compléments. L'addon-operator vous aidera à installer, configurer et maintenir ces compléments à jour.

La nécessité de composants supplémentaires dans le cluster a été révélée dans le rapport de nos collègues driusha. En résumé, la situation actuelle avec Kubernetes est telle que pour une installation simple 'pour jouer', on peut se contenter des composants de base, pour les développeurs et les tests, on peut ajouter Ingress, mais pour une installation complète, que l'on peut qualifier de 'votre production est prête', il faut ajouter une dizaine de différents compléments : quelque chose pour la surveillance, quelque chose pour les logs, ne pas oublier Ingress et cert-manager, définir des groupes de nœuds, ajouter des politiques réseau, assaisonner avec des paramètres sysctl et un pod autoscaler…

Quelle est la spécificité de leur utilisation ?

Comme le montre la pratique, l'installation seule ne suffit pas. Pour travailler confortablement avec le cluster, il faudra mettre à jour les compléments, les désactiver (les retirer du cluster), et certains devront être testés avant d'être installés dans le cluster de production.

Alors, peut-être qu'Ansible suffira ici ? Peut-être. Mais des compléments complets, en général, ne fonctionnent pas sans configurations. Ces configurations peuvent varier en fonction du type de cluster (aws, gce, azure, bare-metal, do, …). Certaines configurations ne peuvent pas être définies à l'avance — elles doivent être extraites du cluster. Et le cluster n'est pas statique : pour certaines configurations, il faudra surveiller les changements. Et là, Ansible ne suffit pas : il faut un programme qui vit dans le cluster, c'est-à-dire un Kubernetes Operator.

Ceux qui ont essayé en pratique shell-operator, diront que les tâches d'installation et de mise à jour des compléments et de suivi des configurations peuvent tout à fait être résolues à l'aide de hooks pour le shell-operator. On peut écrire un script qui fera un conditionnel kubectl apply et surveiller, par exemple, le ConfigMap, où seront stockées les configurations. C'est à peu près ce qui est réalisé dans l'addon-operator.

Comment cela est-il organisé dans l'addon-operator ?

En créant une nouvelle solution, nous avons basé notre approche sur les principes suivants :

• L'installateur de modules doit soutenir la templatisation et la configuration déclarative. Nous n'utilisons pas de scripts magiques qui installent des modules. L'addon-operator utilise Helm pour l'installation des modules. Pour installer, il faut créer un chart et spécifier les valeurs qui seront utilisées pour la configuration.
• Les paramètres peuvent être générés lors de l'installation, ils peuvent être obtenus depuis le cluster, ou bien recevoir des mises à jour, en surveillant les ressources du cluster. Ces opérations peuvent être réalisées à l'aide de hooks.
• Les paramètres peuvent être stockées dans le cluster. Pour stocker les configurations dans le cluster, un ConfigMap/addon-operator est créé et l'addon-operator suit les changements de ce ConfigMap. L'addon-operator donne accès aux hooks aux paramètres par le biais d'accords simples.
• Le module dépend des paramètres. Si les paramètres changent, l'addon-operator déploie le chart Helm avec de nouvelles valeurs. La combinaison du chart Helm, des valeurs pour celui-ci et des hooks est appelée un module (voir ci-dessous pour plus de détails).
• Mise en scène. Pas de scripts de publication magiques. Le mécanisme de mise à jour est similaire à celui d'une application classique — assembler les modules et l'addon-operator dans une image, les taguer et les déployer.
• Contrôle des résultats. L'addon-operator peut fournir des métriques pour Prometheus.

Qu'est-ce qu'un module dans l'addon-operator ?

Un module peut être considéré comme tout ce qui ajoute de nouvelles fonctionnalités au cluster. Par exemple, l'installation de Ingress est un excellent exemple de module. Cela peut être n'importe quel opérateur ou contrôleur avec son CRD : prometheus-operator, cert-manager, kube-controller-manager, etc. Ou quelque chose de petit mais facilitant l'exploitation — par exemple, un copieur de secrets qui copie les secrets de registry dans de nouveaux espaces de noms, ou un réglage de sysctl qui configure les paramètres sysctl sur de nouveaux nœuds.

Pour la réalisation des modules, l'addon-operator fournit plusieurs concepts :

• Helm-chart est utilisé pour installer divers logiciels dans le cluster — par exemple, Prometheus, Grafana, nginx-ingress. Si le composant souhaité dispose d'un Helm-chart, il sera très simple de l'installer via l'addon-operator.
• Stockage des valeurs. Les Helm-charts ont généralement de nombreux paramètres différents qui peuvent évoluer avec le temps. L'addon-operator prend en charge le stockage de ces paramètres et sait surveiller leurs changements afin de réinstaller le Helm-chart avec de nouvelles valeurs.
• Hooks — ce sont des fichiers exécutables que l'Addon-operator lance en réponse à des événements et qui accèdent au stockage des valeurs. Un hook peut surveiller les changements dans le cluster et mettre à jour les valeurs dans le stockage des valeurs. C'est-à-dire qu'avec les hooks, on peut effectuer une découverte pour collecter des valeurs du cluster au démarrage ou selon un calendrier, ou opérer une découverte continue en collectant des valeurs du cluster en fonction des changements dans celui-ci.
• Module — c'est une combinaison d'un chart Helm, d'un stockage des valeurs et de hooks. Les modules peuvent être activés et désactivés. La désactivation d'un module supprime tous les déploiements du chart Helm. Les modules peuvent s'inclure dynamiquement, par exemple si tous les modules nécessaires sont activés ou si la découverte dans les hooks a trouvé les paramètres requis — cela se fait à l'aide d'un script « enabled » auxiliaire.
• Hooks globaux. Ce sont des hooks « autonomes », qui ne sont pas inclus dans les modules et ont accès au stockage global des valeurs, dont les valeurs sont accessibles à tous les hooks des modules.

Comment ces parties fonctionnent-elles ensemble ? Regardons l'image dans la documentation :

Il y a deux scénarios de fonctionnement :

1. Le hook global se déclenche par un événement — par exemple, lors d'un changement de ressource dans le cluster. Ce hook traite les modifications et enregistre les nouvelles valeurs dans le stockage global des valeurs. L'Addon-operator remarque que le stockage global a changé et lance tous les modules. Chaque module détermine à l'aide de ses hooks s'il doit s'activer et met à jour son stockage des valeurs. Si un module est activé, l'Addon-operator lance l'installation du chart Helm. Le chart Helm a alors accès aux valeurs du stockage du module et du stockage global.
2. Le second scénario est plus simple : le hook du module se déclenche par un événement, modifie les valeurs dans le stockage des valeurs du module. L'Addon-operator le remarque et lance le chart Helm avec les valeurs mises à jour.

Un addon peut être implémenté sous la forme d'un seul hook, ou en tant que chart Helm, ou même comme plusieurs modules dépendants — cela dépend de la complexité du composant à installer dans le cluster et du niveau de flexibilité des réglages requis. Par exemple, dans le dépôt (/examples) il y a un addon sysctl-tuner, qui est implémenté à la fois sous la forme d'un simple module avec un hook et un chart Helm, ainsi qu'en utilisant un stockage des valeurs, ce qui permet d'ajouter des réglages par l'édition de ConfigMap.

Distribution des mises à jour

Quelques mots sur l'organisation des mises à jour des composants que met en place l'Addon-operator.

Pour lancer l'Addon-operator dans le cluster, il faut compiler une image avec les ajouts sous forme de fichiers hooks et de charts Helm, ajouter le fichier binaire addon-operator et tout ce dont vous avez besoin pour les hooks : bash, kubectl, jq, python etc. Ensuite, cette image peut être déployée dans le cluster comme une application ordinaire et il est fort probable que vous souhaitiez organiser un schéma de versionnement. Si vous avez peu de clusters, la même approche que pour les applications peut convenir : nouvelle version, nouvelle étiquette, passer en revue tous les clusters et mettre à jour l'image dans les Pods. Cependant, dans le cas d'un déploiement sur un nombre significatif de clusters, le concept de mise à jour automatique à partir d'un canal est plus adapté.

Nous l'organisons de cette manière :

• Un canal est essentiellement un identifiant que vous pouvez définir comme bon vous semble (par exemple, dev/stage/ea/stable).
• Le nom du canal est l'étiquette de l'image. Lorsque des mises à jour doivent être déployées dans le canal, une nouvelle image est construite et étiquetée avec le nom du canal.
• Lorsque qu'une nouvelle image apparaît dans le registre, l'Addon-operator redémarre et se lance avec la nouvelle image.

Ce n'est pas la meilleure pratique, comme indiqué dans la documentation Kubernetes. Cela n'est pas recommandé, mais il s'agit de une application ordinaire qui vit dans un seul cluster. Dans le cas de l'Addon-operator, l'application consiste en de nombreux Deployments répartis sur différents clusters, et la mise à jour automatique est d'une grande aide et facilite la vie.

Les canaux aident aussi dans les tests: s'il y a un cluster de test, vous pouvez le configurer sur un canal ) — une unité d'organisation du pipeline, contenant 1+ tâche, et tester les mises à jour avant de les déployer sur les canaux ea et stable. Si une erreur se produit avec le cluster sur le canal ea , vous pouvez le basculer sur stable, pendant que l'enquête sur le problème avec ce cluster est en cours. Si le cluster est retiré de la prise en charge active, il est basculé sur son canal « figé » — par exemple, freeze-2019-03-20.

En plus des mises à jour des hooks et des charts Helm, il peut être nécessaire de mettre à jour un composant tiers. Par exemple, si vous avez remarqué un bug dans un supposé node-exporter et même trouvé comment le patcher. Puis vous ouvrez un PR et attendez la nouvelle version pour passer en revue tous les clusters et augmenter la version de l'image. Pour ne pas attendre indéfiniment, vous pouvez compiler votre propre node-exporter et passer à celui-ci en attendant l'acceptation du PR.

En fait, cela peut être fait sans l'Addon-operator, mais avec l'Addon-operator, le module pour l'installation de node-exporter sera visible dans un seul dépôt, le Dockerfile pour construire votre image peut également y être maintenu, ce qui permet à tous les participants de mieux comprendre ce qui se passe… Et si plusieurs clusters sont en place, il devient plus facile de tester votre PR ainsi que de déployer une nouvelle version !

Cette organisation de mise à jour des composants fonctionne avec succès chez nous, mais il est également possible de mettre en œuvre tout autre schéma approprié — après tout dans ce cas, l'Addon-operator est un simple fichier binaire.

Conclusion

Les principes mis en œuvre dans l'Addon-operator permettent de construire un processus transparent de création, de test, d'installation et de mise à jour des addons dans le cluster, similaire aux processus de développement d'applications ordinaires.

Les addons pour l'Addon-operator au format de modules (Helm-chart + hooks) peuvent être rendus largement accessibles. Nous, la société Flant, prévoyons de publier au cours de l'été nos travaux sous forme de tels addons. Rejoignez le développement sur GitHub (shell-operator, addon-operator), essayez de créer votre propre addon basé sur des exemples et documentation, attendez les nouvelles sur Habr et sur notre chaîne YouTube!

P.S.

Lisez aussi dans notre blog :

• «Élargir et compléter Kubernetes (aperçu et vidéo de la présentation)»;
• «Nous vous présentons le shell-operator : créer des opérateurs pour Kubernetes est devenu encore plus facile».

Source : habr.com