argo

alterway · Jan 20, 2025 · a70baf3 · a70baf3
1 parent 4f0b086
commit a70baf3
Show file tree

Hide file tree

Showing 11 changed files with 278 additions and 28 deletions.
diff --git a/cours/containers/kubernetes/k8s-architecture.fr.md b/cours/containers/kubernetes/k8s-architecture.fr.md
@@ -238,17 +238,19 @@ Kubernetes n'implémente pas de solution réseau par défaut, mais s'appuie sur
 
 ### Kubernetes : Aujourd'hui
 
-- Version 1.30.x : stable en production
+Les versions de Kubernetes sont exprimées sous la forme x.y.z, où x est la version majeure, y est la version mineure et z est la version du correctif, conformément à la terminologie du Semantic Versioning.
+
+- Version 1.31.x : stable en production
 - Solution complète et une des plus utilisées
 - Éprouvée par Google
 - <https://kubernetes.io/releases/>
 
 
-**1.31:**
-    Latest Release:1.31.0 (released: 2024-08-13)  
-    End of Life:2025-10-28  
+**1.32:**
+    Latest Release:1.32.0 (released: 2024-12-11)  
+    End of Life: 2026-02-28
     Patch Releases: n/a  
-    Complete 1.31 [Schedule](https://kubernetes.io/releases/patch-releases/#1-31) and [Changelog](https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.31.md)
+    Complete 1.31 [Schedule](https://kubernetes.io/releases/patch-releases/#1-32) and [Changelog](https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.32.md)
 
 
 

diff --git a/cours/containers/kubernetes/k8s-argocd-intro.fr.md b/cours/containers/kubernetes/k8s-argocd-intro.fr.md
@@ -0,0 +1,94 @@
+# Introduction à ArgoCD
+
+## Qu'est-ce qu'ArgoCD ?
+
+ArgoCD est un outil de déploiement continu (CD) déclaratif pour Kubernetes.
+- Conçu pour implémenter le GitOps
+- Open source et partie de la CNCF
+- Permet de synchroniser l'état souhaité (Git) avec l'état réel (Kubernetes)
+
+## Pourquoi ArgoCD ?
+
+### Avantages Clés
+- **GitOps natif**: Votre code Git devient la source unique de vérité
+- **Automatisation**: Déploiements automatiques lors des changements dans Git
+- **Visibilité**: Interface utilisateur intuitive pour surveiller les déploiements
+- **Sécurité**: Gestion fine des accès et audit complet des changements
+
+## Architecture
+
+```
+                    ┌─────────────┐
+                    │             │
+                    │    Git      │
+                    │             │
+                    └──────┬──────┘
+                           │
+                           ▼
+┌──────────────┐   ┌──────────────┐   ┌─────────────┐
+│   ArgoCD     │   │   ArgoCD     │   │             │
+│     API      │◄──┤  Controller  │──►│  Kubernetes │
+│    Server    │   │              │   │   Cluster   │
+└──────────────┘   └──────────────┘   └─────────────┘
+```
+
+## Concepts Fondamentaux
+
+### 1. Applications
+- Groupe de ressources Kubernetes à déployer ensemble
+- Définies de manière déclarative
+- Peuvent être liées à différentes sources (Git, Helm)
+
+### 2. Projets
+- Regroupement logique d'applications
+- Permet de définir des restrictions et des permissions
+- Isolation des ressources par équipe/environnement
+
+### 3. Synchronisation
+- Automatique ou manuelle
+- Détection des dérives de configuration
+- Rollback automatique possible
+
+## Exemple de Configuration
+
+```yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: mon-app
+  namespace: argocd
+spec:
+  project: default
+  source:
+    repoURL: https://github.com/mon-org/mon-app.git
+    targetRevision: HEAD
+    path: k8s
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: production
+```
+
+## Bonnes Pratiques
+
+1. **Structure des Repositories**
+   - Séparer le code applicatif des manifestes Kubernetes
+   - Utiliser des branches pour les différents environnements
+
+2. **Sécurité**
+   - Implémenter RBAC strict
+   - Utiliser des secrets externes
+   - Activer SSO quand possible
+
+3. **Monitoring**
+   - Configurer des alertes sur les échecs de synchronisation
+   - Surveiller les métriques ArgoCD
+   - Mettre en place des notifications
+
+## Pour Aller Plus Loin
+
+- Documentation officielle : https://argo-cd.readthedocs.io/
+- Projets complémentaires :
+  - Argo Rollouts pour les déploiements avancés
+  - Argo Events pour l'event-driven
+  - Argo Workflows pour l'orchestration
+
diff --git a/cours/containers/kubernetes/k8s-core-api-objects.fr.md b/cours/containers/kubernetes/k8s-core-api-objects.fr.md
@@ -60,6 +60,7 @@ metadata:
   name: nginx
   labels:
     app: nginx
+    env: prod
 spec:
   containers:
   - name: nginx
@@ -133,8 +134,7 @@ metadata:
   name: test-ingress
   annotations:
     nginx.ingress.kubernetes.io/rewrite-target: /
-    cert-manager.io/cluster-issuer: theClusterIssuer
-    kubernetes.io/tls-acme: "true"
+    cert-manager.io/cluster-issuer: theClusterIssuer 
 spec:
   rules:
   - http:
@@ -216,7 +216,7 @@ yy-ss7nk              1/1     Running   0          84m   10.244.0.5   kind-cp
 
 ### Kubernetes : `Pod`
 
-dans les statuts du pod on trouve la notion de Conditions d'état des pods
+Dans les statuts du pod on trouve la notion de Conditions d'état des pods
 
 - Conditions :
     - `PodScheduled`: Un nœud a été sélectionné avec succès pour "lancer" le pod, et la planification est terminée.
@@ -257,6 +257,15 @@ Les containers peuvent avoir seulement 3 états
 $ kubectl get pods <POD_NAME> -o jsonpath='{.status}' | jq
 ```
 
+
+### Kubernetes : `Pod`
+
+
+![](images/kubernetes/kubernetes-pod.png){height="400px"}
+
+
+
+
 ### Kubernetes : `Deployment`
 
 - Permet d'assurer le fonctionnement d'un ensemble de Pods
@@ -291,7 +300,7 @@ spec:
         - containerPort: 80
 ```
 
-ou en ligne de commande
+Ou en ligne de commande
 
 ```bash
 kubectl create deployment my-app --image=nginx:latest --replicas=3
@@ -609,9 +618,9 @@ spec:
 
 - Lors du démarrage d'un Pod, le kubelet retarde l'exécution des conteneurs d'initialisation jusqu'à ce que le réseau et le stockage soient prêts. Ensuite, le kubelet exécute les conteneurs d'initialisation du Pod dans l'ordre où ils apparaissent dans la spécification du Pod.
 - Chaque conteneur d'initialisation doit se terminer avec succès avant que le suivant ne démarre. 
-- Si un conteneur ne parvient pas à démarrer en raison de l'environnement d'exécution ou se termine avec un échec, il est relancé conformément à la **restartPolicy** du Pod. Cependant, si la **restartPolicy** du Pod est définie sur **Always**, les conteneurs d'initialisation utilisent la restartPolicy OnFailure.
-- Un Pod ne peut pas être **Ready** tant que tous les conteneurs d'initialisation n'ont pas réussi. Les ports d'un conteneur d'initialisation ne sont pas agrégés sous un Service. 
-- Un Pod en cours d'initialisation est dans l'état **Pending** mais doit avoir une condition **Initialized** définie à false.
+- Si un conteneur ne parvient pas à démarrer en raison de l'environnement d'exécution ou se termine avec un échec, il est relancé conformément à la `restartPolicy` du Pod. Cependant, si la `restartPolicy` du Pod est définie sur `Always`, les conteneurs d'initialisation utilisent la restartPolicy OnFailure.
+- Un Pod ne peut pas être `Ready` tant que tous les conteneurs d'initialisation n'ont pas réussi. Les ports d'un conteneur d'initialisation ne sont pas agrégés sous un Service. 
+- Un Pod en cours d'initialisation est dans l'état `Pending` mais doit avoir une condition `Initialized` définie à false.
 - Si le Pod redémarre, ou est redémarré, tous les conteneurs d'initialisation doivent s'exécuter à nouveau.
 
 - Utilisations possibles

diff --git a/cours/containers/kubernetes/k8s-networking.fr.md b/cours/containers/kubernetes/k8s-networking.fr.md
@@ -4,11 +4,15 @@
 
 - Kubernetes n'implémente pas de solution de gestion de réseau par défaut
 - Le réseau est implémenté par des solutions tierces:
+    - [Antrea](https://antrea.io/) : Open vSwitch dans kubernetes
     - [Calico](https://www.projectcalico.org/): IPinIP + BGP
     - [Cilium](https://cilium.io/): eBPF
     - [Weave](https://www.weave.works/)
+    - [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) : Flannel + Calico
+    - [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) : Multi Plugins
     - Bien [d'autres](https://kubernetes.io/docs/concepts/cluster-administration/networking/)
 
+
 ### Kubernetes : CNI
 
 - [Container Network Interface](https://github.com/containernetworking/cni)
@@ -36,14 +40,10 @@
 
 ### Kubernetes : Services
 
-Service de type Spécial `LoadBalancer` : 
 
-- Load Balancing : intégration avec des cloud provider :
-    - AWS ELB
-    - GCP
-    - Azure Kubernetes Service
-    - OpenStack
-    - ...
+![pod network](images/kubernetes/k8s_service.jpg)
+
+
 
 ### Kubernetes : Services : ClusterIP
 
@@ -177,6 +177,14 @@ kubectl expose deploy web --type NodePort --protocol TCP --port 80 --target-port
 
 ### Kubernetes : Services : LoadBalancer
 
+Service de type Spécial
+
+- Load Balancing : intégration avec des cloud provider :
+    - AWS ELB
+    - GCP
+    - Azure Kubernetes Service
+    - OpenStack
+    - ...
 
 ```yaml
 apiVersion: v1
@@ -280,7 +288,19 @@ kubectl expose deploy nginx --port=80 --external-ip=1.2.3.4
 
 ```
 
-
+### Kubernetes : Services Résumé
+
+- `ClusterIP` : C'est le type de service par défaut. Il fournit une IP virtuelle stable accessible uniquement à l'intérieur du cluster, parfait pour la communication entre microservices.
+
+- `NodePort` : Il étend ClusterIP en exposant le service sur un port spécifique de chaque nœud du cluster. C'est utile pour le développement ou les environnements de test.
+
+- `LoadBalancer` : Idéal pour la production, il étend NodePort en provisionnant automatiquement un load balancer externe (souvent fourni par le cloud provider).
+
+- `ExternalName` : Un cas particulier qui permet de créer un alias CNAME vers un service externe au cluster.
+
+- `Headless Service` : Utilisé quand vous avez besoin d'une découverte de service fine, sans Load Balancing. Très utile pour les bases de données distribuées.
+
+- `ExternalIPs` : Permet d'exposer un service Kubernetes sur une adresse IP spécifique qui existe déjà sur l'un des nœuds du cluster, offrant ainsi un accès direct depuis l'extérieur sans passer par un LoadBalancer.
 
 ### Kubernetes : Services Discovery
 
@@ -394,8 +414,9 @@ Il existe plusieurs solutions OSS ou non :
 - 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`. 
+⚠︎ 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 l'attribut `ingressClassName`. 
 
 Ces classes sont créees au moment de l'installation du contrôleur.
 
@@ -404,3 +425,47 @@ Les **Ingress** vont bientôt être dépréciés en faveur des `Gateway API` qui
 Plus d'informations ici : <https://gateway-api.sigs.k8s.io/>
 
 
+### Kubernetes : Gateway API
+
+Les Gateway APIs sont une évolution des Ingress Controllers, offrant une approche plus moderne et flexible pour gérer le trafic entrant dans un cluster Kubernetes. Voici les points essentiels :
+
+Architecture en layers:
+
+- GatewayClass : Définit l'implémentation (comme NGINX, Traefik, etc.)
+- Gateway : Instance spécifique qui gère le trafic entrant
+- Route : Définit les règles de routage (HTTP, TCP, etc.)
+
+
+Avantages principaux:
+
+    - Configuration plus fine et granulaire
+    - Support natif de plusieurs protocoles
+    - Meilleure séparation des responsabilités
+    - API plus extensible et cohérente
+
+
+Cas d'utilisation:
+
+    - Multi-tenancy avec isolation du trafic
+    - Gestion avancée du routage
+    - Configuration du TLS
+    - Gestion du trafic nord-sud et est-ouest
+
+
+Différence avec les Ingress:
+
+Les Gateway APIs offrent plus de fonctionnalités que les Ingress traditionnels :
+
+    - Support multi-protocole natif
+    - Meilleure extensibilité
+    - Configuration plus détaillée
+    - Meilleure séparation des rôles
+
+
+### Kubernetes : Gateway API
+
+![](images/kubernetes/gateway-api-resources.png)
+
+
+
+En savoir plus :[Evolving Kubernetes networking with the Gateway API](https://kubernetes.io/blog/2021/04/22/evolving-kubernetes-networking-with-the-gateway-api/)
diff --git a/cours/containers/kubernetes/k8s-operations.fr.md b/cours/containers/kubernetes/k8s-operations.fr.md
@@ -235,3 +235,13 @@ kubectl example deploy
 Liste des plugins : <https://krew.sigs.k8s.io/plugins/>
 
 
+très utiles 
+
+- `neat` : permet de d'avoir un ouput "propre" d'une resource kubernetes - très utile pour créer des manifestes à partir de resources existantes
+- `ctx` : permet de changer de contexte facilement
+- `ns` : permet de changet de namespace facilement
+- `node-shell` : Créer un shell racine sur un nœud via kubectl, très pratique sur les CSP
+- `df-pv` : Afficher l'utilisation du disque (comme la commande df) pour les volumes persistants
+- `popeye` : Analyse vos clusters pour détecter d'éventuels problèmes de ressources
+
+
diff --git a/cours/containers/kubernetes/k8s-security.fr.md b/cours/containers/kubernetes/k8s-security.fr.md
@@ -2,14 +2,37 @@
 
 ### Authentication & Autorisation
 
-- RBAC (Role Based Access Control)
-- ABAC (Attribute-based access control)
-- WebHook
-- Certificates
-- Token
 
+### Authentication 
 
-### RBAC
+Authentication (Qui êtes-vous ?):
+
+- Vérifie l'identité de l'utilisateur
+- Méthodes principales :
+
+    - Certificats clients X.509
+    - Tokens Bearer (JWT)
+    - Service Accounts pour les pods
+    - OpenID Connect / OAuth2
+    - Fichiers de configuration statiques
+
+**Résultat** : identité confirmée ou requête rejetée
+
+
+
+### RBAC (Autorisation)
+
+
+Authorization (Que pouvez-vous faire ?):
+
+- Vérifie les permissions de l'utilisateur authentifié
+- Utilise principalement RBAC (Role-Based Access Control)
+- Composants clés :
+
+    - Roles : définissent les permissions dans un namespace
+    - ClusterRoles : permissions à l'échelle du cluster
+    - RoleBindings : lient les rôles aux utilisateurs dans un namespace
+    - ClusterRoleBindings : lient les rôles aux utilisateurs au niveau cluster
 
 3 entités sont utilisées :
 
@@ -18,6 +41,13 @@
 - les différentes opérations possibles : `create, list, get, delete, watch, patch`
 
 
+### RBAC
+
+- L'authentification précède toujours l'autorisation
+- Une requête doit passer les deux contrôles pour être acceptée
+- Les deux mécanismes sont indépendants mais complémentaires
+- RBAC est le standard de facto pour l'autorisation dans Kubernetes
+
 ![](images/kubernetes/rbac.svg){height="250px"}
 
 
@@ -127,6 +157,11 @@ kubectl auth can-i get pods /
 ```
 
 
+### NetworkPolicies
+
+![](images/kubernetes/Secure-Your-Kubernetes-Cluster-1024x586.png)
+
+
 ### 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