Overwegingen voor pod-sandboxing voor Azure Kubernetes Service (AKS)

Pod-sandboxing op Azure Kubernetes Service (AKS) kent resourcebeheer, geheugenbeheer, CPU-beheer en beveiligingsaspecten.

Resourcebeheer in pod-sandboxing

Bekijk deze overwegingen wanneer u resources opgeeft voor een implementatie, met name voor grote of resourcegevoelige workloads.

Kata-onderdelen

Een Kata-implementatie bevat onderdelen die worden uitgevoerd op het AKS-knooppunt en onderdelen die worden uitgevoerd in de virtuele podmachine (VM). Deze scheiding tussen host en gast bepaalt hoe het geheugen- en CPU-gebruik worden toegerekend.

Geheugenbeheer in pod-sandboxing

Stel de geheugenlimiet voor pod-VM's hoog genoeg in om uw workload en Kata-gastonderdelen te ondersteunen zonder ongebruikt geheugen toe te wijzen.

Geheugengrootte van pod-VM

Elke pod-VM krijgt geheugen voor de workload en alle gastcomponenten van Kata. Neem geheugen op buiten het verwachte workloadverbruik voor gastonderdelen, zoals de Kata-agent en de VM-kernel. Zie de referentiegebruikswaarden voor typische geheugenwaarden.

De geheugenlimiet voor de Kubernetes-pod bepaalt de geheugengrootte van de pod-VM. Wijzig de geheugenlimiet voor pods om de geheugengrootte van de pod-VM te wijzigen.

RuntimeClass geheugenoverhead neemt doorgaans toe met de geheugengrootte van de pod-VM.

RuntimeClass geheugenoverhead

Workloads voor pod-sandboxing worden geleverd met een standaard Kata RuntimeClass (kata-vm-isolation) met standaardwaarden voor resourceoverhead. Voor een nauwkeuriger beheer van resourcequota stelt u een aangepaste RuntimeClass resourceoverhead in. De geheugenlimiet voor pods beperkt de grootte van het geheugen aan de gastzijde dat beschikbaar is voor de pod-VM. RuntimeClass overhead reserveert knooppuntcapaciteit voor kata-onderdelen aan de hostzijde en hoeft niet rekening te houden met het verwachte geheugenverbruik van gastonderdelen.

U kunt een gespecialiseerde runtime maken en de geheugenoverhead opgeven via het overhead veld in uw RuntimeClass manifest. Met het volgende manifest wordt bijvoorbeeld een runtime gemaakt voor workloads die naar verwachting een lager resourceverbruik hebben:

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

De waarde memory: "120Mi" voegt 120Mi aan vaste overhead voor de pod toe wanneer Kubernetes de pod inplant en de grootte van de cgroup bepaalt. De handler: kata waarde moet overeenkomen met de Kata Runtime-handler die is geconfigureerd op de AKS-knooppunten.

Voordat u een aangepaste RuntimeClass gebruikt, voert u kubectl get runtimeclass uit en controleert u of de bijbehorende handler wordt ondersteund in uw AKS-cluster.

Het opgeven van overhead is niet vereist, maar wordt aanbevolen als u meer controle wilt over de resources die zijn gereserveerd voor uw workloads. Als u de standaardwaarde kata-vm-isolationRuntimeClass gebruikt en geen geheugenlimiet voor pods opgeeft, wordt de grootte van de POD-VM standaard ingesteld op 512Mi. De standaardinstelling RuntimeClass voegt ongeveer 88Mi aan geheugenoverhead toe voor hostcomponenten, wat resulteert in een podlimiet van 600Mi cgroup.

Gebruikersworkloads

Uw Kata-workload kan de geconfigureerde vm-geheugengrootte van de pod gebruiken minus het geheugen dat gastonderdelen, zoals de Kata-agent en de kernel van de gast-VM, verbruiken.

Als u het geheugen van deze onderdelen wilt schatten, gebruikt u:

1. Maak verbinding met de pod-VM (via kubectl exec of kubectl debug, open een shell in uw pod).
2. Voer de free opdracht uit.
3. Controleer de gebruikte kolom om het geheugen te schatten dat de gastkernel en Kata-agent verbruiken.

Geheugen-cgroups

Wanneer Kubernetes een Kata-pod plant, wijst kubelet de pod toe aan een geheugen cgroup. De cgroup dwingt de geheugenaanvragen en -limieten van de pod af, zodat u de resources kunt definiëren die beschikbaar zijn voor de pod.

Het geheugen cgroup heeft twee belangrijke velden:

Als de memory.current waarde op enig moment groter is dan die van memory.max, kan de kernel een OOMKill op de pod activeren als geheugendruk wordt gedetecteerd.

Referentiegebruikswaarden

Gebruik de volgende waarden als typische voorbeelden van geheugengebruik. Geheugengrootten van pod-VM's onder 128 MiB worden niet ondersteund.

Deze tabel lezen: memory.current bevat de geheugentoewijzing van de pod-VM en het huidige gebruik van hostcomponenten. De kubelet berekent memory.max op basis van de geheugenlimiet van de pod plus RuntimeClass overhead. Het verschil tussen deze waarden geeft de capaciteit aan die beschikbaar is voor extra gebruik van hostonderdelen.

Aanbevolen procedures voor geheugenbeheer

• Geef geheugengrootten voor pod-VM's op door in uw manifesten in te stellen limits.memory en geschikte resourcequota te definiëren voor alle implementaties.
  • Gebruik een niet-nul geheugenaanvraag voor de pod om nodecapaciteit voor de pod-VM te reserveren voordat de VM wordt gestart. De aanvraag moet rekening houden met de pod-VM en de containers die erin worden uitgevoerd.
  • Gebruik niet-nulgeheugenoverhead RuntimeClass om rekening te houden met de knooppuntcapaciteit die Kata-hostonderdelen verbruiken.
• Voor resource-intensieve workloads stelt u de geheugenlimiet van een pod zo in dat er voldoende geheugen beschikbaar is voor de workload en de gastcomponenten.
• Stel RuntimeClass geheugenoverhead hoog genoeg in voor Kata-hostonderdelen zonder aanzienlijk meer knooppuntcapaciteit te reserveren dan ze nodig hebben.

CPU-beheer in pod-sandboxing

Wijs CPU-resources toe aan Kata-workloads door CPU-limieten en RuntimeClass overhead voor pods in te stellen. Zonder een CPU-limiet kunnen Kata-hostonderdelen elke CPU-capaciteit gebruiken die beschikbaar is op het knooppunt.

CPU reserveren

Stel een of beide van de volgende velden in om de CPU-capaciteit voor uw Kata-workloads te reserveren:

• De RuntimeClass processorbelasting
• De CPU-limiet voor de pod

Wanneer ten minste één van de twee waarden is opgegeven, behoudt het besturingsvlak het opgegeven aantal CPU's op het knooppunt voor uw workload. Andere pods op hetzelfde knooppunt hebben geen toegang tot deze gereserveerde capaciteit.

CPU-limiet voor pods

Declareer de CPU-limiet voor pods in het manifest van uw toepassing. De limiet bepaalt hoeveel CPU's de containers in de gekoppelde pod-VM kunnen gebruiken.

Als u geen CPU-limiet voor pods declareert, wijst AKS één vCPU toe aan de pod-VM wanneer het knooppunt voldoende capaciteit heeft. Kata-hostonderdelen hebben geen LIMIET voor CPU-verbruik.

RuntimeClass CPU-belasting

Geef de RuntimeClass overhead op om knooppuntcapaciteit te reserveren voor de Kata-hostonderdelen voordat u een workload implementeert.

U kunt de CPU-overhead opgeven via het overhead veld in uw RuntimeClass manifest. Bijvoorbeeld:

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

De waarde cpu: "250m" voegt 0,25 vCPU aan vaste overhead voor de pod toe wanneer Kubernetes de pod inplant en de grootte van de cgroup bepaalt. Stem deze waarde af op basis van het verwachte CPU-verbruik van de Kata-hostonderdelen.

Aanbevolen procedures voor CPU-beheer

• Als uw knooppunt doorgaans veel gratis CPU-capaciteit heeft, zijn deze reserveringen mogelijk niet nodig.
• Als uw knooppunten doorgaans op de grens van hun CPU-verbruik draaien, zorgt een reservering groter dan nul ervoor dat uw pods betrouwbaarder kunnen worden uitgevoerd.
  • CPU-aanvragen voor pods helpen de Kubernetes-scheduler voldoende knooppuntcapaciteit te reserveren voor een workload. Gereserveerde capaciteit voor een specifieke workload is niet beschikbaar voor andere workloads op het knooppunt.
• Geef CPU-aanvragen op die geschikt zijn voor uw infrastructuur. Als uw beschikbare capaciteit bijna nul bereikt, of uw verzoek te groot is, kunnen uw workloads mogelijk niet starten.
• Stem uw CPU-aanvragen af met uw CPU-limieten. Resourceverzoeken zijn van invloed op de planning in Kubernetes, maar de Kata-shim gebruikt ze niet om de grootte van de pod-VM te bepalen. De CPU-limiet bepaalt de vCPU-toewijzing van de pod-VM. Als er geen CPU-limiet is gedeclareerd, ontvangt de pod-VM één vCPU en kata-hostonderdelen hebben geen CPU-verbruikslimiet.

Voorbeelddeclaraties

Beveiligingsoverwegingen voor pod-sandboxing

Pod-sandboxing isoleert workloads van andere workloads en het hostsysteem, maar u moet wel nog rekening houden met de volgende beveiligingsrisico's.

Geprivilegieerde pods

Voor sommige workloads zijn geprivilegieerde pods vereist. U kunt bevoegde pods maken, maar hostapparaten zijn niet gekoppeld aan de pods.

Het gebruik van bevoegde containers biedt hoofdtoegang in de gast-VM, maar de containers blijven geïsoleerd van de host.

Gebruik geprivilegieerde pods alleen wanneer dat nodig is, zelfs bij gebruik van Pod-sandboxing. Alleen vertrouwde gebruikers toestaan om bevoegde pods te beheren.

Opslagvolumes van hostpad

Het koppelen van hostPath volumes aan Kata-pods stelt een deel van het bestandssysteem van de host rechtstreeks bloot aan de container en kan de isolatie van de Pod-sandbox verzwakken. Pas de upstream-beveiligingsrichtlijnen hostPath toe op workloads voor pod-sandboxing.

Bestanden onder /dev zijn een uitzondering omdat ze zijn gekoppeld aan de container vanuit het gastsysteem in plaats van het hostsysteem. Dit gedrag onderhoudt podisolatie wanneer een workload dit pad vereist.

Volumes hostPath met Azure Policy blokkeren

Azure Policy biedt gecentraliseerde, consistente afdwinging en beveiliging voor uw clusteronderdelen.

AKS biedt ingebouwde beleidsdefinities die best practices afdwingen. Wijs het beleid Kubernetes cluster pods should only use allowed volume types toe met het effect Deny, en sluit hostPath uit van de toegestane volumetypen om pods te blokkeren die hostPath-volumes proberen te koppelen.

Volgende stappen

Meer informatie over het implementeren van Pod-sandboxing in AKS.