--- title: "Exposer votre application" description: "Rendre votre application joignable, dans le cluster ou sur Internet : Service ClusterIP, Ingress HTTPS avec certificat automatique, NodePort et LoadBalancer." source_url: html: https://docs.blackswift.cloud/deployer/exposer-en-https/ md: https://docs.blackswift.cloud/deployer/exposer-en-https.md --- # Exposer votre application > Rendre votre application joignable, dans le cluster ou sur Internet : Service ClusterIP, Ingress HTTPS avec certificat automatique, NodePort et LoadBalancer. Cette page vous guide pour rendre vos applications accessibles — à l'intérieur du cluster ou depuis Internet, en HTTPS avec un certificat automatique. :::tip[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) 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**. ```bash kubectl expose deploy/nginx-demo --name web --port 80 -n ``` Ou en YAML : ```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 : ```text http://web..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 : ```text 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](https://docs.blackswift.cloud/deployer/configurer-votre-dns.md). ### Étape 2 : créez l'Ingress avec certificat automatique ```bash kubectl create ingress web-public -n \ --rule "www.example.com/*=web:80,tls=web-tls" \ --annotation cert-manager.io/issuer=letsencrypt ``` ```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 ``` Si vous avez déjà un certificat (wildcard d'entreprise…), créez le secret TLS vous-même et omettez l'annotation cert-manager : ```bash kubectl -n 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 : ```bash kubectl get certificates,challenges -n ``` > ✅ **Test** : ouvrez `https://www.example.com` — votre application s'affiche, > avec un certificat valide. ## 3. Exposer un protocole non-HTTP ### Option A — NodePort (inclus, quota 10) Pour du TCP simple (MQTT, SSH, jeu…) : ```bash kubectl -n expose deploy/ \ --type=NodePort --port= --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](https://docs.blackswift.cloud/comprendre/isolation-reseau.md) bloque le trafic externe ; 2. Relevez le port attribué (`kubectl get svc -n `) et connectez-vous sur `nodeport.k-bdkbsh.blackswift.hosting:`. À 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 : ```yaml 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](https://docs.blackswift.cloud/reference/facturation.md#loadbalancer) ; - Quota : 1 par namespace — si votre namespace affiche encore `services.loadbalancers: 0`, demandez l'activation via [ticket](https://docs.blackswift.cloud/depanner/contacter-le-support.md) ; - 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.cluster.local` | | HTTP(S) public | Ingress + Service | votre domaine ([CNAME](https://docs.blackswift.cloud/deployer/configurer-votre-dns.md)) | | TCP public mutualisé | NodePort + label `exposition: public` | `nodeport.k-bdkbsh.blackswift.hosting:` | | 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](https://docs.blackswift.cloud/depanner/checklist-de-diagnostic.md).