Kubernetes Concepts in 10 Minutes: Pods, Deployments, Services

Kubernetes looks intimidating because it wraps simple ideas in jargon. Strip away the operators, the CRDs, and the dashboards, and three objects do almost all of the real work: pods, deployments, and services. If you can explain how those three relate, you understand enough to run real workloads. This is that explanation, with no clusters and no installs — just a mental model you can carry into any Kubernetes project, including the single-node k3s clusters we will build together later on a plain Netbay VPS.

Pods: the smallest unit of compute

A pod is the atomic unit Kubernetes schedules. It runs one or more containers that share a network namespace, an IP address, and storage volumes. In practice most pods run a single container, but the pod is the layer that ties related containers together — like an app container and a log-shipper sidecar that need to talk over localhost.

You rarely create pods directly. You describe the desired workload in a Deployment, and Kubernetes creates and manages pods for you.

Deployments: the desired state

A Deployment is a declarative description: "run three copies of this image, always." You write the desired state in a YAML file, apply it, and Kubernetes works continuously to match reality to that file. If a pod dies, the Deployment replaces it. If you bump the image tag, the Deployment rolls out new pods gradually.

Services: stable network endpoints

Pods are ephemeral — they get recycled and their IPs change. A Service is a stable virtual IP and DNS name in front of a set of pods. It picks pods with a label selector and load-balances traffic across them. Without services, clients would have nothing stable to talk to.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

How the pieces connect

The Deployment owns the pods; the Service owns the traffic. Clients talk to the Service name (web), the Service forwards to any matching pod by label, and the Deployment keeps the right number of matching pods alive. That is the whole loop.

Working with the objects

Once a cluster is running, the workflow is uniform: write a manifest, apply it, and inspect state.

kubectl apply -f nginx.yaml
kubectl get pods,deployments,services
kubectl rollout status deployment/web
kubectl logs deployment/web

The practical sequence

1. Write a Deployment that declares the image and replica count.
2. Write a Service that selects those pods by label.
3. Apply both files.
4. Confirm pods reach Ready and the Service has endpoints.

Takeaway

Remember the one-liner: Deployments manage pod lifecycles, Services route traffic to pods by label. Everything else in Kubernetes is an extension of that loop. When you are ready to try it, you can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds and install k3s to follow along — netbayhosts.in.