Sidecars derive their names from motorcycle sidecars. The sidecar does not change the bike’s core functionality and can work perfectly without it. Instead, it adds an extra seat, a functionality that helps you give an additional person a ride. Similarly, sidecars in a pod are helper containers that provide functionalities unrelated to the main container’s core functionality and enhance it instead. Examples include logging and monitoring containers. Keeping a separate container for logging will help decouple the logging responsibilities from your main container, which will help you monitor your application even when the main container goes down for some reason.

It also helps if there is some issue with the logging code, and instead of the entire application going down, only the logging container is impacted. You can also use sidecars to keep helper or related containers together with the main container since we know containers within the pod share the same machine.

Tip

Only use multi-container pods if two containers are functionally related and work as a unit.

You can also use sidecars to segregate your application with secrets. For example, if you are running a web application that needs access to specific passwords to operate, it would be best to mount the secrets to a sidecar and let the sidecar provide the passwords to the web application via a link. This is because if someone gains access to your application container’s filesystem, they cannot get hold of your passwords as another container is responsible for sourcing it, as shown in the following diagram:

Figure 5.6 – The sidecar pattern

Let’s implement the preceding pattern to understand a sidecar better. We have a Flask application that interacts with a Redis sidecar. We will pre-populate the Redis sidecar with a secret foobar, and we will do that by using the Kubernetes secret resource.

Secrets

Secrets are very similar to config maps, with the difference that the secret values are base64-encoded instead of plaintext. While base64 encoding does not make any difference, and it is as bad as plaintext from a security standpoint, you should use secrets for sensitive information such as passwords. That is because the Kubernetes community will develop a solution to tighten the security around secrets in future releases. If you use secrets, you will directly benefit from it.

Tip

As a rule of thumb, always use secrets for confidential data, such as API keys and passwords, and config maps for non-sensitive configuration data.

To access the files for this section, go to the following directory:

$ cd ~/modern-devops/ch5/multi-container-pod/sidecar

Now, let’s move on to the example Flask application.