mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-05-22 00:32:49 +00:00
🍱 📝 rewording and updating pics
This commit is contained in:
Ludovic Piot
BIN
slides/images/M6-cluster-multi-tenants.png
Normal file
BIN
slides/images/M6-cluster-multi-tenants.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
BIN
slides/images/M6-github-add-token.jpg
Normal file
BIN
slides/images/M6-github-add-token.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 449 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 262 KiB After Width: | Height: | Size: 265 KiB |
@@ -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?
|
||||
|
||||
<!-- TODO: complete this slide when all the modules are there -->
|
||||
**_⚙️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
|
||||
|
||||
<!-- - HA PostgreSQL -->
|
||||
|
||||
@@ -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
|
||||
</pre>
|
||||
|
||||
---
|
||||
|
||||
@@ -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!
|
||||
|
||||
<!-- TODO: few commands to see what our cluster offers -->
|
||||
<!-- TODO: démarrer shpod avec un serviceaccount qui va bien pour attaquer l'API server
|
||||
### Run inside an shpod
|
||||
**_☁️CLOUDY_** is a Kubernetes cluster created with [Scaleway Kapsule](https://www.scaleway.com/en/kubernetes-kapsule/) managed service
|
||||
|
||||
This managed cluster comes preinstalled with specific features:
|
||||
- Kubernetes dashboard
|
||||
- specific _Storage Classes_ based on Scaleway _IaaS_ block storage offerings
|
||||
- a `Cilium` _CNI_ stack already set up
|
||||
|
||||
```
|
||||
To access our cluster, we'll connect via [`shpod`](https://github.com/jpetazzo/shpod)
|
||||
|
||||
.lab[
|
||||
|
||||
```bash
|
||||
kubectl run shpod --image=jpetazzo/shpod --overrides='{ "spec": { "serviceAccountName": "" } }'
|
||||
```
|
||||
-->
|
||||
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 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
|
||||
|
||||
|
||||
|
||||
@@ -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 architecture
|
||||
class: pic
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 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 <none> 80/TCP 5m1s
|
||||
service/source-controller ClusterIP 10.106.120.137 <none> 80/TCP 5m
|
||||
service/webhook-receiver ClusterIP 10.96.28.236 <none> 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)
|
||||
|
||||
Reference in New Issue
Block a user