[email protected]

Basics · Kubernetes

Kubernetes glossary: the key terms explained

Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual professional, legal or tax advice.

Understand, build and operate Kubernetes? WZ-IT designs, operates and reviews Kubernetes clusters. View Kubernetes services

This glossary explains 60 Kubernetes terms in short definitions. They follow the official Kubernetes glossary and the documentation for the current version 1.37; every entry links to the relevant docs page and, where one exists, to one of our guides. Seven groups organize the terms, and an alphabetical index comes first. As of 28 October 2026.

Table of contents

Alphabetical index

Basics

API Server

The API server (kube-apiserver) is the front end of the control plane and exposes the Kubernetes API. It scales horizontally: several instances can run and share the traffic. Docs: kube-apiserver. Guides: Access Kubernetes privately with NetBird.

Cluster

A cluster is a set of worker machines (nodes) that run containerized applications; every cluster has at least one worker node. The control plane manages the nodes and pods and usually runs across several machines in production. Docs: Cluster components. Guides: Install Kubernetes on Proxmox: k3s with three VMs.

Container

A container is a lightweight, portable, executable image of software with all its dependencies. Containers decouple applications from the host infrastructure and make deployment and scaling easier. Docs: Containers. Guides: Kubernetes vs Docker Compose vs Coolify.

Container Runtime

The container runtime starts and stops containers on every node, for example containerd or CRI-O. Kubernetes supports any implementation of the Container Runtime Interface (CRI), through which the kubelet talks to it. Docs: Container runtimes.

Control Plane

The control plane is the layer that exposes the Kubernetes API and manages the lifecycle of containers. It consists of etcd, the API server, the scheduler and the controller manager, among others. Docs: Cluster components. Guides: Kubernetes on Proxmox.

Controller

A controller is a control loop that watches the state of the cluster and requests changes until the current state moves closer to the desired state. Custom controllers are the basis of the Operator pattern. Docs: Controllers.

Distribution

A distribution bundles Kubernetes with an installer and defaults, for example k3s, RKE2 or Talos Linux. The CNCF checks offerings in the Certified Kubernetes program for the required APIs. Docs: Certified Kubernetes. Guides: k3s vs. RKE2 vs. Talos, What is Talos Linux?, Install Talos Linux on Proxmox.

etcd

etcd is the consistent, highly available key-value store for all API server data, that is, the state of the cluster. For self-operated clusters the etcd snapshot is part of the backup; with managed services responsibility depends on the offering. Docs: Operating etcd clusters. Guides: Kubernetes backup: the four layers.

kubectl

kubectl is the command line tool for talking to a cluster's control plane through the Kubernetes API. It creates, inspects, updates and deletes objects. Docs: kubectl.

kubelet

The kubelet is the agent that runs on every node. It makes sure that the containers described in the PodSpecs run in a pod and are healthy; it does not manage containers that Kubernetes did not create. Docs: kubelet.

Kubernetes

Kubernetes is an open source platform that deploys, scales and manages containerized applications across multiple nodes. It works declaratively: you describe the desired state and controllers align the actual state with it. Docs: Kubernetes overview. Guides: What is Kubernetes?, Do we need Kubernetes?.

Label

Labels are key-value pairs attached to objects such as pods. They organize objects and select subsets; a Service finds its pods through a label selector. Docs: Labels and selectors.

Managed Kubernetes

With managed Kubernetes a provider operates the control plane. In general the Kubernetes glossary describes a managed service as a software offering maintained by a third-party provider. The division of tasks between provider and customer differs per offering. Docs: Managed Service. Guides: European Kubernetes providers compared, Kubernetes on Hetzner, Kubernetes on OVHcloud.

Namespace

A namespace isolates groups of resources within a cluster. Names must be unique only within a namespace; cluster-wide resources such as nodes or StorageClasses belong to no namespace. A ResourceQuota limits consumption. Docs: Namespaces.

Node

A node is a worker machine in Kubernetes, virtual or physical, managed by the control plane. Among other things the kubelet, kube-proxy and a container runtime run on it. Nodes can be operated as VMs on a hypervisor. Docs: Nodes. Guides: Proxmox vs Kubernetes.

Scheduler

The kube-scheduler is the control plane component that watches for newly created pods with no node assigned and selects a node for them. The decision considers resource requirements, affinity rules and taints, among other factors. Docs: kube-scheduler.

Workloads

CronJob

A CronJob starts a Job on a schedule in cron format, comparable to a line in a crontab. Docs: CronJob.

DaemonSet

A DaemonSet ensures that all or selected nodes run a copy of a pod, typically for log collectors and monitoring agents. When a node is added, a pod is added to it too. Docs: DaemonSet.

Deployment

A Deployment manages a replicated application, typically made of pods with no local state. It describes the desired state declaratively and replaces pods step by step on changes; for workloads with local state the StatefulSet is intended. Docs: Deployments.

Job

A Job runs a finite or batch task to completion. It creates one or more pods and ensures that a specified number of them terminate successfully. Docs: Jobs.

Pod

A pod is the smallest and simplest Kubernetes object: a set of running containers in the cluster. It usually holds one main container and optionally sidecar containers; pods are commonly managed by a Deployment. Docs: Pods.

Probe

A probe is a check that the kubelet runs periodically against a running container. Liveness, readiness and startup probes show whether a container is healthy, can receive traffic or is still starting. Docs: Liveness, readiness and startup probes.

ReplicaSet

A ReplicaSet keeps a specified number of replica pods running. The documentation recommends using a Deployment, which manages ReplicaSets and provides declarative updates, instead of using a ReplicaSet directly. Docs: ReplicaSet.

Sidecar Container

Sidecar containers run next to the main container of a pod and provide a pod-local service, for example logging or a proxy. Unlike init containers they keep running after startup; the feature has been stable since Kubernetes 1.33. Service meshes use this pattern. Docs: Sidecar containers. Guides: Istio vs. Linkerd vs. Cilium.

StatefulSet

A StatefulSet manages pods with a sticky identity and a defined order; each pod keeps a persistent identifier across rescheduling. That makes it easier to match existing volumes to replacement pods, for example for databases. Docs: StatefulSets.

Networking

CNI (Container Network Interface)

CNI is the plugin interface through which a network plugin connects pods to the cluster network; Cilium and Calico are common plugins. Whether a NetworkPolicy takes effect depends on the plugin. Docs: Network plugins. Guides: Cilium vs. Calico.

DNS

Kubernetes creates DNS records for services and pods so that applications reach each other by stable names instead of IP addresses. Docs: DNS for Services and Pods.

Gateway API

The Gateway API is a family of API kinds for service networking in Kubernetes: role-oriented, protocol-aware and extensible (GatewayClass, Gateway, HTTPRoute and more). The Kubernetes project recommends Gateway over Ingress. Docs: Gateway API. Guides: Gateway API vs. Ingress.

Ingress

Ingress is an API object for external, usually HTTP access to services, with load balancing, TLS termination and name-based virtual hosting. The Ingress API is frozen: it stays in place but is no longer developed. Docs: Ingress. Guides: Gateway API vs. Ingress.

Ingress Controller

An ingress controller implements Ingress objects; without a running controller an Ingress has no effect. Docs: Ingress controllers. Guides: Migrate from ingress-nginx to the Gateway API.

kube-proxy

kube-proxy is a network proxy that runs on each node and implements part of the Service concept. It maintains network rules that allow network communication to your pods from inside and outside the cluster. Docs: kube-proxy.

LoadBalancer

LoadBalancer is a Service type that exposes the service through an external load balancer. Kubernetes has no load balancing component of its own; you provide one or integrate a cloud provider, on your own hardware for example MetalLB or kube-vip. Docs: Service type LoadBalancer. Guides: MetalLB vs. kube-vip.

NetworkPolicy

A NetworkPolicy specifies which pods may communicate with each other and with other network endpoints. It takes effect only if the CNI plugin implements it; without a controller that implements it, the object has no effect. Docs: Network policies. Guides: Cilium vs. Calico.

Service

A Service makes an application that runs as one or more pods reachable on the network. Pods are usually selected by a label selector; when the pods change, the Service stays stable. Types are ClusterIP, NodePort, LoadBalancer and ExternalName. Docs: Service.

Service Mesh

A service mesh moves encryption, access rules, traffic control and metrics between services into the infrastructure. The classic approach pairs each pod with a proxy, while sidecarless approaches use node-level or kernel functions (eBPF). Docs: CNCF: Service Mesh. Guides: Istio vs. Linkerd vs. Cilium.

Storage

CSI (Container Storage Interface)

CSI is the standard through which storage vendors expose their systems to Kubernetes without adding code to the Kubernetes repository (out-of-tree drivers). A CSI driver must be deployed in the cluster before a StorageClass can use it. Docs: Kubernetes CSI.

PersistentVolume (PV)

A PersistentVolume is an API object for a piece of storage in the cluster that outlives any individual pod. With dynamic provisioning, PVs are created on demand through a PersistentVolumeClaim. Docs: Persistent Volumes. Guides: Kubernetes backup: the four layers.

PersistentVolumeClaim (PVC)

A PersistentVolumeClaim requests storage: size, access mode and reclaim behavior. The claim is mounted as a volume in a container; the details of the storage are described by the PersistentVolume. Docs: Persistent Volumes.

StorageClass

A StorageClass describes a kind of storage and the driver that provides it, and enables dynamic provisioning of PVs. A StorageClass can be set as the default. Docs: Storage classes. Guides: Longhorn vs. Rook-Ceph.

Volume

A volume is a directory containing data that is accessible to the containers in a pod. It lives as long as the pod and survives container restarts; durable data needs a PersistentVolume. Docs: Volumes.

Security

Admission Controller

An admission controller intercepts requests to the API server before the object is persisted. It can be validating or mutating, and any admission controller may reject the request. Docs: Admission controllers.

Audit Log

Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster, generated by users, by applications that use the Kubernetes API and by the control plane itself. Docs: Auditing. Guide: Kubernetes NIS2 and ISO 27001: cluster evidence.

Pod Security Admission

Pod Security Admission is an admission controller that enforces the Pod Security Standards (privileged, baseline, restricted). The level can be set per namespace through labels. Docs: Pod Security Admission.

Role-Based Access Control (RBAC)

RBAC manages authorization decisions through four object kinds: Role and ClusterRole define permissions (in a namespace or cluster-wide), RoleBinding and ClusterRoleBinding grant them to users. Docs: Using RBAC authorization. Guides: Taking over a Kubernetes cluster: audit checklist.

Secret

A Secret stores sensitive data such as passwords, OAuth tokens or SSH keys. Values are base64-encoded and stored unencrypted by default; encryption at rest can be configured. Docs: Secrets.

ServiceAccount

A ServiceAccount is a non-human account that gives application pods and system components a distinct identity in the cluster. It receives permissions through RBAC. Docs: Service accounts.

Operations

Cordon and drain

kubectl cordon marks a node as unschedulable. kubectl drain additionally safely evicts the pods from the node, for example before a kernel upgrade; a PodDisruptionBudget is respected in the process. Docs: Safely drain a node.

Horizontal Pod Autoscaler (HPA)

The HPA automatically scales the number of pod replicas based on resource utilization or custom metrics. It scales workload resources such as Deployments or StatefulSets; it cannot be applied to objects that cannot be scaled, such as DaemonSets. Docs: Horizontal Pod Autoscaling.

kubeadm

kubeadm is a tool for quickly installing Kubernetes and setting up a secure cluster. It installs both the control plane and the worker node components. Docs: kubeadm.

PodDisruptionBudget (PDB)

A PodDisruptionBudget specifies for a replicated application how many pods may be voluntarily evicted at the same time. It cannot prevent involuntary disruptions, but they count against the budget. Docs: Specifying a Disruption Budget.

Requests and limits

Requests set how much CPU and memory a container asks for; the scheduler uses them to pick a node. The kubelet enforces limits, and a CPU limit is a hard limit that the kernel enforces. Docs: Resource management for containers.

ResourceQuota

A ResourceQuota constrains aggregate consumption per namespace: either the number of API objects that can be created by type or the total amount of infrastructure resources. Docs: Resource quotas.

Taints and tolerations

Taints prevent pods from being scheduled onto a node; tolerations allow pods to run on nodes with matching taints. Together they keep pods away from inappropriate nodes. Docs: Taints and tolerations.

Delivery

Custom Resource Definition (CRD)

A CustomResourceDefinition extends the Kubernetes API with your own resource type without building a complete custom API server. Only a controller or operator turns such objects into behavior. Docs: Custom Resources.

GitOps

GitOps is an operating model with four principles: the desired state is described declaratively, stored versioned and immutable, pulled automatically by agents and continuously reconciled. Argo CD and Flux are well-known implementations. Docs: OpenGitOps principles.

Helm

Helm is the package manager for Kubernetes. A chart bundles related Kubernetes configurations and makes applications reproducibly installable and shareable. Docs: Helm documentation. Guides: Migrate from Helm 3 to Helm 4.

Infrastructure as Code (IaC)

Infrastructure as code describes infrastructure in versionable configuration files instead of by hand. OpenTofu is such a tool for cloud and on-premises resources. Docs: OpenTofu documentation. Guides: Automate Talos on Proxmox with OpenTofu.

Kustomize

Kustomize is a standalone tool that customizes Kubernetes objects through a kustomization file. Since Kubernetes 1.14, kubectl supports this as well (kubectl apply -k). Docs: Declarative management with Kustomize.

Manifest

A manifest is the specification of a Kubernetes API object in YAML or JSON and describes the desired state that Kubernetes maintains. Kompose generates first manifests from Docker Compose files. Docs: Working with objects. Guides: Migrate Docker Compose to Kubernetes with Kompose.

Operator

The operator pattern links a controller to one or more custom resources. If a running application acts as a controller and carries out tasks against a custom resource through the API, that is an operator. Docs: Operator pattern.

Status and methodology

As of 28 October 2026. The definitions follow the official Kubernetes glossary and the Kubernetes documentation (current version 1.37), retrieved on 28 October 2026; every term links to the relevant documentation page. The German glossary (kubernetes.io/de) is only partly translated, so the linked documentation is in English. For GitOps, Helm, OpenTofu and service mesh, project or CNCF pages serve as sources, because these terms are not part of Kubernetes core; the CSI definition follows the Kubernetes glossary, and the linked documentation is that of the CSI project. The selection of 60 terms follows our guides and cluster operations; the official glossary contains more. Version statements (sidecar containers stable since 1.33, Ingress frozen) reflect the state of the documentation.

Our approach at WZ-IT

When a cluster is operated, responsibilities are defined per layer, from the control plane and worker nodes through platform add-ons and backups to monitoring and incident response. The split is described under Managed Kubernetes, the review of an existing cluster under the cluster audit (a configuration review with a report). Which points a takeover covers is shown in Taking over a Kubernetes cluster: audit checklist.

Further guides

Understand your cluster and have it operated: The Kubernetes services from WZ-IT cover building, operating and reviewing clusters.

Rather have it operated?

You'd rather not run Kubernetes yourself? WZ-IT handles setup, operations and maintenance - privacy-focused from Germany.

Enquiry

Design, take over, or operate Kubernetes

We design and operate Kubernetes on bare metal, Proxmox, and European cloud platforms, including networking, GitOps, observability, and backups.

  • Straight with Timo and Robin - no sales team, no pitch
  • A professional assessment of your situation
  • Concrete next steps for infrastructure, software or AI

The conversation is free and non-binding.

WZ-IT supported us professionally with the provisioning and setup of NetBird. Alongside the technical implementation, we also received well-founded advice on connecting our Kubernetes clusters. The recommendations were concrete and directly actionable. The collaboration was consistently reliable, fast and on equal terms. We can recommend WZ-IT without reservation.
Kai ClaußHead of Development, SweetConnect GmbH
Timo and Robin, founders of WZ-IT

Design, take over, or operate Kubernetes

WZ-IT supported us professionally with the provisioning and setup of NetBird. Alongside the technical implementation, we also received well-founded advice on connecting our Kubernetes clusters. The recommendations were concrete and directly actionable. The collaboration was consistently reliable, fast and on equal terms. We can recommend WZ-IT without reservation.
Kai ClaußHead of Development, SweetConnect GmbH

Frequently Asked Questions

Answers to the most important questions

Knowledge

More on Kubernetes

Companies worldwide trust WZ-IT

  • Stadtwerke Brühl
  • DGHO e.V.
  • solarwerkstatt berlin
  • Krüger Dirndl
  • ABCO Water Systems
  • Golem.de
  • EVADXB
  • nextGYM
  • AInergy
  • ml&s
  • Odiseo Solutions
  • Annota
  • ARGE
  • SweetConnect GmbH
  • Aphy AG
  • CORGOS
  • Rekorder
  • SolidProof
  • Yonju
  • Keymate
  • Paritel
  • Mr. Clipart
  • Millenium
  • Negosh
  • Führerscheinmacher
  • BTI
  • Deutsche Gesellschaft für Datenschutz
Read client reviews