Master Kubernetes Basics: Architecture, Probes, and Common Commands

What is Kubernetes?

Kubernetes is an open‑source system that automates deployment, scaling, and management of containerized applications. It originated from Google’s Borg project and is the de‑facto container orchestration platform for production workloads.

Kubernetes Architecture

A cluster consists of at least one control‑plane (master) node and multiple worker nodes.

Control‑plane components kubectl – command‑line client used to interact with the cluster.

API Server – the sole entry point for all resource operations; handles authentication, authorization, admission control and discovery.

Controller‑manager – runs controllers that maintain the desired state (e.g., node controller, replication controller, deployment controller).

Scheduler – assigns Pods to nodes based on resource requirements and policies.

etcd – distributed key‑value store that persists the entire cluster state.

Worker‑node components

Kubelet – agent that ensures containers described in a PodSpec are running and reports node status to the API server.

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

Container runtime – software that runs containers (Docker, containerd, etc.).

Pod – the smallest deployable unit; one or more containers share a network namespace and IPC, but have separate UIDs, mount points and PIDs.

Containers vs. Host‑based Deployments

Containers start in seconds, are packaged once and run anywhere, and provide fine‑grained isolation. They require explicit handling of persistent data because the container filesystem is ephemeral.

Pod Health Monitoring

Kubernetes supports three probe types that run periodically to assess Pod health:

livenessProbe – if it fails, the kubelet restarts the container according to the Pod’s restartPolicy.

readinessProbe – if it fails, the Pod is removed from Service endpoints and stops receiving traffic.

startupProbe – gives slow‑starting containers extra time before liveness/readiness checks begin.

All probes share the same configurable fields: initialDelaySeconds – delay before the first check. periodSeconds – interval between checks (default 10 s). timeoutSeconds – timeout for each check. successThreshold – number of consecutive successes required.

Probes can be implemented via three methods:

exec – runs a command inside the container.

httpGet – sends an HTTP/HTTPS request and expects a 2xx‑3xx status code.

tcpSocket – attempts to open a TCP connection to the specified port.

Example exec liveness probe:

apiVersion: v1
kind: Pod
metadata:
  name: exec‑probe
spec:
  containers:
  - name: app
    image: k8s.gcr.io/busybox
    command: ["/bin/sh", "-c", "while true; do echo ok; sleep 10; done"]
    livenessProbe:
      exec:
        command: ["cat", "/tmp/healthy"]
      initialDelaySeconds: 5
      periodSeconds: 5

Example httpGet liveness probe:

apiVersion: v1
kind: Pod
metadata:
  name: http‑probe
spec:
  containers:
  - name: app
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 3
      periodSeconds: 3

Example tcpSocket readiness and liveness probes:

apiVersion: v1
kind: Pod
metadata:
  name: tcp‑probe
spec:
  containers:
  - name: app
    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

Rolling Update Control

Use the following command to view the rolling‑update fields of a Deployment:

kubectl explain deployment.spec.strategy.rollingUpdate

maxSurge – maximum number of Pods that can be created above the desired replica count during an update (percentage or absolute number, default 1).

maxUnavailable – maximum number of Pods that may be unavailable during the update (percentage or absolute number).

Image Pull Policies

Always – always pull the image; used automatically when the tag is latest.

IfNotPresent – pull only if the image is not already present on the node (default for non‑latest tags).

Never – never pull; the image must exist locally.

Pod Phases and Restart Policies

Pending – accepted by the API server but waiting for scheduling or image download.

Running – all containers started and at least one is running.

Succeeded – all containers terminated successfully.

Failed – one or more containers terminated with a non‑zero exit code.

Unknown – the control plane cannot obtain the Pod’s status.

Restart policies (field restartPolicy):

Always – default; the Pod is restarted whenever a container terminates.

OnFailure – restart only if the container exits with a non‑zero status.

Service Purpose and External Access

A Service provides a stable network endpoint for a set of Pods, enabling service discovery and load‑balancing. To expose Pods outside the cluster, a NodePort Service listens on a static port (e.g., 30000) on every node and forwards traffic to the selected Pods.

Rollback a Deployment

# Apply a new version and record the change
kubectl apply -f httpd2-deploy1.yaml --record

# View rollout history
kubectl rollout history deployment/httpd-deploy1

# Roll back to a specific revision
kubectl rollout undo deployment/httpd-deploy1 --to-revision=1

To limit the number of stored revisions, add revisionHistoryLimit: 5 to the Deployment spec.

Labels and Selectors

Labels are key‑value pairs attached to resources for grouping and management. Selectors filter resources based on label criteria.

Equality‑based selectors : =, ==, !=.

Set‑based selectors : in, notin, exists.

Multiple selectors are AND‑ed together.

Example selector syntax:

selector:
  matchLabels:
    app: nginx          # equality‑based
  matchExpressions:
  - key: tier
    operator: In
    values: [frontend, backend]
  - key: environment
    operator: Exists

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

Managing Labels

View labels:

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

Add, modify, or delete a label on a Pod:

# Add
kubectl label pod my-pod version=1
# Modify (overwrite)
kubectl label pod my-pod version=2 --overwrite
# Delete
kubectl label pod my-pod version-

Node label operations are analogous, using kubectl label nodes ….

DaemonSet

A DaemonSet ensures that exactly one Pod runs on each node in the cluster. The replicas field is not supported.

Job

A Job runs a finite task to completion. Parallelism and completions can be tuned:

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  parallelism: 2   # run two Pods simultaneously
  completions: 8   # total successful completions required
  template:
    spec:
      containers:
      - name: worker
        image: busybox
        command: ["/bin/sh", "-c", "echo done"]
      restartPolicy: Never

Pod Lifecycle Steps

Creation

The client submits a Pod manifest to the API server.

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

The scheduler selects a suitable node and sends a binding to the node’s kubelet.

The kubelet creates the containers, mounts volumes, and reports status back to the API server.

Deletion

The API server marks the Pod for termination (default graceful period 30 s).

The Pod is removed from Service endpoints.

If a preStop hook is defined, it is executed.

The kubelet sends SIGTERM to containers; after the grace period, SIGKILL is sent.

Persistent Volume Types

emptyDir – temporary storage tied to the Pod’s lifetime; data is deleted when the Pod is removed.

hostPath – mounts a directory from the host node into the container; creates a strong coupling between Pod and node.

PersistentVolume (PV) – provisioned storage with defined access modes and reclaim policies.

Access modes: ReadWriteOnce, ReadOnlyMany, ReadWriteMany.

Reclaim policies: Recycle (clear data), Retain (manual cleanup), Delete (delete underlying cloud storage).

Pods request storage via a PersistentVolumeClaim (PVC); the claim is bound to a PV with matching size, access mode, and storageClassName .