Kubernetes Pods, Nodes, Clusters
What Pods, Nodes and Clusters Are in Kubernetes
Kubernetes pods are the smallest units that Kubernetes schedules: one or more containers that always run together on the same machine. The containers in a pod share one network address and can share storage volumes, so they can reach each other over localhost. Most pods hold a single container, with extra containers added only for helpers such as log shippers.
Pods run on nodes. A node is a machine, physical or virtual, that has joined a cluster and provides CPU and memory for workloads. The scheduler chooses a node for each pod based on the resources the pod requests and rules such as spreading replicas across machines.
A cluster is the complete set of nodes plus the control plane that manages them. Teams usually run separate clusters for production and testing. Inside one cluster, namespaces divide resources into logical groups, for example one per team or application. For the reasons this coordination is needed, see what Kubernetes does.
Deployments and Services: How Pods Are Managed and Reached
Pods are rarely created by hand. The image each pod runs is pulled from a container registry, and a deployment declares how many identical pods should run and which image they use. The deployment creates and replaces pods to match that count, and it performs rolling updates, so a new version replaces old pods gradually.
Pods are temporary. When a pod is replaced, it receives a new internal address. A service solves this by giving a stable name and address to the group of pods that match its labels. Traffic sent to the service is spread across healthy pods, so other applications never need to track individual addresses.
An ingress handles HTTP and HTTPS traffic from outside the cluster. It routes requests by hostname or path to the right service. An ingress only works when an ingress controller, a separate component that implements its rules, is running in the cluster.
How a News Site Uses Pods, Services and an Ingress
A news website runs its frontend in a deployment with six pods spread across three nodes in one cluster. A service gives those pods one internal name, and an ingress routes requests for the site's domain to that service. If one node fails, the deployment starts replacement pods on the remaining nodes, and the service keeps sending traffic only to healthy pods.
Frequently asked questions
Can a Pod Contain More Than One Container?
Yes. A pod can run several containers that must share a network address and storage, such as an application with a helper container that ships its logs. Containers that do not need to share these resources usually belong in separate pods.
Is a Pod the Same as a Container?
No. A container is a running process packaged with its dependencies. A pod is the unit Kubernetes schedules, and it wraps one or more containers. Kubernetes manages pods rather than individual containers. The Kubernetes vs Docker article explains how the two relate.
How Many Nodes Does a Cluster Need?
There is no fixed number. A cluster can run on a single machine for development, and large production clusters can have thousands of nodes. High availability needs several nodes, so that a single failure does not take down the cluster's workloads. The right size depends on the workload.