top of page

Container Image Configuration Anti-Pattern in Kubernetes - Blog #8

Updated: Apr 12





The images you produce ought to be universally deployable. This is a best practice that existed long before the advent of containers, and it's already codified as part of the 12-factor app. You should only have to build your container images once before sharing them between different environments. The container itself should not have any settings.


If the image you've chosen for your container has IP addresses, passwords, and service URLs are all hard coded and mentioned.Has environment-specific tags like "dev", "qa", or "production", then you're probably building container images that aren't suitable for use in all environments.


Don’t

In order to send something different to production from what was tested, you will need to rebuild your image for each environment.


Simple solutions exist for this issue. Build "generic" container files that make no assumptions about their host system. Any third-party tool, such as Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper, etc., can be used for setup.





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 #1 : Kubernetes Design Pattern Series - An Overview

Blog #2 : K8s Design Pattern Series - Fundamental Pattern

Blog #3 : K8s Design Pattern Series - Structural Pattern

Blog #4: K8s Design Pattern Series: Behavioral Patterns

Blog #5: K8s Design Pattern Series: Higher Level Patterns

Blog #6: K8s Design Pattern Series: Summary

Blog #7: K8s Anti-Design Pattern Series

Blog #8: K8s Anti-Design Pattern Series - Putting the Configuration into the Images of the Containers

Blog #9: K8s Anti-Design Pattern Series - Connecting Applications to Kubernetes Features/Services without Justification

Blog #10: K8s Anti-Design Pattern Series - Mixing Infrastructure and Application Deployment

Blog #11: K8s Anti-Design Pattern Series - Deploying without Memory and CPU Limits

Blog #12: K8s Anti-Design Pattern Series - Understanding Health Probes In Kubernetes

Blog #13: K8s Anti-Design Pattern Series - The Pitfall of ignoring Helm in Kubernetes Package Management

Blog #14: K8s Anti-Design Pattern Series - Why Deployment Metrics matter in Kubernetes

Blog #15: K8s Anti-Design Pattern Series - To Kubernetes or not to Kubernetes weighing Pros and Cons

Blog #16:K8s Anti-Design Pattern Series - Connecting Applications to Kubernetes Features/Services

Blog #17: K8s Anti-Design Pattern Series - Manual Kubectl Edit/Patch Deployments

Blog #18: K8s Anti-Design Pattern Series - Kubernetes Deployments with Latest-Tagged Containers

Blog #19: K8s Anti-Design Pattern Series - Kubectl Debugging

Blog #20: K8s Anti-Design Pattern Series - Misunderstanding Kubernetes Network Concepts

Blog #21: K8s Anti-Design Pattern Series - Dynamic Environments in Kubernetes why Fixed Staging is an Anti-Design

Blog #22: K8s Anti-Design Pattern Series - Combining Clusters of Production and Non-Production


7 views0 comments

Recent Posts

See All
bottom of page