Déploiements Avancés dans Kubernetes : Stratégies et Bonnes Pratiques

Stratégies de Déploiement dans Kubernetes

Les déploiements Kubernetes offrent différentes stratégies pour mettre à jour vos applications. Choisir la bonne stratégie est crucial pour minimiser les interruptions de service et assurer une transition fluide.

Stratégie de Remplacement (Recreate)

La stratégie de remplacement arrête toutes les instances de l’ancienne version avant de démarrer les nouvelles. C’est la stratégie par défaut.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

Avantages :

• Simple à comprendre et à déboguer
• Garantit qu’une seule version est en cours d’exécution à la fois

Inconvénients :

• Temps d’arrêt pendant le déploiement
• Pas de rollback automatique en cas d’échec

Cas d’utilisation :

• Applications qui ne supportent pas plusieurs versions simultanées
• Environnements de développement ou de test
• Applications avec des dépendances de base de données critiques

Stratégie de Rolling Update (RollingUpdate)

La stratégie de mise à jour progressive remplace progressivement les anciennes instances par de nouvelles, en maintenant un nombre minimum d’instances disponibles.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Nombre maximum de pods supplémentaires autorisés
      maxUnavailable: 0  # Nombre maximum de pods non disponibles pendant la mise à jour
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

Avantages :

• Pas de temps d’arrêt
• Rollback automatique en cas d’échec
• Contrôle précis sur le processus de mise à jour

Inconvénients :

• Plus complexe à configurer
• Peut nécessiter plus de ressources pendant la mise à jour

Cas d’utilisation :

• Applications en production
• Services qui nécessitent une haute disponibilité
• Applications qui supportent plusieurs versions simultanées

Stratégie de Blue/Green Deployment

Bien que Kubernetes ne fournisse pas nativement de déploiement blue/green, vous pouvez l’implémenter en utilisant des services et des déploiements.

# Déploiement "Blue" (version actuelle)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# Déploiement "Green" (nouvelle version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: myapp:1.1
---
# Service qui pointe vers la version active
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: blue  # Changez pour "green" pour basculer vers la nouvelle version
  ports:
  - port: 80
    targetPort: 8080

Avantages :

• Basculement instantané entre les versions
• Pas de dégradation de service pendant la mise à jour
• Rollback simple en changeant le sélecteur du service

Inconvénients :

• Nécessite deux fois plus de ressources pendant le déploiement
• Configuration plus complexe
• Nécessite une gestion manuelle ou un script pour le basculement

Cas d’utilisation :

• Applications critiques avec des fenêtres de maintenance strictes
• Services qui nécessitent un basculement rapide en cas de problème
• Applications avec des dépendances complexes entre versions

Stratégie de Canary Deployment

Un déploiement canary expose une petite partie du trafic à la nouvelle version avant de déployer complètement.

# Déploiement principal (version actuelle)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-main
spec:
  replicas: 9
  selector:
    matchLabels:
      app: myapp
      version: main
  template:
    metadata:
      labels:
        app: myapp
        version: main
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# Déploiement canary (nouvelle version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      version: canary
  template:
    metadata:
      labels:
        app: myapp
        version: canary
    spec:
      containers:
      - name: myapp
        image: myapp:1.1
---
# Service qui distribue le trafic
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

Avantages :

• Test en production avec risque minimal
• Détection précoce des problèmes
• Possibilité de collecter des métriques avant le déploiement complet

Inconvénients :

• Configuration plus complexe
• Nécessite une surveillance attentive pendant la phase canary
• Peut nécessiter des outils supplémentaires pour le routage du trafic

Cas d’utilisation :

• Applications avec un grand nombre d’utilisateurs
• Services qui nécessitent une validation en production
• Déploiements à risque élevé

Gestion des Rollbacks

Les rollbacks sont essentiels pour maintenir la disponibilité de votre application en cas de problème avec une nouvelle version.

Rollback Automatique avec Health Checks

Configurez des sondes de santé (liveness et readiness) pour que Kubernetes puisse détecter automatiquement les problèmes et effectuer un rollback.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

Rollback Manuel avec kubectl

Vous pouvez effectuer un rollback manuel vers une version précédente en utilisant la commande kubectl rollout undo :

# Rollback vers la version précédente
kubectl rollout undo deployment/app-deployment

# Rollback vers une version spécifique
kubectl rollout undo deployment/app-deployment --to-revision=2

Bonnes Pratiques pour les Déploiements

1. Utilisez des Tags d’Image Spécifiques

Évitez d’utiliser latest comme tag d’image, car cela rend difficile le suivi des versions et peut entraîner des déploiements non reproductibles.

# À éviter
image: myapp:latest

# Recommandé
image: myapp:1.0.2

2. Définissez des Ressources Limites

Spécifiez les limites de ressources pour éviter qu’un pod ne consomme trop de ressources et n’affecte les autres pods.

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

3. Utilisez des Anti-Affinity Rules

Déployez les pods sur différents nœuds pour améliorer la disponibilité.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - myapp
          topologyKey: kubernetes.io/hostname

4. Implémentez des Stratégies de Mise à l’échelle

Configurez l’auto-scaling horizontal (HPA) pour ajuster automatiquement le nombre de réplicas en fonction de la charge.

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

5. Utilisez des ConfigMaps et des Secrets

Séparez la configuration de l’application du code pour faciliter les modifications sans reconstruire l’image.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: base64encodedpassword
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets

Exemple de Déploiement Complet

Voici un exemple complet d’un déploiement Kubernetes avec les meilleures pratiques :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.2
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - myapp
              topologyKey: kubernetes.io/hostname
---
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

Conclusion

Les déploiements avancés dans Kubernetes offrent une grande flexibilité pour gérer les mises à jour de vos applications. En choisissant la bonne stratégie de déploiement et en suivant les meilleures pratiques, vous pouvez assurer une transition fluide entre les versions tout en maintenant la disponibilité de votre service.

Dans le prochain article, nous explorerons la gestion des secrets et des configurations dans Kubernetes, un aspect crucial pour sécuriser vos applications.