Kubernetes Glossary: 28 Essential Terms Explained [2026]

This glossary covers 28 essential Kubernetes terms — from core workloads to networking, storage, scaling, and cost. Use the category headings to navigate, or browse straight through. Each term is defined in plain language accurate enough for engineers who work with clusters daily.

---

Core Workloads

Pod

The smallest deployable unit in Kubernetes. A Pod wraps one or more containers that share the same network IP, storage volumes, and lifecycle. Kubernetes schedules, scales, and restarts Pods — not individual containers. Every workload running in a cluster lives inside a Pod. See the full guide: What is a Pod in Kubernetes.

Node

A worker machine in a Kubernetes cluster — either a virtual machine or a physical server. Each Node runs a kubelet (which communicates with the control plane), a container runtime (such as containerd), and kube-proxy (which handles networking). Pods are scheduled onto Nodes by the control plane scheduler.

Cluster

A Kubernetes cluster is the complete environment: one or more control plane components (API server, scheduler, etcd, controller manager) plus a set of worker Nodes that run workloads. Everything in Kubernetes operates within the scope of a cluster.

Deployment

A Deployment declares the desired state for a set of identical Pods and keeps the cluster working toward that state. It manages an underlying ReplicaSet and handles rolling updates, rollbacks, and self-healing automatically. Deployments are the standard way to run stateless applications in Kubernetes.

ReplicaSet

A ReplicaSet ensures that a specified number of Pod replicas are running at any given time. If a Pod crashes or is deleted, the ReplicaSet creates a replacement. You rarely create ReplicaSets directly — Deployments manage them for you — but understanding them explains how Kubernetes maintains replica counts.

StatefulSet

StatefulSet is the workload controller for stateful applications. Unlike a Deployment, it gives each Pod a stable, persistent identity — a fixed hostname and an ordered index — and pairs each Pod with its own PersistentVolumeClaim. This makes StatefulSets the right choice for databases, message queues, and anything that needs stable storage and predictable network names.

DaemonSet

A DaemonSet ensures that exactly one Pod runs on every Node in the cluster (or a selected subset of Nodes). When a new Node joins the cluster, the DaemonSet automatically schedules a Pod on it. Common use cases are log collectors, monitoring agents (such as Prometheus node-exporter), and network plugins.

Job / CronJob

A Job runs a Pod to completion — it keeps retrying until the task succeeds or a configured failure threshold is reached. A CronJob is a Job with a cron-style schedule; Kubernetes creates a new Job on each trigger. Use these for batch processing, database migrations, or any workload that should run once or on a schedule rather than continuously.

---

Namespaces and Organization

Namespace

A Namespace is a virtual partition inside a Kubernetes cluster. It provides a scope for resource names, access policies, and resource quotas. Two objects with the same name can coexist if they live in different Namespaces. Teams commonly use Namespaces to separate environments (dev, staging, production) or applications sharing a single cluster. See the full guide: What is a Namespace in Kubernetes.

Label

A Label is a key/value pair attached to any Kubernetes object — Pods, Nodes, Services, and more. Labels are used for selection and grouping: a Service selects the Pods it routes to by matching labels, and a Deployment knows which Pods it owns the same way. Labels carry identifying information and are queryable via label selectors.

Annotation

An Annotation is also a key/value pair on a Kubernetes object, but unlike Labels it is not used for selection. Annotations store non-identifying metadata: tool-specific configuration, build information, links to documentation, or hints for controllers and admission webhooks. They can hold arbitrary strings of any length.

---

Networking

Service

A Service is a stable network endpoint in front of a set of Pods. Because Pod IP addresses change whenever a Pod is recreated, Services provide a fixed virtual IP (ClusterIP) and DNS name that routes to healthy Pods automatically. Services come in several types: ClusterIP, NodePort, and LoadBalancer.

Ingress

An Ingress defines HTTP and HTTPS routing rules for traffic entering the cluster from outside. It maps hostnames and URL paths to internal Services, enabling a single external IP to serve multiple applications. An Ingress Controller (such as NGINX or Traefik) must be running in the cluster to enforce the rules. See the full guide: What is Ingress in Kubernetes.

ClusterIP

ClusterIP is the default Service type. It assigns a virtual IP address that is reachable only from within the cluster — other Pods can connect to it, but it is not accessible from outside. ClusterIP is appropriate for internal communication between microservices.

LoadBalancer

A LoadBalancer Service provisions an external load balancer from the underlying cloud provider (AWS ELB, GCP Cloud Load Balancer, Azure Load Balancer). The cloud assigns a public IP that routes external traffic into the cluster. Each LoadBalancer Service typically creates a dedicated cloud load balancer, which carries a cost.

NetworkPolicy

A NetworkPolicy is a set of firewall rules that control which Pods can communicate with which other Pods or external endpoints. By default, Kubernetes allows all Pod-to-Pod traffic. NetworkPolicies let you enforce a least-privilege model — for example, allowing only the frontend Pods to reach the backend Pods on a specific port.

---

Configuration and Storage

ConfigMap

A ConfigMap stores non-sensitive configuration data as key/value pairs. Applications consume ConfigMaps either as environment variables or as files mounted into the container filesystem. Separating configuration from container images means you can change settings without rebuilding the image.

Secret

A Secret stores sensitive data — passwords, API tokens, TLS certificates — in the cluster. The values are base64-encoded at rest (and optionally encrypted at the etcd level). Like ConfigMaps, Secrets can be injected as environment variables or mounted as files. Base64 encoding is not encryption; proper RBAC and etcd encryption are required to treat Secrets as genuinely secret.

PersistentVolume (PV)

A PersistentVolume is a piece of storage provisioned in the cluster — either by an administrator ahead of time or dynamically by a StorageClass. It exists independently of any individual Pod and survives Pod deletion. A PV has a defined capacity, access mode, and reclaim policy (Retain, Delete, or Recycle).

PersistentVolumeClaim (PVC)

A PersistentVolumeClaim is a request for storage made by a Pod or StatefulSet. It specifies the size and access mode needed, and Kubernetes binds it to a matching PV. The PVC is what workloads reference in their spec — the underlying PV is an implementation detail. Unbound or abandoned PVCs are a common source of unnecessary cloud storage costs.

StorageClass

A StorageClass defines the provisioner, parameters, and reclaim policy for a class of storage. When a PVC references a StorageClass, Kubernetes dynamically provisions a PV of that type instead of requiring an admin to create it manually. Common provisioners include AWS EBS, GCP Persistent Disk, and Azure Disk.

---

Scaling and Resources

Resource Requests

A resource request is the minimum amount of CPU or memory a container declares it needs. The Kubernetes scheduler uses requests to decide which Node can accommodate a Pod. A Node can only run a Pod if it has enough unreserved capacity to satisfy all of the Pod's requests. Underspecified requests lead to poor scheduling decisions and noisy-neighbor problems.

Resource Limits

A resource limit is the maximum CPU or memory a container is allowed to consume. If a container exceeds its memory limit, the kernel OOM-kills it. If it exceeds its CPU limit, it is throttled. Limits protect other workloads on the same Node from a runaway container — but setting them too low causes unnecessary throttling and degraded performance.

HPA (Horizontal Pod Autoscaler)

The Horizontal Pod Autoscaler automatically adjusts the number of Pod replicas in a Deployment or StatefulSet based on observed metrics — most commonly CPU or memory utilization, but also custom metrics via the Metrics API. When load increases, HPA adds Pods; when it drops, HPA removes them. HPA scales out (more Pods), not up (bigger Pods).

VPA (Vertical Pod Autoscaler)

The Vertical Pod Autoscaler analyses historical resource usage for a workload and automatically adjusts container resource requests and limits to match actual consumption. Where HPA changes replica count, VPA changes the resource allocation of each replica. Using VPA reduces both over-provisioning waste and the risk of OOM kills from under-provisioning.

Cluster Autoscaler

The Cluster Autoscaler adds Node capacity when Pods cannot be scheduled due to insufficient resources, and removes underutilized Nodes when their workloads can be consolidated elsewhere. It talks directly to the cloud provider API to provision or decommission VMs. Without it, clusters either run short on capacity or accumulate idle Nodes that generate cost with no workload.

---

Cost and Waste

Orphaned Resource

An orphaned resource is a Kubernetes object — a ConfigMap, Secret, PVC, Service, or other resource — that is no longer referenced or used by any active workload. Orphaned resources accumulate silently as applications evolve: services get replaced, Secrets get renamed, PVCs get left behind after StatefulSets are deleted. They consume cluster quota and, in the case of PVCs, continue to bill for cloud storage even after the workload that needed them is gone.

Resource Waste

Resource waste is the gap between the resources allocated to a workload (via requests and limits) and the resources that workload actually uses. In most production clusters, CPU and memory requests are set conservatively — often 2–5x above real usage — because engineers would rather over-provision than risk an outage. That gap translates directly to idle compute that shows up on your cloud bill. Identifying and right-sizing over-provisioned workloads is one of the highest-ROI actions in Kubernetes cost optimization.

FinOps

FinOps (Financial Operations) is the practice of bringing financial accountability to cloud infrastructure spending. In a Kubernetes context, it means attributing costs to teams, services, or namespaces; setting budgets and alerts; and creating feedback loops between engineering decisions and their cost consequences. FinOps is as much organizational as it is technical — it requires shared ownership of cloud costs across engineering, finance, and product teams.

---

Tooling

kubectl

kubectl is the official command-line tool for communicating with a Kubernetes cluster's API server. It is the primary interface for deploying workloads, inspecting resources, reading logs, and running one-off commands against a cluster. kubectl reads cluster credentials and context from a kubeconfig file.

Helm

Helm is the package manager for Kubernetes. It bundles Kubernetes manifests into reusable, versioned packages called charts. A chart can be configured with a values file and deployed, upgraded, or rolled back as a single unit. Helm is widely used for deploying third-party software (ingress controllers, monitoring stacks, databases) and for managing complex internal application deployments.

kubeconfig

A kubeconfig is a YAML file — typically located at ~/.kube/config — that stores the credentials, cluster endpoints, and context information kubectl uses to connect to one or more clusters. A context in the kubeconfig maps a cluster, a user, and a default Namespace together. Switching between clusters is done by switching the active context.

---

Running Kubernetes in Production?

Orphaned resources — unused ConfigMaps, Secrets, PVCs, and Services — are one of the biggest sources of hidden waste in production clusters. They accumulate silently as applications evolve, and most observability tools don't surface them. KorPro scans your cluster and shows you exactly what's costing you money, with no cloud credentials required.

Run a free scan →