Kapitan à la tête de Kubernetes

Rencontrez Kapitan . Il vous aide à apporter de la beauté et de l'ordre à votre configuration Kubernetes .

Kapitan se fait une réputation grâce aux avis d'utilisateurs satisfaits et se passe donc d'une documentation complète et d'un marketing coûteux. Nous avons assez d' étoiles et quelques mentions de blogueurs et prédicateurs de Kubernetes. Kapitan est même devenu le protagoniste d'un chapitre entier du livre . Plus important encore, il a attiré l'attention de plusieurs sociétés prometteuses, car Kapitan, comme personne d'autre, est capable de démêler la configuration liée au nœud marin .

Sur kubernetes.slack.com, #kapitan a réussi à rassembler une petite communauté mais dévouée (rejoignez-nous!), Nous sommes donc fiers de notre travail :)

Beaucoup croient encore que Kapitan est un mélange de jsonnet et de jinja, mais ils ratent le sujet.
Dans cet article, je vais vous expliquer comment Kapitan gère les déploiements de Kubernetes, mais en général, il est capable de plus que cela. C'est important: Kapitan est universel et n'est pas fixé sur un Kubernetes. Kubernetes est simplement l'une des nombreuses utilisations.

Ce n'est pas un guide (bien que je promette un guide aussi). Je veux juste vous dire pourquoi nous l'avons fait et quels problèmes avec les déploiements de configurations Kubernetes cela devrait résoudre.

Ce que je n'ai pas aimé

J'ai commencé à expérimenter avec Kubernetes en 2015 et suis immédiatement tombé amoureux.
Certes, il y a plusieurs inconvénients que je ne veux pas supporter:

• Contexte . Pour moi, c'est l'un des concepts les plus difficiles à comprendre Kubernetes - et l'un des plus dangereux. Le contexte fait référence au client, il est difficile à comprendre, il est appelé de manière confuse et crée de la confusion lors de l'exécution des commandes kubectl . Je déteste les contextes dans kubectl!
• Configuration imbriquée verbeuse (yaml!) . J'ai dû transpirer pour comprendre chaque niveau de configuration yaml dans le manifeste. Quel est l'intérêt de répéter les étiquettes deux à trois fois à plusieurs endroits?
• Un gâchis avec des équipes impératives et déclaratives . Les nouveaux arrivants à Kubernetes sont encouragés à apprendre par des équipes impératives, bien qu'il soit clair que les gens normaux ne les utilisent pas. À mon avis, il est juste plus difficile d'intégrer Kubernetes dans la bonne stratégie de déploiement pour votre entreprise. Spoiler: Il n'y a pas de «bonne stratégie» unique.
• Configuration d'exécution . Jesse Suen a raison quand il déconseille de passer des paramètres de configuration à la ligne de commande de la barre (ou kubectl et d'autres comme ça). Avec les paramètres, la même commande peut être exécutée différemment à chaque fois.
• Configuration d'application Nous avons appris à gérer les manifestes yaml dans Kubernetes, nous sommes formidables. C'est juste en dessous et Déployer - c'est un bol vide. Il lui reste à faire flotter l'application avec toute sa configuration.
• Les développeurs veulent des vacances et le flux de travail chez Kubernetes est encore un peu perturbé. Les fans de Kubernetes forcent tout le monde à le faire sur place. Est-ce nécessaire? Obéissez à Kelsey Hightower!
• Les opérateurs J'ai des sentiments mitigés pour eux, alors pour l'instant laissez ce sujet :) Je peux seulement dire qu'ils sont souvent maltraités.
• Idempotence . Au contraire, son absence. Si nous additionnons toutes les lacunes ci-dessus, nous obtenons des flux de travail insuffisamment idempotents, ce qui est triste pour Kubernetes.

Que faire

J'ai essayé de résoudre ces problèmes et mis sur pied un petit système de modèles qui utilisait j2cli et quelques scripts bash pour gérer les configurations de Kubernetes.

Le système a tout placé dans le fichier environmentA.yaml et l'a utilisé dans le modèle Jinja2. Le déploiement d'applications de type microservice à partir de plusieurs composants a été possible avec une simple commande:

bin/apply.sh environments/environmentA.yaml 

Cool! Yaml était tout au sujet du déploiement. C’est très pratique, car je pourrais utiliser le même fichier comme source d’information pour autre chose. Dites pour ... les scripts bash !

J'ai compris comment importer des valeurs de yaml dans des scripts pour exécuter des commandes similaires:

 bin/create_kafka_topics.sh environments/environmentA.yaml 

Et puis tout est devenu hors de contrôle à la fois :

• Je n'ai rien pu faire avec la structure du fichier yaml. C'était un méli-mélo des mêmes champs, valeurs, configuration confuse.
• Vous ne saurez jamais comment vous comporter dans l'environnement avant d'avoir essayé. Souvent, cela était dû à des changements dans les modèles jinja2 en raison d'une nouvelle valeur d'inventaire (par exemple, feature_X) qui ne fonctionnait pas dans les environnements où cette fonction n'est pas définie.
• Le même problème avec les scripts: si vous n'essayez pas, vous ne savez pas.
• Parfois, Kubernetes a changé si rapidement que cela m'a dérangé de changer constamment de manifestes pour différentes versions, en particulier en jouant avec les annotations des valeurs.
• Facteur externe : l'équipe de développement est passée des fichiers de configuration aux paramètres de ligne de commande. Un changement aussi mineur nous a dérouté toutes les cartes, et nous avons dû penser à une nouvelle solution.
• Plus important encore : créer des modèles de yaml avec Jinja (ou des modèles Go) n'est PAS amusant! Nous avons ensuite eu une énigme: « Qu'est-ce qui ressemble à du texte, se lit comme du texte, sent comme du texte, mais pas du texte? ". Ou, comme Lee Briggs l'a si bien dit: « Pourquoi diable sommes-nous le modèle yaml? "

Kapitan: Devenir

Nous avons rassemblé toute notre amère expérience et, avec Ricardo Amaro, nous avons commencé à rêver d'un système de gestion de configuration idéal. Ensuite, nous n'avions toujours pas une image claire, mais nous savions que nous aimions et que nous n'aimions pas.

L'amour :

• Git.
• Patterning en général: données / valeurs distinctes des patterns.
• Valeurs distinctes pour différents aspects (application, Kubernetes, runtime ...).
• Approche orientée objet.
• Yaml simplifié comme interface où cacher la complexité de Kubernetes.
• Une compréhension claire de ce qui se passe et pourquoi.
• Réutilisation de valeurs dans différents composants.
• Et les scripts devraient avoir accès aux valeurs.

Nous n'aimons pas :

• Contextes Kubectl
• Moteurs de modèles de texte pour créer yaml.
• Nombre d'indentations: {{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} .
• Magie: tout doit être clair et net. Pas de trucs.
• Gestion manuelle des mots de passe et secrets de l'application.
• Approche Tiller: Nous voulions contrôler l'utilisation des manifestes.
• Approche Git-crypt: les secrets sur le disque ne sont pas cryptés.
• Pipeline de modèles directement vers kubectl.
• Passer des options de ligne de commande.

Et puis deux choses se sont produites :

1. Nous avons découvert le jsonnet de Dave Cunningham pour avoir modelé yaml / json dans un langage orienté objet.
2. Gustavo Buriola nous a montré le reclassement et sans lui nous ne serions pas allés loin.

Ricardo Amaro s'est mis au travail, et bientôt toute l'équipe s'est assise chez Kapitan - certains ont travaillé sur la fonctionnalité de base, d'autres sur son utilisation dans nos projets internes. Gestion des secrets, support gpg \ kms, fonctions définies par l'utilisateur: maintenant Kapitan est un produit à part entière qui fait plus que promis.

Qui est Kapitan?

Kapitan essaie de résoudre tous (ou presque tous) les problèmes dont j'ai parlé.

D'un point de vue technique, Kapitan est très simple:

• Inventaire : une collection hiérarchique de valeurs décrivant le déploiement basé sur yaml. Basé sur le reclassement. Comme hiera.
• Moteurs de modèles : maintenant c'est Jinja2, Jsonnet, Kadet. Ils font l'inventaire et créent des fichiers (yaml, json, documentation ou scripts bash).
• Secrets : secrets des modèles, et Kapitan s'en occupera.

Nous utilisons jsonnet pour modéliser les manifestes et Jinja pour faire le reste.

Parfois, les gens se plaignent que le fichier jsonnet est complètement différent du même yaml, il leur est donc difficile de passer à jsonnet.

Nous avons essayé de résoudre ce problème avec Kadet en enveloppant yaml en Python. Prenez votre yaml préféré comme base et ajoutez-y du Python.

Considérez ceci comme un exosquelette Python pour yaml! Je vais en parler en quelque sorte.

Dans le workflow, Kapitan montre immédiatement le personnage:

• Liberté de choix : nous n'imposons pas de processus de travail et de technologies, mais travaillons généralement sur les principes décrits ci-dessous. En fait, Kapitan peut être utilisé comme vous le souhaitez. Vous n'êtes pas obligé d'utiliser git, vous ne devez pas y compiler de fichiers, et vous pouvez même vous passer de jsonnet! Faites ce que vous voulez.
• GitOps à la moelle osseuse: tout dans git, tout dans une lumière maîtresse qui reflète notre intention.
• Déclarabilité : Kapitan se félicite de la compilation de modèles de manifeste dans des représentations spécifiques. Et vous compilez vos scripts.
• Contexte contrôlé : nous utilisons des scripts compilés pour simplifier notre travail, par exemple, lors de la définition de contextes et de la configuration de clusters.
  Configuration de Kubernetes: compiled/target_A/setup/setup.sh
  Appliquer les modifications: compiled/target_A/setup/apply.sh
• Idempotence : Kapitan vous permet de modifier les modèles et les outils de refactorisation de code. Les manifestes et le code compilés ne changeront pas sans votre commande, vous n'avez donc rien à craindre lors de la refactorisation.
• Cause et effet : nous sommes pour un workflow où les modifications de l'inventaire ou des modèles et des fichiers compilés sont incluses dans une demande de fusion. Ainsi, le réviseur sera en mesure d'évaluer vos changements et leurs conséquences réelles. Il est bon de savoir si une modification du modèle affectera une, deux ou plusieurs cibles.
• Et enfin : Kapitan n'est pas attaché à Kubernetes. Il crée simplement des fichiers. Le déploiement des changements impliquait kubectl . Nous donnons uniquement un shell pour les commandes à exécuter de manière cohérente.

En ai-je besoin?

Disons-le clairement : vous n'avez probablement pas encore besoin de Kapitan.

Mais tout dépend de ce que vous essayez de faire et de la complexité de votre système.

Kapitan est un puissant outil d' investissement. Utilisez-le dans des scénarios complexes où vous devez déployer un tas d'applications sur un tas de clusters.

Si vous avez des applications standard, vous apprenez simplement Kubernetes ou êtes déjà satisfait de votre flux de travail, alors Helm ou son alternative actuelle fonctionnera.

J'imagine Helm comme apt-get pour Kubernetes , et Kapitan est quelque chose comme Puppet .

Dans le prochain article, je donnerai des exemples spécifiques et décrirai en détail l'inventaire. Écrivez ce que vous voulez savoir ou ce avec quoi vous êtes d'accord / en désaccord dans ce post.

Merci à Jacek Gruzewski .