Wahrsagerei

Kubernetes hat in meiner Arbeit bereits eine wichtige Rolle gespielt und wird in Zukunft noch wichtiger. Aber 2018 neigt sich dem Ende zu. Vergessen Sie also die Bescheidenheit und machen Sie eine kühne Vorhersage:

Die Zukunft von Kubernetes sind virtuelle Maschinen, keine Container

Nach dem chinesischen Horoskop war 2018 das Jahr des Hundes, aber in der Technologie war es das Jahr der Kubernetes. Viele lernen gerade etwas über diese revolutionäre Technologie, und IT-Abteilungen überall versuchen, eine „Kubernetes-Strategie“ zu entwickeln [1]. Einige Organisationen haben bereits große Workloads auf Kubernetes übertragen.

[1] Wenn Sie versuchen, eine Kubernetes-Strategie zu entwickeln, sind Sie bereits gescheitert, dies ist jedoch ein Thema für einen anderen Artikel.

Mit anderen Worten, bei Kubernetes gibt es bei jedem Schritt des „Gartner Sensation Cycle“ viele Menschen. Einige stecken in einer Höhle der Enttäuschung fest oder ertrinken in einer Grube der Verzweiflung.


Jeremykemp, Wikipedia . Creative Commons CC BY-SA 3.0

Ich bin ein großer Fan von Containern und ich werde nicht sagen, dass Container tot sind . 2013 gab uns Docker eine Shell für Linux-Container: eine erstaunliche neue Möglichkeit, Anwendungen zu erstellen, zu verpacken, freizugeben und bereitzustellen. Es erschien zum richtigen Zeitpunkt, als wir begannen, die kontinuierliche Lieferung ernst zu nehmen. Ihr Modell wurde ideal für die Lieferkette und trug zur Entstehung der PaaS-Plattform und dann von CaaS bei.



Die Google-Ingenieure sahen, dass die IT-Community endlich bereit für Container war. Google verwendet Container seit sehr langer Zeit und kann in gewissem Sinne als Erfinder der Containerisierung angesehen werden. Sie begannen mit der Entwicklung von Kubernetes. Wie Sie jetzt wissen, ist dies die kostenlose Reinkarnation der Google-eigenen Borg-Plattform.

Bald wurde Kubernetes von allen großen Clouds (GKE, AKS, EKS) unterstützt. On-Premise-Services haben auch schnell Plattformen auf Basis von Kubernetes (Pivotal Container Service, Openshift usw.) erstellt.

Weiche Mandantenfähigkeit

Es war notwendig, ein lästiges Problem zu lösen, das als Mangel an Containern angesehen werden kann ... dies ist eine Mandantenfähigkeit.

Linux-Container wurden nicht als sichere Sandboxen erstellt (wie Solaris Zones oder FreeBSD Jails). Stattdessen bauten sie auf einem gemeinsamen Kernelmodell auf, das Kernelfunktionen verwendet, um eine grundlegende Prozessisolation bereitzustellen. Wie Jesse Frazel sagen würde : "Container sind nicht die wirkliche Sache."


Hinzu kommt, dass die meisten Komponenten von Kubernetes keine Mieter kennen. Natürlich haben Sie Pod- Namespaces und Sicherheitsrichtlinien , aber in der API gibt es so etwas nicht. Sowie in internen Komponenten wie kubelet oder kube-proxy . Dies führt dazu, dass Kubernetes das Modell der "Soft Rent" (Soft Tenancy) umsetzt.


Kubernetes Architektur

Abstraktionen sickern weiter. Eine Plattform auf Containern erbt viele Aspekte der Soft Rent. Plattformen auf mandantenfähigen virtuellen Maschinen erben diesen harten Mietvertrag (VMware, Amazon Web Services, OpenStack usw.).

Das Soft-Rental-Modell von Kubernetes bringt Dienstleister und Distributionen in eine seltsame Position. Der Kubernetes-Cluster selbst wird zu einer „harten Mietlinie“. Selbst innerhalb derselben Organisation gibt es viele Gründe, eine harte Miete zwischen Benutzern (oder Anwendungen) zu fordern. Da öffentliche Clouds vollständig verwaltete Kubernetes als Service bereitstellen, können Kunden problemlos ihren eigenen Cluster verwenden und die Clustergrenze als Isolationspunkt verwenden.

Einige Kubernetes-Distributionen, wie der Pivotal Container Service (PKS) , sind sich dieses Mietproblems bewusst und verwenden ein ähnliches Modell, das dieselben Kubernetes als Service bereitstellt, der aus einer öffentlichen Cloud, jedoch in Ihrem eigenen Rechenzentrum, bezogen werden kann.

Dies führte zur Entstehung des Modells „viele Cluster“ anstelle von „einem großen gemeinsamen Cluster“. Bei GKE-Kunden von Google werden häufig Dutzende von Kubernetes-Clustern für mehrere Teams bereitgestellt. Oft bekommt jeder Entwickler seinen eigenen Cluster. Dieses Verhalten erzeugt eine schockierende Anzahl von Instanzen (Kubesprawl).

Alternativ können Betreiber ihre eigenen Kubernetes-Cluster in ihren eigenen Rechenzentren einrichten, um zusätzliche Arbeit für die Verwaltung mehrerer Cluster zu übernehmen, oder vereinbaren, einen oder zwei große Cluster sanft zu leasen.

Normalerweise besteht der kleinste Cluster aus vier Maschinen (oder virtuellen Maschinen). Eine (oder drei für HA) für Kubernetes Master, drei für Kubernetes Workers. Es wird viel Geld für Systeme ausgegeben, die größtenteils im Leerlauf sind.

Daher müssen Sie Kubernetes irgendwie in Richtung einer starren Mandantenfähigkeit bewegen. Die Kubernetes-Community ist sich dieser Notwendigkeit bewusst. Eine Multi-Lease-Arbeitsgruppe wurde bereits gebildet. Sie arbeitet hart an diesem Problem und es gibt verschiedene Modelle und Vorschläge, wie mit jedem Modell gearbeitet werden soll.

Jesse Frazel hat einen Blog-Beitrag zu diesem Thema geschrieben, und es ist großartig, weil sie viel schlauer ist als ich, sodass ich mich auf sie beziehen und mich vor zehn Jahren intensiven Studiums retten kann, um ihr Niveau zu erreichen. Wenn Sie diesen Beitrag nicht gelesen haben, lesen Sie ihn jetzt.

Nur sehr kleine VMs, die auf Geschwindigkeit optimiert sind ...

Kata Containers ist ein Open Source-Projekt und eine Community, die daran arbeitet, eine Standardimplementierung von leichten virtuellen Maschinen zu erstellen, die wie Container aussehen und funktionieren, aber Workload-Isolation und VM-Sicherheitsvorteile bieten.

Jesse schlägt vor, VM-Containertechnologie wie Kata-Container zu verwenden . Sie bieten Isolation auf VM-Ebene, funktionieren jedoch wie Container. Auf diese Weise kann Kubernetes jedem "Mandanten" (wir nehmen den Mandanten im Namespace an) einen eigenen Satz von Kubernetes-Systemdiensten zuweisen, die in verschachtelten VM-Containern ausgeführt werden (dem VM-Container in der virtuellen Maschine, die die IaaS-Infrastruktur bereitstellt).


Bild von Jesse Frasel: harte Mandantenfähigkeit bei Kubernetes

Dies ist eine elegante Kubernetes Multi-Rental-Lösung. Ihr Vorschlag geht noch weiter, dass Kubernetes verschachtelte VM-Container für Workloads (Pods) verwendet, die auf Kubernetes ausgeführt werden, was zu einer deutlichen Steigerung der Ressourcennutzung führt.

Wir haben noch mindestens eine Optimierung übrig. Erstellen Sie den richtigen Hypervisor für den zugrunde liegenden Infrastrukturanbieter oder Cloud-Anbieter. Wenn der VM-Container eine von IaaS bereitgestellte Abstraktion der ersten Ebene ist, werden wir die Ressourcennutzung weiter erhöhen. Die Mindestanzahl von VMs zum Starten eines Kubernetes-Clusters wird auf einen Computer (oder drei für HA) reduziert, um das Kubernetes-Verwaltungssystem zu hosten, das dem "Superuser" zur Verfügung steht.

Ressourcenoptimierte Mandantenfähigkeit (Kosten)

Eine Kubernetes-Bereitstellung mit zwei Namespaces und mehreren laufenden Anwendungen sieht ungefähr so ​​aus:

Hinweis: Es gibt andere Lasten in derselben IaaS-Infrastruktur. Da es sich um VM-Container handelt, haben sie dieselbe Isolationsstufe wie herkömmliche Cloud-VMs. Daher können sie mit minimalem Risiko auf demselben Hypervisor arbeiten.

Zunächst wird keine Infrastruktur in der Cloud bereitgestellt, sodass für einen Superuser die Kosten Null sind.

Ein Superuser fordert einen Kubernetes-Cluster aus der Cloud an. Der Cloud-Dienstanbieter erstellt eine virtuelle Maschine mit einem Container (oder drei für HA), auf der die wichtigsten Kubernetes-APIs und Systemdienste ausgeführt werden. Der Superuser kann Module im System-Namespace bereitstellen oder neue Bereiche erstellen, um den Zugriff an andere Benutzer zu delegieren.

Superuser erstellt zwei Namespaces foo und bar . Kubernetes fordert zwei VM-Container aus der Cloud für jede Ebene der Namespace-Verwaltung an (Kubernetes API und System Services). Der Superuser delegiert den Zugriff auf diese Namespaces an einige Benutzer. Jeder von ihnen startet einige Workloads (Module), und VM-Container fordern diese Container für diese Workloads an.

In allen Phasen zahlt der Superuser nur für die tatsächlich verbrauchten Ressourcen. Der Cloud-Dienstanbieter kontrolliert diese Ressourcen und sie stehen jedem Cloud-Benutzer zur Verfügung.

Ich sage nicht wirklich etwas Neues ...

Cloud-Service-Provider arbeiten bereits in diese Richtung. Sie können dies überprüfen, indem Sie Community-Ereignisse ansehen (Amazon hat dies möglicherweise bereits stillschweigend mit Fargate durchgeführt).

Der erste Tipp ist Virtual Kubelet , ein Open-Source-Tool, das sich als Kubelet tarnt. Es verbindet Kubernetes mit anderen APIs, wodurch Kubernetes VM-Container von einem Standardplaner in der Cloud anfordern kann.

Weitere Hinweise sind eine Vielzahl neuer Technologien für die VM-Containerisierung, wie die bereits erwähnten Kata-Container sowie der Firecracker von Amazon und der Gvisor von Google.

Fazit

Wenn Sie Verbesserungen im Modell einer harten Miete korrekt implementieren, finden Sie die Virtualisierung von Holy Grail of Kubernetes. Vollständige Isolierung der Workloads und keine zusätzlichen Kosten.

Wenn Sie die öffentliche Cloud nicht verwenden, profitieren Sie dennoch von einer höheren Ressourcennutzung, die sich bei geringeren Hardwareanforderungen auszahlt.

Hoffen wir, dass VMware und OpenStack auf Hypervisoren achten und diese freigeben, die auf leichten VM-Containern und den entsprechenden Virtual Kubelet-Implementierungen basieren.