Remarque perev. : L'article a été écrit par Scott Lowe, un ingénieur informatique senior qui est l'auteur / co-auteur de sept livres imprimés (principalement pour VMware vSphere). Il travaille actuellement dans sa filiale VMware, Heptio (acquise en 2016), spécialisée dans le cloud computing et Kubernetes. Le texte lui-même sert d'introduction vaste et facile à comprendre à la gestion de la configuration pour Kubernetes à l'aide de la technologie Kustomize , récemment incluse avec les K8.
Kustomize est un outil qui permet aux utilisateurs de "personnaliser des fichiers YAML simples et sans modèle à diverses fins, en laissant le YAML d'origine intact et utilisable" (la description est empruntée directement
au référentiel kustomize sur GitHub ). Kustomize peut être exécuté directement ou, à partir de Kubernetes 1.14, utiliser
kubectl -k pour accéder à ses fonctions (bien que depuis Kubernetes 1.15, un binaire distinct soit plus récent que les fonctionnalités intégrées à kubectl).
( Remarque : Avec la récente version de Kubernetes 1.16 , kustomize est également pris en charge dans l'utilitaire kubeadm.) Dans cet article, je souhaite présenter aux lecteurs les bases de kustomize.
Dans sa forme / application la plus simple, kustomize est simplement une collection de ressources (fichiers YAML qui définissent les objets Kubernetes: déploiements, services, etc.) plus une liste d'instructions sur les modifications à apporter à ces ressources. Tout comme make utilise le jeu d'instructions contenu dans le
Makefile et Docker
Dockerfile conteneur basé sur les instructions du
Dockerfile , kustomize utilise
kustomization.yaml pour stocker des instructions sur les modifications que l'utilisateur souhaite apporter au jeu de ressources.
Voici un exemple de fichier
kustomization.yaml :
resources: - deployment.yaml - service.yaml namePrefix: dev- namespace: development commonLabels: environment: development
Je n'essaierai pas de parler de tous les champs possibles du fichier
kustomization.yaml (c'est bien écrit
ici ), mais je donnerai une brève explication d'un exemple spécifique:
- Le champ des
resources indique quelles (quelles ressources) kustomize va changer. Dans ce cas, il recherchera des ressources dans les fichiers deployment.yaml et service.yaml dans son répertoire (si nécessaire, vous pouvez spécifier des chemins d'accès complets ou relatifs). - Le champ
namePrefix demande à kustomize d'ajouter un préfixe spécifique (dans ce cas, dev- ) à l'attribut name de toutes les ressources définies dans le champ resources . Ainsi, s'il existe un name dans Deployment avec la valeur nginx-deployment , kustomize en fera dev-nginx-deployment . - Le champ d'
namespace demande à kustomize d'ajouter l'espace de noms spécifié à toutes les ressources. Dans ce cas, Deployment and Service tombera dans l'espace de noms de development . - Enfin, le champ
commonLabels contient un ensemble d'étiquettes qui seront ajoutées à toutes les ressources. Dans notre exemple, kustomize attribuera une étiquette aux ressources avec l' environment nom et le development valeur.
Si l'utilisateur exécute
kustomize build . dans le répertoire avec le fichier
kustomization.yaml et les ressources nécessaires (c'est-à-dire les fichiers
deployment.yaml et
service.yaml ), puis à la sortie, il recevra le texte avec les modifications enregistrées dans
kustomization.yaml .
Remarque perev. : Illustration tirée de la documentation du projet pour l'utilisation «simple» de kustomizeLa sortie peut être redirigée si vous devez valider les modifications:
kustomize build . > custom-config.yaml
La sortie est déterministe (avec la même entrée, la même sortie sera obtenue), vous ne pouvez donc pas enregistrer le résultat dans un fichier. Au lieu de cela, vous pouvez immédiatement le passer à une autre commande:
kustomize build . | kubectl apply -f -
Les fonctions Kustomize sont également accessibles via
kubectl -k (depuis la version 1.14 de Kubernetes). Cependant, gardez à l'esprit qu'un package kustomize distinct est mis à jour plus rapidement qu'un package intégré dans kubectl (du moins c'est le cas avec la version de Kubernetes 1.15).
Les lecteurs peuvent demander: «Pourquoi toutes ces difficultés, si vous pouvez éditer des fichiers directement?». Grande question. Dans notre exemple, il est vraiment
possible de modifier directement les fichiers
deployment.yaml et
service.yaml , mais qu'en est-il s'ils sont un fork du projet de quelqu'un d'autre? La modification directe des fichiers rend difficile (voire impossible) le rebasage du fork lorsque des modifications sont apportées à la source / source. L'utilisation de kustomize vous permet de centraliser ces modifications dans le fichier
kustomization.yaml , en laissant les fichiers d'origine intacts et en facilitant ainsi le rebase des fichiers source si nécessaire.
Les avantages de kustomize deviennent évidents dans des cas d'utilisation plus complexes. Dans l'exemple ci-dessus,
kustomization.yaml et les ressources se trouvent dans le même répertoire. Cependant, kustomize prend en charge les scénarios d'utilisation lorsqu'il existe une configuration de base et plusieurs de ses variantes, également appelées
superpositions . Par exemple, un utilisateur voulait prendre Déploiement et Service pour nginx, que j'ai utilisé comme exemple, et créer des versions (ou variantes) de développement, de transfert et de production (ou variantes) de ces fichiers. Pour ce faire, il aura besoin des superpositions mentionnées ci-dessus et, en fait, des ressources de base elles-mêmes.
Pour illustrer l'idée de superpositions et
de ressources de base , supposons que les répertoires aient la structure suivante:
- base - deployment.yaml - service.yaml - kustomization.yaml - overlays - dev - kustomization.yaml - staging - kustomization.yaml - prod - kustomization.yaml
Dans le
base/kustomization.yaml utilisateurs utilisent simplement le champ des
resources pour déclarer les ressources que kustomize doit activer.
Dans chacun des
overlays/{dev,staging,prod}/kustomization.yaml utilisateurs se réfèrent à la configuration de base dans le champ des
resources , puis indiquent les modifications spécifiques à
cet environnement . Par exemple, le
overlays/dev/kustomization.yaml peut ressembler à l'exemple donné précédemment:
resources: - ../../base namePrefix: dev- namespace: development commonLabels: environment: development
Dans le même temps, le
overlays/prod/kustomization.yaml peut être complètement différent:
resources: - ../../base namePrefix: prod- namespace: production commonLabels: environment: production sre-team: blue
Lorsque l'utilisateur démarre la
kustomize build . dans le
overlays/dev , kustomize générera une option de développement. Si vous exécutez
kustomize build . dans le répertoire
overlays/prod - vous obtenez l'option de production. Et tout cela - sans apporter de modifications aux fichiers
(de base) d'origine , et tout cela - de manière déclarative et déterministe. Vous pouvez valider la configuration de base et les répertoires de superposition directement dans le système de contrôle de version, sachant qu'à partir de ces fichiers, vous pouvez reproduire la configuration souhaitée à tout moment.
Remarque perev. : Illustration de la documentation du projet pour l'utilisation de superpositions dans kustomizeKustomize peut faire
bien plus que ce qui est décrit dans cet article. Cependant, j'espère que cela servira de bonne introduction.
Ressources supplémentaires
Il existe de nombreux bons articles et publications sur kustomize. En voici quelques-unes que j'ai trouvées particulièrement utiles:
Remarque perev. : Vous pouvez également conseiller le bloc de liens publiés en tant que ressources sur le site Web de l'utilitaire, et la collection ultérieure de vidéos avec les derniers rapports sur kustomize.Si vous avez des questions ou des suggestions pour améliorer ce matériel, je suis toujours ouvert aux commentaires. Vous pouvez me contacter sur
Twitter ou sur
la chaîne Kubernetes Slack . Amusez-vous à modifier vos manifestes avec kustomize!
PS du traducteur
Lisez aussi dans notre blog: