Three container patterns (init, sidecar, ambassador)

I wanted to share these three articles and examples I created that show you how to use these three patterns. If you haven't, you will probably run into these at some point when working with Kubernetes.

### Init Container Pattern

Init containers allow you to separate your application from the initialization logic and provide a way to run the initialization tasks such as setting up permissions, database schemas, or seeding data for the main application, etc. The init containers may also include any tools or binaries that you don't want to have in your primary container image due to security reasons.

### Sidecar Container Pattern

The sidecar container aims to add or augment an existing container's functionality without changing the container. In comparison to the init container from the previous article, the sidecar container starts and runs simultaneously as your application container. The sidecar is just a second container you have in your container list, and the startup order is not guaranteed.

### Ambassador Container Pattern

The ambassador container pattern aims to hide the primary container's complexity and provide a unified interface through which the primary container can access services outside of the Pod.

Are there any other container patterns you ran into when working with Kubernetes?

Links to articles:

- [Kubernetes Init Containers](
- [Sidecar Container Pattern](
- [Ambassador Container Pattern](

2 thoughts on “Three container patterns (init, sidecar, ambassador)”

Leave a Comment