1. Steps To Create Kubernetes Cluster on HI GIO Portal

Overview

This document explains creating a Kubernetes cluster on HI GIO, including selecting configurations, deploying nodes, and initializing the control plane.

Procedure

Create a network for the cluster with available Static IP Pools.
Create firewall and SNAT rules to ensure VMs in the cluster can access the internet.
Make sure HI GIO Load Balancing is enabled.
Make sure there is at least one available public IP.

Step 1: Log in to the HI GIO portal with tenant account > Click More > Kubernetes Container Clusters

Step 2: Click NEW and follow the creation steps to complete the creation process to create a new HI GIO Kubernetes cluster.

Click NEXT
Enter the name of the cluster and select a Kubernetes version > NEXT.

Click NEXT in step 3.

Attaching clusters to Tanzu Mission Control is currently not supported.

Select oVDC and Network for nodes > NEXT.

In the Control Plane window, select the number of nodes and disk size, and optionally select a sizing policy, a placement policy, and a storage profile, and click NEXT.

Configuration field

Description

Number of Nodes

Non-HA: 1
HA: 3

Disk Size (GB)

The minimum allowed is 20 GB

Sizing Policy

TKG medium: If the number of Worker nodes is less than or equal to 10 nodes.
TKG large: If the number of Worker nodes exceeds 10 nodes.

Placement Policy

Leave blank. We do not apply a placement policy for the HI GIO Kubernetes cluster.

Storage Policy

Select an available storage policy.

Configure worker pools setting > NEXT

Configuration field

Description

Name

Enter the worker pool name.

Number of Nodes

Enter the number of nodes of the worker pool.

Disk Size (GB)

The minimum allowed is 20 GB

Sizing Policy

TKG small: Small VM sizing policy for a Kubernetes cluster node (2 CPU, 4GB memory)
TKG medium: Medium VM sizing policy for a Kubernetes cluster node (2 CPU, 8GB memory)
TKG large: Large VM sizing policy for a Kubernetes cluster node (4 CPU, 16GB memory)
TKG extra-large: Extra-large VM sizing policy for a Kubernetes cluster node (8 CPU, 32GB memory)

Placement Policy

Leave blank. We do not apply a placement policy for HI GIO Kubernetes cluster.

Storage Policy

Select an available storage policy.

(Optional) To create additional worker node pools, click Add New Worker Node Pool and configure worker node pool settings.

Configure storage class > NEXT

Configuration field

Description

Select a Storage Profile

Select one of the available storage profiles.

Storage Class Name

The name of the default Kubernetes storage class. This field can be any user-specified name with the following constraints based on Kubernetes requirements:

Contain a maximum of 63 characters
Contain only lowercase alphanumeric characters or hyphens
Start with an alphabetic character
End with an alphanumeric character

Reclaim Policy

Delete policy: This policy deletes the PersistentVolume object when the PersistentVolumeClaim is deleted.
Retain policy: This policy does not delete the volume when the PersistentVolumeClaim is deleted; the volume can be reclaimed manually.

Filesystem

xfs
ext4: This is the default filesystem used for the storage class.

Configure Kubernetes network > 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.

Services CIDR

Specifies a range of IP addresses to use for Kubernetes services. The default value is 100.64.0.0/13.

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 different from the routed IP range.

Virtual IP Subnet

You can specify a subnet CIDR from which one unused IP address is assigned as a Control Plane Endpoint. The subnet must represent a set of addresses in the gateway. The same CIDR is also propagated as the subnet CIDR for the ingress services on the cluster.

You should enter the available public IP into the Control Plane IP

Enable Auto Repair on Errors and Node Health Check > NEXT

Auto Repair on Errors: If errors occur before this cluster becomes available, the CSE Server will automatically attempt to repair the cluster.

Node Health Check: Unhealthy nodes will be remediated after this cluster becomes available according to unhealthy node conditions and remediation rules.