Container Orchestration Language — Cloud-Native Exercises

1 / 5

A senior architect says: "The logging sidecar runs in the same pod as the application container."

What does co-location inside the same pod guarantee that running the two containers in separate pods would not provide?

A pod is a co-scheduling boundary with shared Linux namespaces — it is not just a logical grouping.

What containers in the same pod share:

Shared resource	What this means in practice
Network namespace	Same IP address. Containers communicate via `localhost:port` — no DNS, no service mesh resolution needed
PID namespace (optional)	Containers can see each other's processes if `shareProcessNamespace: true`
IPC namespace	Shared memory and semaphores between containers
Volumes	Pod-level volumes can be mounted by multiple containers (e.g., app writes logs → sidecar reads and ships them)
Node placement	Scheduler places the entire pod on one node — containers are always co-located

What containers in the same pod do NOT automatically share:
• File system — each container has its own root FS from its image. Shared data requires explicit volumeMount
• Resource limits — each container in the pod spec has its own resources.requests / resources.limits
• Restart behaviour — containers can crash and restart independently; a crashing sidecar does not restart the main container (unless restartPolicy triggers the whole pod)

Key vocabulary:
• Pod — the smallest deployable unit in Kubernetes; one or more containers sharing network and storage namespaces
• Sidecar container — a secondary container in the same pod that augments the main application (logging, proxying, config injection)
• Network namespace — the Linux kernel resource that isolates networking; containers in the same pod share it
• Co-scheduling — Kubernetes guarantees all containers in a pod run on the same worker node

2 / 5

A platform engineer says: "We use a StatefulSet for our Kafka brokers because each pod needs a stable hostname and its own dedicated persistent volume."

Which characteristic of StatefulSets is being described that a Deployment cannot provide?

StatefulSets were designed for workloads that need persistent identity — distributed databases, message brokers, and consensus systems.

Deployment vs StatefulSet — what differs:

Property	Deployment	StatefulSet
Pod names	Random suffix: `app-7f4b2c-xkpq9`	Stable ordinal: `kafka-0`, `kafka-1`
DNS hostname	Not addressable by pod name	Each pod gets a stable DNS entry via a Headless Service
Storage	Shared or ephemeral volumes only	`volumeClaimTemplates` — each pod gets its own PVC, retained on restart
Pod ordering	All pods start/stop in parallel	Sequential: `kafka-0` starts before `kafka-1`
Rolling update	Can update all pods simultaneously with surge	Updates one pod at a time, in reverse ordinal order

When to use StatefulSet:
• Distributed databases: PostgreSQL (Patroni), MySQL, MongoDB, Cassandra
• Message brokers: Kafka, RabbitMQ
• Consensus systems: etcd, ZooKeeper
• Any workload where each instance must be individually addressable and retain data across restarts

Key vocabulary:
• StatefulSet — a Kubernetes workload controller that provides stable network identities and persistent storage to pods
• Headless Service — a Service with clusterIP: None that creates individual DNS records for each StatefulSet pod
• volumeClaimTemplates — per-pod PVC templates in a StatefulSet; each replica gets its own bound PersistentVolumeClaim
• Ordinal index — the sequential integer suffix (0, 1, 2…) in a StatefulSet pod's name

3 / 5

A developer says: "We need a LoadBalancer Service for the public-facing API, not a ClusterIP."

What does a ClusterIP Service provide, and what does the LoadBalancer type add on top of that?

Kubernetes Service types form a hierarchy — each type extends the one below it.

Service type	Reachable from	Common use case
ClusterIP (default)	Inside the cluster only via stable virtual IP	Internal service-to-service communication
NodePort	Any node's IP on a static high port (30000–32767)	Development/testing; bare-metal clusters
LoadBalancer	External public IP from cloud provider	Exposing a single service to the internet
ExternalName	Maps to an external DNS name	Aliasing an external database or third-party API

How LoadBalancer works in a managed cluster (GKE, EKS, AKS):
① Kubernetes calls the cloud provider's API to provision a cloud load balancer (AWS ALB/NLB, GCP Cloud Load Balancer, Azure Load Balancer)
② The load balancer gets a public IP (or hostname for NLB)
③ Traffic flows: Internet → Cloud LB → NodePort → kube-proxy → Pod
④ The LoadBalancer service still creates a ClusterIP and NodePort under the hood

When to use Ingress instead:
LoadBalancer creates one cloud LB per service — expensive for many services. An Ingress controller uses a single LB and routes by hostname/path, making it far more cost-effective for multi-service platforms.

Key vocabulary:
• ClusterIP — stable virtual IP for a Service, routable only within the cluster
• LoadBalancer Service — extends ClusterIP by provisioning an external cloud load balancer with a public IP
• kube-proxy — runs on each node; implements Service VIP routing using iptables or IPVS rules
• Ingress — an API object that defines HTTP/HTTPS routing rules; requires an Ingress controller (nginx, Traefik, ALB controller)

4 / 5

A DevOps engineer says: "We isolate dev, staging, and production using Kubernetes namespaces, so pods in different environments cannot communicate."

Which statement correctly describes a common misconception about namespace isolation?

Namespace ≠ network boundary. This is one of the most common Kubernetes security misconceptions.

What namespaces DO provide:

Feature	How namespaces help
Name scoping	Resource names only need to be unique within a namespace
RBAC scope	RoleBindings are namespace-scoped; restrict which teams can access which resources
Resource quotas	Limit total CPU/memory consumption per namespace
LimitRange	Set default and maximum resource limits per container in the namespace

What namespaces do NOT provide (by default):
• Network isolation — any pod can reach any other pod by ClusterIP or DNS name (service.other-namespace.svc.cluster.local) across namespaces unless a CNI-enforced NetworkPolicy blocks the traffic
• Node isolation — pods from different namespaces can run on the same node; node-level isolation requires Taints/Tolerations or dedicated node pools
• Container isolation — not a security boundary at the kernel level

To actually restrict inter-namespace traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-from-other-namespaces
  namespace: production
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}   # allow only within this namespace

Key vocabulary:
• Namespace — a virtual partition for Kubernetes resources providing name scoping, RBAC, and quotas — not a security or network boundary
• NetworkPolicy — a Kubernetes resource that defines ingress/egress traffic rules; enforced by the CNI plugin (Calico, Cilium, Weave Net)
• CNI (Container Network Interface) — the plugin that implements pod networking; must support NetworkPolicy for it to be enforced
• ResourceQuota — caps total resource consumption within a namespace

5 / 5

An SRE explains: "We configure a CPU request of 250m and a CPU limit of 1000m for the application container — the request is deliberately lower than the limit."

Which statement correctly explains the operational difference between a resource request and a limit in Kubernetes?

Requests and limits operate at two different moments in the pod lifecycle: scheduling time and runtime.

Property	Request	Limit
When used	Scheduling time — node selection	Runtime — enforcement by kernel
CPU behaviour	Scheduler sums all requests on a node; won't place pod if available CPU < request	Container is CPU-throttled (not killed) when it exceeds the limit — CFS scheduler enforces it
Memory behaviour	Same scheduling logic as CPU	Container is OOM-killed if it exceeds memory limit (memory cannot be throttled)
QoS class	Requests = limits → Guaranteed Requests < limits → Burstable No requests/limits → BestEffort	Affects eviction priority under node pressure

The 250m/1000m strategy explained:
• 250m request means the scheduler only needs a node with 250 milli-CPUs free — allowing dense pod packing
• 1000m limit means the container can burst to 1 full CPU when the node is not busy
• If the node is under pressure and many pods try to burst simultaneously, they are throttled back toward their requests

Common mistake — setting no limits:
Without a memory limit, a leaked memory application can consume all node memory, causing the kernel's OOM killer to terminate other pods on the same node — a noisy-neighbour problem.

Key vocabulary:
• Resource request — the minimum guaranteed resource reservation used by the scheduler for pod placement
• Resource limit — the maximum resource a container may consume; enforced by the Linux kernel at runtime
• OOM-kill — the kernel terminating a process because it exceeded its memory limit
• CPU throttling — reducing a container's CPU time share when it exceeds its limit; no termination, but increased latency
• QoS class — Kubernetes quality-of-service classification (Guaranteed / Burstable / BestEffort) that determines eviction priority