Accueil›Blog›Test technique Kubernetes pour la data : pods, nodes, GKE, orchestration
Guide recrutement data
Test technique Kubernetes pour la data : pods, nodes, GKE, orchestration
Kubernetes s'impose dans les équipes data pour orchestrer les pipelines, déployer des APIs ML et gérer les workloads Spark ou Airflow. Voici les concepts qu'on teste pour valider un Data Engineer sur K8s.
Data Builder·Juin 2025·8 min de lecture·Data Engineer
Kubernetes (K8s) est devenu incontournable dans les architectures data cloud. Qu'il s'agisse d'orchestrer Airflow sur GKE, de déployer une API FastAPI de scoring ML, ou de lancer des jobs Spark sur Kubernetes, les Data Engineers doivent maîtriser les concepts fondamentaux.
1Concepts fondamentaux
Question discriminante
Quelle est la différence entre un Pod, un Node et un Cluster ? Que se passe-t-il si un Pod tombe ?
- Pod — unité de base Kubernetes. Contient un ou plusieurs conteneurs qui partagent le réseau et le stockage. Éphémère par nature
- Node — machine virtuelle ou physique qui héberge des Pods. Contient : Kubelet (communication avec le plan de contrôle), Container Runtime (Docker/containerd), Kube-Proxy (réseau)
- Cluster — ensemble d'un plan de contrôle et de nodes. Le plan de contrôle contient : kube-apiserver, etcd (stockage d'état), kube-scheduler, kube-controller-manager
- Deployment — décrit l'état désiré (nombre de replicas, image). Si un Pod tombe, le Deployment le recrée automatiquement
- Service — abstraction stable pour exposer des Pods (ClusterIP, NodePort, LoadBalancer)
Distinction clé : un Pod est éphémère — il peut être supprimé et recréé à tout moment. Les données persistantes doivent être dans des Persistent Volumes, pas dans le Pod lui-même.
2Architecture du cluster
Question discriminante
Quel est le rôle d'etcd dans un cluster Kubernetes ? Que se passe-t-il si etcd devient indisponible ?
# Déploiement minimal d'une API data en K8s
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-scoring-ml
spec:
replicas: 3
selector:
matchLabels:
app: api-scoring
template:
metadata:
labels:
app: api-scoring
spec:
containers:
- name: api
image: gcr.io/mon-projet/api-scoring:v1.2
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
env:
- name: MODEL_PATH
valueFrom:
secretKeyRef:
name: ml-secrets
key: model-gcs-path
- etcd — stockage clé-valeur de l'état du cluster. Si etcd est indisponible, le cluster ne peut plus être modifié (mais les workloads en cours continuent)
- kube-scheduler — attribue les Pods aux Nodes selon les ressources disponibles et les contraintes (affinity, taints/tolerations)
- Namespaces — isolation logique dans un cluster (dev, staging, prod)
- ConfigMaps et Secrets — configuration et credentials injectés dans les Pods (ne pas coder en dur dans l'image)
3GKE : Autopilot vs Standard
Question discriminante
Dans quel cas choisissez-vous GKE Autopilot plutôt que Standard ?
| GKE Autopilot | GKE Standard |
|---|
| Gestion des nodes | Automatique (Google) | Manuelle |
| Facturation | Par Pod (ressources demandées) | Par Node (ressources allouées) |
| Scaling | Automatique et transparent | Configurable manuellement |
| OS des nodes | Container-Optimized OS uniquement | COS, Ubuntu, Windows Server |
| Sécurité par défaut | Workload Identity, démarrage sécurisé inclus | Configurable, plus de contrôle |
| Idéal pour | Équipes sans infra spécialisée, workloads variables | Workloads spécialisés, contrôle avancé |
4Cas d'usage data sur Kubernetes
Question discriminante
Comment déploieriez-vous Airflow sur Kubernetes ? Quel executor utiliseriez-vous ?
- Airflow sur K8s — KubernetesExecutor : un Pod par tâche, isolation maximale, scaling automatique. Déploiement via Helm chart officiel
- Spark sur K8s — spark-submit en mode cluster, driver et executors dans des Pods dédiés, pas besoin de YARN
- APIs ML (FastAPI/Flask) — Deployment + Service + HorizontalPodAutoscaler pour le scaling automatique selon la charge
- Jobs batch — CronJob K8s pour les pipelines planifiés simples sans Airflow
- MLflow / Ray — serveurs de tracking ou de calcul distribué déployés sur GKE
5Déploiement et configuration
Question discriminante
Comment gérez-vous les mises à jour sans downtime (rolling update) et le rollback en cas de problème ?
# Rolling update automatique (stratégie par défaut)
kubectl set image deployment/api-scoring api=gcr.io/mon-projet/api-scoring:v1.3
# Vérifier le statut
kubectl rollout status deployment/api-scoring
# Rollback vers la version précédente
kubectl rollout undo deployment/api-scoring
# Helm : déploiement et rollback
helm upgrade api-scoring ./chart --set image.tag=v1.3
helm rollback api-scoring 1 # revenir à la release 1
# Ressources requests/limits : obligatoires sur GKE Autopilot
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
- Rolling update — mise à jour progressive sans interruption de service, configurable avec maxSurge et maxUnavailable
- Requests vs Limits — requests pour le scheduling (ressources garanties), limits pour le maximum autorisé
- Liveness et Readiness probes — K8s vérifie que le Pod répond avant d'envoyer du trafic
- Helm — gestionnaire de packages K8s, indispensable pour déployer des applications complexes (Airflow, Spark, etc.)
6Sécurité et optimisation des coûts
- Workload Identity — lier un Service Account K8s à un Service Account Google Cloud pour accéder à GCS, BigQuery sans stocker de clés JSON
- Secrets management — Google Secret Manager intégré via le Secret Store CSI Driver, pas de Secrets K8s en clair
- Spot/Preemptible nodes — réduction des coûts de 60-90% pour les workloads batch tolérants aux interruptions
- Vertical Pod Autoscaler (VPA) — ajustement automatique des requests/limits selon l'utilisation réelle
- Namespaces + RBAC — isolation des équipes et contrôle des accès au cluster
7Grille par niveau
| Niveau | Maîtrise attendue | Signal GO | NO-GO |
|---|
| Junior | Concepts Pod/Node/Cluster, kubectl de base, Deployments, Services | Sait déployer une image Docker sur K8s, comprend le rôle du scheduler | Ne sait pas ce qu'est un Pod, confond Node et Pod |
| Confirmé | GKE Autopilot vs Standard, Helm, ConfigMaps/Secrets, rolling updates | A déployé sur GKE, utilise Helm, configure les requests/limits, sait faire un rollback | N'a jamais utilisé Helm, ne connaît pas GKE Autopilot |
| Senior | Airflow/Spark sur K8s, Workload Identity, autoscaling, optimisation coûts | A déployé Airflow avec KubernetesExecutor, utilise Workload Identity, a configuré des Spot nodes | Ne sait pas déployer Airflow sur K8s, ne connaît pas Workload Identity |
| Lead | Architecture multi-cluster, GitOps (ArgoCD/Flux), standards d'équipe, FinOps | A mis en place une stratégie GitOps, a optimisé les coûts GKE de son équipe | Ne peut pas expliquer sa stratégie de gestion du cluster en production |
Home›Blog›Kubernetes technical interview for data: pods, nodes, GKE, orchestration
Data hiring guide
Kubernetes technical interview for data: pods, nodes, GKE, orchestration
Kubernetes is becoming essential in data teams to orchestrate pipelines, deploy ML APIs and manage Spark or Airflow workloads. Here are the concepts we test to validate a Data Engineer on K8s.
Data Builder·June 2025·8 min read·Data Engineer
Kubernetes (K8s) has become essential in cloud data architectures. Whether orchestrating Airflow on GKE, deploying a FastAPI ML scoring API, or running Spark jobs on Kubernetes, Data Engineers must master the core concepts.
1Core concepts
Key question
What is the difference between a Pod, a Node and a Cluster? What happens if a Pod goes down?
- Pod — basic Kubernetes unit. Contains one or more containers that share the network and storage. Ephemeral by nature
- Node — virtual or physical machine that hosts Pods. Contains: Kubelet (communication with the control plane), Container Runtime (Docker/containerd), Kube-Proxy (networking)
- Cluster — combination of a control plane and nodes. The control plane contains: kube-apiserver, etcd (state storage), kube-scheduler, kube-controller-manager
- Deployment — describes the desired state (number of replicas, image). If a Pod goes down, the Deployment automatically recreates it
- Service — stable abstraction to expose Pods (ClusterIP, NodePort, LoadBalancer)
Key distinction: a Pod is ephemeral — it can be deleted and recreated at any time. Persistent data must be stored in Persistent Volumes, not in the Pod itself.
2Cluster architecture
Key question
What is the role of etcd in a Kubernetes cluster? What happens if etcd becomes unavailable?
# Minimal deployment of a data API in K8s
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-scoring-ml
spec:
replicas: 3
selector:
matchLabels:
app: api-scoring
template:
metadata:
labels:
app: api-scoring
spec:
containers:
- name: api
image: gcr.io/mon-projet/api-scoring:v1.2
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
env:
- name: MODEL_PATH
valueFrom:
secretKeyRef:
name: ml-secrets
key: model-gcs-path
- etcd — key-value store for cluster state. If etcd is unavailable, the cluster can no longer be modified (but running workloads continue)
- kube-scheduler — assigns Pods to Nodes based on available resources and constraints (affinity, taints/tolerations)
- Namespaces — logical isolation within a cluster (dev, staging, prod)
- ConfigMaps and Secrets — configuration and credentials injected into Pods (do not hard-code in the image)
3GKE: Autopilot vs Standard
Key question
In which cases would you choose GKE Autopilot over Standard?
| GKE Autopilot | GKE Standard |
|---|
| Node management | Automatic (Google) | Manual |
| Billing | Per Pod (requested resources) | Per Node (allocated resources) |
| Scaling | Automatic and transparent | Manually configurable |
| Node OS | Container-Optimized OS only | COS, Ubuntu, Windows Server |
| Default security | Workload Identity, secure boot included | Configurable, more control |
| Ideal for | Teams without specialized infra, variable workloads | Specialized workloads, advanced control |
4Data use cases on Kubernetes
Key question
How would you deploy Airflow on Kubernetes? Which executor would you use?
- Airflow on K8s — KubernetesExecutor: one Pod per task, maximum isolation, automatic scaling. Deployment via official Helm chart
- Spark on K8s — spark-submit in cluster mode, driver and executors in dedicated Pods, no need for YARN
- ML APIs (FastAPI/Flask) — Deployment + Service + HorizontalPodAutoscaler for automatic scaling based on load
- Batch jobs — K8s CronJob for simple scheduled pipelines without Airflow
- MLflow / Ray — tracking or distributed compute servers deployed on GKE
5Deployment and configuration
Key question
How do you handle zero-downtime updates (rolling update) and rollback in case of issues?
# Automatic rolling update (default strategy)
kubectl set image deployment/api-scoring api=gcr.io/mon-projet/api-scoring:v1.3
# Check status
kubectl rollout status deployment/api-scoring
# Rollback to previous version
kubectl rollout undo deployment/api-scoring
# Helm: deployment and rollback
helm upgrade api-scoring ./chart --set image.tag=v1.3
helm rollback api-scoring 1 # revert to release 1
# Resources requests/limits: mandatory on GKE Autopilot
resources:
requests:
memory: "512Mi"