Un cluster K8s en production implique quatre domaines que ce chapitre couvre : le scaling automatique (HPA), la gestion des droits (RBAC), la packaging des applications (Helm), et le monitoring (Prometheus + Grafana).

Rolling Updates et rollback

La stratégie RollingUpdate (défaut) remplace les pods un par un. Avec maxUnavailable: 0, aucun pod n'est coupé avant que le nouveau soit Ready.

# Mettre à jour l'image
kubectl set image deployment/mon-app app=mon-registry/mon-app:2.0.0 -n production
 
# Suivre le rollout
kubectl rollout status deployment/mon-app -n production
# Waiting for deployment "mon-app" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "mon-app" rollout to finish: 1 old replicas are pending termination...
# deployment "mon-app" successfully rolled out
 
# Historique
kubectl rollout history deployment/mon-app -n production
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         <none>
 
# Annoter les révisions (bonne pratique)
kubectl annotate deployment mon-app \
  kubernetes.io/change-cause="Deploy v2.0.0 - ajout feature X" -n production
 
# Rollback immédiat
kubectl rollout undo deployment/mon-app -n production
 
# Rollback à une révision spécifique
kubectl rollout undo deployment/mon-app --to-revision=1 -n production

HPA — Horizontal Pod Autoscaler

Le HPA scale automatiquement le nombre de replicas selon l'utilisation CPU/mémoire ou des métriques custom.

Prérequis : metrics-server doit être installé.

# K3s inclut metrics-server par défaut
kubectl top nodes
kubectl top pods -n production

hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mon-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mon-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70    # scale up si CPU > 70%
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

kubectl apply -f hpa.yaml
kubectl get hpa -n production
# NAME          REFERENCE         TARGETS         MINPODS   MAXPODS   REPLICAS
# mon-app-hpa   Deployment/mon-app   45%/70%         2         10        3

Points d'attention HPA :

Le Deployment doit avoir des resources.requests définis — sans ça, le HPA ne peut pas calculer le pourcentage d'utilisation
Éviter de combiner HPA avec un replicas fixe dans le Deployment (conflit)
minReplicas: 2 minimum en production — jamais 1 (single point of failure)

Readiness et Liveness — le lien avec le scaling

Pendant un scale-up, les nouveaux pods ne reçoivent pas de trafic tant que leur readinessProbe n'est pas passée. C'est le mécanisme qui garantit que vous ne routez pas vers des pods pas encore prêts.

Pendant un scale-down, K8s attend que les connexions actives se terminent avant de supprimer un pod (grace period) :

spec:
  template:
    spec:
      terminationGracePeriodSeconds: 30   # secondes pour terminer proprement
      containers:
        - name: app
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 5"]  # flush les connexions

RBAC — contrôle d'accès

RBAC (Role-Based Access Control) définit qui peut faire quoi dans le cluster. Indispensable quand plusieurs équipes partagent le même cluster.

Concepts

ServiceAccount : identité pour un pod ou une application
Role : permissions dans un namespace
ClusterRole : permissions dans tout le cluster
RoleBinding : attache un Role à un ServiceAccount/user dans un namespace
ClusterRoleBinding : attache un ClusterRole globalement

rbac.yaml

# ServiceAccount pour l'application
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mon-app-sa
  namespace: production
 
---
# Role : lire les secrets et configmaps du namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets", "configmaps"]
    verbs: ["get", "list"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
 
---
# Lier le role au service account
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-reader-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: mon-app-sa
    namespace: production
roleRef:
  kind: Role
  apiRef: app-reader
  apiGroup: rbac.authorization.k8s.io

Kubeconfig pour une équipe

# Créer un kubeconfig limité pour un développeur
# (accès en lecture seule au namespace staging)
kubectl create serviceaccount dev-user -n staging
kubectl create rolebinding dev-readonly \
  --clusterrole=view \
  --serviceaccount=staging:dev-user \
  -n staging
 
# Générer le token
kubectl create token dev-user -n staging --duration=168h

Helm — packaging et templating

Helm est le gestionnaire de paquets de Kubernetes. Il permet de packager des manifestes K8s en "charts" réutilisables et versionnés.

Installer un chart existant

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
 
# Installer PostgreSQL
helm install postgres bitnami/postgresql \
  --namespace production \
  --set auth.postgresPassword=mon-mot-de-passe \
  --set primary.persistence.size=20Gi \
  --set primary.resources.requests.memory=256Mi
 
# Lister les releases
helm list -n production
 
# Mettre à jour
helm upgrade postgres bitnami/postgresql -n production --set image.tag=16.3.0
 
# Rollback
helm rollback postgres 1 -n production
 
# Désinstaller
helm uninstall postgres -n production

Créer son propre chart

helm create mon-app
# Crée la structure :
# mon-app/
# ├── Chart.yaml         ← métadonnées
# ├── values.yaml        ← valeurs par défaut
# └── templates/
#     ├── deployment.yaml
#     ├── service.yaml
#     ├── ingress.yaml
#     └── _helpers.tpl

values.yaml

image:
  repository: mon-registry/mon-app
  tag: "1.0.0"
  pullPolicy: IfNotPresent
 
replicaCount: 3
 
service:
  type: ClusterIP
  port: 80
 
ingress:
  enabled: true
  host: mon-app.example.com
  tls: true
 
resources:
  requests:
    memory: 128Mi
    cpu: 100m
  limits:
    memory: 256Mi
    cpu: 500m

# Valider le chart
helm lint mon-app/
 
# Voir le YAML généré
helm template mon-app/ --values custom-values.yaml
 
# Déployer
helm install mon-app ./mon-app/ -n production --values production-values.yaml

Monitoring — Prometheus et Grafana

Installation via kube-prometheus-stack

Le chart kube-prometheus-stack installe Prometheus, Grafana, AlertManager et les règles d'alerting par défaut en une commande.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
 
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=mon-mot-de-passe \
  --set prometheus.prometheusSpec.retention=15d

Accéder à Grafana :

kubectl port-forward -n monitoring service/monitoring-grafana 3000:80
# http://localhost:3000 — admin / mon-mot-de-passe

Les dashboards par défaut couvrent : utilisation CPU/mémoire par nœud et namespace, latence des pods, état des PersistentVolumes, métriques etcd, et état de l'API Server.

Exposer des métriques depuis votre application

Exposer /metrics pour Prometheus (Node.js)

import { Registry, collectDefaultMetrics, Counter, Histogram } from 'prom-client'
 
const registry = new Registry()
collectDefaultMetrics({ register: registry })
 
const httpRequests = new Counter({
  name: 'http_requests_total',
  help: 'Total HTTP requests',
  labelNames: ['method', 'path', 'status'],
  registers: [registry],
})
 
const httpDuration = new Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request duration',
  labelNames: ['method', 'path'],
  registers: [registry],
})
 
// Route /metrics
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', registry.contentType)
  res.send(await registry.metrics())
})

ServiceMonitor — dire à Prometheus de scraper votre app

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: mon-app
  namespace: production
  labels:
    release: monitoring   # doit matcher le selector du Prometheus
spec:
  selector:
    matchLabels:
      app: mon-app
  endpoints:
    - port: http
      path: /metrics
      interval: 30s

Checklist production K8s

Sécurité

RBAC configuré — principle of least privilege
Secrets dans un outil externe (Sealed Secrets / Vault / External Secrets)
NetworkPolicy pour isoler les namespaces
readOnlyRootFilesystem: true dans le securityContext des conteneurs
runAsNonRoot: true — pas de conteneur en root
Image scanning (Trivy, Snyk) dans la CI

Fiabilité

readinessProbe et livenessProbe sur tous les conteneurs
resources.requests et resources.limits définis
HPA configuré pour les workloads variables
minReplicas: 2 minimum
PodDisruptionBudget pour les services critiques
Backup etcd automatisé

Observabilité

Prometheus + Grafana installés
Alertes sur CPU/mémoire, pods crashlooping, PVC presque pleins
Logs centralisés (Loki, ELK, ou cloud provider)
Tracing distribué si microservices (Jaeger, Tempo)

Vous avez maintenant une vision complète de Kubernetes : des raisons de l'adopter jusqu'au déploiement en production sécurisé avec monitoring. Pour le déploiement de bases de données Redis en cluster dans K8s, le chapitre Redis de cette formation couvre les patterns spécifiques.

Rolling Updates et rollback

La stratégie RollingUpdate (défaut) remplace les pods un par un. Avec maxUnavailable: 0, aucun pod n'est coupé avant que le nouveau soit Ready.

# Mettre à jour l'image
kubectl set image deployment/mon-app app=mon-registry/mon-app:2.0.0 -n production
 
# Suivre le rollout
kubectl rollout status deployment/mon-app -n production
# Waiting for deployment "mon-app" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "mon-app" rollout to finish: 1 old replicas are pending termination...
# deployment "mon-app" successfully rolled out
 
# Historique
kubectl rollout history deployment/mon-app -n production
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         <none>
 
# Annoter les révisions (bonne pratique)
kubectl annotate deployment mon-app \
  kubernetes.io/change-cause="Deploy v2.0.0 - ajout feature X" -n production
 
# Rollback immédiat
kubectl rollout undo deployment/mon-app -n production
 
# Rollback à une révision spécifique
kubectl rollout undo deployment/mon-app --to-revision=1 -n production

HPA — Horizontal Pod Autoscaler

Le HPA scale automatiquement le nombre de replicas selon l'utilisation CPU/mémoire ou des métriques custom.

Prérequis : metrics-server doit être installé.

# K3s inclut metrics-server par défaut
kubectl top nodes
kubectl top pods -n production

hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mon-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mon-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70    # scale up si CPU > 70%
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

kubectl apply -f hpa.yaml
kubectl get hpa -n production
# NAME          REFERENCE         TARGETS         MINPODS   MAXPODS   REPLICAS
# mon-app-hpa   Deployment/mon-app   45%/70%         2         10        3

Points d'attention HPA :

Le Deployment doit avoir des resources.requests définis — sans ça, le HPA ne peut pas calculer le pourcentage d'utilisation
Éviter de combiner HPA avec un replicas fixe dans le Deployment (conflit)
minReplicas: 2 minimum en production — jamais 1 (single point of failure)

Readiness et Liveness — le lien avec le scaling

Pendant un scale-down, K8s attend que les connexions actives se terminent avant de supprimer un pod (grace period) :

spec:
  template:
    spec:
      terminationGracePeriodSeconds: 30   # secondes pour terminer proprement
      containers:
        - name: app
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 5"]  # flush les connexions

RBAC — contrôle d'accès

RBAC (Role-Based Access Control) définit qui peut faire quoi dans le cluster. Indispensable quand plusieurs équipes partagent le même cluster.

Concepts

ServiceAccount : identité pour un pod ou une application
Role : permissions dans un namespace
ClusterRole : permissions dans tout le cluster
RoleBinding : attache un Role à un ServiceAccount/user dans un namespace
ClusterRoleBinding : attache un ClusterRole globalement

rbac.yaml

# ServiceAccount pour l'application
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mon-app-sa
  namespace: production
 
---
# Role : lire les secrets et configmaps du namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets", "configmaps"]
    verbs: ["get", "list"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
 
---
# Lier le role au service account
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-reader-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: mon-app-sa
    namespace: production
roleRef:
  kind: Role
  apiRef: app-reader
  apiGroup: rbac.authorization.k8s.io

Kubeconfig pour une équipe

# Créer un kubeconfig limité pour un développeur
# (accès en lecture seule au namespace staging)
kubectl create serviceaccount dev-user -n staging
kubectl create rolebinding dev-readonly \
  --clusterrole=view \
  --serviceaccount=staging:dev-user \
  -n staging
 
# Générer le token
kubectl create token dev-user -n staging --duration=168h

Helm — packaging et templating

Helm est le gestionnaire de paquets de Kubernetes. Il permet de packager des manifestes K8s en "charts" réutilisables et versionnés.

Installer un chart existant

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
 
# Installer PostgreSQL
helm install postgres bitnami/postgresql \
  --namespace production \
  --set auth.postgresPassword=mon-mot-de-passe \
  --set primary.persistence.size=20Gi \
  --set primary.resources.requests.memory=256Mi
 
# Lister les releases
helm list -n production
 
# Mettre à jour
helm upgrade postgres bitnami/postgresql -n production --set image.tag=16.3.0
 
# Rollback
helm rollback postgres 1 -n production
 
# Désinstaller
helm uninstall postgres -n production

Créer son propre chart

helm create mon-app
# Crée la structure :
# mon-app/
# ├── Chart.yaml         ← métadonnées
# ├── values.yaml        ← valeurs par défaut
# └── templates/
#     ├── deployment.yaml
#     ├── service.yaml
#     ├── ingress.yaml
#     └── _helpers.tpl

values.yaml

image:
  repository: mon-registry/mon-app
  tag: "1.0.0"
  pullPolicy: IfNotPresent
 
replicaCount: 3
 
service:
  type: ClusterIP
  port: 80
 
ingress:
  enabled: true
  host: mon-app.example.com
  tls: true
 
resources:
  requests:
    memory: 128Mi
    cpu: 100m
  limits:
    memory: 256Mi
    cpu: 500m

# Valider le chart
helm lint mon-app/
 
# Voir le YAML généré
helm template mon-app/ --values custom-values.yaml
 
# Déployer
helm install mon-app ./mon-app/ -n production --values production-values.yaml

Monitoring — Prometheus et Grafana

Installation via kube-prometheus-stack

Le chart kube-prometheus-stack installe Prometheus, Grafana, AlertManager et les règles d'alerting par défaut en une commande.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
 
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=mon-mot-de-passe \
  --set prometheus.prometheusSpec.retention=15d

Accéder à Grafana :

kubectl port-forward -n monitoring service/monitoring-grafana 3000:80
# http://localhost:3000 — admin / mon-mot-de-passe

Les dashboards par défaut couvrent : utilisation CPU/mémoire par nœud et namespace, latence des pods, état des PersistentVolumes, métriques etcd, et état de l'API Server.

Exposer des métriques depuis votre application

Exposer /metrics pour Prometheus (Node.js)

import { Registry, collectDefaultMetrics, Counter, Histogram } from 'prom-client'
 
const registry = new Registry()
collectDefaultMetrics({ register: registry })
 
const httpRequests = new Counter({
  name: 'http_requests_total',
  help: 'Total HTTP requests',
  labelNames: ['method', 'path', 'status'],
  registers: [registry],
})
 
const httpDuration = new Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request duration',
  labelNames: ['method', 'path'],
  registers: [registry],
})
 
// Route /metrics
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', registry.contentType)
  res.send(await registry.metrics())
})

ServiceMonitor — dire à Prometheus de scraper votre app

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: mon-app
  namespace: production
  labels:
    release: monitoring   # doit matcher le selector du Prometheus
spec:
  selector:
    matchLabels:
      app: mon-app
  endpoints:
    - port: http
      path: /metrics
      interval: 30s

Checklist production K8s

Sécurité

RBAC configuré — principle of least privilege
Secrets dans un outil externe (Sealed Secrets / Vault / External Secrets)
NetworkPolicy pour isoler les namespaces
readOnlyRootFilesystem: true dans le securityContext des conteneurs
runAsNonRoot: true — pas de conteneur en root
Image scanning (Trivy, Snyk) dans la CI

Fiabilité

readinessProbe et livenessProbe sur tous les conteneurs
resources.requests et resources.limits définis
HPA configuré pour les workloads variables
minReplicas: 2 minimum
PodDisruptionBudget pour les services critiques
Backup etcd automatisé

Observabilité

Prometheus + Grafana installés
Alertes sur CPU/mémoire, pods crashlooping, PVC presque pleins
Logs centralisés (Loki, ELK, ou cloud provider)
Tracing distribué si microservices (Jaeger, Tempo)

Kubernetes

Scaling, RBAC, Helm et production

Rolling Updates et rollback

HPA — Horizontal Pod Autoscaler

Readiness et Liveness — le lien avec le scaling

RBAC — contrôle d'accès

Concepts

Kubeconfig pour une équipe

Helm — packaging et templating

Installer un chart existant

Créer son propre chart

Monitoring — Prometheus et Grafana

Installation via kube-prometheus-stack

Exposer des métriques depuis votre application

Checklist production K8s

Kubernetes

Scaling, RBAC, Helm et production

Rolling Updates et rollback

HPA — Horizontal Pod Autoscaler

Readiness et Liveness — le lien avec le scaling

RBAC — contrôle d'accès

Concepts

Kubeconfig pour une équipe

Helm — packaging et templating

Installer un chart existant

Créer son propre chart

Monitoring — Prometheus et Grafana

Installation via kube-prometheus-stack

Exposer des métriques depuis votre application

Checklist production K8s