Überlegungen zum Pod-Sandkasten für Azure Kubernetes Service (AKS)

Das Pod-Sandboxing auf Azure Kubernetes Service (AKS) umfasst Ressourcenverwaltung, Speicherverwaltung, CPU-Verwaltung und Sicherheitsaspekte.

Ressourcenverwaltung beim Pod-Sandboxing

Überprüfen Sie diese Überlegungen, wenn Sie Ressourcen für eine Bereitstellung angeben, insbesondere für große oder ressourcenabhängige Workloads.

Kata-Komponenten

Eine Kata-Bereitstellung umfasst Komponenten, die auf dem AKS-Knoten und Komponenten ausgeführt werden, die innerhalb des virtuellen Podcomputers (VM) ausgeführt werden. Diese Host- und Gastteilung bestimmt, wie Arbeitsspeicher und CPU-Auslastung berücksichtigt werden.

Speicherverwaltung in Pod-Sandboxing

Legen Sie den Speichergrenzwert der Pod-VM hoch genug fest, um Ihre Workload- und Kata-Gastkomponenten zu unterstützen, ohne nicht genutzten Arbeitsspeicher zu übernehmen.

Größe des VM-Speichers der Pod-VM

Jede Pod-VM bekommt Arbeitsspeicher für die Workload sowie alle Kata-Gastkomponenten. Schließen Sie Arbeitsspeicher über den erwarteten Workloadverbrauch für Gastkomponenten wie den Kata-Agent und den VM-Kernel hinaus ein. Die Referenzverwendungswerte für typische Speicherwerte finden Sie unter .See the reference usage values for typical memory values.

Der Kubernetes-Pod-Speichergrenzwert bestimmt die Größe des VM-Arbeitsspeichers des Pods. Ändern Sie das Speicherlimit des Pods, um die Speichergröße der Pod-VM zu ändern.

RuntimeClass Der Speicher-Overhead nimmt typischerweise mit der Speichergröße der Pod-VM zu.

RuntimeClass Arbeitsspeicheraufwand

Workloads mit Pod-Sandboxing verfügen über eine standardmäßige Kata RuntimeClass (kata-vm-isolation), die Standardwerte für den Ressourcen-Overhead enthält. Richten Sie für eine feinere Steuerung von Ressourcenkontingenten eine benutzerdefinierte RuntimeClass mit spezifischen Ressourcen-Aufwänden ein. Der Pod-Speichergrenzwert hat die Größe des gastseitigen Arbeitsspeichers, der für den virtuellen Pod verfügbar ist. RuntimeClass Der Overhead reserviert Knotenkapazität für hostseitige Kata-Komponenten und muss den erwarteten Speicherverbrauch von Gastkomponenten nicht berücksichtigen.

Sie können eine spezielle Laufzeit erstellen und den Arbeitsspeicheraufwand über das overhead Feld in Ihrem RuntimeClass Manifest angeben. Das folgende Manifest erstellt z. B. eine Laufzeit für Workloads, die voraussichtlich einen geringeren Ressourcenverbrauch aufweisen:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

Der Wert memory: "120Mi" fügt 120 Mi festen Pod-Overhead hinzu, wenn Kubernetes den Pod einplant und die Größe von cgroup bestimmt. Der handler: kata Wert muss mit dem Kata-Laufzeithandler übereinstimmen, der auf den AKS-Knoten konfiguriert ist.

Bevor Sie einen benutzerdefinierten RuntimeClass verwenden, führen Sie kubectl get runtimeclass aus und überprüfen Sie, ob dessen Handler in Ihrem AKS-Cluster unterstützt wird.

Die Angabe des Aufwands ist nicht erforderlich, es wird jedoch empfohlen, wenn Sie eine genauere Kontrolle über die ressourcen wünschen, die für Ihre Workloads reserviert sind. Wenn Sie die Standardeinstellung kata-vm-isolationRuntimeClass verwenden und keinen Pod-Speichergrenzwert angeben, wird die Größe der VM des Pods standardmäßig auf 512Mi festgelegt. Die Standardeinstellung RuntimeClass führt zu einem zusätzlichen Speicherbedarf von etwa 88 Mi für Host-Komponenten, was zu einem Pod-cgroup-Limit von 600 Mi führt.

Benutzerarbeitsauslastungen

Ihre Kata-Workload kann die konfigurierte Speichergröße der Pod-VM nutzen, abzüglich des Speichers, den Gastkomponenten wie der Kata-Agent und der Kernel der Gast-VM verbrauchen.

So schätzen Sie den Arbeitsspeicher, den diese Komponenten verwenden:

1. Stellen Sie eine Verbindung mit der Pod-VM her (öffnen Sie entweder über kubectl exec oder kubectl debug eine Shell in Ihrem Pod).
2. Führen Sie den Befehl free aus.
3. Überprüfen Sie die verwendete Spalte, um den Arbeitsspeicher zu schätzen, den der Gastkernkern und kata-Agent nutzen.

Speichergruppen

Wenn Kubernetes einen Kata-Pod plant, weist Kubelet dem Speicher cgroupden Pod zu. Die cgroup erzwingt die Speicheranforderungen und -limits des Pods, sodass Sie die für den Pod verfügbaren Ressourcen definieren können.

Der Speicher cgroup verfügt über zwei wichtige Felder:

Wenn der Wert den memory.currentWert überschreitet, löst der memory.max Kernel zu einem beliebigen Zeitpunkt ein OOMKill auf dem Pod aus, wenn der Speicherdruck erkannt wird.

Referenznutzungswerte

Verwenden Sie die folgenden Werte als typische Beispiele für die Speicherauslastung. Pod VM-Speichergrößen unter 128 MiB werden nicht unterstützt.

Informationen zum Lesen dieser Tabelle: memory.current Umfasst die Speicherzuweisung des virtuellen Pod-Computers und die aktuelle Hostkomponentenverwendung. Der kubelet berechnet memory.max aus dem Speicherlimit des Pods und dem Overhead von RuntimeClass. Der Unterschied zwischen diesen Werten gibt die Kapazität an, die für die zusätzliche Hostkomponentenverwendung verfügbar ist.

Bewährte Methoden für die Speicherverwaltung

• Geben Sie die Größe des Pod-VM-Speichers an, indem Sie limits.memory in Ihren Manifesten festlegen, und definieren Sie geeignete Ressourcenkontingente für alle Bereitstellungen.
  • Verwenden Sie eine Speicheranforderung für den Pod ungleich null, um vor dem Start der Pod-VM Kapazität auf dem Knoten für die Pod-VM zu reservieren. Die Anforderung sollte den virtuellen Pod und die darin ausgeführten Container berücksichtigen.
  • Verwenden Sie einen RuntimeClass-Arbeitsspeicher-Aufwand größer als null, um der Knotenkapazität Rechnung zu tragen, die von Kata-Hostkomponenten verbraucht wird.
• Legen Sie für ressourcenintensive Workloads einen Pod-Speichergrenzwert fest, der genügend Arbeitsspeicher für die Workload- und Gastkomponenten bereitstellt.
• Legen Sie RuntimeClass den Arbeitsspeicheraufwand hoch genug für Kata-Hostkomponenten fest, ohne wesentlich mehr Knotenkapazität zu reservieren, als sie benötigen.

CPU-Verwaltung in Pod-Sandboxing

Weisen Sie Kata-Workloads CPU-Ressourcen zu, indem Sie Pod-CPU-Grenzwerte und den RuntimeClass Overhead festlegen. Ohne CPU-Grenzwert können Kata-Hostkomponenten jede cpu-Kapazität verwenden, die auf dem Knoten verfügbar ist.

Reservieren der CPU

Legen Sie ein oder beide der folgenden Felder fest, um die CPU-Kapazität für Ihre Kata-Workloads zu reservieren:

• Der RuntimeClass CPU-Aufwand
• Die CPU-Grenze des Pods

Wenn mindestens einer der beiden Werte angegeben wird, behält sich die Steuerebene die angegebene Anzahl von CPUs auf dem Knoten für Ihre Workload vor. Andere Pods auf demselben Knoten können nicht auf diese reservierte Kapazität zugreifen.

Pod CPU-Grenzwert

Deklarieren Sie den Pod-CPU-Grenzwert im Manifest Ihrer Anwendung. Der Grenzwert steuert, wie viele CPUs die Container in der zugeordneten Pod-VM verwenden können.

Wenn Sie keinen Pod-CPU-Grenzwert deklarieren, weist AKS dem virtuellen Pod eine vCPU zu, wenn der Knoten über ausreichende Kapazität verfügt. Kata-Hostkomponenten haben keine CPU-Auslastungsbeschränkung.

RuntimeClass CPU-Overhead

Geben Sie den RuntimeClass-Overhead an, um Knotenkapazität für die Kata-Hostkomponenten zu reservieren, bevor Sie einen Workload bereitstellen.

Sie können den CPU-Aufwand über das overhead Feld in Ihrem RuntimeClass Manifest angeben. Beispiel:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

Der Wert cpu: "250m" fügt 0,25 vCPU festen Pod-Overhead hinzu, wenn Kubernetes den Pod einplant und die Größe von cgroup bestimmt. Optimieren Sie diesen Wert basierend auf dem erwarteten CPU-Verbrauch der Kata-Hostkomponenten.

Bewährte Methoden für die CPU-Verwaltung

• Wenn Ihr Knoten in der Regel über ausreichend freie CPU-Kapazität verfügt, sind diese Reservierungen möglicherweise unnötig.
• Wenn Ihre Knoten in der Regel bis zur Grenze der CPU-Auslastung laufen, stellt eine nicht-null Reservierung sicher, dass Ihre Pods zuverlässiger betrieben werden können.
  • Pod CPU-Anforderungen helfen dem Kubernetes-Scheduler, ausreichende Knotenkapazität für eine Workload zu reservieren. Die reservierte Kapazität für eine bestimmte Workload steht anderen Workloads auf dem Knoten nicht zur Verfügung.
• Geben Sie CPU-Anforderungen an, die Ihre Infrastruktur aufnehmen kann. Wenn Ihre verfügbare Kapazität gegen null geht oder Ihre Anforderung zu groß ist, können Ihre Workloads möglicherweise nicht starten.
• Richten Sie Ihre CPU-Anforderungen an Ihre CPU-Grenzwerte aus. Requests beeinflussen das Kubernetes-Scheduling, aber der Kata-Shim verwendet sie nicht, um die Größe der Pod-VM zu bestimmen. Der CPU-Grenzwert bestimmt die vCPU-Zuordnung der Pod-VM. Wenn kein CPU-Grenzwert deklariert wird, empfängt der virtuelle Pod-VM eine vCPU, und Kata-Hostkomponenten haben keine CPU-Auslastungsbeschränkung.

Beispieldeklarationen

Sicherheitsüberlegungen für Pod-Sandboxing

Pod Sandboxing isoliert Workloads von anderen Workloads und dem Host, aber Sie müssen dennoch die folgenden Sicherheitsrisiken berücksichtigen.

Privilegierte Pods

Einige Workloads erfordern privilegierte Pods. Sie können privilegierte Pods erstellen, Hostgeräte sind jedoch nicht an die Pods angefügt.

Durch die Verwendung privilegierter Container wird der Stammzugriff auf die Gast-VM gewährt, die Container bleiben jedoch vom Host isoliert.

Verwenden Sie privilegierte Pods nur bei Bedarf, auch mit Pod-Sandboxing. Zulassen, dass nur vertrauenswürdige Benutzer privilegierte Pods verwalten können.

Speichervolumes für Hostpfade

Das Einhängen von hostPath Volumes in Kata-Pods macht einen Teil des Hostdateisystems dem Container direkt zugänglich und kann die Isolierung der Pod-Sandbox schwächen. Wenden Sie den Upstream-Sicherheitsleitfaden hostPath auf Pod-Sandboxing-Workloads an.

Dateien unter /dev sind eine Ausnahme, da sie anstelle des Hostsystems in den Container des Gastsystems eingebunden werden. Dieses Verhalten wahrt die Isolation von Pods, wenn ein Workload diesen Pfad erfordert.

Blockieren von Volumes hostPath mit Azure Policy

Azure Policy bietet zentralisierte, konsistente Erzwingung und Sicherheitsvorkehrungen für Ihre Clusterkomponenten.

AKS stellt integrierte Richtliniendefinitionen bereit, die bewährte Methoden erzwingen. Weisen Sie die Richtlinie Kubernetes-Clusterpods sollten nur zulässige Volumetypen verwenden mit dem Effekt Deny zu, und schließen Sie hostPath von den zulässigen Volumetypen aus, um Pods zu blockieren, die versuchen, hostPath-Volumes einzuhängen.

Nächste Schritte

Erfahren Sie, wie Sie Pod-Sandboxing auf AKS bereitstellen.