Kubernetes unter Windows

Mit Kubernetes 1.5 wurde die Unterstützung für Windows-Container in einer Alpha-Version eingeführt. Da die Beta-Version kurz bevorstand, haben wir die Windows-Unterstützung getestet. Ist sie bereits ausgereift genug für Produktionsumgebungen?

Container-Lösungen wie Docker haben sich zu einem beliebten Trend für Softwareentwicklung und Deployment entwickelt. Sie ermöglichen es Entwicklern, Anwendungen einfach überall bereitzustellen, ohne sich um die Einrichtung der Umgebung kümmern zu müssen. Kubernetes (auch k8s genannt) hilft uns, die Lebenszyklen containerisierter Anwendungen zu verwalten, indem es ein Orchestrierungs-Framework bereitstellt, etwa für Auto-Scaling, Zustandsprüfungen und Wiederherstellung.

Ein weiterer aktueller Trend in der Softwareentwicklung sind Microservices, bei denen Anwendungen in kleinere, schlanke, verteilte und containerisierte Services aufgeteilt werden. Da Container ihren Ursprung in Linux haben, unterstützten Docker und damit auch k8s zunächst nur Linux. Ob es uns gefällt oder nicht: Es gibt weiterhin viele Anwendungen – ältere ebenso wie neue –, die speziell für Windows entwickelt wurden. Darüber hinaus müssen bei Microservices einige Services möglicherweise in einer Windows-Umgebung laufen. Deshalb arbeitete Microsoft mit Docker Inc. zusammen, um mit der Veröffentlichung von Windows Server 2016 Windows-Container einzuführen.

Windows-Container müssen weiterhin auf Windows-Hosts laufen. Wenn ihr also die Möglichkeiten von k8s nutzen möchtet, um Container-Anwendungen zu verwalten, die teilweise oder vollständig unter Windows laufen, benötigt ihr Windows-Nodes in eurem k8s-Cluster. Daher wurde eine Windows Special Interest Group (SIG) gegründet, um das Hinzufügen von Windows-Minion-Nodes zu Kubernetes-Clustern zu unterstützen. In Kubernetes 1.5 befand sich die Windows-Unterstützung in der Alpha-Version. Die Roadmap sah eine Beta-Version vor, sobald Kubernetes 1.8 veröffentlicht wird. Die entscheidende Frage ist jedoch: Ist sie bereits ausgereift genug für Produktionsumgebungen?

Die Alpha-Version bringt einige Einschränkungen mit sich, wie in der Ankündigung beschrieben. Erstens unterstützt Windows keine Netzwerk-Namespaces. Das bedeutet, dass Container im selben Pod nicht über localhost kommunizieren können. Dadurch ist die Anzahl der Container pro Pod auf einen beschränkt. Außerdem waren die DNS-Funktionen noch nicht vollständig implementiert, und UDP wurde innerhalb eines Containers nicht unterstützt.

Test der Alpha-Version auf AWS mit Kops

Wir haben die Alpha-Version der Windows-Unterstützung für k8s auf einem mit Kops auf AWS erstellten Cluster getestet. Mit Kops lassen sich k8s-Cluster auf AWS einfach bereitstellen und verwalten. Kops unterstützt die Erstellung eines Linux-basierten Clusters – sowohl für den Master als auch für die Minions. Daher müsst ihr Windows-Minions manuell zum Cluster hinzufügen, indem ihr der von k8s bereitgestellten Anleitung folgt. Die Anleitung führt euch durch die Konfiguration des Netzwerks, das Erstellen der kubelet- und kube-proxy-Binärdateien für Windows sowie das Starten beider Komponenten. Sobald die Windows-Minions erfolgreich eurem k8s-Cluster beigetreten sind, könnt ihr den k8s-Scheduler mithilfe von NodeSelector anweisen, bestimmte Pods – logische Gruppen von Containern – auf den Windows-Minions zu planen.

Der Ansatz der Alpha-Version bringt bei der Verwendung mit Kops auf AWS mehrere Herausforderungen mit sich und eignet sich daher nicht gut für den Einsatz in Produktion:

• Manuelle Änderungen an den Cloud-Ressourcen eures k8s-Clusters – beispielsweise das Starten von Windows-EC2-Instanzen innerhalb der VPC des Clusters – schaffen Abhängigkeiten, die euer Cluster-Management-Tool wie Kops nicht kennt. Das kann den Betrieb eures Cluster-Management-Tools beeinträchtigen. Wenn ihr beispielsweise versucht, den Cluster nach dem manuellen Hinzufügen von Windows-Minions mit Kops zu löschen, schlägt dies aufgrund unbekannter Abhängigkeiten zwischen den AWS-Cloud-Ressourcen fehl.

• Der in der offiziellen Anleitung vorgeschlagene Einrichtungsprozess ist anfällig, und die Netzwerkkonfiguration lässt sich leicht fehlerhaft einrichten. Doch das ist noch nicht alles: Ihr müsst außerdem den Pod-CIDR-Bereich erraten, den der Master eurem Windows-Minion zuweisen wird, bevor er tatsächlich zugewiesen wurde. Das ist alles andere als ideal!

• Da die Windows-Unterstützung in k8s relativ neu ist, entwickelt sie sich mit zunehmender Reife weiter. Die SIG-Gruppe verfolgt beispielsweise inzwischen einen neuen Ansatz, um Windows-Minions mithilfe von OVN für das Networking zu einem k8s-Cluster hinzuzufügen. Obwohl diese Anleitung OVN für das Networking nutzt, sind weiterhin mehrere Schritte erforderlich, um OVS/OVN einzurichten und zu konfigurieren – nicht nur auf den Windows-Minions, sondern auch auf dem Master und den Linux-Minions. Dadurch lässt sich der OVN-Ansatz nicht zusammen mit k8s-Management-Tools wie Kops verwenden.

• Auch Windows Server 2017, dessen Veröffentlichung später in diesem Jahr erwartet wird, wird einige Verbesserungen beim Container-Networking mitbringen, die die Windows-Unterstützung in k8s-Clustern verbessern sollen.

Fazit

Derzeit wird die Windows-Unterstützung in k8s-Clustern zwar immer ausgereifter, ist aber noch nicht bereit für Produktionsumgebungen – insbesondere, wenn ihr ein Cluster-Management-Tool einsetzen möchtet. Was könnt ihr also tun, wenn ihr dennoch Windows-Minions in euren Kubernetes-Clustern benötigt? Ihr habt zwei Möglichkeiten:

1. Ihr könnt eure Cluster in die Azure Cloud verlagern und die kürzlich hinzugefügte Funktion Azure Container Service nutzen, mit der ihr Kubernetes-Cluster mit Windows-Minions bereitstellen könnt.

2. Oder, wenn ihr die Windows-Minions nur zur Ergänzung bestehender Anwendungen benötigt, die in eurem k8s-Cluster bereitgestellt sind – etwa um Windows-Slaves für Jenkins zu hosten –, startet eure Windows-Instanzen (VMs) außerhalb eurer k8s-Cluster in einer separaten VPC und lasst die in eurem k8s-Cluster bereitgestellten Anwendungen diese Windows-Instanzen nutzen. Wir werden diesen Ansatz in einem kommenden Beitrag vorstellen: Darin stellen wir einen Jenkins-Master auf einem k8s-Cluster bereit, mit Windows-Slaves, die sich von einer anderen VPC aus mit dem Master verbinden.

Im vergangenen Jahr hat sich die Windows-Unterstützung rund um Docker und k8s rasant weiterentwickelt, und Microsoft sowie seine Partner scheinen entschlossen, diesen Weg weiterzugehen. Wir werden die Entwicklungen in den kommenden Monaten im Blick behalten, wenn Windows Server 2017 veröffentlicht wird und die Windows-Unterstützung in k8s weiter ausreift.