© zffoto/Shutterstock.com
Cloud Compendium
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.

Michael Frembs


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.NamespacesWenn 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 beispielsweise Pods zu setzen. So kann man die ReplicaSets bzw. AutoScaler eingrenzen. Übrigens: Sollte auf dem Namespace Quotas auf Ressourcen gesetzt werden, lohnt sich ein Blick in die LimitRanges, da ansonsten jeder Pod angeben muss, welche Ressourcen er benötigt (was aber sowieso empfehlenswert ist).Neben Quotas können auch die Zugriffsmöglichkeiten auf Namespace-Ebene eingeschränkt werden. Dank RBAC kann feingranular pro Ressource und Zugriffsmethode definiert werden, wer (sowohl LDAP-Nutzer als auch technische Service-Accounts) was machen darf. Das gibt Entwicklern die Möglichkeit, auf der dev-Stage nahezu Admin-Rechte und ab test-Stage...

Cloud Compendium
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.

Michael Frembs


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.NamespacesWenn 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 beispielsweise Pods zu setzen. So kann man die ReplicaSets bzw. AutoScaler eingrenzen. Übrigens: Sollte auf dem Namespace Quotas auf Ressourcen gesetzt werden, lohnt sich ein Blick in die LimitRanges, da ansonsten jeder Pod angeben muss, welche Ressourcen er benötigt (was aber sowieso empfehlenswert ist).Neben Quotas können auch die Zugriffsmöglichkeiten auf Namespace-Ebene eingeschränkt werden. Dank RBAC kann feingranular pro Ressource und Zugriffsmethode definiert werden, wer (sowohl LDAP-Nutzer als auch technische Service-Accounts) was machen darf. Das gibt Entwicklern die Möglichkeit, auf der dev-Stage nahezu Admin-Rechte und ab test-Stage...

Neugierig geworden?


    
Loading...

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