Les 44 meilleures questions d'entretien sur Kubernetes et leurs réponses en 2025

Questions d'entretien de base sur Kubernetes

Commençons maintenant par les questions d'entretien de base sur Kubernetes. Ces questions couvrent les connaissances fondamentales nécessaires pour comprendre et travailler avec Kubernetes. 

Qu'est-ce qu'un pod dans Kubernetes ?

Un pod est la plus petiteunitédéployable dans Kubernetes. Il représente un ou plusieurs conteneurs fonctionnant dans un environnement partagé. Les conteneurs à l'intérieur d'un pod partagent les ressources de réseau et de stockage.

Voici un simple fichier YAML de définition d'un pod :

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Quel est l'objectif de kubectl ?

Kubectl est le principal outil CLI pour gérer les ressources Kubernetes et interagir avec le cluster. Voici quelques commandes kubectl courantes que vous devriez connaître :

kubectl get pods 				 # list all Pods
kubectl get services 			 # list all Services
kubectl logs <pod-name> 	  	 # view logs of a Pod
kubectl exec -it <pod-name> – /bin/sh # open a shell inside a Pod

Qu'est-ce qu'un déploiement dans Kubernetes ?

Un déploiement dans Kubernetes est une abstraction de niveau supérieur qui gère le cycle de vie des pods. Il garantit que le nombre souhaité de répliques est opérationnel et offre des fonctionnalités telles que les mises à jour en continu, les retours en arrière et l'autorégénération. 

Voici à quoi ressemble un simple fichier YAML de définition de déploiement : 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Qu'est-ce qu'un service Kubernetes et pourquoi est-il nécessaire ?

Un service dans Kubernetes expose un groupe de pods et permet la communication entre eux et vers eux. 

Les pods étant éphémères, leurs adresses IP peuvent changer, ce qui signifie que l'application qui communique avec les pods doit également changer d'adresse IP. Les services fournissent donc un point d'extrémité de réseau stable avec une adresse IP fixe.

Une simple définition YAML d'un service :

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Le service ci-dessus achemine le trafic vers les Pods qui ont l'étiquette app: my-app.

Quels sont les types de services disponibles dans les services Kubernetes ?

Kubernetes fournit quatre types principaux de services, chacun servant un objectif de mise en réseau différent :

• ClusterIP (par défaut) : Permet la communication interne des pods. Uniquement accessible depuis l'intérieur du cluster.
• NodePort : Le service est ainsi exposé sur un port statique de chaque nœud, ce qui le rend accessible depuis l'extérieur du cluster.
• LoadBalancer : Utilise l'équilibreur de charge externe d'un fournisseur de cloud. Le service est alors accessible via une IP publique.
• Nom externe : Associe un service Kubernetes à un nom d'hôte externe. 

Quel est le rôle des ConfigMaps et des secrets dans Kubernetes ?

ConfigMaps stocke les données de configuration non sensibles, tandis que secrets stocke les données sensibles telles que les clés d'API et les mots de passe.

L'utilisation de secrets vous permet d'éviter d'introduire des informations secrètes dans le code de votre application. En revanche, les ConfigMaps vous permettront de rendre vos applications plus configurables, car ces valeurs peuvent être facilement modifiées et vous n'avez pas besoin de les conserver dans le code de votre application.

Exemple de définition YAML de ConfigMap :

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"

Exemple de définition YAML secrète (avec des données encodées en base64) :

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" encoded in Base64

Que sont les espaces de noms dans Kubernetes ?

Un espace de nommage est un cluster virtuel au sein d'un cluster Kubernetes. Il permet d'organiser les charges de travail dans des environnements multi-locataires en isolant les ressources au sein d'un cluster.

Vous trouverez ci-dessous un court extrait de code qui montre comment créer un Namespace à l'aide de kubectl et comment créer et récupérer des Pods dans ce Namespace :

# create a namespace called “dev”
kubectl create namespace dev

# create a Pod in that namespace
kubectl run nginx --image=nginx --namespace=dev

# get Pods in that namespace
kubectl get pods --namespace=dev

Que sont les étiquettes et les sélecteurs dans Kubernetes ?

Les étiquettes sont des paires clé/valeur attachées aux objets (par exemple, les pods). Ils permettent d'organiser les objets Kubernetes. Les sélecteurs filtrent les ressources en fonction des étiquettes. 

Voici un exemple de Pod avec les étiquettes environment: production et app: nginx:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Vous pouvez maintenant utiliser le sélecteur d'étiquettes suivant pour rechercher tous les pods auxquels l'étiquette environment: pod a été attribuée :

kubectl get pods -l environment=production

Qu'est-ce qu'un volume persistant (PV) et une revendication de volume persistant (PVC) ?

Les volumes persistants (PV) fournissent un stockage qui persiste au-delà des cycles de vie des pods. Le PV est une pièce de stockage dans le cluster qui a été provisionnée par un administrateur de cluster ou provisionnée dynamiquement à l'aide des classes de stockage.

Une demande de volume persistant (PVC) est une demande de stockage de la part d'un utilisateur. 

Voici un exemple de PV et de définition PVC YAML : 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Questions d'entretien intermédiaires sur Kubernetes

Maintenant que vous avez pratiqué les bases, nous pouvons passer aux questions de niveau intermédiaire. La compréhension de concepts tels que la mise en réseau, la sécurité, la gestion des ressources et le dépannage est essentielle à ce niveau.

Qu'est-ce que la mise en réseau Kubernetes et comment fonctionne-t-elle ?

La mise en réseau Kubernetes permet la communication entre les pods, les services et les clients externes. Il suit une structure de réseau plate, ce qui signifie que, par défaut, tous les Pods peuvent communiquer entre eux.  

Les concepts clés de la mise en réseau dans Kubernetes sont les suivants :

• Communication de pod à pod : Chaque pod se voit attribuer une adresse IP unique et peut communiquer au sein du cluster. 
• Communication de service à service : Les services fournissent un point de terminaison réseau stable pour un groupe de pods, car les pods sont éphémères. Chaque pod se voit attribuer une nouvelle IP à chaque fois qu'il est créé.
• Contrôleurs d'intrusion : Gérer le trafic externe HTTP/HTTPS.
• Politiques de réseau : Définissez des règles pour restreindre ou autoriser la communication entre les pods.

Qu'est-ce que le contrôle d'accès basé sur les rôles (RBAC) dans Kubernetes ?

Le RBAC est un mécanisme de sécurité qui restreint les utilisateurs et les services en fonction de leurs autorisations. Il se compose de

• Rôles et ClusterRoles : Définir les actions autorisées sur les ressources.
• RoleBindings et ClusterRoleBindings : Attribuez des rôles aux utilisateurs ou aux comptes de service.

Le fichier YAML suivant montre un exemple de rôle qui n'autorise que l'accès en lecture seule aux Pods :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Ce rôle pod-reader peut maintenant être lié à un utilisateur à l'aide de RoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Comment fonctionne la mise à l'échelle automatique de Kubernetes ?

Kubernetes propose trois types de mise à l'échelle automatique pour optimiser l'utilisation des ressources :

1. Autoscaler horizontal (HPA) : Ajuste le nombre de Pods en fonction de l'utilisation du CPU, de l'utilisation de la mémoire ou de mesures personnalisées.
2. Autoscaler vertical (VPA) : Ajuste les demandes de CPU et de mémoire pour les différents Pods.
3. Cluster Autoscaler : Ajuste le nombre de nœuds de travail dans la grappe en fonction des besoins en ressources.

Vous pouvez créer un HPA à l'aide de kubectl :

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

La commande ci-dessus crée un HPA pour un déploiement portant le nom nginx et tente de maintenir l'utilisation moyenne du CPU dans tous les Pods à 50%, avec un nombre minimum de répliques à 1 et un nombre maximum de répliques à 10.

Comment déboguer les pods Kubernetes ?

Lorsque les pods échouent, Kubernetes propose plusieurs façons de les déboguer :

• Utilisez kubectl logs pour vérifier si les journaux des conteneurs contiennent des erreurs.
• Utilisez kubectl describe pod pour examiner les événements et les changements d'état récents.
• Utilisez kubectl exec pour ouvrir un shell interactif et enquêter depuis l'intérieur du conteneur.
• Utilisez kubectl get pods --field-selector=status.phase=Failed pour dresser la liste de tous les pods défaillants.

# get logs of a specific Pod
kubectl get logs <pod-name>

# describe the Pod and check events
kubectl describe pod <pod-name>

# open an interactive shell inside the Pod
kubectl exec -it <pod-name> – /bin/sh

# check all failing pods
kubectl get pods --field-selector=status.phase=Failed

Ces commandes permettent d'identifier les mauvaises configurations, les contraintes de ressources ou les erreurs d'application.

Comment effectuer des mises à jour et des retours en arrière dans Kubernetes ?

Les déploiements Kubernetes prennent en charge les mises à jour en continu pour éviter les temps d'arrêt. Vous pouvez effectuer une mise à jour continue en modifiant un déploiement ou en réglant explicitement son image sur une nouvelle version à l'aide de la fonction de mise à jour continue :

kubectl set image deployment/my-deployment nginx=nginx:1.21

Vous pouvez ensuite vérifier l'état du déploiement :

kubectl rollout status deployment my-deployment

Si vous souhaitez revenir à la version précédente, vous pouvez exécuter le programme :

kubectl rollout undo deployment my-deployment

Qu'est-ce qu'un Ingress dans Kubernetes, et comment cela fonctionne-t-il ?

Un Ingress est un objet API qui gère l'accès HTTP/HTTPS externe aux services à l'intérieur d'un cluster Kubernetes.  Il permet d'acheminer les demandes sur la base du nom d'hôte et des chemins d'accès, agissant comme un proxy inverse pour de multiples applications.

Exemple de définition YAML pour l'ingestion :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Comment Kubernetes gère-t-il les limites de ressources et les demandes ?

Kubernetes vous permet de définir des demandes et des limites de ressources pour les Pods afin de garantir une allocation équitable et éviter la surutilisation des ressources du cluster.

• Les demandes correspondent à la quantité minimale de CPU et de mémoire dont un pod a besoin. Ils sont affectés de manière permanente à un pod. 
• Les limites sont le maximum qu'un pod peut utiliser. Elles ne sont pas affectées au pod, mais si celui-ci a besoin de plus de ressources, il peut croître jusqu'à ce que la limite soit atteinte.

Exemple de définition YAML d'un pod qui définit les demandes et les limites de ressources :

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"

Que se passe-t-il si une ressource Pod doit croître au-delà des limites qui lui sont assignées ?

Si la consommation de mémoire d'un Pod dépasse la limite qui lui a été attribuée, Kubernetes tue immédiatement le conteneur en affichant une erreur de mémoire insuffisante (OOM). Le conteneur redémarre si une politique de redémarrage est définie.

Contrairement à la mémoire, si un pod dépasse la limite de CPU qui lui est attribuée, il n'est pas tué. Au lieu de cela, Kubernetes limite l'utilisation du processeur, ce qui entraîne un ralentissement de l'application.

Qu'est-ce qu'un conteneur init et quand devez-vous l'utiliser ?

Les conteneurs d'initialisation sont des conteneurs spéciaux qui s'exécutent avant que les conteneurs principaux ne démarrent. Ils aident à préparer l'environnement en vérifiant les dépendances, en chargeant les fichiers de configuration ou en configurant les données.

Un exemple pourrait être un conteneur d'initialisation qui attend qu'une base de données soit opérationnelle :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image

Comment Kubernetes gère-t-il les interruptions de pods et la haute disponibilité ?

Kubernetes assure une haute disponibilité grâce à des budgets de perturbation de pods (PDB), des règles d'anti-affinité et des mécanismes d'autoréparation. Voici comment ces mécanismes fonctionnent :

• Budget de perturbation du pod (PDB) : Garantit qu'un nombre minimum de pods reste disponible pendant les interruptions volontaires (par exemple, les mises à jour de clusters où les nœuds doivent être réduits).
• Affinité et anti-affinité des pods : Contrôle les Pods qui peuvent être programmés ensemble ou séparément.
• Sélecteurs de nœuds et tolérances : Contrôlez la répartition des charges de travail entre les nœuds.

Voici un exemple de définition PDB YAML qui garantit qu'au moins deux Pods restent en cours d'exécution pendant les interruptions :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Questions d'entretien avancées sur Kubernetes

Cette section couvre les questions d'entretien Kubernetes avancées, en se concentrant sur les applications avec état, la gestion multi-cluster, la sécurité, l'optimisation des performances et le dépannage. Si vous postulez à un poste d'encadrement, n'hésitez pas à les consulter.

Que sont les StatefulSets et en quoi diffèrent-ils des Deployments ?

Un StatefulSet est utilisé pour les applications avec état qui nécessitent des identités réseau stables, un stockage persistant et un déploiement ordonné. Contrairement aux déploiements, les StatefulSets garantissent que :

• Les pods ont des identités de réseau stables et uniques, où les pods sont nommés comme pod-0, pod-1 etc.
• Les pods sont créés, mis à jour et supprimés dans l'ordre.
• Chaque pod conserve un stockage persistant au fil des redémarrages. Le stockage permanent est défini dans le cadre de la définition YAML du StatefulSet.

Qu'est-ce qu'un maillage de services et pourquoi est-il utilisé dans Kubernetes ?

Un maillage de services gère la communication de service à service de service à serviceen fournissant :

• Gestion du trafic (équilibrage de la charge, déploiement de canaris).
• Sécurité (cryptage mTLS entre les services).
• Observabilité (traçage, métriques, journalisation)

Toutes ces fonctionnalités sont incluses dans la couche d'infrastructure, de sorte qu'aucune modification du code n'est nécessaire. 

Les solutions populaires de maillage de services Kubernetes sont notamment les suivantes : Istio, Linkerd et Consul.

Comment sécuriser un cluster Kubernetes ?

Suivez le modèle de sécurité 4C pour sécuriser un cluster Kubernetes :

1. Sécurité des fournisseurs de cloud : Utilisez les rôles IAM et les règles de pare-feu.
2. Sécurité des clusters : Activez les fonctions RBAC, les journaux d'audit et la sécurité du serveur API.
3. Sécurité des conteneurs : Numérisez les images et utilisez des utilisateurs non root.
4. Sécurité du code : Mettre en œuvre la gestion des secrets et utiliser des politiques de réseau.

Qu'est-ce que les plaintes et les tolérances dans Kubernetes ?

Les taches et les tolérances contrôlent l'endroit où les pods s'exécutent :

• Taches : Marquez les nœuds à rejeter.
• Tolérances : Permet aux Pods d'ignorer certaines Taints.

Voici un exemple d'altération d'un nœud pour qu'il n'accepte que des charges de travail spécifiques :

kubectl taint nodes node1 key1=value1:NoSchedule

Cela signifie qu'aucun pod ne peut être programmé sur node1 tant qu'il n'a pas atteint le niveau de tolérance requis.

Une tolérance est ajoutée dans la section PodSpec comme suit :

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: “value1”
    effect: "NoSchedule"

Le pod serait autorisé à être programmé sur node1.

Que sont les conteneurs sidecar de Kubernetes et comment sont-ils utilisés ?

Un conteneur sidecar fonctionne parallèlement au conteneur de l'application principale dans le même Pod. Il est couramment utilisé pour :

• Journalisation et surveillance (par exemple, collecte de journaux avec Fluentd).
• Proxy de sécurité (par exemple, l'exécution du proxy Envoy d'Istio pour le maillage des services).
• Gestion de la configuration (par exemple, synchronisation des paramètres de l'application).

Exemple de conteneur secondaire pour le traitement des journaux :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}

Le conteneur sidecar exécute Fluentd, qui collecte les journaux du conteneur principal via un volume partagé.

Citez trois causes typiques d'erreurs de Pod et indiquez comment y remédier.

Les cosses peuvent rester bloquées dans En attente, CrashLoopBackOffou ImagePullBackOff états :

• Pod bloqué dans En attente: Vérifiez la disponibilité des nœuds et les limites des ressources. Vous pouvez consulter les événements du Pod pour plus d'informations.
• CrashLoopBackOff: Examinez les journaux d'application et vérifiez les erreurs de configuration.
• ImagePullBackOff: Veillez à ce que le nom de l'image et les informations d'identification soient corrects. Là encore, renseignez-vous sur les événements du Pod pour obtenir de plus amples informations.

Vous pouvez vérifier les événements du pod à l'aide de la commande describe:

kubectl describe pod <pod-name>

Qu'est-ce qu'un webhook de mutation d'admission Kubernetes et comment fonctionne-t-il ?

Un webhook d'admission à la mutation permet la modification en temps réel des objets Kubernetes avant qu'ils ne soient appliqués au cluster et persistés. Il exécute un contrôleur d'admission dynamique dans Kubernetes qui intercepte les demandes d'API avant que les objets ne soient persistés dans etcd. Il peut modifier la charge utile de la demande en injectant, en modifiant ou en supprimant des champs avant d'autoriser la poursuite de la demande.

Ils sont couramment utilisés pour :

• Injection des side-cars.
• Définir des valeurs par défaut pour les pods, les déploiements ou d'autres ressources.
• Renforcement des meilleures pratiques (par exemple, attribution automatique de limites de ressources).
• Ajouter des configurations de sécurité (par exemple, exiger des étiquettes pour le cursus d'audit).

Comment mettre en œuvre des déploiements en temps zéro dans Kubernetes ?

Les déploiements sans temps d'arrêt garantissent que les mises à jour n'interrompent pas le trafic en direct. Kubernetes y parvient en utilisant :

• Mises à jour en continu (par défaut, remplacement progressif des anciens Pods par de nouveaux).
• Déploiements canari (tests avec un sous-ensemble d'utilisateurs).
• Déploiements bleu-vert (passage d'un environnement de production à un environnement de test).

Les sondes de préparation permettent à Kubernetes d'éviter d'envoyer du trafic à des pods non prêts.

Que sont les définitions de ressources personnalisées (CRD) de Kubernetes et quand les utiliser ?

Une définition de ressource personnalisée (CRD) étend les API de Kubernetes, permettant aux utilisateurs de définir et de gérer des ressources personnalisées. Ils sont utilisés pour des cas d'utilisation spécifiques où l'API Kubernetes doit toujours être utilisée pour gérer ces ressources, comme par exemple :

• Gestion d'applications personnalisées (par exemple, modèles d'apprentissage automatique).
• Permettre aux opérateurs Kubernetes de réaliser des applications auto-réparatrices.

Exemple de définition YAML de CRD :

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Vous pouvez maintenant, par exemple, récupérer l'objet shirt à l'aide de kubectl :

kubectl get shirts

Découvrez comment tirer parti de Docker et Kubernetes pour les flux de travail d'apprentissage automatique dansce tutoriel pratique sur la conteneurisation.

Que sont les opérateurs Kubernetes, et comment fonctionnent-ils ?

Un opérateur Kubernetes étend les fonctionnalités de Kubernetes en automatisant le déploiement, la mise à l'échelle et la gestion d'applications complexes. Il est construit à l'aide de CRD et de contrôleurs personnalisés pour gérer la logique propre à l'application.

Les opérateurs travaillent en définissant des ressources personnalisées dans Kubernetes et en surveillant les changements dans le cluster pour automatiser des tâches spécifiques. 

Ce sont les éléments clés d'un opérateur :

• Définition de ressource personnalisée (CRD) : Définit une nouvelle ressource API Kubernetes.
• Contrôleur personnalisé : Surveille le CRD et applique la logique d'automatisation en fonction de l'état souhaité.
• Boucle de réconciliation : S'assure en permanence que l'état de l'application correspond à l'état attendu.

Questions d'entretien sur Kubernetes pour les administrateurs

Les administrateurs Kubernetes maintiennent, sécurisent et optimisent les clusters pour les charges de travail de production. Cette section couvre les questions d'entretien Kubernetes axées sur la gestion des clusters.

Comment sauvegarder et restaurer un cluster etcd dans Kubernetes ?

Etcd est le magasin de valeurs clés qui contient l'ensemble de l'état de la grappe. Des sauvegardes régulières sont essentielles pour éviter la perte de données.

Vous pouvez créer une sauvegarde à l'aide de la commande ci-dessous :

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

Si vous souhaitez maintenant restaurer à partir d'une sauvegarde, vous pouvez exécuter le programme :

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

Comment mettre à niveau un cluster Kubernetes en toute sécurité ?

La mise à niveau d'un cluster Kubernetes est un processus en plusieurs étapes qui nécessite un temps d'arrêt minimal et préserve la stabilité du cluster. Les administrateurs doivent suivre une approche structurée pour éviter les problèmes lors de la mise à niveau :

1. Videz et sauvegardez etcd avant la mise à niveau pour vous assurer que vous pourrez le restaurer en cas d'échec de la mise à niveau.
2. Mettez à niveau le nœud du plan de contrôle.
3. Mettre à jour kubelet et kubectl sur les nœuds du plan de contrôle.
4. Mettez à niveau les nœuds de travail un par un. Avant la mise à niveau, chaque nœud de travailleur doit être vidé afin d'éviter toute interruption de la charge de travail.
5. Mettez à jour les modules complémentaires de la grappe (par exemple, les contrôleurs Ingress, les outils de surveillance, ...).

Comment surveiller un cluster Kubernetes ?

Les administrateurs Kubernetes doivent surveiller la santé du processeur, de la mémoire, du disque, du réseau et de l'application. Les outils suivants sont recommandés pour ces tâches :

• Prometheus + Grafana : Collectez et visualisez les mesures des grappes. Créez des alertes en temps réel pour être informé en cas de problème.
• Loki + Fluentd : Collecter et analyser les journaux.
• Tableau de bord Kubernetes : Surveillance des clusters basée sur l'interface utilisateur.
• Jaeger/OpenTelemetry : Traçage distribué.

Comment sécuriser un cluster Kubernetes ?

La sécurité est un aspect essentiel, et chaque administrateur doit suivre les meilleures pratiques pour sécuriser un cluster Kubernetes :

• Activer RBAC : Restreindre l'accès des utilisateurs à l'aide de rôles et de liaisons de rôles.
• Admission à la sécurité des pods : Utilisez des contrôleurs d'admission pour appliquer les normes de sécurité du Pod.
• Appliquer les politiques de réseau : Restreindre la communication entre les pods, car par défaut, tous les pods peuvent communiquer entre eux.
• Effectuez une rotation régulière des jetons et des certificats API.
• Utilisez la gestion des secrets : Utilisez des outils tels que Vault, AWS Secrets Manager, etc. 

Découvrez comment Kubernetes est mis en œuvre dans le cloud avec ce guide sur l' orchestration de conteneurs à l'aide d'AWS Elastic Kubernetes Service (EKS).

Comment configurer la journalisation de Kubernetes ?

La journalisation centralisée est nécessaire pour le débogage et l'audit. Deux options différentes de piles de journalisation :

• Loki + Fluentd + Grafana (léger et rapide).
• Pile ELK (Elastic, Logstash, Kibana) (évolutif et de qualité professionnelle).

Comment mettre en œuvre la haute disponibilité dans Kubernetes ?

La haute disponibilité est essentielle pour éviter les temps d'arrêt des applications exécutées dans votre cluster Kubernetes. Vous pouvez assurer une haute disponibilité en

• Utilisation de plusieurs nœuds de plan de contrôle. Plusieurs serveurs API permettent d'éviter les temps d'arrêt en cas de défaillance de l'un d'entre eux.
• Activation de l'autoscaler du cluster. Cela permet d'ajouter ou de supprimer automatiquement des nœuds en fonction de la demande.

Comment mettre en œuvre la multitenance des clusters Kubernetes ?

Le multitenancy est assez important si vous mettez en place Kubernetes pour votre entreprise. Il permet à plusieurs équipes ou applications de partager un cluster Kubernetes en toute sécurité sans interférer les unes avec les autres.

Il existe deux types de multi-location :

1. Multitenance souple : Utilise les espaces de noms, RBAC et NetworkPolicies pour isoler au niveau de l'espace de noms.
2. Multi-tenance stricte : Utilise des clusters virtuels ou des plans de contrôle séparés pour isoler un cluster physique (par exemple, KCP).

Comment chiffrer les secrets Kubernetes dans etcd ?

Etcd stocke l'état complet du cluster, ce qui signifie que les informations critiques y sont stockées. 

Par défaut, Kubernetesstocke les secrets en clair dans etcd, ce qui les rend vulnérables à la compromission. Par conséquent, il peut être crucial d'activer le cryptage des secrets au niveau de REST afin que les secrets soient stockés et cryptés.

Dans un premier temps, vous devez créer un fichier de configuration du cryptage et y stocker une clé de cryptage/décryptage :

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}

La configuration ci-dessus spécifie que Kubernetes utilisera le fournisseur aescbc pour chiffrer les ressources Secret, avec un repli sur identity pour les données non chiffrées.

Ensuite, vous devez adapter le fichier de configuration kube-apiserver, qui se trouve généralement à l'adresse /etc/kubernetes/manifests/kube-apiserver.yaml sur un nœud de plan de contrôle, et inclure l'indicateur -- encryption-provider-config qui pointe vers le fichier de configuration du chiffrement que vous avez créé :

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml

Enregistrez les modifications et redémarrez le site kube-apiserver pour appliquer la nouvelle configuration.

Comment gérer les quotas de ressources Kubernetes dans les environnements multi-tenants ?

Les quotas de ressources empêchent un seul locataire (espace de noms) de surconsommer les ressources de la grappe, ce qui perturbe le travail des autres locataires.

Vous pouvez définir des quotas de ressources pour les espaces de noms afin d'attribuer une certaine quantité de ressources à cet espace de noms spécifique. Les utilisateurs de cet espace de noms peuvent alors créer des ressources qui consomment autant de ressources que celles définies dans le quota de ressources de cet espace de noms.

Exemple de définition YAML de ResourceQuota :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Vous pouvez vérifier le ResourceQuota d'un espace de noms en utilisant :

kubectl describe resourcequota namespace-quota -n team-a

Qu'est-ce que CoreDNS ? Comment le configurer et l'utiliser ?

CoreDNS est le fournisseur de DNS par défaut pour les clusters Kubernetes. Il assure la découverte des services et permet aux pods de communiquer en utilisant des noms DNS internes au lieu d'adresses IP.

Caractéristiques de CoreDNS :

• Gère la résolution DNS interne (my-service.default.svc.cluster.local).
• Prise en charge de la configuration DNS personnalisée.
• Équilibre la charge des requêtes DNS entre plusieurs Pods.
• Permet la mise en cache pour améliorer les performances.

Vous pouvez configurer CoreDNS à l'aide du ConfigMap stocké dans l'espace de noms kube-system. Vous pouvez visualiser les paramètres actuels en utilisant :

kubectl get configmap coredns -n kube-system -o yaml

Il suffit de mettre à jour ce ConfigMap et d'appliquer les changements pour adapter la configuration de CoreDNS.

Questions d'entretien sur Kubernetes basées sur des scénarios et la résolution de problèmes

Les ingénieurs sont régulièrement confrontés à des défis complexes en matière d'évolutivité, de réseau, de sécurité, de performance et de dépannage dans des environnements Kubernetes réels, et les enquêteurs le savent. Cette section présente des questions d'entretien basées sur des scénarios qui testent votre capacité à résoudre des problèmes pratiques liés à Kubernetes.

Déboguer une application Kubernetes lente

"Votre équipe signale qu'une application s'exécutant dans Kubernetes est devenue lente et que les utilisateurs subissent des temps de réponse élevés...". Comment résolvez-vous ce problème ?"

Vous pouvez aborder le problème en suivant les étapes suivantes :

1. Vérifiez l'utilisation de la ressource Pod. Augmenter les ressources au cas où elles atteindraient leurs limites.

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

2. Décrivez le Pod lent pour obtenir plus d'informations. Recherchez l'épuisement des ressources, le nombre de redémarrages ou les échecs des sondes de vivacité.

kubectl describe pod <pod-name>

3. Vérifiez que les journaux des conteneurs ne contiennent pas d'erreurs. Recherchez les délais d'attente, les erreurs ou les échecs de connexion.

kubectl logs <pod-name>

4. Testez la latence du réseau, car elle peut ralentir les applications.

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service

5. Vérifier l'état des nœuds Kubernetes et vérifier l'épuisement des ressources sur les nœuds.

kubectl get nodes
kubectl describe node <node-name>

Un serveur web Nginx est en cours d'exécution, mais l'URL exposée ne parvient pas à se connecter.

"Vous avez déployé un serveur web Nginx dans Kubernetes, et le Pod fonctionne correctement, mais l'application n'est pas accessible via l'URL exposée. Que pouvez-vous faire ?"

Marche à suivre pour aborder le problème ci-dessus :

1. Vérifiez que le pod Nginx fonctionne et qu'il est sain.

kubectl get pods -o wide
kubectl describe pod nginx-web

2. Vérifiez le mappage des services et des ports. Assurez-vous que le port correct est exposé et qu'il correspond au port du conteneur du pod. Vérifiez que le service trouve les bons pods.

kubectl describe service nginx-service

3. Vérifiez les politiques de réseau. Si une politique de réseau bloque le trafic entrant, le service ne sera pas accessible.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

4. Vérifiez la configuration des DNS entrant et externe.

kubectl describe ingress nginx-ingress

Le déploiement de Kubernetes échoue après une mise à jour

"Vous avez déployé une nouvelle version de votre application, mais elle ne démarre pas, , ce qui entraîne des interruptions pour vos utilisateurs. Comment pouvez-vous résoudre le problème ?"

Approche de la résolution du problème :

1. Revenir à la version précédente.

kubectl rollout undo deployment my-app

2. Vérifiez l'historique des déploiements et identifiez ce qui a changé dans la nouvelle version.

kubectl rollout history deployment my-app

3. Vérifiez que les journaux du nouveau pod ne contiennent pas d'erreurs.

kubectl logs -l app=my-app

4. Vérifiez l'état de préparation et les sondes de disponibilité.

5. Vérifier les problèmes d'extraction d'image. Parfois, la nouvelle image est erronée ou indisponible.

L'application ne peut pas se connecter à une base de données externe.

"Un microservice exécuté dans Kubernetes ne parvient pas à se connecter à une base de données externe, qui est hébergée en dehors du cluster. Comment pouvez-vous résoudre le problème ?"

Les étapes de l'approche du problème :

1. Vérifiez la connectivité externe depuis l'intérieur d'un pod. Vérifiez si la base de données est accessible depuis le réseau Kubernetes.

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432

2. Vérifiez la résolution DNS dans le Pod. En cas d'échec, il se peut que CoreDNS soit mal configuré.

kubectl exec -it <pod-name> -- nslookup my-database.example.com

3. Vérifiez s'il existe des politiques de réseau qui bloquent l'accès externe, car elles peuvent empêcher le trafic sortant.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

Les ressources du cluster sont épuisées, ce qui fait que les nouveaux Pods restent en attente.

"Les nouvelles nacelles restent dans l'État en attendant. En regardant plus profondément dans les pods, nous voyons que le message "0/3 nodes are available : insufficient CPU and memory" (0/3 nœuds sont disponibles : insuffisance de CPU et de mémoire). Comment procédez-vous pour déboguer et résoudre le problème ?"

Les étapes de l'approche du problème :

1. Vérifiez la disponibilité des ressources du cluster. Recherchez une utilisation élevée de l'unité centrale ou de la mémoire qui empêche la programmation.

kubectl describe node <node-name>
kubectl top nodes

2. Vérifiez quels sont les pods qui consomment le plus de ressources. Définissez des ressources et des limites pour les pods afin de vous assurer qu'ils ne consomment pas trop. Vous pouvez également l'appliquer à tous les espaces de noms du cluster.

kubectl top pods --all-namespaces

3. Réduisez les charges de travail non essentielles pour libérer des ressources.

kubectl scale deployment <deployment-name> --replicas=0

4. Augmentez le nombre de nœuds disponibles pour accroître les ressources de la grappe. Vous pouvez également ajouter d'autres nœuds à l'autoscaler de cluster s'il y en a un d'utilisé.

Conseils pour se préparer à un entretien Kubernetes

Grâce à ma propre expérience des entretiens Kubernetes, j'ai appris que pour réussir, il ne suffit pas de mémoriser des concepts. Vous devez appliquer vos connaissances à des scénarios réels, résoudre des problèmes de manière efficace et expliquer clairement vos solutions.

Si vous voulez réussir les entretiens Kubernetes, suivez les conseils ci-dessous :

1. Maîtrisez les concepts de base de Kubernetes. Assurez-vous de comprendre les pods, les déploiements, les services, les volumes persistants, les ConfigMaps, les secrets, etc.
2. Bénéficiez d'une expérience pratique avec Kubernetes. Lorsque j'ai préparé mes entretiens, j'ai constaté que la mise en place de mon propre cluster Minikube et le déploiement de microservices m'ont aidé à renforcer ma compréhension. Vous pouvez également utiliser un service Kubernetes géré d'un fournisseur de cloud pour vous exercer à l'échelle.
3. Apprenez à déboguer les problèmes Kubernetes, car le dépannage est une partie importante du travail avec Kubernetes dans le monde réel. Vous passerez probablement le plus clair de votre temps à dépanner des applications au travail.
• Les problèmes les plus courants sont le blocage des pods, les pannes de réseau, les volumes persistants qui ne se montent pas correctement et les pannes de nœuds.
4. Comprendre la mise en réseau et l'équilibrage de charge de Kubernetes. L'accent est mis sur la façon dont le réseau est mis en œuvre, sur la façon dont les pods communiquent, sur les types de services existants et sur la façon d'exposer les applications.
5. Sachez comment mettre à l'échelle et optimiser les charges de travail Kubernetes. Les enquêteurs posent souvent des questions sur les stratégies d'expansion et l'optimisation des coûts. Maîtriser l'HPA, l'autoscaler de cluster, les demandes de ressources et les limites. 
6. Comprendre les meilleures pratiques de sécurité de Kubernetes. Connaître RBAC, le contexte de sécurité du Pod, les politiques de réseau et la gestion des secrets.
7. Étudier l'architecture et les aspects internes de Kubernetes. Connaître les composants du plan de contrôle et les interactions entre le kubelet et le runtime du conteneur.

En combinant les connaissances théoriques avec la pratique, et en apprenant à partir de dépannages réels, vous maîtriserez n'importe quel entretien Kubernetes !

Conclusion

Kubernetes est un système d'orchestration de conteneurs puissant mais complexe. Les entretiens pour les postes Kubernetes nécessitent une compréhension approfondie de la théorie et de la résolution de problèmes dans le monde réel. Que vous soyez un ingénieur débutant à la recherche d'un premier emploi ou un ingénieur confirmé aspirant à des fonctions plus importantes, la préparation est toujours essentielle.

Je ne saurais trop insister sur l'importance de la pratique. Il vous aide à trouver plus rapidement les problèmes dans vos applications et à avoir davantage confiance en vos capacités.

Si vous cherchez à renforcer vos fondamentaux, je vous recommande vivement d'explorer des cours tels que Containerization and Virtualization Concepts pour construire une base solide, puis Introduction to Kubernetes pour acquérir une expérience pratique avec Kubernetes.

Je vous souhaite bonne chance pour vos entretiens !