vRealize Automation 8.x – Change Internal Kubernetes IP Range

vRealize Automation (vRA) 8.2 added support for changing the IP address range used by the internal Kubernetes cluster, which is great news as many organisation already use the 10.244.0.0/21 address space. Unfortunately if your network already uses the ranges 10.244.0.0/22 or 10.244.4.0/22, you will likely encounter issues, such a provisioning timeouts.

To resolve this issue in vRA 8.2, run the below commands to view your current configuration, and to update to a new range.

View your Current Configuration

View your current configuration by running the command below. Two /22 subnets are shown, the cluster CIDR and the service CIDR.

1vracli network k8s-subnets

Set your New Configuration

To update the internal Kubernetes IP ranges, run the below command substituting the 192.168.0.0/22 and 192.168.4.0/22 subnets with your own.

1vracli network k8s-subnets --cluster-cidr 192.168.0.0/22 --service-cidr 192.168.4.0/22

Once it is reconfigured, redeploy the application by running the 'clean' command

1/opt/scripts/deploy.sh --onlyClean

Followed by the 'deploy' command

1/opt/scripts/deploy.sh

Reset to Original Configuration

To reset the internal Kubernetes IP ranges back to the default subnets, run the below command

1vracli network k8s-subnets --cluster-cidr 10.244.0.0/22 --service-cidr 10.244.4.0/22

Once it is reconfigured, redeploy the application by running the 'clean' command

1/opt/scripts/deploy.sh --onlyClean

Followed by the 'deploy' command

1/opt/scripts/deploy.sh

Known Issue

There is a bug in vRealize Automation 8.2 which causes the vRA appliance to not deploy / start-up properly, when the Kubernetes internal IP address space is changed to use the 192.168.0.0/16 address space. This post resolves the issue, while VMware develops a patch to resolve the issue permanently.