Best Practices für mehrere Mandanten

Best Practice: RBAC-Autorisierer für zusätzlichen fein granulierten Zugriff verwenden

Wir empfehlen, dass Sie den Kubernetes-RBAC-Autorisierer verwenden, um eine fein granulierte Zugriffskontrolle für Benutzer auf bestimmten Clustern über Kubernetes-RBAC-Rollen und -clusterroles durchzusetzen.

Eine Kubernetes-RBAC-Rolle ist eine Gruppe von Berechtigungen. Beispiel: Eine Rolle kann Leseberechtigungen und Listenberechtigungen für Pods enthalten. Eine Kubernetes-RBAC-clusterrole funktioniert genauso wie eine Rolle, kann jedoch überall im Cluster verwendet werden. Ein Kubernetes-RBAC-Rlebinding ordnet eine Rolle einem Benutzer oder einer Gruppe zu und erteilt dem Benutzer oder der Gruppe die Berechtigungen dieser Rolle für Ressourcen in diesem Namespace. Ebenso ordnet ein Kubernetes-RBAC-clusterrolebinding eine clusterrole einem Benutzer oder einer Gruppe zu, wodurch dem Benutzer oder der Gruppe im gesamten Cluster die Berechtigungen dieser clusterrole erteilt werden.

Siehe Info zu Access Control und Kubernetes Engine (OKE).

Best Practice: Verwenden Sie Namespaces, wenn mehrere Cluster keine Option sind

Es wird empfohlen, separate Namespaces für jedes Team zu erstellen, wenn ein Kubernetes-Cluster groß ist (mit Hunderten von Knoten) und mehrere Teams am Cluster arbeiten. Beispiel: Sie erstellen in der Regel verschiedene Namespaces für Entwicklungs-, Test- und Produktionsteams.

Ein Kubernetes-Cluster kann in Namespaces unterteilt werden, um die Ressourcen des Clusters zwischen mehreren Benutzern aufzuteilen. Anfänglich weist ein Cluster die folgenden Namespaces auf:

• "default" für Ressourcen ohne anderen Namespace
• "kube-system" für Ressourcen, die vom Kubernetes-System erstellt werden
• "kube-node-lease" für ein Leasingobjekt pro Knoten, um die Knotenverfügbarkeit zu bestimmen
• "kube-public" wird im Allgemeinen für Ressourcen verwendet, die im ganzen Cluster zugänglich sein müssen

Namespaces spielen eine wichtige Rolle für die Sicherheit eines Clusters, wenn mehrere Benutzer und Teams an demselben Cluster arbeiten.

Siehe Namespaces in der Kubernetes-Dokumentation.

Best Practice: Mit einer Namensraum-Benennungskonvention können Sie das Deployment in mehreren Umgebungen vereinfachen

Es wird empfohlen, eine Namespace-Benennungskonvention einzurichten und zu verwenden, mit der Sie Deployments in mehreren Umgebungen erstellen und in verschiedenen Clustern gehostet werden können.

Beispiel: Vermeiden Sie es, Umgebungsnamen in Namespace-Namen aufzunehmen. Verwenden Sie stattdessen denselben Namespace-Namen für alle Umgebungen. Wenn Sie denselben Namespace-Namen verwenden, können Sie in allen Umgebungen dieselben Konfigurationsdateien verwenden. Außerdem müssen Sie keine für jede Umgebung spezifische Konfigurationsdatei erstellen.

Siehe Namespaces in der Kubernetes-Dokumentation.

Best Practice: Workloads in dedizierten Knotenpools isolieren

Es wird empfohlen, eine starke Infrastrukturisolation zu implementieren, indem Sie dedizierte Knotenpools verwenden, um Mandanten zu isolieren. Beispiel: Bei einer Anwendung mit mehreren Mandanten, die jeden Mandanten auf einer dedizierten Compute-Ressource ausführt, getrennt durch Knotenpools.

Bei vielen mehrmandantenfähigen SaaS-Anwendungen müssen Mandanten auf dedizierten Compute-Ressourcen ausgeführt werden. Außerdem muss der Netzwerktraffic über Sicherheitslisten pro Mandant kontrolliert werden können. Die beiden gängigsten Strategien für ein solches SaaS-Anwendungsmandantenmodell sind:

• Nutzen Sie Namespaces und Netzwerk-Policys, um Mandanten zu isolieren.
• Nutzen Sie dedizierte Compute-/Sicherheitslisten, um Mandanten zu isolieren.

Best Practice: Ressourcenquoten durchsetzen

Es wird empfohlen, Kubernetes-Ressourcenquotas zu erstellen und durchzusetzen, um sicherzustellen, dass alle Mandanten, die ein Cluster gemeinsam verwenden, fairen Zugriff auf die Clusterressourcen haben.

Erstellen Sie eine Ressourcen-Quota für jeden Namespace, basierend auf der Anzahl der von jedem Mandanten bereitgestellten Pods und der für jeden Pod erforderlichen Arbeitsspeicher- und CPU-Menge.

Beispiel: Die folgende ResourceQuota-Konfiguration:

• ermöglicht Pods im Namespace tenant-a, bis zu 16 CPUs und bis zu 64 GB Arbeitsspeicher anzufordern
• begrenzt die maximale CPU-Anzahl auf 32 und den maximalen Arbeitsspeicher auf 72 GB

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Siehe Ressourcenquoten in der Kubernetes-Dokumentation.

Best Practice: Worker-Knoten und Pods automatisch skalieren

Es wird empfohlen, dass Sie die automatische Skalierung aktivieren, um den Mandantenbedarf zu decken, indem Sie die Knotenpools und Pods in einem Cluster automatisch skalieren.

Die automatische Skalierung stellt sicher, dass das System weiterhin reaktionsschnell und fehlerfrei aussieht, selbst wenn verschiedene Mandanten schwere Workloads in ihren eigenen Namespaces bereitstellen. Mit Autoscaling kann das System auch auf Ausfälle reagieren.

Siehe Kubernetes Cluster Autoscaler verwenden, Kubernetes Horizontal pod Autoscaler verwenden.

Best Practice: Flexiblen Load Balancer verwenden

Es wird empfohlen, eine flexible Ausprägung für Oracle Cloud Infrastructure-Load Balancer anzugeben, um den Mandantenbedarf zu decken.

Mit einer flexiblen Ausprägung für OCI-Load Balancer, die Kubernetes Engine für Kubernetes-Services des Typs LoadBalancer bereitstellt, können Sie:

• Vermeiden Sie die Einschränkungen, die mit Load-Balancer-Ausprägungen mit fester Bandbreite verbunden sind, da Sie Mindest- und Höchstwerte angeben können, um einen oberen und unteren Größenbereich für die Bandbreitenausprägung des Load Balancers zu erstellen.
• Vermeiden Sie die Einschränkungen bei der Skalierung, die nur auf allgemeinen Trafficmustern basieren.

Siehe Flexible Load-Balancer-Ausprägungen angeben.

Best Practice: Netzwerksteuerung zentralisieren (optional)

Es wird empfohlen, die zentrale Kontrolle über Netzwerkressourcen mit einem dynamischen Routinggateway (DRG) und (optional) einem Hub-VCN aufrechtzuerhalten.

Mit einem DRG können Sie Traffic über eine zentrale virtuelle Netzwerk-Appliance weiterleiten.

Wenn Sie optional ein Hub-VCN erstellen, können Sie das Hauptrouting und die Firewalls konfigurieren. Ressourcen in einem Hub-VCN können über interne IPs sicher und effizient mit anderen VCNs kommunizieren. Mit einem Hub-VCN und IAM wird sichergestellt, dass nur Netzwerkadministratoren Zugriff auf das zentrale VCN haben. Durch diese Trennung können Sie das Least-Privilege-Prinzip implementieren.

Beispiel:

• Das zentrale Netzwerkteam kann das Netzwerk ohne Berechtigungen für den Zugriff auf Kubernetes-Cluster (die sich in Spoke-VCNs befinden) verwalten.
• Die Kubernetes Engine-Administratoren können Cluster verwalten, ohne über Berechtigungen zum Bearbeiten des gemeinsamen Netzwerks zu verfügen.

Siehe Traffic über eine zentrale Netzwerk-Virtual-Appliance weiterleiten.