Les outils de base

Tout d’abord, voici les principaux outils que nous allons utiliser :

• kubectl
• helm (secrets/diff)
• sops
• helmfile
• git

Pour versionner facilement vos configurations et pouvoir suivre nos déploiements, nous utilisons helmfile qui permet, comme docker compose, de déclarer des environnements. C’est bien plus simple que de réécrire entièrement toutes les commandes helm (en re-spécifiant le namespace, le fichier values etc…) !

Architecture

Avec kubernetes, lorsqu’on démarre avec un cluster « vide », il n’y a de base que les pods servant à faire tourner les nœuds, tout ça dans les namespaces kube-*.

Afin de bien organiser nos ressources, nous utiliserons plusieurs namespaces comme reverse-proxy, monitoring, logging… Ce qui nous permettra d’accorder aisément des droits plus fins aux utilisateurs connectés au cluster.

Il faut donc commencer par découper nos configurations en plusieurs repositories git :

• Kubernetes Common :
  Permet l’instanciation d’éléments devant être unique au cluster entier. On peut y retrouver notamment le kubernetes dashboard, le reverse-proxy, monitoring ou autres…
• Kubernetes votre-site deployments :
  Contient de quoi déployer les différents environnements de votre site. Si vous voulez livrer une nouvelle version de votre site, c’est via un commit dans ce repository que ça se passera.
• Helm Chart frontend :
  Celui-ci définira tous les composants nécessaires pour déployer votre site. Cela peut être les deployments, les services, les secrets…
• Helm Chart xxx :
  Toutes vos autres chart personnalisées comme une api ou autre…

À quoi ça ressemble ?

Kubernetes common

On commence par un fichier helmfile.yaml qui contiendra la liste de nos releases helm. ex :

releases:
  - name: traefik
    chart: traefik/traefik
    version: x.x.x
    namespace: reverse-proxy
    secrets:
      - ./traefik.values.encrypted.yml

  - name: cert-manager
    chart: jetstack/cert-manager
    version: x.x.x
    namespace: reverse-proxy
    values:
      - ./cert-manager.values.yml

cert-manager.yaml

crds:
  enabled: true
  keep: true

En configurant nos values pour les différents outils, il ne reste plus qu’à exécuter la commande helmfile apply.

Il est parfois nécessaire d’inclure des données sensibles dans les fichiers values, comme une clé privée par exemple. On peut donc passer par le chiffrement de ces fichiers à l’aide sops et de helm secrets, ce qui permettra à helm de bien déchiffrer ces fichiers avant de les appliquer.

Kubernetes votre-site deployments

Ce fichier sera différent du common, car il aura une dimension de plus : l’environnement.

helmfile.yaml

environments:
  preprod: {}
  prod: {}

repositories:
  - name: ma-stack
    url: https://url-du-repo

releases:
  - name: frontend
    chart: ma-stack/frontend
    version: 1.0.0
    namespace: "{{ .Environment.Name }}"
    secrets:
      - ./{{ .Environment.Name }}/frontend.values.encrypted.yaml

  - name: api
    chart: ma-stack/api
    version: 1.0.0
    namespace: prod
    secrets:
      - ./prod/api.values.encrypted.yaml

  - name: api
    chart: ma-stack/api
    version: 2.0.0
    namespace: preprod
    secrets:
      - ./preprod/api.values.encrypted.yaml

Apporter la notion d’environnement à ce helmfile permet de déployer une version spécifique par environnement.

Dans cet exemple, la version 1.0.0 de la chart du frontend est déployée deux fois : une fois sur l’environnement de prod et l’autre sur l’environnement de preprod. La différence peut se jouer sur le fichier values qui contiendra des paramétrages différents en fonction de l’environnement cible.
Par exemple dans les fichiers values, on spécifie généralement le tag de l’image docker déployée, ce qui, dans ce cas, permet de déployer deux versions différentes du site sur chaque environnement.

Concernant l’api, celle-ci a une nouvelle version de la chart en preprod. Cela permet d’ajouter un nouvel élément kubernetes comme un nouveau service ou autre… D’où l’intérêt d’extraire la chart de votre front/api dans un autre repository.

Après tout ça, nous pouvons appliquer cette configuration avec helmfile apply et ça nous livre toutes les modifications nécessaires sur tous les environnements !

Ensuite ?

Avec cette répartition entre différents projets, il ne reste plus qu’à implémenter la CD.
Le déploiement de configurations pourra donc être automatique et nos repositories seront la source de vérité de l’état de votre cluster.
Dans votre chaine d’intégration, mettre à jour un applicatif consistera à faire un commit sur ces repositories.