Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Isolierung von Mandanten

Wenn wir an Mehrmandantenfähigkeit denken, möchten wir oft einen Benutzer oder eine Anwendung von anderen Benutzern oder Anwendungen isolieren, die auf einer gemeinsam genutzten Infrastruktur ausgeführt werden.

Kubernetes ist ein Single-Tenant-Orchestrator, d. h. eine einzelne Instanz der Steuerungsebene wird von allen Mandanten innerhalb eines Clusters gemeinsam genutzt. Es gibt jedoch verschiedene Kubernetes-Objekte, mit denen Sie den Anschein einer Mehrmandantenfähigkeit erzeugen können. Beispielsweise können Namespaces und rollenbasierte Zugriffskontrollen (RBAC) implementiert werden, um Mandanten logisch voneinander zu isolieren. In ähnlicher Weise können Kontingente und Grenzbereiche verwendet werden, um die Menge an Clusterressourcen zu steuern, die jeder Mandant verbrauchen kann. Dennoch ist der Cluster das einzige Konstrukt, das eine starke Sicherheitsgrenze bietet. Das liegt daran, dass ein Angreifer, der Zugriff auf einen Host innerhalb des Clusters erlangt, ConfigMapsalle Secrets und Volumes abrufen kann, die auf diesem Host installiert sind. Sie könnten sich auch als Kubelet ausgeben, was es ihnen ermöglichen würde, die Attribute des Knotens zu manipulieren, der sich innerhalb des Clusters seitlich and/or bewegt.

In den folgenden Abschnitten wird erklärt, wie die Mandantenisolierung implementiert und gleichzeitig die Risiken der Verwendung eines Single-Tenant-Orchestrators wie Kubernetes minimiert werden.

Sanfte Mehrmandantenfähigkeit

Bei Soft-Multi-Tenancy verwenden Sie native Kubernetes-Konstrukte, z. B. Namespaces, Rollen und Rollenbindungen sowie Netzwerkrichtlinien, um eine logische Trennung zwischen Mandanten herzustellen. RBAC kann beispielsweise verhindern, dass Mandanten auf die Ressourcen des jeweils anderen zugreifen oder diese manipulieren. Kontingente und Grenzbereiche steuern die Menge an Clusterressourcen, die jeder Mandant verbrauchen kann, während Netzwerkrichtlinien dazu beitragen können, zu verhindern, dass Anwendungen, die in unterschiedlichen Namespaces bereitgestellt werden, miteinander kommunizieren.

Keine dieser Kontrollen verhindert jedoch, dass sich Pods verschiedener Mandanten einen Knoten teilen. Wenn eine stärkere Isolierung erforderlich ist, können Sie mithilfe einer Knotenauswahl, Anti-Affinitätsregeln, and/or Taints und Toleranzen die Planung von Pods verschiedener Mandanten auf separaten Knoten erzwingen, die häufig als Knoten für einzelne Mandanten bezeichnet werden. In einer Umgebung mit vielen Mietern könnte dies ziemlich kompliziert und kostspielig werden.

Kiosk ist ein Open-Source-Projekt, das bei der Implementierung von Soft-Multi-Tenancy helfen kann. Es ist als eine Reihe von CRDs AND-Controllern implementiert, die die folgenden Funktionen bieten:

Loft ist ein kommerzielles Angebot der Entwickler von Kiosk, das die folgenden Funktionen bietet: DevSpace

Es gibt drei Hauptanwendungsfälle, die durch Soft-Multi-Tenancy abgedeckt werden können.

Unternehmensumgebung

Die erste ist eine Unternehmensumgebung, in der den „Mandanten“ teilweise vertraut wird, da es sich um Mitarbeiter, Auftragnehmer oder anderweitig von der Organisation autorisierte Personen handelt. Jeder Mandant ordnet sich in der Regel einer Verwaltungsabteilung wie einer Abteilung oder einem Team zu.

In dieser Art von Umgebung ist in der Regel ein Clusteradministrator für die Erstellung von Namespaces und die Verwaltung von Richtlinien verantwortlich. Sie können auch ein delegiertes Verwaltungsmodell implementieren, bei dem bestimmten Personen die Aufsicht über einen Namespace übertragen wird, sodass sie CRUD-Operationen für Objekte ausführen können, die nicht mit Richtlinien in Verbindung stehen, wie Bereitstellungen, Dienste, Pods, Jobs usw.

Die durch eine Container-Runtime bereitgestellte Isolierung kann innerhalb dieser Einstellung akzeptabel sein, oder sie muss möglicherweise durch zusätzliche Kontrollen für die Pod-Sicherheit erweitert werden. Es kann auch erforderlich sein, die Kommunikation zwischen Diensten in verschiedenen Namespaces einzuschränken, wenn eine strengere Isolierung erforderlich ist.

Kubernetes als Service

Im Gegensatz dazu kann Soft Multi-Tenancy in Einstellungen verwendet werden, in denen Sie Kubernetes als Service (KaaS) anbieten möchten. Bei KaaS wird Ihre Anwendung zusammen mit einer Sammlung von Controllern, die eine Reihe von PaaS-Diensten bereitstellenCRDs , in einem gemeinsam genutzten Cluster gehostet. Mandanten interagieren direkt mit dem Kubernetes-API-Server und dürfen CRUD-Operationen an Objekten ausführen, die nicht den Richtlinien entsprechen. Es gibt auch ein Self-Service-Element, da Mandanten möglicherweise ihre eigenen Namespaces erstellen und verwalten können. In dieser Art von Umgebung wird davon ausgegangen, dass Mandanten nicht vertrauenswürdigen Code ausführen.

Um Mandanten in dieser Art von Umgebung zu isolieren, müssen Sie wahrscheinlich strenge Netzwerkrichtlinien sowie Pod-Sandboxing implementieren. Beim Sandboxing führen Sie die Container eines Pods in einer Mikro-VM wie Firecracker oder in einem User-Space-Kernel aus. Heute können Sie mit EKS Fargate Sandbox-Pods erstellen.

Software-as-a-Service (SaaS)

Der letzte Anwendungsfall für Soft-Multi-Tenancy ist eine Software-as-a-Service (SaaS-) Umgebung. In dieser Umgebung ist jeder Mandant einer bestimmten Instanz einer Anwendung zugeordnet, die innerhalb des Clusters ausgeführt wird. Jede Instanz hat oft ihre eigenen Daten und verwendet separate Zugriffskontrollen, die normalerweise unabhängig von Kubernetes RBAC sind.

Im Gegensatz zu den anderen Anwendungsfällen hat der Mandant in einer SaaS-Umgebung keine direkte Schnittstelle zur Kubernetes-API. Stattdessen ist die SaaS-Anwendung für die Schnittstelle mit der Kubernetes-API verantwortlich, um die erforderlichen Objekte zur Unterstützung der einzelnen Mandanten zu erstellen.

Kubernetes-Konstrukte

In jeder dieser Instanzen werden die folgenden Konstrukte verwendet, um Mandanten voneinander zu isolieren:

Namespaces

Namespaces sind für die Implementierung von Soft-Multi-Tenancy von grundlegender Bedeutung. Sie ermöglichen es Ihnen, den Cluster in logische Partitionen zu unterteilen. Kontingente, Netzwerkrichtlinien, Dienstkonten und andere Objekte, die für die Implementierung von Mehrmandantenfähigkeit erforderlich sind, sind auf einen Namespace beschränkt.

Netzwerkrichtlinien

Standardmäßig dürfen alle Pods in einem Kubernetes-Cluster miteinander kommunizieren. Dieses Verhalten kann mithilfe von Netzwerkrichtlinien geändert werden.

Netzwerkrichtlinien schränken die Kommunikation zwischen Pods mithilfe von Labels oder IP-Adressbereichen ein. In einer Umgebung mit mehreren Mandanten, in der eine strikte Netzwerkisolierung zwischen Mandanten erforderlich ist, empfehlen wir, mit einer Standardregel zu beginnen, die die Kommunikation zwischen Pods verweigert, und einer anderen Regel, die es allen Pods ermöglicht, den DNS-Server zur Namensauflösung abzufragen. Damit können Sie beginnen, tolerantere Regeln hinzuzufügen, die die Kommunikation innerhalb eines Namespaces ermöglichen. Dies kann nach Bedarf weiter verfeinert werden.

Rollenbasierte Zugriffskontrolle (RBAC)

Rollen und Rollenbindungen sind die Kubernetes-Objekte, die zur Durchsetzung der rollenbasierten Zugriffskontrolle (RBAC) in Kubernetes verwendet werden. Rollen enthalten Listen von Aktionen, die gegen Objekte in Ihrem Cluster ausgeführt werden können. Rollenbindungen geben die Personen oder Gruppen an, für die die Rollen gelten. In den Unternehmens- und KaaS-Einstellungen kann RBAC verwendet werden, um die Verwaltung von Objekten durch ausgewählte Gruppen oder Einzelpersonen zu ermöglichen.

Kontingente

Kontingente werden verwendet, um Grenzwerte für Workloads zu definieren, die in Ihrem Cluster gehostet werden. Mit Kontingenten können Sie die maximale Menge an CPU und Arbeitsspeicher angeben, die ein Pod verbrauchen kann, oder Sie können die Anzahl der Ressourcen einschränken, die einem Cluster oder Namespace zugewiesen werden können. Mit Grenzbereichen können Sie für jedes Limit Mindest-, Höchst- und Standardwerte angeben.

Eine Überbelegung von Ressourcen in einem gemeinsam genutzten Cluster ist oft von Vorteil, da Sie so Ihre Ressourcen maximieren können. Ein unbegrenzter Zugriff auf einen Cluster kann jedoch zu einem Mangel an Ressourcen führen, was zu Leistungseinbußen und zum Verlust der Anwendungsverfügbarkeit führen kann. Wenn die Anforderungen eines Pods zu niedrig angesetzt sind und die tatsächliche Ressourcenauslastung die Kapazität des Knotens übersteigt, kommt es auf dem Knoten zu einer CPU- oder Speicherauslastung. In diesem Fall können Pods neu gestartet und vom and/or Knoten entfernt werden.

Um dies zu verhindern, sollten Sie planen, in einer Umgebung mit mehreren Mandanten Kontingente für Namespaces festzulegen, um Mandanten zu zwingen, bei der Planung ihrer Pods auf dem Cluster Anforderungen und Beschränkungen festzulegen. Dadurch wird auch ein potenzieller Denial-of-Service eingedämmt, indem die Menge an Ressourcen begrenzt wird, die ein Pod verbrauchen kann.

Sie können Kontingente auch verwenden, um die Ressourcen des Clusters an die Ausgaben eines Mandanten anzupassen. Dies ist besonders im KaaS-Szenario nützlich.

Priorität und Präemption von Pods

Pod-Priorität und Präemption können nützlich sein, wenn Sie einem Pod im Vergleich zu anderen Pods mehr Bedeutung beimessen möchten. Mit Pod-Priorität können Sie beispielsweise Pods von Kunde A so konfigurieren, dass sie mit einer höheren Priorität als Kunde B ausgeführt werden. Wenn nicht genügend Kapazität verfügbar ist, entfernt der Scheduler die Pods mit niedrigerer Priorität von Kunde B, um die Pods mit höherer Priorität von Kunde A aufzunehmen. Dies kann besonders praktisch in einer SaaS-Umgebung sein, in der Kunden, die bereit sind, eine Prämie zu zahlen, eine höhere Priorität erhalten.

Mildernde Kontrollen

Ihr Hauptanliegen als Administrator einer Umgebung mit mehreren Mandanten besteht darin, zu verhindern, dass sich ein Angreifer Zugriff auf den zugrundeliegenden Host verschafft. Zur Minderung dieses Risikos sollten die folgenden Maßnahmen in Betracht gezogen werden:

Sandbox-Ausführungsumgebungen für Container

Sandboxing ist eine Technik, bei der jeder Container in einer eigenen isolierten virtuellen Maschine ausgeführt wird. Zu den Technologien, die Pod-Sandboxing durchführen, gehören Firecracker und Firekube von Weave.

Weitere Informationen zu den Bemühungen, Firecracker zu einer unterstützten Runtime für EKS zu machen, finden Sie unter 1238496944684597248.html. https://threadreaderapp.com/thread/

Öffnen Sie Policy Agent (OPA) und Gatekeeper

Gatekeeper ist ein Kubernetes-Zugangscontroller, der mit OPA erstellte Richtlinien durchsetzt. Mit OPA können Sie eine Richtlinie erstellen, die Pods von Mandanten auf separaten Instanzen oder mit einer höheren Priorität als andere Mandanten ausführt. Eine Sammlung gängiger OPA-Richtlinien finden Sie im GitHub Repository für dieses Projekt.

Es gibt auch ein experimentelles OPA-Plugin für CoreDNS, mit dem Sie OPA für die von CoreDNS zurückgegebenen Datensätze verwenden können. filter/control

Kyverno

Kyverno ist eine native Policy-Engine von Kubernetes, die Konfigurationen mit Richtlinien als Kubernetes-Ressourcen validieren, mutieren und generieren kann. Kyverno verwendet zur Validierung Overlays im Kustomize-Stil, unterstützt JSON-Patch und strategischen Merge-Patch für Mutationen und kann Ressourcen auf der Grundlage flexibler Trigger über Namespaces hinweg klonen.

Sie können Kyverno verwenden, um Namespaces zu isolieren, die Pod-Sicherheit und andere bewährte Methoden durchzusetzen und Standardkonfigurationen wie Netzwerkrichtlinien zu generieren. Das Repository für dieses Projekt enthält mehrere Beispiele. GitHub Viele andere sind in der Richtlinienbibliothek auf der Kyverno-Website enthalten.

Isolieren von Mandanten-Workloads auf bestimmte Knoten

Die Beschränkung der Mandanten-Workloads auf bestimmte Knoten kann dazu verwendet werden, die Isolation im Soft-Multi-Tenancy-Modell zu erhöhen. Bei diesem Ansatz werden mandantenspezifische Workloads nur auf Knoten ausgeführt, die für die jeweiligen Mandanten bereitgestellt wurden. Um diese Isolierung zu erreichen, werden native Kubernetes-Eigenschaften (Knotenaffinität sowie Taints and Tolerations) verwendet, um bestimmte Knoten für die Pod-Planung ins Visier zu nehmen und zu verhindern, dass Pods von anderen Mandanten auf den mandantenspezifischen Knoten geplant werden.

Teil 1 — Knotenaffinität

Die Kubernetes-Knotenaffinität wird verwendet, um Knoten für die Planung auf der Grundlage von Knotenbezeichnungen als Ziel festzulegen. Mit den Regeln für die Knotenaffinität werden die Pods von bestimmten Knoten angezogen, die den Selektorbegriffen entsprechen. In der folgenden Pod-Spezifikation wird die requiredDuringSchedulingIgnoredDuringExecution Knotenaffinität auf den jeweiligen Pod angewendet. Das Ergebnis ist, dass der Pod auf Knoten abzielt, die mit dem folgenden Schlüssel/Wert gekennzeichnet sind:. node-restriction.kubernetes.io/tenant: tenants-x

...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-restriction.kubernetes.io/tenant
            operator: In
            values:
            - tenants-x
...

Bei dieser Knotenaffinität ist das Label während der Planung erforderlich, aber nicht während der Ausführung. Wenn sich die Labels der zugrunde liegenden Knoten ändern, werden die Pods nicht allein aufgrund dieser Labeländerung entfernt. Die future Planung könnte jedoch beeinträchtigt werden.

Teil 2 — Makel und Toleranzen

Das Anlocken von Pods zu Knoten ist nur der erste Teil dieses dreiteiligen Ansatzes. Damit dieser Ansatz funktioniert, müssen wir verhindern, dass Pods auf Knoten eingeplant werden, für die die Pods nicht autorisiert sind. Um unerwünschte oder nicht autorisierte Pods abzuwehren, verwendet Kubernetes Node-Taints. Taints werden verwendet, um Bedingungen auf Knoten festzulegen, die verhindern, dass Pods geplant werden. Der folgende Taint verwendet ein Schlüssel-Wert-Paar von. tenant: tenants-x

...
    taints:
      - key: tenant
        value: tenants-x
        effect: NoSchedule
...

Angesichts des obigen Knotens dürfen nur Podstaint, die den Taint tolerieren, auf dem Knoten eingeplant werden. Damit autorisierte Pods auf dem Knoten eingeplant werden können, müssen die jeweiligen Pod-Spezifikationen, wie unten dargestellt, ein toleration „A“ für den Taint enthalten.

...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

Pods mit den oben genannten Eigenschaften toleration werden nicht daran gehindert, auf dem Knoten zu planen, zumindest nicht aufgrund dieses spezifischen Fehlers. Taints werden auch von Kubernetes verwendet, um das Pod-Scheduling unter bestimmten Bedingungen vorübergehend zu unterbrechen, z. B. wenn die Knotenressourcen knapp sind. Mit Knotenaffinität und Taints und Toleranzen können wir die gewünschten Pods effektiv an bestimmte Nodes binden und unerwünschte Pods abwehren.

Teil 3 — Policy-basiertes Management für die Knotenauswahl

Es gibt mehrere Tools, mit denen die Knotenaffinität und die Toleranzen von Pod-Spezifikationen verwaltet werden können, einschließlich der Durchsetzung von Regeln in CICD-Pipelines. Die Durchsetzung der Isolation sollte jedoch auch auf Kubernetes-Clusterebene erfolgen. Zu diesem Zweck können Policy-Management-Tools verwendet werden, um eingehende Kubernetes-API-Serveranfragen auf der Grundlage von Anforderungsnutzlasten zu mutieren, sodass die jeweiligen oben genannten Regeln und Toleranzen für die Knotenaffinität angewendet werden.

Beispielsweise können Pods, die für den Tenants-X-Namespace bestimmt sind, mit der richtigen Knotenaffinität und Toleranz versehen werden, um eine Planung auf den Tenants-X-Knoten zu ermöglichen. Mithilfe von Tools zur Richtlinienverwaltung, die mit dem Kubernetes Mutating Admission Webhook konfiguriert wurden, können Richtlinien verwendet werden, um die Spezifikationen für eingehende Pods zu ändern. Die Mutationen fügen die benötigten Elemente hinzu, um die gewünschte Planung zu ermöglichen. Im Folgenden finden Sie ein Beispiel OPA/Gatekeeper für eine Richtlinie, die eine Knotenaffinität hinzufügt.

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: mutator-add-nodeaffinity-pod
  annotations:
    aws-eks-best-practices/description: >-
      Adds Node affinity - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    namespaces: ["tenants-x"]
  location: "spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms"
  parameters:
    assign:
      value:
        - matchExpressions:
          - key: "tenant"
            operator: In
            values:
            - "tenants-x"

Die obige Richtlinie wird auf eine Kubernetes-API-Serveranfrage angewendet, um einen Pod auf den Tenants-x-Namespace anzuwenden. Die Richtlinie fügt die requiredDuringSchedulingIgnoredDuringExecution Knotenaffinitätsregel hinzu, sodass Pods von Knoten mit dem Label angezogen werden. tenant: tenants-x

Eine zweite Richtlinie (siehe unten) fügt die Toleranz derselben Pod-Spezifikation hinzu, wobei dieselben Übereinstimmungskriterien für Ziel-Namespace und Gruppen, Typen und Versionen verwendet werden.

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: mutator-add-toleration-pod
  annotations:
    aws-eks-best-practices/description: >-
      Adds toleration - https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    namespaces: ["tenants-x"]
  location: "spec.tolerations"
  parameters:
    assign:
      value:
      - key: "tenant"
        operator: "Equal"
        value: "tenants-x"
        effect: "NoSchedule"

Die oben genannten Richtlinien sind spezifisch für Pods. Dies ist auf die Pfade zu den mutierten Elementen in den Elementen der Richtlinien zurückzuführen. location Zusätzliche Richtlinien könnten für den Umgang mit Ressourcen geschrieben werden, die Pods erstellen, z. B. Bereitstellungs- und Jobressourcen. Die aufgelisteten Richtlinien und andere Beispiele finden Sie im GitHubBegleitprojekt zu diesem Leitfaden.

Das Ergebnis dieser beiden Mutationen ist, dass die Hülsen vom gewünschten Knoten angezogen werden, während sie gleichzeitig nicht durch den spezifischen Knotenfleck abgestoßen werden. Um das zu überprüfen, können wir uns die Ausgabeschnipsel von zwei kubectl Aufrufen ansehentenant=tenants-x, um die Nodes mit und die Pods im Namespace zu ermitteln. tenants-x

kubectl get nodes -l tenant=tenants-x
NAME
ip-10-0-11-255...
ip-10-0-28-81...
ip-10-0-43-107...

kubectl -n tenants-x get pods -owide
NAME                                  READY   STATUS    RESTARTS   AGE   IP            NODE
tenant-test-deploy-58b895ff87-2q7xw   1/1     Running   0          13s   10.0.42.143   ip-10-0-43-107...
tenant-test-deploy-58b895ff87-9b6hg   1/1     Running   0          13s   10.0.18.145   ip-10-0-28-81...
tenant-test-deploy-58b895ff87-nxvw5   1/1     Running   0          13s   10.0.30.117   ip-10-0-28-81...
tenant-test-deploy-58b895ff87-vw796   1/1     Running   0          13s   10.0.3.113    ip-10-0-11-255...
tenant-test-pod                       1/1     Running   0          13s   10.0.35.83    ip-10-0-43-107...

Wie wir den obigen Ausgaben entnehmen können, sind alle Pods auf den mit beschrifteten Knoten geplant. tenant=tenants-x Einfach ausgedrückt, werden die Pods nur auf den gewünschten Knoten ausgeführt und die anderen Pods (ohne die erforderliche Affinität und Toleranzen) nicht. Die Workloads der Mandanten sind effektiv isoliert.

Ein Beispiel für eine mutierte Pod-Spezifikation finden Sie unten.

apiVersion: v1
kind: Pod
metadata:
  name: tenant-test-pod
  namespace: tenants-x
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: tenant
            operator: In
            values:
            - tenants-x
...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

In den obigen Beispielen haben wir Richtlinien verwendet, die für OPA/Gatekeeper geschrieben wurden. Es gibt jedoch auch andere Tools zur Richtlinienverwaltung, die unseren Anwendungsfall der Knotenauswahl behandeln. Diese Kyverno-Richtlinie könnte beispielsweise verwendet werden, um die Knotenaffinitätsmutation zu behandeln.

Referenzen

Harte Mehrmandantenfähigkeit

Hard-Multi-Tenancy kann implementiert werden, indem für jeden Mandanten separate Cluster bereitgestellt werden. Dies sorgt zwar für eine sehr starke Isolierung zwischen den Mandanten, hat jedoch mehrere Nachteile.

Erstens kann dieser Ansatz bei vielen Mietern schnell teuer werden. Sie müssen nicht nur die Kosten für die Steuerungsebene für jeden Cluster bezahlen, Sie können auch keine Rechenressourcen zwischen Clustern gemeinsam nutzen. Dies führt letztendlich zu einer Fragmentierung, bei der eine Teilmenge Ihrer Cluster nicht ausgelastet ist, während andere überlastet sind.

Zweitens müssen Sie wahrscheinlich spezielle Tools kaufen oder entwickeln, um all diese Cluster zu verwalten. Mit der Zeit kann die Verwaltung von Hunderten oder Tausenden von Clustern einfach zu umständlich werden.

Schließlich wird die Erstellung eines Clusters pro Mandant im Vergleich zur Erstellung eines Namespaces langsam sein. Dennoch kann in stark regulierten Branchen oder in SaaS-Umgebungen, in denen eine starke Isolierung erforderlich ist, ein Hard-Tenancy-Ansatz erforderlich sein.

Künftige Richtungen

Die Kubernetes-Community hat die aktuellen Schwächen von Soft-Multi-Tenancy und die damit verbundenen Herausforderungen erkannt. Die Multi-Tenancy Special Interest Group (SIG) versucht, diese Mängel durch mehrere Inkubationsprojekte zu beheben, darunter Hierarchical Namespace Controller (HNC) und Virtual Cluster.

Der HNC-Vorschlag (KEP) beschreibt eine Möglichkeit, über- und untergeordnete Beziehungen zwischen Namespaces mithilfe der [Richtlinie] Objektvererbung herzustellen und Mandantenadministratoren die Möglichkeit zu bieten, Unter-Namespaces zu erstellen.

Der Vorschlag für einen virtuellen Cluster beschreibt einen Mechanismus zur Erstellung separater Instanzen der Steuerungsebenendienste, einschließlich des API-Servers, des Controller-Managers und des Schedulers, für jeden Mandanten innerhalb des Clusters (auch bekannt als „Kubernetes on Kubernetes“).

Der Vorschlag für Multi-Tenancy Benchmarks enthält Richtlinien für die gemeinsame Nutzung von Clustern mithilfe von Namespaces zur Isolierung und Segmentierung sowie ein Befehlszeilentool kubectl-mtb zur Überprüfung der Einhaltung der Richtlinien.

Verwaltungstools und Ressourcen für mehrere Cluster