☸️ Kubernetes – Concepts, Installation & Déploiement

Problèmes résolus par K8s

SCÉNARIO 1: Serveur en panne
Sans K8s: Votre app est down à 3h du matin. Vous recevez une alerte.
Avec K8s: Le nœud est marqué "NotReady". K8s redéploie automatiquement les conteneurs sur les nœuds sains. L'app continue de fonctionner sans interruption de service.

SCÉNARIO 2: Pic de trafic (Black Friday)
Sans K8s: Votre serveur sature (100% CPU). Vous devez provisionner un nouveau serveur, le configurer, déployer l'app, configurer le load balancer. (Temps: 2h)
Avec K8s: `kubectl scale deployment/mon-app --replicas=10`. (Temps: 15 secondes). Ou K8s le fait pour vous (Horizontal Pod Autoscaler).

SCÉNARIO 3: Mise à jour (V2)
Sans K8s: Downtime planifié. Vous arrêtez V1, déployez V2. Si V2 bug, vous re-déployez V1 (rollback manuel).
Avec K8s: "Rolling Update". K8s déploie V2 progressivement (1 pod, puis 2, etc.) tout en arrêtant V1. Si V2 échoue (health checks), K8s stoppe le déploiement et fait un rollback automatique vers V1. Zéro downtime.

Le Control Plane (Le Cerveau)

Le Control Plane prend les décisions globales du cluster (ex: planifier les pods) et maintient l'état désiré. Il n'exécute pas les conteneurs applicatifs.

En production, le Control Plane est "HA" (Haute Dispo) avec 3 ou 5 masters pour la redondance d'etcd.

Les Worker Nodes (Les Muscles)

Les Workers sont les machines (VMs ou physiques) qui exécutent les charges de travail (vos conteneurs applicatifs).

2. Deployment : Le gestionnaire

Vous ne créez (presque) jamais de Pods manuellement. Vous créez un **Deployment**.

Un Deployment est un objet qui décrit un **état désiré** (ex: "Je veux 3 Pods de mon app-nginx"). Il gère un ReplicaSet qui, lui, gère la création/destruction des Pods.

Avantages

• Rolling Updates : Déployer une nouvelle version sans downtime.
• Rollbacks : Revenir à une version précédente si la nouvelle bug.
• Scaling : kubectl scale deployment --replicas=5.

               [kubectl scale --replicas=3]
                            ▼
+-------------------------------------------------------+
| Deployment (mon-app)                                  |
|  "Je veux 3 replicas de l'image nginx:1.21"           |
|                                                       |
|  +-------------------------------------------------+  |
|  | ReplicaSet (mon-app-7f... - Géré par Deployment)  |
|  |  "Je m'assure qu'il y a 3 Pods"                   |
|  |                                                 |
|  |  +-------+   +-------+   +-------+              |
|  |  | Pod 1 |   | Pod 2 |   | Pod 3 |              |
|  |  +-------+   +-------+   +-------+              |
|  +-------------------------------------------------+  |
+-------------------------------------------------------+

3. Service : L'adresse stable

Problème : Les Pods sont éphémères. Si un Pod meurt, le Deployment le remplace par un nouveau... avec une nouvelle IP. Comment les autres Pods peuvent-ils le trouver ?

Le **Service** est une abstraction réseau qui fournit une **adresse IP stable** et un **nom DNS** pour un groupe de Pods.

               [Requête vers 'http://mon-service']
                            ▼
+-------------------------------------------------------+
| Service (mon-service) (IP: 10.96.0.10 - STABLE)       |
|  (Selector: app=mon-app)                              |
|                                                       |
|  (Redirige le trafic vers les Pods sains)             |
|        /                 |                 \          |
|       ▼                  ▼                  ▼         |
|  +-------+          +-------+          +-------+      |
|  | Pod 1 |          | Pod 2 |          | Pod 3 |      |
|  | (IP: 10.1.1.2)   | (IP: 10.1.1.3)   | (IP: 10.1.2.2) |
|  +-------+          +-------+          +-------+      |
+-------------------------------------------------------+

Le Service utilise un **Selector** (des labels) pour savoir à quels Pods envoyer le trafic.

Autres objets de "Workload"

kind (Kubernetes in Docker)

kind est un outil plus récent qui exécute un cluster K8s (y compris multi-nœuds) **à l'intérieur de conteneurs Docker**. C'est très léger et rapide. Très populaire pour la CI/CD.

Installation (exemple Linux)

# 1. Installer 'kind'
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# 2. Créer un cluster
kind create cluster --name dev-cluster

# 3. Charger le kubeconfig
kind get kubeconfig --name dev-cluster > ~/.kube/config-kind
export KUBECONFIG=~/.kube/config-kind

# 4. Vérifier
kubectl get nodes

Cluster Multi-nœuds

Créez un fichier kind-config.yml :

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

kind create cluster --config kind-config.yml

Docker Desktop (Le plus simple)

Si vous avez Docker Desktop (Windows ou Mac), il inclut un cluster K8s mono-nœud.

Activation

1. Ouvrez Docker Desktop.
2. Allez dans Settings (Préférences).
3. Allez dans la section Kubernetes.
4. Cochez "Enable Kubernetes".
5. Cliquez sur "Apply & Restart".

Docker Desktop s'occupe de tout (installation, kubectl, configuration du contexte).

Changer de contexte

kubectl doit savoir à quel cluster parler (Docker, Minikube, GKE...).

# Lister les contextes
kubectl config get-contexts

# Changer pour le contexte Docker
kubectl config use-context docker-desktop

Fichier ~/.kube/config

kubectl trouve les informations de connexion (API Server, certificats, tokens) dans un fichier YAML appelé config, situé dans $HOME/.kube/.

Ce fichier gère plusieurs **Contextes** (ex: dev, prod, local).

# Lister tous les contextes
kubectl config get-contexts

CURRENT   NAME              CLUSTER         AUTHINFO        NAMESPACE
* docker-desktop    docker-desktop  docker-desktop
          gke_my-project_... gke_my-project_... gke_my-project_...
          minikube          minikube        minikube        default

# Voir le contexte actuel
kubectl config current-context

# Changer de contexte (pour parler au cluster GKE)
kubectl config use-context gke_my-project_...

# Changer de contexte (pour revenir au local)
kubectl config use-context docker-desktop

Les outils (Minikube, kind, gcloud, az) mettent à jour ce fichier automatiquement pour vous.

Autocomplétion (Bash & Zsh)

Ceci est **essentiel** pour être productif. Cela vous permet d'appuyer sur [TAB] pour compléter les commandes, les types d'objets et les noms de vos Pods/Services.

Activation (Bash)

# Installer bash-completion
sudo apt-get install bash-completion

# Ajouter à votre .bashrc
echo 'source <(kubectl completion bash)' >>~/.bashrc
source ~/.bashrc

Activation (Zsh)

# Ajouter à votre .zshrc
echo 'source <(kubectl completion zsh)' >>~/.zshrc
source ~/.zshrc

Exemples d'utilisation

kubectl g [TAB]
# Affiche: get
kubectl get po [TAB]
# Affiche: pods
kubectl get pods mon-app-web-12345 [TAB]
# (Aucune complétion, car c'est le nom complet)
kubectl logs mon-app-web- [TAB]
# Affiche: mon-app-web-12345 (complète le nom du pod)

GKE (Google Kubernetes Engine)

Considéré comme le plus mature et le plus simple (K8s vient de Google).

Prérequis

# Installer Google Cloud CLI
gcloud components install gke-gcloud-auth-plugin

Création d'un cluster (Autopilot)

Autopilot est un mode GKE "serverless" où vous ne gérez *même pas* les nœuds. Vous payez au Pod.

gcloud container clusters create-auto mon-cluster-autopilot \
    --region=europe-west1

# Récupérer les credentials (met à jour le kubeconfig)
gcloud container clusters get-credentials mon-cluster-autopilot \
    --region=europe-west1

# Vérifier
kubectl get nodes

EKS (Amazon Elastic Kubernetes Service)

Intégration profonde avec l'écosystème AWS (IAM, VPC, ELB).

Prérequis

# Installer AWS CLI
# Installer eksctl (l'outil simple pour EKS)
brew install eksctl

Création d'un cluster (via eksctl)

# Crée un cluster (CloudFormation) et 2 nœuds m5.large
eksctl create cluster \
    --name mon-cluster-eks \
    --region=eu-west-3 \
    --nodegroup-name=nodes-standards \
    --node-type=t3.medium \
    --nodes=2

# (Prend 10-15 minutes)
# eksctl met à jour le kubeconfig automatiquement

# Vérifier
kubectl get nodes

AKS (Azure Kubernetes Service)

L'offre K8s managée de Microsoft Azure.

Prérequis

# Installer Azure CLI
az login

Création d'un cluster

# 1. Créer un groupe de ressources
az group create --name ResGroup-AKS --location westeurope

# 2. Créer le cluster
az aks create \
    --resource-group ResGroup-AKS \
    --name mon-cluster-aks \
    --node-count 2 \
    --enable-managed-identity \
    --generate-ssh-keys

# 3. Récupérer les credentials
az aks get-credentials --resource-group ResGroup-AKS --name mon-cluster-aks

# 4. Vérifier
kubectl get nodes

Anatomie d'un manifeste K8s

Tous les fichiers YAML K8s ont 4 champs principaux :

apiVersion: [Version de l'API à utiliser]
kind: [Type d'objet à créer]
metadata: [Infos sur l'objet (nom, labels...)]
spec: [La "spécification" de l'objet (son état désiré)]

Exemple : Pod Nginx (pod.yml)

Ceci est la définition la plus simple d'un Pod. (Rappel : en pratique, on utilise un Deployment).

# apiVersion 'v1' pour les objets "core"
apiVersion: v1

# kind 'Pod'
kind: Pod

metadata:
  name: mon-pod-nginx
  labels:
    app: serveur-web # Label pour les Services
    env: dev

spec:
  # 'spec' d'un Pod contient une liste de conteneurs
  containers:
  
  # Premier (et unique) conteneur
  - name: nginx-container
    image: nginx:1.22
    ports:
      - containerPort: 80 # Port exposé par le conteneur
    
    # Limites de ressources (bonne pratique)
    resources:
      requests: # Quantité garantie
        memory: "64Mi"
        cpu: "250m" # 0.25 vCPU
      limits: # Plafond maximum
        memory: "128Mi"
        cpu: "500m"

kubectl apply vs kubectl create

Cette distinction est cruciale pour les débutants.

kubectl create -f mon-fichier.yml

• Impératif.
• Tente de créer la ressource.
• Si la ressource (ex: name: mon-pod) existe déjà, cela échoue avec une erreur "AlreadyExists".
• À n'utiliser que si vous êtes certain que l'objet n'existe pas.

kubectl apply -f mon-fichier.yml (La bonne méthode)

• Déclaratif.
• Regarde l'API Server si l'objet existe.
  • S'il n'existe pas : le crée (comme create).
  • S'il existe déjà : K8s calcule la différence (un "diff") entre le YAML et l'état actuel, et n'applique que les changements.
• C'est la commande idempotente à utiliser 99% du temps, notamment en CI/CD.

Supprimer

# Supprime l'objet créé par le fichier
kubectl delete -f mon-fichier.yml

Schéma d'un Rolling Update (maxSurge=1, maxUnavailable=0)

Vous appliquez un YAML avec image: mon-image:v2.0.

ÉTAT INITIAL (replicas=3)
Service -> [ V1 ] [ V1 ] [ V1 ]

ÉTAPE 1 (maxSurge=1)
K8s ajoute 1 Pod V2. Total = 4 Pods (3+1)
Service -> [ V1 ] [ V1 ] [ V1 ] [ V2 (starting) ]

ÉTAPE 2 (readinessProbe V2 OK)
K8s ajoute V2 au Service.
Service -> [ V1 ] [ V1 ] [ V1 ] [ V2 (Ready) ]

ÉTAPE 3 (maxUnavailable=0)
K8s supprime 1 Pod V1. Total = 3 Pods.
Service -> [ V1 ] [ V1 ] [ V2 ]

ÉTAPE 4
K8s ajoute 1 Pod V2. Total = 4 Pods.
Service -> [ V1 ] [ V1 ] [ V2 ] [ V2 (starting) ]

ÉTAPE 5 (readinessProbe V2 OK)
K8s supprime 1 Pod V1. Total = 3 Pods.
Service -> [ V1 ] [ V2 ] [ V2 ]

... (processus répété)

ÉTAT FINAL
Service -> [ V2 ] [ V2 ] [ V2 ]

Si le readinessProbe du Pod V2 échoue, K8s arrête le déploiement et (selon config) peut déclencher un rollback.

Gérer les Deployments

# Appliquer un changement (ex: changer l'image dans le YAML)
kubectl apply -f deployment.yml

# Voir le statut du déploiement
kubectl rollout status deployment/mon-app-deployment

# Mettre à l'échelle (scaling)
kubectl scale deployment/mon-app-deployment --replicas=5

# Mettre à l'échelle automatiquement (HPA)
# (Nécessite le Metrics Server)
kubectl autoscale deployment/mon-app-deployment --cpu-percent=80 --min=3 --max=10

# Voir l'historique des versions
kubectl rollout history deployment/mon-app-deployment

# Revenir à la version précédente (Rollback)
kubectl rollout undo deployment/mon-app-deployment

# Revenir à une version spécifique (ex: 3)
kubectl rollout undo deployment/mon-app-deployment --to-revision=3

DaemonSet (Un Pod par Nœud)

Un DaemonSet garantit qu'une copie d'un Pod s'exécute sur **tous** (ou un sous-ensemble) les nœuds du cluster. Si vous ajoutez un nœud, le DaemonSet y ajoute automatiquement le Pod.

Cas d'usage typiques

• Agents de Logging : (ex: Fluentd, Logstash) pour collecter les logs de *chaque* nœud.
• Agents de Monitoring : (ex: Prometheus Node Exporter, Datadog Agent) pour collecter les métriques de *chaque* nœud.
• Réseau/Stockage : (ex: Calico, Ceph) pour gérer le CNI ou le stockage distribué sur *chaque* nœud.

# Extrait YAML d'un DaemonSet (pour un agent de log)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-agent
spec:
  selector:
    matchLabels:
      name: fluentd-agent
  template:
    metadata:
      labels:
        name: fluentd-agent
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-k8s:v1
        
        # Monte les logs du NŒUD HÔTE dans le conteneur
        volumeMounts:
        - name: varlog
          mountPath: /var/log
          
      volumes:
      - name: varlog
        hostPath: # Accède au filesystem de l'hôte
          path: /var/log

1. ClusterIP (Défaut)

Expose le Service sur une adresse IP **interne** au cluster. C'est le type par défaut.

Usage : Communication interne (ex: un frontend web qui parle à un backend API, ou une API qui parle à une BDD). Le service n'est **pas accessible** depuis l'extérieur du cluster.

type: ClusterIP

[Internet] -X-> [Service ClusterIP]
                   |
[Pod Frontend] ->--+--> [Pods Backend]

2. NodePort (Externe simple)

Expose le Service sur un port statique (ex: 30000-32767) sur **l'IP de chaque Worker Node**.

Usage : Développement, démo, ou cas où vous gérez votre propre Load Balancer externe. Un service NodePort crée *aussi* un ClusterIP.

type: NodePort
# nodePort: 30080 (optionnel, K8s en choisit un sinon)

[Internet] -> http://[IP_DU_NODE]:30080 -> [Service NodePort] -> [Pods Backend]

Inconvénient : Vous devez connaître l'IP d'au moins un nœud, et le port est dans une plage élevée.

3. LoadBalancer (Externe Cloud)

Le type le plus courant pour exposer une application sur Internet. Expose le Service en utilisant le **Load Balancer du fournisseur Cloud** (GCP, AWS, Azure).

Usage : Production. Un service LoadBalancer crée *aussi* un NodePort et un ClusterIP.

type: LoadBalancer

[Internet] -> http://[IP_PUBLIQUE_DU_LB] -> [Service LB] -> [Pods Backend]
               (Provisionnée par AWS/GCP/Azure)

K8s parle à l'API du Cloud, provisionne un LB, et configure les règles pour router le trafic vers les NodePorts des nœuds.

Secret (Configuration sensible)

Similaire à un ConfigMap, mais conçu pour les données sensibles (mots de passe, clés d'API, certificats TLS). Les données sont stockées en **Base64** dans etcd.

Attention : Base64 n'est *pas* du chiffrement, c'est de l'encodage. C'est juste pour éviter que le secret soit lisible à l'œil nu. La vraie sécurité vient de RBAC (qui peut *lire* le Secret) et du chiffrement etcd au repos.

Exemple YAML (secret.yml)

apiVersion: v1
kind: Secret
metadata:
  name: mon-app-secret
type: Opaque # Type par défaut (données arbitraires)
data:
  # Les valeurs DOIVENT être en Base64
  # echo -n 'mon-super-pass' | base64
  DB_PASSWORD: "bW9uLXN1cGVyLXBhc3M="
  # echo -n 'admin' | base64
  DB_USER: "YWRtaW4="

Création impérative

kubectl create secret generic db-secret \
  --from-literal=DB_USER=admin \
  --from-literal=DB_PASSWORD=mon-super-pass

Utilisation dans un Pod

Il y a deux façons principales d'exposer un ConfigMap ou un Secret à un Pod :

apiVersion: v1
kind: Pod
metadata:
  name: pod-avec-config
spec:
  containers:
  - name: mon-app
    image: mon-image
    
    # 1. En tant que Variables d'Environnement
    env:
      - name: MON_APP_URL # Nom de la variable
        valueFrom:
          configMapKeyRef:
            name: mon-app-config # Nom du ConfigMap
            key: API_URL        # Clé dans le ConfigMap
            
      - name: DATABASE_PASS
        valueFrom:
          secretKeyRef:
            name: mon-app-secret # Nom du Secret
            key: DB_PASSWORD    # Clé dans le Secret

    # 2. En tant que Fichier (monté en volume)
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config # Le fichier 'config.properties' sera ici
      
  volumes:
  - name: config-volume
    configMap:
      name: mon-app-config # Monte TOUT le ConfigMap
      items:
      - key: config.properties # Monte juste cette clé
        path: config.properties # sous ce nom de fichier

PersistentVolume (PV) & PersistentVolumeClaim (PVC)

K8s abstrait le stockage (EBS, GCE Disk, NFS...) via deux objets :

• PersistentVolume (PV) : Une "part" de stockage dans le cluster. C'est l'**Offre** de stockage, généralement créée par l'Admin. (ex: "J'ai un disque NFS de 100Go").
• PersistentVolumeClaim (PVC) : Une **Demande** de stockage faite par un utilisateur/Pod. (ex: "Mon Pod a besoin de 10Go de stockage rapide").

K8s fait le "matching" (binding) entre un PVC et un PV compatible.

ADMINISTRATEUR
+----------------------------+
| PersistentVolume (PV)      |
| "Offre: 100Gi, NFS, 'slow'" |
+----------------------------+
+----------------------------+
| PersistentVolume (PV)      |
| "Offre: 50Gi, SSD, 'fast'"  |
+----------------------------+
       |
       | K8s "bind" (lie)
       |
UTILISATEUR (Développeur)
+----------------------------+
| PersistentVolumeClaim (PVC)|
| "Demande: 10Gi, 'fast'"    |
+----------------------------+
       |
       | (Utilisé par le Pod)
       ▼
+----------------------------+
| Pod (ex: BDD PostgreSQL)   |
+----------------------------+

Le développeur n'a pas besoin de savoir ce qu'est "EBS" ou "GCE Disk". Il demande juste "10Gi fast", et K8s s'occupe de lui fournir le bon PV.

Exemple : PVC et Pod

1. pvc.yml (La Demande)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mon-pvc-data
spec:
  accessModes:
    - ReadWriteOnce # Montable en R/W par 1 seul nœud
    # ReadWriteMany (NFS)
    # ReadOnlyMany
  resources:
    requests:
      storage: 5Gi # Je demande 5 Giga
  # storageClassName: "fast" # (Optionnel) demande un type spécifique

2. pod-db.yml (Le Consommateur)

apiVersion: v1
kind: Pod
metadata:
  name: postgres-db
spec:
  containers:
  - name: postgres
    image: postgres:15
    ports:
    - containerPort: 5432
    volumeMounts:
    - name: data-storage
      # Monte le volume dans le répertoire de données de Postgres
      mountPath: /var/lib/postgresql/data
      
  volumes:
  - name: data-storage
    # Ce volume utilise le PVC
    persistentVolumeClaim:
      claimName: mon-pvc-data

StorageClass (Provisionnement Dynamique)

Créer des PV manuellement est fastidieux. Les **StorageClasses** permettent le **provisionnement dynamique**.

L'admin définit une "StorageClass" (ex: "ssd-fast" qui pointe vers GCE PD-SSD, ou "hdd-slow" qui pointe vers GCE PD-Standard).

# Exemple de StorageClass (Cloud)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/gce-pd # Provisionneur GKE
parameters:
  type: pd-ssd # Type de disque Google

Quand un utilisateur crée un PVC demandant la StorageClass "fast-ssd", K8s appelle l'API Google, **crée un disque SSD GCE** (le PV) à la volée, et le lie au PVC. Tout est automatique.

L'Ingress Controller (Le moteur)

Créer un objet kind: Ingress (le YAML) ne fait **RIEN** tout seul.

Un objet Ingress est une "règle de routage". Vous avez besoin d'un **Ingress Controller** (un vrai logiciel qui tourne dans un Pod) pour lire ces règles et appliquer la configuration.

Le Controller n'est (souvent) pas installé par défaut.

Contrôleurs populaires

• Ingress-Nginx : Le plus populaire, maintenu par K8s (utilise Nginx).
• Traefik : Très populaire, moderne, gère le SSL (Let's Encrypt) automatiquement.
• Contrôleurs Cloud : GKE/AWS/Azure ont leurs propres Ingress Controllers qui provisionnent des LB L7 (ex: Google Cloud Load Balancer).

Installation (exemple Nginx Ingress via Helm)

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install nginx-ingress ingress-nginx/ingress-nginx \
    --namespace ingress-nginx \
    --create-namespace

Ceci va créer un Deployment (le contrôleur) et un Service de type LoadBalancer pour l'exposer.

Exemple : ingress.yml

Ce YAML définit les règles de routage (après avoir installé un Ingress Controller).

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mon-ingress
  annotations:
    # Annotation spécifique au contrôleur (ici Nginx)
    nginx.ingress.kubernetes.io/rewrite-target: /
    # Annotation pour le SSL (si cert-manager est installé)
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  # Classe d'Ingress (dit quel contrôleur utiliser)
  ingressClassName: nginx
  
  # Gestion du TLS (HTTPS)
  tls:
  - hosts:
    - api.monsite.com
    - blog.monsite.com
    secretName: monsite-tls-secret # Secret (kind: Secret) contenant le cert/key
    
  rules:
  # Règle 1: Routage basé sur l'hôte
  - host: "api.monsite.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service # Service (ClusterIP)
            port:
              number: 80
              
  # Règle 2: Autre hôte
  - host: "blog.monsite.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blog-wordpress-service
            port:
              number: 80

ServiceAccount (Identité pour les Pods)

Par défaut, un Pod s'exécute avec le ServiceAccount (SA) "default" du Namespace, qui n'a (presque) aucun droit.

Si un Pod a besoin de parler à l'API K8s (ex: un Pod Prometheus qui doit découvrir les Services), vous devez :

1. Créer un ServiceAccount (ex: sa-prometheus).
2. Créer un Role ou ClusterRole avec les permissions (ex: role-prometheus avec "get/list Services").
3. Créer un RoleBinding qui lie sa-prometheus à role-prometheus.
4. Attacher le ServiceAccount au Pod (spec.serviceAccountName: sa-prometheus).

Exemple : Role (Namespace "dev")

Autorise la lecture des Pods dans le NS "dev".

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
- apiGroups: [""] # "" = Core API group
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

Exemple : RoleBinding (Namespace "dev")

Donne le Role "pod-reader" à l'utilisateur "jane.doe".

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jane-can-read-pods
  namespace: dev
subjects:
- kind: User
  name: "jane.doe" # Nom de l'utilisateur
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # Lie à un Role (pas ClusterRole)
  name: pod-reader # Nom du Role ci-dessus
  apiGroup: rbac.authorization.k8s.io

Métriques (CPU/RAM)

K8s intègre un **Metrics Server** (doit souvent être installé) qui collecte les métriques de base (CPU/RAM) des nœuds et des Pods.

Installation (Minikube)

minikube addons enable metrics-server

Commandes

# Voir l'utilisation CPU/RAM des Nœuds
kubectl top nodes
NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   350m         17%    1783Mi          45%

# Voir l'utilisation CPU/RAM des Pods
kubectl top pods -n kube-system
NAME                               CPU(cores)   MEMORY(bytes)
coredns-5dd...                     4m           10Mi
etcd-minikube                      18m          47Mi
kube-apiserver-minikube            60m          256Mi
kube-controller-manager-minikube   15m          42Mi

Ces métriques sont utilisées par le Horizontal Pod Autoscaler (HPA) pour le scaling automatique.

Stack Monitoring (Prometheus & Grafana)

Pour un monitoring avancé (métriques applicatives, dashboards, alertes), la stack standard est Prometheus + Grafana.

• Prometheus : La base de données Time-Series (TSDB). Elle "scrape" (collecte) les métriques exposées par vos applications (sur un endpoint /metrics).
• Grafana : L'outil de visualisation (dashboards) qui se connecte à Prometheus.
• Alertmanager : Gère les alertes (Slack, PagerDuty...) définies dans Prometheus.

[Grafana (Dashboards)] <--> [Prometheus (BDD Métriques)] <-- [Alertmanager]
                                |
                                | (Scrape /metrics)
                                ▼
+-------------------------------------------------------------+
| Cluster K8s                                                 |
|  [Pod App 1 (/metrics)] [Pod App 2 (/metrics)] [Nodes...]   |
+-------------------------------------------------------------+

Installation (via Helm)

# La stack "kube-prometheus-stack" installe tout (Prometheus, Grafana, Alertmanager)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install prometheus prometheus-community/kube-prometheus-stack \
    --namespace monitoring --create-namespace

Débogage

# Décrire un Pod (voir évènements, erreurs, volumes...)
# C'EST LA COMMANDE N°1 POUR LE DEBUG
kubectl describe pod [NOM-DU-POD]

# Décrire un Nœud (voir ressources, statut, Pods dessus)
kubectl describe node [NOM-DU-NODE]

# Voir les logs d'un Pod
kubectl logs [NOM-DU-POD]

# Suivre les logs d'un Pod
kubectl logs -f [NOM-DU-POD]

# Voir les logs du conteneur précédent (s'il a crashé)
kubectl logs --previous [NOM-DU-POD]

# Voir l'utilisation CPU/RAM (si Metrics Server installé)
kubectl top pods
kubectl top nodes

Gestion (Déclaratif)

# Appliquer un manifeste (créer ou mettre à jour)
kubectl apply -f mon-fichier.yml

# Appliquer tous les manifestes d'un dossier
kubectl apply -f ./mon-dossier/

# Supprimer les objets d'un manifeste
kubectl delete -f mon-fichier.yml

# Supprimer par nom
kubectl delete pod [NOM-POD]
kubectl delete service [NOM-SERVICE]

# Supprimer un pod sans attendre (force)
kubectl delete pod [NOM-POD] --grace-period=0 --force

Gestion (Impératif)

# Changer le nombre de replicas
kubectl scale deployment/mon-app --replicas=5

# Mettre à jour l'image d'un deployment
kubectl set image deployment/mon-app [NOM-CONTENEUR]=[NOUVELLE-IMAGE:TAG]

# Voir l'historique et faire un rollback
kubectl rollout status deployment/mon-app
kubectl rollout history deployment/mon-app
kubectl rollout undo deployment/mon-app

Interaction

# Ouvrir un shell dans un conteneur (comme docker exec)
kubectl exec -it [NOM-DU-POD] -- /bin/bash
# (Utiliser /bin/sh si bash n'existe pas)

# Exécuter une commande simple
kubectl exec [NOM-DU-POD] -- ls /app

# Copier des fichiers (local -> pod)
kubectl cp ./mon-fichier.txt [NOM-DU-POD]:/tmp/fichier.txt

# Copier des fichiers (pod -> local)
kubectl cp [NOM-DU-POD]:/app/logs.txt ./logs-app.txt

# Port-forward (local) -> Pod (debug)
# Accédez à http://localhost:8080 sur votre PC
kubectl port-forward pod/[NOM-DU-POD] 8080:80

# Port-forward (local) -> Service (debug)
kubectl port-forward service/[NOM-SERVICE] 8080:80