Introduction

FluxCD est un outil permettant de garder synchronisé un cluster Kubernetes avec la description de sa configuration (par exemple contenue dans un dépôt Git).

Cela suit donc les principes GitOps .

Compréhension

Avant tout, FluxCD fonctionne sur Kubernetes : il apporte des CRD (Custom Resource Definition) à Kubernetes.

C’est ce qui permet de déclarer des ressources via les manifestes Kubernetes habituels (des fichiers .yaml).

Sources possibles

Flux va pouvoir surveiller au regard des sources suivantes :

des dépôts Git,
des buckets,
et des dépôts Helm.

Grâce à ce système, on peut déclarer un dépôt Git à surveiller.

Flux a besoin :

d’avoir accès au dépôt Git,
d’avoir les credentials suffisants pour le lire,
et de savoir dans quel dossier surveiller les changements éventuels.

Depuis où les ressources ?

Pour pouvoir fonctionner, FluxCD proppose :

soit un outil en ligne de commande pour discuter avec le serveur Kubernetes et configurer le(s) agent(s) Flux directement,
soit de s’utiliser soi-même, c’est à dire surveiller un dépôt Git qui contient la déclaration des configurations souhaitées. C’est ce qu’on appelle le bootstrap. Cela utilise tout de même FluxCD en ligne de commande.

Fonctionnement du bootstrap

L’idée est d’initialiser un dépôt Git qui sera pris comme référence par un cluster Kubernetes pour déployer des services.

Il existe des tutoriels du Bootstrap FluxCD pour différents types de dépôt Git .

Par exemple pour Gitlab, cela donnerait :

# Vérification d'accès au Cluster Kubernetes
kubectl get nodes
# Notre clé d'accès personnelle Gitlab (PAT)
export GITLAB_TOKEN=<gl-token>
# Lien entre le dépôt Gitlab et notre cluster
flux bootstrap gitlab \
  --deploy-token-auth \
  --owner=my-gitlab-username \
  --repository=my-project \
  --branch=master \
  --path=clusters/my-cluster \
  --personal

my-gitlab-username peut tout à fait être le nom d’un groupe Gitlab,
my-project est donc le nom du dépôt Git dans ce groupe ou chez cet utilisateur,
et path décrit le dossier dans lequel récupérer les informations nécessaires.

Ainsi, dans l’exemple donné, FluxCD va regarder dans le dossier clusters/my-cluster* pour s’autoconfigurer.

La documentation officielle concernant l'installation utilise un schéma comme celui-ci :

Schéma d’installation de FluxCD entre un cluster Kubernetes et un dépôt Git

Astuce(s)

Trouver les détails sur le cluster

Dans le cluster Kubernetes, une fois FluxCD installé via le bootstrap, nous avons plusieurs ressources utiles pour cela :

une ressource gitrepositories,
et une ressource kustomizations.

Il y en a d’autres mais ce sont celles-ci qui nous intéressent.

Si vous avez suivi le tutoriel sur le site officiel, tout ceci est dans un namespace flux-system. Ainsi on peut avoir les détails sur les différentes ressources :

# Affiche les ressources habituelles (pod, service, deployment et replicaset) contenues dans le namespace flux-system
kubectl -n flux-system get all
# Affiche la liste des dépôts Git suivis
kubectl -n flux-system get gitrepositories
# Exemple : Affiche les détails du dépôt Git nommé flux-system
kubectl -n flux-system describe gitrepositories.source.toolkit.fluxcd.io flux-system
# Affiche la liste des kustomizations
kubectl -n flux-system get kustomizations
# Exemple : Affiche les détails de la kustomization nommée flux-system
kubectl -n flux-system describe kustomizations.kustomize.toolkit.fluxcd.io flux-system

Dans les deux derniers exemples, on va retrouver les infos principales :

# URL utilisée par FluxCD pour le dépôt Git
kubectl -n flux-system describe gitrepositories.source.toolkit.fluxcd.io flux-system |grep URL
# Chemin dans le dépôt Git utilisé par FluxCD
kubectl -n flux-system describe kustomizations.kustomize.toolkit.fluxcd.io flux-system |grep path -i

Dans mon exemple, j’aurais :

URL:      https://gitlab.com/odtre/gitops_zou.git

pour l’URL. Et :

Path:      ./clusters/zou

pour le chemin dans lequel FluxCD « écoute » les manifestes kubernetes.

Exemples

Déployer un Gitlab Runner

En bref

Dans un fichier gitlab-runner.yaml par exemple, situé dans le dossier ./clusters/zou précédent :

---
apiVersion: v1
kind: Namespace
metadata:
  name: testing
  labels:
    toolkit.fluxcd.io/tenant: dev-team
---
# Dépôt HELM de Gitlab
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: gitlab
  namespace: testing
spec:
  interval: 5m
  url: https://charts.gitlab.io
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: gitlab-runner
  namespace: testing
spec:
  releaseName: gitlab-runner
  chart:
    spec:
      chart: gitlab-runner
      sourceRef:
        kind: HelmRepository
        name: gitlab
        namespace: testing
      version: ">=0.73.3 <0.74.0" # Plage de versions pour éviter des désagréments
  interval: 50m
  values:
    gitlabUrl: https://gitlab.com
    rbac:
      create: true
    serviceAccount:
      create: true
    metrics:
      enabled: false
      serviceMonitor:
        enabled: false
    runnerToken: "glrt-tuvwabcdefghijklmnopqrs"
runners:
      name: "zou-runner"

Explications

Le premier paragraphe décrit le namespace dans lequel on souhaite travailler, testing. Mais aussi un “label” pour définir des équipes. Ce n’est pas obligatoire, mais nous avons utilisé la valeur dev-team.

---
apiVersion: v1
kind: Namespace
metadata:
  name: testing
  labels:
    toolkit.fluxcd.io/tenant: dev-team

Le second paragraphe va décrire le dépôt de Charts à utiliser, en l’occurence https://charts.gitlab.io.

On utilise le même namespace qu’avant, testing. Et on donne un nom, gitlab au HelmRepository.

---
# Dépôt HELM de Gitlab
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: gitlab
  namespace: testing
spec:
  interval: 5m
  url: https://charts.gitlab.io

Ce qui va donner le dernier paragraphe pour indiquer quelle(s) version(s) installer pour le chart visé.

On renseigne :

le namespace (testing),
le nom du chart (chart: gitlab-runner),
en utilisant le HelmRepository dont le nom (name) est gitlab,
une plage de versions située entre 0.73.3 et 0.74.0 (chaque fois que le chart évolue, il mettra automatiquement Gitlab Runner à jour),
et en donnant des valeurs spécifiques pour configurer le chart, dans la section values.

En effet, values va reprendre le contenu du fichier values.yaml dans le Chart Helm officiel de Gitlab . Par exemple ici on reprend :

rbac,
gitlabUrl (l’adresse de votre dépôt Gitlab, ici on garde le Gitlab officiel),
serviceAccount,
metrics (pour les désactiver),
et le plus important, runnerToken. Il faut copier la valeur donnée par Gitlab pour la création d'un Runner .

On lui a aussi donné un petit nom : zou-runner (tout en bas).

---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: gitlab-runner
  namespace: testing
spec:
  releaseName: gitlab-runner
  chart:
    spec:
      chart: gitlab-runner
      sourceRef:
        kind: HelmRepository
        name: gitlab
        namespace: testing
      version: ">=0.73.3 <0.74.0" # Plage de versions pour éviter des désagréments
  interval: 50m
  values:
    gitlabUrl: https://gitlab.com
    rbac:
      create: true
    serviceAccount:
      create: true
    metrics:
      enabled: false
      serviceMonitor:
        enabled: false
    runnerToken: "glrt-tuvwabcdefghijklmnopqrs"
runners:
      name: "zou-runner"