KCNA Ep 3: Container Orchestration & Workload Primitives

TL;DR (Quick Summary)

#

• Pod: Smallest deployable unit in K8s (contains 1 or more co-located containers sharing network/storage).
• Deployment: Best for stateless applications (web APIs, microservices) requiring rolling updates and autoscaling.
• StatefulSet: Best for stateful applications (Databases, Kafka, Redis) requiring sticky network IDs (db-0, db-1) and ordered provisioning.
• DaemonSet: Runs exactly 1 pod on every node (Log collectors like Fluentd, CNI networking agents, monitoring agents).
• Job / CronJob: Executable batch tasks that run to completion (run-once or on a cron schedule).

1. Workload Controller Hierarchy

#

graph TD
    Deployment["Deployment Controller"] -->|Manages Revisions| ReplicaSet["ReplicaSet"]
    ReplicaSet -->|Scales Replicas| Pod1["Pod (instance 1)"]
    ReplicaSet -->|Scales Replicas| Pod2["Pod (instance 2)"]

    StatefulSet["StatefulSet"] -->|Ordered Identity| PodS0["Pod (db-0)"]
    StatefulSet -->|Ordered Identity| PodS1["Pod (db-1)"]

    DaemonSet["DaemonSet"] -->|Per Node| PodNode1["Pod (Node 1)"]
    DaemonSet -->|Per Node| PodNode2["Pod (Node 2)"]

2. Detailed Workload Resource Comparison

#

1. Pods (The Atomic Unit)

#

• A Pod wraps one or more containers (e.g., main app container + sidecar logging container).
• Shared Context: All containers inside a single Pod share the same Linux network namespace (same localhost and IP address) and storage volumes.
• Ephemeral: Pod IPs change when pods restart or move to another node.

2. Deployments & ReplicaSets

#

• Designed for stateless microservices.
• ReplicaSet: Guarantees that a specified number of Pod replicas are running at any given time.
• Deployment: Wraps ReplicaSets to support declarative Rolling Updates and Rollbacks without downtime:

  kubectl rollout undo deployment/web-api

3. StatefulSets

#

• Designed for stateful workloads (PostgreSQL, Cassandra, Elasticsearch, ZooKeeper).
• Key Features:
  • Stable Network ID: Pods receive predictable hostnames (mysql-0, mysql-1, mysql-2) instead of random hash suffixes.
  • Stable Storage: Each Pod replica receives its own dedicated PersistentVolumeClaim (PVC) that remains bound even if the Pod is rescheduled.
  • Ordered Execution: Pods are created sequentially (0 -> 1 -> 2) and terminated in reverse order.

4. DaemonSets

#

• Ensures that all (or selected) worker nodes run a copy of a Pod.
• Automatically schedules Pods onto newly added nodes in the cluster.
• Common Use Cases:
  • Log collection daemons: fluentd, filebeat.
  • Cluster monitoring daemons: prometheus-node-exporter.
  • Networking agents: kube-proxy, calico-node.

5. Jobs & CronJobs

#

• Job: Creates one or more Pods and ensures that a specified number of them successfully terminate (exit code 0). Used for database migrations, batch processing, and reporting.
• CronJob: Manages Jobs on a time-based schedule (standard Linux cron syntax):

  schedule: "0 2 * * *" # Runs daily at 2:00 AM

3. Workload Comparison Summary Table

#

4. Key KCNA Exam Practice Questions

#

Question 1

#

Which workload controller is specifically designed to run exactly one instance of a Pod on every worker node in a Kubernetes cluster?

• A) Deployment
• B) StatefulSet
• C) DaemonSet (Correct)
• D) CronJob

Rationale: DaemonSets ensure node-level coverage for infrastructure agents like log collectors and monitoring exporters.

Question 2

#

What workload object should you select when deploying a MySQL primary-replica cluster that requires stable network hostnames (mysql-0, mysql-1) and persistent storage binding?

• A) Deployment
• B) StatefulSet (Correct)
• C) ReplicaSet
• D) DaemonSet

Rationale: StatefulSets provide ordinal index names and persistent volume claim bindings necessary for stateful database clusters.

Summary & Next Steps

#

In this episode, we covered:

• The distinction between stateless (Deployments) and stateful (StatefulSets) workloads.
• Per-node execution using DaemonSets.
• Batch processing using Jobs and CronJobs.

In KCNA Episode 4: Telemetry, Observability & Monitoring, we will examine Prometheus, Grafana, OpenTelemetry, Jaeger, and Fluentbit!