Services und Replication

Kubernetes kennt zwei weitere sehr interessante Features, die bisher noch nicht erwähnt wurden. Mittels eines sogenannten Replication-Controllers können Sie Pods in der Breite skalieren. Anhand eines Pod-Labels können Sie Kubernetes anweisen, diesen Pod x-fach zur Verfügung zu stellen. Kubernetes erzeugt dabei die gewünschte Anzahl von Instanzen der Container und stellt sie auf den vorhandenen Minions zur Verfügung. Kubernetes kümmert sich auch darum, die Anzahl der Instanzen aktuell zu halten. Haben Sie also beispielsweise definiert, dass Sie gerne vier Instanzen Ihres Apache-Pods haben wollen, würde Kubernetes automatisch Apache-Docker-Instanzen starten oder beenden, bis die Anzahl der Instanzen der Definition entspricht.

Auch wenn die einzelnen Container IP-Adressen aus einem zuvor in Docker definierten Netzwerkbereich bekommen, erfolgt der Zugriff auf die einzelnen Instanzen eines Pods eher über sogenannte Services. Kubernetes legt hierfür eine Art Abstraktionslayer über bestimmte Pods vom gleichen Typ und weist diesem Service eine IP-Adresse zu. Der Zugriff auf die einzelnen Instanzen eines Pods erfolgt dann über diese Service-IP. Dafür wird die Anfrage an die Service-IP an die einzelnen Minions weitergeleitet und der Dienst kubelet-proxy auf den Minions ist dafür zuständig, die Anfrage an die richtigen Container weiterzuleiten.

Man kann sich einen solchen Service als eine Art Load-Balancer für ein bestimmtes Set an Pods vorstellen (siehe Bild). Damit das funktioniert, muss jeder Minion-Host über ein zusätzliches Netzwerk-Segment verfügen, aus dem der Pod dann eine IP-Adresse zugewiesen bekommt. Die kubelet-proxy-Dienste leiten die Anfrage dann genau an diese IP-Adresse weiter. Der einzige Cloud-Anbieter, der eine solche Netzwerkkonfiguration von Haus aus anbietet, ist jedoch die Google Cloud Platform. Bei allen anderen Anbietern, auch beim Einsatz des hier verwendeten Atomic-Images in einer lokalen Virtualisierungsumgebung, ist eine manuelle Konfiguration des Docker-Dienstes erforderlich. Diese hier zu beschreiben würde jedoch den Umfang des Artikels sprengen, weshalb der Autor an dieser Stelle auf die entsprechende Dokumentation [9] zu dem Thema verweist.

In den neuesten Releases des Atomic-Images wurde das Tool flannel [10] mit in das Image aufgenommen. Hiermit lassen sich sehr leicht sogenannte Overlay-Netzwerke einrichten, auf die Docker dann zurückgreifen kann. Dies erspart eine recht umfangreiche manuelle Konfiguration.

 Fazit

Auch wenn Kubernetes aktuell noch tief in der Beta-Phase steckt und die Ausrichtung des Tools auf die Google Cloud Engine sichtbar ist, so ist der Zugewinn an Flexibilität im Vergleich zu nackten Docker-Installationen bereits jetzt schon enorm. Kubernetes legt über die vorhandenen Hardware-Ressourcen einen zusätzlichen Abstraktionslayer und stellt sie als großen Hardware-Pool zur Verfügung.

Auf welchem System ein Container letztlich läuft, spielt keine Rolle mehr. Kubernetes sucht sich die hierfür notwendigen Ressourcen selbstständig zusammen und startet den Container dort, wo die Ressourcen vorhanden sind. Durch den Einsatz von Replication-Controllern hilft das Framework dabei, die vorhandenen Container in der Breite zu skalieren. Dies gelingt innerhalb kürzester Zeit.

Kubernetes-Services helfen dabei, den Zugang zu einem Dienst über eine einheitliche IP-Adresse zur Verfügung zu stellen. Somit entfällt das umständliche Heraussuchen von Container-IPs. Dies ist gerade auch dann besonders wertvoll, wenn man daran denkt, dass Container sehr kurzlebig sein können, um kurze Zeit später auf einem anderen Host wieder neu gestartet zu werden, wodurch sich die IP-Adresse ändert. Services abstrahieren diese Änderungen und erfordern keine Neukonfiguration, beispielsweise von vorgeschalteten Loadbalancern.

(of)