iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up
« Previous

Kubernetes HOME

By · Reviewed & last updated · Part of Kubernetes Tutorial

Kubernetes is the orchestration platform for containerised apps: declarative desired state, automatic scheduling, self-healing, and rolling updates.

Kubernetes — homepage

EXAMPLE
# ===== The model =====
# You describe DESIRED state in YAML (Deployment, Service, etc).
# The control plane reconciles ACTUAL state to match.
# If a pod dies, the controller spins up a replacement. If a node dies, pods reschedule.

# ===== Core objects =====
# Pod            smallest deployable unit (usually one container)
# Deployment     manages a set of identical Pods (replicas, rolling updates)
# Service        stable network endpoint in front of pods
# Ingress        HTTP/HTTPS routing into the cluster
# ConfigMap      non-secret config
# Secret         sensitive config (base64 encoded; not encrypted by default)
# Namespace      logical grouping
# Job / CronJob  one-shot / scheduled tasks
# StatefulSet    pods with stable identity + persistent volumes
# DaemonSet      one pod per node (log shippers, agents)

# ===== Tiny example =====
apiVersion: apps/v1
kind: Deployment
metadata: { name: shop }
spec:
  replicas: 3
  selector: { matchLabels: { app: shop } }
  template:
    metadata: { labels: { app: shop } }
    spec:
      containers:
        - name: shop
          image: ghcr.io/me/shop:v1
          ports: [{ containerPort: 3000 }]
          readinessProbe: { httpGet: { path: /healthz, port: 3000 } }
---
apiVersion: v1
kind: Service
metadata: { name: shop }
spec:
  selector: { app: shop }
  ports: [{ port: 80, targetPort: 3000 }]
  type: ClusterIP

# Apply:
#   kubectl apply -f shop.yaml
#   kubectl get pods,svc -l app=shop

# ===== Daily commands =====
# kubectl get pods -A
# kubectl describe pod <name>
# kubectl logs -f <pod>
# kubectl exec -it <pod> -- sh
# kubectl rollout status deploy/shop
# kubectl scale deploy/shop --replicas=5
# kubectl port-forward svc/shop 8080:80

# ===== Where K8s lives =====
# Managed: EKS (AWS), GKE (Google), AKS (Azure), DOKS, Linode LKE
# Self-host: kubeadm, kops, k3s, rke2
# Local dev: kind, k3d, minikube, Docker Desktop

# ===== When K8s wins =====
# - 5+ services that need to talk
# - Multi-tenant or multi-team platforms
# - Need rolling deploys, autoscaling, self-healing
# - Hybrid / multi-cloud portability

# ===== When K8s hurts =====
# - One container, one box, one user (use a PaaS)
# - Tiny team without ops capacity (managed K8s reduces but does not remove this)
# - Apps that need GPU / specialised hardware (manageable but adds complexity)

# ===== Patterns to internalise =====
# - Declarative everything; YAML in git; apply via CI
# - Probes (liveness, readiness, startup) on every container
# - Requests and limits on every container
# - Namespaces per environment; RBAC by namespace

# ===== Pitfalls =====
# - latest image tags -> non-deterministic deploys
# - No resource limits -> noisy neighbour crashes others
# - Secrets in plain ConfigMaps -> rotate immediately
# - kubectl-apply by hand on prod -> drift from git source of truth

Why it matters

Kubernetes is a control plane: you write YAML for the state you want, the controllers do the work. The mental model is "describe, do not script". Reach for it when many services need to be deployed, scaled, and healed without manual touch — and let a managed offering carry the control-plane operations.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
kubectl version --short
kubectl get nodes
Try it Yourself »

Discussion

Loading…

« Previous