Containers and Cloud-Native Platforms

Introduction and Context

Cloud computing has evolved from provisioning complete virtual machines toward packaging applications as portable, independently deployable components. Containers support this transition by combining an application with its libraries, configuration defaults, and runtime dependencies while sharing the host operating system kernel. Containerization is not virtualization in the traditional sense: a virtual machine normally includes a guest operating system, whereas a container is an isolated process environment managed by a container runtime.

Containers are especially valuable in cloud environments because they improve deployment consistency, support rapid release cycles, and allow applications to be scaled horizontally. However, containers alone do not provide a complete production platform. Organizations also need image registries, orchestration, networking, service discovery, persistent storage, security controls, observability, and automated delivery. These capabilities together form a cloud-native operating model.

This chapter uses Kubernetes as the principal orchestration example. Kubernetes is an open-source platform for declaring the desired state of containerized workloads and continuously working to achieve that state. The concepts apply broadly to managed services such as Amazon Elastic Kubernetes Service, Azure Kubernetes Service, and Google Kubernetes Engine.

Learning Objectives

By the end of this chapter, you should be able to:

• explain container images, layers, registries, and runtimes;
• create secure and efficient container images;
• distinguish pods, deployments, services, ingress, and persistent volumes;
• describe Kubernetes control-plane and worker-node architecture;
• apply scheduling, scaling, health checking, and service-discovery concepts;
• design a small cloud-native deployment;
• identify operational, security, governance, and cost limitations; and
• evaluate a container platform using a realistic application scenario.

1. Container Fundamentals

A container image is an immutable, versioned package containing a filesystem, application binaries, metadata, and a startup instruction. An image is not normally executed directly. A container runtime uses the image to create a running container, which has a writable execution layer and isolated process, filesystem, and network views.

The major components are:

• Image: A read-only template used to create containers.
• Container: A running instance of an image.
• Container runtime: Software that downloads images and creates processes, namespaces, and resource controls. Examples include containerd and CRI-O.
• Image registry: A service that stores and distributes images, such as Docker Hub, Amazon Elastic Container Registry, Azure Container Registry, or Google Artifact Registry.
• Container engine: A developer-facing tool that builds and runs containers, such as Docker or Podman.

Linux containers commonly rely on namespaces for isolation and control groups (cgroups) for resource accounting and limiting. Namespaces can isolate process identifiers, networking, mounts, and users. Cgroups restrict or measure CPU and memory consumption. These mechanisms improve isolation but do not make a container equivalent to a separate physical machine; a kernel vulnerability or unsafe privilege configuration can affect the host.

Images and Layers

Images are generally assembled from layers. A Dockerfile instruction such as installing packages or copying application files may create a layer. Layers can be reused between images, reducing transfer time and storage. A change to an early layer can invalidate the cache for later layers, so Dockerfiles should place stable operations before frequently changing application code.

An image reference commonly has the form registry.example/team/app:1.4.2. The tag is human-readable but mutable unless the registry enforces immutability. A digest, such as sha256:..., identifies image content more precisely. Production deployments should use trusted, scanned images and, where reproducibility is critical, digest pinning.

Registries and Supply Chains

A registry normally supports authentication, repositories, tags, manifests, access control, vulnerability scanning, and retention policies. A secure image supply chain includes:

1. source-code review and dependency management;
2. reproducible or controlled image builds;
3. vulnerability and malware scanning;
4. image signing and provenance metadata;
5. promotion from development to testing and production registries; and
6. monitoring and rapid replacement of vulnerable versions.

Scanning is not a guarantee of safety. A clean scan can become outdated, and a vulnerability may be exploitable only under particular configurations. Teams must combine scanning with least privilege, patch management, runtime controls, and incident response.

2. Building Effective Container Images

A minimal example is:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ ./src/
RUN useradd --create-home appuser
USER appuser
EXPOSE 8080
CMD ["python", "src/server.py"]

This example separates relatively stable dependency installation from application code, uses a smaller base image, and avoids running the process as root. EXPOSE documents the intended port; it does not itself publish the port or create a cloud load balancer.

Professional image practices include:

• use a trusted, maintained base image;
• create a .dockerignore file to exclude credentials, build artifacts, and unnecessary files;
• use multi-stage builds so compilers and development tools do not remain in the runtime image;
• run one primary service per container where practical;
• write logs to standard output and standard error;
• handle termination signals and shut down gracefully;
• avoid embedding passwords, tokens, and private keys;
• pin important dependencies and rebuild regularly;
• define explicit health behavior; and
• keep the image small without sacrificing maintainability or security.

A container should generally be treated as disposable. Persistent business data should be stored in a database or persistent volume, not in the container's writable layer. Configuration that varies by environment should be supplied through environment variables, configuration objects, or secret-management systems rather than by rebuilding the image.

3. Kubernetes Architecture and Declarative Operation

Kubernetes follows a declarative model. An administrator describes the desired state, such as “run three replicas of this image,” and controllers compare actual state with desired state. They create, replace, or reschedule resources as necessary. This reconciliation model is a central cloud-native principle.

A Kubernetes cluster contains a control plane and worker nodes.

A pod is the smallest deployable Kubernetes unit. It may contain one or more tightly coupled containers that share a network namespace and, when configured, storage volumes. Most applications use one main container per pod, with sidecars only when their coupling is justified.

A Deployment manages replicated, replaceable pods and supports rolling updates and rollbacks. A ReplicaSet maintains a specified number of matching pods, although it is usually managed indirectly by a Deployment. A StatefulSet provides stable identities and ordered behavior for workloads requiring such properties. A DaemonSet places a pod on selected nodes, commonly for logging or monitoring agents. A Job runs a task to completion, while a CronJob creates Jobs on a schedule.

A simplified Deployment manifest is:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: registry.example/web:1.4.2
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

The selector must match the pod labels. A mismatch can cause the Deployment to manage no pods or the wrong pods. Resource requests influence scheduling; limits constrain consumption. The suffix m means millicpu, so 250m represents one quarter of a CPU unit. Memory quantities such as 256Mi use mebibytes, where 1 Mi = 2²⁰ bytes.

4. Networking, Services, Ingress, and Discovery

Pod IP addresses are ephemeral. Pods may be recreated on different nodes, so clients should not depend on pod addresses. Kubernetes provides a stable abstraction called a Service. A Service selects pods by labels and provides a virtual IP and DNS name.

Common Service types are:

• ClusterIP: Reachable only inside the cluster; the default type.
• NodePort: Exposes a port on each node; useful in limited scenarios but less flexible than a managed load balancer.
• LoadBalancer: Requests an external load-balancing integration from the cloud provider.
• ExternalName: Provides DNS-based indirection rather than proxying traffic.

Within a namespace, a Service can normally be addressed by a DNS name such as web.default.svc.cluster.local. This implements service discovery without hard-coding changing pod addresses.

An Ingress defines HTTP or HTTPS routing from outside the cluster to Services. It may route by hostname or path, terminate TLS, and apply request policies. An Ingress resource requires an Ingress controller; creating the resource alone does not provide a load balancer. Modern Kubernetes environments may also use the Gateway API, which offers more expressive and role-oriented traffic management.

Network policies restrict allowed traffic between pods and namespaces. A secure deployment should begin with a deny-by-default posture where feasible, then explicitly permit required flows. Policies depend on the cluster networking implementation and must be tested because an incorrectly written policy can block health checks, DNS, or application traffic.

5. Persistent Storage

Container filesystems are normally ephemeral. Kubernetes separates storage consumption from pod identity through abstractions such as:

• PersistentVolume (PV): A provisioned storage resource.
• PersistentVolumeClaim (PVC): A request for storage with capacity and access requirements.
• StorageClass: A policy describing dynamic provisioning, performance, and reclaim behavior.

Typical access modes include ReadWriteOnce, ReadOnlyMany, and ReadWriteMany, but exact support depends on the storage provider. A block volume may support attachment to one node, while a distributed file system may support multiple clients. Capacity, latency, durability, backup, encryption, and recovery objectives must be evaluated together.

A PVC is not automatically a backup. Deleting a workload, PVC, or namespace can have different effects depending on the volume's reclaim policy. Production systems require tested backups, restore procedures, and clear retention rules.

6. Scheduling, Health, and Scaling

The scheduler considers resource requests, node capacity, labels, affinities, taints, tolerations, topology constraints, and policy rules. A pod with a CPU request of 250m requires 0.25 CPU units of allocatable capacity, subject to platform-specific accounting. Requests are scheduling declarations, not a guarantee of actual performance; limits and node contention also matter.

Node labels support placement, while taints repel pods unless those pods have matching tolerations. Affinity can encourage or require placement near or away from selected workloads. Topology spread constraints help distribute replicas across zones or nodes, reducing correlated failure risk.

Kubernetes health probes have different purposes:

• Startup probe: Gives a slow-starting application time to initialize.
• Readiness probe: Determines whether a pod should receive traffic.
• Liveness probe: Indicates that a container may need restarting.

A liveness probe should not merely test whether a dependent database is available; otherwise a temporary database outage could cause every application replica to restart. Readiness is usually the appropriate mechanism for removing a temporarily incapable pod from traffic.

Scaling

Horizontal Pod Autoscaling (HPA) changes replica count based on observed metrics. For a simple CPU utilization target, average utilization can be represented as:

CPU usage and CPU requests must refer to compatible measurements over the same observation interval. HPA decisions are affected by sampling windows, stabilization behavior, startup time, and metric quality. HPA does not create additional cluster capacity; a cluster autoscaler or manually provisioned nodes may be needed.

For example, suppose three pods have CPU requests of 200m each and measured usage of 100m, 300m, and 200m. Total usage is 600m and total requests are 600m, so average utilization is (600 ÷ 600) × 100 = 100%. If the target is 70%, HPA will generally seek more replicas, subject to its configured limits and behavior. This calculation assumes the metric represents the same resource and interval for all pods.

Vertical scaling changes resource requests and limits, while cluster scaling changes node capacity. Autoscaling improves elasticity but can increase cost, create startup delays, and amplify instability if metrics or thresholds are poorly selected.

7. Deployment Strategies and Operations

A rolling update gradually replaces old pods with new ones. maxUnavailable limits capacity temporarily removed, while maxSurge controls additional pods created during the update. A rollback is possible when the platform retains the previous ReplicaSet and the image and configuration remain available.

A blue-green deployment maintains separate old and new environments and switches traffic after validation. It provides rapid rollback but temporarily requires additional capacity. A canary deployment sends a small proportion of traffic to the new version, allowing teams to compare error rates, latency, and business indicators before increasing exposure.

Cloud-native operations should include:

• centralized logs with correlation identifiers;
• metrics for traffic, errors, latency, saturation, and resource consumption;
• distributed tracing for multi-service requests;
• alerts tied to service-level objectives rather than every event;
• automated configuration and deployment through version control;
• vulnerability management and patch schedules; and
• tested disaster recovery and rollback procedures.

A useful reliability relationship is that an end-to-end service is constrained by its weakest critical dependency. If a request requires sequential components, their failure probabilities are not simply interchangeable, and correlated failures can dominate. Therefore, teams should map dependencies, define graceful degradation, and avoid assuming that replicas eliminate all failure modes.

8. Security, Governance, and Responsible Practice

Container security is a lifecycle concern. Important controls include:

• least-privilege container users and Kubernetes service accounts;
• restricted pod security settings;
• short-lived credentials and managed secrets;
• image signing, provenance, and admission policies;
• network segmentation and encrypted communication;
• encryption at rest for registry, cluster, and persistent data;
• audit logging and separation of duties; and
• regular review of third-party images and open-source licenses.

Secrets should not be committed to source control or placed casually in image layers. Kubernetes Secrets provide an API abstraction, but their protection depends on cluster access controls and encryption configuration. Highly sensitive credentials may be better managed by a dedicated cloud secret manager integrated through a controlled mechanism.

Governance also includes cost ownership. Excessive replicas, oversized resource requests, unused load balancers, unbounded logs, and continuously running development clusters create avoidable expenditure. Teams should use namespaces, quotas, labels, budgets, and lifecycle policies. Compliance requirements may determine data residency, audit retention, encryption algorithms, and administrator access.

9. Illustrative Case: Containerizing a Student Assessment Platform

Background

A college operates an assessment platform consisting of a web interface, an API, a worker that processes submitted files, and a relational database. The original system runs on one virtual machine. Releases are infrequent because dependencies conflict, and a machine failure interrupts all functions.

Problem Analysis

The web and API components are stateless and can be replicated. The worker is asynchronous and can scale according to queue depth. The database is stateful and requires backups, durable storage, access control, and careful migration management. Uploads should not be stored in container filesystems because pods may be replaced.

Approach

The team builds separate images for the web, API, and worker. Multi-stage builds exclude compilers from runtime images, and each image runs as a non-root user. Images are scanned and promoted through a private registry.

A Kubernetes Deployment manages three API replicas. A ClusterIP Service provides internal discovery, while an Ingress terminates TLS and routes requests to the web and API Services. Readiness probes prevent initialization-incomplete pods from receiving traffic. A Horizontal Pod Autoscaler adjusts API replicas based on CPU and request latency, while a queue-based worker scaler responds to pending jobs.

The database runs on a managed cloud database rather than inside the initial cluster. Uploaded files use object storage, and the API stores object references in the database. Network policies permit the API to reach the database and object-storage endpoint but deny unrelated pod traffic. Resource requests are based on load tests, not guesses. Backups are restored in a separate environment before the system is declared production-ready.

Outcome

Releases become repeatable and can be rolled back. API capacity scales independently from worker capacity, and a failed pod is recreated automatically. The design does not eliminate operational responsibility: database migrations, secrets, image updates, observability, and cost monitoring remain essential.

Learning Points

The case demonstrates that cloud-native architecture is more than placing an application in a container. It requires separating stateless and stateful concerns, designing explicit interfaces, selecting suitable managed services, and validating operational behavior through testing.

10. Limitations and Contemporary Developments

Containers introduce complexity. Kubernetes has a substantial learning curve, and a cluster can be excessive for a small application. Distributed systems create failure modes involving DNS, certificates, identity, networking, scheduling, and eventual consistency. Managed Kubernetes reduces control-plane administration but does not remove application-level security or reliability work.

Service meshes can provide traffic policy, mutual TLS, retries, and telemetry, but they add proxies, configuration, and operational overhead. Serverless containers can simplify infrastructure management for intermittent workloads, while edge and confidential-computing technologies address specialized requirements. Platform engineering teams increasingly provide internal “golden paths” that standardize secure deployment without hiding important operational constraints.

AI-assisted tools can help generate manifests, explain logs, suggest resource settings, or detect anomalous behavior. Their output must be reviewed because generated configurations may expose services, grant excessive permissions, select unsuitable probes, or contain insecure defaults. Human accountability, testing, and policy enforcement remain necessary.

Best-Practice Checklist

Before production deployment, verify that:

1. images are versioned, scanned, signed where required, and built from trusted sources;
2. containers avoid root privileges and receive only necessary capabilities;
3. resource requests and limits are based on measurements;
4. readiness, liveness, and startup probes reflect real application behavior;
5. Services and Ingress expose only intended traffic;
6. network policies and identity permissions follow least privilege;
7. state is stored on durable, backed-up services;
8. logs, metrics, traces, and alerts are operationally useful;
9. deployment and rollback procedures have been tested; and
10. cost, compliance, and ownership are visible.

Chapter Summary

Containers package applications into portable runtime units, while images, registries, and runtimes form the foundation of a reliable delivery process. Kubernetes extends containers with declarative reconciliation, scheduling, rolling deployment, service discovery, ingress, storage, health management, and autoscaling. Pods are ephemeral, so stable Services and external durable storage are essential. Resource requests influence scheduling, probes control traffic and recovery behavior, and autoscaling depends on meaningful metrics and available node capacity. Secure cloud-native operation requires trusted image supply chains, least privilege, network controls, secret protection, observability, backups, governance, and cost discipline. The central design lesson is that containerization is an architectural and operational practice, not merely a packaging command.

Key Terms

Container: An isolated running process created from an image.

Container image: An immutable package containing application files, dependencies, and metadata.

Registry: A repository service for storing and distributing images.

Layer: A reusable filesystem change that contributes to an image.

Runtime: Software that creates and manages containers.

Pod: Kubernetes’ smallest deployable unit.

Deployment: A controller that manages replicated, replaceable pods.

Service: A stable virtual endpoint for a set of pods.

Ingress: HTTP or HTTPS routing into cluster Services.

Service discovery: Locating services through stable names or endpoints.

PersistentVolume: A durable storage resource available to workloads.

PersistentVolumeClaim: A workload request for persistent storage.

Scheduler: The Kubernetes component that assigns pods to nodes.

Readiness probe: A health test determining whether a pod receives traffic.

Liveness probe: A health test that can trigger container restart.

Horizontal scaling: Increasing or decreasing the number of workload replicas.

Network policy: A rule controlling permitted pod communication.

Rolling update: Gradual replacement of one application version by another.

Declarative configuration: A description of desired state reconciled by controllers.

Cloud-native: An approach emphasizing automation, elasticity, resilience, and independently deployable services.

Review Questions

Short Answer Questions

1. What is the difference between a container image and a running container?
2. Why should production applications avoid storing important data in a container’s writable layer?
3. What role does a Kubernetes Service perform?
4. Distinguish a readiness probe from a liveness probe.
5. Why are resource requests important for scheduling?

Long Answer Questions

1. Explain the architecture of a Kubernetes cluster and the responsibilities of its principal components.
2. Describe a secure container image supply chain from source code to production deployment.
3. Compare ClusterIP, NodePort, LoadBalancer, and Ingress-based exposure.
4. Explain how persistent storage is provisioned and why backups are separate from PVCs.
5. Compare rolling, blue-green, and canary deployment strategies, including their operational trade-offs.

Analytical / Application Questions

1. A service has three replicas, but users receive errors during deployment. Analyze how labels, readiness probes, rolling-update limits, and Service selection could contribute to the problem.
2. Design a Kubernetes architecture for an image-processing system with a web front end, asynchronous workers, object storage, and a relational database. Justify which components should be stateless, scaled, or managed externally.
3. A cluster has frequent out-of-memory restarts and rising cloud cost. Propose a diagnostic and remediation plan involving metrics, requests, limits, autoscaling, image behavior, and governance.

Multiple Choice Questions with Answers

Question 1

Which Kubernetes object provides a stable network endpoint for a changing set of pods?

A. Service

B. ConfigMap

C. ReplicaSet

D. PersistentVolume

Correct Answer: A. Service

Question 2

What is the principal purpose of a readiness probe?

A. To build a new image

B. To determine whether a pod should receive traffic

C. To encrypt an image registry

D. To allocate a persistent disk

Correct Answer: B. To determine whether a pod should receive traffic

Question 3

Which component selects a suitable worker node for an unscheduled pod?

A. Kubelet

B. Ingress controller

C. Scheduler

D. Registry

Correct Answer: C. Scheduler

Question 4

A container image digest is preferable to a mutable tag when the primary requirement is:

A. Reproducible identification of exact image content

B. Automatic selection of the newest image

C. Changing application configuration at runtime

D. Increasing pod CPU capacity

Correct Answer: A. Reproducible identification of exact image content

Question 5

Three pods have CPU requests of 200m each and usage values of 100m, 300m, and 200m. What is their average CPU utilization?

A. 50%

B. 70%

C. 100%

D. 150%

Correct Answer: C. 100%

Question 6

Which resource is normally used to request durable storage for a pod?

A. Ingress

B. PersistentVolumeClaim

C. ReplicaSet

D. NodePort

Correct Answer: B. PersistentVolumeClaim

Question 7

What is a major limitation of horizontal pod autoscaling?

A. It cannot change the number of replicas

B. It automatically creates unlimited storage

C. It does not itself guarantee additional cluster node capacity

D. It prevents all application failures

Correct Answer: C. It does not itself guarantee additional cluster node capacity

Question 8

Which practice best reduces the risk of credential exposure in container images?

A. Copy credentials into the Dockerfile

B. Store credentials in image layers

C. Use a controlled secret-management system at runtime

D. Publish the credentials in a private image tag

Correct Answer: C. Use a controlled secret-management system at runtime

Question 9

What does a ClusterIP Service normally provide?

A. Internal cluster access to selected pods

B. A physical server for every pod

C. A container image build environment

D. Automatic database backup

Correct Answer: A. Internal cluster access to selected pods

Question 10

Which deployment strategy sends a small proportion of traffic to a new version before wider release?

A. Blue-green only

B. Canary

C. DaemonSet

D. Reclaim policy

Correct Answer: B. Canary