Bonnes pratiques SPaaS

Ce document regroupe les bonnes pratiques pour la gestion des workloads, du stockage, des images et de la sécurité dans OpenShift.

Il s’adresse aux personnes occupant des rôles d'intégrateur, d'administrateur, ou de développeur, et vise à fournir des recommandations concrètes pour assurer une utilisation efficace et sécurisée de l’environnement OpenShift.

Les exemples sont illustrés en YAML, format standard pour la gestion des configurations.

Gestion de l’isolation et de l’organisation (namespaces)

Les namespaces permettent de segmenter un cluster OpenShift en plusieurs espaces isolés, facilitant la gestion des ressources, des accès et des environnements.

Principes clés

• Chaque namespace agit comme un espace indépendant avec ses propres ressources et politiques.

• Les namespaces permettent d’isoler les workloads et les configurations, limitant les impacts croisés.

• La gestion des droits d’accès et des quotas se fait au niveau des namespaces.

Bonnes pratiques

• ✅ Avoir un namespace dédié pour chaque environnement (développement, test, production) afin d’assurer une isolation claire.

• ✅ Appliquer le principe du moindre privilège avec les RBAC.

• ✅ Avoir des quotas de ressources pour éviter qu’un namespace ne consomme toutes les ressources du cluster.

En cas de pic de ressources sur un des namespaces, ou de besoin de plus de ressources, il sera possible de procéder à une augmentation des limites via une demande de service IWS.

Gestion de la sécurité et accès (NetworkPolicies)

Les NetworkPolicies permettent de contrôler le trafic réseau entre les pods d’un namespace et l’extérieur, renforçant ainsi la sécurité des applications.

Principes clés

• Par défaut, tout le trafic est autorisé. Une NetworkPolicy restreint l’accès dès son application.

• Les règles sont appliquées aux pods sélectionnés et ne bloquent pas les connexions sortantes sauf configuration explicite.

Bonnes pratiques

✅ Restreindre l’accès par défaut avec une politique Deny all.
✅ Autoriser uniquement les flux nécessaires pour limiter les accès aux services critiques.
✅ Protéger les bases de données en limitant leur accès aux seules applications autorisées.
✅ Limiter les accès externes pour empêcher les pods d’accéder à Internet sauf si nécessaire.

Exemple - Bloquer tout trafic entrant

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: client-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Gestion des déploiements

Les Deployments assurent la gestion des applications en OpenShift en permettant le scaling, les mises à jour et la tolérance aux pannes.

Principes clés

• Utiliser Deployments au lieu de pods seuls pour une gestion automatisée.

• Activer RollingUpdate pour minimiser les interruptions lors des mises à jour.

• Définir des sondes (livenessProbe, readinessProbe) pour détecter et réagir aux échecs d’application.

Bonnes pratiques

✅ Utiliser au moins 2 réplicas pour assurer la disponibilité.

✅ Optimiser les ressources avec les Limits/Requests sur CPU/Mémoire.

• Requests : représentent la quantité minimale de ressources réservées pour un conteneur. Oepnshift utilise cette valeur pour planifier le pod sur un nœud capable de fournir au moins cette quantité de ressources.

• Limits : définissent la quantité maximale de ressources qu’un conteneur peut consommer. Si le conteneur dépasse cette limite, il peut être throttlé (en cas de dépassement de limites CPU) ou tué (mémoire).

✅ Automatiser les rollbacks en cas d’échec.

Exemple - Déploiement résilient

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resilient-app
  namespace: client-namespace
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    spec:
      containers:
      - name: app
        image: my-app:latest
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080

Gestion des sondes et de la résilience

Les sondes permettent d’assurer la stabilité des applications.

livenessProbe : Vérifie si l’application fonctionne toujours. readinessProbe : Vérifie si l’application est prête à accepter du trafic. startupProbe : Vérifie si l’application a bien démarré avant de la considérer "vivante".

Bonnes pratiques

✅ Toujours configurer readinessProbe pour éviter d’exposer une application non prête.

✅ Utiliser startupProbe si l’application met du temps à s’initialiser.

✅ Ajuster les seuils (failureThreshold, periodSeconds) en fonction du comportement réel.

Stockage et gestion des volumes

Le stockage dans OpenShift doit être bien géré pour assurer la persistance des données.

Bonnes pratiques

✅ Utiliser ConfigMaps et Secrets pour stocker les configurations et données sensibles.

✅ Privilégier les PersistentVolumeClaims (PVC) pour la persistance des données critiques.

✅ Limiter l’usage de emptyDir aux caches temporaires.

Exemple - PVC pour stockage persistant

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-pvc
  namespace: client-namespace
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Exemple - ConfigMap et Secret

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: client-namespace
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
---
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
  namespace: client-namespace
  labels:
    app: database
type: Opaque
data:
  username: dXNlcm5hbWU=  # "username" en base64
  password: cGFzc3dvcmQ=  # "password" en base64

Gestion des images

L’utilisation d’images sécurisées et maintenues est essentielle pour garantir la fiabilité des applications.

Bonnes pratiques

✅ Utiliser les registres autorisés : http://registry.sigma.fr (Harbor Sigma), Red Hat, Bitnami.

✅ Spécifier un tag précis (latest est déconseillé).

✅ Scanner régulièrement les images avec Trivy ou Clair.

✅ Privilégier des images légères et respecter "Run one process per container".

✅ Utiliser des images UBI (Universal Base Image) de Red Hat pour garantir la compatibilité et le support.

✅ Utiliser des images exécutées en rootless et ne pas forcer les UID. Openshift bloauera les containers en root et les exécutera avec un user aléatoire.

Exemple - Déploiement avec une image de Harbor

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-pvc
  namespace: client-namespace
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Gestion du workload et des dépendances

L’application doit gérer ses dépendances externes sans planter si elles ne sont pas prêtes.

Bonnes pratiques

✅ Utiliser un initContainer pour vérifier la disponibilité des services externes.

✅ Configurer une startupProbe pour éviter d’exécuter les autres probes (sondes ci-dessous) avant que l'application soit correctement démarrée et en capacité de répondre positivement aux sondes.

✅ Définir une readinessProbe pour assurer que le pod est prêt à recevoir du trafic. Cette probe vérifie l’état de l’application et informe OpenShift quand elle peut être considérée comme disponible. Tant que la readinessProbe échoue, le pod est exclu des services, ce qui évite d’envoyer des requêtes à une application non prête.

✅ Définir une livenessProbe pour vérifier que le pod fonctionne correctement. Si la livenessProbe échoue, OpenShift redémarre automatiquement le pod, ce qui permet de récupérer d’un état défaillant ou bloqué. Cette probe assure la résilience de l’application en détectant les pannes internes.

Exemple - Vérification d’une base de données avant le démarrage

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-dependencies
  namespace: client-namespace
spec:
  replicas: 2
  template:
    spec:
      initContainers:
      - name: check-db
        image: busybox
        command: ["sh", "-c", "until nc -z db-service 5432; do sleep 2; done"]
      containers:
      - name: app
        image: my-app:latest
        startupProbe:
          httpGet:
            path: /startup
            port: 8080
          failureThreshold: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080

Autoscaling des workloads : HPA & VPA

La scalabilité automatique des workloads dans OpenShift repose sur deux mécanismes principaux : Horizontal Pod Autoscaler (HPA) et Vertical Pod Autoscaler (VPA). Ils permettent d’adapter les ressources utilisées en fonction de la charge réelle.

Horizontal Pod Autoscaler (HPA)

Le HPA ajuste automatiquement le nombre de pods d’un déploiement selon les métriques système (CPU, mémoire) ou personnalisées.

Bonnes pratiques

✅ Définir des requests/limits clairs pour chaque container.
✅ Utiliser des métriques adaptées : CPU/mémoire, ou Prometheus pour du personnalisé.
✅ Fixer des bornes avec minReplicas et maxReplicas.
✅ Simuler des charges pour valider la configuration.

À éviter

❌ Utiliser HPA sans requests, ce qui rend son fonctionnement incohérent.
❌ Se baser uniquement sur la CPU si la mémoire est critique pour l’application.

Exemple - HPA basé sur CPU

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

User Stories - Stratégies de Scaling avec HPA

User Story 1 : Réagir instantanément à une montée en charge

“En tant qu’équipe e-commerce, je veux que mon application scale très rapidement pendant les pics de trafic (soldes, promotions), afin de garantir la disponibilité.”

behavior:
  scaleUp:
    policies:
    - type: Percent
      value: 900
      periodSeconds: 60

✅ Multiplie par 10 les pods en une minute.

✅ Idéal pour les applications exposées à des charges soudaines.

User Story 2 : Monter vite, descendre lentement

"En tant qu'équipe backend, je veux que mon service monte en charge rapidement mais ne redescende que progressivement, afin d’éviter de tuer des pods trop tôt."

behavior:
  scaleUp:
    policies:
    - type: Percent
      value: 900
      periodSeconds: 60
  scaleDown:
    policies:
    - type: Pods
      value: 1
      periodSeconds: 600

✅ Réagit vite à la montée en charge.

✅ Réduction douce : 1 pod toutes les 10 minutes.

✅ Recommandé pour les services critiques ou avec temps d’amorçage long.

User Story 3 : Éviter les fausses alertes de scale down

“En tant qu’équipe data, je veux éviter que mes pods soient supprimés trop tôt, car ma charge est instable et peut remonter après quelques minutes.”

behavior:
  scaleDown:
    stabilizationWindowSeconds: 600
    policies:
    - type: Pods
      value: 5
      periodSeconds: 60

✅ Attente de 10 minutes avant toute action.

✅ Utilise la recommandation la plus haute.

✅ Prévient les effets de flapping dans des systèmes à trafic irrégulier.

Vertical Pod Autoscaler (VPA)

Le VPA ajuste automatiquement les requests/limits CPU et mémoire des containers en fonction de la consommation réelle.

Bonnes pratiques

✅ Utiliser le mode Off ou Initial en production pour observer les recommandations.
✅ Analyser les recommandations VPA via les logs ou la ressource status.
✅ Appliquer manuellement les suggestions pour éviter les conflits avec HPA.
✅ Utiliser pour les workloads à exécution longue ou batch.

À éviter

❌ Ne pas utiliser VPA en mode Auto si HPA est activé sur la même cible.
❌ Appliquer VPA à des pods de courte durée ou très volatils.

Exemple - VPA en mode recommandé

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: worker-vpa
  namespace: client-namespace
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  updatePolicy:
    updateMode: "Off"

Combinaison HPA + VPA

Il est possible d’utiliser HPA et VPA ensemble avec précaution, car ils peuvent se chevaucher sur la gestion des requests.

Bonnes pratiques

✅ Utiliser HPA pour le scaling horizontal et VPA en mode Off ou Initial pour avoir des recommandations.
✅ Appliquer les suggestions VPA manuellement dans le manifeste du Deployment.
✅ Préférer des métriques custom pour HPA (non liées aux requests CPU) si VPA modifie ces valeurs.

Résumé des recommandations de QoS

Bonnes pratiques

✅ Utiliser au moins 2 réplicas pour assurer la disponibilité.

Lexique

Ressources externe

https://www.redhat.com/en/blog/9-best-practices-for-deploying-highly-available-applications-to-openshift

https://blog.stephane-robert.info/docs/conteneurs/orchestrateurs/kubernetes/requests-limits/

Donnez votre avis

Suggérer un changement, une amélioration ? Consulter ce Form https://forms.office.com/Pages/ResponsePage.aspx?id=b8v7H0_2oEaa-sGKkV9xU_yrH9QgbGhNpR-ExKM5fw9UM05IODBHUDlSV0EzOEY2VlJJT0laQU05RC4u&embed=true%22