Containers, Kubernetes and Hybrid Deployment

Introduction and Context

Modern cloud applications are rarely deployed as a single executable on one server. They are commonly composed of APIs, web interfaces, background workers, databases, message brokers, scheduled jobs and event handlers. Each component may have different scaling, reliability and security requirements. Serverless functions are effective for short-lived, event-driven work, but they are not suitable for every workload. Virtual machines provide strong isolation and operating-system control, but they require more administration. Containers occupy an important middle position: they package an application and its dependencies in a portable, reproducible unit while sharing the host operating-system kernel.

This chapter examines how containers support microservices, how Kubernetes orchestrates containerized workloads, and how service meshes improve communication management. It also develops a decision framework for choosing among functions, containers, virtual machines and hybrid deployment. The emphasis is practical: a cloud professional must not merely know what Kubernetes is, but must be able to decide when its operational complexity is justified.

Learning Objectives

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

• compare functions, containers and virtual machines in terms of isolation, startup, control, cost and operational responsibility;
• explain container images, registries, runtimes, networking and persistent storage;
• package a microservice using a reliable container build process;
• describe Kubernetes objects and the reconciliation model;
• explain deployments, services, ingress, configuration, secrets, autoscaling and resilience;
• evaluate the role and limitations of service meshes;
• select serverless, containerized or hybrid deployment for a business scenario; and
• identify security, governance, observability and cost risks in container platforms.

1. Functions, Containers and Virtual Machines

1.1 Virtual machines

A virtual machine (VM) emulates a complete computer through a hypervisor. Each VM includes a guest operating system, system libraries and applications. The hypervisor allocates virtual CPU, memory, storage and network devices to the guest. Type 1 hypervisors run directly on hardware, whereas Type 2 hypervisors run above a host operating system.

VMs offer strong isolation and extensive control. They can run different operating systems on the same physical host and are appropriate for legacy systems, specialized kernels, regulated workloads and applications requiring a full operating-system environment. Their disadvantages include larger images, longer boot times and greater patching responsibility. A cloud provider may manage the physical host, but the customer commonly remains responsible for the guest operating system and much of the application stack.

1.2 Containers

A container is an isolated process environment that shares the host kernel with other containers. Linux namespaces separate processes, networks, filesystems and users; control groups (cgroups) limit and account for CPU, memory and other resources. A container image contains application code, runtime libraries and metadata in immutable layers. The container runtime creates a running container from that image.

Containers are not miniature VMs. A container normally does not include its own kernel. Consequently, containers usually start faster and use fewer resources than VMs, but kernel vulnerabilities or unsafe privileges can have wider consequences. Container isolation is strong when correctly configured, but it should not automatically be treated as equivalent to VM isolation.

A useful distinction is between an image and a container:

• an image is a versioned, read-only package;
• a container is a running instance of an image; and
• a registry stores and distributes images.

OCI (Open Container Initiative) standards have helped establish interoperable image and runtime formats. Common runtimes include containerd and CRI-O; Docker is widely used as a development and image-building tool, although Kubernetes commonly interacts with a CRI-compatible runtime rather than directly with the Docker Engine.

1.3 Functions as a service

A function platform executes a small unit of code in response to an event, HTTP request, schedule or message. The provider manages servers, runtime provisioning and much of the scaling. Functions encourage short-lived, stateless, independently deployable operations. They are particularly valuable for image processing, notification handling, API endpoints, stream reactions and scheduled automation.

Functions have constraints. Execution duration, package size, memory, concurrency, networking and temporary storage may be limited. Startup latency can increase when a new execution environment must be initialized. Vendor-specific event models can make migration difficult. Long-running processes, specialized networking, predictable high utilization and workloads requiring detailed operating-system control may be better suited to containers or VMs.

1.4 Comparative framework

No category is universally superior. The correct choice depends on workload duration, traffic shape, state, compliance, portability, team capability and total cost.

2. Packaging Microservices in Containers

2.1 The container build process

A production image should contain only what the service needs to run. A typical build process is:

1. select a trusted minimal base image;
2. copy dependency manifests before application source where appropriate, enabling build-cache reuse;
3. install dependencies using a lock file or pinned versions;
4. compile or package the application in a separate build stage;
5. copy only the runtime artifacts into a smaller final image;
6. create a non-root user;
7. define a predictable startup command; and
8. scan, sign and store the image in a controlled registry.

A multi-stage build separates compilers and development tools from the production image. This reduces attack surface and transfer time. A .dockerignore file prevents credentials, test data and unnecessary files from entering the build context.

The image should be immutable: configuration such as database endpoints should normally be supplied at runtime rather than baked into the image. A version tag is useful for humans, but a content digest provides stronger identity because it refers to exact image content.

2.2 A conceptual Dockerfile

The following illustrative pattern uses a builder and a runtime stage:

FROM example-language:builder AS build
WORKDIR /src
COPY dependency.lock ./
RUN install-dependencies --locked
COPY . .
RUN build-production-artifact

FROM example-language:runtime
WORKDIR /app
RUN create-user appuser
COPY --from=build /src/production-artifact ./
USER appuser
EXPOSE 8080
CMD ["./service"]

The exact syntax and commands vary by language. EXPOSE documents an intended port; it does not itself publish that port. A service should write logs to standard output and error, handle termination signals, and expose health endpoints where suitable.

2.3 Image security and supply-chain integrity

Container risk begins before deployment. An image may contain vulnerable operating-system packages, malicious dependencies, embedded secrets or an untrusted base layer. Good practice includes:

• using approved base images and updating them regularly;
• scanning images and software bills of materials (SBOMs);
• pinning dependencies and verifying package signatures where supported;
• signing images and enforcing signature verification at admission;
• running as a non-root user and dropping unnecessary Linux capabilities;
• using read-only filesystems where possible; and
• separating build, test and production registry permissions.

Scanning is not a complete security strategy. A vulnerability database may contain false positives or miss newly emerging threats. Runtime controls, network policy, least privilege and monitoring remain necessary.

2.4 Statelessness and persistence

A container may be replaced at any time. Therefore, durable business state should normally reside in a managed database, object store or persistent volume rather than in the writable container layer. Temporary local storage is appropriate for caches and intermediate files, but it should not be assumed to survive rescheduling.

Stateful services can run in Kubernetes using persistent volumes and operators, but this increases operational difficulty. A managed database is often preferable when the provider can meet performance, compliance and availability requirements.

3. Kubernetes as an Orchestration System

3.1 Purpose and architecture

Kubernetes is a declarative platform for deploying and operating containerized workloads. A user describes a desired state, such as three replicas of an image exposed behind a service. Controllers continually compare actual state with desired state and take corrective action. This is the reconciliation model.

A Kubernetes cluster contains a control plane and worker nodes. The control plane commonly includes:

• the API server, which provides the principal interface;
• a durable key-value store for cluster state;
• the scheduler, which selects suitable nodes for unscheduled workloads; and
• controllers, which reconcile resources such as deployments and nodes.

Worker nodes run a container runtime, a node agent and networking components. Managed Kubernetes services reduce the burden of operating control-plane components, but the customer still owns application configuration, workload security and often node or network configuration.

3.2 Core objects

A Pod is the smallest deployable Kubernetes unit. It contains one or more tightly coupled containers sharing network identity and, where configured, storage. Most application containers run in one-container Pods; sidecars may be justified for logging, proxies or security functions.

A Deployment manages a replicated, usually stateless application and supports rolling updates. A ReplicaSet maintains a specified number of matching Pods, generally under a Deployment. A Service provides a stable virtual endpoint and selects Pods using labels. It decouples clients from changing Pod addresses.

An Ingress or newer Gateway API resource defines external HTTP routing. A ConfigMap stores non-confidential configuration, while a Secret is intended for sensitive values. However, a Secret is not automatically safe merely because it has that name: access control, encryption at rest and careful handling are required.

A StatefulSet supports stable identities and ordered behavior for selected stateful applications. A DaemonSet places a Pod on each eligible node, useful for node-level agents. A Job runs a finite task, and a CronJob schedules Jobs.

3.3 Declarative configuration and reconciliation

Kubernetes manifests specify desired state. For example, a Deployment can request replicas, an image, resource limits and a label selector. The API server validates and stores the object; controllers then create or modify lower-level resources. If a Pod fails, a controller creates a replacement. If a node becomes unavailable, the scheduler may place the workload elsewhere, subject to constraints and storage behavior.

This model improves repeatability and supports infrastructure-as-code practices. It does not eliminate complexity: an incorrect selector, incompatible policy or unavailable image can leave the desired state unattainable. Operators must therefore observe events, conditions and metrics rather than assuming that an accepted manifest means a healthy application.

3.4 Scheduling, resources and availability

A Pod may declare CPU and memory requests, which influence scheduling, and limits, which constrain runtime consumption. A request is not a guarantee of application performance; it is primarily a scheduling and accounting signal. Excessive requests waste capacity, while inadequate requests cause contention or eviction.

A cluster can improve availability through multiple replicas, anti-affinity or topology spread across zones, disruption budgets and appropriate health probes. A readiness probe determines whether a Pod should receive traffic. A liveness probe detects a process that should be restarted. A startup probe protects slow-starting applications from premature liveness failure. Probes must test meaningful conditions; a probe that merely checks whether a process exists may report health while the service cannot serve requests.

3.5 Networking and service discovery

Kubernetes gives Pods network identities, but Pod IP addresses are ephemeral. Services provide stable discovery through cluster DNS and load balancing. Common service types include internal ClusterIP, externally exposed LoadBalancer and node-oriented NodePort. Ingress or Gateway resources provide application-layer routing and TLS termination.

NetworkPolicy can restrict which Pods may communicate. Its effectiveness depends on a network plugin that enforces policy. A default-deny posture, followed by explicit permitted flows, is safer than assuming that internal traffic is trusted.

3.6 Scaling

Horizontal Pod Autoscaling (HPA) changes replica count using metrics such as CPU utilization, memory or application-specific indicators. Vertical scaling changes resource requests and limits. Cluster autoscaling adds or removes nodes. These mechanisms operate at different layers and can interact in unstable ways if poorly tuned.

For a service receiving request rate λ requests per second, with average service time S seconds per request, the approximate concurrency required under stable conditions is:

Here, C is average in-flight concurrency, λ is throughput in requests per second and S is average processing time in seconds. The units are requests/second × seconds/request = requests, which corresponds to concurrent requests. This is a form of the operational relationship often associated with Little’s Law. It assumes a reasonably stable system and measures averages; it does not by itself account for bursts, queue limits or tail latency. For example, at λ = 200 requests/s and S = 0.25 s, C ≈ 50 concurrent requests. Capacity planning still requires headroom and latency-percentile analysis.

4. Service Meshes

A service mesh provides a dedicated communication layer for service-to-service traffic. It commonly supplies mutual TLS, identity, retries, timeouts, traffic shifting, policy and telemetry. A data-plane proxy handles traffic near each workload, while a control plane distributes policy and identity information.

A mesh can make a large microservice system more consistent. For example, platform engineers can enforce encrypted service communication without requiring every development team to implement TLS libraries independently. Canary deployment can route a controlled proportion of traffic to a new version, while distributed tracing can connect requests across services.

However, a mesh adds proxies, certificates, configuration, latency, resource consumption and another failure domain. Automatic retries can amplify load, especially when requests are not idempotent. A timeout should be shorter than the caller’s overall deadline, and retry budgets should be bounded. A small system may obtain greater value from an ingress controller, application libraries and centralized observability than from a full mesh.

The distinction is important: Kubernetes orchestrates workload placement and lifecycle; a service mesh primarily manages communication among workloads. They are complementary, not interchangeable.

5. Hybrid Deployment Models

Hybrid deployment means deliberately combining execution models or environments. Examples include:

• a public API in containers with asynchronous image processing in functions;
• a containerized application connected to a managed database and object storage;
• a private Kubernetes cluster for regulated data with public cloud functions for non-sensitive events;
• VMs for a legacy application, containers for newly developed services and functions for scheduled automation; and
• two cloud environments connected through controlled networking for resilience or regulatory reasons.

Hybrid is not automatically more resilient. It introduces network dependencies, identity federation, duplicated monitoring, data-replication concerns and more complex incident response. The architecture must define system boundaries, ownership, recovery objectives and data location.

5.1 A deployment decision framework

A structured decision can use the following questions:

1. Is execution event-driven and short-lived? If yes, evaluate functions first.
2. Does the service need a custom runtime, long process, special library or predictable network behavior? If yes, evaluate containers.
3. Does it require a custom kernel, full OS control or legacy installation model? If yes, evaluate VMs.
4. Is traffic highly variable, and can the platform tolerate startup delay? Serverless options may be attractive.
5. Is utilization consistently high and predictable? A continuously running container or VM may be more economical.
6. Are there data-residency, isolation or licensing requirements? These may constrain the platform choice.
7. Does the organization have the skills to operate Kubernetes? If not, a managed container platform or serverless container service may be safer.
8. Can the service be stateless, observable and independently deployed? If not, decomposition may need to precede platform selection.

Cost comparison should include engineering labor, observability, security, network transfer, idle capacity, support and migration—not merely compute prices. A low per-invocation price can be outweighed by data-transfer charges or substantial platform engineering.

6. Applied Case: Illustrative Retail Order Platform

Background

A fictional online retailer operates a monolithic order application on VMs. Seasonal promotions create sharp traffic peaks. The application includes catalog browsing, checkout, payment integration, email notification and image resizing. Releases are infrequent because changing one component requires testing and deploying the entire application.

Problem

The retailer wants faster releases and elastic capacity but must protect payment data, maintain audit records and keep order processing reliable. The team has six developers and limited Kubernetes experience.

Analysis

Catalog reads are frequent and stateless. Image resizing is asynchronous and bursty. Payment authorization depends on an external provider and must be auditable. Order records require durable storage. Email delivery can tolerate delay. The team cannot initially justify operating a large self-managed cluster.

Approach and solution

The retailer adopts a staged hybrid design:

• catalog and order APIs are packaged as containers on a managed container platform;
• a managed relational database stores orders and payment audit records;
• object storage holds product images;
• image resizing and email notification use functions triggered by messages;
• a queue separates checkout from non-critical notifications;
• secrets are stored in a managed secrets system and injected at runtime;
• API metrics, structured logs and distributed traces are collected centrally; and
• a small managed Kubernetes cluster is introduced later for services requiring advanced routing and consistent multi-service policy.

The checkout workflow uses an idempotency key so that a retried client request does not create duplicate orders. Payment events are recorded with correlation identifiers. The queue uses a dead-letter destination for messages that repeatedly fail. Readiness probes prevent uninitialized API instances from receiving requests, while replicas are distributed across availability zones where supported.

Outcome

The retailer can scale image processing independently, deploy APIs without rebuilding the entire legacy system and preserve durable order state outside containers. The design avoids adopting Kubernetes for every component on the first day. Later, Kubernetes becomes appropriate for a growing set of services because the organization has gained operational experience and a clear need for policy, scheduling and traffic management.

Learning points

The central lesson is architectural proportionality. Functions, containers and VMs can coexist when boundaries are explicit. A queue can absorb burst traffic, but it does not remove the need for idempotency and monitoring. Managed services reduce infrastructure work but create provider dependencies that should be documented. Migration should be incremental, with measurable reliability and delivery objectives.

7. Governance, Reliability and Professional Practice

Security

Use least-privilege identities for workloads, isolate namespaces and apply network policy. Restrict who can deploy images and who can read secrets. Separate development and production credentials. Protect the Kubernetes API, audit administrative actions and encrypt sensitive data in transit and at rest. A cluster-admin role should be exceptional, not routine.

Reliability

Define service-level objectives (SLOs), such as availability and latency targets, and select indicators that reflect user experience. Test graceful shutdown, dependency failure, node loss and queue backlog. Backups must be restored in practice; a backup that has never been tested is an assumption, not evidence of recoverability.

Observability

Logs explain events, metrics reveal trends and traces connect distributed operations. Useful signals include request rate, error rate, latency percentiles, saturation, restart counts, throttling, queue age and database connection exhaustion. Observability data should avoid exposing passwords, tokens or unnecessary personal information.

Governance and compliance

Container platforms may process personal, financial or health information. Data classification should determine placement, retention and access controls. Regulatory obligations may apply to audit trails, breach response, geographic location and separation of duties. Image provenance and software inventories support vulnerability response and assurance activities.

Sustainability and cost

Overprovisioned clusters consume energy and money. Right-size requests, scale non-production environments down, remove unused images and workloads, and evaluate managed services. Cost allocation tags and namespace budgets make responsibility visible. Efficiency must not compromise resilience by removing all capacity headroom.

8. Contemporary Developments and Limitations

WebAssembly-based workloads offer a potentially smaller and more portable execution unit for selected services, although ecosystem maturity and systems integration vary. Kubernetes operators encode domain-specific operational knowledge, especially for databases and messaging systems, but a poorly designed operator can automate failure at scale. Platform engineering increasingly provides internal “golden paths” that standardize deployment, security and observability while allowing teams to retain application autonomy.

AI workloads are also influencing deployment design. Inference services may require GPUs, specialized scheduling, large model artifacts and careful cost controls. Functions can suit short inference tasks, while long-running container services may be more appropriate for loaded models. AI does not remove the need for data governance, model monitoring, access control and reproducibility.

Kubernetes remains powerful but complex. Common failure modes include excessive microservice decomposition, hidden network latency, configuration drift, unbounded retries, fragile health checks and insufficient expertise. The most professional choice may be a simpler managed service when it meets requirements.

Best-Practice Checklist

• Build small, reproducible, signed images.
• Avoid secrets in source code, images and logs.
• Run containers as non-root users with minimal privileges.
• Externalize configuration and durable state.
• Define requests, limits and meaningful probes.
• Use immutable version references and controlled rollout strategies.
• Apply least privilege, network segmentation and audit logging.
• Design retries, timeouts and idempotency together.
• Monitor user-facing indicators and platform saturation.
• Choose Kubernetes only when its benefits justify its operational cost.
• Reassess architecture as traffic, regulation and team capability change.

Chapter Summary

Containers package application code and dependencies in portable units while sharing a host kernel; virtual machines provide a complete guest operating system and stronger environmental separation; and functions delegate much of execution management to a cloud provider. Each model represents a different balance of control, portability, startup behavior, scaling and operational responsibility.

Effective containerization requires minimal and reproducible images, externalized configuration, secure supply chains and deliberate treatment of state. Kubernetes applies declarative configuration and reconciliation to schedule, expose, scale and heal containerized workloads. Pods, Deployments, Services, probes, resource requests, autoscaling and policies form its core operational vocabulary. Service meshes can standardize identity, encryption, traffic management and telemetry, but their complexity must be justified.

Hybrid deployment is a design choice rather than a compromise by default. Functions, containers, VMs and managed services can be combined when workload characteristics and governance requirements are explicit. The best architecture is proportionate to reliability needs, cost, security, team capability and business value.

Key Terms

Container: An isolated process environment that shares the host kernel.

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

Container registry: A service that stores and distributes container images.

Virtual machine: A software-defined computer containing a guest operating system.

Function as a service: Event-driven execution in which the provider manages much of the runtime infrastructure.

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

Deployment: A Kubernetes object that manages replicated, usually stateless Pods and rolling updates.

Service: A stable Kubernetes network endpoint that selects Pods.

Ingress: A resource for routing external HTTP or HTTPS traffic to services.

ConfigMap: Kubernetes storage for non-confidential configuration data.

Secret: A Kubernetes object intended for sensitive configuration, requiring additional protection.

Reconciliation: The controller process of comparing actual state with declared desired state and correcting differences.

Control plane: Kubernetes components that expose the API, store state, schedule work and run controllers.

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

Horizontal Pod Autoscaler: A controller that adjusts Pod replicas using observed metrics.

Service mesh: A communication layer providing capabilities such as mTLS, traffic policy and telemetry.

Sidecar: An auxiliary container running alongside an application container in the same Pod.

Hybrid deployment: An architecture combining multiple execution models, platforms or environments.

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

Idempotency: The property that repeating an operation produces the same intended result rather than duplicate effects.

Review Questions

5 Short Answer Questions

1. Why is a container different from a virtual machine?
2. What is the purpose of a Kubernetes Service?
3. Distinguish a readiness probe from a liveness probe.
4. Why should durable application state normally be stored outside a container’s writable layer?
5. State two benefits and two costs of a service mesh.

5 Long Answer Questions

1. Compare functions, containers and virtual machines across isolation, control, startup, scaling and operational responsibility.
2. Explain how Kubernetes control-plane components and controllers implement declarative deployment.
3. Describe a secure, reproducible process for building and releasing a production container image.
4. Explain how resource requests, limits, health probes and autoscaling contribute to Kubernetes reliability.
5. Discuss why hybrid deployment can improve flexibility while also increasing governance and operational complexity.

3 Analytical / Application Questions

1. A financial reporting service runs for several hours, requires a custom library and receives predictable daily traffic. Recommend a deployment model and justify your choice against functions and VMs.
2. A microservice receives 200 requests per second and has an average processing time of 0.25 seconds. Estimate average concurrency using C ≈ λS, state the assumptions, and explain why the result is not a complete capacity plan.
3. Design a deployment strategy for a healthcare application containing a regulated patient-record service, bursty document conversion and a legacy billing system. Specify suitable execution models, security controls, state-management choices and major trade-offs.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a container from a virtual machine?

A. A container normally shares the host kernel, while a VM includes a guest operating system.

B. A container always provides stronger isolation than a VM.

C. A VM cannot run a different operating system from its host.

D. A container must contain a complete hypervisor.

Correct Answer: A. A container normally shares the host kernel, while a VM includes a guest operating system.

Question 2

What is the primary purpose of a Kubernetes Service?

A. To compile container images

B. To provide a stable network endpoint for selected Pods

C. To store Kubernetes control-plane state

D. To replace the container runtime

Correct Answer: B. To provide a stable network endpoint for selected Pods

Question 3

Which Kubernetes probe determines whether a Pod should receive traffic?

A. Liveness probe

B. Startup probe

C. Readiness probe

D. Resource probe

Correct Answer: C. Readiness probe

Question 4

Which practice best protects container supply chains?

A. Embedding production passwords in the image

B. Using unpinned dependencies from any public registry

C. Running every container as root

D. Scanning and signing images from controlled sources

Correct Answer: D. Scanning and signing images from controlled sources

Question 5

A service processes 100 requests per second with an average processing time of 0.2 seconds. Using C ≈ λS, what is the approximate average concurrency?

A. 5

B. 20

C. 100

D. 500

Correct Answer: B. 20

Question 6

What does Kubernetes reconciliation mean?

A. Encrypting every container image

B. Comparing actual state with desired state and correcting differences

C. Converting a VM into a function

D. Manually assigning every request to a Pod

Correct Answer: B. Comparing actual state with desired state and correcting differences

Question 7

Which workload is generally a strong candidate for functions?

A. A short-lived, event-driven image conversion task

B. A legacy application requiring a custom guest kernel

C. A database requiring stable local disks and continuous operation

D. A service requiring several hours of uninterrupted execution

Correct Answer: A. A short-lived, event-driven image conversion task

Question 8

What is a significant risk of automatic retries in a service mesh?

A. They always eliminate latency.

B. They can amplify load during dependency failure.

C. They prevent all duplicate operations.

D. They remove the need for timeouts.

Correct Answer: B. They can amplify load during dependency failure.

Question 9

Why should an idempotency key be used in a payment-related workflow?

A. To make a repeated request less likely to create duplicate effects

B. To increase the size of a container image

C. To assign a Kubernetes node

D. To encrypt a database backup automatically

Correct Answer: A. To make a repeated request less likely to create duplicate effects

Question 10

Which statement about Kubernetes Secrets is most accurate?

A. Their name guarantees that their contents are inaccessible.

B. They eliminate the need for access control.

C. They are intended for sensitive values but still require careful protection.

D. They should always be committed to source control.

Correct Answer: C. They are intended for sensitive values but still require careful protection.