Design d'applications conteneurisées pour Kubernetes : guide complet

Le design d'applications conteneurisées pour Kubernetes détermine la réussite ou l'échec de vos déploiements en production. Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Cette adoption massive implique une responsabilité : concevoir des applications qui exploitent réellement les capacités de l'orchestrateur plutôt que de simplement "conteneuriser" du code legacy.

TL;DR : Ce guide détaille les 7 étapes essentielles pour concevoir une application cloud-native prête pour Kubernetes. Vous apprendrez à structurer vos microservices, optimiser vos images Docker, configurer les ressources, gérer les secrets, implémenter les health checks et préparer l'observabilité. Chaque étape inclut des commandes vérifiables et les erreurs courantes à éviter.

Les développeurs qui veulent maîtriser ces compétences suivent la formation LFD459 Kubernetes pour les développeurs d'applications.

Prérequis : ce dont vous avez besoin avant de commencer

Avant de concevoir votre application pour Kubernetes, validez ces prérequis techniques :

# Vérifier Docker
docker --version
# Résultat attendu : Docker version 24.x ou supérieur

# Vérifier kubectl
kubectl version --client
# Résultat attendu : Client Version: v1.29.x

# Vérifier l'accès au cluster
kubectl cluster-info
# Résultat attendu : Kubernetes control plane is running at https://...

Compétences requises :

• Maîtrise de Docker et des Dockerfiles multi-stage
• Compréhension des concepts Kubernetes (Pods, Deployments, Services)
• Familiarité avec YAML et les manifestes Kubernetes

Si vous débutez, consultez d'abord la section Développement applications Kubernetes pour acquérir les fondamentaux.

Étape 1 : Comment appliquer les principes du design cloud-native ?

Le développement cloud-native Kubernetes repose sur des principes architecturaux précis.

Les 12 facteurs adaptés à Kubernetes

L'architecture conteneurs Kubernetes s'appuie sur la méthodologie 12-Factor :

# Exemple : application stateless correctement conçue
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    spec:
      containers:
      - name: api
        image: myapp/api:v1.2.0
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url

À retenir : Une application cloud-native ne stocke jamais d'état en local. Toute persistance passe par des services externes (bases de données, caches, stockage objet).

Étape 2 : Comment structurer l'application en microservices ?

Selon CNCF Research 2025, 59% des organisations développent désormais la majorité de leurs applications en cloud-native. Cette transition exige une structuration rigoureuse.

Définir les frontières de service

Un microservice est une unité de déploiement indépendante qui encapsule une fonctionnalité métier unique. Chaque service possède sa propre base de données et communique via APIs.

# Structure projet recommandée
tree ./kubernetes-app
# Résultat attendu :
# kubernetes-app/
# ├── services/
# │   ├── api-gateway/
# │   │   ├── Dockerfile
# │   │   ├── k8s/
# │   │   │   ├── deployment.yaml
# │   │   │   └── service.yaml
# │   │   └── src/
# │   ├── user-service/
# │   └── order-service/
# ├── charts/
# │   └── app/
# └── skaffold.yaml

Configurer la communication inter-services

# Service discovery via DNS Kubernetes
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8080
---
# Le service api-gateway peut appeler : http://user-service.default.svc.cluster.local

Pour approfondir la gestion des configurations, consultez ConfigMaps et Secrets Kubernetes : bonnes pratiques de configuration.

Étape 3 : Comment optimiser les Dockerfiles pour Kubernetes ?

L'optimisation des images impacte directement les temps de déploiement et la sécurité. Selon Orca Security 2025, 70% des organisations utilisent Kubernetes en environnement cloud, rendant l'optimisation des images critique.

Build multi-stage pour réduire la taille

# Dockerfile optimisé pour Kubernetes
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server

FROM gcr.io/distroless/static:nonroot
COPY --from=builder /app/server /server
USER 65532:65532
EXPOSE 8080
ENTRYPOINT ["/server"]

Vérification de la taille de l'image :

docker build -t myapp:optimized .
docker images myapp:optimized
# Résultat attendu :
# REPOSITORY   TAG         SIZE
# myapp        optimized   15MB  # vs 800MB+ avec golang:1.22

Scanner les vulnérabilités avant déploiement

# Utiliser Trivy pour scanner l'image
trivy image myapp:optimized
# Résultat attendu : vulnérabilités classées par sévérité
# Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

À retenir : Utilisez des images de base distroless ou Alpine. Exécutez toujours en tant qu'utilisateur non-root (USER 65532).

Étape 4 : Comment configurer les ressources Kubernetes correctement ?

La gestion des ressources détermine la stabilité de vos applications. Un ingénieur logiciel Kubernetes doit maîtriser les requests et limits.

Définir requests et limits

Les requests garantissent les ressources minimales. Les limits plafonnent la consommation.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    spec:
      containers:
      - name: api
        image: myapp/api:v1.2.0
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"

Vérification des ressources allouées :

kubectl describe pod api-service-xxxx | grep -A 6 "Limits:"
# Résultat attendu :
#     Limits:
#       cpu:     500m
#       memory:  256Mi
#     Requests:
#       cpu:     100m
#       memory:  128Mi

Calculer les ressources nécessaires

Pour les déploiements complexes, découvrez les Helm Charts Kubernetes : aide-mémoire des commandes essentielles.

Étape 5 : Comment gérer la configuration et les secrets ?

La séparation configuration/code est un principe fondamental. Comme le souligne Chris Aniszczyk, CTO de la CNCF : "Kubernetes is no longer experimental but foundational."

Créer des ConfigMaps

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_TIMEOUT: "30s"
  FEATURE_FLAGS: |
    {
      "new_checkout": true,
      "beta_api": false
    }

kubectl apply -f configmap.yaml
kubectl get configmap app-config -o yaml
# Résultat attendu : ConfigMap créée avec les données

Gérer les Secrets de manière sécurisée

# Créer un secret depuis des valeurs littérales
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password='S3cur3P@ss!'

# Vérifier (les valeurs sont encodées en base64)
kubectl get secret db-credentials -o jsonpath='{.data.username}' | base64 -d
# Résultat attendu : admin

À retenir : Ne commitez jamais de secrets dans Git. Utilisez des outils comme Sealed Secrets ou External Secrets Operator pour les environnements de production.

Étape 6 : Comment implémenter les health checks ?

Les probes Kubernetes déterminent si votre application est prête à recevoir du trafic. Sans health checks, Kubernetes ne peut pas auto-réparer vos workloads.

Configurer les trois types de probes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    spec:
      containers:
      - name: api
        image: myapp/api:v1.2.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        startupProbe:
          httpGet:
            path: /healthz
            port: 8080
          failureThreshold: 30
          periodSeconds: 10

Vérification du statut des probes :

kubectl describe pod api-service-xxxx | grep -A 3 "Liveness:"
# Résultat attendu :
#     Liveness:       http-get http://:8080/healthz delay=15s timeout=1s period=10s
#     Readiness:      http-get http://:8080/ready delay=5s timeout=1s period=5s

Pour une couverture complète de l'observabilité, consultez Observabilité et monitoring des applications sur Kubernetes.

Étape 7 : Comment préparer l'observabilité dès le design ?

Avec 15.6 millions de développeurs utilisant les technologies cloud-native selon CNCF et SlashData, l'observabilité devient un standard de l'industrie.

Implémenter les logs structurés

# Configuration application pour logs JSON
apiVersion: v1
kind: ConfigMap
metadata:
  name: logging-config
data:
  config.yaml: |
    logging:
      format: json
      level: info
      fields:
        service: api-service
        version: v1.2.0

Exemple de sortie de logs :

kubectl logs api-service-xxxx | head -1
# Résultat attendu (JSON structuré) :
# {"timestamp":"2026-02-28T10:15:30Z","level":"info","msg":"Request processed","method":"GET","path":"/api/users","duration_ms":45}

Exposer les métriques Prometheus

// Exemple endpoint /metrics en Go
import (
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.ListenAndServe(":8080", nil)
}

# Annotations pour le scraping Prometheus
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "/metrics"

À retenir : Instrumentez dès le développement. Ajoutez les labels Kubernetes (app, version, environment) à vos métriques pour faciliter le filtrage.

Dépannage : résoudre les erreurs courantes

Erreur : CrashLoopBackOff

Symptôme : Le pod redémarre en boucle.

kubectl get pods
# NAME                  READY   STATUS             RESTARTS
# api-service-xxxx      0/1     CrashLoopBackOff   5

Diagnostic :

kubectl logs api-service-xxxx --previous
kubectl describe pod api-service-xxxx | grep -A 5 "Last State:"

Causes fréquentes :

• livenessProbe trop agressive (initialDelaySeconds insuffisant)
• Dépendance manquante (base de données non accessible)
• Erreur de configuration (variable d'environnement absente)

Erreur : ImagePullBackOff

kubectl describe pod api-service-xxxx | grep -A 3 "Events:"
# Warning  Failed     pull access denied for myapp/api

Solution : Vérifiez les credentials du registry :

kubectl create secret docker-registry regcred \
  --docker-server=ghcr.io \
  --docker-username=<user> \
  --docker-password=<token>

Erreur : OOMKilled

Symptôme : Conteneur tué pour dépassement mémoire.

kubectl describe pod api-service-xxxx | grep OOMKilled
# Reason: OOMKilled

Solution : Augmentez les limits mémoire après analyse :

kubectl top pod api-service-xxxx
# Analysez la consommation réelle avant d'ajuster

Pour approfondir le dépannage, explorez les ressources de la section Certifications Formation Kubernetes.

Récapitulatif et prochaines étapes

Pour aller plus loin dans votre parcours, consultez le programme détaillé de la formation LFD459 ou le guide complet Formation Kubernetes.

Passez à l'action : développez vos compétences Kubernetes

Ce guide couvre les fondamentaux du design d'applications pour Kubernetes. Pour maîtriser ces compétences en conditions réelles avec des formateurs praticiens :

• LFD459 Kubernetes pour les développeurs d'applications : 3 jours pour préparer la certification CKAD et concevoir des applications cloud-native
• Kubernetes, les fondamentaux : 1 journée pour découvrir l'écosystème Kubernetes
• LFS458 Administration Kubernetes : 4 jours pour maîtriser l'administration de clusters et préparer le CKA

Consultez les prochaines dates et inscrivez-vous.