使用K8S管理多个环境(QA、登台、生产、开发等)的良好实践是什么?
例如，假设一个团队正在开发一个产品，该产品需要部署一些api和前端应用程序。通常，这至少需要2个环境:
阶段:在发布到客户端之前进行迭代/测试和验证 生产环境:这是客户端可以访问的环境。应该包含稳定且经过良好测试的特性。
因此，假设团队正在使用Kubernetes，那么托管这些环境的良好实践是什么呢?到目前为止，我们已经考虑了两种选择:
为每个环境使用K8s集群 只使用一个K8s集群，并将它们保存在不同的名称空间中。
(1)似乎是最安全的选择，因为它最大限度地减少了潜在的人为错误和机器故障的风险，这可能会使生产环境处于危险之中。然而，这带来了更多主机的成本，以及更多基础设施管理的成本。
(2)看起来它简化了基础设施和部署管理，因为只有一个集群，但它提出了一些问题，比如:
如何确保人为错误会影响生产环境? 如何确保登台环境中的高负载不会导致生产环境中的性能损失?
可能还有一些其他的担忧，所以我正在StackOverflow上接触K8s社区，以更好地了解人们是如何应对这类挑战的。
当前回答
这取决于您想在每个场景中测试什么。一般来说，我会尽量避免在生产集群上运行测试场景，以避免不必要的副作用(性能影响等)。
如果您打算使用一个完全模仿生产系统的登台系统进行测试，我建议启动一个完整集群的精确副本，并在完成测试后将其关闭，并将部署转移到生产系统。
如果您的目的是测试一个允许测试应用程序部署的登台系统，我会永久地运行一个较小的登台集群，并根据需要更新部署(也包括部署的缩小版本)以进行持续测试。
为了控制不同的集群，我更喜欢使用独立的ci/cd机器，它不是集群的一部分，但用于启动和关闭集群，以及执行部署工作，启动测试等。这允许设置和关闭集群作为自动化测试场景的一部分。
其他回答
我认为有一个中间点。我正在使用eks和节点组。主服务器由aws管理、扩展和维护。然后你可以创建3种类型的节点组(只是一个例子):
1 - General Purpose ->标签:environment= General - Purpose
2 -暂存->标签:环境=暂存(如有必要，会被污染)
3 - Prod ->标签:环境=生产(如有必要，有污染)
您可以在pod上使用公差和节点选择器，以便将它们放置在应该放置的位置。
这允许您为生产的节点组使用更健壮或更强大的节点，例如，用于登台、uat、qa等的SPOT实例……它有几个很大的优点:
环境在物理上是分离的(在名称空间中也是虚拟的) 您可以通过共享主节点和两个环境共享的一些带有pod的节点，以及在staging/uat/…中使用现货或更便宜的实例来降低成本。 没有集群管理开销
您必须注意角色和策略以确保其安全。您可以使用例如eks+calico来实现网络策略。
更新:
我找到了一个在使用EKS时可能有用的文档。它提供了一些关于如何安全运行多租户集群的详细信息，其中一些详细信息可能有助于将生产pod和名称空间与登台中的名称空间隔离开来。
https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/
一定要使用单独的集群进行开发和创建docker映像，这样您的登台/生产集群就可以锁定安全性。是否使用单独的集群进行分期和生产取决于您的风险/成本-当然，保持它们分开将有助于避免分期影响生产。
我还强烈推荐使用GitOps在不同的环境中推广不同版本的应用程序。
为了尽量减少人为错误，我还建议你尽可能地将CI/CD和晋升自动化。
下面是一个演示如何在Kubernetes上的多个环境中使用GitOps在环境和Pull Requests上的预览环境之间进行自动化CI/CD的演示，尽管Jenkins X支持大多数Kubernetes集群
我认为运行单个集群是有意义的，因为它减少了开销和监控。但是，你必须确保网络策略和访问控制到位。
网络策略——禁止开发/qa环境工作负载与prod/staging存储交互。
访问控制——谁可以使用clusterrole、role等访问不同的环境资源。
除非遵从性或其他需求另有规定，否则我倾向于对所有环境使用单个集群。采用这种方法，注意事项如下:
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.
这里有一些想法:
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).
