Entretien Kubernetes : Pods, Services et Deployments en pratique

Les entretiens techniques axés sur Kubernetes représentent un passage obligé pour tout professionnel DevOps ou ingénieur infrastructure en 2026. La maîtrise des trois piliers fondamentaux — Pods, Services et Deployments — constitue le socle minimal attendu par les recruteurs. Cet article décortique ces concepts avec des exemples YAML concrets, des explications sur le fonctionnement interne du réseau Kubernetes, et les stratégies de mise à l'échelle que tout candidat doit connaître.

Les Pods : unité fondamentale d'exécution

Le Pod représente la plus petite unité déployable dans Kubernetes. Contrairement à une idée reçue fréquente chez les candidats débutants, un Pod ne se limite pas à un simple conteneur isolé. Il s'agit d'un groupe logique de conteneurs partageant le même espace réseau, le même stockage et les mêmes spécifications de scheduling.

Chaque Pod possède une adresse IP unique au sein du cluster. Les conteneurs d'un même Pod communiquent entre eux via localhost, ce qui simplifie considérablement l'architecture des applications composées de plusieurs processus interdépendants. Un cas d'usage classique : un conteneur applicatif couplé à un sidecar de logging ou de proxy.

La définition d'un Pod comprend plusieurs éléments critiques que les recruteurs examinent systématiquement :

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

Les sections resources définissent les garanties et limites de consommation. Les requests déterminent le minimum garanti par le scheduler lors du placement sur un nœud. Les limits imposent un plafond strict — tout dépassement mémoire déclenche un OOMKilled par le kernel.

Les probes constituent un autre point d'attention majeur. La readinessProbe contrôle l'inclusion du Pod dans les endpoints des Services : un Pod non ready ne reçoit aucun trafic. La livenessProbe surveille la santé du conteneur et provoque son redémarrage en cas d'échec répété.

Cycle de vie des Pods et politiques de redémarrage

Le cycle de vie d'un Pod traverse plusieurs phases que le candidat doit pouvoir énumérer et expliquer. Cette connaissance démontre une compréhension opérationnelle du fonctionnement de Kubernetes.

| Phase | Description | Signification opérationnelle | |-------|-------------|-----------------------------| | Pending | Pod accepté mais pas encore schedulé | Attente de ressources ou d'images | | Running | Au moins un conteneur en cours d'exécution | Fonctionnement normal | | Succeeded | Tous les conteneurs terminés avec succès | Tâches batch complétées | | Failed | Au moins un conteneur terminé en erreur | Investigation requise | | Unknown | État indéterminable | Problème de communication avec le nœud |

La politique de redémarrage (restartPolicy) détermine le comportement du kubelet face aux terminaisons de conteneurs. Trois valeurs existent :

• Always : redémarrage systématique (défaut pour les Deployments)
• OnFailure : redémarrage uniquement sur code de sortie non nul
• Never : aucun redémarrage automatique

Pour les tâches batch ou les migrations de données, la politique OnFailure convient parfaitement :

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Ce manifeste illustre également l'injection de secrets via les variables d'environnement, une pratique standard pour la gestion des credentials en production.

Deployments : orchestration déclarative des Pods

Les Pods bruts présentent une limitation majeure : leur destruction entraîne une perte définitive. Aucun mécanisme natif ne garantit leur recréation. Les Deployments résolvent ce problème en introduisant une couche d'abstraction déclarative.

Un Deployment définit l'état souhaité — nombre de réplicas, image à utiliser, stratégie de mise à jour — et le controller Kubernetes maintient cet état en permanence. La suppression accidentelle d'un Pod déclenche automatiquement la création d'un remplaçant.

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

La section strategy mérite une attention particulière. Le type RollingUpdate garantit une disponibilité continue pendant les mises à jour. Les paramètres maxUnavailable et maxSurge contrôlent le rythme de transition : ici, au maximum un Pod indisponible et un Pod supplémentaire pendant le processus.

Le champ revisionHistoryLimit conserve les anciens ReplicaSets pour permettre les rollbacks. Chaque modification du template génère une nouvelle révision traçable.

Rollback : retour à une version précédente

La capacité à annuler rapidement un déploiement problématique constitue une compétence opérationnelle fondamentale. Kubernetes conserve l'historique des révisions et permet un retour instantané :

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

La commande rollout history affiche les révisions disponibles avec leurs annotations de changement. En situation d'incident, le rollback vers une révision spécifique offre un contrôle précis sur la version restaurée.

Services : abstraction réseau des Pods

Les Pods possèdent des adresses IP éphémères qui changent à chaque recréation. Cette volatilité rend impossible toute communication directe fiable entre composants. Les Services résolvent ce problème en fournissant une identité réseau stable devant un ensemble de Pods.

Un Service utilise les labels pour sélectionner dynamiquement ses backends. Tout Pod correspondant au sélecteur intègre automatiquement le pool de endpoints. Cette découverte de service automatique simplifie considérablement l'architecture des applications distribuées.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

Le champ port définit le port exposé par le Service, tandis que targetPort indique le port réel du conteneur. Cette indirection permet de standardiser les ports externes indépendamment de l'implémentation interne.

Le DNS interne de Kubernetes résout automatiquement le nom du Service vers son ClusterIP. Un Pod peut ainsi contacter api-service.default.svc.cluster.local ou simplement api-service dans le même namespace.

Types de Services et cas d'usage

Kubernetes propose quatre types de Services correspondant à différents scénarios d'exposition :

| Type | Portée | Cas d'usage | |------|--------|-------------| | ClusterIP | Interne au cluster | Communication inter-services | | NodePort | Accessible via IP des nœuds | Tests, environnements de développement | | LoadBalancer | IP externe via cloud provider | Exposition publique en production | | ExternalName | Alias DNS vers service externe | Intégration de services hors cluster |

Pour une exposition publique en production, le type LoadBalancer délègue la création d'un équilibreur de charge au cloud provider :

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

Les annotations permettent de configurer le comportement spécifique du load balancer selon le provider. Ici, l'annotation AWS spécifie l'utilisation d'un Network Load Balancer plutôt que le Classic Load Balancer par défaut.

Connexion entre Deployments et Services

La relation entre Deployments et Services repose entièrement sur les labels. Un Service route le trafic vers tous les Pods dont les labels correspondent à son sélecteur, indépendamment du Deployment qui les a créés.

Cette propriété permet des patterns de déploiement avancés comme le canary release. Un second Deployment avec le même label app mais une version différente reçoit automatiquement une fraction du trafic :

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

Avec 3 réplicas du Deployment principal et 1 réplica canary, environ 25% du trafic atteint la nouvelle version. Cette approche permet de valider une release en conditions réelles avant un déploiement complet.

HorizontalPodAutoscaler : scaling automatique

Le HorizontalPodAutoscaler (HPA) ajuste dynamiquement le nombre de réplicas d'un Deployment en fonction de métriques observées. Cette automatisation garantit une utilisation optimale des ressources tout en maintenant la performance.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

La section behavior contrôle l'agressivité du scaling. Le paramètre stabilizationWindowSeconds impose un délai avant toute réduction, évitant les oscillations lors de pics de charge transitoires.

Le HPA nécessite le déploiement du Metrics Server dans le cluster pour collecter les métriques CPU et mémoire. Sans ce composant, l'autoscaling reste inopérant — un point que les candidats oublient fréquemment.

Questions d'entretien fréquentes et réponses

Quelle différence entre un Pod et un conteneur ? Un Pod encapsule un ou plusieurs conteneurs partageant le même espace réseau et stockage. Le Pod représente l'unité de scheduling de Kubernetes, pas le conteneur individuel.

Pourquoi ne pas déployer des Pods directement en production ? Les Pods bruts ne bénéficient d'aucun mécanisme de réconciliation. Leur suppression est définitive. Les Deployments garantissent le maintien de l'état souhaité et permettent les mises à jour progressives.

Comment un Service découvre-t-il ses backends ? Le controller Endpoints surveille les Pods correspondant au sélecteur du Service. Tout Pod ready avec les bons labels intègre automatiquement la liste des endpoints.

Quelle stratégie de mise à jour choisir entre RollingUpdate et Recreate ? RollingUpdate convient à la majorité des cas en garantissant une disponibilité continue. Recreate s'impose uniquement lorsque l'application ne supporte pas l'exécution simultanée de plusieurs versions (schéma de base de données incompatible, par exemple).

Comment fonctionne le DNS interne de Kubernetes ? CoreDNS résout les noms de Services vers leurs ClusterIP. Le format complet est <service>.<namespace>.svc.cluster.local. Dans le même namespace, le nom court suffit.

Que se passe-t-il si la readinessProbe échoue ? Le Pod est retiré des endpoints du Service et ne reçoit plus de trafic. Il reste en cours d'exécution et peut redevenir ready si les probes suivantes réussissent.

Comment garantir qu'un Pod tourne sur un nœud spécifique ? Les nodeSelectors, affinités et taints/tolerations contrôlent le placement des Pods. Les affinités offrent plus de flexibilité que les nodeSelectors stricts.

Pour approfondir la préparation aux entretiens DevOps, consulter les questions d'entretien DevOps couvrant les fondamentaux Kubernetes.

Conclusion

La maîtrise des Pods, Services et Deployments forme le socle indispensable de toute expertise Kubernetes. Les points essentiels à retenir :

• Les Pods constituent l'unité d'exécution minimale, regroupant conteneurs, réseau et stockage partagés
• Les Deployments gèrent le cycle de vie déclaratif des Pods avec réplication, mises à jour progressives et rollbacks
• Les Services fournissent une abstraction réseau stable grâce à la sélection par labels et la résolution DNS
• Les probes (readiness et liveness) contrôlent le routage du trafic et le redémarrage des conteneurs
• Le HPA automatise le scaling horizontal en fonction des métriques de charge
• Les labels représentent le mécanisme central de liaison entre tous ces composants

Une préparation efficace aux entretiens Kubernetes exige la pratique régulière de ces concepts sur un cluster réel. La théorie seule ne suffit pas face aux questions techniques approfondies des recruteurs expérimentés.