Pod-Sandboxing-Überlegungen

Für Pod-Sandboxing-Bereitstellungen auf Azure Kubernetes Service (AKS) gibt es mehrere Elemente, die in Bezug auf ressourcenverwaltung, Speicherverwaltung, CPU-Verwaltung und Sicherheit berücksichtigt werden müssen.

Ressourcenverwaltung

Das Verhalten der Speicher- und CPU-Verwaltung mit Pod Sandboxing ist einigen Benutzern möglicherweise nicht vertraut. Diese Überlegungen sind bei der Angabe von Ressourcen in einer Bereitstellung relevant, insbesondere für größere und ressourcenabhängige Workloads.

Kata-Komponenten

In einer Kata-Bereitstellung gibt es in der Regel zwei Komponentenfamilien, die bereitgestellt werden. Sie verfügen über Hostkomponenten und Gastkomponenten.

• Die Wichtigsten Hostkomponenten sind kata shim, Cloud Hypervisor und virtiofsd.
  • Die Kata shim verwaltet einen Vm-Lebenszyklus eines Pods.
  • Cloud Hypervisor ist der virtuelle Computermonitor (VMM), der von kata shim verwendet wird.
  • virtiofsd ist ein Daemon, der zum Freigeben von Dateien zwischen jedem virtuellen Pod-Computer und seinem Containerhost verwendet wird.
• Die wichtigsten Gastkomponenten umfassen die Arbeitslasten des Benutzers, den Pod-VM-Kernel und den Kata-Agent.
  • Der Kata-Agent verwaltet Container innerhalb der Pod-VMs

Speicherverwaltung

Mit Kata-Pods haben Sie die Möglichkeit, die Menge des Arbeitsspeichers der Pod-VM anzugeben, die Ihre Workloads hostet. Es ist wichtig, dass Sie die Werte entsprechend konfigurieren, damit ein Pod über ausreichende Ressourcen verfügt, aber nicht dazu führt, dass dem Pod nicht verwendeter Arbeitsspeicher zugewiesen wird.

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

Jeder Pod-VM, auf der ein Container ausgeführt wird, wird ein Speicherplatz zugewiesen. Diese VM-Speichergröße ist inklusive des gesamten Speichers, der zum Ausführen von Kata-Gastkomponenten erforderlich ist. Benutzer sollten sicherstellen, dass sie zusätzlichen Arbeitsspeicher über den erwarteten Verbrauch ihrer Workloads hinaus puffern, um den Verbrauch anderer Gastkomponenten, wie z. B. kata-Agent oder VM-Kernel, zu berücksichtigen. Beispiele für typische Speicherwerte finden Sie weiter unten in diesem Artikel.

Die Größe des VM-Speichers des Pods entspricht dem Kubernetes-Pod-Speicherlimit , den der Benutzer angibt. Ein Benutzer kann den Wert ändern, indem er seinen Pod-Speichergrenzwert ändert. wenn keine Werte angegeben werden, wird eine Standardgröße von 512Mi angewendet. Sobald der Pod gestartet wird, ist diese Größe festgesetzt.

Da die Größe des VM-Speichers des Pods zunimmt, ist zu erwarten, dass der Speicheraufwand der Laufzeitklasse ebenfalls zunimmt.

Arbeitsspeicheraufwand der Laufzeitklasse

Pod-Sandboxing-Workloads verfügen über eine standardmäßige Kata-Runtime-Klasse (kata-vm-isolation), die standardmäßige Ressourcen-Overheads enthält. Benutzer, die eine präzisere Steuerung ihrer Ressourcenkontingente wünschen, können eine benutzerdefinierte Laufzeitklasse mit spezifischen Ressourcenaufwand einrichten. Dabei sollten Benutzer sicherstellen, dass der Arbeitsspeicher-Overheadwert der Laufzeitklasse ausreicht, um die gesamte erwartete Verwendung für die Hostkomponenten einer Kata-Bereitstellung zu decken. Der Arbeitsspeicheraufwand der Laufzeitklasse muss nicht den erwarteten Arbeitsspeicherverbrauch der Gastkomponenten berücksichtigen.

Sie können eine spezielle Laufzeit erstellen und den Arbeitsspeicheraufwand in Ihrer Laufzeitklasse über das overhead Feld in Ihrem RuntimeClass Manifest angeben. Angenommen, ich möchte eine Laufzeitumgebung für Arbeitslasten erstellen, von denen ich erwarte, dass der Verbrauch geringer ist:

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

Die Angabe von Overheads ist nicht erforderlich und wird vorgeschlagen, wenn Sie eine bessere Kontrolle über die Ressourcen wünschen, die für Ihre Workloads reserviert werden. Wenn Sie die Standardlaufzeitklasse kata-vm-isolation verwenden und keinen Overhead in Ihrem YAML angeben, wird der Overhead der Pod-VM-Größe standardmäßig auf 512Mi festgelegt, und der Overhead der Laufzeitklasse standardmäßig auf 600Mi. Dieser Standardmäßige Laufzeitaufwand wird mit der Standardgröße des virtuellen Pods (512Mi) und dem ungefähren Arbeitsspeicher berechnet, der von Hostkomponenten für eine solche VM-Größe (~88Mi) benötigt wird.

Benutzerarbeitsauslastungen

Wenn ein Benutzer eine Kata-Workload bereitstellt, kann er den Speicher bis zur konfigurierten VM-Speichergröße des Pods verwenden, abzüglich der anderen Gastkomponenten wie dem Kata-Agent oder dem Gast-VM-Kernel.

Wenn Sie eine Annäherung des von diesen Komponenten verwendeten Arbeitsspeichers erhalten möchten:

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 Spalte "used" in der Ausgabe, um einen Überblick über den vom Gastkern-/Kata-Agent verbrauchten Speicher zu erhalten.

Speichergruppen

Wenn ein Kata-Pod ausgeführt werden soll, weist Kubelet den Pod dem Speichercgroup zu. Dadurch cgroup werden die Speicherbeschränkungen/Anforderungen des Pods erzwungen, sodass ein Benutzer die für einen Pod verfügbaren Ressourcenkontingente definieren kann.

Innerhalb des Speichers cgroupgibt es zwei wichtige Felder zu berücksichtigen:

• memory.current definiert, wie viele Bytes Arbeitsspeicher die Hostkomponenten und die Pod-VM an Speicher zuweisen.
• memory.max optional, benutzerdefinierte Obergrenze des Arbeitsspeichers.current für Pods, in denen Benutzer eine Speicherbeschränkung auferlegen möchten.
  • Das Kubelet berechnet diesen Wert als Summe des Speicherlimits eines Pods und des Arbeitsspeicheraufwands der Laufzeitklasse.

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

Benutzer können diese Werte als Referenz für die typische Speichernutzung und Werte in den behandelten verschiedenen Variablen verwenden. Pod VM-Speichergrößen unter 128Mi werden nicht unterstützt.

CPU-Verwaltung

Ähnlich wie bei der Zuweisung von Arbeitsspeicher können Sie Ihren Kata-Workloads auch CPU-Ressourcen zuordnen. Dies wird empfohlen; Ohne einen CPU-Grenzwert für Ihren Kata-Pod zu deklarieren, können Kata-Hostkomponenten jede auf dem Knoten verfügbare CPU-Kapazität verwenden.

Reservieren der CPU

Wenn Sie CPUs für Ihre Kata-Workloads reservieren, haben Sie zwei Felder, die Sie festlegen können.

• CPU-Overhead der Laufzeitklasse
• 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

Sie können den POD-CPU-Grenzwert im Manifest Ihrer Anwendung deklarieren. Ein angegebener Pod-CPU-Grenzwert definiert den Grenzwert der CPUs, die Container in der zugehörigen Pod-VM verwenden können.

Wenn Sie Bruchteile von CPUs für das pod-CPU-Limit angeben, werden diese Bruchzahlen auf die nächste ganze Zahl aufgerundet. Die aufgerundete Zahl wird zur Anzahl der vCPUs, die der Pod-VM zugewiesen sind, aber das cgroup beschränkt die Arbeitslast darauf, nur den im Pod-CPU-Grenzwert angegebenen Bruchteil zu verbrauchen.

Wenn keine Nummer deklariert wird, wird dem virtuellen Pod eine vCPU zugewiesen, wenn die Kapazität auf dem Knoten verfügbar ist. Es gibt keine Beschränkung für den CPU-Verbrauch der Kata-Hostkomponenten.

CPU-Overhead der Laufzeitklasse

Der Laufzeitklassen-Overhead sollte angegeben werden, wenn Sie einige Knotenkapazität für die Kata-Hostkomponenten vorab reservieren möchten.

Sie können den Arbeitsspeicheraufwand in Ihrer Laufzeitklasse ü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"

Bewährte Methoden

Speicherverwaltung

• Stellen Sie sicher, dass Sie die Größe des virtuellen Pod-VM-Arbeitsspeichers (definiert durch das limits.memory Manifest) und geeignete Ressourcenkontingente für alle Ihre Bereitstellungen angeben.
  • Stellen Sie sicher, dass Sie eine nichtzero-Pod-Anforderung verwenden, wenn Sie sicherstellen möchten, dass einige Knotenkapazität für die Pod-VM reserviert ist, bevor diese VM gestartet wird. Die Anforderung sollte die VM des Pods und die Container berücksichtigen, die darauf ausgeführt werden sollen.
  • Stellen Sie sicher, dass Sie einen nicht-null Laufzeitklassenaufwand verwenden, wenn Sie etwas Knotenkapazität für die Kata-Hostkomponenten reservieren möchten, bevor diese Komponenten gestartet werden.
• Wenn Sie erwarten, dass Ihre Pod-Workloads besonders ressourcenhungrig sind, können Sie die Grenzwerte für die Pod-VM entsprechend angeben, um sicherzustellen, dass ausreichend Ressourcen für Ihre Workloads verfügbar sind.
• Deklarieren Sie einen geeigneten Arbeitsspeicheraufwand für die Laufzeitklasse, sodass genügend Arbeitsspeicher für Ihre Hostkomponenten verfügbar ist, aber nicht zu viel benötigt wird, um nicht genutzten Arbeitsspeicher zu vermeiden.

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.

  • Sie können pod CPU-Anforderungen verwenden, um sicherzustellen, dass einige CPU-Knotenkapazität für die Kata-Hostkomponenten reserviert ist. Reservierte Kapazität für eine bestimmte Arbeitslast ist auf dem Knoten nicht für andere Workloads verfügbar.

• Stellen Sie sicher, dass Sie CPU-Anforderungen angeben, die Ihre Infrastruktur aufnehmen kann. Wenn Ihre verfügbare Kapazität nahe 0 ist oder Ihre Anforderung zu groß ist, können Ihre Workloads möglicherweise nicht starten.

• Richten Sie Ihre CPU-Anforderungen an Ihre CPU-Grenzwerte aus. Der Kata-Shim hat keinen Einblick in Anforderungen. Wenn kein CPU-Grenzwert deklariert wird, ist die VM des Pods daher auf eine vCPU beschränkt. Die Kata-Hostkomponenten, die Einblicke in Anforderungswerte haben, verbrauchen den Rest der angeforderten CPU-Anzahl und haben keinen Grenzwert für den CPU-Verbrauch.

• Reservierte Kapazität für eine bestimmte Workload ist für andere Workloads auf dem Knoten nicht verfügbar.

Beispieldeklarationen

Sicherheit

Pod Sandboxing bietet Benutzern eine überzeugende Option, ihre Workloads von anderen Workloads und dem Host zu isolieren. Es gibt jedoch wichtige Sicherheitsbedenken, die berücksichtigt werden sollten.

Privilegierte Pods

Es gibt Szenarien, in denen privilegierte Pods möglicherweise erforderlich sind. Benutzer können privilegierte Pods starten, aber es sind keine Hostgeräte an den Pod angeschlossen.

Die Verwendung privilegierter Container führt zum Stammzugriff auf die Gast-VM, bleibt aber vom Host isoliert.

Privilegierte Pods sollten auch im Rahmen des Pod Sandboxings nur dann verwendet werden, wenn es unbedingt erforderlich ist. Privilegierte Pods sollten weiterhin von vertrauenswürdigen Benutzern verwaltet werden.

Speichervolumes für Hostpfade

hostPath Volumes können in Kata-Pods montiert werden. In Pod Sandboxing kann die Verwendung von hostPath Volumes die Isolation beeinträchtigen, die Kata gewährleistet, da ein Teil des Hostdateisystems dem Container direkt zugänglich gemacht wird, wodurch ein potenzieller Angriffsvektor geöffnet wird. Die Warnungen von Upstream sollten auch als relevant für Pod Sandboxing berücksichtigt werden.

Es gibt einige Ausnahmen; Dateien, die sich im /dev Container befinden, werden vom Gastsystem anstelle des Hostsystems in den Container eingebunden. Dadurch wird die Isolation von Pods in Situationen beibehalten, in denen dieser Pfad zum Funktionieren eingehängt werden muss.

Blockieren von HostPath über Azure-Richtlinie

Mit Azure-Richtlinie können Benutzer skalierte Erzwingungen und Sicherheitsvorkehrungen auf ihre Clusterkomponenten auf eine zentralisierte, konsistente Weise anwenden.

Es gibt eine Reihe integrierter Richtliniensätze für AKS, die bewährte Methoden erzwingen. Benutzer können eine dieser Richtlinien nutzen, um Bereitstellungen zu blockieren, die versuchen, HostPaths zu mounten.

Nächste Schritte

Sobald Sie fertig sind, erfahren Sie, wie Sie Pod-Sandboxing auf AKS einsetzen.