Containers, Orchestration and Cloud-Native Delivery

Introduction

Modern DevOps practices increasingly package applications as containers and operate them through orchestration platforms. Containers provide a consistent unit of software delivery: the application, its runtime dependencies, configuration defaults and required libraries are assembled into an image that can run across a developer workstation, a test environment or a cloud platform. Orchestration adds automation for scheduling, networking, scaling, service discovery, health checking and replacement of failed workloads.

Containers do not eliminate operational responsibility. A poorly constructed image may contain vulnerabilities, unnecessary tools, secrets or excessive privileges. An incorrectly configured orchestrator may expose internal services, lose data or create unreliable deployments. Cloud-native delivery therefore combines technical mechanisms with disciplined security, governance and operational practices.

This chapter introduces container images, Dockerfile construction, registries, container execution and the foundational Kubernetes concepts required to deploy basic applications.

Learning Objectives

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

• explain containers, images, layers, registries and runtimes;
• construct a secure and efficient container image;
• build, tag, scan, publish and retrieve images from a registry;
• distinguish containers from virtual machines;
• explain clusters, nodes, workloads, services, scaling and configuration;
• describe the roles of Kubernetes objects such as Pods, Deployments, Services and ConfigMaps;
• deploy and inspect a basic containerized application;
• identify common security, reliability and governance risks in cloud-native delivery.

1. Containers as a Delivery Abstraction

A container is an isolated process that uses operating-system features to separate its filesystem, process view, network environment and resource controls from other processes. Unlike a virtual machine, a container normally shares the host operating-system kernel. This makes containers comparatively lightweight and fast to start, although it also means that kernel security and runtime configuration remain important.

A container image is an immutable, versioned package used to create containers. It contains a filesystem representation and metadata, including the command to execute, environment defaults and sometimes health-check information. A running container is an instance of an image with a writable runtime layer and assigned resources.

The distinction between image and container is fundamental:

An image is commonly composed of read-only layers. Each Dockerfile instruction may create a layer, although implementation details depend on the builder. Layers can be cached and shared between images. This reduces transfer and storage costs, but it also means that sensitive data copied into an earlier layer may remain recoverable even if a later instruction deletes it. Secrets must never be placed in image build instructions or copied into an image.

Containers and Virtual Machines

A virtual machine includes a guest operating system and runs through a hypervisor. A container generally shares the host kernel and isolates processes using mechanisms such as namespaces and control groups. Virtual machines usually provide stronger isolation boundaries and can run different kernels, while containers generally offer faster startup and greater packaging portability. In production, both technologies may be used together: Kubernetes nodes may themselves be virtual machines running container workloads.

Containers are not automatically secure sandboxes. A container process may still access sensitive host capabilities if it is granted excessive privileges, host namespaces, host paths or Linux capabilities. Security depends on the image, runtime, kernel, orchestration policy and operating procedures.

2. Building Reliable and Secure Images

A Dockerfile describes how a builder constructs an image. 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/ .
RUN useradd --create-home --uid 10001 appuser
USER appuser
EXPOSE 8080
CMD ["python", "app.py"]

This example illustrates several principles:

1. Choose a trustworthy base image. Use an official or internally approved image, record its version and monitor its vulnerabilities.
2. Keep the image small. A smaller image usually transfers faster and contains fewer packages that could be vulnerable. Small size, however, must not compromise required runtime functionality.
3. Use a non-root user. If an application is compromised, a non-root process generally has fewer permissions than a root process.
4. Copy only required files. A .dockerignore file should exclude source-control metadata, local virtual environments, credentials, build output and other irrelevant material.
5. Separate dependency installation from frequently changing source files. This improves build-cache reuse.
6. Use exec-form commands. For example, CMD ["node", "server.js"] normally provides clearer signal handling than a shell-form command.
7. Do not store secrets in the image. Supply credentials at runtime through a managed secret mechanism.
8. Make the process observable. Applications should write logs to standard output and expose suitable health or metrics endpoints.

A multi-stage build separates compilation tools from the runtime image:

FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/server ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/server /server
USER  nonroot:nonroot
ENTRYPOINT ["/server"]

The first stage contains compilers and development dependencies; the final stage contains only the executable and the minimum runtime contents. Multi-stage builds improve the attack surface and image size, but the resulting application must be tested carefully, especially when it depends on native libraries, certificates, time-zone data or shell utilities.

Image Security Controls

Image security is best treated as a supply-chain process rather than a single scan. Important controls include:

• maintain an approved base-image catalogue;
• pin important dependencies and review updates;
• generate a software bill of materials (SBOM);
• scan operating-system packages and application dependencies;
• sign images and verify signatures where supported;
• use provenance or build-attestation data;
• reject images with unacceptable vulnerabilities according to risk policy;
• rebuild regularly, because a previously safe image can become vulnerable when new defects are disclosed;
• remove debugging utilities and package managers from production images where practical.

A vulnerability scanner produces evidence, not an automatic risk decision. A vulnerability may be unreachable, mitigated by configuration or exploitable only under unusual conditions. Conversely, a high-impact vulnerability may require urgent action even if a numerical severity score is moderate. Organizations should combine scanner results with exploitability, exposure, data sensitivity and compensating controls.

3. Registries and the Image Supply Chain

A registry stores image manifests and layers. Public registries provide broad availability; private registries support access control, retention policies, audit logs, geographic replication and organizational governance. A typical workflow is:

write Dockerfile → build → test → scan → tag → push → deploy by digest → monitor

An image reference commonly has the form:

registry.example.com/team/orders:1.4.2

The tag is convenient for people, but tags can be moved. A digest identifies specific content and is therefore more suitable for reproducible production deployment:

registry.example.com/team/orders@sha256:<content-digest>

A practical command sequence might be:

docker build -t registry.example.com/team/orders:1.4.2 .
docker run --rm -p 8080:8080 registry.example.com/team/orders:1.4.2
docker push registry.example.com/team/orders:1.4.2
docker pull registry.example.com/team/orders:1.4.2

The exact commands vary by container engine and registry. Authentication should use short-lived credentials or an identity-based mechanism where possible. Registry permissions should follow least privilege: a build system may push images, while a production cluster may pull images but should not be able to overwrite them.

A mature registry policy usually includes immutable release tags, vulnerability retention rules, deletion protection for deployed artifacts and an audit trail. Image promotion between development, staging and production is safer than rebuilding independently for each environment, because promotion preserves the tested artifact.

4. Orchestration Concepts

Running one container manually is useful for experimentation but insufficient for a production service. Operators must determine where containers run, restart failed processes, expose them to clients, distribute traffic, scale replicas and apply configuration consistently. An orchestrator automates these responsibilities.

A cluster normally consists of control-plane components and worker nodes. The control plane stores the desired state and coordinates decisions. Worker nodes provide compute resources and run workloads. In Kubernetes, the control plane includes an API server, a scheduler, controller managers and a cluster state store, commonly etcd. A node normally runs a container runtime, a node agent and networking components.

The central orchestration model is desired state. An operator declares that, for example, three replicas of an application should run using a specified image. Controllers continually compare actual state with desired state and take corrective action. This is a reconciliation loop, not merely a one-time command.

Figure: The orchestration control loop compares desired and actual state and applies corrective action.

Workloads, Scheduling and Resilience

A workload is a unit of application execution managed by the orchestrator. Kubernetes uses a Pod as its smallest deployable unit. A Pod may contain one or more tightly coupled containers that share network identity and, when configured, storage. Most applications use one main container per Pod, with additional sidecars only when their lifecycle and communication requirements justify them.

A Deployment manages a replicated, usually stateless application. It creates ReplicaSets, supports rolling updates and replaces failed Pods. A StatefulSet is designed for workloads requiring stable identities or persistent storage, although databases still require careful operational design. A DaemonSet places a Pod on selected nodes, commonly for logging or monitoring agents. A Job runs a finite task, while a CronJob schedules recurring Jobs.

The scheduler selects an appropriate node using resource requests, constraints, affinity rules, taints and tolerations. Resource requests influence placement; resource limits constrain consumption. If limits are too low, applications may be terminated or throttled. If requests are too high, the cluster may appear full even when physical capacity remains.

5. Kubernetes Networking and Services

Pods are replaceable and their IP addresses can change. Clients should therefore not depend directly on Pod addresses. A Kubernetes Service provides a stable virtual endpoint and selects Pods using labels. Common Service types include:

• ClusterIP: reachable within the cluster; the usual default for internal services;
• NodePort: exposes a port on each selected node, often for basic or temporary access;
• LoadBalancer: requests an external load-balancing integration from a cloud or infrastructure provider;
• ExternalName: provides a DNS alias to an external name rather than selecting Pods.

An Ingress or a newer Gateway API can route HTTP or HTTPS traffic to Services. External exposure should be deliberate, protected by authentication and authorization, and monitored for unexpected access.

A Service selects Pods through labels, for example app: orders. A selector mismatch is a common cause of an apparently healthy Deployment receiving no traffic. Readiness probes are equally important: a Pod may be running but not ready to serve requests.

6. Configuration, Secrets and Health

Configuration should be separated from the image so that the same artifact can move through environments. Kubernetes ConfigMaps hold non-confidential configuration. Secrets are intended for confidential values such as passwords and tokens, but they should not be assumed to be safe merely because the object is called a Secret. Access controls, encryption at rest, audit logging, rotation and external secret managers are still required.

Configuration should be injected through environment variables, mounted files or application-specific mechanisms. Applications should fail safely when required configuration is missing and should avoid printing credentials in logs.

Kubernetes supports three important probe types:

• Liveness probe: determines whether a container should be restarted;
• Readiness probe: determines whether the container should receive traffic;
• Startup probe: allows slow-starting applications time to initialize before liveness checking becomes active.

A liveness probe must not be so sensitive that temporary dependency failure causes a restart loop. A readiness probe should represent the application’s ability to serve requests, not merely whether its process exists. Probe endpoints should be lightweight and protected from revealing sensitive diagnostic data.

7. Scaling and Delivery Strategies

Horizontal scaling increases the number of application replicas. Kubernetes can perform this manually by changing a replica count or automatically through a Horizontal Pod Autoscaler (HPA), usually based on resource utilization or selected metrics. Autoscaling is not a substitute for capacity planning: new replicas need available CPU, memory, network, storage and downstream-service capacity.

A useful operational relationship for a replicated service is:

where C_total is the approximate total requested capacity, n is the number of replicas, and C_pod is the resource request per Pod. This is a planning approximation, not a performance law. It assumes comparable replicas and ignores system overhead, uneven load, scheduling constraints and bottlenecks outside the application.

Rolling updates replace old Pods gradually. They reduce interruption risk but can temporarily run two application versions. Applications must therefore tolerate mixed-version operation, particularly when database schemas or APIs change. Blue-green delivery maintains separate environments and switches traffic between them. Canary delivery sends a limited proportion of traffic to a new version before wider release. These strategies require observability, rollback criteria and compatible data changes.

8. A Basic Kubernetes Deployment

The following illustrative manifest deploys two replicas and exposes them internally:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 2
  selector:
    matchLabels:
      app: orders
  template:
    metadata:
      labels:
        app: orders
    spec:
      containers:
        - name: orders
          image: registry.example.com/team/orders@sha256:REPLACE_WITH_DIGEST
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector:
    app: orders
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

The Deployment’s selector must match the Pod template label. The Service’s selector must also match that label. The targetPort is the application port inside the Pod, while the Service’s port is the port exposed by the Service. In a laboratory cluster, a learner might apply and inspect the manifest with:

kubectl apply -f orders.yaml
kubectl get deployments,pods,services
kubectl describe deployment orders
kubectl logs deployment/orders

The commands and permissions should be used only in an authorized cluster. Production access should use named identities, namespaces, role-based access control and audit logging rather than shared administrator credentials.

9. Illustrative Case: Moving a Web Service to Kubernetes

Background

A fictional online retailer, Northstar Retail, operates a small order-status API on manually configured virtual machines. Releases are slow because each server has slightly different libraries. During traffic peaks, operators must log in and start additional processes manually.

Problem

The organization needs repeatable releases, basic horizontal scaling and safer recovery from process failure. The team also discovers that a development image contains source-control metadata and that the application runs as root.

Analysis

The technical problem is not solved simply by placing the existing process in a container. The team first identifies runtime dependencies, external configuration, health semantics, persistent data and network boundaries. It determines that the API is stateless, while the database will remain a separately managed service. The team defines a readiness endpoint and agrees that database credentials must be supplied through a managed secret mechanism.

Approach and Solution

The developers create a multi-stage image, add a non-root user, use a .dockerignore file and scan the image in CI. The image is tagged with the release version and promoted to a private registry. Production manifests reference the immutable image digest. A Deployment specifies two replicas, CPU and memory requests, a readiness probe and a rolling-update policy. A ClusterIP Service provides stable internal discovery. An HPA is introduced only after baseline metrics and capacity limits are understood.

The delivery pipeline builds once, runs unit and integration tests, scans the image, deploys to a temporary environment and performs a smoke test. Production deployment is approved through the organization’s change process. Logs, request latency, error rate, restart count and readiness failures are monitored.

Outcome

Releases become repeatable, and a failed Pod is recreated automatically. During a controlled load test, replicas increase within the available cluster capacity. The team also identifies a limitation: scaling the API does not automatically scale the database or eliminate slow queries. Operational ownership therefore includes both the container platform and the application’s dependencies.

Learning Points

• Packaging is only one part of delivery; configuration, observability and security must be designed together.
• Immutable image references improve reproducibility.
• Readiness controls traffic, whereas liveness controls restart decisions.
• Application scaling is constrained by downstream systems and cluster capacity.
• A successful deployment requires tested rollback and clear ownership.

10. Challenges, Governance and Contemporary Practice

Cloud-native systems introduce distributed-systems challenges. Network calls can fail, clocks differ, dependencies become unavailable and retries can amplify load. Teams should use timeouts, bounded retries, idempotent operations and circuit-breaking patterns where appropriate. They should also define service-level indicators such as availability, latency and error rate, while avoiding excessive monitoring that creates noise and unnecessary cost.

Security governance includes image provenance, access control, namespace isolation, network policies, secret rotation, admission controls and incident response. Regulatory obligations may require evidence of who deployed an image, what code and dependencies it contained, where sensitive data was processed and how access was reviewed. Kubernetes does not automatically provide compliance; it provides mechanisms that must be configured and governed.

Artificial intelligence can assist with log classification, anomaly detection, manifest suggestions and vulnerability prioritization. Such tools must not be trusted blindly. Generated manifests can expose services or grant excessive privileges, and automated vulnerability decisions can misclassify risk. Human review, testing and policy enforcement remain necessary.

Current cloud-native practice increasingly emphasizes software supply-chain security, signed artifacts, SBOMs, policy-as-code, GitOps and platform engineering. GitOps stores desired deployment configuration in version control and uses an agent to reconcile the cluster with the approved repository state. Platform engineering provides reusable paths for developers while centralizing security and operational guardrails. These approaches improve consistency but introduce their own governance needs, including repository protection, emergency-change procedures and clear separation of duties.

Best-Practice Checklist

Before deploying a containerized service, verify that:

• the image uses an approved, maintained base image;
• unnecessary packages and files are excluded;
• the process does not require root privileges;
• secrets are injected at runtime and are not present in layers or logs;
• the image has been tested, scanned and preferably signed;
• production deployment uses an immutable digest;
• resource requests and limits are evidence-based;
• readiness, liveness and startup behavior are correctly distinguished;
• the Service selector matches the intended Pods;
• external exposure, network policy and access control are intentional;
• logs, metrics, traces and alerts support diagnosis;
• rollback, backup and disaster-recovery procedures have been tested.

Chapter Summary

Containers package applications into portable, versioned runtime units, while images provide the immutable templates from which containers are created. Secure image construction requires trusted bases, small and purposeful contents, non-root execution, exclusion of secrets and continuous supply-chain verification. Registries distribute images; tags aid human use, whereas digests provide stronger reproducibility.

Orchestration manages workloads across a cluster. Kubernetes expresses desired state through objects such as Pods, Deployments, Services, ConfigMaps and Secrets. Controllers reconcile actual state with the declared state. Deployments manage replicated stateless applications, Services provide stable discovery, probes control traffic and restarts, and resource requests guide scheduling. Scaling and rollout strategies must be considered alongside capacity, observability, data compatibility and downstream dependencies.

Cloud-native delivery is therefore a socio-technical practice. Successful implementation combines container engineering, Kubernetes fundamentals, security governance, automation, monitoring, controlled change and operational learning.

Key Terms

Container: An isolated process environment that shares the host kernel through operating-system mechanisms.

Container image: An immutable package used to create containers.

Container runtime: Software that downloads, creates and executes containers.

Image layer: A usually read-only filesystem layer used to construct an image.

Registry: A service that stores and distributes container images.

Digest: A content-derived identifier for a specific image artifact.

Pod: Kubernetes’ smallest deployable unit, containing one or more related containers.

Cluster: A set of control-plane and worker resources managed as one platform.

Node: A machine that provides resources for running Kubernetes workloads.

Deployment: A Kubernetes object that manages replicated, updateable application Pods.

Service: A stable network endpoint that selects and routes traffic to Pods.

ConfigMap: Kubernetes storage for non-confidential configuration data.

Secret: Kubernetes object intended to hold confidential configuration, subject to additional protection.

Readiness probe: A health check determining whether a workload should receive traffic.

Liveness probe: A health check used to determine whether a container should be restarted.

Reconciliation: Repeated comparison of desired state with actual state followed by corrective action.

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

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

Software bill of materials: An inventory of components and dependencies contained in an artifact.

Review Questions

Short Answer Questions

1. What is the difference between a container image and a running container?
2. Why should production deployments preferably reference an image digest rather than only a tag?
3. What is the purpose of a Kubernetes Service?
4. Distinguish a readiness probe from a liveness probe.
5. State two security practices for constructing container images.

Long Answer Questions

1. Explain the main stages of a secure container-image supply chain, from Dockerfile creation to production deployment.
2. Compare containers and virtual machines in terms of isolation, portability, startup behavior and operational responsibility.
3. Describe how Kubernetes uses desired state and reconciliation to maintain workloads.
4. Explain the roles of Pods, Deployments, Services, ConfigMaps and Secrets in a basic application.
5. Discuss why horizontal scaling of an API may fail to improve performance when downstream dependencies are constrained.

Analytical / Application Questions

1. A Deployment reports two available replicas, but the Service receives no traffic. Identify the configuration checks you would perform and explain why each matters.
2. A team places a database password in a Dockerfile and deletes it in a later instruction. Explain the security risk and propose a safer design.
3. An application is repeatedly restarted during a temporary database outage. Analyze whether its liveness and readiness probes are correctly designed and recommend changes.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an image from a container?

A. An image is a running process, while a container is a registry.

B. An image is a package or template, while a container is an instance created from it.

C. An image is always a virtual machine, while a container is always bare metal.

D. An image stores only logs, while a container stores source code.

Correct Answer: B. An image is a package or template, while a container is an instance created from it.

Question 2

Which image reference provides the strongest content reproducibility for a production deployment?

A. orders:latest

B. orders:stable

C. orders:1.4

D. orders@sha256:<digest>

Correct Answer: D. orders@sha256:<digest>

Question 3

What is the primary purpose of a multi-stage container build?

A. To expose every build tool in production

B. To combine multiple registries into one image

C. To keep compilation tools out of the final runtime image

D. To ensure that containers run as root

Correct Answer: C. To keep compilation tools out of the final runtime image

Question 4

What does a Kubernetes readiness probe primarily control?

A. Whether a container image is pushed to a registry

B. Whether a Pod should receive service traffic

C. Whether a node is powered off

D. Whether a Secret is encrypted

Correct Answer: B. Whether a Pod should receive service traffic

Question 5

Which Kubernetes object provides a stable endpoint for a changing set of Pod IP addresses?

A. Service

B. ConfigMap

C. Job

D. DaemonSet

Correct Answer: A. Service

Question 6

What is the main role of a Deployment?

A. To store confidential credentials

B. To manage replicated application Pods and their updates

C. To provide a physical network cable

D. To compile application source code

Correct Answer: B. To manage replicated application Pods and their updates

Question 7

Which item is most appropriate for a non-confidential application setting such as a feature flag?

A. ConfigMap

B. Private key embedded in an image

C. Container digest

D. Node taint

Correct Answer: A. ConfigMap

Question 8

A Service has a selector app: orders, but the Pods are labelled app: order. What is the most likely result?

A. The Service may have no selected endpoints.

B. The Pods will automatically be renamed.

C. The cluster will convert the Service into a Job.

D. The image will be rebuilt with the correct label.

Correct Answer: A. The Service may have no selected endpoints.

Question 9

If a service has three identical replicas and each requests 200 MiB of memory, what is the approximate total requested memory, ignoring overhead?

A. 200 MiB

B. 400 MiB

C. 600 MiB

D. 800 MiB

Correct Answer: C. 600 MiB

Question 10

Which practice most directly reduces the risk of credentials being recovered from image layers?

A. Copy credentials into an early layer and delete them later

B. Inject credentials at runtime using a managed secret mechanism

C. Use a mutable latest tag

D. Run the application as root

Correct Answer: B. Inject credentials at runtime using a managed secret mechanism