#clusterapi

ClusterAPI Demystified #CAPI #k8s

Deploying Kubernetes clusters may be the biggest hurdle in learning Kubernetes and one of the challenges in managing Kubernetes. ClusterAPI is a project designed to ease this burden and make the management and deployment of Kubernetes clusters simpler.

The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. It…

ClusterAPI for vSphere, now with CNS support

Introduction

If you want to about the basics and key concepts of ClusterAPI, then check out my post on the Alpha back in June here – it covers the high level concepts and troubleshooting of ClusterAPI, as well as what it offers to you as a user who wants to set up Kubernetes.

This blog is a look at what has changed and how you can use ClusterAPI to deploy K8s clusters on vSphere that use CNS and…

The cat is out of the bag. Google Cloud Services platform got rebranded yesterday to the much more suitable name of Anthos. If you happen to read my previous blog post on Kubernetes Cluster API you can put the two together to realize that these are indeed related. Google Anthos is an umbrella of services. I’ve worked with the GKE On-Prem piece the last few weeks and I’m stunned by the level of complexity Google have managed to abstract away and let end users focus on their own business outcomes than try figure out how to build and maintain production worthy Kubernetes clusters. You snap your fingers and you have a Kubernetes cluster, in your private cloud, Google’s cloud or someone else’s cloud. That is the power of the Kubernetes Cluster API. Yesterday your Kubernetes cluster was your pet. Now comes the difficult time to say your last goodbye.

Thanks to Vic Iglesias tweet yesterday (please follow for an immense amount of insights, especially around release engineering and CI/CD) I managed to filter the signal from the noise. This is the most beautiful representation of the GKE On-Prem component under Anthos you’ll find in its current form. Anthos Overview

At the flick of a kubeconfig you can deploy an application to any Kubernetes cluster in the world, there’s nothing new or especially fancy about that. The value in my mind Anthos brings, is a sense of multicloud managed Kubernetes as Anthos will ultimately be able to deploy anything to anywhere including the destination cluster itself. You want to test a new app? Click home a new cluster and have at it. Burn it to the ground 5 minutes later. Reproducible Kubernetes clusters – on-prem and on any cloud. I hear SREs all over the world cheering from the sidelines!

I’ve not yet explored the GCP Marketplace and what APIs are provided but if that endpoint is abstracted in such way that it becomes a two choice declaration – what workload and where. It’s a home-run.

-“But what about your data?”

I glance over the landscape of storage vendors that try to cobble together a story to fit this new paradigm (a sinister laugh follows). Honestly, good luck! If you can’t present uniform multicloud data services you are out. Auf’d. My current employer is in EXTREMELY good shape to assume a leadership position in space with a good head start. To give the followers a fair game, start here:

Do not store your data in the Kubernetes cluster (doh!)

Do not copy data around and process it like someone else is paying the bill (your customer Mr. Vendor)

Having the power to present data to any public cloud, including hybrid, with the ability to transition workloads between clouds fairly seamless (there will be a “last sync” tax and some plumbing) will enable users to decouple themselves from the data gravity problem entirely.

-"Hey Google! Spin up a GKE cluster on Azure and bring my workloads labeled production with you." -"Sure, I’ll play your favorite song from Spotify while I reconfigure your production environment."

I’ve been minimally exposed to “Managed Kubernetes” but recent projects has forced me into get a better understanding what it can do. If you’ve ever deployed a cluster on Amazon EKS, Google GKE or Azure AKS you’ll soon notice that you have no masters in your cluster(!). That’s right, that means someone else is managing that piece of the puzzle for you (and charge you) and everything just works. Also convenient with this concept is that the tools provided by these services allow you to just add more compute nodes dynamically without any effort what so ever.

The trick is brilliant and simple. There IS a dedicated master for your cluster – but it’s managed by an uber Kubernetes cluster – that uber cluster also have access to your IaaS to fling compute nodes left, right and center at your command.

Let’s break this down in a pretty diagram.

A new cuddle command is of course needed for all this to tie together: clusterctl. Clustercuddle allows an admin to create and delete clusters on an IaaS provider. A list of supported, or in development, IaaS providers are available in the Kubernetes SIG Cluster API GitHub repo but all your usual suspects are there amongst the public cloud providers as well as vSphere and OpenStack (unsure if this is in any way related to OpenStack Magnum). The listed project for “Bare Metal” is an OpenStack Ironic fork to allow bare metal provisioning with clusterctl. There was some hay on El Reg about Red Hat joining the fray just the other day, so I'm sure this will all come together for the Red Hat OpenShift customers who opt-out from running Red Hat OpenStack Platfrom (OSP) as the IaaS but clearly want the benefit of running bare metal compute nodes.

Clustercuddle also funnels out all the appropriate kubeconfigs that users need to communicate with their API server running on the uber cluster. The cluster-admin of a slave cluster has a machinedeployment API object where they can manipulate properties for new compute nodes that gets added to the cluster. Behold, simply flicking .spec.replicas will automatically conform the cluster by either provision or decommission nodes.

A sample machinedeployment API object is available in the Cluster API GitHub repo but shown here for completeness:

--- apiVersion: "cluster.k8s.io/v1alpha1" kind: MachineDeployment metadata: name: sample-machinedeployment spec: replicas: 3 selector: matchLabels: foo: bar template: metadata: labels: foo: bar spec: providerSpec: value: apiVersion: "gceproviderconfig/v1alpha1" kind: "GCEProviderConfig" roles: - Node project: "${GCLOUD_PROJECT}" zone: "us-central1-c" machineType: "n1-standard-2" os: "ubuntu-1604-lts" versions: kubelet: 1.9.4