In the previous post in this series, I discussed the CSE configuration options that a service provider can use to provide Kubernetes-as-a-service to their tenants. In this post, I’ll go over how tenants can use the Container Service Extension plugin for Kubernetes cluster deployment in a self-service manner.
If you haven’t read the previous posts in this series, you can do so by clicking on the links provided below.
1: CSE Introduction & Architecture
2: NSX Advanced Load Balancer Configuration & VCD Integration
3: Container Service Extension Configuration by Service Provider
Log in to the tenant’s org to deploy a Kubernetes cluster. The user should be assigned the “Kubernetes Cluster Author” role. To begin with the cluster creation wizard, navigate to Home > More > Kubernetes Container Clusters and click the New button.
Select the Kubernetes runtime for the cluster. CSE 4.0 only supports Tanzu Kubernetes Grid runtime.
Choose the Kubernetes version and give the Kubernetes cluster a name. CSE 4.0 currently only supports TKGm 1.5.4.
Choose the Virtual datacenter in which the Kubernetes cluster will be deployed, as well as the network to which the cluster will be connected. This network should have outbound internet connectivity.
Select the number of worker nodes, disc size, and optionally, sizing and storage policies in the Control Plane window, then click Next.
Enter a name, number of nodes, disc size, and optionally a sizing policy, placement policy, and storage policy for the worker nodes.
In the Kubernetes Storage window, activate the Create Default Storage Class toggle, select a storage profile, and enter a storage class name. Optionally you can configure Reclaim Policy and Filesystem settings.
In the Kubernetes Network window, specify a range of IP addresses for Kubernetes services and a range for Kubernetes pods, and click Next.
| Option | Description |
| Pods CIDR | Specifies a range of IP addresses to use for Kubernetes pods. The default value is 100.96.0.0/11. The pod subnet size must be equal to or larger than /24. You can enter one IP range. |
| Services CIDR | Specifies a range of IP addresses to use for Kubernetes services. The default value is 100.64.0.0/13. You can enter one IP range. |
| Control Plane IP | You can specify your own IP address as the control plane endpoint. You can use an external IP from the gateway or an internal IP from a subnet that is different from the routed IP range. If you do not specify an IP as the control plane endpoint, the CSE server selects one of the unused IP addresses from the associated tenant gateway. |
| Virtual IP Subnet | You can specify a subnet CIDR from which one unused IP address is assigned as Control Plane Endpoint. The subnet must represent a set of addresses that are present in the gateway. The same CIDR is also propagated as the subnet CIDR for the ingress services on the cluster. |
Toggle the Auto Repair on Errors toggle in the Debug Settings window on or off.
When this toggle is turned on, the CSE server attempts to recreate the clusters that are in an error state. When this toggle is deactivated, the CSE server leaves the cluster in an error state for manual troubleshooting.
Click on the Finish button to complete the Cluster deployment wizard.
Depending on the network speed and compute capacity available in your infrastructure, cluster creation takes about 20-30 minutes.
You can view cluster details by clicking on them.
In the backend, a Virtual Service will be created in NSX ALB with pool members as the Kubernetes cluster’s three control planes.
To see more information about the Load Balancer objects created during cluster deployment, navigate to the Load Balancer section by clicking on the Edge Gateway associated with the network configured in the Kubernetes cluster.
Pool Status
Virtual Service
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.