OpenShift Integration mit VMware NSX und Antrea CNI

Die Integration von Red Hat OpenShift mit VMware NSX und dem Antrea Container Network Interface (CNI) eröffnet neue Möglichkeiten für fortschrittliches Netzwerkmanagement in Kubernetes-Umgebungen. In diesem technischen Blog-Artikel dokumentiere ich die Implementierung eines Proof of Concept (PoC), der die erfolgreiche Integration dieser Technologien demonstriert.

Zielsetzung und Motivation

Der Hauptzweck dieses PoC liegt in der Validierung der erfolgreichen Integration von OpenShift mit VMware NSX und NSX Avi LoadBalancer. Dabei stehen zwei zentrale Aspekte im Fokus:

Egress Traffic Management

Die Implementierung von Antrea Egress Pools ermöglicht es, ausgehenden Datenverkehr von spezifischen Namespaces oder Pods über dedizierte und vordefinierte Egress-IP-Adressen zu leiten. Dies ist besonders wichtig für Mandantenfähigkeit und Compliance-Anforderungen.

Antrea bietet als CNI-Plugin erweiterte Netzwerkfunktionen wie richtliniengesteuerte Verkehrskontrolle und IP-basiertes Egress-Routing, die über die nativen Funktionen der Standard-CNI von OpenShift (OVN-Kubernetes) hinausgehen.

Ingress Traffic Management

Durch die Integration des NSX Avi LoadBalancers wird eine hochverfügbare und skalierbare Lösung für eingehenden Datenverkehr bereitgestellt.

Lab und Versionen

Für die Implementierung wurde eine Testumgebung mit folgenden Versionen aufgebaut:

• vCenter: 8.0.3 (Build 24674346)
• ESXi: 8.0.3 (Build 24674464)
• NSX: 4.2.2.0 (Build 24730888)
• NSX Avi LoadBalancer: 22.1.7
• OpenShift: 4.18.9
• Antrea: VMware Antrea v1.11.0

Vorbereitung der NSX-Infrastruktur

NSX-Konfiguration

Die NSX-Umgebung erfordert mehrere grundlegende Komponenten:

T0 Router

Für den PoC wurde ein vorhandener T0 Router verwendet, der als Active-Active konfiguriert ist und per BGP mit einem MikroTik Switch über zwei Uplink-VLANs peert.

T1 Router

Ein dedizierter T1 Router wurde speziell für den PoC erstellt und als “Distributed Only” konfiguriert. T1 Router im HA-Modus “Distributed Only” haben den Vorteil, dass der Traffic distributed geroutet wird und nicht über die Edge Nodes läuft, was sich positiv auf die Performance auswirkt.

T1 Router für NSX Advanced LoadBalancer Management

Für den NSX Advanced LoadBalancer wird ein dedizierter T1 Router “Distributed Only” für das Service Engine Management Segment erstellt.

Overlay Segment

Ein Overlay-Segment für die OpenShift Plattform. In diesem Segment befinden sich sowohl die OpenShift VMs als auch die LoadBalancer Service Engines. Eine wichtige Anforderung von OpenShift ist, dass sich die VIP für Ingress und API im selben “MachineNetwork” befinden.

Für das Management der NSX Advanced LoadBalancer Service Engines wird ein Overlay-Segment erstellt und mit dem T1 Router der dafür erstellt wurde verbunden.

Firewall (Distributed-Firewall / Gateway-Firewall

Wird eine Firewall wie zum Beispiel die Distributed Firewall verwendet, müssen folgende Freischaltungen erstellt werden. Genaue Angaben zu den benötigten Firewall Freischaltungen findet man unter ports.broadcom.com oder in den Installationsunterlagen von OpenShift.

NSX Advanced LoadBalancer Konfiguration

Content Library

Der NSX Advanced LoadBalancer benöntigt eine Content Library für die automatische Bereitstellung der Service Engines

Cloud-Konfiguration

Das Management Segment und der T1 Router wird als Management Network hinzugefügt. Das ls-ocp01 Segment muss als Data Network Segment in der NSX Cloud hinzugefügt werden.

Network Profile

Unter “Infrastructure” → “Cloud Resources” → “Networks” muss das Network Profile für ls-ocp01 und Management entsprechend konfiguriert werden.

IPAM Profile

Das Segment muss im IPAM/DNS Profile ergänzt werden, um automatische IP-Zuweisung zu ermöglichen.

Routing / VRF Context

Für das “Shared” OpenShift Segement ist keine Route notwendig. Möchte man für AKO und virtual Services ein dediziertes Ingress-Segment verwenden, muss für dieses eine “Default Route” konfiguriert werden. Infrastructure → Cloud Ressources → VRF Context

Service Engine Group

Eine dedizierte Service Engine Group wurde mit folgender Konfiguration erstellt: (Dies ist optional, es kann auch eine bestehende Service Engine Group verwendet werden)

• Active/Standby Modus
• 1 vCPU pro Service Engine
• 2 GB Memory pro Service Engine
• SE Name Prefix: ocp01
• 25 Virtual Services pro Service Engine

Virtual Services

Für die OpenShift-Installation werden initial vier Virtual Services benötigt:

Alle Virtual Services werden als “System-L4-Application” erstellt, mit System-TCP Health Monitor und der entsprechenden Service Engine Group.

Nach der Erstellung der Virtual Services, werden diese als “Down” angezeigt, da noch keine Backend Server existieren.

Folgender Ablauf ist während der OpenShift Installation zu beobachten:

1. Nach Erstellung der Virtual Services -> “Down”
2. OpenShift Installation beginnt und die Bootstrap VM wird erstellt -> Virtual Service api und api-int sind “Up”
3. Im Verlauf der OpenShift Installation -> Virtual Service ingress-http und https sind “Up”
4. Installation von OpenShift ist abgeschlossen -> Alle Virtual Service sind im Status “Up”
5. Der Server Pool der Virtual Services api und api-int zeigt 3/4 Server als “Up” an, die Bootstrap VM wird während der Installation automatisch zerstört und ist nicht mehr vorhanden und kann aus dem Server Pool entfernt werden.

DNS und NTP-Konfiguration

NTP-Server

Ein zentraler NTP-Zeitserver ist für die Synchronisation aller Komponenten erforderlich.

DNS-Einträge

Forward-Zone

; lab ocp01
master-01.ocp01     IN A 10.172.145.1
master-02.ocp01     IN A 10.172.145.2
master-03.ocp01     IN A 10.172.145.3
bootstrap.ocp01     IN A 10.172.145.20
api.ocp01           IN A 10.172.145.225
api-int.ocp01       IN A 10.172.145.225
*.apps.ocp01        IN A 10.172.145.230

Reverse-Zone

; lab ocp01
1.145   IN PTR master-01.ocp01.vi-universe.lab.
2.145   IN PTR master-02.ocp01.vi-universe.lab.
3.145   IN PTR master-03.ocp01.vi-universe.lab.
20.145  IN PTR bootstrap.ocp01.vi-universe.lab.
225.145 IN PTR api.ocp01.vi-universe.lab.
225.145 IN PTR api-int.ocp01.vi-universe.lab.

OpenShift Installation mit Antrea CNI

Vorbereitung der Installationsdateien

Download der erforderlichen Komponenten

• OpenShift: Von https://mirror.openshift.com/pub/openshift-v4/clients/ocp/
  • openshift-client-xx.tar.gz
  • openshift-install-xxx.tar.gz
• Antrea: Von support.broadcom.com unter “My Downloads”
  • “VMware Container Networking with Antrea, K8s Operator Manifests” (deploy.tar.gz)

Installationsverzeichnis erstellen

mkdir ~/ocp-install
cd ~/ocp-install

Erstellung der Installationskonfiguration

openshift-install create install-config

Der interaktive Assistent fragt nach verschiedenen Parametern wie Plattform (vSphere), Cluster-Name, vCenter-Zugangsdaten und Ingress / VIP IP-Adresse. Die Ingress IP muss mit dem DNS A Record *.apps.ocp01.vi-universe.lab übereinstimmen und die VIP IP mit dem API und API-Int A-Record.

Die vCenter CA muss auf dem Installationsnode als “Trusted” hinterlegt werden.

Beispiel install-config.yaml

additionalTrustBundlePolicy: Proxyonly
apiVersion: v1
baseDomain: vi-universe.lab #Muss entsprechend angepasst werden
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 0
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: ocp01       #Muss entsprechend angepasst werden
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.172.145.0/24 #Muss entsprechend angepasst werden
  networkType: antrea     #Muss entsprechend auf Antrea angepasst werden
  serviceNetwork:
  - 172.30.0.0/16
platform:
  vsphere:
    apiVIPs:
    - 10.172.145.225     # Muss entsprechend angepasst werden
    failureDomains:
    - name: generated-failure-domain
      region: generated-region
      server: vcsa-01a.vi-universe.lab  # Muss entsprechend angepasst werden
      topology:
        computeCluster: /vi-universe-datacenter/host/nuc11pro-i5 # Muss entsprechend angepasst werden
        datacenter: vi-universe-datacenter # Muss entsprechend angepasst werden
        datastore: /vi-universe-datacenter/datastore/local-esxi-01a_sata_ssd_ds01 # Muss entsprechend angepasst werden
        networks:
        - ls.ocp01 # Muss entsprechend angepasst werden
        resourcePool: /vi-universe-datacenter/host/nuc11pro-i5/Resources # Muss entsprechend angepasst werden
      zone: generated-zone
    ingressVIPs:
    - 10.172.145.230 # Muss entsprechend angepasst werden 
    loadBalancer:
        type: UserManaged
    hosts:
    - role: bootstrap 
      networkDevice: 
        ipAddrs: # Muss entsprechend angepasst werden
        - 10.172.145.20/24
        gateway: 10.172.145.254
        nameservers:
        - 10.172.254.255
    - role: control-plane
      networkDevice:
        ipAddrs:
        - 10.172.145.1/24
        gateway: 10.172.145.254
        nameservers:
        - 10.172.254.255
    - role: control-plane
      networkDevice:
        ipAddrs:
        - 10.172.145.2/24
        gateway: 10.172.145.254
        nameservers:
        - 10.172.254.255
    - role: control-plane
      networkDevice:
        ipAddrs:
        - 10.172.145.3/24
        gateway: 10.172.145.254
        nameservers:
        - 10.172.254.255
    vcenters:
    - datacenters:
      - vi-universe-datacenter # Muss entsprechend angepasst werden
      password: VMware1! # Muss entsprechend angepasst werden
      port: 443
      server: vcsa-01a.vi-universe.lab # Muss entsprechend angepasst werden
      user: administrator@vsphere.local # Muss entsprechend angepasst werden
publish: External
pullSecret: '{"auths":{"cloud.openshift.com":   # Muss entsprechend angepasst werden
sshKey:         # Muss entsprechend angepasst werden

Wichtiger Hinweis: Vor der Erstellung der Manifests sollte unbedingt eine Kopie der install-config.yaml erstellt werden, da diese nach dem nächsten Befehl aufgelöst wird.

Manifest-Erstellung und Antrea-Integration

openshift-install create manifests

In den Manifest-Ordner müssen alle Dateien aus dem Antrea-Download kopiert werden. Inhalt Antrea-Download

Dabei sind folgende Anpassungen erforderlich:

operator.yaml

Der Imagepfad muss angepasst werden:

Die Image-Pfade können aus den NSX Antrea 1.11.0 Release Notes entnommen werden.

image: projects.packages.broadcom.com/antreainterworking/antrea-operator:v2.3.0_vmware.1

operator.antrea.vmware.com_v1_antreainstall_cr.yaml

Verschiedene Image-Pfade und Konfigurationen müssen angepasst werden:

antreaAgentImage: projects.packages.broadcom.com/antreainterworking/antrea-agent-ubi:v2.3.0_vmware.1
antreaControllerImage: projects.packages.broadcom.com/antreainterworking/antrea-controller-ubi:v2.3.0_vmware.1
interworkingImage: projects.packages.broadcom.com/antreainterworking/interworking-ubi:1.3.0_vmware.1

Unter dem Abschnitt “Feature Gates und MP Adapter” müssen folgende Parameter konfiguriert werden.

featureGates:
  NodePortLocal: true  # Bei Verwendung mit NSX Advanced LoadBalancer notwendig
  EgressSeparateSubnet: true  # Notwendig für NSX ChildSegments

mpAdapterConfig:
  clusterName: ocp01  # Muss identisch zur install-config.yaml sein
  nsxManagers: ["IP-Adressen der NSX Manager"]
  enableInterworking: false  # Initial auf false, später auf true ändern

Der folgende Screenshot zeigt die Ordnerstruktur, wie diese nach der Erstellung der Manifests aussieht.

Installation OpenShift

./openshift-install create cluster

Zu beginn der OpenShift Installation, wird ein Bootstrap Node erstellt. Mit dem in der “install-config” angegebenen SSH-Key, kann sich mit dem Bootstrap, Master und Worker Nodes per SSH verbunden werden.

Nach erfolgreicher Installation kann die Kubeconfig exportiert und der Cluster überprüft werden:

export KUBECONFIG=auth/kubeconfig 
./oc get nodes,co

Registrierung von Antrea CNI mit NSX Manager

Zertifikat-Erstellung für Service Principal

# Private Key generieren
openssl genrsa -out antrea-sp.key 2048

# Certificate Signing Request erstellen
openssl req -new -key antrea-sp.key -out antrea-sp.csr \
  -subj "/CN=antrea-sp,OU=NSX,O=MyOrg,L=City,C=DE"

# Zertifikat generieren
openssl x509 -req -in antrea-sp.csr -signkey antrea-sp.key -out antrea-sp.crt -days 365

NSX Principal Identity konfigurieren

Im NSX Manager unter “System” → “Settings” → “User Management” → “Add Principal Identity” wird der Principal User mit der Rolle “Enterprise Admin” erstellt.

Registrierung durchführen

Base64-Kodierung der Zertifikate

cat antrea-sp.crt | base64 -w 0 
cat antrea-sp.key | base64 -w 0 

nsx-cert.yaml erstellen

Die Base64-kodierten Werte werden in die nsx-cert.yaml eingefügt.

Interworking aktivieren

In der operator.antrea.vmware.com_v1_antreainstall_cr.yaml:

enableInterworking: true

Anwendung der Konfiguration

./oc apply -f operator.antrea.vmware.com_v1_antreainstall_cr.yaml -f nsx-cert.yaml
./oc get pods -n vmware-system-antrea

Verifikation und Troubleshooting

Nach erfolgreicher Registrierung sollte das OpenShift Cluster in NSX unter “System” → “Fabric” → “Nodes” → “Container Clusters” → “Antrea” sichtbar sein und einen grünen Status anzeigen.

Wichtige Prüfpunkte

1. Pod-Status überprüfen: Alle Antrea-Pods sollten im Status “Running” sein
2. NSX-Registrierung: Das Cluster sollte in NSX als registriert angezeigt werden
3. Netzwerkkonnektivität: Traffic zwischen Pods sollte ordnungsgemäß funktionieren
4. LoadBalancer-Funktionalität: Virtual Services sollten erreichbar sein

Antrea Egress und ChildSegments

Für die erfolgreiche Bereitstellung von NSX ChildSegments und Antrea Egress Pools müssen folgende Anforderungen erfüllt sein:

1. operator.antrea.vmware.com_v1_antreainstall_cr.yaml FeatureGates → Muss EgressSeparateSubnet: true gesetzt sein
2. OpenShift RP_Filter=2 Die RP_Filters müssen auf 2 gesetzt werden, ansonsten wird der Traffic über das Antrea Interface verhindern. Diese Einstellungen können über den Cluster Node Tuning Operator vorgenommen werden.

Die Option kann per Label auf eine bestimmte Gruppe von Hosts umgesetzt werden → node-role.kubernetes.io/worker:

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: antrea
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Update rp_filter for all
      [sysctl]
      net.ipv4.conf.all.rp_filter=2      
    name: openshift-antrea
  recommend:
  - match:
    - label: node-role.kubernetes.io/worker
      value: ""
    priority: 10
    profile: openshift-antrea

NSX ChildSegments

1. Die verwendete Kubernetes Version muss mindestens 1.31 oder neuer sein
2. Feature Übersicht für Container Workloads in ChildSegments

Nicht unterstützte Features

• Distributed Firewall
• IP Discovery Segment Profile
• MAC Discovery Segment Profile
• Segment Security Segment Profile
• SpoofGuard Segment Profile
• QoS Segment Profile
• Port Mirroring
• IPFix
• NSGroup
• Latency-Funktionen

Unterstützte Features

• Uplink Teaming: Vollständig unterstützt
• Mirror Configuration (Uplink Span): Vollständig unterstützt

NSX ChildSegments bieten die Möglichkeit, Kubernetes Egress-Traffic zu separieren und unterschiedlich zu routen oder zu “NAT-en”. Ein Beispiel dafür wäre die Trennung von Kubernetes Namespaces, welche ein dediziertes ChildSegment und unterschiedliche T1 Router und T0-VRFs verwenden.

Dabei handelt es sich um reguläre NSX Segmente. Folgende Regeln gelten:

• Ein Child-Segment kann mit mehreren Parent-Segmenten verbunden werden
• Ein Parent-Segment kann zahlreiche Child-Segmente haben
• Jedes Child-Segment benötigt eine eindeutige VLAN-ID pro Parent-Segment
• Child-Segmente können nicht als Parent für andere Child-Segmente fungieren
• Innerhalb eines Parent-Segments müssen alle VLAN-IDs der Child-Segmente eindeutig sein
• Ein Child-Segment kann bei verschiedenen Parent-Segmenten dieselbe oder unterschiedliche VLAN-IDs verwenden
• Parent-Segmente senden nur Traffic an Child-Segmente, der mit der entsprechenden VLAN-ID getaggt ist

Connection Binding zwischen Parent und ChildSegment

curl --location --request PUT 'https://nsx-manager-IP-or-FQDN/policy/api/v1/infra/segments/Child-Segment/segment-connection-binding-maps/map100' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW46Vk13YXJlMSFWTXdhcmUxIQ==' \
--data '{
 "segment_path": "/infra/segments/Parent-Segment",
 "vlan_traffic_tag": "100" 
}'

Überprüfung des Bindings

curl --location --request GET 'https://nsx-manager-IP-or-FQDN/policy/api/v1/infra/segments/Child-Segment/segment-connection-binding-maps/'

OpenShift External IP Pool und Egress Ressource

External IP Pool

apiVersion: crd.antrea.io/v1beta1
kind: ExternalIPPool
metadata:
  name: child-egress-ippool
spec:
  ipRanges:
    - start: 10.172.170.1
      end: 10.172.170.199
  subnetInfo:
    gateway: 10.172.170.254
    prefixLength: 24
    vlan: 100 # VLAN ID welche beim Binding angegeben wurde
  nodeSelector: {}
  # Uncomment and modify below to limit which nodes are eligible
  # nodeSelector:
  #   matchLabels:
  #     network-role: egress-gateway

Egress Ressource

apiVersion: crd.antrea.io/v1beta1
kind: Egress
metadata:
  name: child-egress-hello-world1
spec:
  appliedTo:
    podSelector:
      matchLabels:
        app: hello-world1
  externalIPPool: child-egress-ippool

NSX Advanced LoadBalancer und AKO

AKO Installation

./oc create ns avi-system

helm show chart oci://projects.packages.broadcom.com/ako/helm-charts/ako --version 1.13.2

helm show values oci://projects.packages.broadcom.com/ako/helm-charts/ako --version 1.13.2 > values.yaml

Values.yaml Konfiguration

clusterName: ocp01
cniPlugin: 'antrea' 
vipNetworkList:
    - networkName: ls-ocp-1
  #    networkUUID: net-1234
      cidr: 10.172.145.0/24
nsxtT1LR: "/infra/tier-1s/avi-t1"

ControllerSettings:
  serviceEngineGroupName: ocp01  # Name of the ServiceEngine Group.
  controllerVersion: '' # The controller API version
  cloudName: nsx-01a   # The configured cloud name on the Avi controller.
  controllerHost: '10.172.10.225' # IP address or Hostname of Avi Controller
  tenantName: admin  

Helm Installation

helm install ako oci://projects.packages.broadcom.com/ako/helm-charts/ako --version 1.13.2 \
  -f /path/to/values.yaml \
  --set ControllerSettings.controllerHost=<controller IP or Hostname> \
  --set avicredentials.username=<avi-ctrl-username> \
  --set avicredentials.password=<avi-ctrl-password> \
  --namespace=avi-system

Wichtige Prüfpunkte

1. Pod-Status überprüfen: Alle Pods im avi-system Namespace sollten im Status “Running” sein

Dediziertes Ingress Netzwerk

Für ein dediziertes Ingress Netzwerk kann folgendermaßen vorgegangen werden:

1. Erstellen eines weiteren Overlay-Segments z.B. ls-ocp-ingress
2. Hinzufügen im NSX Advanced LoadBalancer entsprechend der obigen Konfiguration
3. Anpassung der values.yaml:

vipNetworkList:
    - networkName: ls-ocp-ingress
  #    networkUUID: net-1234
      cidr: 10.172.150.0/24

nsxtT1LR: "/infra/tier-1s/avi-t1"

L4 Virtual Service Beispiel

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: hello-world1
spec:
  selector:
    app: nginx
  loadBalancerClass: ako.vmware.com/avi-lb
  type: LoadBalancer
  ports:
   - protocol: TCP
     port: 8080
     targetPort: 80

Fazit und Ausblick

Die Integration von OpenShift mit VMware NSX und Antrea CNI bietet erweiterte Netzwerkfunktionen, die über Standard-CNI-Implementierungen hinausgehen. Besonders hervorzuheben sind:

• Erweiterte Egress-Kontrolle: Durch Antrea Egress Pools
• Erweiterte Ingress-Kontrolle: Durch NSX Avi LoadBalancer
• Mandantenfähigkeit: Durch dedizierte IP-Adressen pro Namespace
• Zentrale Verwaltung: Über NSX Manager

Dieser PoC demonstriert erfolgreich, dass eine vollständige Integration möglich ist und sowohl für Entwicklungs- als auch Produktionsumgebungen geeignet ist. Die Lösung eignet sich besonders für Unternehmen, die bereits VMware vSphere-Infrastrukturen betreiben und erweiterte Netzwerkfunktionen für ihre Container-Plattformen benötigen.

In zukünftigen Implementierungen sollten zusätzliche Sicherheitsrichtlinien, Monitoring-Lösungen und Automatisierungsaspekte berücksichtigt werden, um eine vollständige Enterprise-taugliche Lösung zu schaffen.