Dépannage réseau des comptes de service Kubernetes : guide pratique pour administrateurs

Introduction

Les comptes de service Kubernetes (Service Accounts) sont les identités que les Pods utilisent pour interagir avec l'API Kubernetes et les autres services du cluster. Lorsque des Pods utilisent ces comptes, ils héritent de l'identité réseau et des autorisations qui leur sont associées. Les problèmes réseau impliquant les comptes de service peuvent se manifester de plusieurs façons : un Pod peut ne pas parvenir à joindre le serveur d'API, les résolutions DNS peuvent expirer, ou le Pod peut ne pas disposer des autorisations nécessaires même si la connectivité réseau semble correcte. En tant qu'administrateur, vous avez besoin d'une approche systématique pour diagnostiquer et résoudre rapidement ces problèmes.

Ce guide fournit des étapes de dépannage pratiques et des commandes de diagnostic sûres pour les problèmes de réseau des comptes de service dans un contexte d'administration. Vous apprendrez à inventorier votre environnement, à mettre en place un pilote de test isolé, à exécuter des vérifications ciblées de connectivité et d'autorisations, et à récupérer après les échecs courants. Les exemples utilisent un espace de noms de test et un compte de service dédié pour minimiser les risques sur les charges de travail en production. À la fin, vous disposerez d'une liste de contrôle reproductible pour valider le réseau des comptes de service et d'un plan de récupération clair lorsque les choses tournent mal.

Inventaire des versions et de l'environnement

Avant de commencer le dépannage, documentez les versions et la topologie de votre cluster Kubernetes. Cet inventaire vous aide à aligner votre diagnostic avec les comportements connus et les détails de configuration. Rassemblez la version de Kubernetes, le moteur d'exécution des conteneurs, le plugin réseau (CNI) et les détails du compte de service utilisé.

Exécutez les commandes suivantes pour collecter les informations de base du cluster :

kubectl version --short
kubectl get nodes -o wide
kubectl get serviceaccounts --all-namespaces

La sortie attendue de kubectl version --short affiche les versions du client et du serveur, par exemple :

Client Version: v1.28.2
Server Version: v1.28.2

kubectl get nodes -o wide liste chaque nœud avec ses adresses IP internes et externes, son système d'exploitation et la version du moteur d'exécution des conteneurs. kubectl get serviceaccounts --all-namespaces affiche chaque compte de service dans tous les espaces de noms, ce qui est utile pour identifier celui que vous dépannez.

Enregistrez ces détails dans un tableau pour garder une trace de l'environnement :

Si vous avez plusieurs clusters, répétez cet inventaire pour chacun d'eux. Assurez-vous de disposer des autorisations nécessaires pour inspecter le cluster ; en général, vous avez besoin des droits cluster-admin ou d'un rôle avec les permissions get et list sur les nœuds, les espaces de noms et les comptes de service.

Chemin de configuration sécurisé

Lorsque vous testez le réseau des comptes de service, évitez de faire des modifications directement dans les espaces de noms de production. Créez plutôt un espace de noms dédié et un Pod de test qui utilise un nouveau compte de service. Cela isole vos expériences et limite le rayon d'impact si quelque chose tourne mal.

Suivez ces étapes pour mettre en place un environnement de test sûr :

1. Créez un espace de noms pour les tests :

kubectl create namespace net-test

1. Créez un compte de service dans cet espace de noms :

kubectl create serviceaccount test-sa -n net-test

1. Liez le compte de service à un rôle qui accorde des autorisations suffisantes pour le test. Par exemple, pour autoriser la liste des pods et des espaces de noms, créez un Role et un RoleBinding, ou utilisez le ClusterRole intégré view si vous voulez un accès en lecture seule sur l'ensemble du cluster. Pour simplifier ce guide, nous utilisons clusterrole=view pour éviter de trop accorder de permissions :

kubectl create rolebinding test-sa-view \
  --clusterrole=view \
  --serviceaccount=net-test:test-sa \
  -n net-test

Alternativement, si vous avez spécifiquement besoin d'autorisations proches de celles d'un administrateur pour un test plus large, vous pouvez utiliser clusterrole=admin, mais cela accorde un accès en écriture et doit être utilisé avec prudence. Le rôle view est en lecture seule et suffisant pour les vérifications de connectivité.

1. Lancez un Pod de test utilisant ce compte de service. Utilisez une image légère comme busybox avec une commande sleep pour le maintenir en fonctionnement :

kubectl run test-pod \
  --image=busybox:1.36 \
  --restart=Never \
  --serviceaccount=test-sa \
  -n net-test \
  -- sleep 3600

1. Vérifiez que le Pod est en cours d'exécution et notez son adresse IP :

kubectl get pod test-pod -n net-test -o wide

La sortie attendue affiche le Pod avec un STATUS de Running et une IP provenant de la plage CIDR des Pods du cluster. Par exemple :

NAME       READY   STATUS    RESTARTS   AGE   IP               NODE
test-pod   1/1     Running   0          10s   10.244.1.5       worker-1

Cet environnement de test dédié garantit que toute modification de politique réseau ou commande de diagnostic n'affecte pas les autres charges de travail.

Vérification et diagnostics

Avec le Pod de test en cours d'exécution, vous pouvez maintenant effectuer des vérifications de connectivité et d'autorisations. Commencez par vérifier la résolution DNS à l'intérieur du Pod, puis testez la connectivité au serveur d'API à l'aide du jeton du compte de service, et enfin vérifiez les autorisations RBAC.

Vérification de la résolution DNS

Le DNS est un point de défaillance courant. Kubernetes fournit un service DNS de cluster (généralement CoreDNS) qui résout les noms de service. Depuis l'intérieur du Pod de test, interrogez le service par défaut de Kubernetes :

kubectl exec -n net-test test-pod -- nslookup kubernetes.default

La sortie attendue inclut l'adresse IP du cluster du service kubernetes dans l'espace de noms default, par exemple :

Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

Si nslookup échoue ou expire, vérifiez les Pods CoreDNS et leurs journaux :

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

Vérifiez également la ConfigMap CoreDNS pour détecter d'éventuelles erreurs de configuration :

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

Vérification de la connectivité au serveur d'API

Le jeton du compte de service est monté dans le Pod à l'emplacement /var/run/secrets/kubernetes.io/serviceaccount/token. Utilisez ce jeton pour vous authentifier auprès du serveur d'API. Exécutez une simple requête HTTP vers le point de terminaison /api/v1/namespaces du serveur d'API depuis l'intérieur du Pod :

kubectl exec -n net-test test-pod -- sh -c \
  'TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token); \
   wget -qO- --header="Authorization: Bearer $TOKEN" \
   https://kubernetes.default.svc/api/v1/namespaces'

Une réponse réussie renvoie un objet JSON contenant une liste d'espaces de noms. Par exemple, un extrait :

{
  "kind": "NamespaceList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "12345"
  },
  "items": [
    {
      "metadata": {
        "name": "default",
        ...
      }
    }
  ]
}

Si la requête échoue avec une erreur de connexion, des politiques réseau ou des règles de pare-feu peuvent bloquer l'accès au serveur d'API (généralement le port 443). Si elle échoue avec un code 403 Forbidden, le compte de service peut manquer des autorisations RBAC nécessaires.

Vérification des autorisations RBAC

Même si le chemin réseau est ouvert, le compte de service peut ne pas avoir la permission d'effectuer certaines actions. Utilisez kubectl auth can-i pour simuler les autorisations du compte de service sans faire réellement de requête depuis le Pod :

kubectl auth can-i list pods \
  --as=system:serviceaccount:net-test:test-sa \
  -n default

La sortie attendue est yes ou no. Si la sortie est no, inspectez les RoleBindings et ClusterRoleBindings associés au compte de service :

kubectl get rolebindings,clusterrolebindings \
  -o json | jq '.items[] | select(.subjects[]?.name == "test-sa")'

Cette commande suppose que jq est installé ; sinon, utilisez kubectl describe sur chaque liaison.

Diagnostics réseau supplémentaires

Si les vérifications DNS et API réussissent mais que d'autres services sont inaccessibles, examinez les politiques réseau et les points de terminaison des services.

Vérifiez si des NetworkPolicies sont appliquées dans l'espace de noms de test :

kubectl get networkpolicies -n net-test

Si des politiques existent, inspectez leurs règles pour voir si elles autorisent le trafic depuis le Pod de test :

kubectl describe networkpolicy <nom-de-la-politique> -n net-test

Vérifiez également que le service cible a des points de terminaison :

kubectl get endpoints <nom-du-service> -n <espace-de-noms>

Si les points de terminaison sont vides, le sélecteur du service peut ne correspondre à aucun Pod.

Modes de défaillance et récupération

Plusieurs modes de défaillance courants peuvent affecter le réseau des comptes de service. Voici les plus fréquents, avec les étapes de diagnostic et les actions de récupération.

Mauvaise configuration DNS

Symptômes : nslookup échoue ou renvoie une IP différente de celle attendue. Les Pods peuvent signaler could not resolve host.

Diagnostic :

• Vérifiez le statut des Pods CoreDNS.
• Examinez les journaux CoreDNS pour détecter des erreurs.
• Inspectez la ConfigMap CoreDNS pour tout changement personnalisé.

Récupération :

• Si les Pods CoreDNS plantent, redémarrez-les : kubectl rollout restart deployment coredns -n kube-system.
• Si la ConfigMap est mal configurée, corrigez-la et redémarrez CoreDNS.

Port 443 bloqué

Symptômes : le test de connectivité au serveur d'API échoue avec Connection refused ou Connection timed out.

Diagnostic :

• Vérifiez les règles de pare-feu sur les nœuds ou les groupes de sécurité du fournisseur cloud qui peuvent bloquer le port 443 depuis les IP des Pods.
• Vérifiez les NetworkPolicies qui peuvent refuser la sortie vers le serveur d'API.

Récupération :

• Ajustez les règles de pare-feu pour autoriser le trafic Pod-vers-serveur d'API sur le port 443.
• Modifiez ou supprimez les NetworkPolicies restrictives.

Autorisations RBAC insuffisantes

Symptômes : la requête API renvoie 403 Forbidden même si la connectivité réseau est correcte.

Diagnostic :

• Utilisez kubectl auth can-i --as=system:serviceaccount:<namespace>:<sa> pour tester les autorisations.
• Inspectez les RoleBindings et ClusterRoleBindings.

Récupération :

• Accordez les autorisations nécessaires en créant ou en mettant à jour les RoleBindings. Par exemple :

kubectl create rolebinding test-sa-view \
  --clusterrole=view \
  --serviceaccount=net-test:test-sa \
  -n net-test

Si vous devez supprimer des autorisations, supprimez la liaison :

kubectl delete rolebinding test-sa-view -n net-test

Jeton du compte de service non monté

Symptômes : le Pod ne démarre pas ou le fichier de jeton est absent à /var/run/secrets/kubernetes.io/serviceaccount/token.

Diagnostic :

• Décrivez le Pod pour voir les événements : kubectl describe pod test-pod -n net-test.
• Vérifiez si le compte de service existe et est correctement référencé.

Récupération :

• Assurez-vous que le compte de service existe : kubectl get serviceaccount test-sa -n net-test.
• Sinon, créez-le et redémarrez le Pod.

Retour en arrière et nettoyage

Chaque fois que vous apportez des modifications pour les tests, ayez un plan de récupération. Documentez la configuration d'origine avant de modifier toute ressource. Utilisez le contrôle de version pour les manifestes afin de suivre les changements. Pour nettoyer l'environnement de test :

kubectl delete namespace net-test

Cela supprime toutes les ressources de cet espace de noms, y compris le Pod de test, le compte de service et les RoleBindings.

Liste de contrôle des opérations

Utilisez la liste de contrôle suivante pour les opérations réseau de routine des comptes de service afin de garantir une configuration cohérente et sécurisée. Remplacez les valeurs d'exemple par vos détails réels.

Surveillez en outre les erreurs d'authentification dans les journaux du serveur d'API pour détecter les échecs répétés d'un compte de service spécifique :

kubectl logs -n kube-system <nom-du-pod-apiserver> | grep "forbidden"

Remplacez <nom-du-pod-apiserver> par le nom réel du Pod du serveur d'API.

Conclusion

Le dépannage réseau des comptes de service Kubernetes pour les administrateurs nécessite une approche systématique : inventorier votre environnement, mettre en place un pilote de test sûr, exécuter des diagnostics ciblés et comprendre les modes de défaillance courants avec des actions de récupération claires. Ce guide a fourni des commandes concrètes et des exemples pour vérifier le DNS, la connectivité à l'API, les autorisations RBAC et les politiques réseau. En suivant la liste de contrôle, vous pouvez identifier et résoudre rapidement les problèmes réseau, garantissant ainsi des opérations de cluster fiables et sécurisées.

N'oubliez pas d'isoler toujours vos tests dans un espace de noms dédié, d'utiliser des comptes de service avec le principe du moindre privilège et d'avoir un plan de retour en arrière. Documentez toutes les modifications que vous apportez à la configuration du cluster afin de pouvoir revenir en arrière si nécessaire. Commencez par le chemin de configuration sécurisé décrit ici pour minimiser les risques et gagner en confiance avant d'appliquer des modifications aux charges de travail de production.

Avec ces pratiques, vous pouvez réduire les temps d'arrêt et maintenir un environnement réseau Kubernetes performant.