diff --git a/slides/images/M6-cluster-multi-tenants.png b/slides/images/M6-cluster-multi-tenants.png new file mode 100644 index 00000000..b30a6d99 Binary files /dev/null and b/slides/images/M6-cluster-multi-tenants.png differ diff --git a/slides/images/M6-github-add-token.jpg b/slides/images/M6-github-add-token.jpg new file mode 100644 index 00000000..3980f186 Binary files /dev/null and b/slides/images/M6-github-add-token.jpg differ diff --git a/slides/images/M6-github-add-token.png b/slides/images/M6-github-add-token.png deleted file mode 100644 index 3db67eb4..00000000 Binary files a/slides/images/M6-github-add-token.png and /dev/null differ diff --git a/slides/images/M6-github-teams.png b/slides/images/M6-github-teams.png index 2af6e45d..26b616e3 100644 Binary files a/slides/images/M6-github-teams.png and b/slides/images/M6-github-teams.png differ diff --git a/slides/k8s/M6-START-a-company-scenario.md b/slides/k8s/M6-START-a-company-scenario.md index bedd2ddd..36bc7365 100644 --- a/slides/k8s/M6-START-a-company-scenario.md +++ b/slides/k8s/M6-START-a-company-scenario.md @@ -1,58 +1,56 @@ # Using Kubernetes in an Enterprise-like scenario -- 💪🏼 Okay. The former training modules explain each subject in-depth, and each feature one at-a-time +- 💪🏼 Okay. Prior training modules provded detailed explainations of each topic -- 🤯 The 1st tricky thing any `k8s` admin encounters is to choose and configure all these components to build a _Production-ready_ `k8s` cluster +- 🤯 The 1st challenge any Kubernetes admin faces is choosing all these components to build a _Production-ready_ cluster -- 🎯 This module precisely aims to play a scenario of a day-to-day ordinary workflow in companies and see what we'll have to do to build such a _Prod-ready_ Kubernetes cluster +- 🎯 This module aims to simulate a day-to-day typical workflow in companies, exploring the steps needed to run containerized apps on such a _Prod-ready_ cluster -- As we've done it before, we'll start to build/provision our cluster and then improve it by **adding features** one after another +- We'll start by building our cluster and then enhance it by **adding features** one after another --- ## The plan -In our company, we have 3 different teams, **_⚙️OPS_**, **_🎸ROCKY_** and **_🎬MOVY_** +Our company consists of 3 teams: **_⚙️OPS_**, **_🎸ROCKY_** and **_🎬MOVY_** -- **_⚙️OPS_** is the platform engineer building and configuring Kubernetes clusters +- **_⚙️OPS_** is the platform engineering team responsible for building and configuring Kubernetes clusters -- Both **_🎸ROCKY_** and **_🎬MOVY_** build Web apps that manage 💿 music albums - - **_🎸ROCKY_** builds a Web app managing _rock & pop_ albums - - **_🎬MOVY_** builds a Web app for _movie soundtrack_ albums +- Both **_🎸ROCKY_** and **_🎬MOVY_** develop Web apps that manage 💿 music albums + - **_🎸ROCKY_** manages _rock & pop_ albums + - **_🎬MOVY_** handles _movie soundtrack_ albums -- Each app is stored in its own git repository +- Each app resides in its own `Git` repository -- Both **_🎸ROCKY_** and **_🎬MOVY_** want to code, build package and deploy their applications onto a `Kubernetes` _cluster_ _in an autonomous way_ +- Both **_🎸ROCKY_** and **_🎬MOVY_** aim to code, build package and deploy their applications _in an autonomous way_ --- ### Using 2 Kubernetes clusters -**_⚙️OPS_** team will operate 2 `Kubernetes` clusters +The **_⚙️OPS_** team manages 2 Kubernetes clusters -- **_☁️CLOUDY_** is a managed cluster from a public Cloud provider. - - It comes with many features already configured when the cluster is delivered +- **_☁️CLOUDY_** is a managed cluster from a public Cloud provider + - It comes with pre-configured features upon delivery - HA control plane - 2 dedicated worker nodes - - **_⚙️OPS_** will use `Scaleway Kapsule` to deploy it (but many other _KaaS_ are available…) + - The **_⚙️OPS_** team uses `Scaleway Kapsule` to deploy it (though other _KaaS_ options are available…) -- **_🤘METAL_** is a cluster we install _from scratch_ on bare Linux servers. - - **_⚙️OPS_** team will need to configure many components on its own. +- **_🤘METAL_** is a custom-built cluster installed on bare Linux servers + - The **_⚙️OPS_** team needs to configure many components on its own - HA control plane - 3 worker nodes (also hosting control plane components) - - **_⚙️OPS_** will use `k0s` to install it (but many other distros are available…) + - The **_⚙️OPS_** team uses `k0s` to install it (though other distros are available as well…) --- ### Using several envs for each dev team -**_⚙️OPS_** team will create 2 environment for each dev team : for **testing** and **production** purpose +The **_⚙️OPS_** team creates 2 environments for each dev team: **_⚗️TEST_** and **_🏭PROD_** -- it should use tools to **industrialise creation** of both envs and both clusters +- the setup for each env and cluster should adopt an automated and DRY approach to ensure configurations are consistent and to minimize maintainance -- each cluster and each env has it's **own lifecycle** (the addition or configuration of extra components/features may be done on one env and not the other) - -- configurations must be as DRY as possible (to avoid inconsistency and minimize configuration maintainance) +- each cluster and each env has it's **own lifecycle** (adding an extra component/feature may be done on one env without impacting the other) --- @@ -60,24 +58,24 @@ In our company, we have 3 different teams, **_⚙️OPS_**, **_🎸ROCKY_** and Both **_🎸ROCKY_** and **_🎬MOVY_** teams should use **dedicated _"tenants"_** on each cluster/env -- **_🎸ROCKY_** should be able to deploy, upgrade and configure its own app in its dedicated **namespace** without anybody else involved +- the **_🎸ROCKY_** team should be able to deploy, upgrade and configure its app within its dedicated **namespace** without anybody else involved - and the same for **_🎬MOVY_** -- neither conflict nor collision should be allowed between the 2 apps or the 2 teams. +- neither team's deployments might interfere with the other, maintaining a clean and conflict-free environment --- -## The application +## Application overview + +- Both dev teams are working on an app to manage music albums + +- This app is mostly based on a `Spring` framework demo called spring-music -- Both dev teams are developping an app to manage music albums - -- This app is mostly based upon a demo app based upon `Spring` framework: spring-music - - This lab uses a dedicated fork [container.training-spring-music](https://github.com/Musk8teers/container.training-spring-music): - - with 2 branches dedicated to our **_🎸ROCKY_** and **_🎬MOVY_** teams. + - with 2 branches dedicated to the **_🎸ROCKY_** and **_🎬MOVY_** teams -- The app is a 2-tiers app: +- The app architecture consists of 2 tiers: - a `Java/Spring` Web app - a `PostgreSQL` database @@ -85,7 +83,7 @@ Both **_🎸ROCKY_** and **_🎬MOVY_** teams should use **dedicated _"tenants"_ ### 📂 specific file: application.yaml -This is where we configure the application to use `PostgreSQL` database. +This is where we configure the application to connect to the `PostgreSQL` database. .lab[ @@ -112,26 +110,26 @@ This is where the album collection is initially loaded from the file [`album.jso ## 🚚 How to deploy? -**_⚙️OPS_** team offers 2 deployment strategies that dev teams may use in an autonomous way: +The **_⚙️OPS_** team offers 2 deployment strategies that dev teams can use autonomously: -- **_🎸ROCKY_** will use a `Flux` _GitOps_ workflow based upon regular Kubernetes `YAML` resources +- **_🎸ROCKY_** uses a `Flux` _GitOps_ workflow based on regular Kubernetes `YAML` resources -- **_🎬MOVY_** will use a `Flux` _GitOps_ workflow based upon `Helm` charts +- **_🎬MOVY_** uses a `Flux` _GitOps_ workflow based on `Helm` charts --- ## 🍱 What features? -**_⚙️OPS_** team want its clusters to offers the _"best of breed"_ features to its users: +The **_⚙️OPS_** team aims to provide clusters offering the following features to its users: -- a network stack that is able to isolate workloads one from another +- a network stack with efficient workload isolation - ingress and load-balancing capabilites -- a decent monitoring stack +- an enterprise-grade monitoring solution for real-time insights -- policy rules automation to control the kind of Kubernetes resources that are requested by dev teams +- automated policy rule enforcement to control Kubernetes resources requested by dev teams @@ -149,7 +147,7 @@ This is where the album collection is initially loaded from the file [`album.jso - 2 Web apps Java/Spring + PostgreSQL: one for pop and rock albums, another for movie soundtrack albums -- 2 deployment strategies: regular YAML resources + `Kustomize`, `Helm` charts +- 2 deployment strategies: regular `YAML` resources + `Kustomize`, `Helm` charts > 💻 `Flux` is used both @@ -177,17 +175,17 @@ gitGraph branch CLASSY order:4 checkout OPS - commit id:'TEST cluster creation' tag:'T01' + commit id:'Flux install on CLOUDY cluster' tag:'T01' branch CLOUDY-cluster_TEST-env order:1 - commit id:'FLUX install on TEST' tag:'T02' + commit id:'FLUX install on TEST' tag:'T02' type: HIGHLIGHT checkout OPS - commit id:'TEST cluster config.' tag:'T03' + commit id:'ROCKY config.' tag:'T03' checkout CLOUDY-cluster_TEST-env - merge OPS id:'setup of TEST cluster' tag:'T04' + merge OPS id:'ROCKY tenant creation' tag:'T04' checkout OPS - commit id:'FLUX config for ROCKY deployment' tag:'R01' + commit id:'ROCKY deploy. config.' tag:'R01' checkout CLOUDY-cluster_TEST-env merge OPS id:'FLUX ready to deploy ROCKY' type: HIGHLIGHT tag:'R02' @@ -258,5 +256,3 @@ gitGraph checkout PROD-cluster merge OPS type: HIGHLIGHT - ---- diff --git a/slides/k8s/M6-T02-flux-install.md b/slides/k8s/M6-T02-flux-install.md index b8da4aa1..a249a398 100644 --- a/slides/k8s/M6-T02-flux-install.md +++ b/slides/k8s/M6-T02-flux-install.md @@ -1,41 +1,48 @@ -# T02- **_⚗️TEST_** env creation (on **_☁️CLOUDY_** cluster ) +# T02- creating **_⚗️TEST_** env on our **_☁️CLOUDY_** cluster -Let's take a look to our cloudy cluster! +Let's take a look at our **_☁️CLOUDY_** cluster! - - + +] --- -## Flux install +## Flux installation Once `Flux` is installed, -**_⚙️OPS_** team exclusively operates its clusters by updating a code base in a `git` repository +the **_⚙️OPS_** team exclusively operates its clusters by updating a code base in a `Github` repository -_GitOps_ and `Flux` enable **_⚙️OPS_** team to rely on the _first-citizen pattern_ in Kubernetes world: +_GitOps_ and `Flux` enable the **_⚙️OPS_** team to rely on the _first-class citizen pattern_ in Kubernetes' world through these steps: -- describe the desired target state -- and let the automated convergence happens. +- describe the **desired target state** +- and let the **automated convergence** happens --- ### Checking prerequisites -`Flux` _CLI_ is available in your `shpod` pod +The `Flux` _CLI_ is available in our `shpod` pod -First, we check: - - that `Flux` _CLI_ is right there and run correctly - - that it is able to connect to the `API server` - - that both `Flux` and `Kubernetes` are OK and work well together +Before installation, we need to check that: + - `Flux` _CLI_ is correctly installed + - it can connect to the `API server` + - our versions of `Flux` and Kubernetes are compatible -.lab [ +.lab[ ```bash shpod:~# flux --version @@ -51,52 +58,54 @@ shpod:~# flux check --pre --- -### Git repository to store the Flux configuration of our clusters +### Git repository for Flux configuration -- **_⚙️OPS_** uses the _CLI_ - - to create a `fleet-config-using-flux-XXX` repository - - in our `Github` organization : `container-training-fleet` +The **_⚙️OPS_** team uses `Flux` _CLI_ +- to create a `git` repository named `fleet-config-using-flux-XXXXX` (⚠ replace `XXXXX` by a personnal suffix) +- in our `Github` organization named `container-training-fleet` -- To do so, `Flux` _CLI_ needs - - a `Github` _PAT_ (personal access token) - - with _CRUD_ permissions on our `Github` organization repositories +Prerequisites are: + - `Flux` _CLI_ needs a `Github` personal access token (_PAT_) + - to create and/or access the `Github` repository + - to give permissions to existing teams in our `Github` organization + - The PAT needs _CRUD_ permissions on our `Github` organization + - repositories + - admin:public_key + - users -- So, **_⚙️OPS_** team creates a `Github` personal access token +- As **_⚙️OPS_** team, let's creates a `Github` personal access token… --- -### Generate a Github Personal Access Token (PAT) +class: pic -![Generate a Github personal access token](images/M6-github-add-token.png) +![Generating a Github personal access token](images/M6-github-add-token.jpg) --- ### Creating dedicated `Github` repo to host Flux config -- replace the `GITHUB_TOKEN` value by your _Personal Access Token_ -- replace the `GITHUB_REPO` value by your specific repository name - -.lab [ +- let's replace the `GITHUB_TOKEN` value by our _Personal Access Token_ +- and the `GITHUB_REPO` value by our specific repository name + +.lab[ ```bash -$ export GITHUB_TOKEN="my-token" -$ export GITHUB_USER="container-training-fleet" -$ export GITHUB_REPO="fleet-config-using-flux-XXXXX" - -$ flux bootstrap github \ +shpod:~# export GITHUB_TOKEN="my-token" +shpod:~# export GITHUB_USER="container-training-fleet" +shpod:~# export GITHUB_REPO="fleet-config-using-flux-XXXXX" +shpod:~# flux bootstrap github \ --owner=${GITHUB_USER} \ --repository=${GITHUB_REPO} \ --team=OPS \ - --team=ROCKY \ - --team=MOVY \ + --team=ROCKY --team=MOVY \ --path=clusters/CLOUDY ``` - ] --- -Here is the result of the command +Here is the result ```bash ✔ repository "https://github.com/container-training-fleet/fleet-config-using-flux-lpiot" created @@ -142,10 +151,10 @@ Here is the result of the command --- -### Flux configures Github repository permissions for organization teams +### Flux configures Github repository access for teams -- `Flux` configures permissions for organization teams to **maintain** the `Github` repository -- Teams should already exist before `Flux` configuration +- `Flux` sets up permissions that allow teams within our organization to **access** the `Github` repository as maintainers +- Teams need to exist before `Flux` proceeds to this configuration ![Teams in Github](images/M6-github-teams.png) @@ -153,56 +162,124 @@ Here is the result of the command ### ⚠️ Disclaimer -- In this lab, adding these teams as maintainers was just a way to demonstrate how `Flux` _CLI_ configures permissions in Github +- In this lab, adding these teams as maintainers was merely a demonstration of how `Flux` _CLI_ sets up permissions in Github -- We don't need for dev teams to have access to this `Github` repository +- But there is no need for dev teams to have access to this `Github` repository -- 💪🏼 **Separation of concerns** by using multiple `Flux` sources is one of the advantages of _GitOps_ +- One advantage of _GitOps_ lies in its ability to easily set up 💪🏼 **Separation of concerns** by using multiple `Flux` sources --- ### 📂 Flux config files -`Flux` is now installed onto our cloudy cluster! +`Flux` has been successfully installed onto our **_☁️CLOUDY_** Kubernetes cluster! -And it's configuration is now maintained _via_ a _Gitops_ workflow sourcing in the `git` repository +Its configuration is managed through a _Gitops_ workflow sourced directly from our `Github` repository -Let's review the config files `Flux` created and commited into the `git` repository… -… and the actual components in our cluster +Let's review our `Flux` configuration files we've created and pushed into the `Github` repository… +… as well as the corresponding components running in our Kubernetes cluster ![Flux config files](images/M6-flux-config-files.png) --- -### Flux architecture +class: pic ![Flux architecture](images/M6-flux-schema.png) --- +### Flux resources 1/2 + +.lab[ + +```bash +shpod:~# kubectl get all --namespace flux-system +NAME READY STATUS RESTARTS AGE +pod/helm-controller-b6767d66-h6qhk 1/1 Running 0 5m +pod/kustomize-controller-57c7ff5596-94rnd 1/1 Running 0 5m +pod/notification-controller-58ffd586f7-zxfvk 1/1 Running 0 5m +pod/source-controller-6ff87cb475-g6gn6 1/1 Running 0 5m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/notification-controller ClusterIP 10.104.139.156 80/TCP 5m1s +service/source-controller ClusterIP 10.106.120.137 80/TCP 5m +service/webhook-receiver ClusterIP 10.96.28.236 80/TCP 5m +(…) +``` + +] + +--- + +### Flux resources 2/2 + +.lab[ + +```bash +shpod:~# kubectl get all --namespace flux-system +(…) +NAME READY UP-TO-DATE AVAILABLE AGE +deployment.apps/helm-controller 1/1 1 1 5m +deployment.apps/kustomize-controller 1/1 1 1 5m +deployment.apps/notification-controller 1/1 1 1 5m +deployment.apps/source-controller 1/1 1 1 5m + +NAME DESIRED CURRENT READY AGE +replicaset.apps/helm-controller-b6767d66 1 1 1 5m +replicaset.apps/kustomize-controller-57c7ff5596 1 1 1 5m +replicaset.apps/notification-controller-58ffd586f7 1 1 1 5m +replicaset.apps/source-controller-6ff87cb475 1 1 1 5m +``` + +] + +--- + ### Flux components -- `source controller` watches sources based upon `git` repositories to apply the `Kubernetes` resources it finds on the cluster +- the `source controller` monitors `Git` repositories to apply Kubernetes resources on the cluster -- `helm controller` look for new `Helm` _charts_ releases in `Helm` _charts_ repositories to install them on the cluster +- the `Helm controller` checks for new `Helm` _charts_ releases in `Helm` repositories and installs updates as needed -- _CRDs_ store `Flux` configuration in `Kubernetes` control plane +- _CRDs_ store `Flux` configuration within the Kubernetes control plane + +--- + +### Flux resources that have been created + +.lab[ + +```bash +shpod:~# flux get all --all-namespaces +NAMESPACE NAME REVISION SUSPENDED + READY MESSAGE +flux-system gitrepository/flux-system main@sha1:d48291a8 False + True stored artifact for revision 'main@sha1:d48291a8' + +NAMESPACE NAME REVISION SUSPENDED + READY MESSAGE +flux-system kustomization/flux-system main@sha1:d48291a8 False + True Applied revision: main@sha1:d48291a8 +``` + +] --- ### Flux CLI -`Flux` _CLI_ has 3 main roles : +`Flux` Command-Line Interface fulfills 3 primary functions: -1. to install and configure initial `Flux` resources into a _Gitops_-oriented `git` repository - - it configures this repository (permissions, keys to access it…) +1. It installs and configures first mandatory `Flux` resources in a _Gitops_ `git` repository + - ensuring proper access and permissions -1. to locally create the `YAML` files for any `Flux` resources we wish to add to our `Flux` _Gitops_ configuration +2. It locally generates `YAML` files for desired `Flux` resources so that we just need to `git push` them - tenants - sources - … -1. to request the API server for `Flux`-related resources +3. It requests the API server to manage `Flux`-related resources - _operators_ - _CRDs_ - logs @@ -211,22 +288,47 @@ Let's review the config files `Flux` created and commited into the `git` reposit ### 🔍 Flux -- for more info -Look at the `Flux` [chapter in High Five M3 module](./3.yml.html#toc-helm-chart-format) +Please, refer to the [`Flux` chapter in the High Five M3 module](./3.yml.html#toc-helm-chart-format) --- ### Flux relies on Kustomize -The `Flux` component named `kustomize controller` look for `Kustomize` resources in sources +The `Flux` component named `kustomize controller` look for `Kustomize` resources in `Flux` code-based sources -1. `Kustomize` look for the `YAML` manifests listed in the `kustomization` +1. `Kustomize` look for `YAML` manifests listed in the `kustomization.yaml` file 2. and aggregates, hydrates and patches them following the `kustomization` configuration --- -### 🔍 Kustomize -- for more info +### 2 different kustomization resources -Look at the [`Kustomize` chapter in High Five M3 module](./3.yml.html#toc-kustomize) +⚠️ `Flux` uses 2 distinct resources with `kind: kustomization` + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: kustomization +``` + +describes how Kustomize (the _CLI_ tool) appends and transforms `YAML` manifests into a single bunch of `YAML` described resources + +```yaml +apiVersion: kustomize.toolkit.fluxcd.io/v1 group +kind: Kustomization +``` + +describes where `Flux kustomize-controller` look for a `kustomization.yaml` file in a given `Flux` code-based source --- + +### 🔍 Kustomize -- for more info + +Please, refer to the [`Kustomize` chapter in the High Five M3 module](./3.yml.html#toc-kustomize) + +--- + +### 🔍 Group / Version / Kind -- for more info + +For more info about how Kubernetes resource natures are identified by their `Group / Version / Kind` triplet… +… please, refer to the [`Kubernetes API` chapter in the High Five M5 module](./5.yml.html#toc-the-kubernetes-api)