From af63cf1405cd78b39dbc7a97c4929e7c72d574d6 Mon Sep 17 00:00:00 2001 From: Ludovic Piot Date: Wed, 14 May 2025 21:25:59 +0200 Subject: [PATCH] =?UTF-8?q?=F0=9F=9A=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- slides/k8s/a-company-scenario.md | 81 +++++++++++++++++--------------- 1 file changed, 43 insertions(+), 38 deletions(-) diff --git a/slides/k8s/a-company-scenario.md b/slides/k8s/a-company-scenario.md index 89a77311..8d89991b 100644 --- a/slides/k8s/a-company-scenario.md +++ b/slides/k8s/a-company-scenario.md @@ -247,13 +247,14 @@ To do so, the _**🎸ROCKY**_ team requires --- -# incoming Flux +# Incoming Flux 💡 We'll use `Flux` so that deployments will be directly executed from inside the Kubernetes clusters. --- - -The _**⚙️OPS**_ team will proceed to configure GitOps for the _**🎸ROCKY**_ team. +- The _**⚙️OPS**_ team will proceed to configure GitOps + - to configure the Kubernetes clusters + - for the _**🎸ROCKY**_ team, `Flux` will check the app source code Github repository and deploy every time the right git event is triggered + - for the _**🎻CLASSY**_ team, `Flux` will check every time a new Helm Chart release is published in the Helm Charts repository storing the app --- @@ -265,13 +266,13 @@ What the _**⚙️OPS**_ team has to do: - 🔧 Creating the `flux` Github source pointing to the _**rocky**_ app source code repository - 🔧 Adding a `kustomize` patch into the global `flux` config to include the `flux` configuration for the _**rocky**_ app -What the _**🎸rocky**_ team has to do: +What the _**🎸ROCKY**_ team has to do: -- 👨‍💻 Creating the kustomize file in the _**rocky**_ app source code repository +- 👨‍💻 Creating the `kustomize` file in the _**🎸ROCKY**_ app source code repository in Github. --- -## creating the dedicated `rocky` tenant +## Creating the dedicated `rocky` tenant - Using the `flux` _CLI_, we create the file configuring the tenant for the _**🎸ROCKY**_ team - This is done in the global mutualized `base` configuration for both Kubernetes clusters @@ -317,13 +318,13 @@ We want to configure our _**⚗️TEST**_ cluster in a *-as-code and reusable wa ### Flux CLI -* une CLI permet : +- une CLI permet : 1. de créer les fichiers `YAML` pour déployer les ressources `Kubernetes` que l'on souhaite - * y compris les propres composants `Flux` + - y compris les propres composants `Flux` 1. d'interagir avec le dépôt `git` qui va servir de configuration `Flux` 1. d'interroger l'état de Flux sur le _cluster_ - * logs des _operators_ - * _CRD_ + - logs des _operators_ + - _CRD_ --- @@ -335,9 +336,9 @@ We want to configure our _**⚗️TEST**_ cluster in a *-as-code and reusable wa ### Flux components -* `source controller` pour scruter les sources de configuration depuis des dépôts `git` -* `helm controller` pour détecter de nouvelles _releases_ depuis des dépôts de _charts_ `Helm` -* des _CRD_, qui servent de machine à état pour stocker la configuration dans le _cluster_ +- `source controller` pour scruter les sources de configuration depuis des dépôts `git` +- `helm controller` pour détecter de nouvelles _releases_ depuis des dépôts de _charts_ `Helm` +- des _CRD_, qui servent de machine à état pour stocker la configuration dans le _cluster_ --- @@ -349,7 +350,7 @@ Reference to the `Flux` chapter in High Five M3 module ### Flux relies on Kustomize -* `kustomize controller` qui passe la configuration trouvée à `Kustomize` +- `kustomize controller` qui passe la configuration trouvée à `Kustomize` 1. `Kustomize` consolide la configuration trouvée 2. et hydrate les sections template présentes dans la configuration @@ -363,27 +364,26 @@ Reference to the `Kustomize` chapter in High Five M3 module ## T02- _**⚗️TEST**_ cluster - Installing Flux -* À partir de là, toute la configuration du _cluster_ Kubernetes peut se faire exclusivement en manipulant des dépôts `git`. -* On est dans le respect du _pattern_ roi dans `Kubernetes` : **la convergence vers un état cible décrit** +À partir de là, toute la configuration du _cluster_ Kubernetes peut se faire exclusivement en manipulant des dépôts `git`. + +On est dans le respect du _pattern_ roi dans `Kubernetes` : **la convergence vers un état cible décrit** --- - - -### Flux CLI +### Flux CLI 1 1. L'équipe **ops** récupère la _CLI_ `Flux` sur son poste de travail 1. La _CLI_ va s'appuyer sur la configuration `kubectl` pour interagir avec le _cluster_ - * connectivité réseau - * droits _RBAC_ + - connectivité réseau + - droits _RBAC_ ---- ### Flux install - Checking prerequisites 1. On s'assure que - * la CLI se connecte bien - * que les versions de `Flux` et de `Kubernetes` sont OK + - la CLI se connecte bien + - que les versions de `Flux` et de `Kubernetes` sont OK ```bash $ flux check ---pre @@ -396,8 +396,8 @@ $ flux check ---pre ### Git repo to host Flux configuration -* La CLI va créer un dépôt `fleet-infra` dans notre organisation `Github` : `one-kubernetes` -* Elle a besoin d'un _token_ `Github` capable de _CRUD_ sur les dépôts. +- La CLI va créer un dépôt `fleet-infra` dans notre organisation `Github` : `one-kubernetes` +- Elle a besoin d'un _token_ `Github` capable de _CRUD_ sur les dépôts. ---- @@ -418,12 +418,13 @@ $ flux check ---pre ### Disclaimer -* ⚠️ Ici on vous montre pour l'exemple, mais dans le reste du _workshop_ (comme dans la vraie vie) les différentes équipes n'ont pas besoin d'accéder à ce dépôt. -* C'est tout l'avantage des sources de configuration multiples. +- ⚠️ Ici on vous montre pour l'exemple, mais dans le reste du _workshop_ (comme dans la vraie vie) les différentes équipes n'ont pas besoin d'accéder à ce dépôt. + +- C'est tout l'avantage des sources de configuration multiples. ---- -### T03- Creating dedicated `Github` repo to host Flux config. +### T03- Creating dedicated `Github` repo to host Flux config ```bash [1-3|5-10] $ export GITHUB_TOKEN="" @@ -530,18 +531,18 @@ resources: ### Cloning the git repo locally ```bash -$ git clone https://github.com/${GITHUB_USER}/${GITHUB_REPO} +git clone https://github.com/${GITHUB_USER}/${GITHUB_REPO} ``` --- ## _**⚗️TEST**_ cluster - creating the Flux config -* **ops** va avoir à gérer 2 clusters : `staging` et `prod` -* Grace à _Kustomize_, elle va +- **ops** va avoir à gérer 2 clusters : `staging` et `prod` +- Grace à _Kustomize_, elle va 1. créer une config. de base 2. qui sera surchargée par une config. spécifique au _tenant_ -* 💡Ça paraît compliqué, mais pas d'inquiétude : la _CLI_ `Flux` s'occupe de l'essentiel +- 💡Ça paraît compliqué, mais pas d'inquiétude : la _CLI_ `Flux` s'occupe de l'essentiel ---- @@ -747,11 +748,11 @@ Après git commit && git push, on obtient cette arborescence. -* `Flux` scrute le dépôt de _**🎸ROCKY**_, mais il s'attend à y trouver un fichier `kustomization.yaml` -* dev1 doit donc y créer ce fichier +- `Flux` scrute le dépôt de _**🎸ROCKY**_, mais il s'attend à y trouver un fichier `kustomization.yaml` +- dev1 doit donc y créer ce fichier ```bash -$ kustomize create --autodetect +kustomize create --autodetect ``` ---- @@ -799,8 +800,10 @@ EOF ## ⚠️ Limitations - Pour chaque nouveau dépôt applicatif, **ops** doit ajouter une source `Flux` + - _**🎸ROCKY**_ est celui qui produit le `deployment.yaml` - * et donc, **ops** a peu de latitude pour configurer des comportements différents entre `staging` et `prod` + - et donc, **ops** a peu de latitude pour configurer des comportements différents entre `staging` et `prod` + - ça veut dire aussi que **rocky** team est seule à décider de son architecture technique (service, base de données, etc.) ce qui peut être utile en TEST, moins réaliste en _**🚜PROD**_. --- @@ -1230,4 +1233,6 @@ kubectl -n monitoring port-forward svc/monitoring-kube-prometheus-stack-grafana kubectl get secret --namespace kube-prometheus-stack kube-prometheus-stack-grafana -o json | jq '.data | map_values(@base64d)' ``` -## And browse… \ No newline at end of file +## And browse… + +---