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 #15: K8s Anti-Design Pattern Series - To Kubernetes or not to Kubernetes weighing Pros and Cons