Déployer votre première application avec un GitRepository et une Kustomization
Pointez Flux vers des manifestes dans Git à l'aide d'une ressource Kustomization et regardez la synchronisation se faire.
Flux se configure avec des ressources Kubernetes comme tout le reste du cluster. Deux d’entre elles font l’essentiel du travail : une source comme un GitRepository dit où vit la configuration, et une Kustomization dit « prends les manifestes à ce chemin dans cette source et garde-les appliqués à ce cluster ». Ce guide déploie une petite application, puis modifie Git pour voir la synchronisation se produire. Il suppose que Flux est bootstrappé sur un dépôt fleet-infra (voir le guide précédent).
Préparer les manifestes
Dans votre clone de fleet-infra, ajoutez un dossier d’application à côté du dossier clusters créé par le bootstrap :
fleet-infra/
├── clusters/
│ └── dev/
│ ├── flux-system/ # créé par le bootstrap
│ └── webapp.yaml # la Kustomization Flux (section suivante)
└── apps/
└── webapp/
├── namespace.yaml
├── deployment.yaml
└── service.yaml
apps/webapp/namespace.yaml :
apiVersion: v1
kind: Namespace
metadata:
name: webapp
apps/webapp/deployment.yaml :
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
namespace: webapp
spec:
replicas: 2
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: nginx:1.25
ports:
- containerPort: 80
apps/webapp/service.yaml :
apiVersion: v1
kind: Service
metadata:
name: webapp
namespace: webapp
spec:
selector:
app: webapp
ports:
- port: 80
targetPort: 80
Contrairement à certains outils, les manifestes ici nomment explicitement leur namespace, et le dossier inclut l’objet Namespace pour que Flux le crée. Aucun kustomization.yaml n’est nécessaire : quand un dossier n’en contient pas, Flux construit une liste de tous les fichiers YAML qu’il contient.
Écrire la Kustomization Flux
Le bootstrap a déjà créé un GitRepository nommé flux-system qui pointe vers ce même dépôt, vous pouvez donc le réutiliser. clusters/dev/webapp.yaml :
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: webapp
namespace: flux-system
spec:
interval: 10m
sourceRef:
kind: GitRepository
name: flux-system
path: ./apps/webapp
prune: true
wait: true
timeout: 2m
Les éléments qui comptent :
sourceRefest l’origine de l’état désiré. Ici, c’est le dépôtflux-systemconfiguré par le bootstrap.pathest le dossier de la source à appliquer.intervalest la fréquence à laquelle Flux réapplique les manifestes et corrige la dérive, même quand Git n’a pas changé.prune: truesignifie que les objets retirés de Git sont aussi retirés du cluster. C’est désactivé sauf si vous l’activez.waitettimeoutfont attendre à Flux que les ressources appliquées soient prêtes avant de signaler un succès.
Vous pouvez générer ce YAML avec la CLI plutôt que de l’écrire à la main :
flux create kustomization webapp \
--source=GitRepository/flux-system \
--path=./apps/webapp \
--prune=true --wait=true --timeout=2m --interval=10m \
--export > clusters/dev/webapp.yaml
Committer et laisser Flux le prendre en compte
git add -A
git commit -m "Add webapp"
git push
La Kustomization flux-system surveille déjà ./clusters/dev, elle découvre donc la nouvelle Kustomization webapp à sa prochaine exécution. Vous n’exécutez jamais kubectl apply pour l’application. Pour éviter d’attendre, demandez à Flux de vérifier Git tout de suite :
flux reconcile source git flux-system
flux get kustomizations --watch
Confirmer le déploiement
La Kustomization webapp apparaît et passe à Ready avec un message nommant la révision appliquée. Vérifiez le cluster, et demandez à Flux d’afficher ce qu’il possède :
kubectl get all -n webapp
flux tree kustomization webapp
Modifier Git et regarder la synchronisation
Modifiez apps/webapp/deployment.yaml, changez l’image en nginx:1.26, puis committez et poussez. Flux récupère les dépôts selon l’intervalle du GitRepository (une minute par défaut après le bootstrap), puis applique le changement. Un nouveau ReplicaSet est déployé. Vérifiez :
flux reconcile kustomization webapp --with-source
kubectl get deploy webapp -n webapp \
-o jsonpath='{.spec.template.spec.containers[0].image}'; echo
Voilà toute la boucle : on modifie Git, Flux fait converger le cluster. Le guide suivant explique comment contrôler ce comportement.
Utiliser un autre dépôt
Vous n’êtes pas obligé de garder les manifestes d’application dans le dépôt de bootstrap. Pour déployer depuis un autre, créez un GitRepository pour lui et référencez-le depuis la Kustomization :
flux create source git webapp-config \
--url=https://github.com/your-org/webapp-config \
--branch=main --interval=1m \
--export > clusters/dev/webapp-source.yaml
Pour un dépôt privé, ajoutez des identifiants avec flux create secret git et référencez-les avec --secret-ref, ou utilisez une deploy key SSH. Définissez ensuite sourceRef.name: webapp-config dans la Kustomization.
Guides populaires
-
Push ou pull : comment Flux livre sur Kubernetes Pourquoi une livraison pilotée par Git et basée sur le pull change la façon de déployer, de sécuriser et de restaurer les clusters. -
Contrôler le comportement de synchronisation : intervalles, prune, correction de dérive et rollback Décidez quand Flux applique les changements, ce qu'il supprime, comment le mettre en pause et comment annuler un mauvais déploiement. -
Automatiser les mises à jour d'images avec Flux Image Automation Laissez Flux détecter les nouveaux tags d'images de conteneurs et les committer dans Git. -
Configurer le multi-cluster avec Flux Gérez plusieurs clusters depuis un seul dépôt, avec une infrastructure partagée et des différences propres à chaque cluster. -
Flux CD ou Argo CD : choisir un outil GitOps Comparez l'architecture, l'interface, Helm, les secrets, la multi-tenance et l'automatisation d'images pour choisir le bon outil.