Kubernetes Fundamentals

The Kubernetes control plane manages the cluster's global state and makes decisions about scheduling, scaling, and healing. It consists of four core components.

The API Server is the front door to the cluster. All communication—kubectl, dashboard, controller managers, and kubelets—goes through the API server. It validates and processes REST requests, persists state to etcd, and broadcasts events.

etcd is a distributed key-value store that holds the entire cluster state: node registrations, pod definitions, service endpoints, secrets, and configuration. It's the single source of truth. Losing etcd means losing the cluster's state, so production clusters run etcd on dedicated nodes with regular backups.

The Scheduler watches for unscheduled pods and assigns them to nodes based on resource availability, affinity rules, taints/tolerations, and topology constraints. It doesn't run the pod—that's the kubelet's job.

The Controller Manager runs reconciliation loops. The Deployment controller ensures the desired number of pod replicas exist. The Node controller monitors node health. The Service controller provisions load balancers. Each controller compares the desired state (what you declared) with the actual state (what's running) and takes action to converge them.

On each worker node, the kubelet is the agent that communicates with the API server, manages pod lifecycle, runs health checks, and reports node status. The container runtime (containerd or CRI-O) actually runs the containers.

A Pod is the smallest deployable unit in Kubernetes—a group of one or more containers sharing network namespace, storage volumes, and a lifecycle. Pods are ephemeral: when a pod dies, it's gone. Never run production workloads as standalone pods.

A ReplicaSet ensures a specified number of pod replicas run at any time. If a pod crashes, the ReplicaSet creates a replacement. You rarely create ReplicaSets directly—Deployments manage them.

A Deployment declaratively manages ReplicaSets and provides rolling updates, rollbacks, and pause/resume:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: myapp:v2.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Resource requests tell the scheduler how much CPU/memory the pod needs. Limits cap the maximum—the pod is throttled (CPU) or killed (memory) if exceeded. Readiness probes determine if a pod can accept traffic. Liveness probes determine if a pod needs to be restarted.

kubectl is the command-line tool for interacting with the Kubernetes API server. Master these core operations:

# Cluster information
kubectl cluster-info
kubectl get nodes -o wide

# Pod management
kubectl get pods -A                    # All namespaces
kubectl get pods -l app=api-server     # By label
kubectl describe pod <pod-name>        # Detailed info
kubectl logs <pod-name> -c <container> # Container logs
kubectl exec -it <pod-name> -- /bin/sh # Shell into pod

# Deployments
kubectl apply -f deployment.yaml       # Create/update
kubectl rollout status deployment/api  # Watch rollout
kubectl rollout history deployment/api # Version history
kubectl rollout undo deployment/api    # Rollback
kubectl scale deployment/api --replicas=5

# Debugging
kubectl get events --sort-by=.metadata.creationTimestamp
kubectl top pods                      # Resource usage
kubectl port-forward svc/api 8080:8080 # Port forward

The apply command is idempotent—it creates the resource if it doesn't exist, or updates it if the desired state differs from the actual state. This is fundamental to GitOps workflows where declarative YAML is the source of truth.

Use kubectl debug to create ephemeral debug containers attached to running pods without modifying the original container image. This is invaluable for troubleshooting production issues.

Namespaces partition a Kubernetes cluster into virtual sub-clusters. They provide scope for names (two resources can have the same name if in different namespaces), resource quotas, and access controls.

kubectl create namespace production
kubectl create namespace staging
kubectl config set-context --current --namespace=production

Common namespace strategies include separating by environment (dev, staging, prod), by team (platform, data, frontend), or by application tier (web, api, database). Resource quotas prevent one namespace from consuming all cluster resources:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: engineering
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"

NetworkPolicies can restrict traffic between namespaces, enabling zero-trust networking within the cluster. Service accounts in each namespace provide identity for pods to authenticate with the API server and cloud services.

Default namespaces like kube-system (cluster components), kube-public (public cluster info), and default (undeclared resources) should not be used for application workloads. Create dedicated namespaces for better organization and access control.