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.
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.
Quelle est la différence entre un Pod, un Node et un Cluster ? Que se passe-t-il si un Pod tombe ?
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.
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-pathDans 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é |
Comment déploieriez-vous Airflow sur Kubernetes ? Quel executor utiliseriez-vous ?
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"| 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 |
Premier entretien gratuit. Rapport GO/NO-GO sous 48h.