☸️ Partie 6 : Écosystème, Monitoring & Cas d'Usage

L'Observabilité dans Kubernetes (K8s) reprend les 3 piliers (Métriques, Traces, Logs)[cite: 22], mais adaptés à la nature dynamique des conteneurs.

Les solutions (SaaS) comme DataDog [cite: 22, 28] [cite_start]ou (Open Source) Prometheus+Grafana [cite: 22, 28] packagent ces outils.

Prometheus (Projet CNCF) est le standard "de-facto" pour le monitoring de K8s[cite: 22, 28]. Il est basé sur un modèle de "Pull" (Scraping).

Prometheus "scrape" (interroge) périodiquement un endpoint HTTP /metrics (exposé par les services) qui retourne des métriques au format texte.

Composants Clés (Stack "Kube-Prometheus")

• Prometheus Server : Le cœur. Scrape les endpoints, stocke les métriques (TSDB), et exécute les requêtes PromQL.
• Node Exporter : (DaemonSet) Expose les métriques du Nœud (Host) (node_cpu_seconds_total).
• kube-state-metrics : (Deployment) Expose les métriques de l'API K8s (ex: kube_deployment_spec_replicas).
• cAdvisor : (Inclus dans Kubelet) Expose les métriques des conteneurs (CPU/Mem).
• ServiceMonitor (CRD) : (La "magie") Une ressource K8s (CRD) qui dit à Prometheus : "Scrape automatiquement tous les Services qui ont le label app:mon-api".

Prometheus est une excellente base de données (TSDB) et un moteur de requêtes (PromQL), mais un piètre outil de visualisation (UI basique).

Grafana est l'outil de **visualisation (Dashboarding)** standard[cite: 22, 28]. Il se connecte à Prometheus (en tant que "Data Source").

Workflow (Stack "Prom-Stack" [cite: 28])

1. K8s (cAdvisor) expose /metrics.
2. Prometheus (Server) "scrape" /metrics.
3. Grafana (UI) est configuré avec Prometheus comme "Data Source".
4. Vous (l'utilisateur) créez un Dashboard dans Grafana qui exécute une requête PromQL (ex: rate(container_cpu_usage_seconds_total[5m])) contre Prometheus.

DataDog est l'alternative SaaS (payante) à la stack "Prometheus+Grafana+Fluentd+Jaeger" (Open Source)[cite: 22, 28].

Avantage : Tout-en-un (M-T-L), managé.

Installation (Helm Chart [cite: 28])

L'installation (vue en Partie 1) via le Helm Chart [cite: 28] est la méthode standard. Elle déploie :

• Un DaemonSet (l'Agent principal) : 1 Pod par Nœud. Il collecte les métriques du Nœud (Kubelet, cAdvisor), les logs stdout des Pods (via Autodiscovery), et reçoit les Traces APM (port 8126).
• Un Deployment (Cluster Agent) : Un agent "central" qui parle à l'API Server pour la collecte d'événements et (optionnellement) kube-state-metrics.

Autodiscovery (Annotations)

La clé est l'Autodiscovery. Vous "annotez" vos YAML de Deployment pour que l'Agent DataDog (le DaemonSet) sache comment gérer vos Pods.

# (deployment-api.yaml)
metadata:
  annotations:
    # 1. Dit à l'Agent de scraper les métriques Prometheus
    #    (si votre app expose /metrics)
    "ad.datadoghq.com/my-app.check_names": |
      ["openmetrics"]
    "ad.datadoghq.com/my-app.init_configs": |
      [{}]
    "ad.datadoghq.com/my-app.instances": |
      [
        {
          "prometheus_url": "http://%%host%%:8080/metrics",
          "namespace": "my_app",
          "metrics": ["*"]
        }
      ]
    # 2. Dit à l'Agent comment tagguer les logs stdout
    "ad.datadoghq.com/my-app.logs": |
      [
        {"service": "api-users", "source": "python"}
      ]

Comment déployer sur K8s ? [cite_start]L'écosystème inclut des outils de CI/CD[cite: 22].

(Dev -> 'git push')
     |
     ▼
+----------------+
| Jenkins (CI)   |
+----------------+
     | 1. Build Image
     | 2. Push Image (Registry)
     | 3. (Utilise son 'kubeconfig')
     |    kubectl apply -f ...
     ▼
+----------------+
| Cluster K8s    | (Accepte le 'apply')
+----------------+

(Dev -> 'git push' (sur le YAML))
     |
     ▼
+----------------+
| Dépôt Git      | (Source de Vérité)
+----------------+
     |
     | (4. Observe/Pull)
     ▲
+----------------+
| Cluster K8s    |
| +------------+ |
| | ArgoCD     | |
| +------------+ |
| (1. Voit un "diff")
| (2. Se synchronise)
| (3. `kubectl apply` (lui-même))
+----------------+

ArgoCD [cite: 22] (Projet CNCF) est l'outil GitOps (Modèle "Pull") le plus populaire.

Il s'installe dans K8s. Vous lui donnez l'URL d'un dépôt Git (qui contient vos YAMLs K8s). ArgoCD compare en permanence ce dépôt Git (l'État Désiré) avec ce qui tourne dans le cluster (l'État Actuel).

La CRD Application

Vous n'utilisez pas kubectl apply -f mon-deploy.yaml. Vous créez un objet Application (une Custom Resource Definition) qui dit à ArgoCD :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  
  # 1. La Source (Où est le Git ?)
  source:
    repoURL: "https://github.com/mon-repo/k8s-configs.git"
    targetRevision: HEAD
    path: "apps/my-app/prod" # (Le dossier des YAMLs)
    
  # 2. La Destination (Où déployer ?)
  destination:
    server: "https://kubernetes.default.svc"
    namespace: prod
    
  # 3. La Politique (Auto-Sync ?)
  syncPolicy:
    automated:
      prune: true    # (Supprime ce qui n'est plus dans Git)
      selfHeal: true # (Corrige les dérives manuelles)

L'UI d'ArgoCD vous montre alors l'état (Synced ou OutOfSync) de vos applications.

Deux outils CNCF dominent la sécurité (en complément du RBAC/NetworkPolicy)[cite: 22].

# (Ex: Étape de CI)
$ trivy image mon-app:1.2.0

# (Output:)
# ubuntu:22.04 (ubuntu 22.04)
# ===========================
# Total: 5 (HIGH: 2, CRITICAL: 3)
#
# +------------+------------------+----------+
# | LIBRARY    | VULNERABILITY ID | SEVERITY |
# +------------+------------------+----------+
# | openssl    | CVE-2023-1234    | CRITICAL |
# | ...        | ...              | ...      |
# +------------+------------------+----------+
#
# (La CI échoue, le build est bloqué)

Problème : K8s (Service, NetworkPolicy) gère le L4 (IP/Port). Mais comment gérer le L7 (HTTP/gRPC) ? (Ex: "Envoyer 10% du trafic vers v2", "Chiffrer (mTLS) tout le trafic entre Pods", "Retenter (retry) si /api/users échoue" ?).

Solution : Un Service Mesh (Maillage de Services) (ex: Istio [cite: 22][cite_start], Linkerd [cite: 22]).

Architecture (Sidecar Proxy)

Un Service Mesh **injecte automatiquement** un "sidecar" (un 2ème conteneur) (ex: istio-proxy (Envoy)) dans **chaque Pod** de votre application.

Tout le trafic réseau (entrant/sortant) du Pod applicatif est **intercepté** par ce proxy sidecar, qui gère alors (de manière transparente) :

• Sécurité : Chiffrement mTLS (mutuel) automatique entre tous les Pods.
• Observabilité L7 : Métriques (ex: "Taux d'erreur HTTP 5xx", "Latence p99") par endpoint (/api/users).
• Routage Avancé : "Traffic Splitting" (Canary, A/B), Retries, Timeouts.

Résumé des bonnes pratiques (issues de votre PDF [cite: 30]) vues dans les parties précédentes :

[cite_start]
• Helm/Kustomize[cite: 30]: (Voir 5.6) Utiliser le templating/patching. Ne pas appliquer de YAML "brut" en production.
[cite_start]
• Quotas[cite: 30]: (Voir 5.9) Appliquer des ResourceQuota (plafonds) aux namespaces (dev, staging) pour éviter les abus.
[cite_start]
• Probes[cite: 30]: (Voir 5.7) Toujours configurer des LivenessProbe et ReadinessProbe (httpGet) pour l'auto-réparation.
[cite_start]
• Autoscaling[cite: 30]: (Voir 5.8) Configurer des HorizontalPodAutoscaler (HPA) sur le CPU/Mémoire pour gérer la charge.
[cite_start]
• Namespaces séparés[cite: 30]: (Voir 3.7) Isoler prod, staging, dev.
[cite_start]
• RBAC[cite: 30]: (Voir 5.2) Ne *jamais* utiliser le ServiceAccount default. Créer des Rôles dédiés (principe de moindre privilège).
[cite_start]
• Supervision [cite: 30] [cite_start]: Mettre en place le monitoring (Prometheus [cite: 28] [cite_start]ou DataDog [cite: 28]) dès le Jour 0.

Commandes (issues de votre PDF [cite: 26]) pour la gestion quotidienne (Admin).

# (Voir la consommation CPU/Mem des Pods)
# (Nécessite le Metrics Server)
[cite_start]$ kubectl top pods -n  [cite: 26]

# (Voir la consommation CPU/Mem des Nœuds)
$ kubectl top nodes

# (Forcer un redémarrage (rolling) de tous les Pods d'un Deployment)
[cite_start]$ kubectl rollout restart deployment/mon-deploiement [cite: 26]

# (Voir le statut d'un déploiement en cours)
$ kubectl rollout status deployment/mon-deploiement

# (Mettre à l'échelle (impératif))
[cite_start]$ kubectl scale deployment/mon-deploiement --replicas=5 [cite: 26]

# (Vider un Nœud (pour maintenance) (déplace les Pods))
[cite_start]$ kubectl drain  --ignore-daemonsets [cite: 26]

# (Voir tous les événements (erreurs, scheduling) du cluster)
[cite_start]$ kubectl get events -A --sort-by='.lastTimestamp' [cite: 26]

Ressources (basées sur votre PDF [cite: 34]) pour apprendre K8s.