01. September 2023

Enoncé TP 12

/images/k8s.jpeg

TP12 : Helm factorisation

🇫🇷 Version Française

Factorisation

Helm propose un systéme de “sub-chart” afin de mieux ranger nos fichiers Yaml présents dans le dossier template. on va avoir un chart principal qui va rassembler plusieurs autres charts.

L’architecture du chart helm classique va se transformer pour utiliser plus de fonctionnalité de helm:

helm/
  Chart.yaml
  values.yaml
  requirements.yaml
  (.helmignore)
  (OWNERS)
  charts/
     configuration-chart/
        Chart.yaml
        templates/
           (_helpers.tpl)
           (NOTE.txt)
           someYamlFile.yaml
           someOtherYamlFile.yaml
     frontend-chart/
        Chart.yaml
        templates/
           (_helpers.tpl)
           (NOTE.txt)
           someYamlFile.yaml
           someOtherYamlFile.yaml
     backend-chart/
        Chart.yaml
        templates/
           (_helpers.tpl)
           (NOTE.txt)
           someYamlFile.yaml
           someOtherYamlFile.yaml

Dans cet exemple on va avoir un sub-chart chargé de la configuration (namespace, configmap, secret, ingress, …), un sub-chart pour l’applicatif backend (deployment & service) et un autre pour l’applicatif frontend (deployment & service).

l’utilisation et la variabilisation des ces sub-charts vont passer par le nouveau fichier requirements.yaml & le fichier values.yaml.

Le fichiers requirements.yaml va indiquer quels sub-chart il va devoir installer, et quels blocs de configuration il va devoir utiliser dans le values.yaml

Exemple:

requirements.yaml:

- name: frontend-chart
  version: 0.1.0
  alias: frontend

values.yaml:

frontend:
  image: my-image-frontend
  tag: "1.0"
  replicas: 2

le champ alias du requirements.yaml et la premiére clé du bloc du fichier values.yaml doivent être les mêmes pour qu’ils se retrouvent.

les champs name & version du requirements.yaml doivent correspondrent à ces mêmes champs dans le Chart.yaml du sub-chart correspondant pour qu’il sache quel sub-chart il doit utiliser.

On peut ajouter des variables communes à tous les sub-chart via le bloc définie en dessous du values.yaml:

global:
   myCommonKey1: myCommonValue1
   myCommonKey2: myCommonValue2

On va transformer le chart helm réalisé dans le TP11 en un chart un peu plus complexe comme celui expliqué au dessus.

Ce découpage est une simple proposition, si d’autres découpages semblent plus pertinent, libre à vous d’éxpérimenter et de nous faire un retour sur votre vision d’un possible autre découpage.

Dans le cadre de l’application déployé dans cette formation, le passage à un systéme de sub-chart n’est pas obligatoire et n’apporte pas beaucoup de plus-value. Mais dans le cas où l’application évoluerai avec d’autres backend nodeJS par exemple, on pourrait arriver à déployer plusieurs deployment backend en utilisant un seul sub-chart bien paramétré.

En général les micro services d’une même application ont toujours la même configuration de ressource kubernetes, les seules choses qui changent sont souvent les images utilisées et le nom de l’application. C’est pourquoi il peut être interressant de factoriser la définition des ressources, et de simplement avoir à ajouter une entré dans les fichiers requirements.yaml & values.yaml.

Pistes d’améliorations

  • Tester les commandes helm install/delete/upgrade/history/rollback et leurs différentes options.
  • Rendre plus paramétrables la gestion des request/limits
  • Rendre plus paramétrables la gestion des podPriorityClass
  • Utilisation du _helpers.tpl pour modifier / attribuer des valeurs selon certaines conditions (environnement par exemple).
  • Création d’un chart package pour déployé via helm depuis une archive.
🇬🇧 English version

Factorization

Helm offers a “sub-chart” system to better organize our Yaml files present in the template folder. we will have a main chart which will bring together several other charts.

The classic helm chart architecture will be transformed to use more helm functionality:

helm/
  Chart.yaml
  values.yaml
  requirements.yaml
  (.helmignore)
  (OWNERS)
  charts/
     configuration-chart/
        Chart.yaml
        templates/
           (_helpers.tpl)
           (NOTE.txt)
           someYamlFile.yaml
           someOtherYamlFile.yaml
     frontend-chart/
        Chart.yaml
        templates/
           (_helpers.tpl)
           (NOTE.txt)
           someYamlFile.yaml
           someOtherYamlFile.yaml
     backend-chart/
        Chart.yaml
        templates/
           (_helpers.tpl)
           (NOTE.txt)
           someYamlFile.yaml
           someOtherYamlFile.yaml

In this example we will have a sub-chart responsible for the configuration (namespace, configmap, secret, ingress, …), a sub-chart for the backend application (deployment & service) and another for the application frontend (deployment & service).

the use and variation of these sub-charts will go through the new requirements.yaml file & the values.yaml file.

The requirements.yaml file will indicate which sub-charts it will have to install, and which configuration blocks it will have to use in the values.yaml

Example:

requirements.yaml:

- name: frontend-chart
  version: 0.1.0
  alias: frontend

values.yaml:

frontend:
  image: my-image-frontend
  tag: "1.0"
  replicas: 2

the alias field of requirements.yaml and the first block key of the values.yaml file must be the same for them to match.

the name & version fields of the requirements.yaml must correspond to these same fields in the Chart.yaml of the corresponding sub-chart so that it knows which sub-chart it must use.

You can add variables common to all sub-charts via the block defined below values.yaml:

global:
   myCommonKey1: myCommonValue1
   myCommonKey2: myCommonValue2

We are going to transform the helm chart created in TP11 into a slightly more complex chart like the one explained above.

This division is a simple proposal, if other divisions seem more relevant, you are free to experiment and give us feedback on your vision of a possible other division.

As part of the application deployed in this training, switching to a sub-chart system is not obligatory and does not bring much added value. But in the case where the application evolves with other nodeJS backends for example, we could manage to deploy several backend deployments using a single well-configured sub-chart.

In general, micro services of the same application always have the same Kubernetes resource configuration, the only things that change are often the images used and the name of the application. This is why it can be annoying to refactor the resource definition, and simply have to add an entry in the requirements.yaml & values.yaml files.

Areas for improvement

  • Test the helm install/delete/upgrade/history/rollback commands and their different options.
  • Make request/limits management more configurable
  • Make podPriorityClass management more configurable
  • Use of _helpers.tpl to modify / assign values according to certain conditions (environment for example).
  • Creation of a chart package to be deployed via helm from an archive.
Latest Posts