Choosing the Perfect Path: A Deep Dive into Kubernetes Design Patterns

14 min readOct 21, 2023

If you are working with Kubernetes, you might be wondering how to choose the right design pattern for your use case, project, or product. Kubernetes design patterns are reusable solutions to common problems that arise when building and deploying applications on Kubernetes. They can help you improve the performance, reliability, scalability, and security of your applications.

Kubernetes Reusable Elements for Designing Cloud Native Applications: Advanced Patterns

Kubernetes is a powerful platform for building and deploying cloud native applications. It provides a set of features…

romanglushach.medium.com

Foundational Patterns

Basic patterns that define how to run and manage containers on Kubernetes. They are essential for any Kubernetes application.

Predictable Demands

Ensures that each pod has a clear and consistent resource requirement, such as CPU, memory, disk space, etc. This helps the scheduler to place the pods on the most suitable nodes and avoid resource contention or starvation.

You should use this pattern for any pod that has a predictable and stable workload.

have a clear understanding of the performance and scalability needs of your application
want to ensure that your application gets the resources it needs and does not affect other applications on the same cluster
want to avoid over-provisioning or under-provisioning of resources and save costs

Declarative Deployment

Allows you to specify the desired state of your application or service using a declarative language, such as YAML or JSON. Kubernetes will then try to reconcile the actual state with the desired state and apply any changes as needed.

You should use this pattern for any application or service that can be deployed and updated using a declarative approach.

want to automate the deployment and management of your application and its components
want to ensure consistency and reliability across different environments and platforms
want to leverage the built-in features of Kubernetes, such as rolling updates, rollbacks, health checks and service discovery

Health Probe

Enables you to monitor the health and readiness of your pods and containers using probes. A probe is a command or an HTTP request that checks if a pod or a container is alive and ready to serve requests. You can use liveness probes to detect and restart failed containers, and readiness probes to determine if a pod can accept traffic.

You should use this pattern for any pod or container that needs to be monitored and managed by Kubernetes.

want to improve the availability and resilience of your application
want to avoid sending requests to pods or containers that are not ready or alive
want to enable graceful shutdowns and startup delays for your application

Managed Lifecycle

It’s leverages the lifecycle hooks and events of Kubernetes to perform custom actions before or after a pod or a container is created, started, stopped, or deleted. For example, you can use pre-stop hooks to gracefully terminate connections or post-start hooks to initialize data.

You should use this pattern for any pod or container that requires some custom logic during its lifecycle.

want to run some logic or code before or after your application starts or stops
want to perform some cleanup or backup operations when your application terminates
want to integrate with external systems or services that are not managed by Kubernetes

Automated Placement

Allows you to influence the scheduling and placement of your pods on the nodes using affinity and anti-affinity rules, taints and tolerations, node selectors, and pod topology spread constraints. These mechanisms help you to optimize the performance, availability, and resilience of your application or service by distributing the pods across the cluster according to your preferences and constraints.

You should use this pattern for any pod that has specific requirements or preferences for its placement.

want to control where your pods are scheduled and how they are distributed across your cluster
want to optimize the performance, reliability and efficiency of your application
want to isolate or group your pods based on different criteria or policies

Behavioral Patterns

Defines how your containers and pods behave and interact with each other and with external systems. They can help you implement common application scenarios and functionalities.

Batch Job

Represents a finite task that runs until completion and then terminates. A batch job can be executed once or repeatedly at a fixed interval or schedule.

You can use this pattern for any task that does not require continuous availability or interaction, such as data processing, backup, migration, etc.

run a one-time or infrequent task that does not depend on the state of other components or services
scale up or down the number of pods based on the workload or resource availability
monitor the progress and status of the pods and handle failures or retries

Periodic Job

Special type of batch job that runs periodically according to a cron expression.

You can use this pattern for any task that needs to be executed regularly at a specific time or frequency, such as reporting, maintenance, cleanup, etc.

perform a recurring task that does not require user input or interaction, such as backup, cleanup, or synchronization
ensure that the task runs at a consistent time or frequency, regardless of the load or availability of the cluster
limit the concurrency or parallelism of the pods to avoid overloading the cluster or external systems

Stateless Service

Represents a service that does not store any persistent data or state on its own. A stateless service can be scaled horizontally by adding more replicas without affecting its functionality or performance.

You can use this pattern for any service that is purely computational or relies on external storage for its state, such as web servers, API servers, etc.

provide a scalable and resilient service that can handle fluctuating traffic and demand
load balance the requests across multiple pods and route them based on labels or selectors
update or roll back the pods without affecting the availability or functionality of the service

Stateful Service

Represents a service that stores some persistent data or state on its own. A stateful service requires careful management of its replicas and storage volumes to ensure data consistency and availability.

You can use this pattern for any service that needs to maintain some local state, such as databases, message queues, caches, etc.

provide a consistent and reliable service that can handle failures and recovery
maintain the order and identity of the pods and ensure that they can communicate with each other using hostnames or DNS
control the update or deletion of the pods and ensure that they follow a predefined sequence or strategy

Service Discovery

Enables your application or service to discover and communicate with other applications or services in the cluster using their names instead of their IP addresses or ports. Kubernetes provides two types of service discovery: DNS-based and environment variable-based.

You can use this pattern for any application or service that needs to interact with other applications or services in the cluster.

decouple the dependencies and interactions between the pods and services
register and deregister the pods dynamically as they join or leave the cluster
resolve the names or addresses of the services using DNS or environment variables

Self Awareness

Allows your application or service to access some metadata and information about itself and its environment using the downward API. The downward API exposes some fields of the pod spec and status as environment variables or files within the pod.

You can use this pattern for any application or service that needs to know some details about itself or its environment, such as its name, namespace, node name, labels, annotations, resource limits, etc.

customize the behavior or logic of the pods based on their labels, annotations, names, namespaces, or resources
pass configuration parameters or secrets to the pods without hardcoding them in the image or code
update or reload the configuration of the pods without restarting them

Structural Patterns

Defines how to structure your containers within a pod to achieve different goals, such as enhancing functionality, improving performance, or simplifying configuration.

Init Container

Uses a special type of container that runs before the main container in a pod and performs some initialization tasks, such as downloading dependencies, configuring settings, creating data files, etc. The init container must complete successfully before the main container can start.

You can use this pattern for any pod that requires some initialization steps before running the main application or service.

need to run some tasks that are required for the main application container to function properly, but are not part of its core logic
want to separate the initialization logic from the application logic and avoid bloating the application container image with unnecessary tools or scripts
want to run the initialization tasks in a different environment or with different privileges than the application container

Sidecar

Uses an additional container that runs alongside the main container in a pod and provides some supplementary functionality, such as logging, monitoring, proxying, syncing, etc. The sidecar container shares the same lifecycle and resources as the main container.

You can use this pattern for any pod that needs some extra functionality that is not part of the main application or service.

need to add some functionality that is not available in the main application container or that is not part of its core responsibility
want to reuse existing tools or components that can run as a separate process and communicate with the main application container through files, network, or shared memory
want to isolate the additional functionality from the main application container and make it easier to update or replace

Adapter

Uses a container that transforms or adapts the output or input of the main container in a pod to a different format or interface. The adapter container acts as a bridge or a translator between the main container and other components.

You can use this pattern for any pod that needs to communicate with other components that have different formats or interfaces than the main application or service.

need to make the main application container compatible with other components or systems that expect a different format or interface
want to avoid modifying the code of the main application container and instead use an external component that can perform the necessary transformation or adaptation
want to decouple the main application container from its consumers or dependencies and make it easier to switch or modify them

Ambassador

Uses a container that acts as a proxy or a representative of the main container in a pod and handles some external interactions, such as network requests, authentication, encryption, etc. The ambassador container abstracts away some complexity or details from the main container.

You can use this pattern for any pod that needs to interact with external systems that have different protocols or requirements than the main application or service.

need to enhance the communication or interaction of the main application container with other components or systems that have different or complex requirements
want to leverage existing tools or components that can run as a separate process and act as a proxy or intermediary for the main application container
want to abstract away the details or complexities of accessing other components or systems from the main application container and make it easier to configure or change them

Configuration Patterns

Describe how to configure your applications and services using Kubernetes resources and features, such as environment variables, configuration resources, immutable configuration, and configuration templates.

EnvVar Configuration

Uses environment variables to pass configuration values to your application or service. Environment variables are simple and universal, but they have some limitations, such as being immutable, string-only, and flat.

You can use this pattern for any application or service that can accept configuration values as environment variables.

don’t need complex configuration files or dynamic configuration changes
read environment variables natively or with minimal changes
don’t need to store sensitive data in configuration (such as passwords or tokens)

Configuration Resource

Uses a dedicated resource type called ConfigMap to store and distribute configuration values to your application or service. ConfigMaps are more flexible and expressive than environment variables, as they can store multiple key-value pairs, nested structures, and binary data.

You can use this pattern for any application or service that needs more complex or dynamic configuration values than environment variables.

need complex configuration files or dynamic configuration changes.
need to store sensitive data in configuration (such as passwords or tokens)
need to share configuration data across multiple Pods or components

Immutable Configuration

Uses an immutable image or volume to store and deliver configuration values to your application or service. Immutable configuration ensures consistency and reliability across different environments and deployments, but it also requires rebuilding or recreating the image or volume whenever the configuration changes.

You can use this pattern for any application or service that needs high confidence and stability in its configuration values.

have stable and static configuration data that does not change frequently or at all
need high reliability and reproducibility of deployments
applications that follow the 12-factor app methodology

Configuration Template

Uses a template engine or a tool to generate configuration values from a template file and some input parameters. Configuration templates allow you to reuse and customize your configuration values for different environments and scenarios, but they also introduce some complexity and dependency on the template engine or tool.

You can use this pattern for any application or service that needs to vary its configuration values based on some input parameters.

need to customize configuration files based on different environments or parameters
need to inject configuration data into legacy or third-party applications that do not support ConfigMap or Secret resources
need to transform configuration data from one format to another

Security Patterns

Describes how to secure your applications and services using Kubernetes features and best practices, such as process containment, network segmentation, secure configuration, and access control.

Process Containment

Uses containers to isolate your application or service from other processes and resources on the same node. Containers provide a sandboxed environment with limited access and privileges for your application or service.

You can use this pattern for any application or service that needs to run in a controlled and isolated environment.

want to run multiple containers on the same node without interference or conflict
want to improve the security and stability of your application
want to control the resource consumption of your application

Network Segmentation

Uses network policies to restrict the network traffic between your pods and other pods or external systems. Network policies allow you to define rules that specify which pods can communicate with which pods on which ports and protocols.

You can use this pattern for any application or service that needs to enforce network isolation and access control.

want to enforce granular network access control for your application
want to isolate different components or layers of your application
want to comply with security regulations or best practices

Secure Configuration

Uses secrets to store and distribute sensitive configuration values to your application or service. Secrets are encrypted at rest and in transit, and they can be mounted as files or injected as environment variables into your pods.

You can use this pattern for any application or service that needs to handle confidential information, such as passwords, tokens, keys, certificates, etc.

want to apply consistent and comprehensive security settings for your application
want to protect your application from common vulnerabilities or threats
want to adhere to security best practices or requirements

Access Control

Uses role-based access control (RBAC) to regulate the access and permissions of users and applications to your Kubernetes resources. RBAC allows you to define roles that grant specific operations on specific resources, and bind them to users or applications using role bindings or cluster role bindings.

You can use this pattern for any application or service that needs to authenticate and authorize users or applications.

want to manage the access rights and privileges for your application
want to implement fine-grained and dynamic access control for your application
want to support multiple users, groups, or entities with different access needs

Advanced Patterns

These are the patterns that define how to extend and customize the functionality of Kubernetes using custom resources and controllers. They can help you implement complex logic or behavior that is not supported by the built-in Kubernetes objects.

Controller

A controller is a software component that implements the control loop logic for a custom resource. A controller watches the state of a custom resource and makes changes to other resources to achieve the desired state. A controller can also react to events from other resources or external systems. A controller is useful when you need to manage complex or domain-specific resources that are not supported by the built-in Kubernetes controllers.

have a custom resource that represents a desired state or configuration for your application or system
need to orchestrate multiple resources or perform complex operations to achieve the desired state of your custom resource
want to leverage the Kubernetes API and tools for managing your custom resource and its associated resources
want to benefit from the features of Kubernetes such as scalability, reliability, security, and observability

Operator

An operator is a specialized controller that extends the Kubernetes API and encapsulates the domain knowledge and operational logic of a specific application or system. An operator can manage the entire lifecycle of an application or system, from installation and configuration to upgrade and backup. An operator can also provide custom APIs and interfaces for users and administrators. An operator is useful when you need to automate complex or domain-specific tasks that are not covered by the built-in Kubernetes controllers or tools.

have an application or system that requires domain-specific knowledge and expertise to manage
have an application or system that has complex or custom requirements for installation, configuration, upgrade, backup, or recovery
want to provide a consistent and user-friendly experience for managing your application or system across different environments and platforms
want to integrate your application or system with other Kubernetes components and services

Elastic Scale

It’s a pattern that enables an application or system to automatically adjust its resource consumption and performance based on the workload demand. Elastic scale can help optimize the resource utilization and cost efficiency of your application or system, as well as improve its availability and responsiveness. Elastic scale can be achieved by using Horizontal Pod Autoscaling (HPA) or Vertical Pod Autoscaling (VPA) in Kubernetes.

use elastic scale when you have an application or system that has variable or unpredictable workload patterns and needs to adapt to changing demand
use HPA when you have an application or system that can scale horizontally by adding or removing pods based on the CPU or memory utilization or custom metrics
use VPA when you have an application or system that can scale vertically by adjusting the CPU or memory requests and limits of each pod based on the historical usage data
use both HPA and VPA when you have an application or system that can benefit from both horizontal and vertical scaling depending on the workload characteristics and resource constraints

Image Builder

Image builder is a pattern that automates the process of building container images for your application or system. Image builder can help simplify and standardize the image creation process, as well as ensure the quality and security of your images. Image builder can be implemented by using tools such as Dockerfile, Buildpacks, Kaniko, Buildah, Skaffold, etc.

use Dockerfile when you have an application or system that can be easily packaged into a container image by using a series of commands and instructions
use Buildpacks when you have an application or system that can be automatically detected and packaged into a container image by using predefined buildpacks that provide the runtime environment and dependencies
use Kaniko when you have an application or system that can be built into a container image by using Dockerfile but without requiring a Docker daemon or privileged access
use Buildah when you have an application or system that can be built into a container image by using Dockerfile or custom scripts but with more flexibility and control over the image configuration and metadata
use Skaffold when you have an application or system that can be built into a container image by using any of the above tools but with additional features such as live reloading, continuous integration, and deployment
Use Skaffold, Jib, or Source-to-Image (S2I) to build your container images from source code without requiring a Dockerfile. Skaffold, Jib, and S2I are tools that allow you to build container images from source code using various languages, frameworks, and platforms

Conclusion

Remember that the choice of Kubernetes design pattern depends on the specific requirements, constraints, and goals of your project or product. Evaluate the characteristics of your workload, consider scalability, security, and operational aspects, and select the pattern that aligns best with your needs.