Mit Kubernetes Install Quickies haben wir uns vor einiger Zeit schon mal beschäftigt. Sehr guten Eindruck machte damals schon K3S, ein einzelnes Binary, entwickelt von Rancher, zur Benutzung in schmalen Umgebungen für Kubernetes. Wie kriegen wir aber schnell eine arbeitsfähige Umgebung zum Laufen?
Die Antwort lautet wieder Terraform. Mit Terraform können wir Zustände von Resourcen in der Infrastruktur beschreiben, die dann wieder durch Module oder Provider bereitgestellt werden. Um etwa Resourcen in der Open Telekom Cloud zu nutzen, gibt es den Terraform Provider Opentelekomcloud . Dieser stellt Resourcedefinitionen bereit wie etwa ein VPC:
Shell
resource "opentelekomcloud_vpc_v1" "vpc" { | |
name = var.environment | |
cidr = var.vpc_cidr | |
shared = true | |
} |
Sowas gibts dann auch fuer Subnet, EIP, ECS, EVS usw.. Und man kann die Resourcen miteinander verknuepfen. Ein Subnet brauch zum Beispiel die VPC-ID:
Shell
resource "opentelekomcloud_vpc_subnet_v1" "subnet" { | |
name = var.environment | |
vpc_id = opentelekomcloud_vpc_v1.vpc.id | |
cidr = var.subnet_cidr | |
gateway_ip = var.subnet_gateway_ip | |
primary_dns = var.subnet_primary_dns | |
secondary_dns = var.subnet_secondary_dns | |
} |
Am Ende haben wir den kompletten Unterbau fuer unseren Kubernetes Cluster mit Rancher. Deren Logik wird mit cloud-init einfach als Shell-Script in die VM injected und dort lokal ausgefuehrt.
K3S
https://github.com/eumel8/tf-k3s-otc
In diesem Reporitory befindet sich die Resourcenbeschreibung in Terraform zum Installieren eines K3S Clusters in der Open Telekom Cloud.
Vorteile:
- Sehr schmale Cluster Konfiguration mit 1,2 oder 3 Masternodes
- Nodes sind zustandslos, alle Daten liegen in einer RDS-Instanz (MySQL)
- Einzeiler zum beliebigen Erweitern mit Worker Nodes
Nachteile:
- Die RDS-Instanz als Ersatz fuer etcd ist der Dreh- und Angelpunkt des Clusters. Dadurch entstehen auch relativ hohe Betriebskosten
- Aenderungen an der ECS-Infrastruktur koennen dazu fuehren, dass alle Nodes gleichzeitig neu gespawned werden und der Dienst dadurch nicht verfuegbar ist. Dem wurde teilweise begegnet durch unterschiedliche Image-Versionen.
RKE2
https://github.com/eumel8/tf-rke2-otc
In diesem Repository befindet sich die Beschreibung fuer ein Terraform-Deployment in der OTC, das einen Kubernetes Cluster basierend auf RKE2 von Rancher erstellt.
Vorteile:
- Keine teure RDS-Instanz erforderlich, die Masternodes agieren unabhaengiger von der Infrastruktur
- Spezielles CIS Hardening (basierend auf US Governance Anforderungen) sind schon implementiert
Nachteile:
- Die Cluster-Daten liegen in der etcd auf jedem Masternode. Um die Daten nach einem Respawn nicht zu verlieren, wird ein extra Volume benoetigt, was auch einen hohen Datendurchsatz haben muss
- Entsprechend den Anforderungen von etcd muss der Cluster eine ungerade Anzahl von Nodes aufweisen - am wenigsten 1, besser 3
- Installation derzeit noch unstabil. Es sind zu viele Abhaengkeiten beim parallelen Erstellen der VMs. Eine Meldung koennte daraus resultieren, dass zu viele Mitglieder im register Status mit der etcd verbunden sind, wodurch dann erstmal gar nix mehr geht. Da bedarf es weiterer Abhaengigkeiten in Terraform
Der Vorteil bei beiden Methoden ist das "One-Binary"-Konzept. Es bedarf also nicht allzugrosser Vorbereitungen auf dem Betriebssystemlevel. Genausoleicht wie die Installation verlaeuft auch das Loeschen, es wird auch ein Binary zum Loeschen der Umgebung mitgeliefert. Der Gesamteindruck bei beiden ist auch die unkomplizierte Handhabung.
Als Nachteil kann man das Vendor-Lock-In sehen. Beide Projekte sind zwar OpenSource, aber die Entwicklung wird von Rancher gefuehrt, die nun zu SUSE gehoeren. Der neue Produktname ist SUSE Rancher
