Kube One 1.3 macht es einfacher Cluster-Lifecycle-Management in Cloud-, On-Prem-, Edge- und IoT-Umgebungen

Autor Ulrike Ostler |

„Kube One “ist ein Open-Source-Cluster-Lifecycle-Management-Tool von Kubermatic (ehemals Loodse), das die Bereitstellung und Verwaltung von Clustern in einer Cloud-, On-Prem-, Edge- sowie IoT-Umgebung automatisiert. Seit gestern steht die Version1.3 allgemein zur Verfügung.

Anbieter zum Thema

Anwender:innen können verbleibenden Docker-Cluster mit einem einzigen Befehl auf containerd migrieren.
Anwender:innen können verbleibenden Docker-Cluster mit einem einzigen Befehl auf containerd migrieren.
(Bild: Kubermatic)

Seit der Version 0.11 von Kube One gibt es die so genannten Kube-One-Addons, die einen einfach zu bedienenden Mechanismus für die Bereitstellung verschiedener zusätzlicher Komponenten bietet, die die Benutzererfahrung verbessern soll. Allerdings mussten Anwender YAML-Manifeste zusammen mit dem „Kube One-Cluster-Manifest“ bereitstellen, selbst wenn sie die Addons verwendeten.

Jetzt gibt es eine neue Addon-API. Jetzt sind alle zusätzlichen Features, zum Beispiel „cluster-autoscaler“, in eine Kube-One-Binärdatei eingebettet. Wenn Anwender:innen nun eines der Addons verwenden möchten, können sie es einfach über die Addons-API im Kube-One-Cluster-Manifest anfordern.

Darüber hinaus wurden alle bestehenden Go-Strukturen, die für die Bereitstellung der Kernkomponenten verwendet werden, wie der Maschinen-Controller, durch YAML-basierte Addons ersetzt. Wenn eine bereitgestellte Komponente geändert werden soll, müssen User nur das entsprechende Manifest in ihr Addons-Verzeichnis stellen. Es ist unnötig, irgendetwas im Code zu ändern oder Kube One neu zu kompilieren.

Sicherheit mit verwalteter Unterstützung für Encryption Provider

Kubernetes Encryption Provider ermöglichen es, Daten im Ruhezustand zu verschlüsseln. Das bedeutet, dass ausgewählte Ressourcen in verschlüsselter Form in „etcd“ gespeichert werden. Das gilt für folgenden Operationen:

  • Aktivieren/Deaktivieren von Encryption Provider
  • Generierung und Rotation von Verschlüsselungsschlüsseln
  • Verwendung von benutzerdefinierten Konfigurationen
  • Verwendung von KMS-basierten Verschlüsselungsanbietern

Laut Kubermatic ist die Aktivierung von Verschlüsselungs-Provider auf Basis von AESCBC für alle geheimen Objekte im Cluster ist so einfach wie die Verwendung des folgenden Kube One Cluster-Manifests und die Ausführung von `kubeone apply`:

``yamlapiVersion: kubeone.io/v1beta1Art: KubeOneClusterVersionen: kubernetes: '1.22.1'Eigenschaften: encryptionProviders: enable: true```

Automatische Migration von Clustern zu containerd

Mit der Version 1.20 von Kubernetes wurde die Unterstützung für Docker (dockershim) als zugrunde liegende Container-Laufzeitumgebung abgeschafft. Mit dem Kubernetes-Release 1.23 wird die Unterstützung für Docker als Container-Laufzeitumgebung vollständig entfernt.

Stattdessen wird eine mit dem Container Runtime Interface (CRI) kompatible Container-Laufzeitumgebung, wie „containerd“, benötigt. Das bedeutet, dass sich Docker weiterhin im Entwicklungs-Workflow verwendet werden lässt, aber eine CRI-kompatible Container-Laufzeitumgebung auf Kubernetes-Knoten einzusetzen ist.

Außerdem können verbliebene Cluster, auf denen Docker läuft, mit einem einzigen Befehl auf containerd migriert werden. Darüber hinaus wird Containerd mit diesem Release nun auch auf „Flatcar Linux“ unterstützt, so dass Admins FlatcarLinux-Cluster mit Containerd bereitstellen oder bestehenden Cluster migrieren können.

Unterstützung von AWS Spot-Instanzen

Für Anwendungen, die wirklich skalieren müssen, funktioniere die Cloud wirklich gut, heißt es von Kubermatic. Auf der anderen Seite sind die Kosten ein Thema, wenn es um die Optimierung geht. Deshalb gibt es nun eine integrierte, erweiterte Unterstützung für „AWS Spot-Instances“, mit der nicht nur die Spot-Instances selbst konfiguriert werden können, sondern auch der Betrag, den der Benutzer dafür zu zahlen bereit ist.

Für sensible Arbeitslasten kann Kube One Maschinenbereitstellungen mit Spot-Instanzen und reservierten Instanzen nebeneinander in einem einzigen Cluster ausführen. Laut Kubermatic lässt sich mithilfe dieser Art des Spot-Instanzenverbrauchs rund 70 Prozent der Maschinenkosten unserer CI-Pipeline einsparen.

Unterstützung für OpenStack, vSphere und Hetzner

Die neue Version bringt viele Verbesserungen für OpenStack, vSphere und Hetzner. Das Tool stellt jetzt zum Beispiel automatisch einen CSI-Treiber für alle drei Anbieter bereit, so dass von Cloud-Anbietern unterstützte Volumes verwendet werden können. Darüber hinaus wurden die externen Cloud-Controller-Manager (CCMs) für alle unterstützten Anbieter auf die neuesten Versionen aktualisiert, um die aktuellsten Fehlerkorrekturen und Verbesserungen zu berücksichtigen.

Außerdem ist nun eine CCM/CSI-Migration für OpenStack- und „vSphere“-Cluster implementiert, um auf die Abschaffung der In-Tree-Cloud-Anbieter zu reagieren. Ursprünglich waren die Controller, die für die Verbindung Ihrer Cluster mit dem Cloud-Anbieter verantwortlich sind, direkt in Kubernetes integriert.

Diese Controller gelten nun als veraltet und werden durch externe Cloud Controller Manager (CCMs) und CSI-Treiber ersetzt. Wer noch OpenStack- oder vSphere-Cluster hat, die In-Tree-Cloud-Provider verwenden, kann sie jetzt mit einem einzigen Kube-One-Befehl migrieren.

Umgang mit komplexen Anwendungsfällen

Neben der Addons-API wurde auch die Kube-One-Cluster-API verbessert. Anwender:innen können nun ein benutzerdefiniertes CA-Bündel bereitstellen, das von den Komponenten der Steuerebene verwendet werden kann, einschließlich CCM, CSI und Machine-Controller. Dies ist eine wichtige Funktion für OpenStack- und vSphere-Cluster, wenn das Setup eine benutzerdefinierte CA verwendet, der die Betriebssysteme nicht von vornherein vertrauen.

Es gibt auch neue Optionen für die Konfiguration von „kube-proxy“. Admins können wählen, ob sie ihn im „iptables“-Modus, der die Standardeinstellung ist, oder im „IPVS“-Modus ausführen möchten. Die Ausführung von kube-proxy im IPVS-Modus bietet einige zusätzliche Optionen, wie die Aktivierung von „strict ARP“, die Auswahl eines Schedulers oder die Konfiguration von Timeouts. Einige dieser Optionen sind nützlich, insbesondere wenn „MetalLB“ verwendet wird oder die bessere Skalierbarkeit von IPVS genutzt werden soll.

Kubermatic stellt ein Kompatibilitätsdokument bereit, das eine Liste der unterstützten Kubernetes-Versionen für jede Kube-One-Version enthält.

(ID:47639961)