Architektur

Aufgrund dieser gemeinsamen Infrastruktur ist die CNI dieselbe wie die, die im Host-Cluster konfiguriert ist. Das Gleiche gilt für den verfügbaren Speicher, wo die Speicherklassen und Volumes die des Host-Clusters sind.

Um die benötigte Isolation zu gewährleisten, nutzt K3k Netzwerk-Richtlinien.

Im shared Modus nutzt K3k die 'ResourceQuotas' und 'LimitRanges' von Kubernetes, um die Ressourcenteilung zu verwalten und Grenzen durchzusetzen. Da alle Arbeitslasten des virtuellen Clusters im selben Namespace des Host-Clusters ausgeführt werden, werden ResourceQuotas auf diesen Namespace angewendet, um die insgesamt von einem virtuellen Cluster verbrauchten Ressourcen zu begrenzen. LimitRanges werden verwendet, um Standardressourcenanforderungen und -grenzen für Pods festzulegen, um sicherzustellen, dass Arbeitslasten angemessene Ressourcen zugewiesen bekommen, auch wenn sie diese nicht ausdrücklich angeben.

Jeder Pod in einem virtuellen Cluster erhält einen eindeutigen Namen, der den Pod-Namen, den Namespace und den Cluster-Namen umfasst. Dies verhindert Namenskonflikte im gemeinsamen Namespace des Host-Clusters.

Es ist wichtig zu verstehen, dass ResourceQuotas auf Namespace-Ebene angewendet werden. Das bedeutet, dass alle Pods innerhalb eines virtuellen Clusters dasselbe Kontingent teilen. Während dies insgesamt Grenzen für den virtuellen Cluster festlegt, bedeutet es auch, dass die Ressourcenzuteilung dynamisch ist. Wenn eine Arbeitslast ihre vollständige Ressourcenzuteilung nicht nutzt, können andere Arbeitslasten innerhalb des gleichen virtuellen Clusters diese Ressourcen nutzen, auch wenn sie zu unterschiedlichen Implementierungen oder Diensten gehören.

Dieses dynamische Teilen kann sowohl ein Vorteil als auch eine Herausforderung sein. Es ermöglicht eine effiziente Ressourcennutzung, kann jedoch auch zu unvorhersehbarer Leistung führen, wenn Arbeitslasten unterschiedliche Ressourcenanforderungen haben. Darüber hinaus macht dieser Ansatz es schwierig, eine strikte Ressourcenisolation zwischen Arbeitslasten innerhalb desselben virtuellen Clusters zu garantieren.

Die Isolation zwischen virtuellen Clustern im geteilten Modus beruht stark auf Kubernetes-Netzwerkrichtlinien. Netzwerkrichtlinien definieren Regeln, die den Netzwerkverkehr steuern, der zu und von Pods erlaubt ist. K3k konfiguriert Netzwerkrichtlinien, um sicherzustellen, dass Pods in einem virtuellen Cluster nicht mit Pods in anderen virtuellen Clustern oder mit Pods im Host-Cluster selbst kommunizieren können, was eine starke Grundlage für die Netzwerkisolierung bietet.

Während Netzwerkrichtlinien robuste Isolationsfähigkeiten bieten, ist es wichtig, ihre Eigenschaften zu verstehen:

K3k nutzt auch die Kubernetes Pod Security Admission (PSA), um Sicherheitsrichtlinien innerhalb virtueller Cluster basierend auf den Pod Security Standards (PSS) durchzusetzen. PSS definieren verschiedene Sicherheitsstufen für Pods und beschränken, welche Aktionen Pods ausführen können. Durch die Konfiguration von PSA zur Durchsetzung einer bestimmten PSS-Stufe (zum Beispiel baseline oder restricted) für einen virtuellen Cluster stellt K3k sicher, dass Pods den festgelegten Sicherheitsbestimmungen entsprechen und verhindert, dass sie privilegierte Funktionen nutzen oder potenziell gefährliche Operationen ausführen.

Wichtige Aspekte der PSA-Integration umfassen:

Die Architektur des geteilten Modus ist mit Blick auf die Sicherheit konzipiert. K3k verwendet mehrere Schichten von Sicherheitskontrollen, einschließlich Netzwerkrichtlinien und PSA, um virtuelle Cluster und den Host-Cluster zu schützen. Während das geteilte Namespace-Modell eine sorgfältige Konfiguration und Verwaltung erfordert, bieten diese Kontrollen eine robuste Sicherheitsgrundlage für den Betrieb von Workloads in einer Multi-Tenant-Umgebung. K3k bewertet und verbessert kontinuierlich seine Sicherheitsmechanismen, um sich entwickelnden Bedrohungen zu begegnen und das höchste Schutzniveau für seine Benutzer zu gewährleisten.

Virtuelle Cluster im virtual Modus haben jeweils ihre eigene unabhängige Netzwerkkonfiguration, die von ihren jeweiligen K3s-Servern verwaltet wird. Jeder virtuelle Cluster führt sein eigenes CNI-Plugin aus, das innerhalb seines K3s-Servers konfiguriert ist und vollständige Netzwerktrennung von anderen virtuellen Clustern und dem Host-Cluster bietet. Während die virtuellen Cluster-Netzwerke letztendlich auf der Netzwerk-Infrastruktur des Host-Clusters operieren, sind die Netzwerkkonfiguration und das Datenverkehrsmanagement völlig getrennt.

Die Ressourcenteilung im virtual Modus wird verwaltet, indem Ressourcenlimits auf die Pods angewendet werden, die den virtuellen Cluster bilden (sowohl der K3s-Server-Pod als auch die K3s-Agent-Pods). Jeder Pod erhält eine bestimmte Menge an CPU, Speicher und anderen Ressourcen. Die Arbeitslasten, die innerhalb des virtuellen Clusters laufen, nutzen dann diese zugewiesenen Ressourcen. Das bedeutet, dass der virtuelle Cluster als Ganzes über einen definierten Ressourcenpool verfügt, der durch die Limits seiner Bestandteilpods bestimmt wird.

Dieser Ansatz bietet eine klare und direkte Möglichkeit, die verfügbaren Ressourcen für jeden virtuellen Cluster zu steuern. Es erfordert jedoch eine sorgfältige Ressourcenplanung, um sicherzustellen, dass jeder virtuelle Cluster über ausreichende Kapazität für seine Arbeitslasten verfügt.

Der virtual Modus bietet aufgrund der für jeden virtuellen Cluster bereitgestellten dedizierten K3s-Cluster eine starke Isolation. Da jeder virtuelle Cluster seine eigene separate Steuerungsebene und Arbeitsknoten betreibt, sind die Arbeitslasten effektiv voneinander und vom Host-Cluster isoliert. Diese Architektur minimiert das Risiko, dass ein virtueller Cluster andere oder den Host-Cluster beeinflusst.

Die Sicherheit im virtual Modus profitiert von der inhärenten Isolation, die durch die separaten K3s-Cluster bereitgestellt wird. Dennoch gelten weiterhin die besten Sicherheitspraktiken von Kubernetes, und K3k betont einen mehrschichtigen Sicherheitsansatz. Während die K3s-Server-Pods oft mit erhöhten Rechten laufen (aufgrund der Natur ihrer Funktion, die den Zugriff auf Systemressourcen erfordert), empfiehlt K3k, diese Rechte so weit wie möglich zu minimieren und das Prinzip der geringsten Privilegien einzuhalten. Dies kann erreicht werden, indem die erforderlichen Fähigkeiten sorgfältig konfiguriert werden, anstatt sich auf den vollständigen privileged Modus zu verlassen. Weitere Informationen zu den besten Sicherheitspraktiken von K3s finden Sie in der offiziellen K3s-Dokumentation: https://docs.k3s.io/security (Dieser Link bietet allgemeine Sicherheitsrichtlinien, einschließlich Diskussionen über Fähigkeiten und andere relevante Themen).

Derzeit birgt die Sicherheit im virtuellen Modus das Risiko einer Privilegieneskalation, da die Server-Pods aufgrund der Natur ihrer Funktion mit erhöhten Rechten laufen, die den Zugriff auf Systemressourcen erfordern.