Environ 简介

Environ 是 Google Cloud 的概念,用于以逻辑方式组织集群和其他资源,让您可以使用和管理多集群功能,并在您的所有系统中应用一致的政策。Environ 构成企业多集群功能在 Anthos 中的工作原理的关键部分。Environ 在某些 Google Kubernetes Engine (GKE) 功能中也有用到。

本指南介绍了 Environ:Environ 的意义、在组件中的哪些位置使用 Environ,以及如何设置系统以利用 Environ 级别的功能。我们还提供了一些示例来说明 Environ 如何帮助您简化集群和系统管理,并介绍了当您使用 Environ 构建和运行多集群系统时应该遵循的最佳做法

本指南适用于要利用多个集群和相关基础架构的技术读者,包括系统架构师、平台运营商和服务操作员。无论组织是在 Google Cloud 中、跨多个云提供商还是在本地运行多个集群,上述概念都非常有用。

您需要熟悉基本的 Kubernetes 概念(例如集群);如果没有,请参阅 Kubernetes 基础知识GKE 文档准备 Anthos Service Mesh 的应用

如需详细了解 Anthos 以及使用 Environ 的组件,请参阅我们的 Anthos 技术概览探索 Anthos 教程。但是,您无需熟悉 Anthos 即可按照本指南进行操作。

简介

通常,当组织接受容器、容器编排和服务网格等云原生技术时,它们到达运行单个集群的点已不复存在。组织选择部署多个集群以实现其技术和业务目标的原因多种多样;例如,将生产环境与非生产环境分开,或者隔离各个层级、语言区域或团队中的服务。如需详细了解多集群方法带来的优势和利弊权衡,请参阅多集群用例

随着集群数量的增加,管理和治理这些集群及其内部的资源也变得越来越困难。此时,组织通常致力于构建自定义工具和操作政策,以获得所需的控制级别。

Google Cloud 提供了 Environ 概念,可帮助管理员管理多个集群。Environ 提供了一种对集群进行逻辑分组和归一化的方法,让基础架构的管理变得更轻松。在 Anthos 和 GKE 环境中都可以使用 Environ;您可以在本文档后面的启用 Environ 的组件部分中查看可以利用 Environ 的 Anthos 和 GKE 组件列表。

采用 Environ 可帮助您的组织将管理级别从单个集群升级到整组集群。此外,Environ 需要的标准化可以帮助您的团队采用与 Google 所用做法类似的最佳做法。为了便于比较,就像组织资源是 Google Cloud 资源层次结构中的根节点,用于政策以及控制其下分组的资源,Environ 构成了用于管理多个集群的根节点。

术语

以下是在讨论 Environ 时会用到的一些重要术语。

Environ 感知资源

Environ 感知资源是可以作为 Environ 进行逻辑分组和管理的 Google Cloud 项目资源。目前,只有 Kubernetes 集群可以充当 Environ 成员,不过我们可以预见虚拟机 (VM) 实例和其他资源能够在未来的平台迭代中加入 Environ。Google Cloud 提供 Connect 服务,用于将资源注册为 Environ 成员。

Environ 宿主项目

与大多数其他 Google Cloud 资源一样,Environ 实现根植于 Google Cloud 项目中,我们将其称为 Environ 宿主项目。给定的 Cloud 项目只能关联一个 Environ(或不关联任何 Environ)。此限制可强化使用 Cloud 项目在未受治理或未一起使用的资源之间实现更强的隔离。

支持 Environ 的组件

以下 Anthos 和 GKE 组件都会使用 Environ 概念(例如命名空间和身份相同性),以提供简化的方式来使用集群和服务。如需了解将 Environ 与每个组件搭配使用时的任何当前要求或限制,请参阅组件要求

  • 工作负载身份池(Anthos 和 GKE 集群)
    Environ 提供了一个常用的工作负载身份池,可用于进行身份验证并在网格内以及向外部服务统一授权工作负载。

  • Anthos Service Mesh (Anthos)
    Anthos Service Mesh 是一套工具,可帮助您在 Google Cloud 或本地监控和管理可靠服务网格。您可以在属于同一 Environ 的资源(如集群和虚拟机)之间形成服务网格。

  • Anthos Config Management (Anthos) 和 Config Sync (GKE)
    Anthos Config Management 可让您部署和监控存储在中央 Git 代码库中的系统的声明性政策和配置更改,并利用命名空间、标签和注释等 Kubernetes 核心概念。借助 Anthos Config Management(及其非 Anthos 集群的同级产品 Config Sync),政策和配置会在 Environ 中定义,但在每个本地成员资源中应用和强制执行。

  • 多集群 Ingress (Anthos)
    多集群 Ingress 使用 Environ 定义可以实现流量负载平衡的一组集群和服务端点,从而启用低延迟时间和高可用性服务。

分组基础架构

作为防火墙的重要概念,分组也就是选择相关 Environ 感知资源应该是 Environ 的一部分。如需决定如何对内容进行分组,您需要回答以下问题:

  • 资源之间是否相关?
    • 具有大量跨服务通信的资源最适合在 Environ 中进行集中管理。
    • 同一部署环境中的资源(例如您的生产环境)应集中在 Environ 中进行管理。
  • 谁管理资源?
    • 统一(或至少相互信任)对资源的控制至关重要,这可确保 Environ 的完整性。

为了说明这一点,假设有一个组织具备多条业务线 (LOB)。在这种情况下,服务很少跨 LOB 边界进行通信,处于不同 LOB 的服务以不同方式进行管理(例如,各个 LOB 的升级周期不同),这些服务的每个 LOB 甚至拥有一组不同的管理员。在这种情况下,或许较佳的做法是为每个 LOB 设置 Environ。此外,每个 LOB 也可能采用多个 Environ 将其生产服务和非生产服务分开。

随着其他 Environ 概念在以下方面的深入探索,您可能会发现在考虑特定组织需求时可创建多个 Environ 的其他原因。

相同性

Environ 概念的一个重要概念是相同性概念。这意味着,某些 Kubernetes 对象(例如不同上下文中同名的集群)将被视为同一对象。这种标准化做法使得管理 Environ 资源更具可控性。它提供了有关如何设置命名空间、服务和身份的可靠指导。但是,它也遵循大多数组织自身也在实施的内容。

命名空间相同性

Environ 中的基本相同性示例是命名空间相同性。许多组件会将不同集群中同名的命名空间视为同一命名空间。考虑该属性的另一种方法是,命名空间在整个 Environ 中以逻辑方式定义,即使命名空间的实例化仅存在于一组 Environ 资源中也是这样。

请参考以下 backend 命名空间示例。虽然命名空间仅会在集群 A 和 B 中实例化,但它已在集群 C 中隐式预留(必要时,您还可以将 backend 服务安排到集群 C 中)。这意味着将命名空间分配给整个 Environ,而不是按集群分配。因此,命名空间相同性要求整个 Environ 具有一致的命名空间所有权。

展示 Environ 中的命名空间相同性的图表
Environ 中的命名空间相同

服务相同性

Anthos Service Mesh 和多集群 Ingress 在命名空间中使用服务相同性的概念。与命名空间相同性类似,这意味着具有相同命名空间和服务名称的服务被视为同一服务。

对于 Anthos Service Mesh,服务端点可以在整个网格中进行合并。对于多集群 Ingress 时,MultiClusterService (MCS) 资源能够使端点更明确地合并;但我们推荐根据命名采用类似的做法。因此,请务必确保同一命名空间中名称完全相同的服务实际上是相同的服务。

在以下示例中,互联网流量在集群 B 和 C 的 frontend 命名空间内的同名服务中实现了负载平衡。同样,借助 Environ 中的服务网格属性,frontend 服务可以访问集群 A 和 C 的 auth 命名空间中的同名服务。

展示 Environ 中服务一致性的示意图
同一 Environ 中的服务相同

访问外部资源时的身份相同性

Environ 中的服务在出站时可以利用通用身份访问 Google Cloud 服务、对象存储等外部资源。此通用身份可让 Environ 内的服务访问一次外部资源(而不是逐个访问集群)。

为了进一步说明这一点,请参考以下示例。集群 A、B 和 C 在其 Environ 中注册了通用身份。当 backend 命名空间中的服务访问 Google Cloud 资源时,其身份将被映射到名为 back 的常用 Google Cloud 服务帐号。Google Cloud 服务帐号 back 可以在任意数量的代管式服务(从 Cloud Storage 到 Cloud SQL)上获得授权。当在 backend 命名空间中添加新的 Environ 资源(例如集群)时,它们会自动继承工作负载身份相同性属性。

由于身份相同,因此 Environ 中的所有资源都必须受到信任且管理严格。回顾之前的例子,如果集群 C 归一个单独的不受信任的团队所有,则他们还可以创建 backend 命名空间并访问代管式服务,就像集群 A 或集群 B 中的 backend 一样。

展示在 Environ 外部访问资源的身份相同性的示意图
在 Environ 外部访问资源的身份相同性

Environ 内的身份相同

在 Environ 中,身份相同性的用法与我们先前讨论的外部身份相同性的用法类似。就像授权 Environ 服务访问一次外部服务一样,您也可以在内部为它们授权。

在以下示例中,我们已为 frontend 授予了 backend 的访问权限。借助 Environ,我们无需指定集群 B 和 C 中的 frontend 可以访问集群 A 和 B 中的 backend。相反,我们只需指定 Environ 中的 frontend 可以访问 Environ 中的 backend。此属性不仅可以简化授权操作,而且还可提高资源边界的灵活性;现在,可以轻松在集群之间移动工作负载,而不会影响工作负载的授权方式。如同工作负载身份相同性,对 Environ 资源进行治理至关重要,这可确保服务之间通信的完整性。

展示 Environ 中的身份相同性的示意图
对同一 Environ 内的身份信息

排他性

Environ 感知资源在任何给定时间都只能属于单个 Environ,这一限制由 Google Cloud 工具和组件强制执行。此限制可确保只有一个可靠来源用于治理集群。此限制没有排他性,即使是使用最简单的组件也很复杂,需要您的组织解释并配置来自多个 Environ 的多个组件的交互方式。

高信任度

服务相同性、工作负载身份相同性、网格身份相同性均是以 Environ 成员之间的高信任度原则为基础构建的。这种信任机制能够将这些资源的管理级别提升至 Environ,而不是逐一管理每个资源(即逐一管理 Kubernetes 资源的每个集群),最终使集群边界变得不太重要。

在另一个 Environ 中,集群提供防止受到半径影响、保护(控制层面和底层基础架构)、嘈杂邻域等的保护。但是,它们对于政策和治理并没有很强的边界,因为任何一个 Environ 中的管理员成员可能会影响 Environ 其他成员的服务的运作方式。

因此,我们建议 Environ 管理员不信任的资源放入各自的 Environ 中,以便将其隔离。然后,您可以根据需要在单个 Environ 边界上向各项服务授权。

后续步骤

准备考虑将这些概念应用到您自己的系统吗?请参阅我们的 Environ 要求和最佳做法