Kubernetes Patterns - Foundations

Introduction: The Path to Cloud Native

The journey to cloud-native architecture builds on several evolutionary steps in software architecture and operations. Kubernetes emerged as the platform that operationalizes these concepts at scale.

Architectural Foundations

Microservices - Moving from monoliths to independently deployable services that own specific business capabilities. Each service maps to one or more Pods.

Domain-Driven Design - Organizing code around business domains provides the conceptual framework for identifying microservice boundaries and designing clean interfaces.

Hexagonal Architecture - Separating business logic from infrastructure concerns enables portability and testability, critical for cloud environments where applications must run across diverse platforms.

Twelve-Factor Methodology - Concrete principles for building cloud-native apps, including configuration management, dependency declaration, and stateless processes.

Containers - The universal packaging standard for cloud-native applications.

Distributed Primitives

Kubernetes provides distributed primitives that abstract infrastructure complexity:

Containers - The foundational building blocks for cloud-native applications. Pods - The atomic unit of scheduling, grouping one or more containers with shared networking and storage.

Services - Stable network endpoints that provide service discovery and load balancing for ephemeral Pods.

Labels - Flexible, multi-dimensional organization and selection of resources.

Annotations - Non-searchable metadata for machine consumption and tooling.

Namespaces - Logical resource pools that enable multi-tenancy, authorization, and resource governance.

Predictable Demands: Resource Management

Runtime Dependencies

Runtime dependencies are the resources Pods need to function. Kubernetes makes these explicit rather than environmental:

File Storage - PersistentVolumeClaims provide durable storage that survives Pod restarts.

Networking - Rather than hostPort (which creates node coupling), applications declare container ports and expose them through Services.

Configuration - ConfigMaps and Secrets externalize configuration, following twelve-factor principles of environment-based config.

Resource Profiles

Resource profiles define computational requirements through requests and limits:

Compressible Resources - CPU can be throttled without killing processes. Exceeding limits causes slower execution.

Incompressible Resources - Memory cannot be compressed. Exceeding limits causes Pod termination (OOMKilled).

Requests - Minimum guaranteed resources, used by scheduler for placement decisions.

Limits - Maximum allowed resources, enforced by kubelet via cgroups.

The relationship between requests and limits determines Quality of Service classes.

Quality of Service Classes

QoS classes determine Pod priority during resource pressure. Classes are automatically assigned based on resource specifications:

Guaranteed - requests = limits for all resources. Highest priority, last to be evicted.

Burstable - requests < limits. Medium priority, can use extra capacity when available.

BestEffort - No requests or limits specified. Lowest priority, first to be evicted.

QoS class determines eviction order when nodes run out of incompressible resources like memory.

Pod Priority and Preemption

While QoS is automatic, Pod Priority is explicitly assigned via PriorityClass:

PriorityClass - Cluster-wide resources defining priority values.

Preemption - When high-priority Pods can’t schedule, Kubernetes may evict lower-priority Pods to make room.

Orthogonality with QoS - Priority controls scheduling and preemption; QoS controls eviction during resource pressure. They work together but serve different purposes.

Project Resources

Namespace-level resource governance enables multi-tenancy and prevents resource exhaustion:

ResourceQuota - Aggregated resource limits per Namespace. Controls total CPU, memory, storage, and object counts.

LimitRange - Container-level constraints and defaults. Ensures individual containers are appropriately sized and provides defaults when resources aren’t specified.

Together, ResourceQuota and LimitRange provide both aggregate governance and individual container sanity checks.

Capacity Planning

Accurate resource profiles enable effective capacity planning:

Right-sizing - Profile containers accurately based on actual resource usage to avoid over-provisioning or starvation.

Vertical Pod Autoscaler (VPA) - Analyzes usage patterns and recommends request/limit adjustments, helping tune profiles based on real behavior.

Cluster capacity - Sum resource requests across all Pods to understand cluster utilization and identify scaling needs.

Namespace quotas - Aggregate ResourceQuotas help distribute cluster capacity fairly across teams.

How It All Fits Together

These concepts form a cohesive system:

1. Applications are packaged as containers with explicit runtime dependencies

2. Containers are grouped into Pods with defined resource profiles

3. Pods are organized via Labels, discovered through Services, and isolated in Namespaces

4. Resource profiles determine QoS classes and work with priority to control scheduling and eviction

5. Namespace governance through ResourceQuota and LimitRange ensures fair resource distribution

6. Cloud-native architecture and twelve-factor methodology provide the application-level patterns that complement Kubernetes infrastructure primitives

Navigation

Core Concepts

• Cloud Native Architecture - The architectural journey
• Distributed Primitives - Kubernetes abstractions
• Twelve-Factor App - Application methodology

Primitives

• Containers - Building blocks
• Pods - Scheduling units
• Services - Network endpoints
• Labels - Organization
• Annotations - Metadata
• Namespaces - Logical boundaries

Resource Management

• Resource Profiles - Requests and limits
• QoS Classes - Quality of service
• Pod Priority - Explicit priority and preemption
• ResourceQuota - Namespace limits
• LimitRange - Container defaults

Dependencies

• Runtime Dependencies - What Pods need
• Persistent Volumes - Durable storage

Managed Lifecycle: Reacting to Platform Events

Core Pattern

Managed Lifecycle reverses the communication flow from Health Probes. Instead of Kubernetes extracting information via probes, the platform sends commands and applications must respond appropriately. This enables:

Platform Control - Kubernetes decides when to start, stop, and restart containers based on policies. Applications cede control and react to platform events.

Graceful Operations - Automated deployments, scaling, and recovery depend on applications handling lifecycle events correctly.

Cloud Native Citizenship - Proper lifecycle management is essential for cloud-native applications following twelve-factor disposability principles.

Termination Signals

When Kubernetes terminates Pods, a precise signal sequence occurs:

SIGTERM - Graceful shutdown signal sent after PreStop hook. Applications should:

• Complete in-flight requests
• Stop accepting new work
• Release resources cleanly
• Exit within the grace period (default 30 seconds)

SIGKILL - Forceful termination if the process hasn’t exited after grace period. This signal cannot be caught or handled - immediate termination with no cleanup opportunity.

Proper SIGTERM handling is critical for zero-downtime rolling deployments.

Lifecycle Hooks

Kubernetes provides hooks for fine-grained lifecycle control:

PostStart Hook - Executes immediately after container creation:

• Asynchronous trigger with container start
• Blocking call - container stays Waiting until complete
• Useful for startup coordination, but has race conditions with main process
• At-least-once semantics (may execute multiple times)

PreStop Hook - Executes before SIGTERM:

• Blocking call before termination begins
• For graceful shutdown preparation
• Execution time counts against grace period
• Useful for applications that can’t handle signals directly

Both hooks support exec (run command) and httpGet (HTTP request) handlers, similar to health probe mechanisms.

Advanced Lifecycle Controls

For sophisticated lifecycle management beyond basic hooks:

Init Containers - Pod-level initialization before application containers:

• Run sequentially in defined order
• Each must complete successfully before next starts
• Stronger timing guarantees than PostStart hooks
• Useful for dependency waiting, configuration setup, database migrations
• Share volumes with application containers

Commandlet Pattern - Replace container entrypoint with lifecycle wrapper:

• Generic wrapper handles startup/shutdown logic
• Intercepts and processes signals before forwarding to application
• Often injected via Init Containers
• Provides fine-grained control without modifying application code
• Reusable across different applications

Integration with Deployments

Lifecycle management directly impacts deployment strategies:

Rolling Deployment - Requires proper SIGTERM handling to avoid dropped requests during Pod replacement. The minReadySeconds parameter works with health probes and hooks to prevent premature progression.

Blue-Green and Canary** - Benefit from quick startup and graceful shutdown to enable rapid environment switches and safe traffic shifting.

Best Practices

Signal Handling - Always implement SIGTERM handlers in application code. Don’t rely solely on PreStop hooks.

Grace Period Configuration - Set terminationGracePeriodSeconds based on actual shutdown needs. Default 30 seconds suits most applications.

Hook Selection - Use Init Containers for critical initialization requiring ordering. Use hooks for lightweight, container-specific tasks.

Process Management - Ensure PID 1 receives signals correctly. Use exec in shell scripts or consider Commandlet pattern for proper signal propagation.

Navigation Update

Managed Lifecycle

• Managed Lifecycle - Foundational pattern
• SIGTERM - Graceful shutdown signal
• SIGKILL - Forceful termination
• PostStart Hook - Container startup
• PreStop Hook - Container shutdown
• Init Containers - Pod initialization
• Commandlet Pattern - Entrypoint wrapper

Dependencies

• Runtime Dependencies - What Pods need
• Persistent Volumes - Durable storage

Automated Placement: Intelligent Pod Scheduling

The Scheduling Challenge

As cloud-native systems scale, manually assigning Pods to nodes becomes impractical. The Kubernetes scheduler automates this by matching resource requests with available node capacity while honoring placement policies.

Effective placement impacts availability, performance, and capacity utilization. Poor placement creates single points of failure, increases latency, and wastes resources through inefficient packing.

Scheduling Prerequisites

The scheduler requires several prerequisites for effective placement:

Available Node Resources - Nodes must have allocatable capacity after accounting for Kube-Reserved (Kubernetes daemons), System-Reserved (OS daemons), and Eviction Thresholds (OOM prevention buffers).

Container Resource Demands - Pods must declare resource requirements through requests and limits. These runtime dependencies enable informed scheduling decisions.

Scheduler Configuration - The scheduler uses filtering (predicates) to find feasible nodes and scoring (priorities) to rank them. Scheduling profiles and plugins customize this behavior.

Placement Mechanisms

Several mechanisms allow influencing scheduler decisions:

Node Selector - The simplest approach, specifying labels that must exist on target nodes.

Node Affinity - More expressive than selectors, supporting operators like In, NotIn, Exists, and Gt. Rules can be required (hard constraints) or preferred (soft constraints that increase node scoring).

Pod Affinity and Anti-Affinity - Base placement on other Pods already running on nodes. Affinity enables colocation for low-latency interactions. Anti-affinity enables spreading across failure domains for high availability.

Topology Spread Constraints - Ensure even Pod distribution across topology domains (zones, nodes, racks) for better utilization and availability.

Taints and Tolerations - Reverse the control flow - nodes specify taints that repel Pods unless they have matching tolerations. Integrates with Pod priority and QoS classes.

Descheduler - Optional component that improves cluster utilization by evicting and rescheduling poorly placed Pods based on QoS and priority.

Best Practices

Start with resource profiles - Accurate resource declarations enable resource-consumption-driven scheduling, the foundation of effective placement.

Label strategically - Apply labels to nodes and Pods describing their properties to enable flexible selection.

Use constraints sparingly - Let the scheduler work automatically. Add affinity, anti-affinity, and taints only for specific requirements like data locality or high availability.

Test scheduling policies - Verify Pods can schedule under various failure scenarios. Overly restrictive policies may prevent scheduling during node failures or maintenance.

Navigation Update

Automated Placement

• Automated Placement - Foundational pattern for intelligent scheduling