使用K8S管理多个环境(QA、登台、生产、开发等)的良好实践是什么?
例如，假设一个团队正在开发一个产品，该产品需要部署一些api和前端应用程序。通常，这至少需要2个环境:
阶段:在发布到客户端之前进行迭代/测试和验证 生产环境:这是客户端可以访问的环境。应该包含稳定且经过良好测试的特性。
因此，假设团队正在使用Kubernetes，那么托管这些环境的良好实践是什么呢?到目前为止，我们已经考虑了两种选择:
为每个环境使用K8s集群 只使用一个K8s集群，并将它们保存在不同的名称空间中。
(1)似乎是最安全的选择，因为它最大限度地减少了潜在的人为错误和机器故障的风险，这可能会使生产环境处于危险之中。然而，这带来了更多主机的成本，以及更多基础设施管理的成本。
(2)看起来它简化了基础设施和部署管理，因为只有一个集群，但它提出了一些问题，比如:
如何确保人为错误会影响生产环境? 如何确保登台环境中的高负载不会导致生产环境中的性能损失?
可能还有一些其他的担忧，所以我正在StackOverflow上接触K8s社区，以更好地了解人们是如何应对这类挑战的。
当前回答
使用多个集群是一种规范，至少可以强制执行生产和“非生产”之间的强烈分离。
本着这种精神，请注意GitLab 13.2(2020年7月)现在包括:
Core中部署多个Kubernetes集群
使用GitLab部署多个Kubernetes集群之前需要高级许可证。 我们的社区发表了意见，我们也听取了意见:部署到多个集群甚至对个人贡献者也是有用的。 根据您的反馈，从GitLab 13.2开始，您可以在Core中部署到多个组和项目集群。
请参阅文档和版本。
其他回答
我认为有一个中间点。我正在使用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/
这取决于您想在每个场景中测试什么。一般来说，我会尽量避免在生产集群上运行测试场景，以避免不必要的副作用(性能影响等)。
如果您打算使用一个完全模仿生产系统的登台系统进行测试，我建议启动一个完整集群的精确副本，并在完成测试后将其关闭，并将部署转移到生产系统。
如果您的目的是测试一个允许测试应用程序部署的登台系统，我会永久地运行一个较小的登台集群，并根据需要更新部署(也包括部署的缩小版本)以进行持续测试。
为了控制不同的集群，我更喜欢使用独立的ci/cd机器，它不是集群的一部分，但用于启动和关闭集群，以及执行部署工作，启动测试等。这允许设置和关闭集群作为自动化测试场景的一部分。
一定要使用单独的集群进行开发和创建docker映像，这样您的登台/生产集群就可以锁定安全性。是否使用单独的集群进行分期和生产取决于您的风险/成本-当然，保持它们分开将有助于避免分期影响生产。
我还强烈推荐使用GitOps在不同的环境中推广不同版本的应用程序。
为了尽量减少人为错误，我还建议你尽可能地将CI/CD和晋升自动化。
下面是一个演示如何在Kubernetes上的多个环境中使用GitOps在环境和Pull Requests上的预览环境之间进行自动化CI/CD的演示，尽管Jenkins X支持大多数Kubernetes集群
多集群注意事项
看看Vadim Eisenberg (IBM / Istio)的这篇博客文章:清单:使用多个Kubernetes集群的优缺点，以及如何在它们之间分配工作负载。
我想强调一些优点和缺点:
使用多个集群的原因 生产/开发/测试分离:特别适用于测试Kubernetes的新版本、服务网格或其他集群软件 遵从性:根据一些规定，一些应用程序必须运行在单独的集群/单独的vpn中 更好的安全性隔离 Cloud/on-prem:在内部服务之间分配负载 使用单个集群的原因 减少设置、维护和管理开销 提高利用率 降低成本
考虑到一个不太昂贵的环境，普通的维护，但仍然确保生产应用程序的安全隔离，我建议:
1个用于DEV和登台的集群(通过名称空间分隔，甚至可能使用网络策略隔离，就像在Calico中一样) 1个集群用于PROD
环境平价
保持开发、分期和生产尽可能相似是一个很好的实践:
支持服务之间的差异意味着微小的不兼容性 突然出现，导致代码在开发中工作并通过测试或 在生产中登台失败。这些类型的错误会产生摩擦 这削弱了持续部署的动力。
将强大的CI/CD工具与头盔相结合。您可以使用helm值的灵活性来设置默认配置，只需要覆盖不同环境的配置即可。
带有AutoDevops的GitLab CI/CD与Kubernetes进行了强大的集成，允许您管理多个已经具有helm支持的Kubernetes集群。
管理多个集群(kubectl交互)
当您使用多个Kubernetes集群时，很容易 搞砸上下文，在错误的集群中运行kubectl。除了 也就是说，Kubernetes有版本不匹配的限制 客户端(kubectl)和服务器(kubernetes master)，因此运行命令 在正确的上下文中并不意味着运行正确的客户端版本。
要克服这个问题:
使用asdf管理多个kubectl版本 将KUBECONFIG env var设置为在多个KUBECONFIG文件之间进行更改 使用kube-ps1跟踪当前上下文/名称空间 使用kubectx和kubens在集群/命名空间之间快速切换 使用别名将它们组合在一起
我有一篇文章举例说明了如何实现这一点:在多个Kubernetes集群中使用不同的kubectl版本
我还推荐以下内容:
掌握KUBECONFIG文件由Ahmet Alp Balkan(谷歌工程师) Zalando如何管理140多个Kubernetes集群
使用多个集群是一种规范，至少可以强制执行生产和“非生产”之间的强烈分离。
本着这种精神，请注意GitLab 13.2(2020年7月)现在包括:
Core中部署多个Kubernetes集群
使用GitLab部署多个Kubernetes集群之前需要高级许可证。 我们的社区发表了意见，我们也听取了意见:部署到多个集群甚至对个人贡献者也是有用的。 根据您的反馈，从GitLab 13.2开始，您可以在Core中部署到多个组和项目集群。
请参阅文档和版本。
