Cluster API: ClusterClass und Managed Topologies
Ein wenig Kontext...
Bevor wir uns den Details zuwenden, sollten wir einen Schritt zurückgehen und einen Blick auf die Geschichte der Cluster-API werfen.
Das Cluster-API-Projekt begann vor drei Jahren. In den ersten Versionen konzentrierte sich das Projekt auf die Implementierung einer deklarativen API, welche die Bereitstellung und Verwaltung von Kubernetes Cluster über Cloudanbieter hinweg vereinheitlichte.
Ein voller Erfolg. Die großen Cloudanbieter wie AWS, Azure, Digital Ocean, GCP, Metal3, vSphere adaptierten die Cluster API umgehend und es werden immer mehr.
Nachdem die Roadmap für die Integration der Cluster API geklärt war, verlagerte sich der Schwerpunkt auf neue Funktionen:
- die automatische Control-Plane- und etcd-Verwaltung
- erweiterte selfhealing Funktionalitäten
- neue Strategien für die Verwaltung von Node-Instanzen
und vieles mehr.
Im Jahr 2021 indem viele Unternehmen die Cluster-API bereits produktiv einsetzen, um eine Vielzahl von Kubernetes-Clustern auf deklarative Art und Weise zu verwalten, konzentrierte sich das Projekt auf die Stabilisierung des Codes, der APIs und der Dokumentation.
Mit dieser soliden Basis und einer lebendigen, weiterwachsenden und einladenden Community, war es an der Zeit die Benutzerfreundlichkeit der Cluster API sowohl für neue als auch für erfahrene Benutzer zu optimieren.
Logische Konsequenz: ClusterClass und Managed Topologies!
Die Idee hinter der ClusterClass ist einfach:
Bau dir eine abstrakte ClusterKonfiguration und verwende sie als Vorlage, um die Komplexität deiner Clusterkonfiguration zu reduzieren.
ClusterClass Definition:
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
name: my-amazing-cluster-class
spec:
controlPlane:
ref:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlaneTemplate
name: high-availability-control-plane
machineInfrastructure:
ref:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
name: control-plane-machine
workers:
machineDeployments:
- class: type1-workers
template:
bootstrap:
ref:
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
name: type1-bootstrap
infrastructure:
ref:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
name: type1-machine
- class: type2-workers
template:
bootstrap:
ref:
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
name: type2-bootstrap
infrastructure:
ref:
kind: DockerMachineTemplate
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
name: type2-machine
infrastructure:
ref:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerClusterTemplate
name: cluster-infrastructure
Die Möglichkeiten sind endlos. Du kannst ClusterClass-Definitonen aus der Community, Standard-ClusterClass-Definitionen von deinem Cloundanbieter, interne ClusterClasses oder sogar benutzerdefinierte ClusterClass-Definitionen für fortgeschrittene Szenarien erstellen.
Mit Hilfe von Managed Topologies lassen sich die ClusterClass-Definitonen an ein Cluster binden.
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: my-amazing-cluster
namespace: bar
spec:
topology: # define a managed topology
class: my-amazing-cluster-class # use the ClusterClass mentioned earlier
version: v1.21.2
controlPlane:
replicas: 3
workers:
machineDeployments:
- class: type1-workers
name: big-pool-of-machines
replicas: