A breakdown, in my own words, of Kubernetes key concepts.


A pod is the smallest unit of compute available to you, the user of kubernetes. There may be deeper granularity beyond pod, but as far as what you (as the user of k8s) are allowed to touch and/or know about, this is the smallest unit.

A Pod can be one or more containers, however the key here being that if it’s more than one container then they are co-located and co-scheduled, deployed at the same time, and tightly coupled. In practice, a Pod is usually one container unless two processes need to share common hard-resources such as disk space.

Pod. It’s like the smallest scalable unit of your application.

In terms of Docker concepts, a Pod is similar to a group of Docker containers with shared namespaces and shared file volumes.


A Node refers to, usually, one machine. A Pod always runs on a Node. A Node can (and usually does) have multiple pods running inside it. Each Node is managed by the Kubernetes control plane. The Kubernetes control plane usually handles scheduling Pods across Nodes, and does this automatically based on available resources in each Node.

A Node in Kubernetes must have at least:

  • Kubelet running on it, for interacting with the Kubernetes cluster at large.
  • A container runtime, for running the pods inside it.


K8s doc

An “application” running on a set of pods exposed to some network (either internal, or even outside world) is a service in kubernetes. This is an abstraction over a set of pods, basically. It can be, for example, one microservice. The pods that make up a service are coagulated by the service’s selector. Aka, a selector dictates what pods a service can point to.

apiVersion: v1
kind: Service
  name: my-service
  selector: MyApp
    - protocol: TCP
      port: 80
      targetPort: 9376

The selector here is any pod that has the name MyApp.

Kubernetes also provides some mechanisms for service registry and service discovery, so that services inside Kubernetes can figure out where to find other services. These features are provided by a REST-ish API served up by the Kubernetes API server.

You can, for example, perform service registry by POST a Service definition to the API server to create a new instance.

Services can be exposed internally within the cluster (ClusterIP), externally to the internet (NodePort or LoadBalancer), or through custom configurations.


A deployment is an abstraction on top of Kubernetes’s ReplicaSet, used for managing the deployment of a set of pods. This is useful for things like rolling updates, rollbacks, etc. When you update a deployment, it will create a new ReplicaSet under the hood, and perform the rolling update, switching over workloads to the new replica set.

Last modified: April 12, 2023
© 2023