Exposer votre application

Cette page vous guide pour rendre vos applications accessibles — à l’intérieur du cluster ou depuis Internet, en HTTPS avec un certificat automatique.

Kubernetes en 2 phrases

• Service = petit load balancer interne : il donne une IP + un nom DNS stable pour joindre vos Pods.
• Ingress = reverse-proxy frontal (HTTPS) : il reçoit les requêtes venant d’Internet et les renvoie vers un Service.

1. Rendre l’application joignable dans le cluster (Service)

Via Rancher

1. Ouvrez Service Discovery › Services dans votre namespace.
2. Cliquez sur Create et choisissez ClusterIP.
3. Remplissez :
   • Name : web
   • Selectors : app=nginx-demo (les labels de vos pods)
   • Port : 80 (port d’écoute de votre conteneur)
4. Validez avec Create.

Via kubectl

kubectl expose deploy/nginx-demo --name web --port 80 -n <namespace>

Ou en YAML :

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: nginx-demo
  ports:
    - port: 80
      targetPort: 80

Votre application répond maintenant, depuis n’importe quel pod de vos namespaces, sur :

http://web.<votre-namespace>.svc.cluster.local

2. Publier en HTTPS sur votre domaine (Ingress)

Étape 1 : pointez votre domaine

Créez un enregistrement CNAME chez votre fournisseur DNS :

www.example.com  →  ingress.k-bdkbsh.blackswift.hosting

Le guide détaillé par fournisseur (OVHcloud, Gandi, Cloudflare…), y compris le cas du domaine racine (example.com sans www), est ici : Configurer votre DNS.

Étape 2 : créez l’Ingress avec certificat automatique

Via kubectl

kubectl create ingress web-public -n <namespace> \
  --rule "www.example.com/*=web:80,tls=web-tls" \
  --annotation cert-manager.io/issuer=letsencrypt

Via un manifest YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-public
  annotations:
    cert-manager.io/issuer: letsencrypt
spec:
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80
  tls:
    - hosts: ["www.example.com"]
      secretName: web-tls

Certificat personnalisé

Si vous avez déjà un certificat (wildcard d’entreprise…), créez le secret TLS vous-même et omettez l’annotation cert-manager :

kubectl -n <namespace> create secret tls web-tls \
  --cert=fullchain.pem --key=privkey.pem

Puis référencez web-tls dans la section tls de l’Ingress.

L’annotation cert-manager.io/issuer: letsencrypt déclenche l’émission automatique d’un certificat Let’s Encrypt (généralement en 1 à 2 minutes, une fois le DNS propagé). Suivez l’émission :

kubectl get certificates,challenges -n <namespace>

✅ Test : ouvrez https://www.example.com — votre application s’affiche, avec un certificat valide.

Note

Aucun label particulier n’est requis sur vos pods pour l’exposition via Ingress : le trafic transite par le reverse-proxy de la plateforme. Le label exposition: public ne concerne que le NodePort et le LoadBalancer ci-dessous.

Au sujet du retrait du projet ingress-nginx

Le projet open source ingress-nginx a été arrêté en mars 2026 — vous l’avez peut-être lu. C’est anticipé et géré : la plateforme s’appuie sur les images maintenues par Chainguard (programme EmeritOSS), spécialiste des images « zéro CVE », qui corrige les vulnérabilités et met à jour les dépendances. Vos Ingress et leurs annotations continuent de fonctionner à l’identique, sans aucune action de votre part.

3. Exposer un protocole non-HTTP

Option A — NodePort (inclus, quota 10)

Pour du TCP simple (MQTT, SSH, jeu…) :

kubectl -n <namespace> expose deploy/<deployment> \
  --type=NodePort --port=<port> --name=<service-name>

⚠️ Deux conditions pour que le service soit joignable depuis Internet :

1. Ajoutez le label exposition: public sur vos pods (pas sur le Service) — sans lui, la politique réseau bloque le trafic externe ;
2. Relevez le port attribué (kubectl get svc -n <namespace>) et connectez-vous sur nodeport.k-bdkbsh.blackswift.hosting:<node-port>.

À savoir : un NodePort ne peut pas être restreint par adresse IP source — une fois exposé, le port répond à tout Internet. Si vous devez limiter l’accès à certaines IP (VPN d’entreprise, partenaires…), utilisez un LoadBalancer et son loadBalancerSourceRanges (ci-dessous), ou gérez la restriction dans l’application.

Option B — LoadBalancer (option payante, IP dédiée)

Pour une IP publique dédiée avec le port de votre choix :

apiVersion: v1
kind: Service
metadata:
  name: mon-service-public
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster   # Cluster ou Local — voir ci-dessous
  loadBalancerSourceRanges:        # optionnel : IP sources autorisées
    - 203.0.113.0/24
    - 198.51.100.42/32
  selector:
    app: mon-app        # pods qui doivent porter le label exposition: public
  ports:
    - port: 5432

• Tarif : 0,02 €/h par LoadBalancer ;

• Quota : 1 par namespace — si votre namespace affiche encore services.loadbalancers: 0, demandez l’activation via ticket ;

• Le label exposition: public est requis sur les pods ciblés. Il ouvre le pod à tout ce qui peut l’atteindre : le filtrage se fait par loadBalancerSourceRanges, pas par une NetworkPolicy. Une règle ipBlock ajoutée à côté ne restreindra rien — les politiques réseau s’additionnent, et celle qui accompagne le label autorise tout ;

• loadBalancerSourceRanges restreint l’accès aux plages d’IP listées (CIDR) — c’est l’avantage du LoadBalancer sur le NodePort, qui ne le permet pas. Omettez le champ pour un service ouvert à tous ;

• externalTrafficPolicy : Cluster ou Local, selon votre service. Les deux modes fonctionnent quelle que soit la région où tournent vos pods, et loadBalancerSourceRanges s’applique à l’identique dans les deux cas — il agit à l’entrée du LoadBalancer, avant tout routage interne.

  • Cluster répartit le trafic sur toutes vos réplicas, où qu’elles soient. En contrepartie, lorsque la réplique servie n’est pas sur le nœud d’entrée, le paquet fait un saut de plus et votre application voit une adresse interne du cluster à la place de celle du client.
  • Local sert le client sans saut supplémentaire et votre application voit la vraie IP source. En contrepartie, seules les réplicas situées sur un même nœud reçoivent du trafic : les autres n’en voient aucun.

  En pratique : Local pour un service à instance unique (base de données, broker, serveur de jeu) — vous y gagnez l’IP réelle du client et un saut de moins, sans rien perdre. Cluster dès que vous comptez sur plusieurs réplicas pour encaisser la charge.

  Dans les deux modes, si plus aucun pod ne tourne, l’IP cesse d’être annoncée : le LoadBalancer ne masque pas une indisponibilité de votre service.

Récapitulatif

Besoin	Objet K8s	Accès
Interne au cluster	Service ClusterIP	<svc>.<ns>.svc.cluster.local
HTTP(S) public	Ingress + Service	votre domaine (CNAME)
TCP public mutualisé	NodePort + label exposition: public	nodeport.k-bdkbsh.blackswift.hosting:<port>
TCP public, IP dédiée	LoadBalancer + label exposition: public	IP dédiée (0,02 €/h)

Un problème d’exposition ? Voir Problème de connexion ou de réseau.