Kubernetes en production : Deployments, Ingress et Secrets

🎯 Objectifs

À la fin de ce module, vous serez capable de :

✅ Gérer des Deployments avec rolling updates et rollbacks
✅ Externaliser la configuration avec ConfigMaps et Secrets
✅ Exposer des applications via Ingress
✅ Gérer le stockage persistant avec PV et PVC
✅ Mettre en place l'auto-scaling
✅ Appliquer les bonnes pratiques de production

📋 Prérequis

Module Découvrir Kubernetes complété
Cluster local fonctionnel (Minikube ou kind)
kubectl configuré

🚀 Deployments

Pourquoi ?

Un Pod seul n'est pas redémarré en cas d'échec. Un Deployment gère :

Le nombre de réplicas souhaité
Les rolling updates (mises à jour progressives)
Les rollbacks (retour en arrière)

Exemple YAML

yaml

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Commandes

bash

# Déployer
kubectl apply -f nginx-deployment.yaml

# Voir les deployments
kubectl get deployments

# Modifier le nombre de réplicas
kubectl scale deployment nginx-deployment --replicas=5

# Vérifier l'état du rollout
kubectl rollout status deployment nginx-deployment

# Mettre à jour l'image
kubectl set image deployment/nginx-deployment nginx=nginx:1.28

# Annuler la dernière mise à jour
kubectl rollout undo deployment nginx-deployment

# Historique des rollouts
kubectl rollout history deployment nginx-deployment

Stratégie de mise à jour

yaml

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # +1 pod max pendant la mise à jour
      maxUnavailable: 0   # 0 pod indisponible pendant la mise à jour

💡 Avec maxUnavailable: 0, aucune interruption de service pendant le déploiement.

🔄 ReplicaSets

Un ReplicaSet garantit qu'un nombre donné de Pods identiques est en cours d'exécution. Les Deployments créent et gèrent les ReplicaSets automatiquement.

bash

# Voir les ReplicaSets
kubectl get rs

# Détails
kubectl describe rs nginx-deployment-xxxx

⚠️ Ne modifiez pas les ReplicaSets directement. Utilisez toujours le Deployment parent.

⚙️ ConfigMaps

Concept

Les ConfigMaps permettent d'externaliser la configuration de vos conteneurs (variables, fichiers de config).

Création

bash

# Depuis des valeurs littérales
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=APP_PORT=8080

# Voir le contenu
kubectl get configmap app-config -o yaml

YAML

yaml

# app-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  APP_PORT: "8080"
  config.json: |
    {"debug": false, "log_level": "info"}

Utilisation dans un Deployment

yaml

spec:
  containers:
    - name: app
      image: mon-app:1.0
      envFrom:
        - configMapRef:
            name: app-config
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

🔒 Secrets

Concept

Les Secrets stockent des données sensibles : mots de passe, tokens, clés API.

Création

bash

# Créer un secret
kubectl create secret generic db-credentials \
  --from-literal=DB_USER=admin \
  --from-literal=DB_PASS=s3cur3P@ss

# Voir les secrets (les valeurs sont masquées)
kubectl get secret db-credentials -o yaml

YAML

yaml

# db-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DB_USER: YWRtaW4=        # echo -n "admin" | base64
  DB_PASS: czNjdXIzUEBzcw== # echo -n "s3cur3P@ss" | base64

Utilisation

yaml

spec:
  containers:
    - name: app
      image: mon-app:1.0
      env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: DB_USER

⚠️ Important : les Secrets sont encodés en base64, pas chiffrés. En production, activez le chiffrement etcd ou utilisez un outil comme Vault.

🌍 Ingress

Concept

Un Ingress gère le routage HTTP/HTTPS vers vos Services. Il nécessite un Ingress Controller (ex : nginx-ingress).

Installation du contrôleur

bash

# Avec Minikube
minikube addons enable ingress

# Vérifier
kubectl get pods -n ingress-nginx

Exemple YAML

yaml

# app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: mon-app.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-service
                port:
                  number: 80

bash

kubectl apply -f app-ingress.yaml
kubectl get ingress

💡 Ajoutez 127.0.0.1 mon-app.local dans /etc/hosts pour tester localement.

TLS

yaml

spec:
  tls:
    - hosts:
        - mon-app.local
      secretName: tls-secret

💾 Persistent Volumes

Concept

Les données dans un Pod sont éphémères. Pour persister les données :

PersistentVolume (PV) : ressource de stockage provisionnée par l'admin
PersistentVolumeClaim (PVC) : demande de stockage par l'utilisateur

PVC

yaml

# app-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Utilisation dans un Deployment

yaml

spec:
  containers:
    - name: app
      image: postgres:16
      volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: app-data

💡 Les StorageClasses permettent le provisionnement dynamique - le PV est créé automatiquement à la demande du PVC.

📈 Scaling

Manuel

bash

kubectl scale deployment nginx-deployment --replicas=10

Horizontal Pod Autoscaler (HPA)

Le HPA ajuste automatiquement le nombre de réplicas selon l'utilisation CPU ou mémoire.

bash

# Activer le metrics-server (Minikube)
minikube addons enable metrics-server

# Créer un HPA
kubectl autoscale deployment nginx-deployment \
  --min=2 --max=10 --cpu-percent=70

# Voir les HPA
kubectl get hpa

YAML

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

🛠️ Commandes Avancées

Commande	Description
`kubectl top pods`	Utilisation CPU/mémoire des pods
`kubectl top nodes`	Utilisation CPU/mémoire des nœuds
`kubectl port-forward svc/nginx 8080:80`	Accéder à un service localement
`kubectl diff -f fichier.yaml`	Voir les changements avant d'appliquer
`kubectl apply -f .`	Appliquer tous les fichiers d'un dossier
`kubectl get events --sort-by=.metadata.creationTimestamp`	Voir les événements récents
`kubectl explain deployment.spec`	Documentation d'un champ YAML

💡 kubectl apply est déclaratif (état désiré). kubectl create est impératif (échoue si la ressource existe déjà).

✅ Bonnes Pratiques

Limites de ressources

Toujours définir requests et limits pour éviter qu'un pod consomme toutes les ressources :

yaml

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

Probes de santé

yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

Probe	Rôle
Liveness	Redémarre le pod s'il ne répond plus
Readiness	Retire le pod du service s'il n'est pas prêt

Autres bonnes pratiques

🏷️ Utilisez des namespaces pour isoler les environnements (dev, staging, prod)
🔐 Activez RBAC pour contrôler les accès au cluster
📌 Spécifiez toujours un tag d'image précis (pas latest)
📝 Utilisez des labels cohérents sur toutes vos ressources
🗂️ Versionnez vos fichiers YAML dans Git

🎯 Points Clés

Un Deployment gère les réplicas, les mises à jour et les rollbacks
Les ConfigMaps externalisent la configuration non sensible
Les Secrets stockent les données sensibles (base64, pas chiffré par défaut)
L'Ingress route le trafic HTTP/HTTPS vers les services
Les PVC fournissent du stockage persistant aux pods
Le HPA ajuste automatiquement le nombre de réplicas
Toujours définir des limites de ressources et des probes de santé

📚 Ressources

🚀 Prochaines étapes

Vous gérez Kubernetes en production. Surveillez maintenant vos applications :

Surveiller ses applications avec Prometheus et Grafana - Prometheus, Grafana, logs centralisés et alerting

Kubernetes en production : Deployments, Ingress et Secrets

🎯 Objectifs

À la fin de ce module, vous serez capable de :

✅ Gérer des Deployments avec rolling updates et rollbacks
✅ Externaliser la configuration avec ConfigMaps et Secrets
✅ Exposer des applications via Ingress
✅ Gérer le stockage persistant avec PV et PVC
✅ Mettre en place l'auto-scaling
✅ Appliquer les bonnes pratiques de production

📋 Prérequis

Module Découvrir Kubernetes complété
Cluster local fonctionnel (Minikube ou kind)
kubectl configuré

🚀 Deployments

Pourquoi ?

Un Pod seul n'est pas redémarré en cas d'échec. Un Deployment gère :

Le nombre de réplicas souhaité
Les rolling updates (mises à jour progressives)
Les rollbacks (retour en arrière)

Exemple YAML

yaml

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Commandes

bash

# Déployer
kubectl apply -f nginx-deployment.yaml

# Voir les deployments
kubectl get deployments

# Modifier le nombre de réplicas
kubectl scale deployment nginx-deployment --replicas=5

# Vérifier l'état du rollout
kubectl rollout status deployment nginx-deployment

# Mettre à jour l'image
kubectl set image deployment/nginx-deployment nginx=nginx:1.28

# Annuler la dernière mise à jour
kubectl rollout undo deployment nginx-deployment

# Historique des rollouts
kubectl rollout history deployment nginx-deployment

Stratégie de mise à jour

yaml

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # +1 pod max pendant la mise à jour
      maxUnavailable: 0   # 0 pod indisponible pendant la mise à jour

💡 Avec maxUnavailable: 0, aucune interruption de service pendant le déploiement.

🔄 ReplicaSets

Un ReplicaSet garantit qu'un nombre donné de Pods identiques est en cours d'exécution. Les Deployments créent et gèrent les ReplicaSets automatiquement.

bash

# Voir les ReplicaSets
kubectl get rs

# Détails
kubectl describe rs nginx-deployment-xxxx

⚠️ Ne modifiez pas les ReplicaSets directement. Utilisez toujours le Deployment parent.

⚙️ ConfigMaps

Concept

Les ConfigMaps permettent d'externaliser la configuration de vos conteneurs (variables, fichiers de config).

Création

bash

# Depuis des valeurs littérales
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=APP_PORT=8080

# Voir le contenu
kubectl get configmap app-config -o yaml

YAML

yaml

# app-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  APP_PORT: "8080"
  config.json: |
    {"debug": false, "log_level": "info"}

Utilisation dans un Deployment

yaml

spec:
  containers:
    - name: app
      image: mon-app:1.0
      envFrom:
        - configMapRef:
            name: app-config
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

🔒 Secrets

Concept

Les Secrets stockent des données sensibles : mots de passe, tokens, clés API.

Création

bash

# Créer un secret
kubectl create secret generic db-credentials \
  --from-literal=DB_USER=admin \
  --from-literal=DB_PASS=s3cur3P@ss

# Voir les secrets (les valeurs sont masquées)
kubectl get secret db-credentials -o yaml

YAML

yaml

# db-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DB_USER: YWRtaW4=        # echo -n "admin" | base64
  DB_PASS: czNjdXIzUEBzcw== # echo -n "s3cur3P@ss" | base64

Utilisation

yaml

spec:
  containers:
    - name: app
      image: mon-app:1.0
      env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: DB_USER

⚠️ Important : les Secrets sont encodés en base64, pas chiffrés. En production, activez le chiffrement etcd ou utilisez un outil comme Vault.

🌍 Ingress

Concept

Un Ingress gère le routage HTTP/HTTPS vers vos Services. Il nécessite un Ingress Controller (ex : nginx-ingress).

Installation du contrôleur

bash

# Avec Minikube
minikube addons enable ingress

# Vérifier
kubectl get pods -n ingress-nginx

Exemple YAML

yaml

# app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: mon-app.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-service
                port:
                  number: 80

bash

kubectl apply -f app-ingress.yaml
kubectl get ingress

💡 Ajoutez 127.0.0.1 mon-app.local dans /etc/hosts pour tester localement.

TLS

yaml

spec:
  tls:
    - hosts:
        - mon-app.local
      secretName: tls-secret

💾 Persistent Volumes

Concept

Les données dans un Pod sont éphémères. Pour persister les données :

PersistentVolume (PV) : ressource de stockage provisionnée par l'admin
PersistentVolumeClaim (PVC) : demande de stockage par l'utilisateur

PVC

yaml

# app-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Utilisation dans un Deployment

yaml

spec:
  containers:
    - name: app
      image: postgres:16
      volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: app-data

💡 Les StorageClasses permettent le provisionnement dynamique - le PV est créé automatiquement à la demande du PVC.

📈 Scaling

Manuel

bash

kubectl scale deployment nginx-deployment --replicas=10

Horizontal Pod Autoscaler (HPA)

Le HPA ajuste automatiquement le nombre de réplicas selon l'utilisation CPU ou mémoire.

bash

# Activer le metrics-server (Minikube)
minikube addons enable metrics-server

# Créer un HPA
kubectl autoscale deployment nginx-deployment \
  --min=2 --max=10 --cpu-percent=70

# Voir les HPA
kubectl get hpa

YAML

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

🛠️ Commandes Avancées

Commande	Description
`kubectl top pods`	Utilisation CPU/mémoire des pods
`kubectl top nodes`	Utilisation CPU/mémoire des nœuds
`kubectl port-forward svc/nginx 8080:80`	Accéder à un service localement
`kubectl diff -f fichier.yaml`	Voir les changements avant d'appliquer
`kubectl apply -f .`	Appliquer tous les fichiers d'un dossier
`kubectl get events --sort-by=.metadata.creationTimestamp`	Voir les événements récents
`kubectl explain deployment.spec`	Documentation d'un champ YAML

💡 kubectl apply est déclaratif (état désiré). kubectl create est impératif (échoue si la ressource existe déjà).

✅ Bonnes Pratiques

Limites de ressources

Toujours définir requests et limits pour éviter qu'un pod consomme toutes les ressources :

yaml

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

Probes de santé

yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

Probe	Rôle
Liveness	Redémarre le pod s'il ne répond plus
Readiness	Retire le pod du service s'il n'est pas prêt

Autres bonnes pratiques

🏷️ Utilisez des namespaces pour isoler les environnements (dev, staging, prod)
🔐 Activez RBAC pour contrôler les accès au cluster
📌 Spécifiez toujours un tag d'image précis (pas latest)
📝 Utilisez des labels cohérents sur toutes vos ressources
🗂️ Versionnez vos fichiers YAML dans Git

🎯 Points Clés

Un Deployment gère les réplicas, les mises à jour et les rollbacks
Les ConfigMaps externalisent la configuration non sensible
Les Secrets stockent les données sensibles (base64, pas chiffré par défaut)
L'Ingress route le trafic HTTP/HTTPS vers les services
Les PVC fournissent du stockage persistant aux pods
Le HPA ajuste automatiquement le nombre de réplicas
Toujours définir des limites de ressources et des probes de santé

📚 Ressources

🚀 Prochaines étapes

Vous gérez Kubernetes en production. Surveillez maintenant vos applications :

Surveiller ses applications avec Prometheus et Grafana - Prometheus, Grafana, logs centralisés et alerting

Kubernetes en production : Deployments, Ingress et Secrets

🎯 Objectifs

📋 Prérequis

🚀 Deployments

Pourquoi ?

Exemple YAML

Commandes

Stratégie de mise à jour

🔄 ReplicaSets

⚙️ ConfigMaps

Concept

Création

YAML

Utilisation dans un Deployment

🔒 Secrets

Concept

Création

YAML

Utilisation

🌍 Ingress

Concept

Installation du contrôleur

Exemple YAML

TLS

💾 Persistent Volumes

Concept

PVC

Utilisation dans un Deployment

📈 Scaling

Manuel

Horizontal Pod Autoscaler (HPA)

YAML

🛠️ Commandes Avancées

✅ Bonnes Pratiques

Limites de ressources

Probes de santé

Autres bonnes pratiques

🎯 Points Clés

📚 Ressources

🚀 Prochaines étapes

Exercices Pratiques

Kubernetes en production : Deployments, Ingress et Secrets

🎯 Objectifs

📋 Prérequis

🚀 Deployments

Pourquoi ?

Exemple YAML

Commandes

Stratégie de mise à jour

🔄 ReplicaSets

⚙️ ConfigMaps

Concept

Création

YAML

Utilisation dans un Deployment

🔒 Secrets

Concept

Création

YAML

Utilisation

🌍 Ingress

Concept

Installation du contrôleur

Exemple YAML

TLS

💾 Persistent Volumes

Concept

PVC

Utilisation dans un Deployment

📈 Scaling

Manuel

Horizontal Pod Autoscaler (HPA)

YAML

🛠️ Commandes Avancées

✅ Bonnes Pratiques

Limites de ressources

Probes de santé

Autres bonnes pratiques

🎯 Points Clés

📚 Ressources