Introduction
High-quality cloud-native containers are essential, but not sufficient on their own. The next step is to reuse containers and combine them into pods in order to obtain the desired result. This group of patterns is concerned with how a pod's containers should be arranged in order to best serve a variety of scenarios. These configurations are a direct outcome of the forces acting on containers inside pods.
Here are the key types of structural patterns.
Init Container pattern
SideCar Patterns
Adapter Patterns
Ambassador Patterns
Init Container Pattern
With the introduction of the Init Container, we now have two distinct life cycles: one for the core application containers and one for the ones that deal with initialization. Init containers help the principle of separation of concerns by separating operations related to initialization from the main life cycle of application containers. Whenever initialization logic is needed, this style presents a core Kubernetes idea that is used by many others.
SideCar Patterns
Sidecar explains how to add to an existing container's features without altering the container itself. This is a key container design that facilitates the close collaboration of containers with distinct purposes.
Adapter Patterns
In cases where all containers running in an application pod must be exposed in a unified way, this variant of the sidecar is utilized.
To illustrate, consider a pod with three containers: two containers act as the application, while the third container, the adapter, unifies the logs from the two application containers into a single format that can be consumed by a separate tool. Even if the primary containers are built in different languages, the logs are presented in the same way across both, making them accessible to a wide range of third-party tools.
Ambassador Patterns
In this sense, we have yet another iteration of the sidecar idea. An application that is containerized and operating in a pod may at times require interaction with services that are not part of the pod itself. The Ambassador idea can be useful in several situations. This component operates as a proxy, relieving the primary application container of the burden of making direct connections to external services.
One such case is when an application has to access a cache or datastore that is located elsewhere. The request is received by the primary application container, which then passes it along to the ambassador container, which in turn sends it on to the external source.
Continuous Blog Series :
Blog #15: K8s Anti-Design Pattern Series - To Kubernetes or not to Kubernetes weighing Pros and Cons