Kubernetes Concepts Explained Simply

Kubernetes Concepts Explained Simply

Kubernetes can feel overwhelming with its jargon: pods, services, deployments, ingress. But at its core, it solves a simple problem: how to run and manage containers across many machines. Once you map the concepts to everyday analogies, it clicks.

The Cluster: A Team of Computers

A Kubernetes cluster is a group of machines (physical or virtual) that work together. You have one or more control plane nodes that manage the cluster, and several worker nodes that run your applications. Think of the control plane as the manager, and workers as the employees doing the actual work.

The control plane decides where to place workloads, monitors health, and responds to changes. Workers just run containers and report back.

Pods: The Smallest Unit

You don't deploy containers directly in Kubernetes. You deploy pods. A pod is a wrapper around one or more containers that share the same network and storage. In most cases, a pod runs a single container, but sometimes you need a helper container (like a log shipper) alongside your main app.

Think of a pod as a house with one or more roommates. They share the same IP address and can communicate via localhost. The house is the smallest unit you can schedule.

Here's a minimal pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: nginx:latest

You rarely create pods directly. Instead, you use controllers that manage them for you.

Deployments: Desired State

A deployment is a controller that ensures a certain number of pod replicas are running. You declare the desired state (e.g., "run 3 replicas of my app"), and Kubernetes works to match that state. If a pod dies, the deployment replaces it. If you update the image, it rolls out new pods gradually.

This is like having a thermostat: you set the temperature, and the system keeps adjusting to hit that target.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: nginx:latest

Services: Stable Entry Points

Pods are ephemeral; they get created and destroyed, and their IPs change. You don't want clients to track individual pod IPs. A service provides a stable virtual IP and DNS name that routes traffic to a set of pods (selected by labels).

Think of it as a receptionist. You call the receptionist, and they forward you to the right person (pod) currently available.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 80

Services come in types: ClusterIP (internal only), NodePort (exposes on each node's IP), and LoadBalancer (integrates with cloud load balancers).

Ingress: The Front Door

If services are internal routing, ingress is the external entry point. It manages HTTP and HTTPS traffic from outside the cluster to services. You define rules based on hostnames or paths.

For example, api.example.com routes to one service, while example.com routes to another. Ingress often requires an ingress controller (like NGINX) that implements those rules.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

ConfigMaps and Secrets: Settings and Credentials

Applications need configuration. ConfigMaps store non-sensitive settings like environment variables or config files. Secrets store sensitive data like passwords and API keys, encoded in base64 (but still not secure by default; use encryption in production).

Instead of baking config into your image, you inject it at runtime. This keeps your containers portable.

Namespaces: Separate Areas

A cluster can host multiple teams or projects. Namespaces provide logical separation. You can have dev, prod, or team-a namespaces. Resources inside a namespace are isolated, and you can apply quotas and policies per namespace.

Putting It All Together

A typical workflow looks like this:

1. Write a Dockerfile for your app.
2. Push the image to a registry.
3. Create a Deployment that references the image.
4. Create a Service to expose it internally.
5. Create an Ingress to route external traffic.

Kubernetes handles scaling, self-healing, and rolling updates. You just describe what you want, and it makes it happen.

Wrapping Up

Start with these core objects and build up. Don't try to learn every resource at once. Run a local cluster with Kind or Minikube, deploy a simple app, and experiment. Once you understand pods, deployments, and services, you've covered 80% of daily Kubernetes work.

The rest is just variations on these themes.