Top 10 must know Kubernetes design patterns

4 min readMay 27, 2020

In general, design patterns are implemented to solve and reuse common well thought out architectures. Design patterns also introduce efficiency into your application and for your developers, reducing overhead and providing you with a way to reuse containers across your applications. There are several ways to group or to enhance containers inside of Kubernetes Pods. These patterns can be categorized as single node, multi-container patterns or you can use the more advanced multi-node applications patterns.

Full Article…

http://entradasoft.com/blogs/top-10-must-know-kubernetes-design-patterns

More generally, we see Kubernetes enabling a new generation of design patterns, similar to object oriented design patterns, but this time for containerized applications. That design patterns would emerge from containerized architectures is not surprising — containers provide many of the same benefits as software objects, in terms of modularity/packaging, abstraction, and reuse. Even better, because containers generally interact with each other via HTTP and widely available data formats like JSON, the benefits can be provided in a language-independent way.

There are many important concepts in Kubernetes, but these are the most important ones to start with:

Foundational patterns

These patterns represent the principles and best practices that containerized applications must comply with in order to become good cloud-native apps.

Health Probe pattern

Health Probe dictates that every container should implement specific APIs to help the platform observe and manage the application in the healthiest way possible. To be fully automate, a cloud-native application must be highly observable by allowing its state to be inferred so that Kubernetes can detect whether the application is up and ready to serve requests.

Predictable Demands pattern

This explains why every container should declare its resource profile and stay confined to the indicated resource requirements. The foundation of successful application deployment, management, and coexistence on a shared cloud environment is dependent on identifying and declaring the application’s resource requirements and runtime dependencies.

Automated Placement patterns

explains how to influence workload distribution in a multi-node cluster. Placement is the core function of the Kubernetes scheduler for assigning new Pods to nodes satisfying container resource requests and honoring scheduling policies.

Structural patterns

The patterns in this category are focused on structuring and organizing containers in a Pod to satisfy different use cases. The forces that affect containers in Pods result in these patterns.

Init Container pattern

Init Container introduces a separate life cycle for initialization-related tasks and the main application containers. Init Containers enable separation of concerns by providing a separate life cycle for initialization-related tasks distinct from the main application containers.

Sidecar patterns

Sidecar describes how to extend and enhance the functionality of a pre-existing container without changing it.

Behavioral patterns

These patterns describe the life-cycle guarantees of the Pods ensured by the managing platform. Depending on the type of workload, a Pod might run until completion as a batch job or be scheduled to run periodically. It might run as a daemon service or singleton.

Batch Job patterns

Batch Job describes how to run an isolated, atomic unit of work until completion.

Stateful Service patterns

Stateful Service describes how to create and manage distributed stateful applications with Kubernetes. Such applications require features such as persistent identity, networking, storage, and ordinality.

Service Discovery pattern

Service Discovery explains how clients can access and discover the instances that are providing application services.

Higher-level patterns

The patterns in this category are more complex and represent higher-level application management patterns. Some of the patterns here (such as Controller) are timeless, and Kubernetes itself is built on top of them.

Controller pattern

Controller is a pattern that actively monitors and maintains a set of Kubernetes resources in a desired state.

Operator pattern

An Operator is a Controller that uses a Custom Resource Definitions to encapsulate operational knowledge for a specific application in an algorithmic and automated form.

Multi-node application patterns

In a multi-node pattern, containers are not on a single machine or node, instead these more advanced patterns coordinate communications across multiple nodes.

Leader election pattern

A pattern is to link a leader election library to your application through an election leader container. You can then deploy a set of leader-election containers, each one co-scheduled with an instance of the application that needs the leader election. A simplified HTTP API can then be used over the localhost network to perform the election when needed.

Work Queue pattern

This is another common problem in distributed computing. Like leader elections it also benefits from containerization. There are frameworks available to solve the problem but again are limited to a single language environment. Instead, a generic work queue container can be created and reused whenever this capability is required. The developer then for example will then only need to create another container that can take input data and transform it the required output. The generic work queue container in this case does the heavy lifting to coordinate the queue.

Scatter/gather pattern

In this pattern, which is common in search engines, an external client sends an initial request to a “root” or to a “parent” node. The root scatters the request out to a group of servers to perform a set of tasks in parallel and where each shard returns partial data. The root is responsible for gathering the data into a single response for the original request.