Introduction
We discussed why you should not store configuration inside a container and why a container should not know anything about the cluster it is running on in the previous section. We can take this a step further by requiring each container to be unaware that it is running within Kubernetes at all. Unless you are developing a cluster-managing application, you should not tamper with the Kubernetes API or other external services that are assumed to be inside the cluster. This is a common scenario when teams adopt Kubernetes and fail to isolate their application from the cluster. Some classic examples include applications such as:
Do
With this new unified image, you can easily distribute it across all of your clusters. Learning what it is and how it was made is much less of a mystery.
Second, if you need to make any setup adjustments to your cluster, you won't have to re-create the container image from scratch; instead, you can make those adjustments to the external configuration system. Even the current configuration can be updated without restarts or redeployments, depending on the programming language and framework used.
Don't miss our next blog in the K8s Anti-Design Pattern Series, where we'll be discussing the issue of connecting applications to Kubernetes features or services for no apparent reason. Be sure to check it out to learn about the potential risks of this anti-pattern and find solutions to avoid it in your Kubernetes deployments.
Continuous Blog Series :
Blog #15: K8s Anti-Design Pattern Series - To Kubernetes or not to Kubernetes weighing Pros and Cons