Kubernetes支持多个环境(Staging、QA、生产等)

使用K8S管理多个环境(QA、登台、生产、开发等)的良好实践是什么?

例如，假设一个团队正在开发一个产品，该产品需要部署一些api和前端应用程序。通常，这至少需要2个环境:

阶段:在发布到客户端之前进行迭代/测试和验证生产环境:这是客户端可以访问的环境。应该包含稳定且经过良好测试的特性。

因此，假设团队正在使用Kubernetes，那么托管这些环境的良好实践是什么呢?到目前为止，我们已经考虑了两种选择:

为每个环境使用K8s集群只使用一个K8s集群，并将它们保存在不同的名称空间中。

(1)似乎是最安全的选择，因为它最大限度地减少了潜在的人为错误和机器故障的风险，这可能会使生产环境处于危险之中。然而，这带来了更多主机的成本，以及更多基础设施管理的成本。

(2)看起来它简化了基础设施和部署管理，因为只有一个集群，但它提出了一些问题，比如:

如何确保人为错误会影响生产环境? 如何确保登台环境中的高负载不会导致生产环境中的性能损失?

可能还有一些其他的担忧，所以我正在StackOverflow上接触K8s社区，以更好地了解人们是如何应对这类挑战的。

当前回答

使用多个集群是一种规范，至少可以强制执行生产和“非生产”之间的强烈分离。

本着这种精神，请注意GitLab 13.2(2020年7月)现在包括:

Core中部署多个Kubernetes集群

使用GitLab部署多个Kubernetes集群之前需要高级许可证。我们的社区发表了意见，我们也听取了意见:部署到多个集群甚至对个人贡献者也是有用的。根据您的反馈，从GitLab 13.2开始，您可以在Core中部署到多个组和项目集群。

请参阅文档和版本。

2020-07-25 23:50:45

其他回答

这里有一些想法:

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).

2022-07-26 17:52:34

除非遵从性或其他需求另有规定，否则我倾向于对所有环境使用单个集群。采用这种方法，注意事项如下:

Make sure you also group nodes per environment using labels. You can then use the nodeSelector on resources to ensure that they are running on specific nodes. This will reduce the chances of (excess) resource consumption spilling over between environments. Treat your namespaces as subnets and forbid all egress/ingress traffic by default. See https://kubernetes.io/docs/concepts/services-networking/network-policies/. Have a strategy for managing service accounts. ClusterRoleBindings imply something different if a clusters hosts more than one environment. Use scrutiny when using tools like Helm. Some charts blatantly install service accounts with cluster-wide permissions, but permissions to service accounts should be limited to the environment they are in.

2019-03-22 09:28:20

我认为运行单个集群是有意义的，因为它减少了开销和监控。但是，你必须确保网络策略和访问控制到位。

网络策略——禁止开发/qa环境工作负载与prod/staging存储交互。

访问控制——谁可以使用clusterrole、role等访问不同的环境资源。

2019-03-01 05:34:15

使用多个集群是一种规范，至少可以强制执行生产和“非生产”之间的强烈分离。

本着这种精神，请注意GitLab 13.2(2020年7月)现在包括:

Core中部署多个Kubernetes集群

请参阅文档和版本。

2020-07-25 23:50:45

一定要使用单独的集群进行开发和创建docker映像，这样您的登台/生产集群就可以锁定安全性。是否使用单独的集群进行分期和生产取决于您的风险/成本-当然，保持它们分开将有助于避免分期影响生产。

我还强烈推荐使用GitOps在不同的环境中推广不同版本的应用程序。