使用Kubernetes的多个环境(阶段、质量保证、生产等)

Question

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

举个例子，假设一个团队正在开发一个需要部署几个API以及前端应用程序的产品。通常，这至少需要两个环境：

• 阶段:用于迭代/测试和验证，然后发布到客户端。
• 生产:这是客户可以访问的环境。应该包含稳定和测试良好的特性。

那么，假设团队正在使用Kubernetes，那么托管这些环境的最佳实践是什么呢？到目前为止，我们已经考虑了两个选择：

1. 对每个环境使用K8s集群
2. 只使用一个K8s集群，并将它们保存在不同的命名空间中。

(1)似乎是最安全的选择，因为它最大限度地减少了可能使生产环境受到威胁的人为错误和机器故障的风险。然而，这是伴随着更多主机器的成本和更多基础设施管理的成本而来的。

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

• 如何确保人为错误可能影响生产环境？
• 如何确保阶段环境中的高负载不会导致生产环境中的性能损失？

可能还有一些其他的问题，因此我正在与K8s社区联系，以便更好地了解人们如何应对这些挑战。

Answer 1

多簇考虑

看看这篇来自Vadim (IBM /Istio)的博客文章：核对表:使用多个Kubernetes集群的利弊，以及如何在它们之间分配工作负载。

我想强调一下其中的一些利弊：

使用多集群的原因

• 生产/开发/测试的分离:特别是用于测试新版本的Kubernetes、服务网格和其他集群软件。
• 遵从性:根据某些规定，某些应用程序必须在单独的集群/单独的VPN中运行。
• 更好的隔离以确保安全
• 云/on:在前提服务之间分配负载

使用单个集群的原因

• 减少设置、维护和管理开销
• 提高利用率
• 降低成本

考虑到一个不太昂贵的环境，平均维护，但仍然确保生产应用程序的安全隔离，我建议：

• 1用于DEV和暂存的集群(由名称空间分隔，甚至使用网络策略(如在https://www.projectcalico.org/calico-network-policy-comes-to-kubernetes/中)隔离)
• 1组用于PROD

环境均等

它是一个良好做法，可以尽可能地保持开发、分期和生产的相似性：

支持服务之间的差异意味着出现了微小的不兼容，导致在开发中工作并通过测试的代码在生产中失败。这些类型的错误会产生摩擦，从而抑制持续部署。

将强大的CI/CD工具与 掌舵相结合。您可以使用舵值的灵活性来设置默认配置，只需将不同环境的信任覆盖到另一个环境。

GitLab CI/CD与AutoDevops与Kubernetes有一个强大的集成，它允许您管理已经有舵机支持的多个Kubernetes集群。

管理多个集群 (__kubectl interactions)

当您使用多个Kubernetes集群时，很容易处理上下文并在错误的集群中运行kubectl。除此之外，Kubernetes还拥有限制，用于控制客户端(kubectl)和服务器(kubernetes主版)之间的版本不匹配，因此在正确的上下文中运行命令并不意味着运行正确的客户端版本。

为了克服这一问题：

• 使用asdf管理多个kubectl版本
• KUBECONFIG env在多个kubeconfig文件之间进行更改
• 使用kube-ps1跟踪当前上下文/命名空间
• 使用kubens在集群/命名空间之间进行快速更改
• 使用别名将它们组合在一起。

我有一篇文章举例说明了如何做到这一点：使用多个Kubernetes集群的不同kubectl版本

我还建议如下：

• 掌握KUBECONFIG文件由Ahmet Alp巴尔干(谷歌工程师)
• Zalando如何管理140+ Kubernetes集群由Henning Jacobs (扎兰多科技)

Answer 2

一定要使用单独的集群进行开发和创建坞映像，这样您的分期/生产集群就可以从安全性的角度进行锁定。是否为staging + production使用单独的集群取决于您根据风险/成本来决定--当然，保持它们的分离将有助于避免staging影响production。

我还强烈建议使用GitOps在您的环境中推广应用程序的版本。

为了最大限度地减少人为错误，我还建议您考虑尽可能多地自动化您的CI/CD和升级。

以下是在GKE上进行的环境和预览环境之间升级的如何使用GitOps在Kubernetes上实现多环境下CI/CD自动化的演示，虽然Jenkins支持大多数kubernetes集群

Answer 3

这取决于您想要在每个场景中测试什么。通常，我会尽量避免在生产集群上运行测试场景，以避免不必要的副作用(性能影响等)。

如果您的目的是使用完全模拟生产系统的暂存系统进行测试，那么我建议您在完成测试并将部署转移到生产中之后，启动完整集群的确切副本，并关闭它。

如果您的目的是测试一个允许测试应用程序部署的暂存系统，我将永久运行一个较小的暂存集群，并根据持续测试的需要更新部署(也包括一个缩小的部署版本)。

为了控制不同的集群，我更希望有一个单独的ci/cd机器，它不是集群的一部分，而是用于触发和关闭集群，以及执行部署工作、启动测试等。这允许设置和关闭集群作为自动测试场景的一部分。