Mastering Kubernetes: Core Concepts, Architecture, Probes, and Best Practices

1. What is Kubernetes?

Kubernetes is an open‑source system for automating deployment, scaling, and management of containerized applications, originating from Google’s internal Borg system.

2. What are the components of the Kubernetes architecture?

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

The master node exposes the API, schedules deployments, and manages nodes.

Worker nodes run a container runtime (e.g., Docker) and the kubelet agent to communicate with the master.

Kubernetes master components

kubectl : command‑line client.

API Server : central entry point for all API requests.

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

Scheduler : assigns pods to suitable nodes based on policies.

etcd : distributed key‑value store holding the cluster state.

Worker node components

kubelet : manages container lifecycle, volumes, and networking on the node.

kube‑proxy : provides service discovery and load‑balancing within the cluster.

container‑runtime : software that runs containers (e.g., Docker).

Pod : the smallest deployable unit; may contain one or more containers sharing certain namespaces.

3. Difference between container‑based and host‑based deployments

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

4. Pod health‑checking mechanisms

Kubernetes provides three probe types for pod health monitoring:

livenessProbe : restarts containers that are unhealthy.

readinessProbe : removes pods from service endpoints when they are not ready.

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

Common probe parameters include initialDelaySeconds, periodSeconds, timeoutSeconds, and successThreshold.

Probes can be implemented using three methods:

1) Exec

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

2) HttpGet

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

3) TcpSocket

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 .

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

5. Controlling a rolling update

Key parameters can be inspected with:

# kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge : allows the number of pods to exceed the desired count during an update (percentage or absolute number).

maxUnavailable : limits how many pods may be unavailable during the update.

6. Image pull policies

Kubernetes supports three image pull policies, viewable via kubectl explain pod.spec.containers:

Always : pull the image on every pod start (default for the latest tag).

Never : use only a locally‑available image.

IfNotPresent : pull only when the image is not present locally (default for non‑ latest tags).

7. Image states

Running : the container is scheduled and running.

Pending : the pod is created but not yet scheduled or pulling an image.

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

8. Pod restart policies

Always (default): restart the pod whenever it terminates.

OnFailure : restart only if the pod exits with a non‑zero status.

9. Purpose of a Service

A Service provides a stable network 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-devploy1
# kubectl rollout undo deployment httpd-devploy1 --to-revision=1
spec:
  revisionHistoryLimit: 5

11. Labels and label selectors

Labels group resources; selectors filter resources based on label criteria. Two selector types exist:

Equality‑based (e.g., =, ==, !=).

Set‑based (e.g., in, notin, exists).

12. Common label categories

Release: stable, canary, beta Environment: dev, qa, production, op Application: 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

# Pod label operations
kubectl label pod label-pod abc=123          # add
kubectl label pod label-pod abc=456 --overwrite  # modify
kubectl label pod label-pod abc-               # delete
# Node label operations
kubectl label nodes node01 disk=ssd
kubectl label nodes node01 disk=sss --overwrite
kubectl label nodes node01 disk-

15. DaemonSet characteristics

A DaemonSet runs exactly one pod on each node, useful for log collection and node monitoring.

16. Job resource

A Job runs one‑off tasks; parallelism and completions can be tuned.

# Example to increase Job efficiency
spec:
  parallelism: 2
  completions: 8
  template:
    metadata:

17. Pod lifecycle phases

Pending : awaiting scheduling or image pull.

Running : containers are created and at least one is active.

Succeeded : all containers terminated successfully.

Failed : containers terminated with non‑zero exit codes.

Unknown : status cannot be obtained.

18. Pod creation workflow

Client submits pod spec to the API server.

API server stores the object in etcd via the controller‑manager.

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

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

19. Pod deletion process

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

Pod is removed from service endpoints.

If a pre‑stop hook exists, it is executed.

Containers receive a TERM signal; after the grace period, a KILL signal.

20. What is a Service?

A Service gives a stable IP/port for a set of pods, handling load balancing and external access.

21. Service registration in Kubernetes

Pods load Service information at startup, allowing them to communicate via Service names.

22. Accessing pods from outside the cluster

Use a Service of type NodePort, which opens the same port on every node (e.g., 30000) and forwards traffic to the Service.

23. Persistent storage options

1) EmptyDir

Temporary directory shared among containers in a pod; deleted when the pod is removed.

2) HostPath

Mounts an existing host directory or file into the container; creates tight coupling between pod and node.

3) PersistentVolume (PV)

Cluster‑wide storage backed by NFS, GFS, etc., with access modes:

ReadWriteOnce

ReadOnlyMany

ReadWriteMany

Reclaim policies include Recycle, Retain, and Delete. A PersistentVolumeClaim (PVC) requests storage that matches a PV’s size, access mode, and storage class.

PS: Reclaim policy determines whether the underlying data is deleted when the PV is removed.