Ich durfte bereits für diverse Projekte VMware NSX als SDN und/oder Security Lösung implementieren. In den letzten Jahren wirkte ich zudem in diversen Integrationsprojekten von Enterprise Container Plattformen, welche das NSX Container Plugin (NCP) als Container Network Interface (CNI) nutzen, mit. Vor allem bei vSphere with Tanzu Projekten ist das NCP, wie aber auch das Antrea CNI, eminent vertreten.

Da beide CNIs ähnliche Aspekte umfassen, liegt es nur nahe, dass man überlagernde Funktionen zentralisieren und einheitlich verwalten möchte. Mit VMware NSX erhält man eine einheitliche Verwaltungs- und Orchestrierungsinstanz für die Netzwerk- und Sicherheitsautomatisierung der Infrastruktur, aber auch der Container Plattform.

Die VMware Container Networking with Antrea Lösungskomponente umfasst u.a. den sog. NSX Interworking Adapter, welcher es mir erlaubt, meine Kubernetes Cluster am NSX Management Plane (MP) und Central Control Plane (CCP) zu registrieren. Dadurch stehen mir zusätzliche Funktionen im NSX Manager zur Verfügung:

• Anzeigen von Antrea K8s (Pods, Namespaces, Services etc.) Ressourcen im NSX UI.
• Zentrale Verwaltung von Gruppen und Security Policies im NSX UI, welche auf effektive K8s Ressourcen verweisen.
• Erweiterung der Trace Flow Funktionalität für Pod/CNI Datenflüsse für zentrales Monitoring und Analyse.
• Integration von K8s Cluster, wo Antrea als primäres oder sekundäres CNI genutzt wird.

Die Integration eines K8s Cluster mit Antrea in das NSX CCP/MP ist denkbar einfach und umfasst folgende Schritte:

1. Vorbereitung
   1. Ermitteln der aktuellen Antrea OSS Version
   2. Download der Konfigurationsdateien (YAML)
   3. Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration
2. Deployment des NSX Interworking Adapters

 

Vorbereitung

 

Ermitteln der aktuellen Antrea OSS Version

Als erstes muss die aktuell eingesetzte Open Source Software (OSS) Version vom Antrea CNI auf dem Kubernetes Ziel-Cluster ermittelt werden. Hierzu gibt es zweit gängige Optionen:

Option: vSphere with Tanzu

Hierzu muss man in den Context des vSphere Namespace wechseln, in welchem sich der Tanzu Kubernetes Cluster (TKC) befindet.

 
# Change into respective vSphere Namespace where TKC is located
kubectl config use-context VSPHERE_NAMESPACE

# Check the assocaited Antrea package of the respective TKC
kubectl get antreaconfigs.cni.tanzu.vmware.com CLUSTER_NAME-antrea-package \
--output yaml | grep antrea.tanzu.vmware.com

# Sample output from an antrea-package
apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: AntreaConfig
  metadata:
    labels:
      tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.11.3---vmware.2-tkg.2-advanced

Option: K8s Cluster lokal

Auf dem lokalen Kubernetes Cluster (in meinem Fall der TKC) kann man sich via kubectl exec Command in den Antrea Controller Pod einwählen und den antctl Command ausführen.

kubectl -n kube-system exec antrea-controller-8589557c86-wprxn --stdin --tty -- antctl version
antctlVersion: v1.11.3-79e45ea
controllerVersion: v1.11.3-79e45ea

Nach dem die OSS Version ermittelt wurde, kann man das korrespondierende VMware Container Networking with Antrea Software Bundle herunterladen. Hier eine kleine Übersicht der aktuellen Releases:

VMware Container Networking Version	Based on Antrea OSS Version	Compatible With Antrea-NSX Interworking Version
1.9.0 (Release Notes)	1.15.0	0.15.0_vmware.1
1.8.0 (Release Notes)	1.13.1	0.13.0_vmware.1
1.7.0 (Release Notes)	1.11.1	0.11.0

In unserem Fall müssen wir für die OSS Version 1.11.3 die VMware Container Networking with Antrea Version 1.7.0 nutzen, welche gem. Release Notes mit der Antrea Interworking Image Version 0.11.2_vmware.1 kompatibel ist:

Antrea-NSX images:

• projects.registry.vmware.com/antreainterworking/interworking-debian:0.11.0, 0.11.1, 0.11.2_vmware.1
• projects.registry.vmware.com/antreainterworking/interworking-ubuntu:0.11.0, 0.11.1
• projects.registry.vmware.com/antreainterworking/interworking-photon:0.11.0, 0.11.1, 0.11.2_vmware.1
• projects.registry.vmware.com/antreainterworking/interworking-ubi:0.11.0, 0.11.1

 

 

Download der Konfigurationsdateien (YAML)

Das entsprechende VMware Container Networking with Antrea Bundle kann über das VMware Customer Connect Portal bezogen werden.

Es sind jeweils mehrere Bundles gelistet und so gibt es auch für Antrea-NSX Interworking ein spezifisches: VMware Container Networking with Antrea, NSX Interworking Adapter Image and Deployment Manifests

Das Zip File sollte wie folgt benannt sein: antrea-interworking-<VERSION>.zip

Wie bereits erwähnt, habe ich beide Version 1.7.0 und 1.8.0 heruntergeladen, um aus der Version 1.8.0 das neuere antreansxctl CLI Tool zu extrahieren und jenes aus der Version 1.7.0 damit zu ersetzen. Anschliessend habe ich das 1.7.0 Bundle neu komprimiert und auf meinen Jumphost hochgeladen.

 

Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration

Sobald das Zip File vorhanden ist, kann man es entpacken:

# Extract the antrea-networking ZIP file
unzip antrea-interworking-0.11.0.zip
Archive: antrea-interworking-0.11.0.zip
creating: antrea-interworking-0.11.0/
creating: antrea-interworking-0.11.0/bin/
inflating: antrea-interworking-0.11.0/bin/antreansxctl.tar.gz
inflating: antrea-interworking-0.11.0/bootstrap-config.yaml
inflating: antrea-interworking-0.11.0/deregisterjob.yaml
inflating: antrea-interworking-0.11.0/interworking-debian-0.11.0.tar
inflating: antrea-interworking-0.11.0/interworking.yaml
inflating: antrea-interworking-0.11.0/inventorycleanup.yaml
inflating: antrea-interworking-0.11.0/ns-label-webhook.yaml

# Extract the antreansxctl CLI tool from the GZ file
tar -xzf antrea-interworking-0.11.0/bin/antreansxctl.tar.gz

# Move the antreansxctl binary to the local bin store to make it available for runtime execution
sudo mv antreansxctl /usr/local/bin

Nach dem sämtliche Files und Binaries vorhanden sind, muss noch eine kleine Anpassung bei den beiden Files interworking.yaml und deregisterjob.yaml (letzteres wird benötigt, wenn man die Integration entfernen möchte) vorgenommen werden. Damit die benötigten Images von der korrekten Image Registry heruntergeladen werden können, müssen die Image URI Parameter angepasst werden. In meinem Fall lade ich die Image von der offiziellen VMware Registry herunter:

projects.registry.vmware.com/antreainterworking/interworking-debian:VERSION
projects.registry.vmware.com/antreainterworking/interworking-ubuntu:VERSION
projects.registry.vmware.com/antreainterworking/interworking-photon:VERSION
projects.registry.vmware.com/antreainterworking/interworking-ubi:VERSION

Da ich das PhotonOS als Basis OS meines TKCs verwende, muss ich sämtliche Image URI Referenzen in den beiden Files interworking.yaml und deregisterjob.yaml ändern:

 
# Replace the field after "image: vmware.io/antrea/interworking:0.11.0" with "image: projects.registry.vmware.com/antreainterworking/interworking-photon:0.11.2_vmware.1" in interworking.yaml and deregisterjob.yaml
sed -i 's|image: vmware.io/antrea/interworking:0.11.0|image: projects.registry.vmware.com/antreainterworking/interworking-photon:0.11.2_vmware.1|' antrea-interworking-0.11.0/interworking.yaml antrea-interworking-0.11.0/deregisterjob.yaml

 

Als Workaround in der Version 1.7.0 kann man folgende Ergänzungen im interworking.yaml File vornehmen:

---
apiVersion: v1
kind: Namespace
metadata:
  name: vmware-system-antrea
  labels:
    app: antrea-interworking
    openshift.io/run-level: '0'
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: privileged
    pod-security.kubernetes.io/warn-version: latest
---

Alternativ kann man auch ca. 10 Minuten warten, bis der kapp-controller eingreift und den Namespace mit den entsprechenden Annotations ergänzt.

Mit dem antreansxctl CLI Tool kann nun das Bootstrap Config File erstellt und der NSX Principal Identity (PI) User (inkl. Self-signed Certificate) im NSX Manager hinterlegt werden:

antreansxctl bootstrap --cluster-name shared-tkc01 --nsx-managers 10.24.0.50 --user admin --password 'VMware1!VMware1!'
bootstrap.go:51] "bootStrap" User="admin" ClusterName="shared-tkc01"
cluster.go:260] Configure NSX client for manager IP 10.24.0.50
cluster.go:119] Selected endpoint index: 0, ip: 10.24.0.50
bootstrap.go:97] "Checking PrincipalIdentities in NSX" clusterName="shared-tkc01" Result=false
bootstrap.go:113] "Creating self signed cert" clusterName="shared-tkc01"
bootstrap.go:187] "Creating PrincipalIdentities in NSX" clusterName="shared-tkc01" vpc=""
bootstrap.go:205] "vpc argument is empty, creating enterprise admin PI"
bootstrap.go:225] "Creating principal identity" ClusterName="shared-tkc01"
bootstrap.go:233] "Created principal identity" user="shared-tkc01" vpc="" key="shared-tkc01.key" cert="shared-tkc01.crt" PrincipalIdentity={[...]}
bootstrap.go:235] "role: enterprise_admin on /"
bootstrap.go:275] "Creating bootstrap Configmap and Secret yaml file" clusterName="shared-tkc01" nsxManagers=["10.24.0.50"] vpc=""
bootstrap.go:278] "Created bootstrap Configmap and Secret yaml file" bootstrapYamlFile="shared-tkc01-bootstrap-config.yaml"

Anschliessend sollten folgende Files erstellt worden sein:

• shared-tkc01-bootstrap-config.yaml
• shared-tkc01.crt
• shared-tkc01.key

Mittels NSX API Call lässt sich rasch verifizieren, ob der PI User angelegt wurde:

curl -k -u 'admin:VMware1!VMware1!' \
--request GET 'https://10.24.0.50/api/v1/trust-management/principal-identities/' | grep -i '"name" : "shared-tkc01"' -A 22 -B 1
[…]
"results" : [ {
"name" : "shared-tkc01",
"node_id" : "shared-tkc01",
"role" : "enterprise_admin",
"certificate_id" : "0041f40a-4f52-4718-947d-3c57f7f98806",
"roles_for_paths" : [ {
"path" : "/",
"roles" : [ {
"role" : "enterprise_admin"
} ],
"delete_path" : false
} ],
"is_protected" : true,
"resource_type" : "PrincipalIdentity",
"id" : "03b51c9f-8bda-419d-8a26-9740895e82db",
"display_name" : "shared-tkc01@shared-tkc01",
"_create_time" : 1713260925476,
"_create_user" : "admin",
"_last_modified_time" : 1713260925476,
"_last_modified_user" : "admin",
"_system_owned" : false,
"_protection" : "NOT_PROTECTED",
"_revision" : 0
}, {

 

Deployment des NSX Interworking Adapters

Folgende Files werden für die Installation benötigt:

• shared-tkc01-bootstrap-config.yaml
• antrea-interworking-0.11.0/interworking.yaml

Anschliessend kann das Deployment via kubectl ausgeführt werden:

kubectl apply -f shared-tkc01-bootstrap-config.yaml -f antrea-interworking-0.11.0/interworking.yaml
namespace/vmware-system-antrea created
configmap/bootstrap-config created
secret/nsx-cert created
customresourcedefinition.apiextensions.k8s.io/antreaccpadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com created
customresourcedefinition.apiextensions.k8s.io/antreampadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com created
namespace/vmware-system-antrea configured
configmap/cluster-id created
configmap/antrea-interworking-config created
serviceaccount/register created
role.rbac.authorization.k8s.io/register created
rolebinding.rbac.authorization.k8s.io/register created
role.rbac.authorization.k8s.io/vmware-system-antrea-register created
rolebinding.rbac.authorization.k8s.io/vmware-system-antrea-register created
serviceaccount/interworking created
clusterrole.rbac.authorization.k8s.io/antrea-interworking created
clusterrolebinding.rbac.authorization.k8s.io/antrea-interworking created
clusterrole.rbac.authorization.k8s.io/antrea-interworking-supportbundle created
clusterrolebinding.rbac.authorization.k8s.io/antrea-interworking-supportbundle created
job.batch/register created
deployment.apps/interworking created

Bei erfolgreichem Deployment sollte der neue Namespace vmware-system-antrea angelegt worden sein und den Interworking Pod beherbergen:

kubectl -n vmware-system-antrea get all
NAME READY STATUS RESTARTS AGE
pod/interworking-579ff578f7-ng48n 4/4 Running 0 45s
pod/register-v5qrg 0/1 Completed 0 46s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/interworking 1/1 1 1 46s

NAME DESIRED CURRENT READY AGE
replicaset.apps/interworking-579ff578f7 1 1 1 45s

NAME COMPLETIONS DURATION AGE
job.batch/register 1/1 7s 46s

Anschliessend kann man über das NSX UI den Status der Integration verifizieren:

Ab diesem Punkt ist der K8s Cluster mit dem NSX CCP/MP registriert und kann bspw. für das Erstellen von Network Policies via NSX UI verwendet werden.