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.
|
1 |
vracli 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.
|
1 |
vracli 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
|
1 |
vracli 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.