多集群注意事项

看看Vadim Eisenberg（IBM / Istio）的这篇博客文章：Checklist: pros and cons of using multiple Kubernetes clusters, and how to distribute workloads between them。
我想强调一些优点/缺点：

多集群的原因

• 生产/开发/测试分离：特别是用于测试Kubernetes的新版本，服务网格，其他集群软件
• 合规性：根据某些法规，某些应用程序必须在单独的群集/单独的VPN中运行
• 更好的隔离，以确保安全
• Cloud/on-prem：在本地服务之间分配负载
  单集群的理由
• 减少设置、维护和管理开销
• 提高利用率
• 降成本

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

• 1个用于DEV和STAGING的集群（通过命名空间分隔，* 甚至可以使用网络策略进行隔离，如Calico *）
• 1个PROD群集

环境奇偶校验

这是一个good practice，以保持开发，登台和生产尽可能相似：
备份服务之间的差异意味着微小的不兼容性突然出现，导致在开发或阶段中工作并通过测试的代码在生产中失败。这些类型的错误会产生摩擦，从而抑制持续部署。

**合并，将强大的CI/CD工具与helm**相结合。您可以使用helm值的灵活性来设置默认配置，只需覆盖不同环境下的不同配置。

GitLab CI/CD with AutoDevops与Kubernetes有强大的集成，允许您管理多个Kubernetes集群，这些集群已经支持Helm。

Managing multiple clusters（kubectl交互）

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

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

我有一篇文章介绍了如何实现这一点：Using different kubectl versions with multiple Kubernetes clusters
我还建议阅读以下内容：

• Mastering the KUBECONFIG file由Ahmet Alp巴尔干半岛的（*Google工程师 *）
• How Zalando Manages 140+ Kubernetes Clusters by Henning Jacobs（Zalando Tech）

一定要使用单独的集群进行开发和创建docker镜像，这样你的staging/production集群就可以被安全地锁定。是否为staging + production使用单独的集群取决于你的风险/成本-当然，保持它们的独立将有助于避免staging影响production。
我还强烈推荐使用GitOps在您的环境之间推广您的应用程序版本。
为了最大限度地减少人为错误，我还建议您尽可能多地为CI/CD和促销进行自动化。
这里是a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps，用于在Pull Requests上在环境和预览环境之间进行升级，这是在GKE上实时完成的，尽管Jenkins X支持大多数kubernetes集群

这取决于你想在每个场景中测试什么。通常我会尽量避免在生产集群上运行测试场景，以避免不必要的副作用（性能影响等）。
如果您打算使用一个 * 完全模仿生产系统 * 的临时系统进行测试，我建议您启动完整集群的精确副本，并在完成测试后关闭它，然后将部署转移到生产环境。
如果您的目的是测试一个允许 * 测试应用程序 * 部署的临时系统，我将永久运行一个较小的临时集群，并根据持续测试的需要更新部署（以及部署的缩小版本）。
为了控制不同的集群，我更喜欢有一个单独的ci/cd机器，它不是集群的一部分，但用于启动和关闭集群以及执行部署工作，启动测试等。

很明显，通过将生产集群与临时集群分开，可以降低影响生产服务的潜在错误的风险。然而，这是以更多的基础设施/配置管理为代价的，因为它至少需要：

• 至少3个主服务器用于生产群集，至少一个主服务器用于分段群集
• 2个Kubectl配置文件添加到CI/CD系统

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

• QA：这是我们进行日常部署的地方，也是我们在向客户端发布之前进行内部QA的地方）
• 客户端QA：这是我们在部署到生产环境之前进行部署的地方，以便客户端可以在发布到生产环境之前验证环境）
• 生产：部署生产服务的地方。

我认为短暂/按需集群是有意义的，但仅适用于某些用例（负载/性能测试或非常“大”的集成/端到端测试），但对于更持久/粘性的环境，我看到在单个集群中运行它们可能会减少开销。
我想我想联系一下k8s社区，看看对于我所描述的这种场景，使用了什么模式。

除非法规遵从性或其他要求另有规定，否则我倾向于为所有环境使用单个集群。使用此方法时，注意事项如下：

• 请确保您还使用标签对每个环境的节点进行分组。然后您可以在资源上使用nodeSelector，以确保它们在特定节点上运行。这将减少环境之间（过度）资源消耗溢出的机会。
• 默认情况下，将您的命名空间视为禁用，并禁止所有的出口/入口流量。请参阅https://kubernetes.io/docs/concepts/services-networking/network-policies/。
• 有一个管理服务帐户的策略。如果一个集群承载多个环境，ClusterRoleBindings意味着不同的东西。
• 在使用Helm等工具时要仔细检查。有些图表会公然安装具有群集范围权限的服务帐户，但服务帐户的权限应限于其所在的环境。

我认为有一个中间点。我正在使用eks和节点组。master由aws管理，缩放和维护。然后您可以创建3种节点组（只是一个示例）：
1 -通用->标签：环境=通用
2 - Staging -> labels：environment=staging（如果需要，则进行污点处理）
3 -产品->标签：环境=生产（如有必要，污染）
您可以在pod上使用tolerations和节点选择器，以便将它们放置在应该放置的位置。
这允许您为生产的节点组使用更健壮或更强大的节点，例如，SPOT示例用于staging，uat，qa等，并且有几个大的优点：

• 环境在物理上是分离的（在名称空间中也是虚拟的）
• 您可以通过以下方式降低成本：不仅共享master，还共享两个环境共享的pod节点，以及在staging/uat/.
• 无群集管理开销

你必须注意角色和策略来保证它的安全。你可以使用eks+calico来实现网络策略。
更新：
我发现了一个在使用EKS时可能有用的文档。它有一些关于如何安全运行多租户集群的细节，其中一些细节可能有助于将生产Pod和命名空间与staging中的Pod和命名空间隔离开来。
https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/

这里有一些想法：
1.不要信任命名空间来保护集群免受灾难。拥有独立的生产和非生产（开发、阶段、测试等）集群是最低的必要要求。bring down entire clusters已经知道嘈杂的邻居。
1.代码和k8s部署（Helm、Kustomize等）的单独存储库将使像trunk-based development and feature-flagging这样的最佳实践随着团队规模的扩大而变得更容易。
1.使用环境即服务（EaaS）将允许每个PR在其自己的短期内进行测试每个环境都是生产环境的高保真副本（包括自定义基础设施，如数据库、存储桶、DNS等），因此开发人员可以在可信赖的环境中远程编码（不是minikube）。这可以帮助减少配置漂移，改善发布周期，并改善整体开发体验。（免责声明：我为EaaS公司工作）。

使用多个集群是一种规范，至少可以在生产和“非生产”之间强制分离。
本着这种精神，请注意GitLab 13.2（2020年7月）现在包括：

Core多Kubernetes集群部署

使用GitLab通过GitLab部署多个Kubernetes集群之前需要Premium许可证。
我们的社区发言，我们倾听：部署到多个集群甚至对个人贡献者都很有用。

根据您的反馈，从GitLab 13.2开始，您可以在Core中部署到多个组和项目集群。

的数据
参见文档和issue。

我认为运行单个集群是有意义的，因为它减少了开销，监控。但是，你必须确保网络策略，访问控制到位。
网络策略-禁止dev/qa环境工作负载与prod/staging存储交互。
访问控制-谁可以访问不同的环境资源，使用角色，角色等。