The ambassador pattern – Container Orchestration with Kubernetes

The ambassador pattern derives its name from an ambassador, an envoy representing a country overseas. You can also think of an ambassador as a proxy of a particular application. Let’s say, for example, that you have migrated one of your existing Python Flask applications to containers, and one of your containers needs to communicate with a Redis database. The database always existed in the local host. Therefore, the database connection details within your application contain localhost everywhere.

Now, there are two approaches you can take:

  • You can change the application code and use config maps and secrets (more on these later) to inject the database connection details into the environment variable.
  • You can keep using the existing code and use a second container as a TCP proxy to the Redis database. The TCP proxy will link with the config map and secrets and contain the Redis database’s connection details.

Tip

The ambassador pattern helps developers focus on the application without worrying about the configuration details. Consider using it if you want to decouple application development from config management.

The second approach solves our problem if we wish to do a like-for-like migration. We can use config maps to define the environment-specific configuration without changing the application code. The following diagram shows this approach:

Figure 5.4 – The ambassador pattern

Before we delve into the technicalities, let’s understand a config         map.

Config map

A config map contains key-value pairs that we can use for various purposes, such as defining environment-specific properties or injecting an external variable at container startup or during runtime.

The idea of the config map is to decouple the application with configuration and to externalize configuration at a Kubernetes level. It is similar to using a properties file, for example, to define the environment-specific configuration.

The following diagram explains this beautifully:

Figure 5.5 – Config maps

We will use ConfigMap to define the connection properties of the external Redis database within the ambassador container.

Related Posts

Static provisioning – Managing Advanced Kubernetes Resources-2

As the Service resource is created, we can create a StatefulSet resource that uses the created PersistentVolume and Service resources. The StatefulSet resource manifest, nginx-manual-statefulset.yaml, looks like…

Static provisioning – Managing Advanced Kubernetes Resources-1

Static provisioning is the traditional method of provisioning volumes. It requires someone (typically an administrator) to manually provision a disk and create a PersistentVolume resource using the…

StatefulSet resources – Managing Advanced Kubernetes Resources

StatefulSet resources help manage stateful applications. They are similar to Deployment resources, but unlike a Deployment resource, they also keep track of state and require Volume and…

Managing stateful applications – Managing Advanced Kubernetes Resources

Imagine you’re a librarian in a magical library. You have a bunch of enchanted books that store valuable knowledge. Each book has a unique story and is…

Horizontal Pod autoscaling – Managing Advanced Kubernetes Resources-2

Now, let’s autoscale this deployment. The Deployment resource needs at least 1 pod replica and can have a maximum of 5 pod replicas while maintaining an average…

Horizontal Pod autoscaling – Managing Advanced Kubernetes Resources-1

Imagine you’re the manager of a snack bar at a park. On a sunny day, lots of people come to enjoy the park, and they all want…

Leave a Reply

Your email address will not be published. Required fields are marked *