3.1 Core Workload Objects (Pods, Deployments & ReplicaSets)

Kubernetes and Cloud Native Associate KCNA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the KCNA Exam & Certification Path 1.2 How to Use This Study Guide

2 Chapter 2: Kubernetes Fundamentals - Cluster Architecture & the API

2.1 Kubernetes Architecture & Control Plane Components 2.2 Worker Node Architecture & Node Components 2.3 Kubernetes API, Declarative Management & kubectl 2.4 Kubernetes Releases, API Versioning & Deprecation Policy

3 Chapter 3: Kubernetes Fundamentals - Workloads & Configuration

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets) 3.2 Advanced Controllers (StatefulSets, DaemonSets, Jobs & CronJobs) 3.3 Namespaces, Labels, Selectors & Annotations 3.4 ConfigMaps, Secrets & Application Configuration 3.5 Pod & Container Lifecycle, Restart Policies & Graceful Termination

4 Chapter 4: Kubernetes Fundamentals - Scheduling & Autoscaling

4.1 Scheduling, Resource Management & Node Selection 4.2 Advanced Scheduling: Affinity, Topology Spread, Priority & Disruption Budgets 4.3 Autoscaling Workloads & Clusters (HPA, VPA, Cluster Autoscaler, KEDA)

5 Chapter 5: Kubernetes Fundamentals - Cluster Administration & Extensibility

5.1 Kubernetes Distributions, Installation Tools & Managed Services 5.2 Cluster Administration: Node Maintenance, Upgrades & etcd Backup 5.3 Extending Kubernetes: CRDs, Operators & the Controller Pattern

6 Chapter 6: Kubernetes Fundamentals - Containerization

6.1 Container Fundamentals, Runtimes & Registries 6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

7 Chapter 7: Container Orchestration - Networking & Service Discovery

7.1 Kubernetes Networking, Services & Ingress 7.2 Cluster DNS & Service Discovery with CoreDNS 7.3 NetworkPolicies, Zero-Trust Segmentation & the Gateway API

8 Chapter 8: Container Orchestration - Storage

8.1 Storage Concepts (PVs, PVCs, StorageClasses & CSI) 8.2 Volume Types, Snapshots & Stateful Storage Operations

9 Chapter 9: Container Orchestration - Security

9.1 Kubernetes Security & Access Control (RBAC & ServiceAccounts) 9.2 The 4C's of Cloud Native Security & Supply-Chain Trust 9.3 Service Mesh, mTLS & Zero-Trust Service Identity

10 Chapter 10: Container Orchestration - Troubleshooting

10.1 Container Troubleshooting & Health Probes 10.2 Cluster & Node-Level Troubleshooting

11 Chapter 11: Cloud Native Application Delivery

11.1 Cloud Native CI/CD Pipelines & Build Tooling 11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux) 11.3 Deployment Strategies & Release Management 11.4 Progressive Delivery Automation: Argo Rollouts, Flagger & Feature Flags 11.5 Application Debugging & Developer Workflows in Kubernetes 11.6 Platform Engineering & Developer Self-Service

12 Chapter 12: Cloud Native Architecture - Observability & Principles

12.1 Cloud Native Observability (Logging, Metrics & Tracing) 12.2 Cloud Native Principles & Architecture Patterns 12.3 Serverless, FaaS & Event-Driven Architecture

13 Chapter 13: Cloud Native Architecture - CNCF Ecosystem & Community

13.1 The CNCF Landscape, Governance & Project Lifecycle 13.2 Cloud Native Community, Collaboration & Contribution

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets)

Key Takeaways Explain This Topic AI

A Pod is the smallest execution unit in Kubernetes, wrapping one or more containers that share network namespaces (IP address and port space) and storage volumes.

Multi-container Pod patterns include Sidecar containers (auxiliary tasks like logging or proxying) and Init containers (run sequentially to completion before app containers start).

ReplicaSets maintain a specified replica count of identical Pods using declarative label selectors (matchLabels and matchExpressions) to ensure high availability and self-healing.

Deployments provide declarative state management over ReplicaSets, enabling automated rolling updates (maxSurge, maxUnavailable), zero-downtime upgrades, revision tracking, and rollbacks.

kubectl rollout undo allows reverting a Deployment to a previous revision, leveraging underlying ReplicaSet revision history preserved by Kubernetes.

Last updated: August 2026

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets)

In Kubernetes, applications are rarely deployed as bare, standalone containers. Instead, Kubernetes abstracts containerized software into structured workload API objects. Understanding the fundamental workload primitives— Pods , ReplicaSets , and Deployments —is central to mastering Kubernetes architecture and passing the KCNA exam.

1. Pod Anatomy & Shared Namespaces

A Pod is the basic building block of Kubernetes—the smallest and simplest deployable object in the Kubernetes object model. A Pod represents a single instance of a running process in your cluster and wraps one or more containers (such as Docker or containerd containers).

The Single-Container vs. Multi-Container Pod

In the vast majority of cloud-native use cases, Pods follow a single-container pattern, where one Pod encapsulates a single application process (e.g., a Python web server or a Go microservice). However, Kubernetes explicitly supports multi-container Pods , where two or more tightly coupled containers share resources and lifetime.

When containers are co-located within the same Pod, Kubernetes configures them to share critical Linux kernel namespaces:

Shared Network Namespace : All containers in a Pod share the same network stack, IP address, network interface, and port space. Containers within the same Pod can communicate with each other over localhost (using IPC or loopback networking).

Shared Storage Volumes : Pods can define shared storage volumes mounted into the filesystem of each container, enabling high-speed local file sharing between containers.

Shared Lifecycle : All containers in a Pod are scheduled onto the same worker node, started together, and terminated together.

Note

Because containers inside a single Pod share the same network namespace, two containers in the same Pod cannot bind to the same network port (e.g., both trying to listen on port 8080 ), or a port conflict will occur.

2. Multi-Container Pod Patterns

When building complex container workloads, multi-container Pods utilize standardized design patterns to extend application functionality without mutating the primary application container image.

The Sidecar Pattern

A Sidecar container runs alongside the primary application container within the same Pod. Its purpose is to enhance, protect, or extend the primary container without changing its core source code. Common sidecar examples include:

Log Collectors : A sidecar tailing local log files generated by the app container and streaming them to centralized storage (e.g., Fluentd or Vector).

Service Mesh Proxies : A sidecar proxying network traffic for security and telemetry (e.g., Envoy in an Istio service mesh).

Configuration Refreshers : A sidecar monitoring external secrets vaults and updating local config files.

Init Containers

Init containers are specialized containers that run to completion before standard application containers are started. A Pod can have multiple init containers, which execute sequentially in the exact order defined in the YAML manifest.

Key characteristics of Init containers include:

They always run to completion before the next init container or application container starts.

If an init container fails, Kubernetes restarts the Pod repeatedly until the init container succeeds (governed by the Pod's restartPolicy ).

They are commonly used for setup tasks, such as populating database schemas, generating cryptographic certificates, or waiting for a dependency service to become reachable over the network. apiVersion: v1

kind: Pod

metadata:

name: myapp-pod

labels:

app.kubernetes.io/name: myapp

spec:

initContainers:

• name: init-myservice
• image: busybox:1.36
• command: ['sh', '-c', 'until nc -z -w 2 myservice 6379; do echo waiting for redis; sleep 2; done']

containers:

• name: myapp-container
• image: nginx:1.25

ports:

• containerPort: 80
• name: log-sidecar
• image: busybox:1.36
• command: ['sh', '-c', 'tail -n+1 -F /var/log/nginx/access.log']
• 3. ReplicaSets: Ensuring Pod Replication

While you can create individual Pods directly in Kubernetes, doing so creates naked Pods . If the underlying worker node fails, naked Pods are not rescheduled or recovered. To ensure resilience and scalability, Kubernetes uses controllers to manage Pod lifecycles.

A ReplicaSet is a controller whose primary purpose is to maintain a stable set of identical, running Pod replicas at any given time. It guarantees the availability of a specified number of Pods.

Label Selectors

ReplicaSets locate the Pods they are responsible for managing through Label Selectors . Rather than tracking Pods by direct name, a ReplicaSet queries Pod labels in the cluster using two selector forms:

matchLabels : Simple key-value equality matching (e.g., app: frontend ).

matchExpressions : Advanced set-based filtering (e.g., environment in (production, staging) ).

If a Pod managed by a ReplicaSet crashes or its node dies, the ReplicaSet controller detects that the current count of matching Pods is below the desired replicas count and automatically provisions a new Pod from its embedded template spec.

4. Deployments: Declarative Updates & Rollbacks

In modern production environments, operators rarely manage ReplicaSets directly. Instead, they use Deployments . A Deployment is a higher-level declarative object that manages ReplicaSets underneath, providing declarative updates for Pods and ReplicaSets. +-------------------------------------------------------+

• | Deployment |
• +-------------------------------------------------------+
• |
• v
• +-------------------------------------------------------+
• | ReplicaSet (Revision 2) |
• +-------------------------------------------------------+
• | | |
• v v v
• +---------+ +---------+ +---------+
• | Pod | | Pod | | Pod |
• +---------+ +---------+ +---------+
• Rolling Updates & Rollback Mechanics

When you modify a Deployment's Pod template (e.g., updating the container image version), the Deployment controller creates a new ReplicaSet and performs a Rolling Update . It gradually scales up the new ReplicaSet while scaling down the old ReplicaSet, ensuring zero application downtime.

Rolling updates are controlled by two key parameters under spec.strategy.rollingUpdate :

maxSurge : The maximum number (or percentage) of Pods that can be created above the desired replica count during an update (e.g., 25% ).

maxUnavailable : The maximum number (or percentage) of Pods that can be unavailable during the update process (e.g., 25% ).

Revision History & Rollbacks

Kubernetes tracks Deployment updates by saving past ReplicaSets as revision history. If a new deployment fails (e.g., due to a broken image tag or crash-looping code), you can instantly revert to a previous working state: # Check rollout history

kubectl rollout history deployment/web-app

• # Rollback to the immediate previous revision
• kubectl rollout undo deployment/web-app

• # Rollback to a specific historical revision
• kubectl rollout undo deployment/web-app --to-revision=2
• 5. Workload Comparison Summary

• Feature Pod ReplicaSet Deployment
• Abstraction Level Low (Basic unit) Medium (Replication) High (Workload lifecycle)
• Self-Healing No (Naked Pod) Yes (Maintains count) Yes (Via ReplicaSets)
• Rolling Updates No No Yes (Automated zero-downtime)
• Revision History No No Yes (Undo/rollback supported)
• Direct Usage Testing / One-off Rare (Managed by Deployment) Primary production pattern apiVersion: apps/v1
• kind: Deployment

metadata:

name: frontend-deployment

labels:

app: frontend

spec:

replicas: 3

strategy:

type: RollingUpdate

rollingUpdate:

• maxSurge: 1
• maxUnavailable: 0

selector:

matchLabels:

app: frontend

template:

metadata:

labels:

app: frontend

spec:

containers:

• name: nginx
• image: nginx:1.25.3

ports:

- containerPort: 80