Suivant nous présentons son frère aîné - . Il s'agit d'un projet Open Source utilisé pour installer des composants système dans un cluster Kubernetes, qui peuvent être appelés modules complémentaires.
Pourquoi des ajouts ?
Ce n'est un secret pour personne que Kubernetes n'est pas un produit tout-en-un prêt à l'emploi, et pour créer un cluster « adulte », vous aurez besoin de divers ajouts. Addon-operator vous aidera à installer, configurer et maintenir ces modules complémentaires à jour.
Le besoin de composants supplémentaires dans le cluster est divulgué dans Collègues . En bref, la situation actuelle de Kubernetes est telle que pour une simple installation « ludique », vous pouvez vous débrouiller avec les composants prêts à l'emploi, pour les développeurs et les tests, vous pouvez ajouter Ingress, mais pour une installation complète, à propos de laquelle vous pouvez dire "votre production est prête", vous devez ajouter une douzaine de modules complémentaires différents : quelque chose pour la surveillance, quelque chose pour la journalisation, n'oubliez pas l'entrée et le gestionnaire de certificats, sélectionnez des groupes de nœuds, ajoutez des politiques réseau, la saison avec les paramètres sysctl et pod autoscaler...
Quelles sont les spécificités de travailler avec eux ?
Comme le montre la pratique, l'affaire ne se limite pas à une seule installation. Pour travailler confortablement avec le cluster, les modules complémentaires devront être mis à jour, désactivés (supprimés du cluster) et vous souhaiterez en tester certains avant de les installer dans le cluster de production.
Alors, peut-être qu’Ansible suffira ici ? Peut être. Mais En général, les modules complémentaires à part entière ne vivent pas sans paramètres. Ces paramètres peuvent différer selon la variante du cluster (aws, gce, azure, bare-metal, do, ...). Certains paramètres ne peuvent pas être spécifiés à l'avance, ils doivent être obtenus auprès du cluster. Et le cluster n'est pas statique : pour certains paramètres, vous devrez surveiller les modifications. Et ici, Ansible manque déjà : vous avez besoin d'un programme qui vit dans un cluster, c'est-à-dire Opérateur Kubernetes.
Ceux qui l'ont essayé au travail , ils diront que les tâches d'installation et de mise à jour des modules complémentaires et des paramètres de surveillance peuvent être complètement résolues en utilisant pour l'opérateur shell. Vous pouvez écrire un script qui fera un conditionnel kubectl apply et surveillez, par exemple, ConfigMap, où les paramètres seront stockés. C'est à peu près ce qui est implémenté dans l'opérateur complémentaire.
Comment cela est-il organisé dans l'opérateur add-on ?
Lors de la création d'une nouvelle solution, nous sommes partis des principes suivants :
- Le programme d'installation du module complémentaire doit prendre en charge modèles et configuration déclarative. Nous ne créons pas de scripts magiques qui installent des modules complémentaires. L'opérateur de module complémentaire utilise Helm pour installer des modules complémentaires. Pour l'installer, vous devez créer un graphique et sélectionner les valeurs qui seront utilisées pour la configuration.
- Les paramètres peuvent être générer à l'installation, ils peuvent obtenir du clusterOu recevoir des mises à jour, surveillant les ressources du cluster. Ces opérations peuvent être implémentées à l’aide de hooks.
- Les paramètres peuvent être stocker dans un cluster. Pour stocker les paramètres dans le cluster, un opérateur ConfigMap/addon est créé et l'opérateur Addon surveille les modifications apportées à ce ConfigMap. L'opérateur complémentaire donne aux hooks l'accès aux paramètres à l'aide de conventions simples.
- L'ajout dépend des paramètres. Si les paramètres ont changé, l'opérateur Addon déploie la charte Helm avec de nouvelles valeurs. Nous avons appelé la combinaison du graphique Helm, de ses valeurs et des hooks un module (voir ci-dessous pour plus de détails).
- Mise en scène. Il n’existe pas de scripts de version magiques. Le mécanisme de mise à jour est similaire à une application classique : collectez les modules complémentaires et les opérateurs de modules complémentaires dans une image, marquez-les et déployez-les.
- Contrôle des résultats. L'opérateur de module complémentaire peut fournir des métriques pour Prometheus.
Qu'est-ce que le remplissage dans l'opérateur complémentaire ?
Un ajout peut être considéré comme tout ce qui ajoute de nouvelles fonctions au cluster. Par exemple, l'installation d'Ingress est un excellent exemple de module complémentaire. Il peut s'agir de n'importe quel opérateur ou contrôleur possédant son propre CRD : prometheus-operator, cert-manager, kube-controller-manager, etc. Ou quelque chose de petit, mais plus facile à utiliser - par exemple, secret copier, qui copie les secrets du registre dans de nouveaux espaces de noms, ou sysctl tuner, qui configure les paramètres sysctl sur les nouveaux nœuds.
Pour implémenter des modules complémentaires, Addon-operator propose plusieurs concepts :
- Tableau de barre utilisé pour installer divers logiciels dans le cluster - par exemple, Prometheus, Grafana, nginx-ingress. Si le composant requis possède une charte Helm, son installation à l'aide de l'opérateur Addon sera très simple.
- Stockage des valeurs. Les graphiques Helm ont généralement de nombreux paramètres différents qui peuvent changer au fil du temps. L'opérateur complémentaire prend en charge le stockage de ces paramètres et peut surveiller leurs modifications afin de réinstaller la charte Helm avec de nouvelles valeurs.
- Crochets sont des fichiers exécutables que l'opérateur Addon exécute sur des événements et qui accèdent au magasin de valeurs. Le hook peut surveiller les modifications dans le cluster et mettre à jour les valeurs dans le magasin de valeurs. Ceux. À l'aide de hooks, vous pouvez effectuer une découverte pour collecter les valeurs du cluster au démarrage ou selon un calendrier, ou vous pouvez effectuer une découverte continue, en collectant les valeurs du cluster en fonction des modifications apportées au cluster.
- Module est une combinaison d'un graphique Helm, d'un magasin de valeurs et de hooks. Les modules peuvent être activés ou désactivés. Désactiver un module signifie supprimer toutes les versions des cartes Helm. Les modules peuvent s'activer dynamiquement, par exemple, si tous les modules dont ils ont besoin sont activés ou si la découverte a trouvé les paramètres nécessaires dans les hooks - cela se fait à l'aide d'un script auxiliaire activé.
- Crochets mondiaux. Ce sont des hooks « à eux seuls », ils ne sont pas inclus dans les modules et ont accès à un magasin de valeurs globales dont les valeurs sont disponibles pour tous les hooks des modules.
Comment ces pièces fonctionnent-elles ensemble ? Regardons l'image de la documentation :
Il existe deux scénarios de travail :
- Le hook global est déclenché par un événement, par exemple lorsqu'une ressource du cluster change. Ce hook traite les modifications et écrit les nouvelles valeurs dans le magasin de valeurs globales. L'opérateur du module complémentaire remarque que le stockage global a changé et démarre tous les modules. Chaque module, à l'aide de ses hooks, détermine s'il doit être activé et met à jour son magasin de valeurs. Si le module est activé, l'opérateur Addon démarre l'installation de la charte Helm. Dans ce cas, la charte Helm a accès aux valeurs du stockage du module et du stockage global.
- Le deuxième scénario est plus simple : un hook de module est déclenché par un événement et modifie les valeurs dans le magasin de valeurs du module. L'opérateur du module complémentaire le remarque et lance le graphique Helm avec les valeurs mises à jour.
L'ajout peut être implémenté sous la forme d'un seul hook, ou sous la forme d'une seule charte Helm, ou même si plusieurs modules dépendants - cela dépend de la complexité du composant installé dans le cluster et du niveau de flexibilité de configuration souhaité. Par exemple, dans le référentiel () il existe un module complémentaire sysctl-tuner, qui est implémenté à la fois comme un simple module avec un hook et un graphique Helm, et en utilisant le magasin de valeurs, qui permet d'ajouter des paramètres en éditant ConfigMap.
Livraison des mises à jour
Quelques mots sur l'organisation des mises à jour des composants installés par l'opérateur Addon.
Pour exécuter l'opérateur Addon dans un cluster, vous avez besoin construire une image avec des ajouts sous forme de fichiers de graphiques hook et Helm, ajoutez un fichier binaire addon-operator et tout ce dont vous avez besoin pour les crochets : bash, kubectl, jq, python etc. Ensuite, cette image peut être déployée sur le cluster en tant qu'application standard, et vous souhaiterez probablement organiser l'un ou l'autre système de balisage. S'il y a peu de clusters, la même approche que pour les applications peut convenir : nouveau release, nouvelle version, aller sur tous les clusters et corriger l'image des Pods. Cependant, dans le cas d'un déploiement sur un nombre important de clusters, le concept d'auto-mise à jour depuis un canal nous convenait mieux.
Voici comment nous procédons :
- Un canal est essentiellement un identifiant qui peut être défini sur n'importe quoi (par exemple, dev/stage/ea/stable).
- Le nom de la chaîne est la balise d'image. Lorsque vous devez déployer des mises à jour sur une chaîne, une nouvelle image est assemblée et étiquetée avec le nom de la chaîne.
- Lorsqu'une nouvelle image apparaît dans le registre, l'opérateur Addon est redémarré et lancé avec la nouvelle image.
Ce n'est pas une bonne pratique, comme écrit dans . Ce n'est pas recommandé de faire cela, mais nous parlons de une application régulière qui vit dans le même cluster. Dans le cas d'un opérateur Addon, une application représente de nombreux déploiements dispersés sur des clusters, et la mise à jour automatique aide beaucoup et facilite la vie.
Aide des chaînes et en test: s'il y a un cluster auxiliaire, vous pouvez le configurer sur le canal stage et intégrez-y les mises à jour avant de les déployer sur les chaînes ea и stable. Si avec un cluster sur le canal ea une erreur s'est produite, vous pouvez le basculer sur stable, pendant que le problème avec ce cluster est à l'étude. Si le cluster est retiré du support actif, il passe à son canal "gelé" - par exemple, freeze-2019-03-20.
En plus de mettre à jour les hooks et les graphiques Helm, vous devrez peut-être mise à jour et composant tiers. Par exemple, vous avez remarqué un bug dans l'exportateur de nœuds conditionnel et avez même compris comment le corriger. Ensuite, vous avez ouvert le PR et attendez que la nouvelle version parcoure tous les clusters et augmente la version de l'image. Afin de ne pas attendre indéfiniment, vous pouvez créer votre exportateur de nœuds et y basculer avant d'accepter le PR.
En général, cela peut être fait sans opérateur Addon, mais avec l'opérateur Addon, le module d'installation de node-exporter sera visible dans un référentiel, le Dockerfile pour construire votre image peut être conservé là, cela devient plus facile pour tous les participants le processus pour comprendre ce qui se passe... Et s'il y a plusieurs clusters, alors il devient plus facile à la fois de tester votre PR et de déployer une nouvelle version !
Cette organisation de mise à jour des composants fonctionne avec succès pour nous, mais tout autre schéma approprié peut être mis en œuvre - après tout dans ce cas, l'opérateur Addon est un simple fichier binaire.
Conclusion
Les principes mis en œuvre dans Addon-operator vous permettent de créer un processus transparent de création, de test, d'installation et de mise à jour de modules complémentaires dans un cluster, similaire aux processus de développement d'applications classiques.
Les modules complémentaires pour l'opérateur Addon au format module (graphique Helm + hooks) peuvent être rendus publics. Nous, la société Flant, prévoyons de publier nos développements sous la forme de tels ajouts au cours de l'été. Rejoignez le développement sur GitHub (, ), essayez de faire votre propre ajout en fonction de и , attendez des nouvelles sur Habré et sur notre !
PS
A lire aussi sur notre blog :
- «";
- «».
Source: habr.com