Pod

På noden er en pod en sandkasse: runtimen opretter først et network namespace (traditionelt holdt åbent af en lillebitte "pause"-container), CNI-plugin'et giver det en IP, og applikationscontainerne tilslutter sig derefter dette namespace. Containere i samme pod deler derfor én IP og ét portrum og når hinanden på localhost; de deler IPC-namespace og kan dele PID-namespace, hvis shareProcessNamespace er sat. Filsystemerne er adskilte, medmindre containerne monterer det samme volumen på pod-niveau, fx et emptyDir, der lever lige så længe som poden. Poden planlægges samlet én gang og flytter aldrig: at "flytte" en pod betyder i virkeligheden at slette den og oprette en ny med nyt navn og ny IP, og derfor går stabil adressering gennem Services.

En podspecifikation kan rumme tre slags containere. Init-containere kører færdigt i rækkefølge, før applikationscontainerne starter. Sidecar-containere - erklæret som init-containere med restartPolicy: Always - starter før og kører side om side med hovedcontainerne og stoppes efter dem; den indbyggede sidecar-understøttelse kom i Kubernetes 1.28, blev slået til som standard i 1.29 og blev stabil i 1.33. Ephemeral containers kan føjes til en kørende pod til fejlfinding med kubectl debug. kubelet styrer sundheden via liveness probes (genstart ved fejl), readiness probes (fjern fra Service-endepunkter) og startup probes (hold de andre probes tilbage ved langsom opstart). Ved sletning modtager hver container SIGTERM, preStop-hooks kører, og efter terminationGracePeriodSeconds (30 sekunder som standard) dræbes tilbageværende processer med SIGKILL.

Ressourceforespørgsler og -grænser per container afgør podens QoS-klasse: Guaranteed, når alle containere har ens forespørgsler og grænser for CPU og hukommelse, BestEffort, når ingen er sat, og ellers Burstable; ved hukommelsespres på noden smides BestEffort-pods ud først. Pods oprettes næsten aldrig direkte: et Deployment styrer ReplicaSets, der opretter pods, mens StatefulSets, DaemonSets og Jobs dækker stabil identitet, én per node og opgaver, der kører til ende. Statiske pods, defineret af filer på en node, er den måde, kubeadm kører selve kontrolplanet på.

Det meste sikkerhed på containerniveau i Kubernetes udtrykkes i podens securityContext og spec: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, capabilities.drop: [ALL], seccompProfile: RuntimeDefault, og om hostNetwork, hostPID, hostIPC eller hostPath-volumener bruges. Pod Security Admission tjekker disse felter mod profilerne privileged, baseline og restricted per namespace. Fordi alle containere i en pod deler netværksidentitet og et eventuelt monteret service account-token, har en kompromitteret sidecar samme netværksrækkevidde som hovedapplikationen; en pod er en enhed for fælles placering og fælles skæbne, ikke en sikkerhedsgrænse mellem dens containere.