build 7bbbddf7 | content blog-content@c8490fa · 338 posts | profiles 20 · corpus 267 | 0 skipped | | format
apiVersion: soultec.ch/v1kind: Postmetadata: name: antrea-nsx-integration locale: de labels: author: matthias-grasmueck series: how-to capability/network: 2.16 capability/security: 2.16 capability/containers: 2.39 vendor/vmware: 0.88 annotations: source: blog-content/posts/de/antrea-nsx-integration.md route: /de/insights/antrea-nsx-integration/ schema: /nerd/schema/posts.json markdown: /de/insights/antrea-nsx-integration.mdspec: title: Antrea Integration in NSX date: 2024-04-16 author: matthias-grasmueck locale: de summary: >- Ich durfte bereits für diverse Projekte VMware NSX als SDN und/oder Security Lösung implementieren. capabilities: [network, security, containers] vendors: [vmware] series: how-to hero: /blog-assets/antrea-nsx-integration/hero.webp legacySlug: antrea-nsx-integration migrated: 2026-08-24 draft: false sections: - body: | Ich durfte bereits für diverse Projekte [VMware NSX](https://www.vmware.com/products/nsx.html) 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](https://www.vmware.com/products/vsphere/vsphere-with-tanzu.html) 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 > Die nachfolgenden Beispiele wurden auf einem vSphere with Tanzu (vSphere 8.0 Update 2) Cluster durchgeführt. Dabei wurde ein Tanzu Kubernetes (Guest) Cluster mit dem Tanzu Kubernetes Release (TKR) 1.26.13 basierend auf dem PhotonOS verwendet. - heading:

Ermitteln der aktuellen Antrea OSS Version

body: | Als erstes muss die aktuell eingesetzte Open Source Software (OSS) Version vom Antrea CNI auf dem Kubernetes Ziel-Cluster ermittelt werden. Hierzu gibt es zwei 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. ```yaml # 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](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) Command in den Antrea Controller Pod einwählen und den [antctl](https://antrea.io/docs/main/docs/antctl/) Command ausführen. ```yaml 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.9.0/rn/vmware-container-networking-with-antrea-190-release-notes/index.html)) | 1.15.0 | 0.15.0\_vmware.1 | | 1.8.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.8.0/rn/vmware-container-networking-with-antrea-180-release-notes/index.html)) | 1.13.1 | 0.13.0\_vmware.1 | | 1.7.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html)) | 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html) 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](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-debian/artifacts-tab?publicAndNotLogged=yes) - projects.registry.vmware.com/antreainterworking/interworking-ubuntu:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubuntu/artifacts-tab?publicAndNotLogged=yes) - projects.registry.vmware.com/antreainterworking/interworking-photon:[0.11.0, 0.11.1, 0.11.2\_vmware.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-photon/artifacts-tab?publicAndNotLogged=yes) - projects.registry.vmware.com/antreainterworking/interworking-ubi:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubi/artifacts-tab?publicAndNotLogged=yes) > Mit der VMware Container Networking with Antrea Version 1.7.0 wurde das [**antreansxctl**](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.x/vmware_antrea_install/GUID-DF0C6F11-9877-4849-8F3E-CC3F824126C0.html?hWord=N4IghgNiBc4HYBcBOBTMcDOAPAxgqAvkA) CLI Tool eingeführt. Das Tool wird ständig weiterentwickelt und neue Funktionen/Optimierungen werden im jeweils nächsten VMware Container Networking with Antrea Release mitgeliefert. In der VMware Container Networking with Antrea Version 1.7.0 ist das Tool noch eingeschränkt nutzbar und besitzt bspw. noch keine **bootstrap** Option. Dieser Optionsparameter ist jedoch enorm hilfreich und vereinfacht den Integrationsprozess enorm. Daher habe ich das VMware Container Networking with Antrea Bundle von der Version 1.8.0 heruntergeladen und das antreansxctl CLI Tool daraus extrahiert. - heading:

Download der Konfigurationsdateien (YAML)

body: | Das entsprechende VMware Container Networking with Antrea Bundle kann über das [VMware Customer Connect Portal](https://customerconnect.vmware.com/downloads/info/slug/networking_security/vmware_antrea/1_x) 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. - heading:

Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration

body: | Sobald das Zip File vorhanden ist, kann man es entpacken: ```bash # 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 Images 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: ```bash # 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 ``` > **Achtung:** Im **interworking.yaml** File des VMware Container Networking with Antrea 1.7.0 Bundles wurde die Pod Security Annotation für den **vmware-system-antrea** Namespace nicht angepasst. Dadurch kommt es zu diversen Warnungen und der Register-Job kann nicht erfolgreich ausgeführt werden. Als Workaround in der Version 1.7.0 kann man folgende Ergänzungen im interworking.yaml File vornehmen: ```yaml --- 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: ```bash 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: ```bash 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 > Es ist wichtig, dass zuerst das bootstrap-config.yaml und anschliessend das interworking.yaml File angewendet wird. Anschliessend kann das Deployment via kubectl ausgeführt werden: ```bash 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: ```bash 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: ![antrea-nsx-interworking](/blog-assets/antrea-nsx-integration/01.webp) 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.status: corpus: 267 alsoLike: - {ref: posts/vsphere-with-tanzu-und-nsx-advanced-load-balancer-avi-secret-not-found, score: 1.00} - {ref: posts/lessons-learned-vsphere-with-tanzu-und-nsx-advanced-load-balancer-integration-mit-private-ca, score: 1.00} - {ref: solutions/vmware/vmware-cloud-foundation/addon/advanced-security, score: 0.75}
{ "apiVersion": "soultec.ch/v1", "kind": "Post", "metadata": { "name": "antrea-nsx-integration", "locale": "de", "labels": { "author": "matthias-grasmueck", "series": "how-to", "capability/network": "2.16", "capability/security": "2.16", "capability/containers": "2.39", "vendor/vmware": "0.88" }, "annotations": { "source": "blog-content/posts/de/antrea-nsx-integration.md", "route": "/de/insights/antrea-nsx-integration/", "schema": "/nerd/schema/posts.json", "markdown": "/de/insights/antrea-nsx-integration.md" } }, "spec": { "title": "Antrea Integration in NSX", "date": "2024-04-16", "author": "matthias-grasmueck", "locale": "de", "summary": "Ich durfte bereits für diverse Projekte VMware NSX als SDN und/oder Security Lösung implementieren.", "capabilities": [ "network", "security", "containers" ], "vendors": [ "vmware" ], "series": "how-to", "hero": "/blog-assets/antrea-nsx-integration/hero.webp", "legacySlug": "antrea-nsx-integration", "migrated": "2026-08-24", "draft": false }, "sections": [ { "body": "Ich durfte bereits für diverse Projekte [VMware NSX](https://www.vmware.com/products/nsx.html) 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](https://www.vmware.com/products/vsphere/vsphere-with-tanzu.html) Projekten ist das NCP, wie aber auch das Antrea CNI, eminent vertreten.\n\nDa 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.\n\nDie **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:\n\n- Anzeigen von Antrea K8s (Pods, Namespaces, Services etc.) Ressourcen im NSX UI.\n- Zentrale Verwaltung von Gruppen und Security Policies im NSX UI, welche auf effektive K8s Ressourcen verweisen.\n- Erweiterung der Trace Flow Funktionalität für Pod/CNI Datenflüsse für zentrales Monitoring und Analyse.\n- Integration von K8s Cluster, wo Antrea als primäres oder sekundäres CNI genutzt wird.\n\nDie Integration eines K8s Cluster mit Antrea in das NSX CCP/MP ist denkbar einfach und umfasst folgende Schritte:\n\n1. Vorbereitung\n 1. Ermitteln der aktuellen Antrea OSS Version\n 2. Download der Konfigurationsdateien (YAML)\n 3. Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration\n2. Deployment des NSX Interworking Adapters\n\n# Vorbereitung\n\n> Die nachfolgenden Beispiele wurden auf einem vSphere with Tanzu (vSphere 8.0 Update 2) Cluster durchgeführt. Dabei wurde ein Tanzu Kubernetes (Guest) Cluster mit dem Tanzu Kubernetes Release (TKR) 1.26.13 basierend auf dem PhotonOS verwendet." }, { "heading": "

Ermitteln der aktuellen Antrea OSS Version

",
"body": "Als erstes muss die aktuell eingesetzte Open Source Software (OSS) Version vom Antrea CNI auf dem Kubernetes Ziel-Cluster ermittelt werden. Hierzu gibt es zwei gängige Optionen:\n\n**Option: vSphere with Tanzu**\n\nHierzu muss man in den Context des vSphere Namespace wechseln, in welchem sich der Tanzu Kubernetes Cluster (TKC) befindet.\n\n```yaml\n \n# Change into respective vSphere Namespace where TKC is located\nkubectl config use-context VSPHERE_NAMESPACE\n\n# Check the assocaited Antrea package of the respective TKC\nkubectl get antreaconfigs.cni.tanzu.vmware.com CLUSTER_NAME-antrea-package \\\n--output yaml | grep antrea.tanzu.vmware.com\n\n# Sample output from an antrea-package\napiVersion: cni.tanzu.vmware.com/v1alpha1\nkind: AntreaConfig\n metadata:\n labels:\n tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.11.3---vmware.2-tkg.2-advanced\n```\n\n**Option: K8s Cluster lokal**\n\nAuf dem lokalen Kubernetes Cluster (in meinem Fall der TKC) kann man sich via [kubectl exec](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) Command in den Antrea Controller Pod einwählen und den [antctl](https://antrea.io/docs/main/docs/antctl/) Command ausführen.\n\n```yaml\nkubectl -n kube-system exec antrea-controller-8589557c86-wprxn --stdin --tty -- antctl version\nantctlVersion: v1.11.3-79e45ea\ncontrollerVersion: v1.11.3-79e45ea\n```\n\nNach 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:\n\n| VMware Container Networking Version | Based on Antrea OSS Version | Compatible With Antrea-NSX Interworking Version |\n| --- | --- | --- |\n| 1.9.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.9.0/rn/vmware-container-networking-with-antrea-190-release-notes/index.html)) | 1.15.0 | 0.15.0\\_vmware.1 |\n| 1.8.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.8.0/rn/vmware-container-networking-with-antrea-180-release-notes/index.html)) | 1.13.1 | 0.13.0\\_vmware.1 |\n| 1.7.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html)) | 1.11.1 | 0.11.0 |\n\nIn 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html) mit der Antrea Interworking Image Version **0.11.2\\_vmware.1** kompatibel ist:\n\nAntrea-NSX images:\n\n- projects.registry.vmware.com/antreainterworking/interworking-debian:[0.11.0, 0.11.1, 0.11.2\\_vmware.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-debian/artifacts-tab?publicAndNotLogged=yes)\n- projects.registry.vmware.com/antreainterworking/interworking-ubuntu:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubuntu/artifacts-tab?publicAndNotLogged=yes)\n- projects.registry.vmware.com/antreainterworking/interworking-photon:[0.11.0, 0.11.1, 0.11.2\\_vmware.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-photon/artifacts-tab?publicAndNotLogged=yes)\n- projects.registry.vmware.com/antreainterworking/interworking-ubi:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubi/artifacts-tab?publicAndNotLogged=yes)\n\n> Mit der VMware Container Networking with Antrea Version 1.7.0 wurde das [**antreansxctl**](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.x/vmware_antrea_install/GUID-DF0C6F11-9877-4849-8F3E-CC3F824126C0.html?hWord=N4IghgNiBc4HYBcBOBTMcDOAPAxgqAvkA) CLI Tool eingeführt. Das Tool wird ständig weiterentwickelt und neue Funktionen/Optimierungen werden im jeweils nächsten VMware Container Networking with Antrea Release mitgeliefert. In der VMware Container Networking with Antrea Version 1.7.0 ist das Tool noch eingeschränkt nutzbar und besitzt bspw. noch keine **bootstrap** Option. Dieser Optionsparameter ist jedoch enorm hilfreich und vereinfacht den Integrationsprozess enorm. Daher habe ich das VMware Container Networking with Antrea Bundle von der Version 1.8.0 heruntergeladen und das antreansxctl CLI Tool daraus extrahiert." }, { "heading": "

Download der Konfigurationsdateien (YAML)

",
"body": "Das entsprechende VMware Container Networking with Antrea Bundle kann über das [VMware Customer Connect Portal](https://customerconnect.vmware.com/downloads/info/slug/networking_security/vmware_antrea/1_x) bezogen werden.\n\nEs 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**\n\nDas Zip File sollte wie folgt benannt sein: **antrea-interworking-<VERSION>.zip**\n\nWie 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." }, { "heading": "

Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration

",
"body": "Sobald das Zip File vorhanden ist, kann man es entpacken:\n\n```bash\n# Extract the antrea-networking ZIP file\nunzip antrea-interworking-0.11.0.zip\nArchive: antrea-interworking-0.11.0.zip\ncreating: antrea-interworking-0.11.0/\ncreating: antrea-interworking-0.11.0/bin/\ninflating: antrea-interworking-0.11.0/bin/antreansxctl.tar.gz\ninflating: antrea-interworking-0.11.0/bootstrap-config.yaml\ninflating: antrea-interworking-0.11.0/deregisterjob.yaml\ninflating: antrea-interworking-0.11.0/interworking-debian-0.11.0.tar\ninflating: antrea-interworking-0.11.0/interworking.yaml\ninflating: antrea-interworking-0.11.0/inventorycleanup.yaml\ninflating: antrea-interworking-0.11.0/ns-label-webhook.yaml\n\n# Extract the antreansxctl CLI tool from the GZ file\ntar -xzf antrea-interworking-0.11.0/bin/antreansxctl.tar.gz\n\n# Move the antreansxctl binary to the local bin store to make it available for runtime execution\nsudo mv antreansxctl /usr/local/bin\n```\n\nNach 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 Images von der offiziellen VMware Registry herunter:\n\n```\nprojects.registry.vmware.com/antreainterworking/interworking-debian:VERSION\nprojects.registry.vmware.com/antreainterworking/interworking-ubuntu:VERSION\nprojects.registry.vmware.com/antreainterworking/interworking-photon:VERSION\nprojects.registry.vmware.com/antreainterworking/interworking-ubi:VERSION\n```\n\nDa 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:\n\n```bash\n \n# 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\nsed -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\n```\n\n> **Achtung:** Im **interworking.yaml** File des VMware Container Networking with Antrea 1.7.0 Bundles wurde die Pod Security Annotation für den **vmware-system-antrea** Namespace nicht angepasst. Dadurch kommt es zu diversen Warnungen und der Register-Job kann nicht erfolgreich ausgeführt werden.\n\nAls Workaround in der Version 1.7.0 kann man folgende Ergänzungen im interworking.yaml File vornehmen:\n\n```yaml\n---\napiVersion: v1\nkind: Namespace\nmetadata:\n name: vmware-system-antrea\n labels:\n app: antrea-interworking\n openshift.io/run-level: '0'\n pod-security.kubernetes.io/enforce: privileged\n pod-security.kubernetes.io/enforce-version: latest\n pod-security.kubernetes.io/audit: privileged\n pod-security.kubernetes.io/audit-version: latest\n pod-security.kubernetes.io/warn: privileged\n pod-security.kubernetes.io/warn-version: latest\n---\n```\n\nAlternativ kann man auch ca. 10 Minuten warten, bis der kapp-controller eingreift und den Namespace mit den entsprechenden Annotations ergänzt.\n\nMit 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:\n\n```bash\nantreansxctl bootstrap --cluster-name shared-tkc01 --nsx-managers 10.24.0.50 --user admin --password 'VMware1!VMware1!'\nbootstrap.go:51] \"bootStrap\" User=\"admin\" ClusterName=\"shared-tkc01\"\ncluster.go:260] Configure NSX client for manager IP 10.24.0.50\ncluster.go:119] Selected endpoint index: 0, ip: 10.24.0.50\nbootstrap.go:97] \"Checking PrincipalIdentities in NSX\" clusterName=\"shared-tkc01\" Result=false\nbootstrap.go:113] \"Creating self signed cert\" clusterName=\"shared-tkc01\"\nbootstrap.go:187] \"Creating PrincipalIdentities in NSX\" clusterName=\"shared-tkc01\" vpc=\"\"\nbootstrap.go:205] \"vpc argument is empty, creating enterprise admin PI\"\nbootstrap.go:225] \"Creating principal identity\" ClusterName=\"shared-tkc01\"\nbootstrap.go:233] \"Created principal identity\" user=\"shared-tkc01\" vpc=\"\" key=\"shared-tkc01.key\" cert=\"shared-tkc01.crt\" PrincipalIdentity={[...]}\nbootstrap.go:235] \"role: enterprise_admin on /\"\nbootstrap.go:275] \"Creating bootstrap Configmap and Secret yaml file\" clusterName=\"shared-tkc01\" nsxManagers=[\"10.24.0.50\"] vpc=\"\"\nbootstrap.go:278] \"Created bootstrap Configmap and Secret yaml file\" bootstrapYamlFile=\"shared-tkc01-bootstrap-config.yaml\"\n```\n\nAnschliessend sollten folgende Files erstellt worden sein:\n\n- shared-tkc01-bootstrap-config.yaml\n- shared-tkc01.crt\n- shared-tkc01.key\n\nMittels NSX API Call lässt sich rasch verifizieren, ob der PI User angelegt wurde:\n\n```bash\ncurl -k -u 'admin:VMware1!VMware1!' \\\n--request GET 'https://10.24.0.50/api/v1/trust-management/principal-identities/' | grep -i '\"name\" : \"shared-tkc01\"' -A 22 -B 1\n[…]\n\"results\" : [ {\n\"name\" : \"shared-tkc01\",\n\"node_id\" : \"shared-tkc01\",\n\"role\" : \"enterprise_admin\",\n\"certificate_id\" : \"0041f40a-4f52-4718-947d-3c57f7f98806\",\n\"roles_for_paths\" : [ {\n\"path\" : \"/\",\n\"roles\" : [ {\n\"role\" : \"enterprise_admin\"\n} ],\n\"delete_path\" : false\n} ],\n\"is_protected\" : true,\n\"resource_type\" : \"PrincipalIdentity\",\n\"id\" : \"03b51c9f-8bda-419d-8a26-9740895e82db\",\n\"display_name\" : \"shared-tkc01@shared-tkc01\",\n\"_create_time\" : 1713260925476,\n\"_create_user\" : \"admin\",\n\"_last_modified_time\" : 1713260925476,\n\"_last_modified_user\" : \"admin\",\n\"_system_owned\" : false,\n\"_protection\" : \"NOT_PROTECTED\",\n\"_revision\" : 0\n}, {\n```\n\n# Deployment des NSX Interworking Adapters\n\nFolgende Files werden für die Installation benötigt:\n\n- shared-tkc01-bootstrap-config.yaml\n- antrea-interworking-0.11.0/interworking.yaml\n\n> Es ist wichtig, dass zuerst das bootstrap-config.yaml und anschliessend das interworking.yaml File angewendet wird.\n\nAnschliessend kann das Deployment via kubectl ausgeführt werden:\n\n```bash\nkubectl apply -f shared-tkc01-bootstrap-config.yaml -f antrea-interworking-0.11.0/interworking.yaml\nnamespace/vmware-system-antrea created\nconfigmap/bootstrap-config created\nsecret/nsx-cert created\ncustomresourcedefinition.apiextensions.k8s.io/antreaccpadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com created\ncustomresourcedefinition.apiextensions.k8s.io/antreampadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com created\nnamespace/vmware-system-antrea configured\nconfigmap/cluster-id created\nconfigmap/antrea-interworking-config created\nserviceaccount/register created\nrole.rbac.authorization.k8s.io/register created\nrolebinding.rbac.authorization.k8s.io/register created\nrole.rbac.authorization.k8s.io/vmware-system-antrea-register created\nrolebinding.rbac.authorization.k8s.io/vmware-system-antrea-register created\nserviceaccount/interworking created\nclusterrole.rbac.authorization.k8s.io/antrea-interworking created\nclusterrolebinding.rbac.authorization.k8s.io/antrea-interworking created\nclusterrole.rbac.authorization.k8s.io/antrea-interworking-supportbundle created\nclusterrolebinding.rbac.authorization.k8s.io/antrea-interworking-supportbundle created\njob.batch/register created\ndeployment.apps/interworking created\n```\n\nBei erfolgreichem Deployment sollte der neue Namespace **vmware-system-antrea** angelegt worden sein und den Interworking Pod beherbergen:\n\n```bash\nkubectl -n vmware-system-antrea get all\nNAME READY STATUS RESTARTS AGE\npod/interworking-579ff578f7-ng48n 4/4 Running 0 45s\npod/register-v5qrg 0/1 Completed 0 46s\n\nNAME READY UP-TO-DATE AVAILABLE AGE\ndeployment.apps/interworking 1/1 1 1 46s\n\nNAME DESIRED CURRENT READY AGE\nreplicaset.apps/interworking-579ff578f7 1 1 1 45s\n\nNAME COMPLETIONS DURATION AGE\njob.batch/register 1/1 7s 46s\n```\n\nAnschliessend kann man über das NSX UI den Status der Integration verifizieren:\n\n![antrea-nsx-interworking](/blog-assets/antrea-nsx-integration/01.webp)\n\nAb 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." } ], "status": { "corpus": 267, "alsoLike": [ { "ref": "posts/vsphere-with-tanzu-und-nsx-advanced-load-balancer-avi-secret-not-found", "score": "1.00" }, { "ref": "posts/lessons-learned-vsphere-with-tanzu-und-nsx-advanced-load-balancer-integration-mit-private-ca", "score": "1.00" }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/advanced-security", "score": "0.75" } ] }}
apiVersion = "soultec.ch/v1"kind = "Post"[metadata]name = "antrea-nsx-integration"locale = "de"[metadata.labels]author = "matthias-grasmueck"series = "how-to""capability/network" = "2.16""capability/security" = "2.16""capability/containers" = "2.39""vendor/vmware" = "0.88"[metadata.annotations]source = "blog-content/posts/de/antrea-nsx-integration.md"route = "/de/insights/antrea-nsx-integration/"schema = "/nerd/schema/posts.json"markdown = "/de/insights/antrea-nsx-integration.md"[spec]title = "Antrea Integration in NSX"date = 2024-04-16author = "matthias-grasmueck"locale = "de"summary = "Ich durfte bereits für diverse Projekte VMware NSX als SDN und/oder Security Lösung implementieren."capabilities = ["network", "security", "containers"]vendors = ["vmware"]series = "how-to"hero = "/blog-assets/antrea-nsx-integration/hero.webp"legacySlug = "antrea-nsx-integration"migrated = 2026-08-24draft = false[[sections]]body = '''Ich durfte bereits für diverse Projekte [VMware NSX](https://www.vmware.com/products/nsx.html) 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](https://www.vmware.com/products/vsphere/vsphere-with-tanzu.html) 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 Konfiguration2. Deployment des NSX Interworking Adapters# Vorbereitung> Die nachfolgenden Beispiele wurden auf einem vSphere with Tanzu (vSphere 8.0 Update 2) Cluster durchgeführt. Dabei wurde ein Tanzu Kubernetes (Guest) Cluster mit dem Tanzu Kubernetes Release (TKR) 1.26.13 basierend auf dem PhotonOS verwendet.'''[[sections]]heading = "

Ermitteln der aktuellen Antrea OSS Version

"
body = '''Als erstes muss die aktuell eingesetzte Open Source Software (OSS) Version vom Antrea CNI auf dem Kubernetes Ziel-Cluster ermittelt werden. Hierzu gibt es zwei 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.```yaml # Change into respective vSphere Namespace where TKC is locatedkubectl config use-context VSPHERE_NAMESPACE# Check the assocaited Antrea package of the respective TKCkubectl get antreaconfigs.cni.tanzu.vmware.com CLUSTER_NAME-antrea-package \--output yaml | grep antrea.tanzu.vmware.com# Sample output from an antrea-packageapiVersion: cni.tanzu.vmware.com/v1alpha1kind: 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](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) Command in den Antrea Controller Pod einwählen und den [antctl](https://antrea.io/docs/main/docs/antctl/) Command ausführen.```yamlkubectl -n kube-system exec antrea-controller-8589557c86-wprxn --stdin --tty -- antctl versionantctlVersion: v1.11.3-79e45eacontrollerVersion: 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.9.0/rn/vmware-container-networking-with-antrea-190-release-notes/index.html)) | 1.15.0 | 0.15.0\_vmware.1 || 1.8.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.8.0/rn/vmware-container-networking-with-antrea-180-release-notes/index.html)) | 1.13.1 | 0.13.0\_vmware.1 || 1.7.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html)) | 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html) 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](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-debian/artifacts-tab?publicAndNotLogged=yes)- projects.registry.vmware.com/antreainterworking/interworking-ubuntu:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubuntu/artifacts-tab?publicAndNotLogged=yes)- projects.registry.vmware.com/antreainterworking/interworking-photon:[0.11.0, 0.11.1, 0.11.2\_vmware.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-photon/artifacts-tab?publicAndNotLogged=yes)- projects.registry.vmware.com/antreainterworking/interworking-ubi:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubi/artifacts-tab?publicAndNotLogged=yes)> Mit der VMware Container Networking with Antrea Version 1.7.0 wurde das [**antreansxctl**](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.x/vmware_antrea_install/GUID-DF0C6F11-9877-4849-8F3E-CC3F824126C0.html?hWord=N4IghgNiBc4HYBcBOBTMcDOAPAxgqAvkA) CLI Tool eingeführt. Das Tool wird ständig weiterentwickelt und neue Funktionen/Optimierungen werden im jeweils nächsten VMware Container Networking with Antrea Release mitgeliefert. In der VMware Container Networking with Antrea Version 1.7.0 ist das Tool noch eingeschränkt nutzbar und besitzt bspw. noch keine **bootstrap** Option. Dieser Optionsparameter ist jedoch enorm hilfreich und vereinfacht den Integrationsprozess enorm. Daher habe ich das VMware Container Networking with Antrea Bundle von der Version 1.8.0 heruntergeladen und das antreansxctl CLI Tool daraus extrahiert.'''[[sections]]heading = "

Download der Konfigurationsdateien (YAML)

"
body = '''Das entsprechende VMware Container Networking with Antrea Bundle kann über das [VMware Customer Connect Portal](https://customerconnect.vmware.com/downloads/info/slug/networking_security/vmware_antrea/1_x) 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.'''[[sections]]heading = "

Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration

"
body = '''Sobald das Zip File vorhanden ist, kann man es entpacken:```bash# Extract the antrea-networking ZIP fileunzip antrea-interworking-0.11.0.zipArchive: antrea-interworking-0.11.0.zipcreating: antrea-interworking-0.11.0/creating: antrea-interworking-0.11.0/bin/inflating: antrea-interworking-0.11.0/bin/antreansxctl.tar.gzinflating: antrea-interworking-0.11.0/bootstrap-config.yamlinflating: antrea-interworking-0.11.0/deregisterjob.yamlinflating: antrea-interworking-0.11.0/interworking-debian-0.11.0.tarinflating: antrea-interworking-0.11.0/interworking.yamlinflating: antrea-interworking-0.11.0/inventorycleanup.yamlinflating: antrea-interworking-0.11.0/ns-label-webhook.yaml# Extract the antreansxctl CLI tool from the GZ filetar -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 executionsudo 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 Images von der offiziellen VMware Registry herunter:```projects.registry.vmware.com/antreainterworking/interworking-debian:VERSIONprojects.registry.vmware.com/antreainterworking/interworking-ubuntu:VERSIONprojects.registry.vmware.com/antreainterworking/interworking-photon:VERSIONprojects.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:```bash # 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.yamlsed -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```> **Achtung:** Im **interworking.yaml** File des VMware Container Networking with Antrea 1.7.0 Bundles wurde die Pod Security Annotation für den **vmware-system-antrea** Namespace nicht angepasst. Dadurch kommt es zu diversen Warnungen und der Register-Job kann nicht erfolgreich ausgeführt werden.Als Workaround in der Version 1.7.0 kann man folgende Ergänzungen im interworking.yaml File vornehmen:```yaml---apiVersion: v1kind: Namespacemetadata: 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:```bashantreansxctl 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.50cluster.go:119] Selected endpoint index: 0, ip: 10.24.0.50bootstrap.go:97] "Checking PrincipalIdentities in NSX" clusterName="shared-tkc01" Result=falsebootstrap.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.keyMittels NSX API Call lässt sich rasch verifizieren, ob der PI User angelegt wurde:```bashcurl -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 AdaptersFolgende Files werden für die Installation benötigt:- shared-tkc01-bootstrap-config.yaml- antrea-interworking-0.11.0/interworking.yaml> Es ist wichtig, dass zuerst das bootstrap-config.yaml und anschliessend das interworking.yaml File angewendet wird.Anschliessend kann das Deployment via kubectl ausgeführt werden:```bashkubectl apply -f shared-tkc01-bootstrap-config.yaml -f antrea-interworking-0.11.0/interworking.yamlnamespace/vmware-system-antrea createdconfigmap/bootstrap-config createdsecret/nsx-cert createdcustomresourcedefinition.apiextensions.k8s.io/antreaccpadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com createdcustomresourcedefinition.apiextensions.k8s.io/antreampadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com creatednamespace/vmware-system-antrea configuredconfigmap/cluster-id createdconfigmap/antrea-interworking-config createdserviceaccount/register createdrole.rbac.authorization.k8s.io/register createdrolebinding.rbac.authorization.k8s.io/register createdrole.rbac.authorization.k8s.io/vmware-system-antrea-register createdrolebinding.rbac.authorization.k8s.io/vmware-system-antrea-register createdserviceaccount/interworking createdclusterrole.rbac.authorization.k8s.io/antrea-interworking createdclusterrolebinding.rbac.authorization.k8s.io/antrea-interworking createdclusterrole.rbac.authorization.k8s.io/antrea-interworking-supportbundle createdclusterrolebinding.rbac.authorization.k8s.io/antrea-interworking-supportbundle createdjob.batch/register createddeployment.apps/interworking created```Bei erfolgreichem Deployment sollte der neue Namespace **vmware-system-antrea** angelegt worden sein und den Interworking Pod beherbergen:```bashkubectl -n vmware-system-antrea get allNAME READY STATUS RESTARTS AGEpod/interworking-579ff578f7-ng48n 4/4 Running 0 45spod/register-v5qrg 0/1 Completed 0 46sNAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/interworking 1/1 1 1 46sNAME DESIRED CURRENT READY AGEreplicaset.apps/interworking-579ff578f7 1 1 1 45sNAME COMPLETIONS DURATION AGEjob.batch/register 1/1 7s 46s```Anschliessend kann man über das NSX UI den Status der Integration verifizieren:![antrea-nsx-interworking](/blog-assets/antrea-nsx-integration/01.webp)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.'''[status]corpus = 267[[status.alsoLike]]ref = "posts/vsphere-with-tanzu-und-nsx-advanced-load-balancer-avi-secret-not-found"score = "1.00"[[status.alsoLike]]ref = "posts/lessons-learned-vsphere-with-tanzu-und-nsx-advanced-load-balancer-integration-mit-private-ca"score = "1.00"[[status.alsoLike]]ref = "solutions/vmware/vmware-cloud-foundation/addon/advanced-security"score = "0.75"
<?xml version="1.0" encoding="UTF-8"?><manifest kind="Post"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>antrea-nsx-integration</name> <locale>de</locale> <labels> <author>matthias-grasmueck</author> <series>how-to</series> <entry key="capability/network">2.16</entry> <entry key="capability/security">2.16</entry> <entry key="capability/containers">2.39</entry> <entry key="vendor/vmware">0.88</entry> </labels> <annotations> <source>blog-content/posts/de/antrea-nsx-integration.md</source> <route>/de/insights/antrea-nsx-integration/</route> <schema>/nerd/schema/posts.json</schema> <markdown>/de/insights/antrea-nsx-integration.md</markdown> </annotations> </metadata> <spec> <title>Antrea Integration in NSX</title> <date>2024-04-16</date> <author>matthias-grasmueck</author> <locale>de</locale> <summary>Ich durfte bereits für diverse Projekte VMware NSX als SDN und/oder Security Lösung implementieren.</summary> <capabilities> <item>network</item> <item>security</item> <item>containers</item> </capabilities> <vendors> <item>vmware</item> </vendors> <series>how-to</series> <hero>/blog-assets/antrea-nsx-integration/hero.webp</hero> <legacySlug>antrea-nsx-integration</legacySlug> <migrated>2026-08-24</migrated> <draft>false</draft> </spec> <sections> <section> <body>Ich durfte bereits für diverse Projekte [VMware NSX](https://www.vmware.com/products/nsx.html) 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](https://www.vmware.com/products/vsphere/vsphere-with-tanzu.html) 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 Konfiguration2. Deployment des NSX Interworking Adapters# Vorbereitung&gt; Die nachfolgenden Beispiele wurden auf einem vSphere with Tanzu (vSphere 8.0 Update 2) Cluster durchgeführt. Dabei wurde ein Tanzu Kubernetes (Guest) Cluster mit dem Tanzu Kubernetes Release (TKR) 1.26.13 basierend auf dem PhotonOS verwendet. </body> </section> <section> <heading>

Ermitteln der aktuellen Antrea OSS Version

</heading>
<body>Als erstes muss die aktuell eingesetzte Open Source Software (OSS) Version vom Antrea CNI auf dem Kubernetes Ziel-Cluster ermittelt werden. Hierzu gibt es zwei 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.```yaml # Change into respective vSphere Namespace where TKC is locatedkubectl config use-context VSPHERE_NAMESPACE# Check the assocaited Antrea package of the respective TKCkubectl get antreaconfigs.cni.tanzu.vmware.com CLUSTER_NAME-antrea-package \--output yaml | grep antrea.tanzu.vmware.com# Sample output from an antrea-packageapiVersion: cni.tanzu.vmware.com/v1alpha1kind: 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](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) Command in den Antrea Controller Pod einwählen und den [antctl](https://antrea.io/docs/main/docs/antctl/) Command ausführen.```yamlkubectl -n kube-system exec antrea-controller-8589557c86-wprxn --stdin --tty -- antctl versionantctlVersion: v1.11.3-79e45eacontrollerVersion: 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.9.0/rn/vmware-container-networking-with-antrea-190-release-notes/index.html)) | 1.15.0 | 0.15.0\_vmware.1 || 1.8.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.8.0/rn/vmware-container-networking-with-antrea-180-release-notes/index.html)) | 1.13.1 | 0.13.0\_vmware.1 || 1.7.0 ([Release Notes](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html)) | 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](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.7.0/rn/vmware-container-networking-with-antrea-170-release-notes/index.html) 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](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-debian/artifacts-tab?publicAndNotLogged=yes)- projects.registry.vmware.com/antreainterworking/interworking-ubuntu:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubuntu/artifacts-tab?publicAndNotLogged=yes)- projects.registry.vmware.com/antreainterworking/interworking-photon:[0.11.0, 0.11.1, 0.11.2\_vmware.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-photon/artifacts-tab?publicAndNotLogged=yes)- projects.registry.vmware.com/antreainterworking/interworking-ubi:[0.11.0, 0.11.1](https://projects.registry.vmware.com/harbor/projects/16052/repositories/interworking-ubi/artifacts-tab?publicAndNotLogged=yes)&gt; Mit der VMware Container Networking with Antrea Version 1.7.0 wurde das [**antreansxctl**](https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.x/vmware_antrea_install/GUID-DF0C6F11-9877-4849-8F3E-CC3F824126C0.html?hWord=N4IghgNiBc4HYBcBOBTMcDOAPAxgqAvkA) CLI Tool eingeführt. Das Tool wird ständig weiterentwickelt und neue Funktionen/Optimierungen werden im jeweils nächsten VMware Container Networking with Antrea Release mitgeliefert. In der VMware Container Networking with Antrea Version 1.7.0 ist das Tool noch eingeschränkt nutzbar und besitzt bspw. noch keine **bootstrap** Option. Dieser Optionsparameter ist jedoch enorm hilfreich und vereinfacht den Integrationsprozess enorm. Daher habe ich das VMware Container Networking with Antrea Bundle von der Version 1.8.0 heruntergeladen und das antreansxctl CLI Tool daraus extrahiert. </body> </section> <section> <heading>

Download der Konfigurationsdateien (YAML)

</heading>
<body>Das entsprechende VMware Container Networking with Antrea Bundle kann über das [VMware Customer Connect Portal](https://customerconnect.vmware.com/downloads/info/slug/networking_security/vmware_antrea/1_x) 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-&lt;VERSION&gt;.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. </body> </section> <section> <heading>

Anpassen der Konfigurationsdateien und Generieren der Bootstrap Konfiguration

</heading>
<body>Sobald das Zip File vorhanden ist, kann man es entpacken:```bash# Extract the antrea-networking ZIP fileunzip antrea-interworking-0.11.0.zipArchive: antrea-interworking-0.11.0.zipcreating: antrea-interworking-0.11.0/creating: antrea-interworking-0.11.0/bin/inflating: antrea-interworking-0.11.0/bin/antreansxctl.tar.gzinflating: antrea-interworking-0.11.0/bootstrap-config.yamlinflating: antrea-interworking-0.11.0/deregisterjob.yamlinflating: antrea-interworking-0.11.0/interworking-debian-0.11.0.tarinflating: antrea-interworking-0.11.0/interworking.yamlinflating: antrea-interworking-0.11.0/inventorycleanup.yamlinflating: antrea-interworking-0.11.0/ns-label-webhook.yaml# Extract the antreansxctl CLI tool from the GZ filetar -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 executionsudo 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 Images von der offiziellen VMware Registry herunter:```projects.registry.vmware.com/antreainterworking/interworking-debian:VERSIONprojects.registry.vmware.com/antreainterworking/interworking-ubuntu:VERSIONprojects.registry.vmware.com/antreainterworking/interworking-photon:VERSIONprojects.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:```bash # 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.yamlsed -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```&gt; **Achtung:** Im **interworking.yaml** File des VMware Container Networking with Antrea 1.7.0 Bundles wurde die Pod Security Annotation für den **vmware-system-antrea** Namespace nicht angepasst. Dadurch kommt es zu diversen Warnungen und der Register-Job kann nicht erfolgreich ausgeführt werden.Als Workaround in der Version 1.7.0 kann man folgende Ergänzungen im interworking.yaml File vornehmen:```yaml---apiVersion: v1kind: Namespacemetadata: 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:```bashantreansxctl 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.50cluster.go:119] Selected endpoint index: 0, ip: 10.24.0.50bootstrap.go:97] "Checking PrincipalIdentities in NSX" clusterName="shared-tkc01" Result=falsebootstrap.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.keyMittels NSX API Call lässt sich rasch verifizieren, ob der PI User angelegt wurde:```bashcurl -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 AdaptersFolgende Files werden für die Installation benötigt:- shared-tkc01-bootstrap-config.yaml- antrea-interworking-0.11.0/interworking.yaml&gt; Es ist wichtig, dass zuerst das bootstrap-config.yaml und anschliessend das interworking.yaml File angewendet wird.Anschliessend kann das Deployment via kubectl ausgeführt werden:```bashkubectl apply -f shared-tkc01-bootstrap-config.yaml -f antrea-interworking-0.11.0/interworking.yamlnamespace/vmware-system-antrea createdconfigmap/bootstrap-config createdsecret/nsx-cert createdcustomresourcedefinition.apiextensions.k8s.io/antreaccpadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com createdcustomresourcedefinition.apiextensions.k8s.io/antreampadapterinfos.clusterinformation.antrea-interworking.tanzu.vmware.com creatednamespace/vmware-system-antrea configuredconfigmap/cluster-id createdconfigmap/antrea-interworking-config createdserviceaccount/register createdrole.rbac.authorization.k8s.io/register createdrolebinding.rbac.authorization.k8s.io/register createdrole.rbac.authorization.k8s.io/vmware-system-antrea-register createdrolebinding.rbac.authorization.k8s.io/vmware-system-antrea-register createdserviceaccount/interworking createdclusterrole.rbac.authorization.k8s.io/antrea-interworking createdclusterrolebinding.rbac.authorization.k8s.io/antrea-interworking createdclusterrole.rbac.authorization.k8s.io/antrea-interworking-supportbundle createdclusterrolebinding.rbac.authorization.k8s.io/antrea-interworking-supportbundle createdjob.batch/register createddeployment.apps/interworking created```Bei erfolgreichem Deployment sollte der neue Namespace **vmware-system-antrea** angelegt worden sein und den Interworking Pod beherbergen:```bashkubectl -n vmware-system-antrea get allNAME READY STATUS RESTARTS AGEpod/interworking-579ff578f7-ng48n 4/4 Running 0 45spod/register-v5qrg 0/1 Completed 0 46sNAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/interworking 1/1 1 1 46sNAME DESIRED CURRENT READY AGEreplicaset.apps/interworking-579ff578f7 1 1 1 45sNAME COMPLETIONS DURATION AGEjob.batch/register 1/1 7s 46s```Anschliessend kann man über das NSX UI den Status der Integration verifizieren:![antrea-nsx-interworking](/blog-assets/antrea-nsx-integration/01.webp)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. </body> </section> </sections> <status> <corpus>267</corpus> <alsoLike> <item> <ref>posts/vsphere-with-tanzu-und-nsx-advanced-load-balancer-avi-secret-not-found</ref> <score>1.00</score> </item> <item> <ref>posts/lessons-learned-vsphere-with-tanzu-und-nsx-advanced-load-balancer-integration-mit-private-ca</ref> <score>1.00</score> </item> <item> <ref>solutions/vmware/vmware-cloud-foundation/addon/advanced-security</ref> <score>0.75</score> </item> </alsoLike> </status></manifest>
How-To · 2024-04-16

Antrea Integration in NSX

Ich durfte bereits für diverse Projekte VMware NSX als SDN und/oder Security Lösung implementieren.

2024-04-16Datum
Matthias GrasmückAutor
7Min. Lesezeit
Themen Netzwerk 2.16 Security 2.16 Container 2.39
Hersteller VMware 0.88

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

Die nachfolgenden Beispiele wurden auf einem vSphere with Tanzu (vSphere 8.0 Update 2) Cluster durchgeführt. Dabei wurde ein Tanzu Kubernetes (Guest) Cluster mit dem Tanzu Kubernetes Release (TKR) 1.26.13 basierend auf dem PhotonOS verwendet.

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 zwei 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 VersionBased on Antrea OSS VersionCompatible With Antrea-NSX Interworking Version
1.9.0 (Release Notes)1.15.00.15.0_vmware.1
1.8.0 (Release Notes)1.13.10.13.0_vmware.1
1.7.0 (Release Notes)1.11.10.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:

Mit der VMware Container Networking with Antrea Version 1.7.0 wurde das antreansxctl CLI Tool eingeführt. Das Tool wird ständig weiterentwickelt und neue Funktionen/Optimierungen werden im jeweils nächsten VMware Container Networking with Antrea Release mitgeliefert. In der VMware Container Networking with Antrea Version 1.7.0 ist das Tool noch eingeschränkt nutzbar und besitzt bspw. noch keine bootstrap Option. Dieser Optionsparameter ist jedoch enorm hilfreich und vereinfacht den Integrationsprozess enorm. Daher habe ich das VMware Container Networking with Antrea Bundle von der Version 1.8.0 heruntergeladen und das antreansxctl CLI Tool daraus extrahiert.

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-.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 Images 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

Achtung: Im interworking.yaml File des VMware Container Networking with Antrea 1.7.0 Bundles wurde die Pod Security Annotation für den vmware-system-antrea Namespace nicht angepasst. Dadurch kommt es zu diversen Warnungen und der Register-Job kann nicht erfolgreich ausgeführt werden.

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

Es ist wichtig, dass zuerst das bootstrap-config.yaml und anschliessend das interworking.yaml File angewendet wird.

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:

antrea-nsx-interworking

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.

Passt ausserdem