Mastering Kubernetes: Core Architecture, Probes, and Deployment Strategies

1. What is Kubernetes?

Kubernetes is an open‑source system for automating deployment, scaling, and management of containerized applications, primarily used for container orchestration in production environments. It originated from Google’s Borg system, which was used internally for 15 years.

2. Components of the K8s Architecture

A typical cluster consists of at least one master node and multiple worker nodes.

Master node: exposes the API, schedules deployments, and manages nodes.

Worker node: runs a container runtime (e.g., Docker) and the kubelet agent to communicate with the master.

K8s Architecture Details

Master components (do not run workloads):

Kubectl – command‑line client.

API Server – the sole entry point for resource operations, handling authentication, authorization, and discovery.

Controller‑manager – maintains cluster state (fault detection, auto‑scaling, rolling updates).

Scheduler – assigns pods to nodes based on scheduling policies.

etcd – stores the entire cluster state.

Worker node components:

Kubelet – manages container lifecycle, volumes, and networking; restarts failed containers.

Kube‑proxy – provides service discovery and load balancing within the cluster.

Container runtime – e.g., Docker.

Pod – the smallest unit, containing one or more containers that share certain namespaces.

3. Difference Between Container and Host Deployment

Containers start in seconds, are portable, and isolate services, but require careful handling of data persistence.

4. Pod Health‑Check Mechanisms

Kubernetes provides three probe types for pod health monitoring:

livenessProbe – restarts the container if it becomes unhealthy.

readinessProbe – removes the pod from service endpoints when it fails.

startupProbe – allows slow‑starting applications to avoid premature restarts.

All probes share common parameters:

initialDelaySeconds – delay before the first check.

periodSeconds – interval between checks.

timeoutSeconds – timeout for a check.

successThreshold – number of successful checks required.

Probe execution methods:

Exec – runs a command inside the container.

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

HttpGet – sends an HTTP request; 200‑399 indicates success.

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

TCPSocket – attempts a TCP connection to the container’s port.

Probe results can be Success, Failure, or Unknown.

5. Controlling Rolling Updates

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

maxSurge – number or percentage of extra pods created during update (default 1).

maxUnavailable – number of pods that may be unavailable during update.

6. Image Pull Policies

Kubernetes supports three policies:

Always – always pull the image when the tag is latest.

Never – use only a local image.

IfNotPresent – pull only if the image is not already present locally.

Default: Always for latest tags, otherwise IfNotPresent.

7. Image States

Running – containers are scheduled and running.

Pending – created but not yet scheduled or pulling images.

Unknown – API server cannot determine the pod’s status.

8. Pod Restart Policies

Always – restart on any termination (default).

OnFailure – restart only on non‑zero exit codes.

9. Service Purpose

Provides a stable endpoint for a set of pods, enabling service discovery and load balancing.

10. Version Rollback Commands

# kubectl apply -f httpd2-deploy1.yaml --record
# kubectl rollout history deployment httpd-deploy1
# kubectl rollout undo deployment httpd-deploy1 --to-revision=1
# spec:
#   revisionHistoryLimit: 5

11. Labels and Selectors

Labels group resources; selectors filter resources based on equality or set‑based expressions.

Equality: =, ==, !=

Set‑based: in, notin, exists

12. 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

13. Viewing Labels

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

14. Adding, Modifying, Deleting Labels

# Add label
kubectl label pod label-pod abc=123
# Modify label
kubectl label pod label-pod abc=456 --overwrite
# Delete label
kubectl label pod label-pod abc-
# Node label operations similar

15. DaemonSet Characteristics

Runs exactly one pod on each node; cannot specify replicas. Used for log collection and node monitoring.

16. Job Resource Overview

Jobs run one‑off tasks. Parallelism and completions can be configured to improve throughput.

spec:
  parallelism: 2
  completions: 8
  template:
    metadata:

17. Pod Lifecycle States

Pending – awaiting scheduling.

Running – containers are active.

Succeeded – all containers terminated successfully.

Failed – containers terminated with errors.

Unknown – status cannot be obtained.

18. Pod Creation Process

Client submits pod spec to kube‑apiserver.

Controller‑manager creates the resource object.

Object is stored in etcd.

Kube‑scheduler selects a suitable node.

Kubelet on the node runs the pod and reports status.

19. Pod Deletion Workflow

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

Pod is removed from service endpoints.

Pre‑stop hooks are executed if defined.

TERM signal is sent; after timeout, SIGKILL is sent.

20. Service Functionality

Provides a fixed entry point for pods whose IPs may change, enabling stable communication and load balancing.

21. Service Registration in K8s

Pods load service information at startup to resolve service names.

22. External Access to Pods

Use a Service of type NodePort, which opens the same port on all nodes (e.g., 30000) and forwards traffic to the corresponding pods.

23. Data Persistence Methods

EmptyDir – temporary storage shared among containers in a pod; deleted with the pod.

HostPath – mounts a host directory into the container; tightly couples pod to node.

PersistentVolume (PV) – provisioned storage with access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) and reclaim policies (Recycle, Retain, Delete). PersistentVolumeClaim (PVC) requests storage matching a PV’s specifications.