Kubernetes verstehen, aufbauen und betreiben lassen? WZ-IT plant, betreibt und prüft Kubernetes-Cluster. Kubernetes-Leistungen ansehen
Dieses Lexikon erklärt 60 Kubernetes-Begriffe in kurzen Definitionen. Sie folgen dem offiziellen Kubernetes-Glossar und der Dokumentation der aktuellen Version 1.37; jeder Eintrag verweist auf die zuständige Dokumentationsseite und, wo vorhanden, auf einen unserer Ratgeber. Sieben Gruppen ordnen die Begriffe, am Anfang steht ein alphabetischer Index. Stand: 28. Oktober 2026.
Inhaltsverzeichnis
- Alphabetischer Index
- Grundlagen
- Workloads
- Netzwerk
- Storage
- Sicherheit
- Betrieb
- Delivery
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Alphabetischer Index
- A: Admission Controller, API Server, Audit Log
- C: Cluster, CNI (Container Network Interface), Container, Container Runtime, Control Plane, Controller, Cordon und Drain, CronJob, CSI (Container Storage Interface), Custom Resource Definition (CRD)
- D: DaemonSet, Deployment, Distribution, DNS
- E: etcd
- G: Gateway API, GitOps
- H: Helm, Horizontal Pod Autoscaler (HPA)
- I: Infrastructure as Code (IaC), Ingress, Ingress Controller
- J: Job
- K: kube-proxy, kubeadm, kubectl, kubelet, Kubernetes, Kustomize
- L: Label, LoadBalancer
- M: Managed Kubernetes, Manifest
- N: Namespace, NetworkPolicy, Node
- O: Operator
- P: PersistentVolume (PV), PersistentVolumeClaim (PVC), Pod, Pod Security Admission, PodDisruptionBudget (PDB), Probe
- R: ReplicaSet, Requests und Limits, ResourceQuota, Role-Based Access Control (RBAC)
- S: Scheduler, Secret, Service, Service Mesh, ServiceAccount, Sidecar Container, StatefulSet, StorageClass
- T: Taints und Tolerations
- V: Volume
Grundlagen
API Server
Der API Server (kube-apiserver) ist das Frontend der Control Plane und stellt die Kubernetes-API bereit. Er skaliert horizontal: Mehrere Instanzen können laufen und den Verkehr untereinander aufteilen. Doku: kube-apiserver. Ratgeber: Kubernetes privat über NetBird erreichen.
Cluster
Ein Cluster ist eine Gruppe von Worker-Maschinen (Nodes), auf denen containerisierte Anwendungen laufen; jeder Cluster hat mindestens einen Worker Node. Die Control Plane verwaltet Nodes und Pods und läuft in Produktion meist verteilt auf mehrere Rechner. Doku: Cluster components. Ratgeber: Kubernetes auf Proxmox installieren: k3s mit drei VMs.
Container
Ein Container ist ein leichtgewichtiges, portables, ausführbares Abbild einer Software mit allen Abhängigkeiten. Container entkoppeln Anwendungen von der Host-Infrastruktur und erleichtern Deployment und Skalierung. Doku: Containers. Ratgeber: Kubernetes vs. Docker Compose vs. Coolify.
Container Runtime
Die Container Runtime startet und stoppt Container auf jedem Node, zum Beispiel containerd oder CRI-O. Kubernetes unterstützt jede Implementierung des Container Runtime Interface (CRI), über das das Kubelet mit ihr spricht. Doku: Container runtimes.
Control Plane
Die Control Plane ist die Schicht, die die Kubernetes-API bereitstellt und den Lebenszyklus der Container steuert. Sie besteht unter anderem aus etcd, API Server, Scheduler und Controller Manager. Doku: Cluster components. Ratgeber: Kubernetes auf Proxmox.
Controller
Ein Controller ist eine Kontrollschleife, die den Zustand des Clusters beobachtet und Änderungen veranlasst, bis der Ist-Zustand dem gewünschten Zustand näherkommt. Eigene Controller bilden die Grundlage des Operator-Musters. Doku: Controllers.
Distribution
Eine Distribution bündelt Kubernetes mit Installer und Voreinstellungen, zum Beispiel k3s, RKE2 oder Talos Linux. Das CNCF prüft Angebote im Programm Certified Kubernetes auf die erforderlichen APIs. Doku: Certified Kubernetes. Ratgeber: k3s vs. RKE2 vs. Talos, Was ist Talos Linux?, Talos Linux auf Proxmox installieren.
etcd
etcd ist der konsistente, hochverfügbare Key-Value-Store für alle Daten des API Servers, also den Zustand des Clusters. Bei selbst betriebenen Clustern gehört der etcd-Snapshot zur Sicherung; bei verwalteten Diensten hängt die Zuständigkeit vom Angebot ab. Doku: Operating etcd clusters. Ratgeber: Kubernetes-Backup: die vier Ebenen.
kubectl
kubectl ist das Kommandozeilenwerkzeug, mit dem Sie über die Kubernetes-API mit der Control Plane eines Clusters sprechen. Damit lassen sich Objekte anlegen, prüfen, ändern und löschen. Doku: kubectl.
kubelet
Das Kubelet ist der Agent auf jedem Node. Es stellt sicher, dass die in den PodSpecs beschriebenen Container in einem Pod laufen und gesund sind; Container, die nicht von Kubernetes erzeugt wurden, verwaltet es nicht. Doku: kubelet.
Kubernetes
Kubernetes ist eine Open-Source-Plattform, die containerisierte Anwendungen über mehrere Nodes ausrollt, skaliert und verwaltet. Sie arbeitet deklarativ: Sie beschreiben den gewünschten Zustand, Controller gleichen den tatsächlichen Zustand daran an. Doku: Kubernetes overview. Ratgeber: Was ist Kubernetes?, Brauchen wir Kubernetes?.
Label
Labels sind Schlüssel-Wert-Paare an Objekten wie Pods. Sie organisieren Objekte und wählen Teilmengen aus; ein Service findet seine Pods über einen Label-Selektor. Doku: Labels and selectors.
Managed Kubernetes
Bei Managed Kubernetes betreibt ein Anbieter die Control Plane. Allgemein beschreibt der Kubernetes-Glossar einen Managed Service als Software-Angebot, das ein Drittanbieter pflegt. Die Aufgabenteilung zwischen Anbieter und Kunde unterscheidet sich je Angebot. Doku: Managed Service. Ratgeber: Europäische Kubernetes-Provider im Vergleich, Kubernetes auf Hetzner, Kubernetes auf OVHcloud.
Namespace
Ein Namespace isoliert Gruppen von Ressourcen innerhalb eines Clusters. Namen müssen nur innerhalb eines Namespace eindeutig sein; clusterweite Ressourcen wie Nodes oder StorageClasses gehören keinem Namespace. Verbrauch begrenzt eine ResourceQuota. Doku: Namespaces.
Node
Ein Node ist eine Worker-Maschine in Kubernetes, virtuell oder physisch, verwaltet von der Control Plane. Auf ihm laufen unter anderem Kubelet, kube-proxy und eine Container Runtime. Nodes lassen sich als VMs auf einem Hypervisor betreiben. Doku: Nodes. Ratgeber: Proxmox vs Kubernetes.
Scheduler
Der kube-scheduler ist die Control-Plane-Komponente, die neu erstellte Pods ohne Node beobachtet und einen Node für sie auswählt. Die Entscheidung berücksichtigt unter anderem Ressourcenanforderungen, Affinity-Regeln und Taints. Doku: kube-scheduler.
Workloads
CronJob
Ein CronJob startet einen Job nach einem Zeitplan im Cron-Format, vergleichbar mit einer Zeile in einer crontab. Doku: CronJob.
DaemonSet
Ein DaemonSet stellt sicher, dass auf allen oder ausgewählten Nodes eine Kopie eines Pods läuft, typisch für Log-Collector und Monitoring-Agenten. Kommt ein Node hinzu, wird auch dort ein Pod angelegt. Doku: DaemonSet.
Deployment
Ein Deployment verwaltet eine replizierte Anwendung, typischerweise aus Pods ohne lokalen Zustand. Es beschreibt den Soll-Zustand deklarativ und tauscht Pods bei Änderungen schrittweise aus; für Workloads mit lokalem Zustand ist das StatefulSet gedacht. Doku: Deployments.
Job
Ein Job führt eine endliche oder Batch-Aufgabe bis zum Abschluss aus. Er legt einen oder mehrere Pods an und stellt sicher, dass eine festgelegte Anzahl davon erfolgreich endet. Doku: Jobs.
Pod
Ein Pod ist das kleinste und einfachste Kubernetes-Objekt: eine Gruppe laufender Container im Cluster. Er enthält meist einen Hauptcontainer und optional Sidecar-Container; Pods werden üblicherweise über ein Deployment verwaltet. Doku: Pods.
Probe
Eine Probe ist eine Prüfung, die das Kubelet regelmäßig an einem laufenden Container ausführt. Liveness-, Readiness- und Startup-Probes zeigen, ob ein Container gesund ist, Verkehr erhalten kann oder noch startet. Doku: Liveness, readiness and startup probes.
ReplicaSet
Ein ReplicaSet hält eine festgelegte Anzahl von Replica-Pods am Laufen. Die Dokumentation empfiehlt, statt eines ReplicaSets direkt ein Deployment zu verwenden, das ReplicaSets verwaltet und deklarative Updates liefert. Doku: ReplicaSet.
Sidecar Container
Sidecar-Container laufen neben dem Hauptcontainer eines Pods und liefern einen Pod-lokalen Dienst, etwa für Logging oder einen Proxy. Anders als Init-Container laufen sie nach dem Start weiter; die Funktion ist seit Kubernetes 1.33 stable. Service Meshes nutzen dieses Muster. Doku: Sidecar containers. Ratgeber: Istio vs. Linkerd vs. Cilium.
StatefulSet
Ein StatefulSet verwaltet Pods mit stabiler Identität und fester Reihenfolge; jeder Pod behält einen persistenten Bezeichner über Neuplanungen hinweg. Das erleichtert es, bestehende Volumes den Ersatz-Pods zuzuordnen, etwa bei Datenbanken. Doku: StatefulSets.
Netzwerk
CNI (Container Network Interface)
CNI ist die Plugin-Schnittstelle, über die ein Netzwerk-Plugin Pods mit dem Cluster-Netz verbindet; Cilium und Calico sind verbreitete Plugins. Ob eine NetworkPolicy wirkt, hängt vom Plugin ab. Doku: Network plugins. Ratgeber: Cilium vs. Calico.
DNS
Kubernetes legt DNS-Einträge für Services und Pods an, sodass sich Anwendungen über stabile Namen statt über IP-Adressen erreichen. Doku: DNS for Services and Pods.
Gateway API
Die Gateway API ist eine Familie von API-Typen für Service-Networking in Kubernetes, rollenorientiert, protokollbewusst und erweiterbar (GatewayClass, Gateway, HTTPRoute und weitere). Das Kubernetes-Projekt empfiehlt Gateway statt Ingress. Doku: Gateway API. Ratgeber: Gateway API vs. Ingress.
Ingress
Ingress ist ein API-Objekt für den externen, meist HTTP-Zugriff auf Services, mit Lastverteilung, TLS-Terminierung und namensbasiertem Virtual Hosting. Die Ingress-API ist eingefroren: Sie bleibt bestehen, wird aber nicht weiterentwickelt. Doku: Ingress. Ratgeber: Gateway API vs. Ingress.
Ingress Controller
Ein Ingress Controller setzt Ingress-Objekte um; ohne laufenden Controller bleibt ein Ingress wirkungslos. Doku: Ingress controllers. Ratgeber: Von ingress-nginx zu Gateway API migrieren.
kube-proxy
kube-proxy ist ein Netzwerk-Proxy auf jedem Node, der einen Teil des Service-Konzepts umsetzt. Er pflegt Netzwerkregeln, über die Pods aus dem Cluster und von außen erreichbar werden. Doku: kube-proxy.
LoadBalancer
LoadBalancer ist ein Service-Typ, der den Service über einen externen Load Balancer erreichbar macht. Kubernetes bringt keine eigene Load-Balancer-Komponente mit; Sie stellen eine bereit oder binden einen Cloud-Anbieter an, auf eigener Hardware etwa MetalLB oder kube-vip. Doku: Service type LoadBalancer. Ratgeber: MetalLB vs. kube-vip.
NetworkPolicy
Eine NetworkPolicy legt fest, welche Pods untereinander und mit anderen Netzwerkzielen kommunizieren dürfen. Sie wirkt nur, wenn das CNI-Plugin sie umsetzt; ohne umsetzenden Controller hat das Objekt keine Wirkung. Doku: Network policies. Ratgeber: Cilium vs. Calico.
Service
Ein Service macht eine Anwendung, die als ein oder mehrere Pods läuft, im Netzwerk erreichbar. Die Pod-Auswahl erfolgt meist über einen Label-Selektor; wechseln die Pods, bleibt der Service stabil. Typen sind ClusterIP, NodePort, LoadBalancer und ExternalName. Doku: Service.
Service Mesh
Ein Service Mesh verlagert Verschlüsselung, Zugriffsregeln, Traffic-Steuerung und Metriken zwischen Services in die Infrastruktur. Der klassische Ansatz koppelt jeden Pod mit einem Proxy, sidecarlose Ansätze nutzen Funktionen auf Node-Ebene oder im Kernel (eBPF). Doku: CNCF: Service Mesh. Ratgeber: Istio vs. Linkerd vs. Cilium.
Storage
CSI (Container Storage Interface)
CSI ist der Standard, über den Storage-Anbieter ihre Systeme für Kubernetes bereitstellen, ohne Code im Kubernetes-Repository (Out-of-Tree-Treiber). Ein CSI-Treiber muss im Cluster installiert sein, bevor eine StorageClass ihn nutzen kann. Doku: Kubernetes CSI.
PersistentVolume (PV)
Ein PersistentVolume ist ein API-Objekt für ein Stück Speicher im Cluster, das über die Lebensdauer eines einzelnen Pods hinaus besteht. Bei dynamischer Bereitstellung entstehen PVs bei Bedarf über einen PersistentVolumeClaim. Doku: Persistent Volumes. Ratgeber: Kubernetes-Backup: die vier Ebenen.
PersistentVolumeClaim (PVC)
Ein PersistentVolumeClaim fordert Speicher an: Größe, Zugriffsmodus und Verhalten bei der Freigabe. Der Claim wird als Volume in einen Container eingehängt, die Details des Speichers beschreibt das PersistentVolume. Doku: Persistent Volumes.
StorageClass
Eine StorageClass beschreibt eine Art von Speicher und den Treiber, der ihn bereitstellt, und ermöglicht die dynamische Bereitstellung von PVs. Eine StorageClass kann als Standard festgelegt werden. Doku: Storage classes. Ratgeber: Longhorn vs. Rook-Ceph.
Volume
Ein Volume ist ein Verzeichnis mit Daten, das den Containern eines Pods zugänglich ist. Es lebt so lange wie der Pod und überdauert Container-Neustarts; dauerhafte Daten brauchen ein PersistentVolume. Doku: Volumes.
Sicherheit
Admission Controller
Ein Admission Controller fängt Anfragen an den API Server ab, bevor das Objekt gespeichert wird. Er kann validierend oder mutierend sein, und jeder Admission Controller darf die Anfrage ablehnen. Doku: Admission controllers.
Audit Log
Das Kubernetes-Auditing liefert eine sicherheitsrelevante, chronologische Aufzeichnung der Aktionen im Cluster, erzeugt von Nutzern, von Anwendungen über die Kubernetes-API und von der Control Plane selbst. Doku: Auditing. Ratgeber: Kubernetes NIS2 und ISO 27001: Nachweise im Cluster.
Pod Security Admission
Pod Security Admission ist ein Admission Controller, der die Pod Security Standards (privileged, baseline, restricted) durchsetzt. Die Stufe lässt sich über Labels je Namespace festlegen. Doku: Pod Security Admission.
Role-Based Access Control (RBAC)
RBAC steuert Autorisierungsentscheidungen über vier Objekttypen: Role und ClusterRole definieren Berechtigungen (im Namespace beziehungsweise clusterweit), RoleBinding und ClusterRoleBinding weisen sie Nutzern zu. Doku: Using RBAC authorization. Ratgeber: Kubernetes-Cluster übernehmen: Audit-Checkliste.
Secret
Ein Secret speichert vertrauliche Daten wie Passwörter, OAuth-Tokens oder SSH-Schlüssel. Die Werte sind base64-kodiert und standardmäßig unverschlüsselt gespeichert; die Verschlüsselung im Ruhezustand (encryption at rest) lässt sich konfigurieren. Doku: Secrets.
ServiceAccount
Ein ServiceAccount ist ein Nicht-Personen-Konto, das Anwendungs-Pods und Systemkomponenten eine eigene Identität im Cluster gibt. Berechtigungen erhält es über RBAC. Doku: Service accounts.
Betrieb
Cordon und Drain
kubectl cordon markiert einen Node als nicht planbar. kubectl drain räumt zusätzlich die Pods sicher aus dem Node, etwa vor einem Kernel-Upgrade; ein PodDisruptionBudget wird dabei beachtet. Doku: Safely drain a node.
Horizontal Pod Autoscaler (HPA)
Der HPA skaliert die Zahl der Pod-Replikas automatisch anhand der Ressourcenauslastung oder benutzerdefinierter Metriken. Er skaliert Workload-Ressourcen wie Deployments oder StatefulSets; auf nicht skalierbare Objekte wie DaemonSets lässt er sich nicht anwenden. Doku: Horizontal Pod Autoscaling.
kubeadm
kubeadm ist ein Werkzeug, um Kubernetes schnell zu installieren und einen sicheren Cluster einzurichten. Es installiert sowohl die Control Plane als auch die Komponenten der Worker Nodes. Doku: kubeadm.
PodDisruptionBudget (PDB)
Ein PodDisruptionBudget legt für eine replizierte Anwendung fest, wie viele Pods freiwillig gleichzeitig verdrängt werden dürfen. Unfreiwillige Ausfälle verhindert es nicht, sie zählen aber gegen das Budget. Doku: Specifying a Disruption Budget.
Requests und Limits
Requests legen fest, wie viel CPU und Speicher ein Container anfordert; der Scheduler nutzt sie für die Node-Auswahl. Limits setzt das Kubelet durch, ein CPU-Limit ist ein hartes Limit, das der Kernel erzwingt. Doku: Resource management for containers.
ResourceQuota
Eine ResourceQuota begrenzt den aggregierten Verbrauch pro Namespace: entweder die Zahl der anlegbaren API-Objekte je Typ oder die Gesamtmenge an Infrastrukturressourcen. Doku: Resource quotas.
Taints und Tolerations
Taints verhindern, dass Pods auf einem Node eingeplant werden; Tolerations erlauben es Pods, auf Nodes mit passenden Taints zu laufen. Beide zusammen halten Pods von ungeeigneten Nodes fern. Doku: Taints and tolerations.
Delivery
Custom Resource Definition (CRD)
Eine CustomResourceDefinition erweitert die Kubernetes-API um einen eigenen Ressourcentyp, ohne einen eigenen API-Server zu bauen. Erst ein Controller oder Operator macht aus solchen Objekten Verhalten. Doku: Custom Resources.
GitOps
GitOps ist ein Betriebsverfahren mit vier Prinzipien: Der Soll-Zustand ist deklarativ beschrieben, versioniert und unveränderlich abgelegt, wird von Agenten automatisch abgeholt und fortlaufend abgeglichen. Argo CD und Flux sind bekannte Umsetzungen. Doku: OpenGitOps principles.
Helm
Helm ist der Paketmanager für Kubernetes. Ein Chart bündelt zusammengehörige Kubernetes-Konfigurationen und macht Anwendungen reproduzierbar installierbar und teilbar. Doku: Helm documentation. Ratgeber: Helm 3 auf Helm 4 migrieren.
Infrastructure as Code (IaC)
Infrastructure as Code beschreibt Infrastruktur in versionierbaren Konfigurationsdateien statt per Hand. OpenTofu ist ein solches Werkzeug für Cloud- und On-Premises-Ressourcen. Doku: OpenTofu documentation. Ratgeber: Talos auf Proxmox mit OpenTofu automatisieren.
Kustomize
Kustomize ist ein eigenständiges Werkzeug, das Kubernetes-Objekte über eine kustomization-Datei anpasst. Seit Kubernetes 1.14 unterstützt kubectl das ebenfalls (kubectl apply -k). Doku: Declarative management with Kustomize.
Manifest
Ein Manifest ist die Spezifikation eines Kubernetes-API-Objekts in YAML oder JSON und beschreibt den Soll-Zustand, den Kubernetes aufrechterhält. Aus Docker-Compose-Dateien erzeugt Kompose erste Manifeste. Doku: Working with objects. Ratgeber: Docker Compose zu Kubernetes migrieren mit Kompose.
Operator
Das Operator-Muster verbindet einen Controller mit einer oder mehreren Custom Resources. Läuft eine Anwendung als Controller und führt über die API Aufgaben an einer Custom Resource aus, ist das ein Operator. Doku: Operator pattern.
Stand und Methodik
Stand: 28.10.2026. Die Definitionen folgen dem offiziellen Kubernetes-Glossar und der Kubernetes-Dokumentation (aktuelle Version 1.37), abgerufen am 28.10.2026; zu jedem Begriff steht die zuständige Dokumentationsseite. Die verlinkten Seiten sind englisch, weil die deutsche Fassung des Glossars (kubernetes.io/de) nur teilweise übersetzt ist. Für GitOps, Helm, OpenTofu und Service Mesh dienen die Seiten der Projekte beziehungsweise des CNCF als Quelle, weil diese Begriffe nicht zum Kubernetes-Kern gehören; die CSI-Definition folgt dem Kubernetes-Glossar, die verlinkte Dokumentation ist die des CSI-Projekts. Die Auswahl der 60 Begriffe folgt unseren Ratgebern und dem Clusterbetrieb; der offizielle Glossar enthält mehr. Versionsangaben (Sidecar Container stable seit 1.33, Ingress eingefroren) geben den Stand der Dokumentation wieder.
Unser Vorgehen bei WZ-IT
Beim Betrieb eines Clusters sind die Zuständigkeiten je Ebene festgelegt, von Control Plane und Worker-Nodes über Plattform-Add-ons und Backups bis zu Monitoring und Incident-Reaktion. Die Aufteilung beschreibt Managed Kubernetes, die Prüfung eines bestehenden Clusters das Cluster-Audit als Konfigurations-Review mit Bericht. Welche Punkte eine Übernahme umfasst, zeigt Kubernetes-Cluster übernehmen: Audit-Checkliste.
Weiterführende Guides
- Was ist Kubernetes?
- Brauchen wir Kubernetes?
- Kubernetes-Cluster übernehmen: Audit-Checkliste
- Kubernetes-Backup: die vier Ebenen
- Gateway API vs. Ingress
- Istio vs. Linkerd vs. Cilium
Cluster verstehen und betreiben lassen: Die Kubernetes-Leistungen von WZ-IT umfassen Aufbau, Betrieb und Prüfung von Clustern.
