SerrNovik - Fotolia

Kubernetes 1.6 verbessert Sicherheit, Skalierbarkeit und Storage-Provisioning

Multi-User, Multi-Workloads und Skalierbarkeit: Kubernetes 1.6 gilt als Stabilization Release, bringt aber auch zahlreiche neue Funktionen.

Pünktlich zur CloudNativeCon und KubernetesCon 2017 Europe in Berlin steht die neue Kubernetes-Version 1.6 zur Verfügung. Kubernetes 1.6 wird zwar offiziell als Stabilization Release bezeichnet, enthält aber dennoch einige weitreichende Neuerungen, die das Kubernetes-Projekt für immer mehr Unternehmen interessant machen dürften.

Der offizielle Kubernetes-Blog betitelt die Neuerungen mit „Multi-User, Multi-Workloads at Scale“ und meint damit vor allem die neuen Funktionen rund um rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC) und Workload-Scheduling, während parallel dazu die maximal unterstützte Anzahl an Kubernetes-Nodes auf 5.000 Nodes pro Cluster angehoben wurde.

Bessere Kubernetes-Skalierbarkeit durch etcd3

Mit Kubernetes 1.6 wurde die Entwicklung einer neuen Release-Version erstmals nicht von Google selbst verantwortet, sondern mit Dan Gillespie, Software Engineer bei CoreOS, von einem Unternehmen aus der Kubernetes-Community. Damit, so Dan Gillespie selbst, wollte Google ein klares Zeichen für die Offenheit bei der Weiterentwicklung des Kubernetes-Projekts zeigen.

Kubernetes wird im Rahmen der Cloud Native Computing Foundation (CNCF) weiterentwickelt, neben Google und CoreOS sind auch Unternehmen wie Red Hat, Intel, Docker, IBM, Dell EMC, Cisco, Fujitsu oder Mesosphere maßgeblich am Kubernetes-Projekt beteiligt.

Grundlage der neuen Skalierbarkeit auf bis zu 5.000 Nodes und 150.000 Pods, so Dan Gillespie weiter, ist der Wechsel auf die neue Version 3 des verteilten Key Value Store etcd. Dabei könne man sich etcd als grundlegende Kubernetes-Datenbank vorstellen, die ein umfassendes Inventar der Kubernetes-Bereitstellung enthält.

Weitere Artikel zu Kubernetes:

Vorteile der Container-Orchestrierung mit Kubernetes

Swarm vs. Kubernetes: Zwei Tools zur Container-Orchestrierung

Container-Virtualisierung mit Kubernetes, Docker und GKE

Nun war etcd3 zwar schon seit Kubernetes 1.4 nutzbar, erst mit Kubernetes 1.6 wird etcd3 aber jetzt zum Standard für Kubernetes-Deployments. Mit etcd3 geht auch ein Wechsel der Encoding Engine auf protobuf einher, weshalb das Kubernetes-Projektteam auf GitHub empfiehlt, vor dem Upgrade auf Kubernetes 1.6 dringend per Backup die etcd-Daten zu sichern. Durch den Wechsel auf protobuf, so die Kubernetes-Dokumentation auf GitHub, sei ein Downgrade auf eine frühere Kubernetes-Version vor 1.6 nicht mehr möglich.

Native RBAC-Funktionen in Kubernetes 1.6

Die wichtigste Neuerung in Kubernetes 1.6 ist laut Dan Gillespie aber die Weiterentwicklung von RBAC vom Alpha- in den Beta-Status. Damit habe RBAC zwar noch nicht den Status als stabil und damit bereit für den Produktiveinsatz erreicht, immerhin sei man diesem Ziel aber jetzt einen Schritt näher.

Während ihrer Keynote auf der CloudNativeCon/KubeCon zeigte  Aparna Sinha, Product Management Lead für Kubernetes bei Google, wie sich per RBAC in Kubernetes über unterschiedliche Namensräume je nach zugewiesener Rolle unterschiedliche Zugriffsrechte konfigurieren lassen. Damit können Administratoren ab Kubernetes 1.6 Anwendern zum Beispiel für Cluster-Nodes oder auch nur für einzelne Kubernetes-Pods granulare Rechte einrichten, von einfachen Lese- bis hin zu umfangreichen Admin-Rechten.

Aparna Sinha von Google während der RBAC-Demonstration auf der CloudNativeCon/KubeCon 2017.
Aparna Sinha von Google auf der CloudNativeCon/KubeCon 2017.

Dynamic Provisioning vereinfacht das Storage-Management

Im Cloud-Native-Umfeld gilt zwar das Mantra zustandsloser Cloud-Anwendungen (Stateless Apps), gerade Enterprise-Umgebungen dürften aber kaum ohne persistenten Storage auskommen. Für diese Anwendungsfälle verbessert Kubernetes 1.6 das Storage-Management durch Dynamic Storage Provisioning, das jetzt als stabil und damit bereit für Produktivumgebungen gilt.

Bisher mussten Kubernetes-Workloads spezifische Storage-Geräte zugewiesen werden, mit Dynamic Storage Provisioning können Administratoren jetzt über Persistent Volume Claims (PVC) eine Storage-Klasse angeben, mit denen sich die Storage-Anforderung vom konkreten Provisioning entkoppeln lässt. Storage muss zur Kubernetes-Nutzung also nicht mehr vorab definiert werden, sondern wird von Kubernetes selbst je nach Bedarf provisioniert.

Neben dem Automatisierungspotenzial liegt der große Vorteil des Dynamic Storage Provisionings vor allem in der Portabilität der Storage-Implementierung über Pods und Nodes hinweg, was zum Beispiel Hochverfügbarkeitsszenarien zugutekommen soll. Standardmäßig enthält Kubernetes 1.6 vordefinierte Storage-Klassen für AWS, Microsoft Azure, Google Cloud Platform und VMware vSphere.

Scheduling, Affinität und Anti-Affinität

Das erweiterte Scheduling in Kubernetes 1.6 ist derzeit im Beta-Status verfügbar und gibt Kubernetes-Administratoren mehr Möglichkeiten zum Pod-Scheduling an die Hand. Damit lassen sich beispielsweise Pods auf bestimmte Nodes eines Clusters beschränken, was erneut für Hochverfügbarkeitskonfigurationen genutzt werden kann. Genauso können aber auch für unterschiedliche Kubernetes-Pods unterschiedliche Scheduler verwendet werden.

Auch die Node-Affinität beziehungsweise Anti-Affinität steht in Kubernetes 1.6 als Beta-Funktion zur Verfügung und ermöglicht das Scheduling von Kubernetes-Workloads auf Basis vorgegebener oder angepasster Node-Label, über die sich beispielsweise bestimmte Host-Namen, Hardwarearchitekturen oder auch Betriebssystemversionen als erwünscht oder strikt vorgegeben für das Scheduling definieren lassen.

CRI ermöglicht Rkt-Nutzung

Bei der Interaktion mit Container-Runtimes führt Kubernetes 1.6 mit dem Container Runtime Interface (CRI) gewissermaßen eine neue Abstraktionsebene ein und ermöglicht so jetzt auch die Nutzung anderer Container-Laufzeitumgebungen wie etwa rkt von CoreOS. Dabei bleibt Docker die Standard-Runtime, laut Dan Gillespie wird es mit dem neuen CRI aber wesentlich einfacher, die vorhandene Container-Runtime durch andere auszutauschen. Die CRI-Implementierung für Docker befindet sich mit Kubernetes 1.6 im Beta-Stadium, der Support für alternative Runtimes dagegen lediglich im Alpha-Status.

Ebenfalls im frühen Alpha-Status ist die Nutzung multipler NVIDIA-GPUs für Machine-Learning- und Big-Data-Anwendungen möglich. Hierfür müssen Kubernetes-Nodes mit vorinstallierten NVIDIA-Treibern zur Verfügung stehen, zudem ist die GPU-Nutzung über unterschiedliche Nodes hinweg nur über die Docker-Runtime möglich. Unter diesen Voraussetzungen können Container-Workloads aber schon jetzt auf die Rechenkraft der GPUs zugreifen. Dabei teilen sich Container oder Pods keine GPUs, sie können aber jeweils für sich durchaus auch mehrere GPUs nutzen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Cloud-Anwendungen

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close