minikube n’atteint pas une API privée ? Vérifiez d’abord le pilote

Une API privée répond depuis votre ordinateur portable et un Pod dans minikube ne l’atteint pas. Avant de modifier quoi que ce soit sur l’hôte, nommez le pilote derrière le profil actif, car ce seul fait décide du réseau d’où la requête sort réellement. Testez ensuite le même point de terminaison depuis l’hôte, depuis le nœud et depuis le Pod. Un seul de ces trois est ce qui a échoué, et une mauvaise supposition coûte un après-midi.

Étape 0 : nommer le pilote et l’origine

Demandez à minikube quel profil est actif et comment il s’exécute. Un pilote de conteneur place le nœud dans un conteneur sur votre machine, un pilote de VM le place dans une machine virtuelle, et un pilote distant le place ailleurs entièrement.

minikube profile list
minikube status
kubectl config current-context

Notez ensuite l’origine de la requête. La réponse détermine quel résolveur et quelles routes comptent, et ce n’est pas toujours celui de l’hôte. Deux profils sur le même ordinateur portable peuvent se comporter complètement différemment pour la même URL.

Étape 1 : tester trois fois le même point de terminaison

Utilisez un point de terminaison inoffensif et gardez le nom d’hôte, le port et la famille d’adresses identiques dans les trois tests. Changer l’un d’eux entre les exécutions rend les résultats incomparables.

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

Un pull d’image réussi par le nœud ne prouve rien sur la résolution de noms pour un hôte privé. Une requête publique réussie ne prouve encore moins. Séparez les résultats par contexte, car un schéma sur trois lignes est un diagnostic et un échec isolé est un indice.

Si la ligne de l’hôte échoue aussi, arrêtez-vous. Vous avez un problème de réseau sur l’hôte et le cluster est une distraction.

Étape 2 : conserver le chemin de l’hôte vers le cluster

Il existe une seconde direction que les gens oublient : l’hôte doit continuer à joindre l’API et les services du cluster. Un client VPN peut installer des routes qui entrent en concurrence avec les préfixes que minikube utilise pour son réseau de nœuds, sa plage de services et sa plage de pods.

Quand cela se produit, le symptôme est déroutant, car le tunnel fonctionne et kubectl cesse de répondre ou un NodePort refuse les connexions. Cela ressemble à une panne du cluster et c’est une panne de routage de l’ordinateur portable.

Vérifiez la table de routage de l’hôte par rapport aux plages de minikube avant d’accuser le tunnel de quoi que ce soit d’autre. Le chevauchement se voit généralement comme une route plus spécifique pointant vers l’interface du tunnel pour un préfixe que le cluster attend à lui.

Étape 3 : résoudre le chevauchement sans désactiver le VPN

Le propre manuel VPN et proxy de minikube traite de ces conflits et considère ses plages d’exemple comme des éléments à inspecter, non comme une liste universelle. Lisez-le en parallèle du profil que vous avez réellement.

Là où un chevauchement réel existe, la réponse prise en charge est une plage non chevauchante ou une politique d’accès local délibérée approuvée par le propriétaire du VPN. Changer la plage de services n’est pas la même chose que changer la plage de pods, et ni l’un ni l’autre n’équivaut à changer le réseau de nœuds.

Désactiver le tunnel d’entreprise pour faire fonctionner un cluster local n’est pas un contournement ; c’est une décision de politique que quelqu’un d’autre doit prendre. Portez-la devant cette personne plutôt que de le faire discrètement après le départ de tout le monde. Si vous l’avez déjà fait, remettez-le en place avant de demander.

Étape 4 : séparer proxy, DNS et quatre formes de panne

Si un proxy est requis, identifiez quel contexte en a besoin. Un réglage de navigateur sur l’hôte ne configure pas un processus dans le nœud, et un Pod a besoin des variables d’environnement ou d’une configuration de proxy au niveau du cluster.

Classez ensuite la panne au lieu de la décrire. Un nom qui ne se résout pas, c’est du DNS. Un nom qui se résout et refuse une connexion, c’est du routage ou un écouteur. Une connexion qui s’établit et échoue à l’identité, c’est TLS. Une connexion réussie avec un corps d’erreur, c’est l’application.

Chacune de ces quatre relève d’une correction différente, et une seule concerne le VPN. Notez laquelle vous avez observée dans chaque contexte, et la personne suivante hérite de preuves au lieu d’une histoire.