Dissecting a Tanzu Kubernetes Cluster Spec with the TKG Service for vSphere

June 30, 2020 Kendrick Coleman

This post is part of a series that  examines some of the fundamentals of creating, utilizing, and managing Tanzu Kubernetes clusters with the Tanzu Kubernetes Grid (TKG) Service for vSphere. If you need a primer to understand the basic concepts, make sure you read vSphere 7 — Introduction to Tanzu Kubernetes Grid Clusters. And if you haven’t already, this would also be a good time to read An Elevated View of the Tanzu Kubernetes Grid Service Architecture, the first post in the series.

In this post, we will focus on deploying a TKG Service cluster using a simple, customized specification. This yaml spec will be an object of kind TanzuKubernetesCluster. The spec that is used is an adaptation of what’s available in the public VMware documentation.

Let’s go through the steps line by line:

apiVersion: run.tanzu.vmware.com/v1alpha1

kind: TanzuKubernetesCluster

metadata:

  name: tkg-demo-cluster-01

  namespace: demo-tkg-ns

spec:

  distribution:

    version: v1.17.4+vmware.1-tkg.1.057f6be    #The full image name is specified

  topology:

    controlPlane:

      count: 1                                 #1 control plane nodes

      class: guaranteed-xsmall                 #extra small size VM

      storageClass: demo-tkg-storagepolicy     #Specific storage class for control plane

    workers:

      count: 3                                 #3 worker nodes

      class: best-effort-xsmall                #extra small size VM

      storageClass: demo-tkg-storagepolicy     #Specific storage class for workers

  settings:

    network:

      cni:

        name: calico

      services:

        cidrBlocks: ["198.51.100.0/12"]        #Cannot overlap with Supervisor Cluster

      pods:

        cidrBlocks: ["192.0.2.0/16"]           #Cannot overlap with Supervisor Cluster

    storage:

      classes: ["demo-tkg-storagepolicy"]      #Named PVC storage classes

      defaultClass: demo-tkg-storagepolicy     #Default PVC storage class

In the metadata section, the name is what the Tanzu Kubernetes cluster will be called when it’s deployed, and will be recognized in the vCenter UI. Another required step  is specifying the vSphere namespace where this TKG cluster will be provisioned.

Within the spec, the version is a direct mapping of what’s available in the subscribed content catalog. This version correlates to a template with a Kubernetes version as well.

The topology is where the ability for customization comes into play. A Kubernetes topology consists of at least one Kubernetes control plane image that runs all the Kubernetes services (such as the API server and control loops), with one or more Kubernetes workers that are responsible for running the workloads. In each section, there is a count, which is analogous to a replica count in Kubernetes denoting the number of each kind. For a TKG cluster, these are represented as virtual machines (VMs).

The class for each type has a few different variations. The first denotes guaranteed vs. best effort. If a machine class has the guaranteed label, vSphere reservations for CPU and memory are set for the VM. Best effort, on the other hand, will not have any reservations. There are also pre-defined VM sizes available that determine the amount of vCPU and RAM;  they range from extra small to extra large. The VM classes can be retrieved using the kubectl command as well. For this example, to keep resources light, the extra-small variant will be utilized.

Next is defining the storage class to be applied to the VMs  for datastore placement. The storage class maps to a storage policy that is defined in the vSphere namespace.

The sections that cover advanced settings are completely optional. The network settings define the type of CNI. For this deployment, Calico will be the default CNI. The services and pod CIDrs are taken from the documentation and have not been adjusted. As seen above, these IP ranges cannot overlap with the Supervisor Cluster.

The storage section defines the storage policies that will be assigned as storage classes to the Tanzu Kubernetes cluster. Multiple storage policies can be added in a comma-separated array. At the same time, the default storage class can be specified for any persistent volume claim created inside the Tanzu Kubernetes cluster.

Now the TanzuKubernetesCluster object can be applied to the Supervisor Cluster using kubectl. Once the cluster has been deployed, it will be available as part of the inventory using `kubectl get tanzukubernetesclusters`.

The cluster can be accessed directly by authenticating with kubectl vSphere using the namespace and cluster flags. This step adds the token to the KUBECONFIG file, where the context can be used for the cluster. After setting the context to the Tanzu Kubernetes cluster, it will function just like a normal Kubernetes cluster.

For a complete step-by-step of the process, be sure to watch this video:

Stay tuned to catch the next blog post and video in the series. For more information in the meantime, check out the Tanzu Kubernetes Grid site

About the Author

Kendrick Coleman is a reformed sysadmin and virtualization junkie. His attention has shifted from hypervisors to cloud-native platforms focused on containers. In his role as an Open Source Technical Product Manager, he figures out new and interesting ways to run open source cloud native infrastructure tools with VMware products. He's involved with the Kubernetes SIG community and frequently blogs about all the things he's learning. He has been a speaker at DockerCon, OpenSource Summit, ContainerCon, CloudNativeCon, and many more. His free time is spent sharing bourbon industry knowledge hosting the Bourbon Pursuit Podcast.

More Content by Kendrick Coleman
Previous
Simply Scaling a Tanzu Kubernetes Cluster with the TKG Service for vSphere
Simply Scaling a Tanzu Kubernetes Cluster with the TKG Service for vSphere

Learn how to take a Tanzu Kubernetes cluster and scale it on demand.

Next
Auto-Configured Application Topology and In-Context Logs at Your Service
Auto-Configured Application Topology and In-Context Logs at Your Service

VMware Tanzu Observability by Wavefront (Tanzu Observability) has added application maps to its distribute...