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, wollen 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 erwecken können. Beispielsweise können Namespaces und Role-based 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. Dies liegt daran, dass ein Angreifer, der Zugriff auf einen Host innerhalb des Clusters erlangt, alle Secrets und Volumes abrufen kannConfigMaps, die auf diesem Host gemountet sind. Sie könnten sich auch als Kubelet ausgeben, was es ihnen ermöglichen würde, die Attribute des Knotens zu manipulieren, der sich seitlich innerhalb des Clusters and/or bewegt.

In den folgenden Abschnitten wird erklärt, wie Sie die Mandantenisolierung implementieren und gleichzeitig die Risiken mindern, die mit der Verwendung eines Single-Tenant-Orchestrators wie Kubernetes verbunden sind.

Weiche Mehrmandantenfähigkeit

Bei der weichen Mehrmandantenfähigkeit verwenden Sie native Kubernetes-Konstrukte, z. B. Namespaces, Rollen und Rollenbindungen sowie Netzwerkrichtlinien, um eine logische Trennung zwischen den Mandanten herzustellen. RBAC kann beispielsweise verhindern, dass Mandanten auf die Ressourcen des jeweils anderen zugreifen oder sich gegenseitig 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 verschiedenen Namespaces bereitgestellt werden, miteinander kommunizieren.

Keine dieser Steuerungen verhindert jedoch, dass Pods verschiedener Mandanten einen Knoten gemeinsam nutzen. Wenn eine stärkere Isolierung erforderlich ist, können Sie eine Knotenauswahl, Anti-Affinitätsregeln, and/or Taints und Toleranzen verwenden, um zu erzwingen, dass Pods verschiedener Mandanten auf separaten Knoten geplant werden. Diese werden oft als Knoten für einzelne Mandanten bezeichnet. In einer Umgebung mit vielen Mandanten könnte dies ziemlich kompliziert und unerschwinglich werden.

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

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

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

Einstellung für Unternehmen

Die erste ist in einer Unternehmensumgebung, in der den „Mietern“ ein gewisses Vertrauen entgegengebracht wird, da sie Mitarbeiter oder Auftragnehmer sind oder anderweitig von der Organisation autorisiert wurden. Jeder Mandant gehört in der Regel einer Verwaltungsabteilung an, z. B. einer Abteilung oder einem Team.

In einer solchen Umgebung ist in der Regel ein Clusteradministrator für die Erstellung von Namespaces und die Verwaltung von Richtlinien verantwortlich. Sie können auch ein Modell der delegierten Verwaltung implementieren, bei dem bestimmte Personen die Aufsicht über einen Namespace erhalten, sodass sie CRUD-Operationen für Objekte ausführen können, die nichts mit Richtlinien zu tun haben, 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 Steuerelemente 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 Dienst

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

Um Mandanten in einer solchen Umgebung zu isolieren, müssen Sie wahrscheinlich strenge Netzwerkrichtlinien sowie Pod-Sandboxing implementieren. Beim Sandboxing werden die Container eines Pods in einer Micro-VM wie Firecracker oder in einem User-Space-Kernel ausgeführt. Heute können Sie mit EKS Fargate Sandbox-Pods erstellen.

Software-as-a-Service (SaaS)

Der letzte Anwendungsfall für Soft-Multi-Tenancy liegt in einer 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 ist der Tenant in einer SaaS-Einstellung nicht direkt mit der Kubernetes-API verbunden. Stattdessen ist die SaaS-Anwendung für die Schnittstelle zur 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 grundlegend für die Implementierung von Soft-Multi-Tenancy. Sie ermöglichen es Ihnen, den Cluster in logische Partitionen zu unterteilen. Kontingente, Netzwerkrichtlinien, Dienstkonten und andere Objekte, die für die Implementierung der Mehrmandantenfähigkeit erforderlich sind, sind einem Namespace zugeordnet.

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 weiteren Regel, die es allen Pods ermöglicht, den DNS-Server zur Namensauflösung abzufragen. Damit können Sie beginnen, weitere freizügige Regeln hinzuzufügen, die die Kommunikation innerhalb eines Namespaces ermöglichen. Dies kann bei Bedarf weiter verfeinert werden.

Role-based 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 für 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 Gesamtmenge an CPU und Arbeitsspeicher begrenzen, die in einem Namespace verbraucht werden kann, oder die Anzahl der Objekte begrenzen, die erstellt werden können. Grenzbereiche ermöglichen es Ihnen, die Mindest-, Höchst- und Standardwerte für CPU und Arbeitsspeicher für einzelne Pods und Container innerhalb eines Namespace zu deklarieren.

Das Überbeanspruchen von Ressourcen in einem gemeinsam genutzten Cluster ist oft von Vorteil, da Sie so Ihre Ressourcen optimal nutzen können. 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 eingestellt sind und die tatsächliche Ressourcenauslastung die Kapazität des Knotens übersteigt, kommt es auf dem Knoten zu einer Belastung der CPU oder des Speichers. In diesem Fall werden die Pods möglicherweise neu gestartet und vom and/or Knoten entfernt.

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 im Cluster Anforderungen und Grenzwerte anzugeben. Außerdem wird so ein potenzieller Denial-of-Service eingedämmt, indem die Menge an Ressourcen, die ein Pod verbrauchen kann, begrenzt wird.

Sie können auch Kontingente verwenden, um die Ressourcen des Clusters so aufzuteilen, dass sie den Ausgaben eines Mandanten entsprechen. Dies ist besonders im KaaS-Szenario nützlich.

Pod-Priorität und Präemption

Pod-Priorität und Präemption können nützlich sein, wenn Sie einem Pod im Vergleich zu anderen Pods eine höhere 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 in einer SaaS-Umgebung praktisch sein, in der Kunden, die bereit sind, eine Prämie zu zahlen, eine höhere Priorität erhalten.

Abschwächende Kontrollen

Ihr Hauptanliegen als Administrator einer Umgebung mit mehreren Mandanten besteht darin, zu verhindern, dass ein Angreifer Zugriff auf den zugrunde liegenden Host erhält. 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 auf einer eigenen isolierten virtuellen Maschine ausgeführt wird. Zu den Technologien, die Pod-Sandboxing durchführen, gehört Firecracker.

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

Öffnen Sie den Policy Agent (OPA) Gatekeeper &

Gatekeeper ist ein Kubernetes-Zugangscontroller, der mit OPA erstellte Richtlinien durchsetzt. https://www.openpolicyagent.org/ Mit OPA können Sie eine Richtlinie erstellen, die Pods von Mandanten auf separaten Instanzen oder mit einer höheren Priorität als bei anderen 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 Kustomize-style Overlays zur Validierung, unterstützt JSON-Patch und strategischen Merge-Patch für Mutationen und kann Ressourcen auf der Grundlage flexibler Trigger namespace-übergreifend 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 https://github.com/aws/aws-eks-best-practices/tree/master/policies/kyverno Viele andere sind in der Richtlinienbibliothek auf der Kyverno-Website enthalten.

Isolierung der Mandanten-Workloads auf bestimmte Knoten

Das Beschränken der Mandanten-Workloads auf die Ausführung auf bestimmten Knoten kann verwendet werden, um die Isolierung 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 werden. Um diese Isolierung zu erreichen, werden native Kubernetes-Eigenschaften (Knotenaffinität sowie Taints und Toleranzen) verwendet, um für die Pod-Planung auf bestimmte Knoten abzuzielen und zu verhindern, dass Pods von anderen Mandanten auf den mandantenspezifischen Knoten geplant werden.

Teil 1 — Node-Affinität

Die Kubernetes-Knotenaffinität wird verwendet, um Knoten für die Planung auf der Grundlage von Knotenbezeichnungen anzuvisieren. Mit den Regeln für die Knotenaffinität werden die Pods zu bestimmten Knoten hingezogen, die den Selektorbedingungen entsprechen. In der folgenden Pod-Spezifikation wird die requiredDuringSchedulingIgnoredDuringExecution Node-Affinität auf den jeweiligen Pod angewendet. Das Ergebnis ist, dass der Pod auf Knoten abzielt, die mit den folgenden Bezeichnungen versehen sind key/value: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 zukünftige Planung könnte jedoch beeinträchtigt werden.

Teil 2 — Makel und Toleranzen

Das Anziehen von Pods an Knoten ist nur der erste Teil dieses dreiteiligen Ansatzes. Damit dieser Ansatz funktioniert, müssen wir verhindern, dass Pods aus der Planung auf Knoten verteilt werden, für die die Pods nicht autorisiert sind. Um unerwünschte oder nicht autorisierte Pods abzuwehren, verwendet Kubernetes Node-Taints. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Taints werden verwendet, um Nodes mit Bedingungen zu versehen, die verhindern, dass Pods geplant werden. Das folgende Taint verwendet ein Schlüssel-Wert-Paar von. tenant: tenants-x

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

Angesichts des obigen Knotens taint dürfen nur Pods, die den Taint tolerieren, auf dem Knoten geplant werden. Damit autorisierte Pods auf dem Knoten eingeplant werden können, müssen die jeweiligen Pod-Spezifikationen die Angabe „A toleration to the Taint“ enthalten (siehe unten).

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

Pods mit den oben genannten Bedingungen toleration werden nicht daran gehindert, auf dem Knoten zu planen, zumindest nicht aufgrund dieses speziellen Fehlers. Taints werden auch von Kubernetes verwendet, um die Pod-Planung unter bestimmten Bedingungen, wie z. B. unter Ressourcendruck auf dem Knoten, vorübergehend zu beenden. Mithilfe von Node-Affinität sowie Taints und Toleranzen können wir die gewünschten Pods effektiv an bestimmte Knoten binden und unerwünschte Pods abwehren.

Teil 3 — Verwaltung Policy-based für die Knotenauswahl

Es gibt mehrere Tools, mit denen Sie die Knotenaffinität und die Toleranzen von Pod-Spezifikationen verwalten können, einschließlich der Durchsetzung von Regeln in CICD-Pipelines. Die Durchsetzung der Isolation sollte jedoch auch auf Kubernetes-Cluster-Ebene erfolgen. Zu diesem Zweck können Tools zur Richtlinienverwaltung verwendet werden, um eingehende Kubernetes-API-Serveranfragen auf der Grundlage von Anforderungsnutzlasten so zu modifizieren, dass die oben genannten Regeln und Toleranzen für die Node-Affinitä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 die 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 erforderlichen Elemente hinzu, um die gewünschte Planung zu ermöglichen. Eine OPA/Gatekeeper Beispielrichtlinie, die eine Node-Affinität hinzufügt, ist unten zu sehen.

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-Serveranforderung 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 den Ziel-Namespace sowie für 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. Das liegt an den Pfaden zu den mutierten Elementen in den Elementen der Richtlinien. location Zusätzliche Richtlinien könnten für den Umgang mit Ressourcen, die Pods erstellen, wie Bereitstellungs- und Jobressourcen, geschrieben werden. Die aufgeführten Richtlinien und andere Beispiele finden Sie im GitHub Begleitprojekt zu diesem Handbuch.

Das Ergebnis dieser beiden Mutationen ist, dass die Schoten vom gewünschten Knoten angezogen werden, während sie gleichzeitig nicht durch den spezifischen Knotenfleck abgestoßen werden. Um dies zu überprüfen, können wir uns die Ausgabeschnipsel zweier kubectl Aufrufe ansehen, mit denen die Knoten beschriftet wurdentenant=tenants-x, und die Pods im Namespace abgerufen werden. 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 Knoten geplant, die mit gekennzeichnet sind. tenant=tenants-x Einfach ausgedrückt, die Pods laufen nur auf den gewünschten Knoten und die anderen Pods (ohne die erforderliche Affinität und Toleranzen) nicht. Die Arbeitslasten der Mandanten sind effektiv isoliert.

Ein Beispiel für eine mutierte Pod-Spezifikation ist unten zu sehen.

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 ebenfalls behandeln. Diese Kyverno-Richtlinie könnte beispielsweise verwendet werden, um die Mutation der Knotenaffinität zu behandeln.

Referenzen

Harte Mehrmandantenfähigkeit

Eine harte Mehrmandantenfähigkeit 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, wenn Sie viele Mieter haben, kann dieser Ansatz schnell teuer werden. Sie müssen nicht nur für die Kosten der Steuerungsebene für jeden Cluster aufkommen, Sie werden auch nicht in der Lage sein, Rechenressourcen zwischen Clustern gemeinsam zu nutzen. Dies führt letztendlich zu einer Fragmentierung, bei der ein Teil Ihrer Cluster nicht ausgelastet ist, während andere überlastet sind.

Zweitens müssen Sie wahrscheinlich spezielle Tools kaufen oder bauen, 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 das Erstellen eines Clusters pro Mandant im Vergleich zum Erstellen eines Namespaces langsam vonstatten gehen. Dennoch kann in stark regulierten Branchen oder in SaaS-Umgebungen, in denen eine starke Isolierung erforderlich ist, ein Hardtenancy-Ansatz erforderlich sein.

Künftige Richtungen

Die Kubernetes-Community hat die aktuellen Mängel der weichen Mehrmandantenfähigkeit und die Herausforderungen erkannt, die eine harte Mehrmandantenfähigkeit mit sich bringt. 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, Eltern-Kind-Beziehungen zwischen Namespaces mithilfe der [Policy] -Objektvererbung herzustellen. Außerdem wird Mandantenadministratoren die Möglichkeit gegeben, Unternamespaces zu erstellen.

Der Virtual Cluster-Vorschlag beschreibt einen Mechanismus zur Erstellung separater Instanzen der Control-Plane-Dienste, 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 Multi-Tenancy Benchmarks-Vorschlag 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. https://github.com/kubernetes-sigs/multi-tenancy/blob/master/benchmarks/kubectl-mtb/README.md

Multi-cluster Management-Tools und Ressourcen