使用Kubernetes的多种环境（分期，质量检查，生产等）

使用K8S来管理多个环境（QA，登台，生产，开发等）的良好做法是什么？

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

• 登台：在发布/发布之前，用于迭代/测试和验证
• 生产：客户可以访问的环境。应包含稳定且经过测试的功能。

那么，假设团队正在使用Kubernetes，那么托管这些环境的良好做法是什么？到目前为止，我们考虑了两种选择：

1. 在每个环境中使用K8s集群
2. 仅使用一个K8s集群，并将其保留在不同的名称空间中。

（1）似乎是最安全的选择，因为它最大程度地降低了可能导致人为错误和机器故障的风险，而这种风险可能会使生产环境面临危险。但是，这伴随着更多主机的成本以及更多基础架构管理的成本。

（2）看起来它简化了基础架构和部署管理，因为只有一个集群，但是它提出了一些问题，例如：

• 如何确保人为错误会影响生产环境？
• 如何确保过渡环境中的高负载不会在生产环境中造成性能损失？

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

多个集群注意事项

看看Vadim Eisenberg（IBM / Istio）的这篇博客文章：清单：使用多个Kubernetes集群的优缺点，以及如何在它们之间分配工作负载。

我想强调一些优点/缺点：

具有多个集群的原因

• 生产/开发/测试分离：特别是用于测试Kubernetes，服务网格和其他集群软件的新版本
• 合规性：根据某些法规，某些应用程序必须在单独的群集/单独的VPN中运行
• 更好的安全隔离
• 云/本地：在本地服务之间分配负载

拥有单个集群的原因

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

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

• 1个用于DEV和STAGING的集群（使用名称为Calico的网络策略，由名称空间分隔，甚至可以隔离）
• 1个PROD集群

环境平价

保持开发，暂存和生产尽可能相似是一个好习惯：

支持服务之间的差异意味着极小的不兼容性会出现，从而导致在开发过程中成功运行并通过测试的代码或在生产中暂存的代码失败。这些类型的错误会产生摩擦，阻碍持续部署。

将功能强大的CI / CD工具与helm结合使用。您可以使用helm值的灵活性来设置默认配置，而只是覆盖因环境而异的配置。

具有AutoDevops的GitLab CI / CD与Kubernetes进行了强大的集成，这使您可以管理已经支持头盔的多个Kubernetes集群。

管理多个集群 （kubectl交互）

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

为了克服这个问题：

• 使用asdf管理多个kubectl版本
• 设置环境KUBECONFIG变量以在多个kubeconfig文件之间切换
• 用于kube-ps1跟踪您当前的上下文/名称空间
• 使用kubectx和kubens在群集/命名空间之间快速更改
• 使用别名将它们组合在一起

我有一篇文章举例说明了如何实现此目的：对多个Kubernetes集群使用不同的Kubectl版本

我还建议以下内容：

• 掌握 Ahmet Alp Balkan（Google工程师）的KUBECONFIG文件
• Zalando如何管理140多个Kubernetes集群作者：Henning Jacobs（Zalando Tech）

绝对使用单独的群集进行开发和创建docker映像，以便您的登台/生产群集可以安全地锁定。是否要使用单独的群集staging + production取决于您的风险/成本-确定将它们分开将有助于避免staging影响production。

我也强烈建议使用GitOps在您的环境之间升级应用程序的版本。

为了最大程度地减少人为错误，我还建议您针对CI / CD和升级尽可能地进行自动化。

这是一个演示示例，演示了如何使用GitOps在Kubernetes上的多个环境中自动化CI / CD，以在环境之间进行升级以及在Pull Requests上预览环境，尽管Jenkins X支持大多数kubernetes集群，该演示仍在GKE上进行

这取决于您要在每种情况下测试的内容。通常，我会尽量避免在生产集群上运行测试方案，以避免不必要的副作用（性能影响等）。

如果您打算使用与生产系统完全相似的登台系统进行测试，我建议您启动完整集群的精确副本，并在完成测试并将部署移至生产后将其关闭。

如果您的目的是测试允许测试应用程序的登台系统部署我将永久运行一个较小的登台群集，并根据连续测试的要求更新部署（以及缩小版本的部署）。

为了控制不同的群集，我更喜欢使用单独的ci / cd机，该计算机不属于群集，但用于启动和关闭群集以及执行部署工作，启动测试等。这允许设置和关闭集群作为自动化测试方案的一部分。

显然，通过使生产集群远离阶段，可以减少潜在错误影响生产服务的风险。但是，这需要更多的基础架构/配置管理，因为它至少需要：

• 至少3个用于生产集群的主机，至少1个用于暂存主机
• 将2个Kubectl配置文件添加到CI / CD系统

我们也不要忘记，可能存在多个环境。例如，我曾在至少有3种环境的公司工作：

• 质量检查：这是我们每天进行部署的地方，也是我们发布给客户端之前进行内部质量检查的地方）
• 客户端质量检查：我们在部署到生产之前进行了部署，以便客户端可以在发布到生产之前验证环境）
• 生产：部署生产服务的位置。

我认为临时/按需群集是有意义的，但仅适用于某些用例（负载/性能测试或非常“大”的集成/端到端测试），但对于更持久的/粘性环境，我认为开销可能会减少通过在单个群集中运行它们。

我想我想联系k8s社区，以了解针对这些场景（例如我所描述的场景）使用的模式。

除非合规性或其他要求另有规定，否则我倾向于在所有环境中使用单个群集。通过这种方法，注意点是：

• 确保您还在每个环境中使用标签对节点进行分组。然后，您可以使用nodeSelectoron资源来确保它们在特定节点上运行。这将减少环境之间（过多）资源消耗溢出的机会。

• 默认情况下，将您的名称空间视为子网，并禁止所有出口/入口流量。参见https://kubernetes.io/docs/concepts/services-networking/network-policies/。

• 制定管理服务帐户的策略。ClusterRoleBindings如果群集承载多个环境，则意味着不同。

• 使用Helm之类的工具时，请仔细检查。一些图表公然安装了具有群集范围权限的服务帐户，但是对服务帐户的权限应限于它们所在的环境。

通常，使用多个群集是强制在生产和“非生产”之间进行严格区分的标准。

本着这种精神，请注意，GitLab 13.2（2020年7月）现在包括：

Core中的多个Kubernetes集群部署

使用GitLab与GitLab一起部署多个Kubernetes集群之前需要高级许可证。
我们的社区在发言，我们在倾听：部署到多个集群甚至对于单个贡献者也是有用的。
根据您的反馈，从GitLab 13.2开始，您可以部署到Core中的多个组和项目集群。

查看文档和问题 /

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

网络策略-禁止dev / qa环境工作负载与产品/临时存储进行交互。

访问控制-可以使用ClusterRoles，Role等访问不同环境资源的人。