Kubernetes Nodes vs. Pods: Die wichtigsten Unterschiede erklärt

Was ist ein Kubernetes-Node?

Ein Kubernetes-Node ist eine Worker-Maschine im Cluster, die containerisierte Anwendungen ausführt. Es handelt sich also um den tatsächlichen Rechner – physisch oder virtuell –, der die Anwendungen betreibt.

Jeder Node enthält die Dienste, die zum Ausführen von Pods nötig sind, und wird von den Komponenten der Control Plane verwaltet. Nodes sind entweder physische Server in lokalen Rechenzentren oder virtuelle Maschinen in Cloud-Umgebungen wie AWS EC2, Google Compute Engine oder Azure Virtual Machines.

Jeder Node führt zentrale Komponenten aus: das kubelet, das sicherstellt, dass Container in Pods laufen, die Container-Runtime (in der Regel containerd oder CRI-O als Implementierung des Container Runtime Interface) und den kube-proxy, der die Netzwerkregeln pflegt (eBPF-basierte CNI-Dataplanes wie Cilium können ihn allerdings vollständig ersetzen). Der Node stellt die eigentlichen Compute-Ressourcen bereit – CPU, Arbeitsspeicher, Storage und Netzwerk –, die Pods beim Ausführen von Anwendungen nutzen.

Was ist ein Kubernetes-Pod?

Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes, die sich erstellen oder deployen lässt. Kubernetes führt Container nicht direkt aus, sondern gruppiert einen oder mehrere Container in einem Pod. Dieser Pod dient als Hülle und stellt gemeinsame Ressourcen bereit, etwa Storage-Volumes, einen Netzwerk-Namespace und Spezifikationen für den Betrieb der Container.

Container innerhalb desselben Pods teilen sich eine IP-Adresse und einen Port-Bereich, kommunizieren über localhost miteinander und greifen auf gemeinsame Storage-Volumes zu. Diese enge Kopplung ermöglicht drei gängige Muster für Multi-Container-Pods: Sidecar (ein Logging- oder Monitoring-Agent neben der Hauptanwendung), Ambassador (ein Proxy, der Verbindungen zu externen Diensten vereinfacht) und Adapter (vereinheitlicht das Ausgabeformat heterogener Container). Ein Sidecar-Muster kombiniert beispielsweise einen nginx-Container mit einem Fluent-Bit-Container, der Logs an Elasticsearch übermittelt. Die meisten Pods enthalten jedoch nur einen einzigen Container und folgen damit dem Prinzip einer primären Anwendung pro Pod.

Kubernetes Nodes vs. Pods: Die zentralen Unterschiede

Der grundlegende Unterschied zwischen Nodes und Pods liegt in ihrer Rolle innerhalb der Kubernetes-Hierarchie. Nodes sind Komponenten auf Infrastrukturebene und stellen die physischen oder virtuellen Ressourcen bereit. Pods dagegen sind Abstraktionen auf Anwendungsebene, die diese Ressourcen nutzen.

Schnelle Diagnosebefehle:

# Alle Nodes mit IP-Adressen und Rollen anzeigen
kubectl get nodes -o wide
# Node-Details, Bedingungen und Kapazität prüfen
kubectl describe node
# Alle Pods über alle Namespaces mit Node-Zuordnung auflisten
kubectl get pods -A -o wide
# Pod-Ereignisse und Konfiguration prüfen
kubectl describe pod -n
# Ressourcennutzung in Echtzeit prüfen
kubectl top nodes
kubectl top pods -A

Mit diesen Befehlen lassen sich der Zustand der Nodes, die Verteilung der Pods und der Ressourcenverbrauch im gesamten Cluster schnell einschätzen.

Ein Node-Pool (in EKS „Node-Group“) umfasst eine Gruppe von Nodes mit demselben Instanztyp, derselben Availability Zone und derselben Konfiguration. So lassen sich unterschiedliche Anforderungen abbilden, etwa GPU-Nodes für Machine Learning oder Spot-Instanzen für Batch-Jobs.

Node-Pools greifen auf zwei Ebenen mit dem Autoscaling ineinander:

• der Horizontal Pod Autoscaler (HPA) skaliert die Pod-Replicas anhand von CPU- und Speicher-Metriken;

• der Cluster Autoscaler fügt einem Pool Nodes hinzu, wenn Pods wegen unzureichender Ressourcen im Status „Pending“ verharren, und entfernt zu wenig ausgelastete Nodes nach einer Verzögerung beim Scale-down.

Skaliert der HPA ein Deployment beispielsweise von 5 auf 20 Replicas, passen aber nur 10 auf die vorhandenen Nodes, stellt der Cluster Autoscaler zusätzliche Nodes aus dem passenden Pool bereit, um die übrigen 10 Pods aufzunehmen.

Wie Nodes und Pods in der Kubernetes-Architektur zusammenspielen

Das Kubernetes-Cluster steuert die Beziehung zwischen Nodes und Pods über die Control Plane. Beim Deployen einer Anwendung bewertet der Kubernetes-Scheduler die Nodes anhand der Ressourcenanforderungen der Pods, der Regeln für Node-Affinität und Anti-Affinität, der Topology-Spread-Constraints, der Taints und Tolerations sowie eigener Scheduler-Richtlinien. Anschließend bindet er jeden Pod an genau einen Node, der alle Anforderungen erfüllt. Das kubelet auf jedem Node stellt danach sicher, dass die zugewiesenen Pods laufen und fehlerfrei arbeiten.

Diese Architektur ermöglicht zentrale Kubernetes-Funktionen:

• Automatische Pod-Verteilung – der Scheduler verteilt Pods gezielt über die Nodes, abhängig von den verfügbaren Ressourcen und den Constraints;

• Selbstheilung – fällt ein Pod aus, erstellt Kubernetes automatisch einen Ersatz; fällt ein Node aus, werden die Pods auf fehlerfreie Nodes verschoben;

• Skalierung – das horizontale Autoscaling erstellt oder entfernt Pod-Replicas anhand von Metriken, während das Cluster-Autoscaling Nodes je nach Ressourcenbedarf der Pods hinzufügt oder entfernt;

• Lastverteilung – mehrere Pod-Replicas lassen sich für Hochverfügbarkeit über verschiedene Nodes verteilen.

Die Beziehung zwischen Nodes und Pods erstreckt sich auch auf die Kubernetes-Controller, die den Lebenszyklus der Pods verwalten:

• Deployment – verwaltet zustandslose Pod-Replicas mit Rolling Updates (Webanwendungen, APIs);

• StatefulSet – verwaltet zustandsbehaftete Pods mit stabilen Netzwerkidentitäten und persistentem Storage (Datenbanken, Message Queues);

• DaemonSet – stellt einen Pod pro Node für clusterweite Dienste bereit (Log-Collectors, Monitoring-Agents);

• Job/CronJob – führt Pods für die Batch-Verarbeitung oder geplante Aufgaben bis zum Abschluss aus.

Deployments verwalten den gewünschten Zustand der Pod-Replicas über die Nodes hinweg und erstellen bei Updates neue Pods, bevor sie alte beenden.

Sicherheitsaspekte von Nodes und Pods

Die Sicherheitsanforderungen unterscheiden sich deutlich zwischen Nodes und Pods, weil beide unterschiedliche Rollen im Cluster erfüllen. Unternehmen ordnen diese Kontrollen meist Compliance-Frameworks zu:

• der CIS Kubernetes Benchmark liefert über 100 Kontrollen für die Härtung von Nodes (4.1: kubelet-Berechtigungen einschränken) und die Pod-Sicherheit (5.2: privilegierte Container minimieren);

• NIST 800-190 behandelt Container-Sicherheit über den gesamten Image-Lebenszyklus, den Betrieb (runtime) und die Orchestrierung hinweg;

• ISO 27001 und SOC 2 verlangen dokumentierte Zugriffskontrollen und Audit-Logging auf Infrastruktur- und Anwendungsebene.

Policy-as-Code-Tools wie OPA Gatekeeper, Kyverno oder die Wiz Policy Engine setzen diese Standards automatisch durch – sie blockieren nicht konforme Pod-Deployments und kennzeichnen fehlkonfigurierte Nodes, bevor diese in die Produktion gelangen.

Eine agentless, einheitliche Transparenz über Nodes, Pods und Identitäten schafft die Grundlage, um least privilege durchzusetzen, Container-Escape-Versuche zu erkennen und lateral movement zu verhindern – indem sich Infrastruktur- und Anwendungskontext miteinander verknüpfen lassen. Die Node-Sicherheit schützt die zugrunde liegende Infrastruktur, darunter das Betriebssystem, das kubelet und die Container-Runtime. Dazu gehört, das Host-Betriebssystem abzusichern, den SSH-Zugriff zu verwalten, Systempakete aktuell zu halten und eine Netzwerksegmentierung auf Infrastrukturebene umzusetzen.

Die Pod-Sicherheit arbeitet auf Anwendungsebene und umfasst mehrere zentrale Bausteine:

• Security Contexts – sie legen über einen security context die Berechtigungen und Zugriffseinstellungen für Pods und Container fest;

• Pod Security Standards und Admission – sie setzen die Pod Security Standards (PSS) über Pod-Security-Admission-Controller (PSA) durch; die PodSecurityPolicy wurde in Kubernetes v1.25 entfernt und durch das integrierte PSA-Admission-Plugin mit den Richtlinienstufen Restricted, Baseline und Privileged ersetzt;

• Netzwerkrichtlinien – sie steuern den Datenverkehr zwischen Pods auf Anwendungsebene;

• Service-Konten – sie verwalten die Identitäten der Pods und die RBAC-Berechtigungen im Cluster; least privilege lässt sich umsetzen, indem Rollen eng gefasst und für Pods ohne API-Zugriff automountServiceAccountToken: false gesetzt werden;

• Secrets-Management – hier kommen Kubernetes Secrets mit aktivierter etcd-Verschlüsselung im Ruhezustand zum Einsatz; externe Secret Stores wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault lassen sich über den Secrets Store CSI Driver einbinden, um Secrets automatisch zu rotieren und die Angriffsfläche des Clusters zu verringern.

Container-Escape-Schwachstellen sind ein kritisches Risiko: Bricht ein Angreifer aus einem Container aus, kann er den gesamten Node kompromittieren und möglicherweise lateral movement zu anderen Pods ermöglichen. Das zeigt, warum Defense-in-Depth-Strategien sowohl die Sicherheit auf Node-Ebene als auch auf Pod-Ebene abdecken müssen.

Ressourcenverwaltung und -zuteilung zwischen Nodes und Pods

Die Ressourcenverwaltung in Kubernetes folgt einem hierarchischen System: Nodes stellen Ressourcen bereit, und Pods nutzen sie über Requests und Limits. Jeder Node verfügt über zuteilbare Ressourcen (CPU, Arbeitsspeicher, Storage), die das kubelet für laufende Pods reserviert, nachdem es System-Daemons und Kubernetes-Komponenten berücksichtigt hat.

Pods geben ihren Ressourcenbedarf über zwei zentrale Mechanismen an:

• Resource Requests – die Mindestmenge an CPU und Arbeitsspeicher, die dem Pod garantiert wird;

• Resource Limits – die maximale Menge an Ressourcen, die der Pod nutzen darf;

• Quality-of-Service-Klassen (QoS) – Kubernetes weist anhand von Requests und Limits die QoS-Klassen Guaranteed, Burstable oder BestEffort zu.

Der Scheduler nutzt die Resource Requests, um die Platzierung auf einem Node zu bestimmen, und stellt sicher, dass die Nodes über ausreichend freie Kapazität verfügen. Überschreitet ein Pod sein Speicherlimit, beendet der Kernel den Container sofort per OOMKill; CPU-Limits drosseln die Nutzung über CFS-Quotas, ohne den Pod zu beenden. Node-Pressure-Bedingungen treten auf, wenn einem Node die Ressourcen knapp werden, und lösen Pod-Evictions anhand von QoS-Klasse und Ressourcenverbrauch aus.

Eine wirksame Ressourcenverwaltung erfordert es, die Node-Kapazität zu überwachen und die Auslastung über alle Nodes hinweg zu verfolgen, um Engpässe zu erkennen. Kontextbezogene Risiko- und Kapazitätseinblicke helfen dabei, Requests und Limits der Pods passend zu dimensionieren und OOMKilled-Container sowie CPU-Throttling zu verhindern, bevor sie die Leistung der Anwendungen beeinträchtigen oder kaskadierende Ausfälle in der Produktion auslösen. Kubernetes unterstützt offiziell Cluster mit bis zu 5.000 Nodes und insgesamt 150.000 Pods gemäß den im Kubernetes-Projekt dokumentierten Skalierungsgrenzen. Zudem sollten Pods durch passende Requests und Limits auf den tatsächlichen Bedarf der Anwendung zugeschnitten werden. Node-Affinität und Anti-Affinität steuern die Platzierung der Pods anhand von Node-Labels, während Taints und Tolerations Pods auf bestimmten Nodes verhindern oder zulassen. So lassen sich beispielsweise GPU-Nodes für ML-Workloads reservieren:

# GPU-Nodes mit einem Taint versehen
kubectl taint nodes gpu-node-1 workload=ml:NoSchedule
# Pod toleriert den Taint
tolerations:
- key: workload
  operator: Equal
  value: ml
  effect: NoSchedule
# GPU-Node über Affinität anfordern
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: accelerator
          operator: In
          values:
          - gpu

So lassen sich nur ML-Pods mit der passenden Toleration auf den teuren GPU-Nodes einplanen.

Monitoring und Troubleshooting von Nodes und Pods

Das Troubleshooting von Kubernetes-Problemen erfordert für Nodes und Pods unterschiedliche Ansätze. Eine durchgängige Nachvollziehbarkeit vom Code bis in die Cloud verkürzt die mittlere Zeit bis zur Behebung (MTTR), indem sie fehlerhafte Pods mit ihren Quell-Manifesten, Container Images und verantwortlichen Teams verknüpft und anschließend Laufzeit-Erkennungen mit den tatsächlichen attack paths über den Security Graph korreliert. Probleme auf Node-Ebene zeigen sich meist als systemische Störungen, die mehrere Pods betreffen, während Probleme auf Pod-Ebene oft anwendungsspezifisch sind oder mit der Container-Konfiguration zusammenhängen.

Beim Troubleshooting von Nodes stehen diese Bereiche im Fokus:

• Node-Status und -Bedingungen – der Ready-Status sowie Bedingungstypen wie MemoryPressure, DiskPressure, PIDPressure und NetworkUnavailable geben jeweils Hinweise auf konkrete Ressourcenengpässe oder Verbindungsprobleme;

• Systemressourcen – CPU, Arbeitsspeicher, Festplattennutzung und Netzwerkverbindung auf Betriebssystemebene überwachen;

• kubelet-Logs – die kubelet-Logs auf Fehler bei der Verwaltung des Pod-Lebenszyklus oder der Kommunikation mit dem API-Server prüfen;

• Container-Runtime – prüfen, ob die Container-Runtime funktioniert und Images abrufen kann.

Das Troubleshooting von Pods erfordert die Diagnose konkreter Fehlerbilder:

Pods im Status „Pending“:

• die Ereignisse aus kubectl describe pod auf „Insufficient CPU/memory“ prüfen und dann Nodes skalieren oder Requests reduzieren;

• auf „0/3 nodes available: taint“ achten und Tolerations hinzufügen oder Taints entfernen;

• bei „ImagePullBackOff“ den Image-Namen, die Registry-Zugangsdaten und den Netzwerkzugriff prüfen.

CrashLoopBackOff:

• die Container-Logs mit kubectl logs --previous prüfen;

• die Konfiguration der Liveness- und Readiness-Probes prüfen, da die Probes zu aggressiv eingestellt sein können;

• die Abhängigkeiten der Anwendung prüfen (Datenbankverbindungen, Konfigurationsdateien).

NodeNotReady:

• per SSH auf den Node zugreifen und systemctl status kubelet prüfen;

• das CNI-Plugin mit kubectl get pods -n kube-system | grep cni prüfen;

• die Node-Bedingungen mit kubectl describe node auf Festplatten-, Speicher- oder PID-Druck prüfen.

Dieses systematische Vorgehen grenzt ein, ob die Probleme aus Scheduling-Constraints, Anwendungsfehlern oder Infrastrukturausfällen stammen.

Gängige Troubleshooting-Befehle helfen bei der Diagnose auf beiden Ebenen; kubectl describe liefert dabei detaillierte Informationen zu Status, Ereignissen und Bedingungen von Nodes und Pods.

Wie Wiz Kubernetes-Nodes und -Pods absichert

Wiz bietet agentless Transparenz über die gesamte Kubernetes-Infrastruktur und scannt Nodes wie Pods ohne Leistungseinbußen oder aufwendige Bereitstellung. Die Plattform erstellt ein umfassendes Inventar aller Kubernetes-Ressourcen – von der zugrunde liegenden Node-Infrastruktur bis zu den einzelnen Containern in den Pods – und ermöglicht Sicherheitsteams so, ihre gesamte Angriffsfläche zu verstehen.

Der Wiz Security Graph bildet die Beziehungen zwischen Nodes, Pods, Containern, Identitäten, sensiblen Daten und Cloud-Diensten ab und macht so reale attack paths über alle Infrastrukturebenen sichtbar. Anschließend priorisiert er die Behebung nach Ausnutzbarkeit (aktive Exploits, waffenfähige CVEs), Angriffsfläche im Netzwerk (mit dem Internet verbunden, übermäßige Berechtigungen) und Blast Radius (Zugriff auf besonders schützenswerte Daten). Dieser kontextbezogene Blick zeigt, wie ein kompromittierter Pod zu Zugriff auf Node-Ebene eskalieren kann oder wie ein fehlkonfigurierter Node mehrere Pods einem Risiko aussetzt. Indem Wiz Schwachstellen, Fehlkonfigurationen, die Angriffsfläche im Netzwerk und Identitätsberechtigungen über Nodes und Pods hinweg korreliert, erkennt die Plattform toxische Kombinationen, die reale Sicherheitsrisiken schaffen.

Ein schlanker eBPF-Runtime-Sensor ergänzt Erkennungen in Echtzeit über Nodes und Pods hinweg – er identifiziert Container-Escapes, Versuche der privilege escalation, Krypto-Mining-Prozesse, reverse shells und verdächtige ausgehende Verbindungen – mit präzisem Reaktionskontext auf Prozessebene und ohne Agent-Overhead. Der Sensor überwacht sowohl System-Calls auf Node-Ebene als auch das Anwendungsverhalten auf Pod-Ebene, um auffällige Aktivitäten, unbefugte Zugriffsversuche und mögliche Sicherheitsverletzungen zu erkennen, sobald sie auftreten.

Die attack path analysis zeigt, wie ein kompromittierter Pod zu Zugriff auf Node-Ebene und weiter zu umfassenderen Cloud-Ressourcen eskalieren kann – über toxische Risikokombinationen. Dieser umfassende Blick ermöglicht eine priorisierte Behebung anhand der tatsächlichen Ausnutzbarkeit statt anhand theoretischer Schweregrade.

Wiz Code verlagert die Sicherheit früh in den Entwicklungsprozess – es scannt IaC-Templates, Helm Charts und Container Images in CI-Pipelines und blockiert riskante Deployments über dieselbe Policy Engine, die auch den Betrieb (runtime) steuert. Dieser einheitliche Ansatz verhindert eine Abweichung der Richtlinien und stellt sicher, dass die in der Produktion durchgesetzten Pod Security Standards bereits vor dem Merge des Codes validiert werden. Durch die Analyse von YAML-Definitionen, Helm Charts und Container Images vor dem Deployment lassen sich Sicherheitsprobleme erkennen und beheben, bevor sie produktive Nodes und Pods beeinträchtigen.

Ein umfassender Schutz der workloads reicht von Schwachstellen in Container Images auf Pods bis zu Risiken auf Betriebssystemebene der Worker-Nodes – mit einer einheitlichen Risikopriorisierung. Dieser Ansatz macht getrennte Tools für Node- und Pod-Sicherheit überflüssig und sorgt für konsistente Richtlinien über die gesamte Kubernetes-Umgebung. Wiz schafft agentless Transparenz vom Code bis in die Cloud über Nodes und Pods hinweg – mit risikopriorisierten, graphbasierten Einblicken, die reale attack paths statt endloser Schwachstellenlisten zeigen. Fordern Sie eine Demo an und sehen Sie, wie Wiz die Komplexität von Kubernetes in konkrete Maßnahmen überführt.

Häufig gestellte Fragen