Une brève introduction à Kustomize

Noter. trad.: L'article a été rédigé par Scott Lowe, un ingénieur possédant une vaste expérience en informatique, qui est l'auteur/co-auteur de sept livres imprimés (principalement sur VMware vSphere). Il travaille désormais pour sa filiale VMware Heptio (acquise en 2016), spécialisée dans le cloud computing et Kubernetes. Le texte lui-même constitue une introduction concise et facile à comprendre à la gestion de la configuration pour Kubernetes à l'aide de la technologie. Personnaliser, qui a récemment rejoint les K8.

Kustomize est un outil qui permet aux utilisateurs de « personnaliser des fichiers YAML simples et sans modèle à des fins différentes, en laissant le YAML d'origine intact et utilisable » (description empruntée directement à personnaliser le dépôt sur GitHub). Kustomize peut être exécuté directement ou, à partir de Kubernetes 1.14, utilisé kubectl -k pour accéder à ses fonctionnalités (bien que depuis Kubernetes 1.15, le binaire séparé soit plus récent que les fonctionnalités intégrées à kubectl). (Noter. trad.: Et avec la récente version Kubernetes 1.16 personnaliser soutenu par également 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 pour les modifications qui doivent être apportées à ces ressources. Tout comme make utilise le jeu d'instructions contenu dans Makefile, et Docker construit le conteneur en fonction des instructions de Dockerfile,personnaliser les usages kustomization.yaml pour stocker des instructions sur les modifications que l'utilisateur souhaite apporter à un ensemble de ressources.

Voici un fichier exemple 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 dans le fichier. kustomization.yaml (c'est bien écrit sur ici), mais je vais donner une brève explication d'un exemple spécifique :

• Champ resources indique ce que (quelles ressources) kustomize va changer. Dans ce cas, il recherchera des ressources dans les fichiers deployment.yaml и service.yaml dans votre répertoire (vous pouvez spécifier des chemins complets ou relatifs si nécessaire).
• Champ namePrefix demande à kustomize d'ajouter un certain préfixe (dans ce cas - dev-) attribuer name toutes les ressources définies dans le champ resources. Ainsi, si le déploiement a name avec un sens nginx-deployment, personnaliser le fera dev-nginx-deployment.
• Champ namespace demande à kustomize d'ajouter l'espace de noms donné à toutes les ressources. Dans ce cas, le déploiement et le service tomberont dans l'espace de noms development.
• Enfin, le terrain commonLabels contient un ensemble d'étiquettes qui seront ajoutées à toutes les ressources. Dans notre exemple, kustomize attribuera une étiquette aux ressources portant le nom environment et sens development.

Si l'utilisateur le fait kustomize build . dans le répertoire avec le fichier kustomization.yaml et les ressources nécessaires (c'est-à-dire les fichiers deployment.yaml и service.yaml), puis en sortie, il recevra un texte avec les modifications spécifiées dans kustomization.yaml.

Noter. trad.: Illustration issue de la documentation du projet sur l'utilisation « simple » de kustomize

La sortie peut être redirigée si les modifications doivent être validées :

kustomize build . > custom-config.yaml

Les données de sortie sont déterministes (les mêmes données d'entrée produiront les mêmes résultats de sortie), vous n'avez donc pas besoin de sauvegarder le résultat dans un fichier. Au lieu de cela, il peut être transmis directement à une autre commande :

kustomize build . | kubectl apply -f -

Les fonctionnalités de personnalisation sont également accessibles via kubectl -k (depuis Kubernetes version 1.14). Cependant, gardez à l'esprit que le package kustomize autonome est mis à jour plus rapidement que le package kubectl intégré (du moins c'est le cas avec la version Kubernetes 1.15).

Les lecteurs peuvent se demander : « Pourquoi toute cette complexité si vous pouvez modifier les fichiers directement ? » Excellente question. Dans notre exemple, en effet on peut modifier des fichiers deployment.yaml и service.yaml directement, mais que se passe-t-il s'il s'agit d'un fork du projet de quelqu'un d'autre ? Changer de fichiers directement rend difficile (voire impossible) le rebasement d'un fork lorsque des modifications sont apportées à l'origine/source. Utiliser kustomize permet de centraliser ces modifications dans un fichier kustomization.yaml, laissant les fichiers originaux intacts et facilitant ainsi le rebasement des fichiers originaux 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 sont dans le même répertoire. Cependant, kustomize prend en charge les cas d'utilisation dans lesquels il existe une configuration de base et de nombreuses variantes de celle-ci, également appelées superpositions. Par exemple, un utilisateur souhaitait utiliser Deployment and Service pour nginx, que j'ai utilisé comme exemple, et créer des versions (ou variantes) de développement, de préparation et de production de ces fichiers. Pour ce faire, il aura besoin des superpositions mentionnées ci-dessus et, de fait, des ressources de base elles-mêmes.

Pour illustrer l'idée de superpositions et de ressources sous-jacentes (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

En fichier base/kustomization.yaml utilisateurs utilisant le champ resources déclarez simplement les ressources que kustomize doit inclure.

Dans chacun des fichiers overlays/{dev,staging,prod}/kustomization.yaml les utilisateurs se réfèrent à la configuration de base sur le terrain resources, puis indiquez les modifications spécifiques pour environnement donné. Par exemple, fichier overlays/dev/kustomization.yaml pourrait ressembler à l’exemple donné plus tôt :

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Dans ce cas, le fichier overlays/prod/kustomization.yaml ça pourrait être complètement différent :

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Lorsque l'utilisateur exécute kustomize build . dans le catalogue overlays/dev, kustomize générera l'option de développement. Si tu cours kustomize build . dans le catalogue overlays/prod - vous bénéficiez de l'option production. Et tout cela - sans apporter aucune modification à l'original (basique) fichiers, le tout de manière déclarative et déterministe. Vous pouvez valider la configuration de base et les répertoires de superposition directement dans le contrôle de version, sachant qu'à partir de ces fichiers vous pouvez reproduire à tout moment la configuration souhaitée.

Noter. trad.: Illustration tirée de la documentation du projet sur l'utilisation des superpositions dans kustomize

Personnaliser peut beaucoup plus que ce qui est couvert dans cet article. Cependant, j’espère que cela constituera une bonne introduction.

Ressources additionnelles

Il existe de nombreux bons articles et publications sur kustomize. En voici quelques-uns que j’ai trouvés particulièrement utiles :

• Modifier la configuration YAML de base pour différents environnements de production/test à l'aide de Kustomize;
• Kustomize — La bonne façon de créer des modèles dans Kubernetes;
• Gestion déclarative des objets Kubernetes à l'aide de Customize;
• Personnalisation des graphiques Helm en amont avec Customize.

Noter. trad.: Vous pouvez également recommander un bloc de liens publiés sous forme Ressources sur le site Web de l'utilitaire, suivi d'une collection 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 au Twitter ou Canal Kubernetes Slack. Amusez-vous à modifier vos manifestes avec kustomize !

PS du traducteur

A lire aussi sur notre blog :

• «Outils pour les développeurs d'applications exécutées sur Kubernetes";
• «Kubernetes 1.14 : tour d'horizon des principales innovations";
• «Cinq principaux résultats du Helm Summit 2019 à Amsterdam";
• «Introduction pratique au gestionnaire de packages pour Kubernetes - Helm».

Source: habr.com