使用Kubernetes的多个环境(分段,QA,生产等)

Question

K8S用于管理多种环境(QA,分期,生产,开发等)被认为是一种很好的做法？

例如,假设一个团队正在开发一个需要部署一些API的产品,以及一个前端应用程序.通常,这将需要至少2个环境:

• 暂存:在发布到客户端之前进行迭代/测试和验证
• 生产:这是客户可以访问的环境.应包含稳定且经过良好测试的功能.

因此,假设团队正在使用Kubernetes,那么托管这些环境的好习惯是什么？到目前为止,我们考虑了两个选择:

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

(1)似乎是最安全的选择,因为它可以最大限度地降低潜在的人为错误和机器故障的风险,从而使生产环境处于危险之中.但是,这需要更多主机的成本以及更多基础架构管理的成本.

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

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

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

Answer 1

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

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

为了最大限度地减少人为错误,我还建议您尽可能多地考虑自动化CI/CD和促销.

下面是一个演示如何使用GitOps在Kubernetes上使用GitOps自动化CI/CD以在环境和Pull请求上的预览环境之间进行升级,这是在GKE上实现的,尽管Jenkins X支持大多数kubernetes集群

Answer 2

这取决于您希望在每个场景中测试的内容.一般情况下,我会尽量避免在生产群集上运行测试场景,以避免任何不必要的副作用(例如性能影响).

如果您的重点是一个完全模仿生产系统的临时系统,我建议您在完成测试并将部署移至生产后,启动完整集群的精确副本并将其关闭.

如果您的目的是允许测试应用程序部署的分段系统,那么我将永久运行较小的分段集群,并根据连续测试的需要更新部署(还有部署的缩小版本).

为此,我更喜欢使用一个单独的部署机器,它不是集群的一部分,但用于启动和关闭集群以及执行部署工作.这样即使作为自动化测试场景的一部分,也可以设置群集.

Answer 3

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

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

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

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

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

Answer 4

多个集群注意事项

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

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

具有多个集群的原因

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

拥有单个集群的原因

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

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

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

环境平价

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

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

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

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

管理多个集群 （kubectl交互）

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

为了克服这个问题：

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

看一下本文，它说明了如何实现此目的：将不同的kubectl版本与多个Kubernetes集群一起使用

我也建议您阅读以下内容：掌握KUBECONFIG文件

Answer 5

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

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

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

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

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

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

Answer 6

我认为有一个中间点。我正在与 eks 和节点组合作。主服务器由 aws 管理、扩展和维护。然后您可以创建 3 种节点组（仅作为示例）：

1 - 通用 -> 标签：环境=通用

2 - 暂存 -> 标签：环境=暂存（如有必要，则进行污点）

3 - 产品 -> 标签：环境=生产（如有必要，则污染）

您可以在 Pod 上使用容差和节点选择器，以便将它们放置在应该放置的位置。

这允许您为生产节点组使用更强大或更强大的节点，例如，用于登台、uat、qa 等的 SPOT 实例......并且有几个很大的优点：

• 环境在物理上是分离的（实际上，在命名空间中）
• 您不仅可以共享主节点，还可以共享两个环境共享的具有 pod 的一些节点，以及在 staging/uat/... 中使用现货或更便宜的实例来降低成本。
• 无集群管理开销

您必须注意角色和策略以确保其安全。您可以使用 eks+calico 等来实施网络策略。

更新：

我找到了一个在使用 EKS 时可能有用的文档。它包含有关如何安全运行多租户集群的一些详细信息，其中一些详细信息可能有助于将生产 Pod 和命名空间与暂存中的 Pod 和命名空间隔离。

https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/

Answer 7

这里有一些想法：

1. 不要信任命名空间来保护集群免受灾难。拥有独立的生产和非生产（开发、阶段、测试等）集群是最低的必要要求。众所周知，吵闹的邻居会导致整个集群瘫痪。

2. 随着团队规模的扩大，代码和 k8s 部署的单独存储库（Helm、Kustomize 等）将使基于主干的开发和功能标记等最佳实践变得更加容易。

3. 使用环境即服务 (EaaS) 将允许每个 PR 在其自己的短期（短暂）环境中进行测试。每个环境都是生产环境的高保真副本（包括数据库、存储桶、dns 等自定义基础设施），因此开发人员可以针对值得信赖的环境（不是 minikube）进行远程编码。这有助于减少配置偏差、改善发布周期并改善整体开发体验。（免责声明：我在一家 EaaS 公司工作）。