🥇Kubernetes 1.16 : aperçu des principales nouveautés | ProHoster

Note de traduction.: Cet article a été écrit par Scott Lowe, un ingénieur expérimenté en IT, qui est l'auteur/co-auteur de sept livres imprimés (principalement sur VMware vSphere). Il travaille actuellement pour sa filiale VMware — Heptio (acquise en 2016), spécialisée dans le cloud computing et Kubernetes. Le texte sert d'introduction concise et facile à comprendre à la gestion des configurations pour Kubernetes à l'aide de la technologie Kustomize, récemment intégrée à K8s.

Kustomize est un outil qui permet aux utilisateurs « d'adapter des fichiers YAML simples et sans modèles à diverses fins, tout en laissant le YAML original intouché et réutilisable » (description tirée directement de référentiel kustomize sur GitHub). Kustomize peut être exécuté directement ou, à partir de Kubernetes 1.14, utilisé kubectl -k pour accéder à ses fonctionnalités (bien qu'à l'état actuel de Kubernetes 1.15, un binaire distinct soit plus récent que les fonctionnalités intégrées à kubectl). (Note de traduction.: Avec la récente publication Kubernetes 1.16 kustomize est pris en charge , il est également intégré dans l'outil kubeadm.) Dans cette publication, je souhaite familiariser les lecteurs avec les bases de kustomize.

Dans sa forme/application la plus simple, kustomize est simplement un ensemble de ressources (fichiers YAML définissant des objets Kubernetes : Deployments, Services, etc.) plus une liste d'instructions sur les modifications à apporter à ces ressources. De la même manière que make utilise un ensemble d'instructions contenues dans Makefile, et Docker construit un conteneur basé sur les instructions de Dockerfile, kustomize utilise kustomization.yaml pour stocker les directives sur les modifications que l'utilisateur souhaite apporter à l'ensemble de ressources.

Voici un exemple de fichier kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Je ne vais pas essayer de parler de tous les champs possibles dans le fichier kustomization.yaml (c'est bien expliqué ici), mais je donnerai une brève explication d'un exemple spécifique :

• Champ resources indique quels (ressources) seront modifiés par kustomize. Dans ce cas, il recherchera les ressources dans les fichiers deployment.yaml et service.yaml dans son répertoire (il est possible d'indiquer des chemins absolus ou relatifs).
• Champ namePrefix indique à kustomize d'ajouter un préfixe spécifique (dans ce cas — dev-) à l'attribut nom de toutes les ressources définies dans le champ resources. Ainsi, si dans le Deployment il y a nom avec la valeur nginx-deployment, kustomize le transformera en dev-nginx-deployment.
• Champ namespace indique à kustomize d'ajouter un espace de noms donné à toutes les ressources. Dans ce cas, Deployment et Service seront placés dans l'espace de noms développement.
• 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 le nom environment et la valeur développement.

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

Note de traduction.: Illustration de la documentation du projet sur l'utilisation "simple" de kustomize

La sortie peut être redirigée, si nécessaire pour enregistrer les modifications :

kustomize build . > custom-config.yaml

Les résultats sont déterministes (avec les mêmes données en entrée, les mêmes résultats seront obtenus en sortie), il n'est donc pas nécessaire de sauvegarder le résultat dans un fichier. Au lieu de cela, il peut être immédiatement passé à une autre commande :

kustomize build . | kubectl apply -f -

L'accès aux fonctionnalités de kustomize peut également être obtenu via kubectl -k (à partir de la version 1.14 de Kubernetes). Cependant, gardez à l'esprit qu'un package kustomize autonome se met à jour plus rapidement que celui intégré dans kubectl (en tout cas, c'est ce qui se passe avec la version 1.15 de Kubernetes).

Les lecteurs pourraient se demander : "Pourquoi toutes ces complexités, si l'on peut éditer les fichiers directement ?" Excellente question. Dans notre exemple, il est effectivement est possible possible de modifier les fichiers deployment.yaml et service.yaml directement, mais que faire s'ils sont un fork d'un projet ? Modifier les fichiers directement complique (si ce n'est pas impossible) le rebase du fork lorsque des modifications sont apportées à la source. L'utilisation de kustomize permet de centraliser ces modifications dans un fichier kustomization.yaml, laissant les fichiers originaux intacts et facilitant ainsi, si nécessaire, le rebase des fichiers sources.

Les avantages de kustomize deviennent évidents dans des cas d'utilisation plus complexes. Dans l'exemple ci-dessus, kustomization.yaml les ressources se trouvent dans le même répertoire. Cependant, kustomize supporte des scénarios d'utilisation où il existe une configuration de base et de nombreuses variantes de celle-ci, également connues sous le nom de la nouvelle commande. Par exemple, l'utilisateur a souhaité prendre le Deployment et le Service pour nginx, que j'ai utilisés comme exemple, et créer des versions (ou variantes) de développement, de staging et de production de ces fichiers. Pour cela, il lui faudra les overlays mentionnés ci-dessus et les ressources de base.

Pour illustrer l'idée des overlays et des ressources de base (base resources), 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 fichier base/kustomization.yaml les utilisateurs utilisent le champ resources déclarent simplement les ressources que doit inclure kustomize.

Dans chacun des fichiers overlays/{dev,staging,prod}/kustomization.yaml les utilisateurs font référence à la configuration de base dans le champ resources, puis spécifient les modifications concrètes pour cet environnement. Par exemple, le fichier overlays/dev/kustomization.yaml pourrait ressembler à l'exemple donné précédemment :

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

Le fichier overlays/prod/kustomization.yaml pourrait être complètement différent :

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

Lorsque l'utilisateur exécutera kustomize build . dans le répertoire overlays/dev, kustomize générera une variante development. Si toutefois on exécute kustomize build . dans le répertoire overlays/prod — cela produira une variante production. Et tout cela — sans apporter de modifications aux fichiers (base) et tout cela — de manière déclarative et déterministe. La configuration de base et les répertoires d'overlays peuvent être directement engagés dans le système de contrôle de version, sachant qu'à partir de ces fichiers, on peut reproduire la configuration souhaitée à tout moment.

Note de traduction.: Illustration de la documentation du projet sur l'utilisation des overlays dans kustomize

Kustomize sait beaucoup faire plus que ce qui est expliqué dans cet article. Néanmoins, j'espère qu'il servira de bonne introduction.

Ressources supplémentaires

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

• Changez la configuration YAML de base pour différents environnements prod/test en utilisant Kustomize;
• Kustomize — La bonne manière de faire du templating dans Kubernetes;
• Gestion déclarative des objets Kubernetes en utilisant Kustomize;
• Personnaliser les charts Helm en amont avec Kustomize.

Note de traduction.: Un bloc de liens publié comme recommandé sur le site de l'outil, suivi d'une collection de vidéos des dernières présentations sur kustomize. Ressources Si vous avez des questions ou des suggestions pour améliorer ce matériel, je suis toujours ouvert aux retours. Vous pouvez me contacter sur le

canal Slack Kubernetes Twitter ou sur . Amusez-vous à modifier vos manifests avec kustomize !Cinq principaux enseignements du Helm Summit 2019 à Amsterdam

P.S. de l'auteur

Lisez aussi dans notre blog :

• «Outils pour les développeurs d'applications exécutées dans Kubernetes»;
• «Kubernetes 1.13 : aperçu des principales nouveautés»;
• «Note du traducteur : Cet article a été écrit par Scott Lowe — un ingénieur avec une vaste expérience dans l'IT, auteur/co-auteur de sept livres publiés (principalement sur VMware vSphere).»;
• «Une introduction pratique au gestionnaire de paquets pour Kubernetes — Helm».

Source : habr.com