images

alterway · Sep 13, 2024 · f30e0ea · f30e0ea
1 parent 7bc41b2
commit f30e0ea
Show file tree

Hide file tree

Showing 24 changed files with 174 additions and 66 deletions.
diff --git a/cours/containers/kubernetes/k8s-architecture.fr.md b/cours/containers/kubernetes/k8s-architecture.fr.md
@@ -40,17 +40,13 @@
 - core services :
 
     - `kube-scheduler` : Implémente les fonctionnalités de scheduling
-
     - `kube-controller-manager` : Responsable de l'état du cluster, boucle infinie qui régule l'état du cluster afin d'atteindre un état désiré
-
     - `kube-cloud-controller-manager` : Est un composant important du plan de contrôle (control plane) de Kubernetes, spécifiquement conçu pour interagir avec l'infrastructure cloud sous-jacente
-
     - `kube-proxy` : Permet le forwarding TCP/UDP et le load balancing entre les services et les backends (Pods)
 
-
 - Le control plane est aussi appelé "Master"
 
-![](images//kubernetes/control-plane.webp){height="150px"}
+![](images//kubernetes/control-plane.webp){height="250px"}
 
 ### Kubernetes : `etcd`
 
@@ -118,15 +114,14 @@ Le kube-controller-manager exécute et fait tourner les processus de contrôle d
 - Fonction principale :
 
     - Le CCM agit comme une interface entre Kubernetes et le fournisseur de cloud spécifique (comme AWS, Google Cloud, Azure, etc.). Il permet à Kubernetes de gérer les ressources spécifiques au cloud de manière indépendante du reste du cluster.
-
     - Séparation des responsabilités :
         - Avant l'introduction du CCM, le contrôleur de nœud (node controller), le contrôleur de route (route controller) et le contrôleur de service (service controller) étaient intégrés au contrôleur de gestion Kubernetes (kube-controller-manager). Le CCM a extrait ces fonctionnalités spécifiques au cloud pour les gérer séparément.
     - Contrôleurs spécifiques au cloud : Le CCM implémente plusieurs contrôleurs qui interagissent avec l'API du fournisseur de cloud :
         - Node Controller : Vérifie si les nœuds ont été supprimés dans le cloud après avoir cessé de répondre.
         - Route Controller : Configure les routes dans l'infrastructure cloud pour que les pods sur différents nœuds puissent communiquer.
         - Service Controller : Crée, met à jour et supprime les load balancers du cloud.
 
-![](images//kubernetes/Kubernetes-Architecture-Diagram-Explained.png){height="260px"}
+![](images//kubernetes/Kubernetes-Architecture-Diagram-Explained.png){height="280px"}
 
 
 ### Kubernetes : `kube-proxy`
@@ -165,13 +160,9 @@ Certains plugins réseaux, tel que **Cilium**, permettent de ne plus utiliser **
 ![](images//kubernetes/services-userspace-overview.svg){height="400px"}
 
 - Userspace mode est ancien et inefficace. 
-
 - Le paquet est comparé aux règles iptables puis transféré au pod **kube-Proxy**, qui fonctionne comme une application pour transférer le paquet aux pods backend.
-
 - Kube-proxy fonctionne sur chaque nœud en tant que processus dans l'espace utilisateur. 
-
 - Il distribue les requêtes entre les pods pour assurer l'équilibrage de charge et intercepte la communication entre les services. 
-
 - Malgré sa portabilité et sa simplicité, le surcoût de traitement des paquets dans l'espace utilisateur le rend moins efficace pour les charges de trafic élevées.
 
 
@@ -180,25 +171,19 @@ Certains plugins réseaux, tel que **Cilium**, permettent de ne plus utiliser **
 ![](images//kubernetes/services-iptables-overview.svg){height="400px"}
 
 - Le mode iptables est préférable car il utilise la fonctionnalité iptables du noyau, qui est assez mature. 
-
 - kube-proxy gère les règles iptables en fonction du fichier YAML du service de Kubernetes.
-
 - Pour gérer le trafic des services, Kube-proxy configure des règles iptables sur chaque nœud.
-
 - Il achemine les paquets vers les pods pertinents en utilisant du NAT (Network Address Translation) iptables. 
-
 - Ce mode fonctionne bien avec des volumes de trafic modestes et est plus efficace que le mode espace utilisateur.
 
 ### Kubernetes : `kube-proxy` IPVS mode
 
 
 ![](images//kubernetes/services-ipvs-overview.svg){height="400px"}
 
-IPVS mode équilibre la charge en utilisant la fonctionnalité IPVS du noyau Linux. Par rapport au mode IPtables, il offre une meilleure évolutivité et des performances améliorées.
-
-IPVS est le mode recommandé pour les installations à grande échelle car il peut gérer de plus gros volumes de trafic avec efficacité. 
-
-**IPtable Non !**
+- IPVS mode équilibre la charge en utilisant la fonctionnalité IPVS du noyau Linux. Par rapport au mode IPtables, il offre une meilleure évolutivité et des performances améliorées.
+
+- IPVS est le mode recommandé pour les installations à grande échelle car il peut gérer de plus gros volumes de trafic avec efficacité. **IPtable Non !**
 
 
 
@@ -218,7 +203,7 @@ Elle, Il, iel ?  😉
 - Intégration avec le système d'exploitation : Kubelet s'intègre avec le système d'exploitation hôte pour gérer les réseaux, les volumes et autres fonctionnalités du système.
 
 
-![](images//kubernetes/CRI.png){height="400px"}
+![](images//kubernetes/CRI.png){height="300px"}
 
 
 
@@ -268,5 +253,6 @@ Kubernetes n'implémente pas de solution réseau par défaut, mais s'appuie sur
 
 
 
-![Top expectation](images/kubernetes/k2024.avif)
+![Top expectation](images/kubernetes/k2024.avif){height="400px"}
+
 
diff --git a/cours/containers/kubernetes/k8s-certification.fr.md b/cours/containers/kubernetes/k8s-certification.fr.md
@@ -3,7 +3,9 @@
 ### CKA exam
 
 - La durée de l'examen est de 2h
+
 - Avec des exercices pratiques dans un cluster déjà opératinnel
+
 - Accès à la ddocumentation officielle de Kubernetes autorisé
 
 - Quelques liens utiles:
@@ -13,6 +15,4 @@ https://docs.linuxfoundation.org/tc-docs/certification/lf-candidate-handbook
 https://github.com/cncf/curriculum
 
 
-
-
 
diff --git a/cours/containers/kubernetes/k8s-core-api-objects.fr.md b/cours/containers/kubernetes/k8s-core-api-objects.fr.md
@@ -61,7 +61,9 @@ spec:
 
 ### Kubernetes : Labels
 
-- La commande `kubectl get pods`, par défaut, ne liste pas les labels. Il est possible de les voir en utilisant `--show-labels`:
+- La commande `kubectl get pods`, par défaut, ne liste pas les labels. 
+
+- Il est possible de les voir en utilisant `--show-labels`:
 
 ```console
 $ kubectl get pods --show-labels

diff --git a/cours/containers/kubernetes/k8s-helm-intro.fr.md b/cours/containers/kubernetes/k8s-helm-intro.fr.md
@@ -28,7 +28,7 @@ A voir :
 - Cela permet d'installer par ex. 10 instances de MongoDB
   (avec des versions et configurations potentiellement différentes)  
 
-### Kubernetes : Conceptes de Helm 
+### Kubernetes : Concepts de Helm 
 
 - `helm` est un outil CLI
 

diff --git a/cours/containers/kubernetes/k8s-logging-monitoring.fr.md b/cours/containers/kubernetes/k8s-logging-monitoring.fr.md
@@ -36,8 +36,8 @@ lab-middleware-c46cd576f-7zckz   1m           43Mi
 ### Logging
 
 - Tout comme docker, Kubernetes permet d'afficher les logs générés par les applications avec la commande `kubectl logs`
-- L'option -f permet de diffusion en direct des logs
-- Pour les pods multiconteneurs, il est nécessaire de spécifier le conteneur dont on veut visualiser les logs
+- L'option `-f` permet de diffusion en direct des logs
+- Pour les pods multi-conteneurs, il est nécessaire de spécifier le conteneur dont on veut visualiser les logs
 
 
 ### Logging

diff --git a/cours/containers/kubernetes/k8s-networking.fr.md b/cours/containers/kubernetes/k8s-networking.fr.md
@@ -384,12 +384,23 @@ spec:
 
 ### Kubernetes : Ingress Controller
 
-Pour utiliser un `Ingress`, il faut un Ingress Controller. Il existe plusieurs offres sur le marché :
+Pour utiliser un `Ingress`, il faut un `Ingress Controller`
+
+Il existe plusieurs solutions OSS ou non :
 
 - Traefik : <https://github.com/containous/traefik>
 - Istio : <https://github.com/istio/istio>
 - Linkerd : <https://github.com/linkerd/linkerd>
 - Contour : <https://www.github.com/heptio/contour/>
 - Nginx Controller : <https://github.com/kubernetes/ingress-nginx>
 
+⚠︎ Note : Il est possible d'avoir plusieurs Ingress Controller sur un cluster il suffira dans les objets ingress de préciser sur quelle classe d'ingress on souhaite le créer.
+Ca se fait par `ingressClassName`. 
+
+Ces classes sont créees au moment de l'installation du contrôleur.
+
+Les **Ingress** vont bientôt être dépréciés en faveur des `Gateway API` qui sont la nouvelle génération de Kubernetes Ingress, Load Balancing, et Service Mesh APIs.
+
+Plus d'informations ici : <https://gateway-api.sigs.k8s.io/>
+
 
diff --git a/cours/containers/kubernetes/k8s-observability-monitoring.fr.md b/cours/containers/kubernetes/k8s-observability-monitoring.fr.md
@@ -10,27 +10,35 @@
   - Command: Exécute une commande dans le conteneur
   - grpc : standard GRPC Health Checking Protocol
 
+
+![](images/kubernetes/probes.png){height="700px"}
+
+
+### Sondes : Startup
+
+- Disponible en bêta à partir de la version 1.18
+- Utiles pour les applications qui ont un démarrage lent
+- Permet de ne pas augmenter les `initialDelaySeconds` des Readiness et Liveness
+- Elle sert à savoir quand l'application est prête
+- Les 3 sondes combinées permet de gérer très finement la disponibilité de l'application
+
+
+
 ### Sondes : Readiness
 
 - Gère le trafic à destination du pod
 - Un pod avec une sonde readiness *NotReady* ne reçoit aucun trafic
 - Permet d'attendre que le service dans le conteneur soit prêt avant de router du trafic
 - Un pod *Ready* est ensuite enregistrer dans les *endpoints* du service associé
 
+
+
 ### Sondes : Liveness
 
 - Gère le redémarrage du conteneur en cas d'incident
 - Un pod avec une sonde liveness sans succès est redémarré au bout d'un intervalle défini
 - Permet de redémarrer automatiquement les pods "tombés" en erreur
 
-### Sondes : Startup
-
-- Disponible en bêta à partir de la version 1.18
-- Utiles pour les applications qui ont un démarrage lent
-- Permet de ne pas augmenter les `initialDelaySeconds` des Readiness et Liveness
-- Elle sert à savoir quand l'application est prête
-- Les 3 sondes combinées permet de gérer très finement la disponibilité de l'application
-
 
 ### Différents types de sondes : `httpGet`
 
@@ -44,8 +52,6 @@
     - tout autre code = échec
 
 
-
-
 
 ### Différents types de sondes : `exec`
 

diff --git a/cours/containers/kubernetes/k8s-resources-handling.fr.md b/cours/containers/kubernetes/k8s-resources-handling.fr.md
@@ -130,3 +130,7 @@ spec:
 ```
 
 
+![](images/kubernetes/resource-quota-limitrange.gif){height="700px"}
+
+
+
diff --git a/cours/containers/kubernetes/k8s-security.fr.md b/cours/containers/kubernetes/k8s-security.fr.md
@@ -130,15 +130,17 @@ kubectl auth can-i get pods /
 ### NetworkPolicies
 
 - La ressource `NetworkPolicy` est une spécification permettant de définir comment un ensemble de `pods` communiquent entre eux ou avec d'autres endpoints
+
 - Le `NetworkPolicy` utilisent les labels pour sélectionner les pods sur lesquels s'appliquent les règles qui définissent le trafic alloué sur les pods sélectionnés
+
 - Le `NetworkPolicy` est générique et fait partie de l'API Kubernetes. Il est nécessaire que le plugin réseau déployé supporte cette spécification
 
 
 ### NetworkPolicies
 
 - DENY tout le trafic sur une application
 - LIMIT le trafic sur une application
-- DENY le trafic all non alloué dans un namespace
+- DENY les trafic entrant et sortant dans un namespace
 - DENY tout le trafic venant d'autres namespaces
 - exemples de Network Policies : <https://github.com/ahmetb/kubernetes-network-policy-recipes>
 
@@ -169,7 +171,7 @@ Cilium Network Policy Editor : <https://editor.networkpolicy.io/?id=xJYCeLwGmAGx
 
 ### NetworkPolicies : outils : Tufin Network Policy Viewer
 
-Tufin Network Policy Viewer : https://orca.tufin.io/netpol/
+Tufin Network Policy Viewer : <https://orca.tufin.io/netpol/>
 
 
 ![tufin](images/kubernetes/npp2.png){height="400px"}
Original file line number	Diff line number	Diff line change
Expand Up		@@ -130,3 +130,7 @@ spec:
		```


		![](images/kubernetes/resource-quota-limitrange.gif){height="700px"}