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 #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 #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 #22: K8s Anti-Design Pattern Series - Combining Clusters of Production and Non-Production