VKS Machine Rollout Stuck in Provisioned Phase Due to Missing NoProxy Configuration

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

• During a Cluster API or Tanzu machine rollout, node provisioning stops or becomes permanently stuck in the Provisioned phase. 
• The cluster displays the following status alert: NodeHealthy: Waiting for a Node with spec.providerID vsphere://... to exist
• Node describe reveals a TLS handshake timeout when attempting to connect to the Control Plane API Server at <kube-apiserver_IP>:6443

Environment

vSphere Kubernetes Service

Cause

Internal management traffic destined for the Control Plane API Server is incorrectly routed through the external corporate proxy infrastructure because the API Server IP address is omitted from the noProxy configuration array.

Resolution

Modify the cluster deployment configuration to bypass the proxy for internal traffic using one of the two validated approaches below:

Method 1: Complete Removal of the System Proxy Block

Use this method if the nodes do not require a global corporate proxy to pull images from registries or communicate with external networks.

1. Open the cluster configuration file (example: cluster.yaml).

2. Delete or comment out the entire systemProxy definition block:

   # systemProxy:
#   http: http://<REDACTED_HOSTNAME_1>:9480
#   https: http://<REDACTED_HOSTNAME_1>:9480
#   noProxy:
#     ...

3. Apply the modified configuration to the management plane: kubectl apply -f cluster.yaml

Method 2: Explicitly Patch the NoProxy List

Use this method if the corporate proxy configuration must be retained for outbound internet or external network access.

1. Open the cluster configuration file (example: cluster.yaml).

2. Navigate to the systemProxy block and add the Control Plane API Server IP address (kube-apiserver_IP) directly to the noProxy list items:
   
     systemProxy:
    http: http://<REDACTED_HOSTNAME_1>:9480
    https: http://<REDACTED_HOSTNAME_1>:9480
    noProxy:
      - <REDACTED_IP_1>
      - <REDACTED_CIDR_1> 

3. Apply the updated configuration manifest to the cluster: kubectl apply -f cluster.yaml