Stackbook Logo
← Back to Tools

Kubernetes Basics

A practical introduction to Kubernetes: pods, deployments, services, config, probes, kubectl commands, and how it fits into a container-based architecture.

4 min read

Kubernetes is an open-source container orchestrator. You describe the desired state of your application, for example "run three copies of this image and expose them on port 80", and Kubernetes continuously works to make reality match. It schedules containers onto nodes, restarts failed ones, rolls out updates, and scales replicas. Use it when you run many containers across multiple machines and need self-healing and automated deployment. For a single small service, plain Docker or a managed platform is often simpler.

Quick start

For local experiments, use minikube or kind, plus kubectl.

kind create cluster --name dev
kubectl cluster-info
kubectl get nodes

Core concepts

  • Pod: the smallest deployable unit, one or more containers sharing network and storage. Pods are ephemeral.
  • Deployment: manages a set of identical pods through a ReplicaSet and handles rolling updates and rollbacks.
  • Service: a stable virtual IP and DNS name that load-balances across matching pods.
  • ConfigMap and Secret: inject configuration and sensitive values into pods.
  • Namespace: a logical partition for isolating teams or environments.
  • Ingress: HTTP routing from outside the cluster to services.
  • Node and control plane: nodes run workloads, while the control plane (API server, scheduler, controllers, etcd) manages the cluster.

Everything is declarative. You write YAML, apply it, and controllers reconcile.

Deploying an application

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-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Apply and inspect it:

kubectl apply -f web.yaml
kubectl get deploy,pods,svc
kubectl describe pod web-xxxxx
kubectl logs deploy/web
kubectl port-forward svc/web 8080:80

Operating it

kubectl scale deploy/web --replicas=5
kubectl set image deploy/web web=nginx:1.27.1-alpine
kubectl rollout status deploy/web
kubectl rollout undo deploy/web
kubectl exec -it deploy/web -- sh
kubectl get events --sort-by=.lastTimestamp
kubectl delete -f web.yaml

Rolling updates replace pods gradually. The readiness probe prevents traffic from reaching a pod that is not ready, which makes updates zero-downtime when configured correctly.

Common pitfalls

  • No resource requests or limits. The scheduler cannot place pods sensibly, and one noisy pod can starve others.
  • Missing or wrong probes. A liveness probe that is too aggressive causes restart loops, and no readiness probe sends traffic to cold pods.
  • Using the latest tag, which breaks reproducibility and rollbacks.
  • Treating pods as durable. Data written to a pod filesystem is lost. Use PersistentVolumes or an external database.
  • Secrets in Git. Kubernetes Secrets are only base64 encoded by default. Use sealed secrets, an external secrets operator, or a cloud secret manager.
  • CrashLoopBackOff and ImagePullBackOff. Start with kubectl describe pod and kubectl logs --previous.
  • Over-adopting. Kubernetes carries real operational cost, so consider managed offerings like EKS, GKE, or AKS.

Where Kubernetes fits in an architecture

Kubernetes is the runtime layer between your container images and the infrastructure. CI builds and pushes images, a GitOps tool or pipeline applies manifests, and the cluster runs services behind an ingress controller. Around it sit supporting pieces: Prometheus and Grafana for observability, Jaeger or Tempo for tracing, a service mesh for mTLS and traffic control, and Horizontal Pod Autoscaler for scaling on CPU or custom metrics. Helm or Kustomize manage manifest variants across environments.

Key takeaways

  • Declare desired state in YAML and let controllers reconcile.
  • Use Deployments for stateless workloads, Services for stable access, and probes for safe rollouts.
  • Always set resource requests and limits and pin image versions.
  • Keep state outside pods and secrets outside Git.
  • Debug with describe, logs, and events before guessing.