Kubernetes Basics for Developers: Pods, Deployments, Services and More

Kubernetes (K8s) has become the standard platform for running containerized applications at scale. If you are already comfortable with Docker, Kubernetes is the natural next step — it orchestrates your containers across a cluster of machines, handling scaling, self-healing, and rolling deployments automatically.

This guide focuses on what developers need to know day-to-day.

Why Kubernetes?

Docker solves the "runs on my machine" problem. But in production you need more:

• Scaling — running 20 copies of your service during peak traffic, 2 during quiet hours
• Self-healing — automatically restarting crashed containers
• Rolling deployments — updating your app with zero downtime
• Service discovery — containers finding each other without hardcoded IPs
• Configuration management — separating secrets and config from your image

Kubernetes provides all of this through a declarative API — you describe the desired state, and Kubernetes continuously works to make reality match it.

Core Concepts

Cluster

A Kubernetes cluster consists of:

• Control Plane — the brain: API server, scheduler, etcd (state store), controller manager
• Nodes (Worker Nodes) — the machines that actually run your containers

You interact with the cluster through kubectl, the command-line client.

Pod

A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share the same network namespace and storage.

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  containers:
    - name: app
      image: my-app:1.0
      ports:
        - containerPort: 3000
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

In practice, you rarely create Pods directly. You create Deployments, which manage Pods for you. A Pod created alone is not rescheduled if its node dies.

Deployment

A Deployment manages a set of identical Pods (a ReplicaSet). It handles rolling updates, rollbacks, and ensures the desired number of replicas is always running.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: my-app:1.0
          ports:
            - containerPort: 3000
          env:
            - name: NODE_ENV
              value: production
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

readinessProbe tells Kubernetes when the container is ready to receive traffic. Kubernetes will not send requests to a Pod until it passes the probe.

Service

Pods have ephemeral IPs that change when they restart. A Service gives your Pods a stable network identity and load balances traffic across them.

yaml
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app        # matches Pods with this label
  ports:
    - port: 80         # Service port
      targetPort: 3000 # Pod port
  type: ClusterIP      # Internal only (default)

Service types:

Type	Description
ClusterIP	Internal cluster IP only — default
NodePort	Exposes on each node's IP at a static port
LoadBalancer	Provisions a cloud load balancer (AWS ELB, GCP LB)
ExternalName	Maps to an external DNS name

Ingress

An Ingress exposes HTTP/HTTPS routes from outside the cluster to Services inside. It handles path-based and host-based routing.

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

Configuration

ConfigMap

Store non-sensitive configuration as key-value pairs:

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  MAX_CONNECTIONS: "100"
  LOG_LEVEL: info

Use in a Deployment:

yaml
envFrom:
  - configMapRef:
      name: app-config

Secret

Store sensitive data (passwords, API keys, TLS certs). Values are base64-encoded (not encrypted by default — use encryption at rest in production):

yaml
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=   # base64 of "password123"
  API_KEY: c2VjcmV0a2V5          # base64 of "secretkey"

Reference in a Deployment:

yaml
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: DB_PASSWORD

Essential kubectl Commands

bash
# Get resources
kubectl get pods
kubectl get deployments
kubectl get services
kubectl get all

# Describe (detailed info + events)
kubectl describe pod my-app-abc123
kubectl describe deployment my-app

# Logs
kubectl logs my-app-abc123
kubectl logs -f my-app-abc123          # follow
kubectl logs my-app-abc123 --previous  # crashed container logs

# Execute a command inside a pod
kubectl exec -it my-app-abc123 -- bash

# Apply a manifest file
kubectl apply -f deployment.yaml

# Delete resources
kubectl delete pod my-app-abc123
kubectl delete -f deployment.yaml

# Scale a deployment
kubectl scale deployment my-app --replicas=5

# Rolling update (change image)
kubectl set image deployment/my-app app=my-app:2.0

# Rollback
kubectl rollout undo deployment/my-app

# Check rollout status
kubectl rollout status deployment/my-app

# Port forward to a pod (local debugging)
kubectl port-forward pod/my-app-abc123 3000:3000
kubectl port-forward service/my-app-service 8080:80

Namespaces

Namespaces partition cluster resources between teams or environments:

bash
# List namespaces
kubectl get namespaces

# Create a namespace
kubectl create namespace staging

# Work in a specific namespace
kubectl get pods -n staging
kubectl apply -f deployment.yaml -n staging

# Set default namespace for your session
kubectl config set-context --current --namespace=staging

Common convention: default, staging, production, monitoring as separate namespaces in one cluster.

Resource Requests and Limits

Always set resource requests and limits. Without them, a misbehaving pod can starve other workloads on the node.

yaml
resources:
  requests:
    memory: "128Mi"   # guaranteed allocation
    cpu: "250m"       # 0.25 CPU cores
  limits:
    memory: "256Mi"   # hard cap — pod killed if exceeded
    cpu: "500m"       # throttled if exceeded

250m means 250 millicores = 0.25 of one CPU core.

Probes: Health Checks

yaml
livenessProbe:    # restart container if this fails
  httpGet:
    path: /healthz
    port: 3000
  initialDelaySeconds: 15
  periodSeconds: 20

readinessProbe:   # stop sending traffic if this fails
  httpGet:
    path: /ready
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10

• livenessProbe — is the container alive? Failure = restart
• readinessProbe — is it ready for traffic? Failure = removed from Service endpoints
• startupProbe — for slow-starting containers, disables liveness until app is up

Practice Kubernetes on Froquiz

Kubernetes knowledge is increasingly expected for backend and DevOps roles. Test your Docker and infrastructure knowledge on Froquiz — and explore all our DevOps topics.

Summary

• Pod — smallest unit, wraps containers; use Deployments not bare Pods
• Deployment — manages replicas, rolling updates, and rollbacks
• Service — stable network endpoint, load balances across Pods
• Ingress — HTTP routing from outside the cluster to internal Services
• ConfigMap — non-sensitive config; Secret — sensitive data
• Always set resource requests and limits
• Liveness probes restart unhealthy containers; readiness probes remove them from traffic
• kubectl apply, kubectl logs, kubectl exec, kubectl port-forward are your daily tools