使用K8S管理多个环境(QA、登台、生产、开发等)的良好实践是什么?
例如,假设一个团队正在开发一个产品,该产品需要部署一些api和前端应用程序。通常,这至少需要2个环境:
阶段:在发布到客户端之前进行迭代/测试和验证
生产环境:这是客户端可以访问的环境。应该包含稳定且经过良好测试的特性。
因此,假设团队正在使用Kubernetes,那么托管这些环境的良好实践是什么呢?到目前为止,我们已经考虑了两种选择:
为每个环境使用K8s集群
只使用一个K8s集群,并将它们保存在不同的名称空间中。
(1)似乎是最安全的选择,因为它最大限度地减少了潜在的人为错误和机器故障的风险,这可能会使生产环境处于危险之中。然而,这带来了更多主机的成本,以及更多基础设施管理的成本。
(2)看起来它简化了基础设施和部署管理,因为只有一个集群,但它提出了一些问题,比如:
如何确保人为错误会影响生产环境?
如何确保登台环境中的高负载不会导致生产环境中的性能损失?
可能还有一些其他的担忧,所以我正在StackOverflow上接触K8s社区,以更好地了解人们是如何应对这类挑战的。
这里有一些想法:
Do not trust namespaces to protect the cluster from catastrophe. Having separate production and non-prod (dev,stage,test,etc) clusters is the minimum necessary requirement. Noisy neighbors have been known to bring down entire clusters.
Separate repositories for code and k8s deployments (Helm, Kustomize, etc.) will make best practices like trunk-based development and feature-flagging easier as the teams scale.
Using Environments as a Service (EaaS) will allow each PR to be tested in its own short-lived (ephemeral) environment. Each environment is a high-fidelity copy of production (including custom infrasture like database, buckets, dns, etc.), so devs can remotely code against a trustworthy environment (NOT minikube). This can help reduce configuration drift, improve release cycles, and improve the overall dev experience. (disclaimer: I work for an EaaS company).