
Après l'
opérateur shell, nous présentons son frère aîné -
opérateur addon . Il s'agit d'un projet Open Source utilisé pour installer des composants système dans le cluster Kubernetes, qui peut être appelé un mot courant - modules complémentaires.
Pourquoi faire des ajouts?
Ce n'est un secret pour personne que Kubernetes n'est pas un produit fini tout-en-un, et divers ajouts seront nécessaires pour créer un cluster «adulte». Addon-operator vous aidera à installer, configurer et maintenir ces modules complémentaires à jour.
Le besoin de composants supplémentaires dans le cluster est révélé dans un
rapport de collègues
driusha . En bref, la situation avec Kubernetes en ce moment est que pour une installation simple, vous pouvez "jouer" avec des composants prêts à l'emploi, pour les développeurs et les tests, vous pouvez ajouter Ingress, mais pour une installation complète, que 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 les journaux, n'oubliez pas l'entrée et le gestionnaire de certificats, sélectionnez des groupes de nœuds, ajoutez des stratégies réseau, assaisonnez avec sysctl et les paramètres de mise à l'échelle automatique des pods ...

Quelles sont les spécificités de travailler avec eux?
Comme le montre la pratique, le cas n'est pas limité à une seule installation. Pour un travail confortable avec le cluster, les modules complémentaires devront être mis à jour, désactivés (supprimés du cluster) et vous voudrez tester quelque chose avant de l'installer dans le cluster de production.
Alors peut-être qu'Ansible suffit ici? C'est possible. Mais les
ajouts à part entière dans le cas général ne vivent pas sans paramètres . Ces paramètres peuvent varier en fonction de l'option de cluster (aws, gce, azure, bare-metal, do, ...). Certains paramètres ne peuvent pas être définis à l'avance - ils doivent être obtenus à partir du cluster. Et le cluster n'est pas statique: pour certains paramètres, vous devrez suivre les modifications. Et ici Ansible manque déjà: nous avons besoin d'un programme qui vit dans un cluster, c'est-à-dire Opérateur Kubernetes.
Ceux qui ont essayé l'
opérateur shell en fonctionnement diront que les tâches d'installation et de mise à jour des modules complémentaires et des paramètres de suivi peuvent être complètement résolues à l'aide de
crochets pour l'opérateur shell. Vous pouvez écrire un script qui
kubectl apply
et surveillera
kubectl apply
, par exemple, ConfigMap, où les paramètres seront stockés. C'est approximativement ce qui est implémenté dans addon-operator.
Comment est-ce organisé en addon-operator?
Pour créer une nouvelle solution, nous sommes partis des principes suivants:
- Le programme d'installation du module complémentaire doit prendre en charge les modèles et la configuration déclarative . Nous ne faisons pas de scripts magiques qui installent des modules complémentaires. L'opérateur d'addon utilise Helm pour installer les modules complémentaires. Pour installer, vous devez créer un graphique et mettre en évidence les valeurs qui seront utilisées pour configurer.
- Les paramètres peuvent être générés lors de l'installation , ils peuvent être obtenus à partir du cluster ou recevoir des mises à jour en surveillant les ressources du cluster. Ces opérations peuvent être implémentées à l'aide de crochets.
- Les paramètres peuvent être stockés dans un cluster . Pour stocker les paramètres dans le cluster, ConfigMap / addon-operator est créé et Addon-operator surveille les modifications de ce ConfigMap. Addon-operator donne aux hooks accès aux paramètres à l'aide de conventions simples.
- L'addition dépend des paramètres . Si les paramètres ont changé, l'opérateur Addon déploie le Helm-chart avec de nouvelles valeurs. L'union du graphique Helm, ses valeurs et les crochets que nous avons appelés le module (voir ci-dessous pour plus de détails).
- Mise en scène . Aucun script de sortie magique. Le mécanisme de mise à jour est similaire à une application classique - collectez des modules complémentaires et un opérateur de module complémentaire dans une image, testez et déployez.
- Contrôle du résultat . L'opérateur d'addon peut fournir des métriques pour Prometheus.
Qu'est-ce que l'addon dans addon-operator?
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 avec son propre CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. Ou quelque chose de petit, mais simplifiant l'opération - par exemple, un copieur secret, la copie des secrets du registre vers de nouveaux espaces de noms, ou un tuner sysctl, la configuration des paramètres sysctl sur de nouveaux nœuds.
Addon-operator propose plusieurs concepts pour implémenter des modules complémentaires:
- Le graphique Helm est utilisé pour installer divers logiciels dans le cluster - par exemple, Prometheus, Grafana, nginx-ingress. Si le composant requis possède un graphique Helm, son installation à l'aide de l'opérateur Addon sera très simple.
- Réserve de valeurs . Les graphiques Helm ont généralement de nombreux paramètres différents qui peuvent changer au fil du temps. Addon-operator prend en charge le stockage de ces paramètres et est capable de surveiller leurs modifications afin de réinitialiser le Helm-chart avec de nouvelles valeurs.
- Les hooks 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. C'est-à-dire à l'aide de hooks, vous pouvez effectuer une découverte pour collecter des valeurs du cluster au démarrage ou selon un calendrier, ou une découverte continue, en collectant des valeurs du cluster par des modifications dans le cluster.
- Un module est une union d'un graphique Helm, de valeurs de stockage et de crochets. Les modules peuvent être activés et désactivés. La désactivation d'un module entraîne la suppression de toutes les versions du graphique Helm. Les modules peuvent s'activer dynamiquement, par exemple, si tous les modules dont il a besoin sont inclus ou si la découverte a trouvé les paramètres nécessaires dans les hooks - cela se fait à l'aide d'un script activé auxiliaire.
- Crochets mondiaux Il s'agit de hooks «autonomes», ils ne sont pas inclus dans les modules et ont accès au stockage de valeurs globales, dont les valeurs sont disponibles pour tous les hooks des modules.
Comment ces pièces fonctionnent-elles ensemble? Considérez l'image de la documentation:

Deux scénarios de travail:
- Un hook global est déclenché par un événement - par exemple, lorsqu'une ressource d'un cluster change. Ce hook traite les modifications et écrit les nouvelles valeurs dans le stockage de valeurs globales. L'opérateur de l'addon remarque que le stockage global a changé et lance tous les modules. Chaque module, à l'aide de ses crochets, 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 du Helm-chart. Dans ce cas, les valeurs de la mémoire du module et de la mémoire globale sont accessibles au Helm-chart.
- Le deuxième scénario est plus simple: un hook de module est déclenché par un événement, modifie les valeurs dans le stockage des valeurs du module. Addon-operator le remarque et lance le graphique Helm avec des valeurs mises à jour.
L'add-on peut être implémenté comme un seul crochet ou comme un Helm-chart, ou
même comme plusieurs modules dépendants - cela dépend de la complexité du composant installé dans le cluster et du niveau souhaité de flexibilité de configuration. Par exemple, dans le référentiel (
/ examples ), il y a un module complémentaire sysctl-tuner, qui est implémenté à la fois comme un module simple avec un crochet et un graphique Helm, et en utilisant le stockage des valeurs, qui permet d'ajouter des paramètres en modifiant ConfigMap.
Mettre à jour la livraison
Quelques mots sur l'organisation des mises à jour des composants que l'opérateur Addon installe.
Pour exécuter Addon-operator dans un cluster, vous devez
collecter une image avec des ajouts sous la forme de fichiers de graphique de hook et de barre, ajouter le fichier binaire d'
addon-operator
et tout ce qui est nécessaire pour les hooks:
bash
,
kubectl
,
jq
,
python
, etc. De plus, cette image peut être déployée sur le cluster en tant qu'application régulière, et vous souhaiterez probablement organiser tel ou tel schéma de balisage. S'il y a peu de clusters, la même approche qu'avec les applications peut convenir: une nouvelle version, une nouvelle version, parcourez tous les clusters et corrigez l'image des Pods. Cependant, dans le cas d'un déploiement vers un nombre notable de clusters, le concept d'auto-renouvellement à partir du canal nous convenait mieux.
Nous l'avons arrangé comme ceci:
- Un canal est essentiellement un identifiant qui peut être défini par n'importe qui (par exemple, dev / stage / ea / stable).
- Le nom du canal est la balise d'image. Lorsque vous devez déployer des mises à jour de la chaîne, une nouvelle image est collectée et étiquetée avec le nom de la chaîne.
- Lorsqu'une nouvelle image apparaît dans le registre, l'opérateur Addon redémarre et démarre avec la nouvelle image.
Ce n'est pas une bonne pratique, comme décrit dans la
documentation de Kubernetes . Ce n'est pas recommandé, mais nous parlons d'une
application régulière qui vit dans un cluster . Dans le cas de Addon-operator, une application est un grand nombre de déploiements répartis sur plusieurs clusters, et l'auto-mise à jour est très utile et simplifie la vie.
Les canaux aident
au test : s'il existe un cluster auxiliaire, vous pouvez le configurer sur le canal de
stage
et y effectuer des mises à jour avant de le déployer sur
stable
canaux
ea
et
stable
. Si une erreur se produit avec le cluster sur le canal
ea
, vous pouvez le basculer sur
stable
pendant qu'une enquête sur le problème avec ce cluster est en cours. Si le cluster est retiré du support actif, il passe à son canal «gelé» - par exemple,
freeze-2019-03-20
.
Outre la mise à jour des crochets et des graphiques Helm, vous devrez peut-être
mettre à
jour un composant tiers . Par exemple, vous avez remarqué une erreur dans l'exportateur de nœuds conditionnel et avez même compris comment le corriger. Ensuite, nous avons ouvert PR et attendons une nouvelle version pour parcourir tous les clusters et augmenter la version de l'image. Afin de ne pas attendre indéfiniment, vous pouvez récupérer votre nœud-exportateur et y basculer avant d'accepter le PR.
En général, cela peut être fait sans Addon-operator, mais avec Addon-operator, le module d'installation de node-exporter sera visible dans un référentiel, vous pouvez conserver le Dockerfile pour construire votre image là, il devient plus facile pour tous les participants au processus de comprendre que arrive ... Et s'il y a plusieurs clusters, il devient plus facile à la fois de tester votre PR et d'enrouler une nouvelle version!
Cette organisation des mises à jour des composants fonctionne avec succès avec nous, mais vous pouvez implémenter tout autre schéma approprié, car
dans ce cas, Addon-operator 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 ordinaires.
Les modules complémentaires pour l'opérateur Addon au format des modules (Helm-chart + hooks) peuvent être téléchargés au public. Nous, la société Flant, prévoyons de présenter nos réalisations au cours de l'été sous la forme de tels ajouts. Rejoignez le développement sur GitHub (
shell-operator ,
addon-operator ), essayez de faire votre ajout à partir d'
exemples et de
documentation , attendez les nouvelles sur le Habré et sur notre
chaîne YouTube !
MISE À JOUR (14 juin) : Si vous avez des collègues anglophones qui pourraient être intéressés par l'opérateur d'addon, alors l'annonce correspondante pour eux est disponible dans notre blog sur Medium .PS
Lisez aussi dans notre blog: