Master Kubernetes: Core Concepts, Architecture, Probes, and Deployment Strategies

What is Kubernetes?

Kubernetes is an open‑source system for automating deployment, scaling, and management of containerized applications, providing production‑grade container orchestration.

Container vs. Host Deployment

Containers start in seconds, enable "build once, run anywhere", and isolate services, but require careful handling of persistent data.

Kubernetes Architecture

The control plane (master) exposes the API, schedules pods, and manages the cluster, while worker nodes run the container runtime and kubelet.

Master components :

kubectl – client CLI

API Server – central entry point with authentication, authorization, and discovery

Controller‑manager – maintains cluster state (fault detection, autoscaling, rolling updates)

Scheduler – assigns pods to nodes based on policies

etcd – distributed key‑value store for cluster state

Node components :

Kubelet – manages pod lifecycle, volumes, and networking

Kube‑proxy – implements Service load‑balancing and cluster‑internal service discovery

container‑runtime – e.g., Docker, runs containers

Pod – smallest deployable unit; containers in a pod share network and IPC namespaces but have isolated UTS, PID, and mount namespaces

Pod Health‑Checking Probes

Kubernetes provides three probe types to monitor pod health:

livenessProbe – restarts a container when it becomes unhealthy.

readinessProbe – removes a pod from a Service endpoint list until it becomes ready.

startupProbe – gives slow‑starting containers extra time before other probes act.

Common probe parameters:

initialDelaySeconds – delay before first check

periodSeconds – interval between checks (default 10 s)

timeoutSeconds – timeout for a single check

successThreshold – number of consecutive successes required

Probe implementations:

Exec Probe Example

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

HTTP GET Probe Example

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 3
      periodSeconds: 3

TCP Socket Probe Example

spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Probe results can be Success , Failure , or Unknown .

Rolling Update Controls

Use kubectl explain deploy.spec.strategy.rollingUpdate to view parameters:

maxSurge – maximum number of pods above the desired count (percentage or absolute, default 1)

maxUnavailable – maximum number of pods that may be unavailable during the update

Image Pull Policies

Three policies control when images are pulled:

Always – pull every time (default for :latest tags)

IfNotPresent – pull only if the image is not present locally (default for non‑latest tags)

Never – never pull; use only local images

Pod Restart Policies

Always – default; restart whenever the pod terminates

OnFailure – restart only on container failure

Version Rollback Commands

kubectl apply -f httpd2-deploy1.yaml --record   # apply and record version
kubectl rollout history deployment httpd-deploy1   # view history
kubectl rollout undo deployment httpd-deploy1 --to-revision=1   # rollback to revision 1

Labels and Selectors

Labels group similar resources; selectors filter them. Equality‑based selectors use =, ==, !=. Set‑based selectors use in, notin, exists.

Common label categories:

Release: stable, canary, beta Environment: dev, qa, production, op App: ui, as, pc, sc Tier: frontend, backend, cache Partition: customerA, customerB Track: daily, weekly Viewing labels:

kubectl get pod --show-labels
kubectl get pod -L env,tier
kubectl get pod -l env,tier

DaemonSet Characteristics

A DaemonSet ensures exactly one pod runs on each node, unlike Deployments which may run multiple replicas.

Pod Lifecycle States

Pending – created but not yet scheduled or pulling images

Running – containers created and at least one is running

Succeeded – all containers terminated successfully

Failed – all containers terminated with non‑zero exit codes

Unknown – status cannot be obtained

Pod Creation Process

Client submits pod spec (YAML) to kube-apiserver.

API server notifies controller‑manager to create the object.

Controller stores the pod spec in etcd.

Scheduler selects a suitable node and sends the pod spec to the node’s kubelet.

Kubelet creates the pod; status is reported back and stored in etcd.

Pod Deletion Process

API server receives delete request (default 30 s graceful period).

Pod is removed from Service endpoints.

If a pre‑stop hook is defined, it runs inside the pod.

Kubelet sends SIGTERM to containers.

After the grace period, SIGKILL is sent to force termination.

Service Overview

Services provide a stable network endpoint for pods whose IPs may change, load‑balancing traffic across a set of pod endpoints.

Service Registration

When a pod starts, it loads all Service definitions in the cluster, enabling inter‑pod communication via Service names.

Data Persistence Options

Common volume types:

emptyDir – temporary storage that lives as long as the pod runs on a node.

hostPath – mounts a directory from the host node (tight coupling).

PersistentVolume (PV) / PersistentVolumeClaim (PVC) – abstract storage resources managed by the cluster administrator, decoupling pod specs from underlying storage implementations.