使用Kubernetes

Question

K8S用于管理多种环境（QA，分期，生产，开发等）的良好做法是什么？

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

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

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

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

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

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

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

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

Answer 1

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

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

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

虽然Jenkins X支持大多数kubernetes集群，但是在GKE上实现了环境和拉动请求预览环境之间的促销a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps

Answer 2

这取决于您希望在每个场景中测试的内容。一般情况下，我会尽量避免在生产群集上运行测试场景，以避免不必要的副作用（性能影响等）。

如果您打算使用完全模仿生产系统的暂存系统进行测试，我建议启动整个群集的精确副本，并在完成测试后关闭它并移动部署到生产。

如果您的目的是测试允许测试应用程序部署的暂存系统，我将永久运行较小的暂存群集并根据需要更新部署（还有部署的缩小版本）用于连续测试。

为了控制不同的集群，我更喜欢拥有一个单独的ci / cd机器，它不是集群的一部分，但用于启动和关闭集群，以及执行部署工作，启动测试等。这样可以设置并关闭群集作为自动化测试方案的一部分。

Answer 3

很明显，通过将生产群集设置从暂存阶段开始，可以降低影响生产服务的潜在错误风险。然而，这需要更多的基础设施/配置管理，因为它至少需要：

• 生产群集至少有3个主服务器和至少一个主服务器
• 要添加到CI / CD系统的2个Kubectl配置文件

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

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

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

我想我想联系k8s社区，看看哪些模式用于我所描述的场景。

Answer 4

多个群集注意事项

看看这篇博客文章：Checklist: pros and cons of using multiple Kubernetes clusters, and how to distribute workloads between them。

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

  

有多个集群的原因

     

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

     

有一个集群的原因

     

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

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

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

环境平价

这是good pratice，用于保持开发，登台和生产尽可能相似：

  

支持服务之间的差异意味着极小的不兼容性   突然出现，导致代码在开发中起作用并通过了测试，或者   停产失败。这些类型的错误会产生摩擦   不利于持续部署。

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

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

Managing multiple clusters （kubectl互动）

  

当您使用多个Kubernetes集群时，很容易   弄乱上下文并在错误的集群中运行kubectl。超越   也就是说，Kubernetes具有restrictions，用于   客户端（kubectl）和服务器（kubernetes主服务器），因此运行命令   在正确的上下文中并不意味着运行正确的客户端版本。

要克服这一点：

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

看看本文，它说明了如何完成此操作：Using different kubectl versions with multiple Kubernetes clusters

我还建议阅读：Mastering the KUBECONFIG file

Answer 5

使用多个群集是常态，在清单上强制在生产和“非生产”之间建立强烈的隔离。

本着这种精神，请注意，GitLab 13.2 (July 2020)现在包括：

Core中的多个Kubernetes集群部署

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

请参见documentation和issue /

Answer 6

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

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

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

• 具有管理服务帐户的策略。 ClusterRoleBindings表示如果群集承载多个环境，则有所不同。

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

Answer 7

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

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

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