Tanzu Supervisor Lifecycle

Einer der Vorteile, die Tanzu bietet, ist ein automatisches Lifecycle der Plattform. Hierfür wird regelmässig eine neue Version des vCenters veröffentlich. Gestern Abend war es wieder soweit. Hier die das What´s new:

What’s New?

Supervisor Cluster

• Management of VMs using Kubernetes via the Virtual Machine Service: This release adds the Virtual Machine Service to the infrastructure services included in vSphere with Tanzu, delivering Kubernetes native VM management for developers. VM Service enables developers to deploy and manage VMs in a vSphere namespace in a self-service model using Kubernetes commands.  At the same time, the IT admin is able to govern resource consumption and availability of the service, while still providing developers with a cloud-native experience. 
• Self-service creation of Namespaces for Developers: IT admins can now create and configure a Supervisor Namespace as a self-service namespace template.  This template defines resource limits and permissions for usage. Developers can then use this template to provision a namespace and run workloads within it, without having to explicitly request one and wait for approval. 

Tanzu Kubernetes Grid Service for vSphere

• Kubernetes metrics-server enabled by default: The Kubernetes metrics-server is an aggregator of cluster usage data that will now be enabled in all Tanzu Kubernetes clusters. Users can now view current Node and Pod consumption using `kubectl top`.
• System mutating webhooks now support dry-run mode: Users can now integrate popular tools like the Terraform Kubernetes provider with Tanzu Kubernetes Grid Service.  Previously the system webhooks did not support dry-run mode, which was a requirement for the Terraform `plan` command.
• Custom VM Classes: Tanzu Kubernetes Clusters can consume the custom Virtual Machine Classes through VM Service. This will allow users to configure different amounts of CPU and Memory allocated to the Virtual Machines that make up a Tanzu Kubernetes Cluster

Nun steht man da. Hat den vCenter via VAMI aktualisiert und hat neue Funktionen bei Tanzu zur Verfügung.

Auch wenn die Änderungen umfangreich sind, so ist es wichtig, dass man weiss, dass nun durch die Einführung der VM Klassen ein zusätzlicher Schritt bei der Erstellung eines Namespace notwendig wird.

Erstellt man den Namespace wie bisher und will dann ein Cluster ausrollen erhält man eine Fehlermeldung:

sgmelin@localpc clusterdef % k apply -f tanzu-cluster-01.yaml Error from server (could not find spec.topology.controlPlane.class "best-effort-xsmall", could not find spec.topology.workers.class "best-effort-small"): error when creating "tanzu-cluster-01.yaml": admission webhook "default.validating.tanzukubernetescluster.run.tanzu.vmware.com" denied the request: could not find spec.topology.controlPlane.class "best-effort-xsmall", could not find spec.topology.workers.class "best-effort-small"

Wenn wir die Meldung durchlesen wird klar, was fehlt. Zunächst schauen wir uns das einfache YAML File an:

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
 name: cluster-01
spec:
 topology:
   controlPlane:
     count: 1
     class: best-effort-xsmall
     storageClass: r1-3stripes
   workers:
     count: 3
     class: best-effort-small
     storageClass: r1-3stripes
 distribution:
  version: v1.18.5

Wie man sieht, ein ganz einfaches Cluster mit einer ControlPlane Node und drei Worker Nodes. Die ControlPlane basiert auf dem Image best-effort-xsmall und die Workers auf best-effort-small.

Neu in ist nun, dass man im Namespace definieren muss, welche VM Klassen dem Entwickler zur Verfügung stehen. Standardmässig ist keine Klasse aktiv. Daher muss im Namespace nun die VM Klasse mitgegeben werden. Vergisst man dies, erhält man die o.g. Fehlermeldung:

Also geben wir die erlaubten VM Klassen an:

Und schon funktioniert der Rollout:

sgmelin@localpc clusterdef % k apply -f tanzu-cluster-01.yaml
tanzukubernetescluster.run.tanzu.vmware.com/cluster-01 created

Nun, wir waren eigentlich beim Lifecycle stehen geblieben.

Fangen wir beim Supervisor Cluster an:

Wenn wir nun das Update starten, wird mittels eine Rolling Updates der Supervisor Cluster aktualisiert. Wir sehen hier nun, dass ein vierter Node ausgerollt wird:

Dieser vierte Node ersetzt den ersten in der Liste, danach wird dieser gelöscht und ein weiterer ausgerollt, bis alle Supervisor Nodes aktualisiert sind.

Nun wird auch klar, wieso man bei erstellen des Supervisor Clusters vier aufeinander folgende IP Adressen benötigt, obwohl nur drei Knoten ausgerollt werden. Hier ein Blick in die Tasks Konsole: