Container Design Patterns for Kubernetes Pods Design

Here is a list of container design patterns which can be used to create useful grouping of containers (atomic unit) such as Kubernetes pods:

• Sidecar pattern
• Ambassador pattern
• Adapter pattern

These patterns advocates usage of additional containers to complement the primary / main container and have these containers form an atomic unit. The usage of additional containers as recommended by design patterns are based on some of the following design guidelines:

• Separation of concerns
• Containers’ reusability (Cohesive containers); Recall Uncle Bob’s (Robert Martin) single responsibility principle (SOLID) when working with object-oriented programming

These patterns results in creation of atomic unit of containers with a set of containers acting as core containers and others as the ones complementing the core containers. These atomic units are called different in different container orchestration tools such as following:

• Kubernetes Pods
• Nomads task group
• AWS ECS task definition
• Mesos Pod

Sidecar Pattern (Sidecar Container)

Sidecar design pattern is a form of single-node, multiple containers application patterns. Sidecar pattern advocates the usage of additional container for extending or enhancing the main container. This container can be called as a sidecar pattern.

The following are some of the related examples:

• A web-server container can be deployed with an another (sidecar) container that reads the web server logs generated by web-server container from file system and sends the log/stream the logs to the remote server. The sidecar container complements the webserver container by processing its logs. One can argue that why not the web server process its own logs? The answer lies in some of the following:
  • Separation of concerns: Let each container take care of their core concern. Web server container would be serving web pages while sidecar container would be processing server logs. This would be helpful during issues resolution stages when issues related to one concern should not conflict with other concern.
  • Single responsibility principle: A container has primarily got one reason for change. In other words, each container do one thing well. Based on this principle, one can have separate teams work on different containers as their concerns are segregated well enough.
  • Cohesiveness/Reusability: With sidecar containers for processing logs, this container can as well be reused at other places in the application.

  Following diagram represents the same:

  Figure 1. Sidecar container (logging)  {image credit: design patterns}

   

• Another example could be to use have web server deployed with a sidecar container that synchronizes file system with git repository; Notice the reusability of git synchronizer container. Application container is simply connecting to a Redis server on localhost. Following diagram represents the same:

  Figure 2. Sidecar container (git synchronizer) {image credit: Kubernetes}

   

Ambassador/Proxy Pattern (Ambassador Container)

Ambassador pattern is another form of single-node, multiple containers application patterns. This pattern advocates usage of additional containers as proxies to the external group/cluster of servers. The primary goal is to simplify the access of external servers using the ambassador container. This container can be grouped as a logical atomic unit such that the application container can invoke this ambassador/proxy container which can, then, invoke the cluster of servers. The following is primary advantage of using ambassador container:

• Let ambassador container takes care of connecting to cluster of servers; Application container connects the ambassador container using “localhost” paradigm.
• Above enables using standalone server (and not cluster of servers) in the development environment. Application container opens the connection to the server on “localhost” and find the proxy without any service discovery.

The following are some of the examples:

• Ambassador container acting as a proxy to Memcached servers; Following diagram represents the same:

  Figure 3. Ambassador (memcached) container

• Ambassador container acting as a proxy to redis cluster of servers; Ambassador container becomes responsible for splitting reads and writes and sending them on to the appropriate servers.Following diagram represents the same:

  Figure 4. Ambassador (redis) container {image credit: Kubernetes}

Adapter Pattern (Adaptor Container)

Adapter pattern is yet another form of single-node, multiple containers application patterns. It advocates usage of additional containers to present a simplified, homogenized view of an application running within a container. These containers can be called as adapter container. The main container communicates with the adapter container through localhost or a shared local volume. This is unlike ambassador container which simply the access to external servers.

A concrete example of the adapter pattern is adapters that ensure all containers in a system have the same monitoring interface. The following diagram represents usage of adapter container for monitoring:

Container Patterns for Kubernetes Pods

Applying above container design patterns, Kuberentes pods can comprise of following containers in addition to main / application container.

• One or more containers running within a pod for enhancing the main container functionality (logger container, git synchronizer container); These are sidecar container
• One or more containers running within a pod for accessing external applications/servers (Redis cluster, memcache cluster); These are called ambassador container
• One or more containers running within a pod to allow access to application running within the container (Monitoring container); These are called as adapter containers