vSphere Supervisor cluster deployment hangs in "Configuring" state with error "Timed out waiting for LB service update" due to untrusted Avi Controller certificate

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

When attempting to enable Workload Management or deploy a new vSphere Supervisor cluster backed by the NSX Advanced Load Balancer (Avi), the deployment stalls in a Configuring state.

• The vCenter Server Recent Tasks pane or the Workload Management UI displays the following timeout event:

  "Configured Load Balancer fronting the kubernetes API Server. Timed out waiting for LB service update. This operation is part of the cluster enablement and will be retried."

• Inspecting the Avi Kubernetes Operator (AKO) pod logs (kubectl logs -n vmware-system-ako <ako-pod-name>) within the Supervisor control plane reveals repeated TLS validation and x509 unknown authority errors:

  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 
  Client error for URI: login. Error: Post "https://##.##.##.##/login": tls: failed to verify certificate: x509: certificate signed by unknown authority 
  CheckControllerStatus is disabled for this session, not going to retry.
  Failed to invoke API. Error: Post "https://##.##.##.##/login": tls: failed to verify certificate: x509: certificate signed by unknown authority response error: Rest request error, returning to caller
  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
  WARN    ingestion/vcf_k8s_controller.go:361    Failed to get Secret, got err: secrets "avi-secret" not found

Environment

VMware vSphere Kubernetes Service 

NSX Advanced Load Balancer (Avi Controller) 

Cause

This issue occurs when the NSX Advanced Load Balancer (Avi Controller) is utilizing a portal certificate issued by an internal or non-well-known Certificate Authority (CA), and the full certificate trust chain has not been supplied to the infrastructure.

Because the underlying Kubernetes components in the Supervisor cluster do not have the corresponding Root/Intermediate CA chain to explicitly trust this portal certificate, the API connection requests are securely rejected. This TLS rejection prevents the AKO pod from retrieving the avi-init-secret / avi-secret from the Avi Controller. Without these credentials, AKO cannot provision the required Load Balancer VIPs to front the Kubernetes API Server, permanently halting the cluster enablement process.

Resolution

To resolve this issue, you must establish explicit trust by updating the certificate chain within the infrastructure, allowing the AKO pod to successfully validate the Avi Controller's portal certificate.

     1. Obtain the full certificate chain (Root CA and any Intermediate CAs) that signed the Avi Controller's portal certificate.

     2. Apply the remediation and certificate injection steps outlined in Broadcom KB 385435: How to update Certificate Chain in NSX-T.

     3. Once the certificate chain is properly propagated, navigate back to the vSphere Client and initiate a fresh redeployment of the Workload Management Supervisor cluster.