Cas pratiques Kubernetes

Contexte : Une API HTTP est déployée via un Deployment Kubernetes pour des tests internes. Le Problème : Le Service associé ne parvient pas à router correctement le trafic car le port du conteneur n'est pas explicitement déclaré. Contraintes : Vous devez corriger uniquement le manifeste YAML du Deployment. L'application écoute sur le port 5000. Livrable attendu : Fournir un Deployment mis à jour incluant la déclaration correcte du containerPort afin d'assurer une configuration claire et cohérente.

Contexte : Une équipe a déployé une application avec un Deployment et un Service afin de l'exposer dans le cluster. Le Problème : Le Service ne route aucun trafic vers les Pods. Après inspection, les Pods sont bien en Running mais aucun endpoint n'est associé au Service. Contraintes : Vous devez corriger uniquement les labels ou selectors dans les manifestes YAML. Aucun changement dans l'image Docker. Deployment : apiVersion: apps/v1 kind: Deployment metadata: name: web-app spec: replicas: 2 selector: matchLabels: app: frontend template: metadata: labels: app: web spec: containers: - name: web image: nginx Livrable attendu : Fournir une version cohérente permettant au Service de cibler correctement les Pods.

Contexte : Vous venez de déployer une petite API Node.js sur un cluster Kubernetes interne pour des tests fonctionnels. Le Problème : Après application du manifeste, le Pod entre immédiatement en état CrashLoopBackOff. Les logs indiquent que l'application tente d'écouter sur le port 3000 alors que la configuration expose un autre port. Contraintes : Vous devez corriger uniquement le fichier YAML fourni. Aucun changement dans l'image Docker ni dans le code applicatif. L'application écoute bien sur le port 3000. Manifest actuel : apiVersion: v1 kind: Pod metadata: name: api-test spec: containers: - name: api image: my-api:latest ports: - containerPort: 8080 Livrable attendu : Fournir une version corrigée du manifeste permettant au Pod de démarrer correctement sans redémarrages en boucle.

Contexte : Une équipe souhaite organiser ses ressources Kubernetes dans un namespace dédié nommé staging. Le Problème : Lors du déploiement, une erreur indique que le namespace staging n'existe pas. Contraintes : Vous devez corriger la configuration sans modifier les images Docker. Toutes les ressources doivent être correctement associées au namespace staging. Livrable attendu : Fournir les manifestes nécessaires permettant la création du namespace et le déploiement correct des ressources associées.

Contexte : Une application de démonstration doit être accessible depuis l'extérieur du cluster Kubernetes pour une présentation client. Le Problème : Actuellement, l'application n'est accessible qu'en interne via ClusterIP. Contraintes : Vous devez créer un Service de type NodePort exposant le port 3000 du conteneur. Aucun Ingress requis. Livrable attendu : Fournir un manifeste YAML complet définissant un Service NodePort correctement configuré permettant un accès externe simplifié.

Contexte : Une application interne doit être rendue tolérante aux pannes simples via la réplication de Pods. Le Problème : Actuellement, l'application est définie via un simple Pod unique, ce qui la rend fragile en cas de crash. Contraintes : Vous devez créer un Deployment avec au moins 3 replicas. L'image utilisée est nginx:alpine. Aucun Service externe requis. Livrable attendu : Fournir un manifeste YAML complet définissant un Deployment scalable garantissant la création et la gestion automatique de plusieurs Pods identiques.

Contexte : Une base de données PostgreSQL doit être déployée dans Kubernetes pour des tests internes. Le Problème : Les données sont perdues à chaque redémarrage du Pod car aucun stockage persistant n'est configuré. Contraintes : Vous devez utiliser un PersistentVolumeClaim simple. Image : postgres:15. Aucun StorageClass spécifique requis. Livrable attendu : Fournir un manifeste YAML incluant un PersistentVolumeClaim et un Deployment ou Pod PostgreSQL utilisant ce volume persistant.

Contexte : Une application web a été déployée avec succès sous forme de Deployment sur un cluster Kubernetes de développement. Le Problème : Les autres Pods du cluster ne parviennent pas à communiquer avec cette application car aucun Service n'est correctement configuré. Contraintes : Vous devez créer ou corriger un Service de type ClusterIP. L'application écoute sur le port 3000. Aucun accès externe requis. Livrable attendu : Fournir un manifeste YAML définissant un Service correctement relié au Deployment via des labels cohérents, permettant la communication interne au cluster.

Contexte : Une application nécessite une variable d'environnement nommée APP_ENV pour fonctionner correctement selon l'environnement. Le Problème : Le Pod est déployé mais l'application affiche une erreur indiquant que la variable APP_ENV est absente. Contraintes : Vous devez définir cette variable directement dans le manifeste YAML. Aucune modification de l'image Docker. Valeur attendue : production. Livrable attendu : Fournir un manifeste Pod ou Deployment correctement configuré avec la variable d'environnement injectée dans le conteneur.

Contexte : Une application nécessite un fichier de configuration externe pour fonctionner selon différents environnements. Le Problème : Les développeurs ont intégré la configuration directement dans l'image, rendant les changements difficiles. Contraintes : Vous devez créer un ConfigMap contenant un fichier config.json et le monter dans le conteneur sous /app/config. Livrable attendu : Fournir les manifestes nécessaires (ConfigMap et Pod ou Deployment) permettant de monter correctement la configuration dans le conteneur.

Contexte : Deux applications web distinctes sont déployées dans le même cluster Kubernetes et doivent être accessibles via des noms de domaine différents. Le Problème : Actuellement, chaque application est exposée via un NodePort distinct, rendant l'architecture peu élégante et difficile à maintenir. Contraintes : Vous devez utiliser un Ingress avec routage basé sur le host. Les Services backend existent déjà. Livrable attendu : Fournir un manifeste Ingress configuré pour router api.example.com vers le service api-service et app.example.com vers app-service.

Contexte : Une application web subit des pics de charge imprévisibles. L'équipe a tenté d'implémenter un autoscaling horizontal. Le Problème : Malgré la configuration d'un HPA, le nombre de Pods ne varie jamais. Les métriques CPU semblent ignorées. Contraintes : Vous devez corriger le manifeste HPA et vérifier les prérequis nécessaires. Aucun changement du code applicatif. Le Deployment cible s'appelle web-app. Livrable attendu : Fournir une configuration HPA valide permettant un scaling automatique basé sur l'utilisation CPU, incluant les spécifications correctes et les ressources requises.

Contexte : Une base de données nécessite des identités réseau stables et un stockage persistant. Le Problème : L'équipe a utilisé un Deployment classique, causant des problèmes d'identité réseau et de persistance. Contraintes : Vous devez remplacer le Deployment par un StatefulSet avec volumeClaimTemplates approprié. Image : postgres:15. Livrable attendu : Fournir un manifeste StatefulSet correct garantissant stockage persistant et identité stable des Pods.

Contexte : Une tâche de migration de données doit être exécutée une seule fois dans le cluster. Le Problème : L'équipe utilise un Deployment classique, ce qui provoque des redémarrages inutiles du traitement. Contraintes : Vous devez créer un Job Kubernetes exécutant le conteneur une seule fois et redémarrant uniquement en cas d'échec. Livrable attendu : Fournir un manifeste Job correctement configuré pour un traitement batch ponctuel.

Contexte : Une application nécessite des identifiants sensibles pour accéder à une base de données externe. Le Problème : Les développeurs ont injecté ces informations directement dans le manifeste Deployment en clair. Contraintes : Vous devez utiliser un objet Secret Kubernetes et l'injecter proprement dans le conteneur via variables d'environnement. Aucun changement du code. Livrable attendu : Fournir les manifestes nécessaires pour créer un Secret et modifier le Deployment afin d'utiliser ces valeurs de manière sécurisée.

Contexte : Une base de données interne doit uniquement être accessible par un microservice spécifique au sein du cluster. Le Problème : Actuellement, tous les Pods du namespace peuvent communiquer avec la base, ce qui ne respecte pas les exigences de sécurité internes. Contraintes : Vous devez créer une NetworkPolicy restreignant l'accès à la base PostgreSQL. Aucun changement dans les images ni dans les Services. Livrable attendu : Fournir un manifeste NetworkPolicy autorisant uniquement le Pod portant le label role: api à accéder au Pod base de données sur le port 5432.

Contexte : Une API en production doit être mise à jour sans interruption de service. Le Problème : Les mises à jour actuelles provoquent des interruptions car la stratégie de rolling update n'est pas configurée explicitement. Contraintes : Vous devez configurer la stratégie RollingUpdate avec maxUnavailable et maxSurge adaptés. Aucun changement dans l'image. Livrable attendu : Fournir un manifeste Deployment configuré pour effectuer des mises à jour progressives sans downtime.

Contexte : Une application critique consomme parfois trop de ressources, impactant les autres workloads du cluster. Le Problème : Aucun request ni limit CPU/memory n'est défini dans le Deployment. Contraintes : Vous devez ajouter des ressources requests et limits raisonnables sans modifier l'image Docker. L'application fonctionne correctement avec 200m CPU et 256Mi mémoire. Livrable attendu : Fournir un manifeste Deployment mis à jour intégrant des requests et limits adaptés garantissant une meilleure gestion des ressources.

Contexte : L'organisation souhaite isoler les équipes frontend et backend dans des namespaces distincts. Le Problème : Actuellement, tous les développeurs disposent d'accès complets au cluster. Contraintes : Vous devez créer deux namespaces et définir des Role et RoleBinding limitant l'accès de chaque équipe à son namespace respectif. Livrable attendu : Fournir les manifestes nécessaires (Namespace, Role, RoleBinding) garantissant une séparation claire des responsabilités via RBAC.

Contexte : Une API interne est déployée sur Kubernetes et utilisée par plusieurs équipes. Depuis quelques jours, des interruptions aléatoires sont observées. Le Problème : Les Pods redémarrent de manière imprévisible car aucune livenessProbe ni readinessProbe n'est configurée. L'application expose un endpoint /health sur le port 3000. Contraintes : Vous devez modifier uniquement le manifeste du Deployment. Aucun changement dans l'image Docker. Les probes doivent être configurées avec des délais cohérents pour éviter les faux positifs. Livrable attendu : Fournir un manifeste Deployment intégrant une livenessProbe et une readinessProbe correctement paramétrées pour stabiliser le service.

Contexte : Une application critique doit survivre à la perte complète d'une zone de disponibilité. Le Problème : Les Pods sont actuellement concentrés dans une seule zone du cluster. Contraintes : Utiliser nodeAffinity et topologySpreadConstraints pour garantir une répartition multi-zone. Livrable attendu : Fournir un manifeste Deployment assurant une distribution équilibrée des Pods entre plusieurs zones afin de garantir la résilience.

Contexte : Plusieurs équipes doivent partager un cluster Kubernetes tout en restant strictement isolées les unes des autres. Le Problème : Les rôles actuels permettent un accès excessif aux ressources inter-namespace. Contraintes : Mettre en place une séparation stricte via Namespace, Role, ClusterRole et RoleBinding. Aucun accès cluster-admin pour les équipes. Livrable attendu : Proposer une architecture RBAC complète permettant une isolation multi-tenant sécurisée et contrôlée.

Contexte : L'équipe souhaite adopter une approche déclarative pour gérer les déploiements Kubernetes. Le Problème : Les déploiements sont actuellement appliqués manuellement via kubectl apply sans traçabilité claire. Contraintes : Utiliser uniquement des manifestes Kubernetes et une stratégie Git centralisée. Aucun outil GitOps externe imposé. Livrable attendu : Décrire une architecture GitOps simplifiée incluant structuration des manifestes et stratégie de versionnement cohérente.

Contexte : Une application haute performance doit être répartie sur plusieurs nœuds pour éviter toute saturation locale. Le Problème : Les Pods sont actuellement planifiés sur le même nœud, créant un point de défaillance unique. Contraintes : Utiliser podAntiAffinity pour forcer la distribution sur différents nœuds. Aucun changement applicatif. Livrable attendu : Fournir un manifeste Deployment intégrant des règles d'affinité garantissant une distribution équilibrée des Pods.

Contexte : Une base de données distribuée est déployée via StatefulSet dans un cluster Kubernetes pour garantir haute disponibilité. Le Problème : Lors d'un redémarrage partiel du cluster, plusieurs Pods redémarrent simultanément, provoquant une perte de quorum et une indisponibilité du service. Contraintes : Vous devez corriger uniquement la configuration Kubernetes. Aucun changement de l'image. Garantir une mise à jour ordonnée et contrôlée des Pods. Manifest actuel (extrait) : apiVersion: apps/v1 kind: StatefulSet spec: replicas: 3 updateStrategy: type: RollingUpdate Livrable attendu : Proposer une configuration robuste incluant gestion appropriée de la stratégie d'update et des PodDisruptionBudget afin d'éviter toute perte simultanée de quorum.

Contexte : Une application interne est déployée dans le cluster mais ne devrait pas être exposée publiquement. Le Problème : Le Service est défini en type LoadBalancer, rendant l'application accessible depuis l'extérieur. Contraintes : Vous devez corriger la configuration pour limiter l'accès interne uniquement sans modifier les Deployments. Livrable attendu : Fournir une configuration sécurisée remplaçant le Service par une alternative adaptée et garantissant l'isolation du service.

Contexte : Une nouvelle version d'une API doit être testée progressivement sur une portion limitée du trafic en production. Le Problème : Les mises à jour classiques RollingUpdate ne permettent pas de diriger un pourcentage précis du trafic vers la nouvelle version. Contraintes : Utiliser uniquement des objets natifs Kubernetes (Deployment, Service). Aucun outil externe comme service mesh. Livrable attendu : Concevoir une architecture permettant un déploiement canary via deux Deployments distincts et une gestion de répartition contrôlée du trafic.

Contexte : Une entreprise souhaite améliorer la gestion des secrets sensibles dans Kubernetes. Le Problème : Les Secrets sont stockés en base64 sans politique de rotation ni séparation claire des responsabilités. Contraintes : Utiliser des mécanismes natifs Kubernetes et structurer une stratégie de rotation sans outil externe. Livrable attendu : Proposer une architecture sécurisée de gestion des secrets incluant segmentation, bonnes pratiques et rotation contrôlée.

Contexte : Un cluster héberge plusieurs workloads critiques et non critiques. Le Problème : Certains Pods essentiels sont évincés lors de pression mémoire car aucune classe QoS n'est correctement définie. Contraintes : Configurer correctement requests et limits pour obtenir une classe Guaranteed pour les Pods critiques. Livrable attendu : Proposer un manifeste garantissant une QoS optimale pour les applications stratégiques du cluster.

Contexte : Une API critique doit rester disponible même lors des opérations de maintenance du cluster. Le Problème : Lors d'un drain de nœud, plusieurs Pods sont évincés simultanément, entraînant une interruption de service. Contraintes : Vous devez créer un PodDisruptionBudget adapté à un Deployment comportant 4 replicas. Aucun changement du code applicatif. Livrable attendu : Fournir un manifeste PodDisruptionBudget garantissant qu'au moins 3 Pods restent disponibles lors des opérations volontaires d'éviction.