# Entretien Kubernetes : Pods, Services et Deployments en pratique > Questions d'entretien Kubernetes sur les Pods, Services et Deployments avec exemples YAML, fonctionnement réseau et stratégies de scaling pour 2026. - Published: 2026-04-04 - Updated: 2026-04-04 - Author: SharpSkill - Tags: kubernetes, devops, pods, services, deployments, entretien - Reading time: 12 min --- 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. > **Mémo rapide pour l'entretien** > > Les Pods exécutent les conteneurs, les Deployments gèrent leur cycle de vie et leur réplication, les Services exposent les Pods sur le réseau. Cette triade forme le cœur de toute application Kubernetes en production. ## 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 : ```yaml # 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é. > **Piège classique en entretien** > > Confondre readinessProbe et livenessProbe révèle une compréhension superficielle de Kubernetes. La readinessProbe gère le routage du trafic, la livenessProbe gère le redémarrage des conteneurs défaillants. Ces deux mécanismes remplissent des fonctions distinctes et complémentaires. ## 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 : ```yaml # 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. ```yaml # 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é : ```bash # 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. ```yaml # 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 : ```yaml # 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. > **Gateway API : l'avenir du networking Kubernetes** > > La Gateway API représente l'évolution majeure du networking Kubernetes. Plus expressive que les Ingress traditionnels, elle offre une séparation claire des responsabilités entre équipes infrastructure et développement. Les candidats avisés mentionnent cette technologie lors des discussions sur l'architecture réseau. ## 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 : ```yaml # 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. ```yaml # 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 `..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](/technologies/devops/interview-questions/kubernetes-basics) 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. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/fr/blog/devops/kubernetes-interview-pods-services-deployments-explained