Kubernetes Terminology

The following list contains the key terms and components that Kubernetes uses in its structure.

Pod

The smallest deployable unit in Kubernetes. It usually runs a single application, but it can sometimes include multiple tightly connected applications. Each application runs in its own container. Every pod has its own IP address, making it appear as a separate computer within the Kubernetes overlay network. When multiple containers are deployed within a single pod, each container listens on a different port and can communicate with the others over localhost.

Service

Provides a stable, permanent IP address, while pods' addresses change over time because pods can be created and removed dynamically. When multiple instances of an application are running, the service automatically balances traffic between the pods. When one application communicates with another inside the cluster, it connects through the service rather than directly to individual pods. In addition, a service can be configured to expose an application to external traffic, allowing users or systems outside the Kubernetes cluster to access it.

Node

A physical or virtual machine that runs part of your application in a Kubernetes cluster. Nodes provide the CPU, memory, and storage needed to run pods.

Worker Node

Runs the actual workloads — the pods that host your applications. Kubernetes automatically distributes pods across worker nodes and restarts them elsewhere if a node fails, ensuring availability and resilience.

Control-Plane (Master) Node

Runs the core components that manage the cluster, such as the API server, scheduler, and controller manager. It makes decisions about where pods should run and continuously monitors the overall state of the cluster.

Kubernetes Cluster

The complete system composed of a group of nodes that work together as a single unit to run your applications. The cluster nodes serve one or more of the following roles:

• Control plane—Manages the cluster and decides where pods should run.

• Worker—Hosts and executes the applications inside pods.

• Datastore—Stores the cluster state and configuration.

Overlay Network

An overlay network in Kubernetes is a virtual network that spans all nodes in the cluster. It assigns IP addresses to pods and services, allowing them to communicate with each other as if they were on the same local network, regardless of where they physically run. The underlying node network remains hidden from the pods, simplifying communication and connectivity.

Load Balancer

External traffic coming from outside the Kubernetes cluster is first sent to a load balancer, which distributes incoming requests across the worker nodes. In a typical setup where an ingress controller is used, each request that reaches a worker node is then routed to an ingress controller pod, which handles further routing inside the cluster.

Ingress Controller

While a service can expose an application to the outside world, exposing each service separately would require a different load balancer and, therefore, a different hostname for each external service. To make this easier, Kubernetes often uses a special component called an ingress controller. It routes external requests based on rules such as the hostname or URL path—for example, sending different parts of a website to different services. In essence, an ingress controller acts as a Kubernetes-native reverse proxy or HTTP gateway, managing and directing all incoming web traffic. The ingress controller itself is just an application running inside Kubernetes—it runs in one or more pods and has a service associated with it, just like any other workload. Typically, it is the only component directly exposed to the outside world.

Resource

A Kubernetes resource is an object that represents part of the desired state of a Kubernetes cluster, such as namespace or node. Learn more