Questions et Réponses d'Entretien Kubernetes

Introduction

Bienvenue dans ce guide complet conçu pour vous doter des connaissances et de la confiance nécessaires pour exceller lors des entretiens Kubernetes. Que vous débutiez votre parcours dans l'orchestration de conteneurs ou que vous soyez un professionnel expérimenté cherchant à approfondir votre expertise, ce document propose une approche structurée pour maîtriser les concepts de Kubernetes. Nous avons méticuleusement sélectionné un large éventail de questions, couvrant les principes fondamentaux, les considérations architecturales avancées, le dépannage pratique, les défis basés sur des scénarios et les interrogations spécifiques aux rôles pour les développeurs, les administrateurs et les ingénieurs DevOps. Préparez-vous à améliorer votre compréhension, à affiner vos compétences en résolution de problèmes et à naviguer avec assurance dans tout entretien Kubernetes.

Fondamentaux et Concepts Clés de Kubernetes

Qu'est-ce que Kubernetes et pourquoi est-il utilisé ?

Réponse :

Kubernetes est une plateforme d'orchestration de conteneurs open-source qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Il est utilisé pour gérer les complexités de l'exécution des applications en production, garantissant une haute disponibilité, une scalabilité et une utilisation efficace des ressources.

Expliquez la différence entre un Pod et un Conteneur dans Kubernetes.

Réponse :

Un conteneur est un paquet logiciel léger et exécutable qui inclut tout le nécessaire pour exécuter une application. Un Pod est la plus petite unité déployable dans Kubernetes, encapsulant un ou plusieurs conteneurs, des ressources de stockage, une adresse IP réseau unique et des options qui régissent la manière dont les conteneurs doivent s'exécuter. Tous les conteneurs au sein d'un Pod partagent le même espace de noms réseau et peuvent communiquer via localhost.

Qu'est-ce qu'un Nœud (Node) dans Kubernetes ?

Réponse :

Un Nœud est une machine de travail dans Kubernetes, qui peut être une VM ou une machine physique. Chaque Nœud contient les composants nécessaires pour exécuter des Pods, y compris le Kubelet (agent du master), Kube-proxy (proxy réseau) et un runtime de conteneur (par exemple, Docker, containerd).

Décrivez les principaux composants du Plan de Contrôle (Control Plane) de Kubernetes (Nœud Master).

Réponse :

Le Plan de Contrôle comprend le Kube-API Server (expose l'API Kubernetes), etcd (un magasin clé-valeur cohérent et hautement disponible pour les données du cluster), le Kube-Scheduler (surveille les nouveaux Pods et les assigne aux Nœuds) et le Kube-Controller-Manager (exécute des processus de contrôleurs tels que les contrôleurs de Nœuds, de Réplication, d'Endpoints et de Comptes de Service).

Qu'est-ce qu'un Déploiement (Deployment) dans Kubernetes et pourquoi est-il utilisé ?

Réponse :

Un Déploiement est une abstraction de plus haut niveau qui gère l'état désiré de vos Pods et ReplicaSets. Il fournit des mises à jour déclaratives pour les Pods et les ReplicaSets, vous permettant de définir combien de répliques d'une application doivent être en cours d'exécution et comment déployer des mises à jour ou revenir aux versions précédentes.

Comment Kubernetes gère-t-il le réseau pour les Pods ?

Réponse :

Kubernetes attribue une adresse IP unique à chaque Pod. Tous les conteneurs au sein d'un Pod partagent cette IP et peuvent communiquer via localhost. Les Pods sur différents Nœuds peuvent communiquer en utilisant un plugin CNI (Container Network Interface), qui implémente la superposition réseau (network overlay). Kube-proxy gère les règles réseau sur les Nœuds pour permettre la découverte de services et l'équilibrage de charge.

Qu'est-ce qu'un Service dans Kubernetes et quels sont ses types ?

Réponse :

Un Service est une manière abstraite d'exposer une application s'exécutant sur un ensemble de Pods en tant que service réseau. Il fournit une adresse IP stable et un nom DNS pour un groupe de Pods. Les types courants incluent ClusterIP (interne au cluster), NodePort (expose le service sur un port statique sur l'IP de chaque Nœud) et LoadBalancer (expose le service extérieurement en utilisant un équilibreur de charge du fournisseur cloud).

Expliquez le rôle d'un ReplicaSet.

Réponse :

Un ReplicaSet garantit qu'un nombre spécifié de répliques de Pods sont en cours d'exécution à tout moment. Son objectif principal est de maintenir la stabilité et la disponibilité d'un ensemble de Pods. Bien que vous puissiez utiliser les ReplicaSets directement, ils sont généralement gérés par les Déploiements pour des fonctionnalités plus avancées comme les mises à jour progressives (rolling updates).

Qu'est-ce que kubectl et quelle est sa fonction principale ?

Réponse :

kubectl est l'outil en ligne de commande pour interagir avec un cluster Kubernetes. Il permet aux utilisateurs d'exécuter des commandes sur les clusters Kubernetes, de déployer des applications, d'inspecter et de gérer les ressources du cluster, et de visualiser les journaux. Il communique avec le serveur API Kubernetes.

Quel est le rôle de etcd dans Kubernetes ?

Réponse :

etcd est un magasin clé-valeur distribué, cohérent et hautement disponible utilisé par Kubernetes pour stocker toutes les données du cluster. Cela inclut les données de configuration, les informations d'état, les métadonnées et l'état désiré du cluster. Il agit comme la source unique de vérité pour le cluster Kubernetes.

Sujets Avancés et Architecture de Kubernetes

Expliquez le concept d'un Opérateur Kubernetes et donnez un exemple d'utilisation.

Réponse :

Un Opérateur Kubernetes est une méthode pour empaqueter, déployer et gérer une application native à Kubernetes. Il étend l'API Kubernetes pour créer, configurer et gérer des instances d'applications complexes. Vous utiliseriez un Opérateur pour des applications stateful comme les bases de données (par exemple, Cassandra, MySQL) afin d'automatiser des tâches telles que les sauvegardes, les mises à niveau et la mise à l'échelle.

Décrivez le rôle d'une Définition de Ressource Personnalisée (Custom Resource Definition - CRD) dans Kubernetes.

Réponse :

Une Définition de Ressource Personnalisée (CRD) vous permet de définir vos propres ressources personnalisées dans Kubernetes, étendant ainsi l'API Kubernetes. Cela vous permet de stocker et de récupérer des données structurées que Kubernetes peut gérer. Les CRDs sont fondamentales pour la création d'Opérateurs et la définition d'objets spécifiques à une application.

Comment le serveur API Kubernetes gère-t-il l'authentification et l'autorisation des requêtes ?

Réponse :

Le serveur API gère l'authentification via diverses méthodes telles que les certificats clients, les jetons porteurs (bearer tokens) ou les jetons de compte de service. Après l'authentification, l'autorisation est effectuée à l'aide de modules tels que RBAC (Role-Based Access Control), l'autorisation de Nœud (Node authorization) ou ABAC (Attribute-Based Access Control). RBAC est le plus courant, définissant des rôles avec des permissions et les liant à des utilisateurs ou des comptes de service.

Quelle est la différence entre un DaemonSet et un Deployment dans Kubernetes ?

Réponse :

Un Deployment gère un ensemble de pods identiques, garantissant qu'un nombre désiré de répliques sont en cours d'exécution dans le cluster, généralement pour des applications stateless. Un DaemonSet garantit que tous les nœuds (ou certains d'entre eux) exécutent une copie d'un pod, ce qui est utile pour les services au niveau du cluster tels que les collecteurs de logs (par exemple, Fluentd) ou les agents de surveillance (par exemple, Node Exporter) qui doivent s'exécuter sur chaque nœud.

Expliquez le concept des Politiques de Sécurité des Pods (Pod Security Policies - PSPs) et pourquoi elles sont dépréciées.

Réponse :

Les Politiques de Sécurité des Pods (PSPs) étaient un contrôleur d'admission qui appliquait des normes de sécurité aux pods et aux conteneurs. Elles permettaient aux administrateurs de cluster de contrôler des aspects sensibles à la sécurité tels que le mode privilégié, l'accès au réseau hôte et les types de volumes. Les PSPs sont dépréciées au profit de l'Admission de Sécurité des Pods (Pod Security Admission - PSA) et de moteurs de politiques comme OPA Gatekeeper, qui offrent un contrôle plus flexible et granulaire.

Comment obtenir une haute disponibilité pour le plan de contrôle Kubernetes ?

Réponse :

La haute disponibilité pour le plan de contrôle est obtenue en exécutant plusieurs instances du serveur API, d'etcd, du Controller Manager et du Scheduler. etcd s'exécute généralement en tant que cluster basé sur un quorum (par exemple, 3 ou 5 nœuds). Un équilibreur de charge est placé devant les serveurs API pour distribuer le trafic et assurer le basculement (failover).

Qu'est-ce qu'un webhook d'admission mutateur (mutating admission webhook) et comment peut-il être utilisé ?

Réponse :

Un webhook d'admission mutateur est un rappel HTTP qui peut modifier les requêtes adressées au serveur API Kubernetes avant qu'elles ne soient persistées. Il peut injecter des conteneurs sidecar, ajouter des labels/annotations, ou définir des valeurs par défaut pour des champs. Par exemple, il peut injecter automatiquement un sidecar istio-proxy dans les pods pour l'intégration de la mesh de services.

Décrivez le rôle d'etcd dans un cluster Kubernetes.

Réponse :

etcd sert de magasin clé-valeur cohérent et hautement disponible pour Kubernetes. Il stocke toutes les données du cluster, y compris la configuration, l'état et les métadonnées de tous les objets Kubernetes (pods, déploiements, services, etc.). Il est essentiel au fonctionnement du cluster, et sa disponibilité a un impact direct sur la santé du cluster.

Comment Kubernetes gère-t-il l'application des politiques réseau ?

Réponse :

Les Politiques Réseau (Network Policies) de Kubernetes sont des spécifications qui définissent comment les groupes de pods sont autorisés à communiquer entre eux et avec des points d'extrémité externes. Elles sont implémentées par un plugin réseau (CNI) qui prend en charge NetworkPolicy, tel que Calico, Cilium ou Weave Net. Le plugin CNI traduit ces politiques en règles de pare-feu.

Que sont les Taints et les Tolerations, et comment sont-ils utilisés pour la planification des pods ?

Réponse :

Les Taints sont appliqués aux nœuds, les marquant comme "inappropriés" pour certains pods, à moins que ces pods n'aient des Tolerations correspondantes. Les Tolerations sont appliquées aux pods, leur permettant d'être planifiés sur des nœuds taints. Ce mécanisme est utilisé pour réserver des nœuds pour des charges de travail spécifiques (par exemple, des nœuds GPU) ou pour évincer des pods de nœuds non sains.

Questions Basées sur des Scénarios et de Conception

Les pods de votre application redémarrent fréquemment. Comment diagnostiqueriez-vous ce problème dans Kubernetes ?

Réponse :

Je commencerais par vérifier kubectl describe pod <nom-du-pod> pour les événements et le statut. Ensuite, j'utiliserais kubectl logs <nom-du-pod> pour examiner les logs de l'application à la recherche d'erreurs. Enfin, j'inspecterais kubectl logs <nom-du-pod> -p pour les logs des instances de conteneur précédentes afin de comprendre la cause du crash.

Vous devez déployer une nouvelle version de votre application sans interruption de service (downtime). Comment y parviendriez-vous dans Kubernetes ?

Réponse :

J'utiliserais une stratégie RollingUpdate pour le Deployment. Cela permet à Kubernetes de remplacer progressivement les anciens pods par de nouveaux, garantissant qu'un nombre minimum de pods soient toujours disponibles. Les vérifications de santé (readiness probes) sont cruciales pour s'assurer que les nouveaux pods sont prêts avant que le trafic ne leur soit acheminé.

Décrivez un scénario où vous utiliseriez un StatefulSet au lieu d'un Deployment.

Réponse :

J'utiliserais un StatefulSet pour les applications qui nécessitent des identifiants réseau stables et uniques, un stockage persistant stable, et un déploiement/une mise à l'échelle/une suppression ordonnés et gracieux. Les exemples incluent les bases de données comme PostgreSQL ou les systèmes distribués comme Apache Kafka, où chaque réplique a besoin de son propre volume persistant et d'un nom d'hôte prévisible.

Votre cluster Kubernetes manque de ressources (CPU/Mémoire). Quelles mesures prendriez-vous pour diagnostiquer et atténuer ce problème ?

Réponse :

Premièrement, j'utiliserais kubectl top nodes et kubectl top pods pour identifier les consommateurs de ressources excessifs. Ensuite, je vérifierais les requêtes et les limites de ressources sur les pods pour m'assurer qu'elles sont correctement définies. Les mesures d'atténuation incluent l'optimisation de l'utilisation des ressources par l'application, la mise à l'échelle horizontale du cluster, ou l'ajustement des requêtes/limites de ressources.

Comment exposeriez-vous une application web s'exécutant dans Kubernetes à Internet de manière sécurisée ?

Réponse :

J'utiliserais un Service Kubernetes de type LoadBalancer ou NodePort pour exposer l'application au sein du cluster ou au trafic externe. Pour un accès HTTP/HTTPS sécurisé, je déploierais un contrôleur Ingress (par exemple, Nginx Ingress) et définirais des ressources Ingress avec terminaison TLS, en m'intégrant souvent avec Cert-Manager pour le provisionnement automatisé de certificats.

Vous devez exécuter une tâche batch unique qui traite des données puis se termine. Quel objet Kubernetes utiliseriez-vous ?

Réponse :

J'utiliserais un objet Job Kubernetes. Un Job garantit qu'un nombre spécifié de pods achèvent leurs tâches avec succès. Pour les tâches récurrentes, j'utiliserais un CronJob, qui crée des objets Job selon un calendrier défini.

Concevez une stratégie de haute disponibilité pour un microservice critique dans Kubernetes.

Réponse :

Je déploierais le microservice en tant que Deployment avec plusieurs répliques (par exemple, 3 ou plus) réparties sur différents nœuds en utilisant des règles d'anti-affinité. J'implémenterais des sondes de readiness et de liveness robustes. Pour la persistance des données, j'utiliserais une base de données distribuée ou un StatefulSet avec des volumes persistants. Enfin, je m'assurerais de la configuration appropriée des requêtes/limites de ressources et de l'autoscaling.

Comment géreriez-vous les informations sensibles comme les clés API ou les identifiants de base de données pour vos applications dans Kubernetes ?

Réponse :

J'utiliserais les Secrets Kubernetes pour stocker les informations sensibles. Ces secrets peuvent être montés en tant que fichiers dans les pods ou exposés en tant que variables d'environnement. Pour une sécurité renforcée, je m'intégrerais avec des systèmes de gestion de secrets externes comme HashiCorp Vault ou les services KMS des fournisseurs cloud.

Votre application doit accéder à une base de données s'exécutant en dehors du cluster Kubernetes. Comment configureriez-vous cela en toute sécurité ?

Réponse :

Je créerais un Service Kubernetes de type ExternalName ou un Service headless avec des Endpoints pour représenter la base de données externe au sein du cluster. Cela permet aux pods de résoudre la base de données par un nom de service Kubernetes. Des politiques réseau seraient utilisées pour restreindre le trafic sortant uniquement à l'IP et au port de la base de données, et les identifiants seraient gérés via les Secrets Kubernetes.

Vous observez que le temps de réponse de votre application augmente sous une forte charge. Comment mettriez-vous à l'échelle votre application dans Kubernetes pour gérer cela ?

Réponse :

J'implémenterais l'Autoscaling Horizontal de Pods (Horizontal Pod Autoscaling - HPA) pour le Deployment, configuré pour s'adapter en fonction de l'utilisation du CPU ou de métriques personnalisées comme les requêtes par seconde. Cela ajoute automatiquement plus de répliques de pods lorsque la demande augmente. Je m'assurerais également que le cluster sous-jacent dispose d'une capacité de nœuds suffisante ou j'implémenterais le Cluster Autoscaler.

Questions Spécifiques aux Rôles (Développeur, Administrateur, DevOps)

Développeur : Comment diagnostiqueriez-vous un Pod bloqué dans un état 'Pending' ?

Réponse :

Je commencerais par vérifier kubectl describe pod <nom-du-pod> pour les événements indiquant des problèmes tels que des ressources insuffisantes (CPU/mémoire), des problèmes d'affinité de nœud/taint, ou des revendications de volume persistant non liées. Ensuite, j'inspecterais les conditions du nœud et la disponibilité des ressources en utilisant kubectl describe node <nom-du-nœud>.

Développeur : Vous devez déployer une nouvelle version de votre application. Quelle est la manière la plus sûre de le faire dans Kubernetes pour minimiser les interruptions de service ?

Réponse :

J'utiliserais une stratégie RollingUpdate pour le Deployment. Cela remplace progressivement les anciens Pods par de nouveaux, garantissant une disponibilité continue. Je définirais également des sondes de readiness pour m'assurer que les nouveaux Pods sont sains avant que le trafic ne leur soit acheminé.

Administrateur : Un utilisateur signale qu'il ne peut pas accéder à un service s'exécutant dans le cluster. Quelles mesures prendriez-vous pour diagnostiquer le problème ?

Réponse :

Je commencerais par vérifier kubectl describe service <nom-du-service> pour vérifier sa configuration et la disponibilité des endpoints. Ensuite, j'inspecterais les Pods qui supportent le service pour leur état de santé (kubectl get pods -o wide) et je vérifierais leurs logs pour les erreurs d'application. Les politiques réseau ou les règles de pare-feu pourraient également être un facteur.

Administrateur : Comment vous assurez-vous que seuls les utilisateurs autorisés peuvent accéder à des ressources spécifiques au sein d'un cluster Kubernetes ?

Réponse :

J'implémenterais le contrôle d'accès basé sur les rôles (Role-Based Access Control - RBAC). Cela implique de définir des Roles (permissions au sein d'un namespace) ou des ClusterRoles (permissions à l'échelle du cluster) et de les lier ensuite à des utilisateurs ou des comptes de service en utilisant des RoleBindings ou des ClusterRoleBindings.

Administrateur : Décrivez un scénario où vous utiliseriez une NetworkPolicy.

Réponse :

J'utiliserais une NetworkPolicy pour contrôler le flux de trafic entre les Pods ou entre les Pods et les points d'extrémité externes. Par exemple, pour isoler un Pod de base de données afin que seuls des Pods d'application spécifiques puissent s'y connecter, ou pour restreindre le trafic sortant d'un namespace de développement.

DevOps : Comment gérez-vous les secrets (par exemple, clés API, identifiants de base de données) de manière sécurisée dans Kubernetes ?

Réponse :

Bien que les Secrets Kubernetes fournissent un encodage de base, pour une sécurité réelle, je m'intégrerais avec des solutions de gestion de secrets externes comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault. Ces solutions peuvent injecter des secrets directement dans les Pods ou utiliser des pilotes CSI pour le montage dynamique, évitant ainsi de stocker des données sensibles directement dans Git.

DevOps : Expliquez le rôle d'un chart Helm et comment il bénéficie aux pipelines CI/CD.

Réponse :

Un chart Helm est un gestionnaire de paquets pour Kubernetes, regroupant toutes les ressources Kubernetes nécessaires (Deployments, Services, ConfigMaps, etc.) en une seule unité versionnable. Dans CI/CD, il permet des déploiements cohérents et répétables entre les environnements, des mises à niveau/rétrogradations de version faciles, et la paramétrisation des configurations.

DevOps : Comment implémenteriez-vous le déploiement continu pour une application de microservices sur Kubernetes ?

Réponse :

J'utiliserais une approche GitOps avec un outil comme Argo CD ou Flux. Une fois le code fusionné et testé, un pipeline CI construit l'image Docker et met à jour le tag de l'image dans le manifeste Kubernetes (par exemple, dans un dépôt Git). L'opérateur GitOps détecte ensuite le changement dans Git et l'applique automatiquement au cluster, assurant la synchronisation de l'état désiré.

DevOps : Quelles sont les métriques clés que vous surveilleriez pour un cluster Kubernetes et ses applications ?

Réponse :

Pour le cluster, je surveillerais l'utilisation des ressources des nœuds (CPU, mémoire, disque), la latence du serveur API et la santé d'etcd. Pour les applications, les métriques clés incluent l'utilisation du CPU/mémoire des Pods, les taux de requêtes, les taux d'erreurs, la latence et les métriques métier spécifiques à l'application. Prometheus et Grafana sont des outils courants pour cela.

DevOps : Décrivez comment vous géreriez le stockage persistant pour les applications stateful dans Kubernetes.

Réponse :

J'utiliserais des PersistentVolumes (PVs) et des PersistentVolumeClaims (PVCs). Une PVC demande du stockage à un PV, qui est provisionné par une StorageClass. Cela abstrait l'infrastructure de stockage sous-jacente, permettant aux applications de demander du stockage sans connaître ses spécificités, et assure la persistance des données même si les Pods sont replanifiés.

Dépannage et Débogage de Kubernetes

Votre pod est bloqué dans l'état 'Pending'. Quelles sont les raisons courantes et comment le dépanner ?

Réponse :

Les raisons courantes incluent des ressources insuffisantes (CPU/mémoire), des taints/tolérances de nœud, ou des problèmes de volume persistant. J'utiliserais kubectl describe pod <nom-du-pod> pour vérifier les événements de défaillance de planification, les requêtes de ressources et l'état de liaison des volumes.

Un pod est dans l'état 'CrashLoopBackOff'. Qu'est-ce que cela indique et comment le déboguer ?

Réponse :

Cela indique que le conteneur à l'intérieur du pod démarre et plante de manière répétée. Je vérifierais d'abord kubectl logs <nom-du-pod> pour les erreurs d'application. Si les logs ne sont pas utiles, j'utiliserais kubectl describe pod <nom-du-pod> pour rechercher des événements OOMKilled ou des échecs de sondes de readiness/liveness.

Comment vérifier les logs d'un conteneur spécifique dans un pod multi-conteneurs ?

Réponse :

Vous pouvez spécifier le nom du conteneur en utilisant l'indicateur -c avec kubectl logs. Par exemple : kubectl logs <nom-du-pod> -c <nom-du-conteneur>. Cela permet d'isoler les logs d'un service particulier.

Un service n'est pas accessible depuis l'extérieur du cluster. Quelles mesures prendriez-vous pour diagnostiquer cela ?

Réponse :

Je vérifierais le type de service (par exemple, NodePort, LoadBalancer) et son IP/port externe. Ensuite, je vérifierais les règles de pare-feu, les groupes de sécurité et les politiques réseau. Enfin, je vérifierais si les sélecteurs du service correspondent correctement aux labels des pods et si les pods sont en cours d'exécution et sains.

Vous suspectez qu'une politique réseau bloque le trafic vers votre application. Comment le confirmer ?

Réponse :

J'utiliserais kubectl describe networkpolicy <nom-de-la-politique> pour comprendre ses règles. Ensuite, je vérifierais les labels et les namespaces du pod pour voir s'ils sont ciblés par des politiques. Des outils comme kube-no-trouble ou netshoot dans un pod de débogage peuvent également aider à tester la connectivité.

Comment obtenir un shell dans un conteneur en cours d'exécution à des fins de débogage ?

Réponse :

Vous pouvez utiliser kubectl exec -it <nom-du-pod> -- /bin/bash (ou /bin/sh si bash n'est pas disponible). Cela vous permet d'inspecter le système de fichiers du conteneur, d'exécuter des commandes et de diagnostiquer les problèmes directement dans son environnement.

Quelles sont les causes courantes de 'ImagePullBackOff' et comment les dépanner ?

Réponse :

Les causes courantes incluent un nom/tag d'image incorrect, des problèmes d'authentification de registre privé, ou des problèmes de connectivité réseau vers le registre. Je vérifierais kubectl describe pod <nom-du-pod> pour les erreurs de tirage d'image et je vérifierais les noms d'image, les identifiants de registre (secrets) et l'accès réseau.

Votre application connaît une latence élevée, mais les pods semblent sains. Quel pourrait être le problème ?

Réponse :

Cela pourrait indiquer une contention de ressources (étranglement CPU), un code d'application inefficace, ou des problèmes avec des dépendances externes. Je vérifierais les métriques d'utilisation des ressources (CPU/mémoire) pour les pods, j'examinerais les logs de l'application pour les requêtes lentes, et j'inspecterais la latence réseau vers les services externes.

Comment déboguer un échec de sonde de liveness ou de readiness ?

Réponse :

Je vérifierais kubectl describe pod <nom-du-pod> pour les événements d'échec de sonde et la commande/le chemin spécifique utilisé. Ensuite, j'utiliserais kubectl logs <nom-du-pod> pour voir si l'application plante ou ne répond pas au point d'extrémité de la sonde. L'exécution manuelle de la commande de sonde à l'intérieur du conteneur peut également aider.

Un nœud est dans l'état 'NotReady'. Quelles sont les raisons typiques et comment enquêter ?

Réponse :

Les raisons typiques incluent le kubelet qui ne s'exécute pas, des problèmes réseau empêchant la communication avec le plan de contrôle, ou des ressources de nœud insuffisantes. Je me connecterais au nœud via SSH, je vérifierais systemctl status kubelet, j'examinerais les logs du kubelet (journalctl -u kubelet), et je vérifierais la connectivité réseau au serveur API.

Meilleures Pratiques et Sécurité Kubernetes

Quelles sont les meilleures pratiques clés pour sécuriser les clusters Kubernetes ?

Réponse :

Les pratiques clés incluent la mise en œuvre du contrôle d'accès basé sur les rôles (RBAC) avec le principe du moindre privilège, la mise à jour régulière de Kubernetes et de ses composants, l'analyse des images de conteneurs pour les vulnérabilités, la segmentation réseau à l'aide de Network Policies, et la sécurisation de l'accès au serveur API.

Expliquez le principe du 'moindre privilège' dans le RBAC de Kubernetes.

Réponse :

Le moindre privilège signifie accorder aux utilisateurs et aux comptes de service uniquement les permissions minimales nécessaires pour accomplir leurs tâches. Cela minimise l'impact potentiel en cas de compromission d'un compte, réduisant ainsi la surface d'attaque au sein du cluster.

Comment les Network Policies améliorent-elles la sécurité dans un cluster Kubernetes ?

Réponse :

Les Network Policies définissent comment les pods sont autorisés à communiquer entre eux et avec des points d'extrémité externes. Elles agissent comme des pare-feu au niveau du pod, permettant la segmentation réseau et l'isolement des charges de travail sensibles pour empêcher toute communication non autorisée.

Quelle est l'importance de l'analyse d'images dans un pipeline CI/CD pour les déploiements Kubernetes ?

Réponse :

L'analyse d'images identifie les vulnérabilités connues (CVE) et les mauvaises configurations dans les images de conteneurs avant le déploiement. Son intégration dans CI/CD garantit que seules des images sécurisées et conformes sont poussées vers les registres et déployées dans le cluster, empêchant ainsi l'exécution de logiciels vulnérables.

Décrivez une méthode courante pour gérer les secrets en toute sécurité dans Kubernetes.

Réponse :

Bien que les Secrets Kubernetes fournissent un stockage de base, ils sont encodés en base64, et non chiffrés au repos par défaut. Les meilleures pratiques impliquent l'utilisation de solutions de gestion de secrets externes comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault, souvent intégrées via des pilotes CSI ou des opérateurs de secrets externes, pour chiffrer et gérer les données sensibles.

Que sont les Pod Security Standards (PSS) et pourquoi sont-ils importants ?

Réponse :

Les Pod Security Standards sont des contrôles de sécurité intégrés qui définissent différents niveaux d'isolation pour les pods (Privileged, Baseline, Restricted). Ils aident à appliquer les meilleures pratiques de sécurité en empêchant les pods de s'exécuter avec des paramètres trop permissifs, tels que l'accès root ou les montages de chemins hôtes.

Comment pouvez-vous prévenir les attaques d'escalade de privilèges au sein d'un cluster Kubernetes ?

Réponse :

La prévention de l'escalade de privilèges implique plusieurs mesures : l'application des Pod Security Standards, l'utilisation de conteneurs immuables, la limitation de l'accès hôte, la mise en œuvre d'un RBAC strict, et l'audit régulier des configurations du cluster et des activités des utilisateurs. Limiter les capacités et interdire les conteneurs privilégiés sont cruciaux.

Quel est le rôle d'un Service Mesh (par exemple, Istio, Linkerd) dans la sécurité Kubernetes ?

Réponse :

Un Service Mesh améliore la sécurité en fournissant des fonctionnalités telles que le mTLS (mutual TLS) pour la communication chiffrée entre les services, des politiques de contrôle d'accès granulaires, et le chiffrement du trafic. Il centralise les configurations de sécurité et l'observabilité pour la communication des microservices.

Expliquez le concept d'« infrastructure immuable » dans Kubernetes.

Réponse :

L'infrastructure immuable signifie qu'une fois qu'un composant (comme une image de conteneur ou une application déployée) est construit et déployé, il n'est jamais modifié. Tout changement nécessite la construction d'une nouvelle image et le remplacement de l'ancienne instance, ce qui améliore la cohérence, la fiabilité et la sécurité en réduisant la dérive de configuration.

Comment les quotas de ressources et les limit ranges contribuent-ils à la stabilité et à la sécurité du cluster ?

Réponse :

Les quotas de ressources limitent la quantité totale de CPU, de mémoire et d'autres ressources qui peuvent être consommées par un namespace, empêchant ainsi l'épuisement des ressources. Les limit ranges définissent les requêtes/limites de ressources par défaut et maximales pour les pods au sein d'un namespace, garantissant que les applications ne consomment pas de ressources excessives et améliorant la stabilité et l'équité du cluster.

Défis Kubernetes Pratiques et Concrets

Vous avez un Pod qui plante continuellement. Comment dépanneriez-vous ce problème ?

Réponse :

Je commencerais par vérifier kubectl describe pod <nom-du-pod> pour les événements et le statut. Ensuite, j'utiliserais kubectl logs <nom-du-pod> pour examiner les logs de l'application. S'il s'agit d'une boucle de crash, je vérifierais kubectl logs --previous <nom-du-pod> pour les logs du dernier conteneur terminé.

Un Deployment est bloqué dans un état en attente (pending). Quelles sont les raisons courantes et comment les diagnostiquer ?

Réponse :

Les raisons courantes incluent des ressources insuffisantes (CPU/mémoire), des taints/tolérances de nœud, ou des problèmes de sélecteurs de nœud/affinité. J'utiliserais kubectl describe pod <nom-du-pod> pour voir les événements de planification et kubectl get events --field-selector involvedObject.kind=Node pour vérifier les conditions des nœuds.

Comment exposeriez-vous une application sans état s'exécutant dans un Deployment au trafic externe ?

Réponse :

Je créerais un Service de type LoadBalancer ou NodePort pour exposer le Deployment. Pour un routage plus avancé et une terminaison SSL, j'utiliserais une ressource Ingress, qui nécessite un Ingress Controller.

Vous devez effectuer une mise à jour progressive (rolling update) d'un Deployment sans interruption de service. Comment Kubernetes gère-t-il cela, et quelles sont les considérations clés ?

Réponse :

Les Deployments Kubernetes gèrent les mises à jour progressives par défaut, en créant de nouveaux Pods avant de terminer les anciens en fonction des paramètres maxUnavailable et maxSurge. Les considérations clés incluent des sondes de readiness appropriées, une allocation de ressources suffisante et des tests de la nouvelle version avant le déploiement complet.

Décrivez un scénario où vous utiliseriez un ConfigMap par rapport à un Secret.

Réponse :

J'utiliserais un ConfigMap pour les données de configuration non sensibles, comme les variables d'environnement de l'application ou les fichiers de configuration. J'utiliserais un Secret pour les données sensibles, telles que les clés API, les identifiants de base de données ou les certificats TLS, qui sont stockés chiffrés par défaut.

Comment vous assurez-vous qu'un Pod ne s'exécute que sur des nœuds disposant d'un matériel spécifique (par exemple, des GPU) ?

Réponse :

J'utiliserais des Node Selectors ou Node Affinity. Les Node Selectors sont plus simples pour les correspondances exactes (nodeSelector: {gpu: 'true'}). Node Affinity offre plus de flexibilité avec les règles requiredDuringSchedulingIgnoredDuringExecution ou preferredDuringSchedulingIgnoredDuringExecution.

Un Service ne route pas le trafic vers ses Pods. Quelles étapes suivriez-vous pour déboguer cela ?

Réponse :

Tout d'abord, je vérifierais kubectl describe service <nom-du-service> pour m'assurer que son sélecteur correspond aux labels des Pods. Ensuite, je vérifierais kubectl get endpoints <nom-du-service> pour voir si des IPs de Pods sont listées. Enfin, je m'assurerais que les Pods sont sains et que leurs sondes de readiness réussissent.

Vous devez exécuter une tâche unique, comme une migration de base de données, au sein de votre cluster. Quelle ressource Kubernetes utiliseriez-vous ?

Réponse :

J'utiliserais une ressource Kubernetes Job. Un Job crée un ou plusieurs Pods et s'assure qu'un nombre spécifié d'entre eux se terminent avec succès. Pour les tâches planifiées, j'utiliserais un CronJob.

Expliquez le but d'un PersistentVolume (PV) et d'un PersistentVolumeClaim (PVC).

Réponse :

Un PersistentVolume (PV) est un morceau de stockage dans le cluster provisionné par un administrateur. Un PersistentVolumeClaim (PVC) est une demande de stockage par un utilisateur. Le PVC se lie à un PV approprié, permettant aux Pods de consommer un stockage durable indépendamment de leur cycle de vie.

Comment mettriez-vous à l'échelle un Deployment manuellement et automatiquement ?

Réponse :

Manuellement, j'utiliserais kubectl scale deployment <nom-du-deployment> --replicas=<nombre>. Automatiquement, j'utiliserais un Horizontal Pod Autoscaler (HPA), qui ajuste le nombre de Pods dans un Deployment ou un ReplicaSet en fonction de l'utilisation observée du CPU ou d'autres métriques personnalisées.

Résumé

Passer un entretien Kubernetes peut être une expérience difficile mais enrichissante. Ce document a fourni un aperçu complet des questions courantes et des réponses éclairées, conçues pour vous doter des connaissances et de la confiance nécessaires pour exceller. N'oubliez pas qu'une préparation approfondie est primordiale ; la compréhension des concepts fondamentaux, des applications pratiques et des scénarios de dépannage améliorera considérablement vos performances.

Au-delà de l'entretien, le parcours avec Kubernetes est celui de l'apprentissage et de l'adaptation continus. Le paysage évolue rapidement, et rester curieux, expérimenter de nouvelles fonctionnalités et s'engager avec la communauté garantira que vos compétences restent aiguisées et pertinentes. Embrassez les défis, célébrez vos succès et continuez à développer votre expertise dans cette technologie dynamique et essentielle.