4 unique types of containers that will boost your Kubernetes design

The container encasing your application code is not the only kind that you can run on Kubernetes.

There are many container “patterns” you can run to suit specific needs. In this post, we will cover the support containers that you might find within a pod.

In K8s talk, these patterns are single node, multi-container patterns.

Let’s explore the 4 types of support containers you can run:

Container Type #1 – Sidecar

Superpower: Extend app’s capabilities

Useful for running support services on the same pod as the application container

Benefit/s:

  • Functionality of application is enhanced without tight coupling of code
  • Potential to automate support services for all newly spun-up containers
  • Prevent support service faults from spreading to application container

Example/s:

  • Run NGINX sidecar to serve HTTPS requests to an application that can not be modified and only accepts HTTP requests
  • Run Gitsync sidecar container to push codebase updates to PV that application container can retrieve to update itself
  • Run Jaeger agent as a sidecar in the same pod as the service you want to trace. Listens to UDP packets transmitted by service

Issue/s: benefit of sidecar container is that it is small. Make sure you keep it this way otherwise bulkiness can consume resources that should go to app container.

Sidecar pattern

Container Type #2 – Init

Superpower: Pre-game app for success

Useful for running services that will start and end before the main application container spools up

Benefit/s:

  • Run utilities or code that could make the application container less secure
  • Access secrets that the app container cannot access for security reasons
  • Delay app container startup until a series of conditions are met

Example/s: init container pulls config file from Git repo then loads stored data into persistent volume for application container to call up when it runs

Issue/s: init container do not support lifecycle, liveness probe, readiness probe or startup probe because code must run to completion[source]

Init pattern

Container Type #3 – Adapter

Superpower: Make app data consistent

Useful for helping application containers connect with outside services. This container type is used for collecting and sending data out of the pod.

Benefit/s:

  • Collects and packages data in a way that suits external services
  • Sets a standard for communication by adapting to different formats
  • Contains reusable modules (open source) so it’s easier to deploy

Example/s:

  • Prometheus (monitoring) – adapter transforms output from app container into data that conforms to the Prometheus time-series database
  • Intelligent health checks like running database queries from the application

Issue/s:

  • Minimal ability to control the application container
  • Single adapter may not suit requirements of the external service
  • Marginal increase in network latency overhead
Adapter pattern

Container Type #4 – Ambassador

Superpower: Broker to the outside world

Useful for connecting application containers with the outside world just like adapter containers, but in a different way. They receive data from outside services.

Benefit/s:

  • Allows legacy applications to make use of proxy, circuit breaking etc.
  • Add cloud connectivity to a legacy application that is hard to modify
  • Manages features independently of the application it is supporting

Example/s:

  • Sharding ambassador to pull from different shards of a database
  • Payments ambassador to connect with external services like payment provider
  • A/B testing splitting traffic to different versions of a service

Issue/s: may increase network latency, which may be unacceptable in some situations

Leave a Comment