Module 2 — Kubernetes Ingress et réseaux cloud

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 9 minutes

---

Les 3 types de Service Kubernetes

Le module Kubernetes a déjà utilisé un Service de type ClusterIP — le type par défaut, accessible uniquement depuis l’intérieur du cluster. Il en existe deux autres :

Type	Portée	Cas d’usage
ClusterIP	Interne au cluster uniquement	Communication entre microservices (ex: l’app parlant à Redis)
NodePort	Un port fixe ouvert sur chaque nœud du cluster	Développement/démo ; rarement utilisé tel quel en production
LoadBalancer	Provisionne un load balancer cloud réel (ELB/ALB sur AWS, équivalents Azure/GCP)	Exposition publique en production, sur un cluster cloud managé

NodePort, exposé réellement sur le cluster de ce cours

$ kubectl expose deployment demo-app -n demo-app --name=demo-app-nodeport --type=NodePort --port=80 --target-port=5000
service/demo-app-nodeport exposed

$ kubectl get svc demo-app-nodeport -n demo-app
NAME                TYPE       CLUSTER-IP     PORT(S)
demo-app-nodeport   NodePort   10.43.88.221   80:32466/TCP

Kubernetes a choisi automatiquement le port 32466 (dans la plage par défaut 30000-32767) et l’a ouvert sur chaque nœud du cluster. Vérifié en accédant réellement à ce port depuis le nœud lui-même :

$ wget -qO- http://localhost:32466/
{"message":"Bonjour depuis le conteneur applicatif","visites":63}

Pourquoi LoadBalancer est préféré en production, malgré son coût : un NodePort expose un port au-dessus de 30000 sur chaque nœud — peu pratique à documenter, et chaque nœud devient un point d’entrée à sécuriser individuellement. Un type: LoadBalancer sur un cluster cloud managé (EKS, GKE, AKS) déclenche automatiquement la création d’un vrai load balancer cloud (par exemple un AWS Network Load Balancer), avec une IP publique stable unique — le NodePort sous-jacent existe toujours, mais reste un détail d’implémentation invisible pour l’utilisateur.

Ingress : un point d’entrée HTTP unique pour plusieurs services

Un Service de type LoadBalancer par application déployée devient coûteux (un load balancer cloud facturé par heure, par application). L’Ingress résout ça : un seul point d’entrée HTTP/HTTPS qui route vers plusieurs Services internes selon le nom d’hôte ou le chemin de l’URL.

ingress.yaml (exemple)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  namespace: demo-app
spec:
  rules:
    - host: app.exemple.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: demo-app
                port:
                  number: 80
    - host: admin.exemple.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: admin-app
                port:
                  number: 80

Un seul Ingress (et un seul load balancer cloud derrière lui) route ici deux noms de domaine différents vers deux Services internes distincts. C’est le rôle d’un Ingress Controller (Nginx Ingress Controller, ou Traefik — volontairement désactivé sur le cluster de démonstration de ce cours pour garder le focus sur les concepts fondamentaux) de lire ces règles et de les appliquer réellement.

Réseaux cloud : les briques de base

Au-delà de Kubernetes, tout déploiement cloud (AWS, Azure, GCP) repose sur les mêmes concepts réseau fondamentaux :

Concept	Rôle
VPC (Virtual Private Cloud)	Réseau privé et isolé, la limite de sécurité de premier niveau autour de vos ressources cloud
Sous-réseau (subnet)	Subdivision d’un VPC, généralement associée à une zone de disponibilité physique
Sous-réseau public vs privé	Public = route directe vers une passerelle internet ; privé = pas d’accès entrant direct depuis internet (bases de données, backends internes)
Groupe de sécurité (Security Group)	Pare-feu virtuel au niveau de l’instance — contrôle le trafic entrant/sortant par port et protocole
Table de routage	Détermine où va le trafic sortant d’un sous-réseau

Le schéma le plus courant : les serveurs applicatifs et le load balancer vivent dans des sous-réseaux publics, les bases de données et backends internes vivent dans des sous-réseaux privés — de sorte qu’une base de données n’est jamais directement joignable depuis internet, seulement depuis les serveurs applicatifs à l’intérieur du même VPC.

Internet
   │
   ▼
[ Load Balancer ]  ← sous-réseau public
   │
   ▼
[ Serveurs applicatifs ]  ← sous-réseau public ou privé selon l'architecture
   │
   ▼
[ Base de données ]  ← sous-réseau privé (jamais exposé directement)

Ce schéma correspond directement à ce qu’on observe déjà côté Kubernetes : un Ingress (le load balancer) expose l’application, un Service de type ClusterIP (Redis, dans les modules précédents) reste volontairement inaccessible depuis l’extérieur du cluster — la même logique de cloisonnement, appliquée à deux échelles différentes.

Prochaine étape

Bases de données et stockage : SQL, NoSQL et automatisation