Kubernetes Patterns

Chapter 17. Ambassador

The Ambassador pattern is a specialized Sidecar responsible for hiding complexity and providing a unified interface for accessing services outside the Pod. In this chapter, we see how the Ambassador pattern can act as a proxy and decouple the main Pod from directly accessing external dependencies.

Problem

Containerized services don’t exist in isolation and very often have to access other services that may be difficult to reach in a reliable way. The difficulty in accessing other services may be due to dynamic and changing addresses, the need for load balancing of clustered service instances, an unreliable protocol, or difficult data formats. Ideally, containers should be single-purposed and reusable in different contexts. But if we have a container that provides some business functionality and consumes an external service in a specialized way, the container will have more than one responsibility.

Consuming the external service may require a special service discovery library that we do not want to put in our container. Or we may want to swap different kinds of services by using different kinds of service discovery libraries and methods. This technique of abstracting and isolating the logic for accessing other services in the outside world is the goal of this Ambassador pattern.

Solution

To demonstrate the pattern, we will use a cache for an application. Accessing a local cache in the development environment may be a simple configuration, but in the production ...