Problème de connexion ou de réseau

Deux familles de symptômes, deux démarches. Dans les deux cas, gardez en tête le modèle réseau de la plateforme : il explique 80 % des surprises.

« Mon application ne joint pas sa dépendance »

La matrice qui-joint-qui

Cible	Joignable ?
Service du même namespace (http://mon-svc)	✅
Service d’un autre namespace de votre organisation (http://mon-svc.c-acme-rtximz-tooling)	✅
Service d’une autre organisation	❌ bloqué by design — passez par son exposition publique
Internet (API externes, registres…)	✅ egress libre

Diagnostic pas à pas

# 1. La cible existe-t-elle et a-t-elle des endpoints ?
kubectl get svc,endpointslices -n <namespace-cible>
# Un Service sans endpoints = selector qui ne matche aucun pod prêt

# 2. Test de connectivité depuis un pod
kubectl exec -it deploy/mon-app -n <namespace> -- sh
wget -qO- http://mon-svc.<namespace-cible>:80/ --timeout=5

Causes fréquentes, dans l’ordre :

1. Service sans endpoints : le selector du Service ne correspond pas aux labels des pods, ou les pods ne passent pas leur readinessProbe ;
2. Mauvais port : le Service écoute sur port, votre app sur targetPort — vérifiez les deux ;
3. Cible dans une autre organisation : c’est l’isolation qui joue, pas une panne (pourquoi) ;
4. L’egress n’est jamais le coupable : les connexions sortantes (Internet, APIs externes) sont libres — si une API externe ne répond pas, le problème est chez elle ou dans votre configuration (DNS, proxy applicatif…).

« Mon site est injoignable depuis Internet »

Via Ingress (HTTP/HTTPS)

# 1. Le DNS pointe-t-il vers la plateforme ?
dig +short www.example.com
# Attendu : ingress.k-bdkbsh.blackswift.hosting. puis des IP

# 2. L'Ingress est-il bien câblé ?
kubectl describe ingress <ingress> -n <namespace>

Symptôme	Cause probable
Timeout / mauvais site affiché	DNS pas propagé ou CNAME absent — Configurer votre DNS
404 de nginx	Aucune règle Ingress ne matche ce host — vérifiez l’orthographe du domaine dans l’Ingress
503	Le Service cible n’existe pas, mauvais port, ou aucun pod prêt derrière
Avertissement certificat	Certificat pas encore émis — voir ci-dessous

Certificat TLS bloqué

L’émission Let’s Encrypt se suit de bout en bout :

kubectl get certificates -n <namespace>          # READY doit passer à True
kubectl get certificaterequests,orders,challenges -n <namespace>
kubectl describe challenge <nom> -n <namespace>  # le détail du blocage

Un challenge qui boucle = Let’s Encrypt n’arrive pas à joindre http://votre-domaine/.well-known/acme-challenge/…. Presque toujours : le DNS ne pointe pas (encore) vers la plateforme. Corrigez le DNS, l’émission repart seule.

Via NodePort ou LoadBalancer (TCP direct)

Le trafic arrive directement sur vos pods : le label exposition: public est requis sur les pods — pas sur le Service. Vérifiez :

kubectl get pods -n <namespace> -L exposition
# La colonne EXPOSITION doit afficher "public"

Le label se pose dans le template du Deployment (exemple) — un label ajouté à la main sur un pod disparaît à son prochain remplacement.

---

Toujours bloqué ? Contactez le support avec la sortie des commandes de cette page.