Aller au contenu principal
Wiki Cloud Avenue
Tous les sujets

Comprendre l’exposition réseau sur Hosted OpenShift on VCD

L’exposition réseau d’une application sur un Hosted Cluster OpenShift Cloud Avenue est particulière :
l’environnement IaaS ne permet pas d’attacher une IP publique directement à un workload Kubernetes.
Ce comportement est volontaire, hérité du modèle sécurisé Cloud Avenue.

Ce guide explique :

  • pourquoi l’IP publique ne peut pas être attachée directement,
  • comment Cloud Avenue utilise MetalLB par défaut,
  • comment créer un pool d’IP interne pour vos applications,
  • comment publier vos services via DNAT sur la Edge Gateway du tenant.

1. Pourquoi on ne peut pas attribuer une IP publique directement à un Service LoadBalancer ?

Dans Cloud Avenue, chaque tenant possède sa propre Edge Gateway.
C’est elle qui gère :

  • les IP publiques,
  • les règles NAT,
  • la sécurité réseau,
  • l’isolation entre tenants.

De ce fait :

  • aucune IP publique ne peut être assignée à un worker,
  • aucune IP publique ne peut être attribuée à un service Kubernetes,
  • toute exposition vers Internet passe obligatoirement par la Edge du tenant.

En résumé :

Une IP publique ne peut jamais pointer directement vers un pod. L’accès se fait uniquement via des règles DNAT sur la Edge Gateway.

2. Pourquoi Cloud Avenue déploie MetalLB par défaut ?

Les environnements IaaS (comme Cloud Avenue) ne disposent pas d’un load balancer natif Kubernetes.
OpenShift ne peut donc pas attribuer automatiquement des IP externes sans un composant supplémentaire.

C’est pour cela que Cloud Avenue installe MetalLB par défaut.

MetalLB, c’est quoi ?

MetalLB est un Load Balancer pour Kubernetes conçu pour les environnements bare-metal et IaaS.
Il permet :

  • d’attribuer des IP internes aux Services de type LoadBalancer,
  • de répondre aux requêtes ARP/Layer2 sur le réseau des workers,
  • de fournir une IP interne stable pour chaque application exposée.

Mais ces IP restent internes.
Pour les rendre publiques, il faut du DNAT.

3. Le pool MetalLB par défaut livré avec chaque cluster

Lors de la livraison, Cloud Avenue configure un premier pool MetalLB très restreint.
Il sert uniquement à :

  • l’accès à la console OpenShift,
  • l’accès aux routes Ingress *.apps.<CLUSTER_ID>.kaas.cav.

Ce pool contient une unique IP (ou un très petit range).
Il ne doit pas être utilisé pour les applications du client.

4. Comment exposer ses applications ?

→ Il faut créer un pool MetalLB supplémentaire

Pour exposer vos applications via LoadBalancer, vous devez créer votre propre pool MetalLB.

Ce pool doit :

  • appartenir au même réseau que les workers,
  • ne pas chevaucher le pool OpenShift,
  • utiliser des IP disponibles dans votre plage réseau.

Exemple

Supposons que vos workers utilisent le réseau :
192.168.10.0/24

Vous pouvez réserver un pool pour vos apps :
192.168.10.50-192.168.10.100

5. Créer un pool MetalLB (AddressPool + L2Advertisement)

Voici un exemple complet à adapter selon votre réseau.

IPAddressPool

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: pool-applications
  namespace: metallb-system
spec:
  addresses:
    - 192.168.10.50-192.168.10.100

L2Advertisement

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: pool-applications
  namespace: metallb-system
spec:
  ipAddressPools:
    - pool-applications

Appliquez la configuration :

oc apply -f pool-applications.yaml

Vérifiez :

oc -n metallb-system get ipaddresspool
oc -n metallb-system get l2advertisement

6. Déployer votre service LoadBalancer (attribue une IP MetalLB interne)

Exemple :

oc expose deployment myapp --type=LoadBalancer --port=8080

Vérifiez :

oc get svc myapp

Vous verrez une IP interne provenant du pool, par exemple :

EXTERNAL-IP   192.168.10.55

⚠️ Cette IP n’est pas publique.
Elle n’est accessible que dans le réseau du tenant.

7. Rendre l’application accessible depuis Internet : créer une règle DNAT

Pour exposer votre application au public, il faut créer une règle DNAT sur la Edge Gateway du tenant :

Public IP → IP MetalLB → Pod

Exemple DNAT :

  • IP publique : 164.2.123.45
  • IP MetalLB du service : 192.168.10.55
  • Port public : 443
  • Port interne : 8080

La règle ressemblera à :

DNAT:
164.2.123.45:443  →  192.168.10.55:8080

À partir de cet instant :

  • l’IP publique répond,
  • la Edge translate vers l’IP MetalLB interne,
  • Kubernetes route ensuite vers votre application.

Résumé global

ÉlémentRôle
IP publiqueGérée par la Edge Gateway du tenant
MetalLBAttribue des IP internes LoadBalancer
Pool MetalLB par défautRéservé à OpenShift (*.apps + console)
Pool MetalLB clientPermet d’exposer vos applications
DNAT Edge GatewayRend l’application accessible depuis Internet

En une phrase :

MetalLB fournit une IP interne, la Edge la publie via DNAT, et l’application devient accessible depuis Internet.