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
- 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
- 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.
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
- 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]
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.
- 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
- 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
- Minimal ability to control the application container
- Single adapter may not suit requirements of the external service
- Marginal increase in network latency overhead
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.
- 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
- 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