03. VMware Cluster API

VMware Cluster API

LTFUT on ~~Heptio~~ VMware Cluster API.

Cluster API

What is it?

A brief history

Why use it?

ClusterAPI fits into the 3rd category of the Tanzu product line, Cloud Infrastructure

FRAGMENTS.

What is it?

Cluster API is a Kubernetes sub-project focussed on providing declarative APIs and tooling to simplify the management of Kubernetes clusters at scale.
- Includes both;
  - Day 1 Operations (The initial provisioning of clusters)
  - Day 2 Operations (Upgrading and operating of clusters)
A better name might have been Cluster Framework

History.

Originally created by Heptio in 2017 and later donated to the Cluster Lifecycle SIG in 2018.
The upstream Kubernetes development is broken down in to SIGs or Special Interest Groups in an effort to focus development.
VMware acquired Heptio in December 2018
VMware integrated Cluster API into vSphere 7 as part of Project Pacific which went to general availability in early 2020.

Why use it?

Cluster API allows for a consistent API surface across supported Cloud Providers.
Including all the major cloud players and the list of supported providers is growing rapidly.
NOTE: For comparison, in 2018 when I first created this presentation they only had AWS and GCP, now there is over 20 supported providers.

References

Architecture

So onto the architecture.

Show diagram in a new window.

..Terminology..

Starting from the bottom;

Cloud Provider: The underlying cloud provider like AWS, GCP, Digital Ocean or vSphere.
Infrastructure Provider: An SDK to abstract a source of resources such as compute and networking.
- Each vendor supports and maintains their own provider.
- For example;
  - AWS has CAP-A
  - Azure has CAP-Z
  - VMware has CAP-V
- Cluster API abstracts individual cloud providers allowing you to use the same code to interact across clouds.
- Each cloud provider can then place their own specific customisations within the infrastructure provider codebase.
Management Cluster: As the name suggests, this is a cluster that’s used to manage clusters. Each workload cluster is represented as an API object within the management cluster giving you a single point of control.
Workload Cluster: Another descriptive name, as this is a cluster that’s used to run application workloads.
Bootstrap Provider:
- Automates the initial setup.
- Generates cluster certificates
- Initializes the control plane and creation of worker nodes (the instances which run the actual workloads)
- Joins the control plane and worker nodes to the cluster
Workflow
- Bootstrap Process
- Management Cluster
- Workload Cluster

References.

Cluster API Book

Example

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: MetalCluster
metadata:
    name: talos
    namespace: my-cluster
spec:
    apiEndpoints:
        - host: 10.254.0.5
          port: 64436

Scenario

The world’s most critical application.

Scenario.

Before we get to the demo, let’s play out a fictional scenario to get some context about the problem we’re solving.
Let’s say were working for a Managed Services Provider.
A customer has come to us with a problem.
- Their critical application, named ‘The Sock Shop’ has been experiencing a lot of downtime and they need a solution.
- Currently, they are all in with one cloud provider but they would like to go multi-cloud, and we need to get them up and running quickly.
- It’s mission critical that people need to be able to purchase their socks for the upcoming winter season.
- This customer only has a small development team working on the application.
- They want to outsource the platform engineering work so they can focus on their mission to keep people’s feet warm.
The MSP also has a small SRE team and want to keep the code as DRY as possible, re-using as much as possible between customers and cloud environments to avoid re-work.
If you haven’t heard of this app, the ‘Sock Shop’ is a microservices demo, or a hello-world of kubernetes and was created by Weaveworks circa 2017 for demonstration purposes.

References.

The Sock Shop

Kubernetes

Secure Ingress

Metrics and Logging

Policy

Backups

Warming those cold feet.

Automation first

Code Promotion

Keep code DRY

Modular and Extensible

Efficient use of resources

Minimal vendors

Scenario

After a series of workshops with the customer, a set of guiding principles for the project was defined.

FRAGMENTS.

Automation first: Delivered with GitOps.
Promotion of changes: Promote code changes through environments, tested and re-tested at each stage.
Keep code DRY: when possible across Cloud Providers. (Stands for don’t repeat yourself)
A modular and extensible platform:
- Technology moves fast.
- The platform should have modular and swappable components to keep the platform ’evergreen’ and adaptable over time.
Efficient use of resources
- Freeing engineers from the burden of TOIL with a higher focus on new capability and feature development.
Minimal vendors
- less throats to choke when help is needed.
- Avoid the vendor blame game where you might have support cases bouncing between vendors until resolution.
  - I added this one to the scenario recently during this update.
  - Unfortunately back in 2018, it required a myriad of separate open source projects to get this done.
  - Fast-forward to now however, it’s possible to have a single vendor in VMware that provides 95% of the entire stack.

Demo

VMware Cluster API

Cluster API

Architecture

Example

Scenario

Demo

Questions