A Single Kubernetes Cluster housing Prod/Dev/Staging @ the same time has some serious issues.
- Why Staging? You don’t want to break Prod with a new deployment that goes south. Also Kubernetes Cluster upgrades/modifications could be tested on this one. It will not break Production nor will it break Development, both would mean a serious impact. Developers who can’t work… (You could even think about a separate Test Cluster for the Cluster Administrators)
- Ability to test Node changes, Cluster changes, or other Infra related changes to the cluster without bringing down Prod/Dev/Staging @ the same time.
- Kubernetes Cluster upgrades can be tested first on NON-prod cluster before applying on Prod Cluster.
- Security might be different in Development Environment for ‘Development’ Reasons. Also Developers can not impact performance on Prod Environment. And as a last point Security is not that ‘easy’ to implement. So keeping these three environments separated alread helps on a security level.
- Different Users per Environment. The less users the less breaks created by users. Prod and Staging have few Users. Development has lots. Keep them separated from a Stability POV.
- Also having A Kubernetes Cluster with worker nodes spread over 2 Datacenters asks for investigation. This would be bad practice from a performance and Resiliency (HA) point of view. Needs more investigation.