Mandantenfähigkeit kann in Kubernetes zum Einsatz kommen, um IT-Ressourcen und Abläufe voneinander zu trennen. Anwender müssen entscheiden, wie viel Isolation wirklich nötig ist.
Es könnte so schön sein: die Entwicklung von Anwendungen für die hybride Cloud und die Bereitstellung Cloud-nativer Anwendungen sind in derselben Struktur vereint, Rechenzentren und Clouds in einem Pool von Ressourcen zusammengefasst, und die Verwaltung und Orchestrierung wird von einem einzigen mächtigen Scheduler – Kubernetes – übernommen.
Doch die Realität ist anders. IT-Anwendungen lassen sich nicht vereinheitlichen. Einige Anwendungen sind immer wichtiger als andere, und es gibt Gründe, bestimmten Aufgaben zeitweise bei der Ressourcennutzung den Vortritt zu gewähren.
Es gibt auch Gründe, den Zugriff einzuschränken. Manchmal ist es notwendig, verschiedene Niederlassungen, Abteilungen oder Anwendungen desselben Unternehmens als unabhängige Kunden einer virtualisierten Ressource zu betrachten. Das ist das Einsatzgebiet für Kubernetes Multi-Tenancy (Mandantenfähigkeit).
Kubernetes unterstützt Labels, Taints und Toleranzen, mit denen Nutzer erkennen können, wann es sinnvoll ist, Ressourcen explizit zu lenken, entweder um teure oder knappe Funktionen auf Servern für bestimmte Fälle zu reservieren oder um sicherzustellen, dass wichtige Anwendungen jederzeit die Ressourcen bekommen, die sie benötigen. Kubernetes Multi-Tenancy ist eine weitere Umsetzung der altbekannten Erkenntnis, dass nicht alle Anwendungen gleich behandelt werden können. Die Verwendung von mehreren Mandanten ist jedoch kein Ersatz für Netzwerk- und API-Sicherheit.
Zwei Varianten für Mandantenfähigkeit
Es gibt zwei konzeptuell verschiedene Wege, die zu Kubernetes Multi-Tenancy führen. Zum einen kann eine Kubernetes-Bereitstellung mehrere mandantenspezifische Cluster umfassen, aber als Ganzes verwaltet werden. Dies bezeichnet man in Kubernetes als Föderation. Bei der zweiten Variante beherbergen die Cluster selbst mehrere unabhängige Mandanten. Letzteres ist das, was bei Kubernetes als Multi-Tenancy bezeichnet wird. Organisationen sollten jedoch die Vorteile und Herausforderungen beider Varianten evaluieren.
Ein Unternehmen könnte den Einsatz mehrerer Mandanten in Betracht ziehen, wenn die IT funktional unabhängige Unternehmen mit kollektiven Ressourcen unterstützt, oder wenn es plant, separate geschäftsspezifische IT-Ressourcen zu konsolidieren. Eine Lösung mit mehreren Mandanten kann beispielsweise bei der Unterstützung getrennter Tochtergesellschaften oder bei einer Fusion oder Übernahme zwischen zwei Unternehmen mit unterschiedlichen IT-Plattformen von Vorteil sein. In diesen Fällen werden durch die Mandantenfähigkeit die Ressourcen und Abläufe getrennter Organisationen auch in der IT weiterhin getrennt.
Der Einsatz von Mandantenfähigkeit muss durch einen triftigen Grund gerechtfertigt sein.
Der Nachteil ist jedoch, dass durch die Verwendung von mehreren Mandanten die Effizienz leidet und eventuelle Preisvorteile bei der Skalierung von Servern oder Cloud-Angeboten eingebüßt werden. Wenn der Grad der Trennung zwischen den Mandanten zunimmt, müssen das Betriebspersonal und die Ressourcenpools bestimmten Mandanten fest zugewiesen werden.
Möglicherweise reichen die Kapazitäten der Mitarbeiter jedoch nicht, alle getrennten Anwendungen und Ressourcen voll zu versorgen. Zudem leidet möglicherweise die Hosting-Effizienz aller Mandanten, da Anwendungen nicht frei über alle geeigneten Hosts hinweg migrieren können.
Der Einsatz von Mandantenfähigkeit muss also durch einen triftigen Grund gerechtfertigt sein. Für eine Organisation, die keine voneinander getrennten Anwendungen und Ressourcen benötigt, kommt dies gar nicht erst in Frage. Wer vermutet, dass er seine Ressourcen partitionieren muss, sollte die Gründe dafür sorgfältig prüfen.
Wenn es nur darum geht, eine korrekte Ressourcenzuteilung zu gewährleisten, ist das Trennen über Label, Taints und Toleranzen meist überflüssig. Sollte sich jedoch tatsächlich erweisen, dass das nicht ausreicht oder Compliance oder Sicherheitsanforderungen eine stärkere Partitionierung von Anwendungen und Ressourcen erfordern, hängt der nächste Schritt von der Größe des Unternehmens ab.
Bei großen Unternehmen sind die genannten Nachteile aufgrund der großen Menge an IT-Ressourcen, die sie verbrauchen, und aufgrund der Größe des IT-Teams weniger gravierend. Deshalb bietet es sich mitunter an, Tochtergesellschaften oder Geschäftsbereiche als unabhängige Mandanten zu führen.
Auch bei einer Aufteilung der Personal- und Hosting-Ressourcen nach Mandanten, wird jeder von ihnen groß genug sein, um einen effizienten Betrieb und die Unterstützung von Ressourcen zu gewährleisten. Ein großes Unternehmen muss sich dann entscheiden, ob es Multi-Tenant-Cluster oder mandantenspezifische Cluster unter einer allgemeinen Policy einführen sollte. Für mittelgroße Unternehmen muss sich ein Multi-Tenant-Cluster jedoch schon aus gewichtigen Gründen lohnen, um in Betracht zu kommen.
Föderation und Cluster gegeneinander abwägen
Eine Kubernetes-Föderation ermöglicht es einer Organisation, mehrere Kubernetes-Bereitstellungen und Cluster zu vereinen. Diese Funktion ist wertvoll für Multi-Cloud- und Hybrid-Cloud-Benutzer, die neben Kubernetes On-Premises auch Kubernetes-Cloud-Services verwalten.
Organisationen können diese Funktion auch zum Einrichten von übergeordneten Richtlinien für mandantenspezifische Kubernetes-Bereitstellungen verwenden. IBM, Red Hat, VMWare und Google bieten erweiterte Kubernetes-Pakete an, die für den Einsatz mit einer Föderation entwickelt wurden.
Der größte Vorteil der föderationsbasierten Mandantenfähigkeit besteht darin, dass sie eine vollständige Isolation der Organisationen und Mandanten bietet und dennoch die Möglichkeit beibehält, allgemeingültige Richtlinien für die Ressourcennutzung und die Bereitstellung von Containern festzulegen, wo dies erforderlich ist. Das ist eine besonders praktische Methode, mit der sich verhindern lässt, dass halbautonome Kubernetes-Mandanten gemeinsam genutzte Ressourcen in Beschlag nehmen oder Cloud-Ressourcen überbeanspruchen.
Allerdings muss jeder Mandant eine Kubernetes-Domain verwalten, um diese Vorteile zu nutzen, was für die einzelnen IT-Abteilungen aufwendig werden kann. Außerdem müssen die Cluster jeweils einem Mandanten zugeordnet werden. Das kann zu einem verschwenderischen Umgang mit Ressourcen führen, wenn einige Mandanten verhältnismäßig klein sind, also wenig Serverressourcen benötigen oder sehr wechselnde Ansprüche an ihren Server stellen.
Für kleinere Unternehmen – und große Unternehmen, welche die Nachteile des Föderationsmodells scheuen – ist eine Cluster-Multi-Tenancy vielleicht die bessere Option. Der Schlüssel dazu ist die korrekte Nutzung der in Kubernetes integrierten Cluster-Multi-Tenancy-Funktionen. Jeder Mandant erhält einen separaten Namespace.
Dann schützen Admins die Kubernetes-APIs und setzen die voreingestellte Kubernetes-Regel, die bewirkt, dass alle Komponenten, Container und Pods miteinander kommunizieren können, durch Richtlinien manuell außer Kraft.
Mit der Funktion Resssource Quota weist der Admin nun Kapazitäten an Namespaces zu; Labels, Taints und Toleranzen funktionieren ebenfalls, es ist aber schwieriger, sie über die Namespaces hinweg zu verwalten.
Schließlich kommen noch einige Kubernetes-Add-Ons oder -Implementierungen für die Partitionierung auf der Betriebsebene in Frage. Das Endergebnis ähnelt einer Multi-Tenancy-Lösung hinsichtlich der Isolation, erfordert jedoch weniger Aufwand im Betrieb.
Der Nachteil dieser Strategie besteht darin, dass man sich der föderationsbasierten Mandantenfähigkeit nur im Hinblick auf die Mandantenisolation annähert und dabei ein ungewöhnliches Kubernetes-Modell in Bezug auf die Kommunikation zwischen den Pods einsetzt. Unternehmen müssen alle unternehmensweiten Anwendungen über Mandanten hinweg außerhalb von Kubernetes integrieren – eine Vorgehensweise, die in einer Föderation üblich ist, aber nicht innerhalb einer einzigen Kubernetes-Domäne.
Darüber hinaus muss sichergestellt werden, dass die IT-Mitarbeiter die Unterschiede bei der Bereitstellung in mehreren Mandanten verstehen, denn das Fortführen alter Gewohnheiten kann die Isolation oder Stabilität gefährden.
Innerhalb der Kubernetes-Gemeinschaft gibt es außerdem eine eigene Gruppe für Mandantenfähigkeits-Belange, deren Dokumente nur für Mitglieder zugänglich sind. Diese Gruppe scheint den Prozess für Cluster-basierte Multi-Tenancy als einen geeigneten Ersatz für den föderativen Ansatz voranzutreiben und die Trennung noch zu intensivieren, so dass die einzelnen Mandanten komplett wie unabhängige Unternehmen geführt werden. Sollte dies der Fall sein, wird das auf Dauer die Nutzung von Multi-Tenancy für viele Anwender noch unattraktiver machen.
