vSphere with Tanzu und NSX Advanced Load Balancer – avi-secret not found
Ich bin kürzlich über ein interessantes Verhalten bei einem Funktionstest einer VMware vSphere with Tanzu Container Runtime Plattform in Kombination mit dem VMware NSX Advanced Load Balancer
Ich bin kürzlich über ein interessantes Verhalten bei einem Funktionstest einer VMware vSphere with Tanzu Container Runtime Plattform in Kombination mit dem VMware NSX Advanced Load Balancer gestolpert. Ich persönlich finde Funktionstests immer spannend, da man aus erster Hand erfahren kann, wie die eigenen Systeme unter erschwerten Bedingungen funktioniere bzw. ab wann sie den Dienst quittieren.
Die Plattform basierte dabei auf vSphere with Tanzu (vSphere 8.0 Update 2), NSX Data Center (4.1.2.1) und NSX (Avi) Advanced Load Balancer (22.1.5). Sämtliche Komponenten wurden in einem integrierten Setup bereitgestellt. Das heisst, dass sämtliche Schnittstellen automatisiert angesteuert werden, was eine echte Cloud-like Experience für Developer und Plattform-Administratoren bietet.
Dabei dient NSX Data Center in erster Linie der Netzwerk- und Security-Automatisierung (bspw. Antrea CNI Integration in NSX) und NSX Advanced Load Balancer der automatisierten Bereitstellung von L4 Load Balancer Services (kann um L7 Ingress Integration erweitert werden). Diesen Grad der Automatisierung erreicht man sprichwörtlich mit der Initialen «Out-of-the-Box» Bereitstellung der vSphere with Tanzu Container Plattform.
Das Problem
Als ich alle drei NSX ALB Controller ausgeschaltet (power-off) habe, um ein Desaster-Szenario zu simulieren, hat sich alles so verhalten, wie erwartet. Die Überraschung kam erst nach der erfolgreichen Wiederherstellung des NSX ALB Control Planes zum Vorschein.
Als ich ein Deployment mit einem Service vom Typen LoadBalancer bereitstellen wollte, stellte ich fest, dass ich keine externe IP-Adresse vom NSX ALB Controller erhalte:
kubectl get svc -n ft-nsx-alb
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ft-nsx-alb service/kubernetes LoadBalancer 10.96.0.10 <pending> 443/TCP 1d
ft-nsx-alb service/supervisor LoadBalancer 10.96.0.134 <pending> 80/TCP 1dIm NSX ALB Control Plane konnte ich keine Indizien zu diesem Verhalten finden, da einfach nichts protokolliert wurde und dieser Umstand liefert mir wiederum einen Verdacht, woraufhin ich den zuständigen Service auf dem Supervisor Cluster überprüfte.
Der Avi Kubernetes Operator (AKO) Service ist dabei für die Kommunikation des Supervisor Cluster mit dem NSX ALB Controller Cluster zuständig und genau dieser Service befand sich nicht im ordnungsgemässen Running Zustand:
kubectl get pods -A | grep -v Running
NAMESPACE NAME READY STATUS RESTARTS AGE
vmware-system-ako vmware-system-ako-ako-controller-manager-65d78d698d-c944k 1/2 CrashLoopBackOff 1465 (2m24s ago) 49dDaraufhin habe ich sämtliche Ressourcen im vmware-system-ako Namespace überprüft:
kubectl -n vmware-system-ako get all
NAME READY STATUS RESTARTS AGE
pod/vmware-system-ako-ako-controller-manager-65d78d698d-c944k 1/2 CrashLoopBackOff 1465 (4m17s ago) 49d
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/vmware-system-ako-ako-controller-manager 0/1 1 0 49d
NAME DESIRED CURRENT READY AGE
replicaset.apps/vmware-system-ako-ako-controller-manager-65d78d698d 1 1 0 49dEin kubectl describe auf den fehlerhaften Pod lieferte folgendes Indiz:
kubectl -n vmware-system-ako describe pod vmware-system-ako-ako-controller-manager-65d78d698d-c944k
[...]
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning BackOff 3m14s (x33529 over 5d10h) kubelet Back-off restarting failed container manager in pod vmware-system-ako-ako-controller-manager-65d78d698d-c944k_vmware-system-ako(e629cb54-f4fe-409f-8ac4-f2b0ac58b506)In den entsprechenden Logs konnte man dann das effektive Problem ausmachen:
kubectl -n vmware-system-ako logs vmware-system-ako-ako-controller-manager-65d78d698d-c944k infra | more
2024-02-02T09:16:01.591Z INFO infra-main/main.go:49 AKO-Infra is running with version: ob-21883866-460f000-7e6ff10
2024-02-02T09:16:01.591Z INFO infra-main/main.go:55 We are running inside kubernetes cluster. Won't use kubeconfig files.
2024-02-02T09:16:01.594Z INFO infra-main/main.go:76 Successfully created kube client for ako-infra
2024-02-02T09:16:01.594Z INFO utils/utils.go:173 Initializing configmap informer in vmware-system-ako
2024-02-02T09:16:01.675Z INFO lib/dynamic_client.go:134 Skipped initializing dynamic informers for cniPlugin
2024-02-02T09:16:01.682Z INFO ingestion/vcf_k8s_controller.go:346 Got data from ConfigMap {"advancedL4":"true","cloudName":"/infra/sites/default/enforcement-points/default/transport-zones/overlay-tz","clusterID":"domain-c[...]","controllerIP":"[...]","credentialsSecretName":"avi-secret","credentialsSecretNamespace":"vmware-system-ako","logLevel":"WARN","serverURL":"https://[...]"}
2024-02-02T09:16:01.682Z INFO ingestion/vcf_k8s_controller.go:427 TransportZone to use for AKO is set to /infra/sites/default/enforcement-points/default/transport-zones/overlay-tz
E0202 09:16:20.192221 1 avisession.go:668] Client error for URI: login. Error: Post "https://[...]/login": dial tcp [...]:443: connect: no route to host
E0202 09:16:20.193030 1 avisession.go:714] CheckControllerStatus is disabled for this session, not going to retry.
E0202 09:16:20.193046 1 avisession.go:716] Failed to invoke API. Error: Post "https://[...]/login": dial tcp [...]:443: connect: no route to host
E0202 09:16:20.193123 1 avisession.go:383] response error: Rest request error, returning to caller: Post " https://[...]/login": dial tcp [...]:443: connect: no route to host
2024-02-02T09:16:20.193Z ERROR ingestion/vcf_k8s_controller.go:381 Failed to connect to AVI controller using secret provided by NCP, the secret would be deleted, err: Rest request error, returning to caller: Post "https://[...]/login": dial tcp [...]:443: connect: no route to host
2024-02-02T09:16:20.201Z INFO ingestion/vcf_k8s_controller.go:210 ConfigMap Add
2024-02-02T09:16:20.204Z INFO ingestion/vcf_k8s_controller.go:346 Got data from ConfigMap {"advancedL4":"true","cloudName":"/infra/sites/default/enforcement-points/default/transport-zones/overlay-tz","clusterID":"domain-c[...]","controllerIP":"[...]","credentialsSecretName":"avi-secret","credentialsSecretNamespace":"vmware-system-ako","logLevel":"WARN","serverURL":"https://[...]"}
2024-02-02T09:16:20.206Z WARN ingestion/vcf_k8s_controller.go:361 Failed to get Secret, got err: secrets "avi-secret" not found
2024-02-02T09:16:20.206Z INFO ingestion/vcf_k8s_controller.go:210 ConfigMap Add
2024-02-02T09:16:20.208Z INFO ingestion/vcf_k8s_controller.go:346 Got data from ConfigMap
[...]Die Zeile […]Failed to connect to AVI controller using secret provided by NCP, the secret would be deleted[…] lieferte dabei den ausschlaggebenden Punkt.
Die Lösung
Somit schien für die Generierung des fehlenden Secrets der NSX Container Plugin (NCP)-Service zuständig zu sein, woraufhin ich diesen neustartete, um den Secret-Regenerierungsprozess anzustossen:
kubectl -n vmware-system-nsx get pods
NAME READY STATUS RESTARTS AGE
nsx-ncp-5f4f7d6597-7rstp 2/2 Running 0 49d
nsx-ncp-5f4f7d6597-ppl7w 2/2 Running 0 49d
kubectl -n vmware-system-nsx delete pod nsx-ncp-5f4f7d6597-7rstp
kubectl -n vmware-system-nsx delete pod nsx-ncp-5f4f7d6597-ppl7wNachdem die NCP Pods neu generiert wurden, erschien ein avi-init-secret, welches wiederum einen Reboot des AKO Services auslöste. Kurz danach erschien dann auch das erhoffte avi-secret Objekt:
kubectl -n vmware-system-ako get secrets
NAME TYPE DATA AGE
avi-init-secret Opaque 3 26h
avi-secret Opaque 3 26hEine kurze Verifizierung meines Deployments zeigte, dass nun wieder LoadBalancer VIP IP-Adressen vom NSX ALB Controller zugewiesen wurden:
kubectl get svc -n ft-nsx-alb
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ft-nsx-alb service/kubernetes LoadBalancer 10.96.0.10 172.16.22.31 443/TCP 1d
ft-nsx-alb service/supervisor LoadBalancer 10.96.0.134 172.16.22.32 80/TCP 1dTL;DR
Nach einem Totalausfall des NSX ALB Controller Cluster kann ggf. ein Neustart der NCP Pods wahre Wunder bewirken.
