© zffoto/Shutterstock.com
Isolierte Stages innerhalb eines Kubernetes-Clusters erstellen

Staging in Kubernetes


Wie viele wissen, werden in der Entwicklung oft mehrere Stages verwendet, etwa dev, test und prod. Wenn man nun die Transformation in die Cloud angeht, stellt sich oft die Frage, wie viele Kubernetes-Cluster installiert werden sollen. Soll für jede Stage ein eigener Kubernetes-Cluster installiert werden, oder kann man mehrere Stages zusammenführen und sich somit Installations- und Konfigurationsaufwand sparen? Im Folgenden wird aufgezeigt, wie innerhalb eines Kubernetes-Clusters voneinander isolierte Stages erstellt werden können. Im Anschluss werden die Vor- und Nachteile mehrere Stages innerhalb eines Kubernetes-Clusters diskutiert.

Während der Entwicklung einer Anwendung werden unterschiedliche Anforderungen an die jeweiligen Stages gestellt. Während in der dev-Stage alles auf den Entwickler ausgelegt ist – dieser also viele Rechte hat, wenig Rücksicht auf andere nehmen muss und somit die Anwendung auch mal nicht funktionieren kann bzw. nicht ansprechbar sein darf –, sieht es in der prod-Stage komplett anders aus. Auf dieser Stage laufen die Anwendungen, die für die Nutzer gedacht sind. Das heißt, diese Anwendungen müssen hochverfügbar sein (Zero Downtime). Außerdem bringen diese Nutzer produktive, personenbezogene Daten mit, die nicht für jedermanns Augen gedacht sind. Mehrere Stages sind also nicht nur eine Best Practice, sondern unabdingbar.

Namespaces

Wenn man beim Sprung in die Cloud nun Kubernetes einsetzt, muss man fast unweigerlich Namespaces zur Gruppierung und Sortierung der Ressourcen verwenden. Die offizielle Dokumentation schreibt dazu: „Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces“ [1]. Kubernetes bietet hierfür ein RESTful API an. Dementsprechend findet jede Konfiguration über eine Ressource statt, diese werden in Namespaces abgelegt und gruppiert. Vorstellbar – wenn auch zu grobgranular – wäre ein Namespace pro Stage. Empfehlenswerter wäre ein Namespace pro Stage und Produkt bzw. Anwendung, vor allem wenn der Kubernetes-Cluster von mehreren Teams genutzt wird.

Pro Namespace können unterschiedliche Konfigurationen vorgenommen werden. Es ist unter anderem möglich, Quotas zu definieren. Dadurch wird der Ressourcenverbrauch (RAM und CPU) aller laufenden Pods innerhalb des Namespace gedeckelt. Den dev-Namespaces können z. B. weniger Ressourcen zur Verfügung gestellt werden als den test-Namespaces. Des Weiteren ist es möglich, auch Limits auf Anzahl von beispi...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang