diff --git a/content/kubernetes-hell-to-heaven/css/custom.css b/content/kubernetes-hell-to-heaven/css/custom.css index 92a704a..5f49f27 100644 --- a/content/kubernetes-hell-to-heaven/css/custom.css +++ b/content/kubernetes-hell-to-heaven/css/custom.css @@ -182,6 +182,13 @@ padding: 0.45em 0.85em; } +.reveal blockquote .blockquote-sub { + display: block; + margin-top: 0.0em; + font-size: 0.88em; + color: var(--text-subtle); +} + .reveal aside.notes { display: none !important; } @@ -238,7 +245,7 @@ } /* - * Slide « boucle » (n° 6) : graphe cyclique Mermaid = très haut ; graphe linéaire + libellés courts. + * Slide « boucle » (API / événements / controllers / réconciliation) : graphe Mermaid assez large — hauteur plafonnée. * Pas de scale() : ça ne réduit pas la hauteur de layout (Reveal mesure scrollHeight). */ .reveal .slides section.slide-boucle { @@ -260,7 +267,16 @@ line-height: 1.15; } -/* Mermaid sur la slide « boucle » : hauteur mini correcte (éviter l’écrasement à ~78px qui tuait les libellés) */ +.reveal section.slide-boucle .slide-boucle-lead { + margin: 0 0 0.45em; + padding: 0; + list-style: none; + font-size: clamp(0.82rem, 2.6vw, 0.95rem); + color: var(--text-muted); + line-height: 1.35; +} + +/* Mermaid sur la slide « boucle » : graphe fusionné (outils + boucle) — un peu plus de hauteur qu’avant */ .reveal section.slide-boucle .mermaid { margin: 0.25em auto 0.15em; line-height: normal; @@ -269,7 +285,7 @@ } .reveal section.slide-boucle .mermaid svg { - max-height: min(34vh, 220px) !important; + max-height: min(42vh, 300px) !important; overflow: visible !important; } diff --git a/content/kubernetes-hell-to-heaven/img/helmsh-icon.svg b/content/kubernetes-hell-to-heaven/img/helmsh-icon.svg new file mode 100644 index 0000000..b713b37 --- /dev/null +++ b/content/kubernetes-hell-to-heaven/img/helmsh-icon.svg @@ -0,0 +1,116 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/kubernetes-hell-to-heaven/img/logo-kustomize.B5HO6GxI_1tyDev.webp b/content/kubernetes-hell-to-heaven/img/logo-kustomize.B5HO6GxI_1tyDev.webp new file mode 100644 index 0000000..9d61dc7 Binary files /dev/null and b/content/kubernetes-hell-to-heaven/img/logo-kustomize.B5HO6GxI_1tyDev.webp differ diff --git a/content/kubernetes-hell-to-heaven/index.html b/content/kubernetes-hell-to-heaven/index.html index 3af8d5d..7fb64cf 100644 --- a/content/kubernetes-hell-to-heaven/index.html +++ b/content/kubernetes-hell-to-heaven/index.html @@ -37,27 +37,37 @@

Kubernetes : délire d’Ops ?

-

On vous l’a vendu comme un truc d’infra

+

On nous l’a surtout vendu comme un truc d’infra.
+ Moi aussi, je suis passé par ce réflexe. +

+
+
+

Kubernetes c'est un délire de dev +

+
+

Kubernetes = API + état + boucle

De vos outils au noyau Linux

-
flowchart LR
-    A[Clients] --> B[kube-api]
-    B --> C[etcd]
-    B --> D[Controllers]
-    D --> E[kubelet]
-    E --> F[containerd]
-    F --> G[Kernel Linux]
+        

+    flowchart LR
+      B[kube-api]
+      subgraph Clients
+      A01[kubectl]
+      A02@{ img: "img/helmsh-icon.svg", pos: "b", h: 44, constraint: "on" }
+      A03@{ img: "img/logo-kustomize.B5HO6GxI_1tyDev.webp", pos: "b", h: 36, constraint: "on" }
+      end
+      A01 --> B
+      A02 --> B
+      A03 --> B
+      D --> B
+      B --> C[etcd]
+      B --> D[Controllers]
+      D --> E[kubelet]
+      E --> F[containerd]
+      F --> G[Kernel Linux]
+      classDef logoBare fill:transparent,stroke:transparent,stroke-width:0px;
+      class A02,A03 logoBare;
 
-
-

Kubernetes ne fait pas tourner vos apps

- - -
-

État voulu → réel : la boucle

+

Kubernetes ne fait pas tourner vos apps : la boucle de contrôle

+
flowchart LR
-    A[Désiré] --> B[API] --> C[Controllers] --> D[Réel]
+    DS[Spec · désir] --> AP[kube-apiserver]
+    AP <-->|objets cluster| ET[(etcd)]
+    AP --> EV[Watch · événements]
+    EV --> CTRL[Controllers]
+    CTRL -->|réconciliation · requêtes API| AP
+    subgraph NODE[Nœud]
+      K[kubelet] -->|CRI| CD[containerd]
+    end
+    AP -->|spec Pods · synchro| K
+    K -->|status| AP
 

- réinjecte vers les contrôleurs · chaque tour : observer, décider, agir + Les changements d’objets (Pods, etc.) vivent dans l’API ; le kubelet les + synchronise depuis l’API, puis traduit en appels CRI vers + containerd. Le status remonte par le même kubelet vers l’API.

@@ -142,10 +169,10 @@

Kubernetes vous évite de vivre dans le noyau

-

À côté de ça, un cluster qui râle, c’est presque du repos.

+

À côté de ça, un cluster qui râle, c'est presque du repos.

-
-

Automatiser le métier… en code dans le cluster

- -

Sans opérateur : scripts, crons, humains dans la boucle

+
+

Exemple Reflector : secret DB → namespace applicatif

+

Le secret « source de vérité » vit avec la base ; Reflector recrée un miroir là où l’app tourne.

+
# Namespace database — secret maître (ex. mot de passe géré par l’opérateur / la DBA)
+apiVersion: v1
+kind: Secret
+metadata:
+  name: db-credentials
+  namespace: database
+  annotations:
+    reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
+    reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true"
+    reflector.v1.k8s.emberstack.com/reflection-auto-namespaces: "app-shop"
+stringData:
+  DATABASE_URL: "postgres://…"
+
+ + +
+
+

Exemple Reloader : rollout quand le secret miroir change

+

Le Deployment monte le secret copié ; Reloader redémarre les Pods si le Secret (ou ConfigMap) référencé + est mis à jour.

+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: shop-api
+  namespace: app-shop
+  annotations:
+    reloader.stakater.com/auto: "true"
+spec:
+  template:
+    spec:
+      containers:
+        - name: api
+          envFrom:
+            - secretRef:
+                name: db-credentials   # copie Reflector depuis database/
+
+ + +

Cert-manager, Postgres, Keycloak : la spec devient une entité

@@ -453,6 +532,51 @@ spec:

+
+

Quelle techno pour développer votre opérateur ?

+
+ + + + + + + + + + + + + + + + + + + + + + + + +
PisteOutils typiquesÀ retenir
Go (référence)Kubebuilder, controller-runtime, client-goMême patterns que l’upstream (reconcile, owner refs). Sous pic + d’événements : goroutines + files + back-off → peu de RAM en plus — + le Pod opérateur ne part pas en limite quand le cluster s’emballe.
Operator SDKCLI Red Hat · Go (souvent comme Kubebuilder) · Ansible / HelmGo = solide ; Ansible / Helm = wrapper playbooks / charts — court si la logique métier épaissit.
Autres langagesPython Kopf, Rust kube-rs, Java (Fabric8, Quarkus)…Si équipe ou libs métier ; moins d’exemples tout faits côté core k8s.
+

Go + controller-runtime pour un opérateur maison sérieux ; sinon : celui que l’équipe + livre et maintient le mieux.

+

Charge ↑ : un runtime qui gonfle la RAM par événement mange votre quota ; Go + controller-runtime, + non.

+ +

Quand un opérateur est légitime

+

Exemple concret de CRD à la slide suivante.

+
+

Exemple — KeycloakClientCredential

+

CRD secrets.carbogame.com/v1alpha1spec.source (realm, client) → + spec.target (Secret, rafraîchissement, mapping des clés).

+
apiVersion: secrets.carbogame.com/v1alpha1
+kind: KeycloakClientCredential
+metadata:
+  name: gitea-creds
+  namespace: keycloak
+spec:
+  source:
+    keycloakServer: prod-keycloak
+    realm: operator
+    clientId: gitea
+  target:
+    secretName: gitea-secret-creds
+    namespace:
+      - gitea
+    refreshPeriod: 10m
+    fields:
+      clientId: key
+      clientSecret: secret
+
+

Extrait type ; en chart Helm, namespace et keycloakServer sont injectés via + include "common.namespace" …, {{ .Values.global.env }}-keycloak, etc.

+ +
+
+

Développer son opérateur : réutiliser les autres

+ + +

Ce qu’un opérateur bien choisi vous apporte

-

Un opérateur mal conçu, c’est un microservice sous LSD.

+

Un opérateur mal conçu, c’est un microservice dont plus personne ne tient les règles du jeu.

@@ -701,7 +890,8 @@ spec: - + +