Google Cloud Anthos 和 GKE 有什么关系，混合云 Kubernetes 应该如何理解

很多企业第一次接触 Google Cloud 的混合云 Kubernetes 时，都会遇到一个看似简单的问题：Google Kubernetes Engine（GKE）和 Anthos 到底是什么关系？为什么有时看到 GKE，有时又看到 Anthos、GKE Enterprise、Google Distributed Cloud，甚至还会出现 Fleet、Connect Gateway 和 Cloud Service Mesh 等名称？

如果只按照传统产品名称去理解，很容易把它们看成几个彼此独立的 Kubernetes 产品。实际上，Google Cloud 这几年的产品体系已经发生了明显变化。Anthos 曾经是 Google Cloud 推动混合云和多云 Kubernetes 的重要品牌，而现在相关能力已经逐渐整合进 GKE Enterprise、Fleet Management、Google Distributed Cloud 等体系。因此，理解今天的混合云 Kubernetes，不能简单地把 Anthos 看成一个单独的“管理平台”，更不能把 GKE 理解成 Anthos 里面的一个普通组件。

GKE 本身是什么

Google Kubernetes Engine，简称 GKE，是 Google Cloud 提供的托管 Kubernetes 服务。最典型的场景就是企业直接在 Google Cloud 上创建 Kubernetes 集群，把应用部署到 Google 的云基础设施中。

例如，一家公司有一个电商平台，订单系统、商品系统、支付接口和后台管理服务都运行在 Kubernetes 中。如果全部部署在 Google Cloud，那么企业可以使用 GKE 创建和管理 Kubernetes 集群，由 Google Cloud 负责大量底层基础设施和 Kubernetes 运维工作。

这就是最容易理解的 GKE。

但大型企业往往不会把所有业务都放到一个公有云里。

一家银行可能因为监管要求，把客户核心数据和部分交易系统留在自己的数据中心；与此同时，营销网站、数据分析平台或者部分互联网业务又希望使用 Google Cloud 的计算资源。制造企业也可能在工厂附近运行 Kubernetes，用于实时控制和边缘计算，同时把总部的数据分析业务放到公有云。

这时候，企业面对的已经不是“如何运行一个 Kubernetes 集群”，而是“如何管理很多分散在不同环境中的 Kubernetes 集群”。

Anthos 曾经解决的正是这个问题

Anthos 最初是 Google Cloud 为混合云和多云 Kubernetes 推出的产品品牌。它的核心思想不是把所有 Kubernetes 集群物理上变成一个集群，而是在不同环境中运行多个 Kubernetes 集群，再利用统一的管理、配置、身份、安全和服务治理能力，让这些集群可以按照统一的规则进行管理。

这一点非常重要。

假设一家企业有三个 Kubernetes 集群，一个运行在 Google Cloud 的 GKE 上，一个运行在公司自己的 VMware 数据中心，还有一个运行在另一家公有云中。它们仍然是三个独立的 Kubernetes 集群，各自拥有自己的节点、Pod、网络和控制平面。

所谓“统一管理”，并不意味着三个集群突然变成了一个大型 Kubernetes 集群。

更准确的理解是，企业可以把这些集群组织成一个 fleet，也就是逻辑上的集群集合，然后通过 Google Cloud 提供的 Fleet Management 等能力，对多个集群实施统一的配置、策略、身份和可观测性管理。Google 当前的 GKE 文档也明确将 fleet 定义为可以共同管理的一组 Kubernetes 集群和相关资源，而且 fleet 可以包含 Google Cloud 之外的集群。

从 Anthos 到 GKE Enterprise

这也是今天理解 Anthos 最容易出错的地方。

Google Cloud 在2023年推出 GKE Enterprise，将 GKE 和 Anthos 的很多能力进一步整合到统一的平台体系中。Google 当时明确表示，GKE Enterprise 是建立在 GKE 和 Anthos 能力之上的集成式容器平台，并继续提供混合云和多云支持。

因此，如果读者看到几年前的技术文章写着“Anthos 管理 GKE、本地 Kubernetes 和多云 Kubernetes”，并不能简单地把这套产品关系原封不动搬到今天。

今天更适合把它理解成一个不断演进的 Google Cloud Kubernetes 平台体系：GKE负责 Kubernetes 工作负载运行，Fleet Management 负责多集群组织和管理，而 Google Distributed Cloud 则把 GKE 相关能力延伸到企业自己的数据中心、VMware 或裸机环境。Google 当前文档已经将 Anthos 相关的本地部署产品逐步归入 Google Distributed Cloud 体系。

那么混合云 Kubernetes 到底是什么

混合云 Kubernetes 并不是一种特殊版本的 Kubernetes。

它首先是一种部署架构。

例如，一家公司可能有两个集群。第一个是运行在 Google Cloud 上的 GKE 集群，负责网站、API 和弹性计算业务；第二个运行在公司自己的数据中心，负责不能离开企业内部网络的数据库访问、生产系统或者受监管的数据处理。

两个集群之间可以存在网络连接，也可以通过统一的身份、安全和配置体系进行管理，但它们仍然是两个独立的 Kubernetes 集群。

如果企业使用 Google Distributed Cloud software only for VMware，就可以在自己的 VMware vSphere 基础设施中运行 GKE 相关的 Kubernetes 环境；如果使用裸机方案，则可以直接在企业自己的物理服务器上部署相关集群。Google 当前文档显示，这些方案原先分别与 Anthos clusters on VMware、Anthos clusters on bare metal 等名称有关。

这就形成了比较典型的混合云架构。

真正困难的地方是多个集群之间的管理

假设企业有十个 Kubernetes 集群。

其中三个在 Google Cloud，两个在公司总部的数据中心，三个在不同地区的分支机构，还有两个运行在其他云环境。如果每个集群都由不同团队独立管理，很快就会出现版本不同、权限不同、网络规则不同、日志格式不同的问题。

例如，安全团队要求所有生产环境禁止某种高风险容器配置。如果只有一个 Kubernetes 集群，管理员修改一次策略即可。但如果企业拥有二十个集群，逐个登录、逐个修改，不但效率低，而且很容易出现遗漏。

Fleet 的意义就在这里。

Google Cloud 可以把不同位置的 Kubernetes 集群注册到 fleet 中，再使用 Config Sync、Policy Controller、Cloud Service Mesh 等能力，对多个集群实施统一的配置、策略和服务治理。Google 的文档也说明，fleet 可以包含 Google Cloud 内外的 Kubernetes 集群，第三方 Kubernetes 集群则可以通过注册方式加入。

这比“一个控制平面管理所有 Kubernetes”更加准确。

混合云并不等于所有业务跨集群运行

这是很多架构设计中容易出现的误区。

例如，一家企业把订单服务部署在 Google Cloud，把客户数据库留在本地数据中心。理论上两个环境可以通过网络连接，但并不意味着订单服务应该每处理一笔请求就跨公网访问一次本地数据库。

如果网络延迟从几毫秒增加到几十毫秒甚至更高，而应用又存在大量同步数据库调用，业务性能可能迅速下降。更严重的是，一旦专线或者网络连接发生故障，云端业务可能同时受到影响。

因此，混合云设计通常需要首先考虑业务边界，而不是先考虑 Kubernetes。

哪些应用必须留在本地？哪些应用可以部署到公有云？哪些数据允许跨环境传输？哪些服务需要实时通信？哪些任务可以采用异步消息？这些问题比“选择哪个 Kubernetes 产品”更加重要。

GKE 也不是负责自动把工作负载随意搬来搬去

原文中还有一个容易误解的地方，即认为 Anthos 可以根据负载把资源动态分配到本地或者云端。

实际上，混合云 Kubernetes 并不是一个“哪里有空闲 CPU 就把 Pod 搬到哪里”的全球调度器。

不同 Kubernetes 集群具有独立的控制平面、节点、网络和存储。企业可以利用多集群能力进行工作负载部署、流量管理和配置同步，但跨集群调度涉及网络、镜像、身份、存储、数据一致性、合规性等大量条件，并不是简单地把一个 Pod 从本地服务器移动到 GKE。

因此，企业通常会通过 GitOps、CI/CD、fleet 配置管理或者多集群服务治理，让相同或不同版本的应用按照预先设计的规则部署到不同集群，而不是依赖一个“万能调度器”自动决定所有工作负载的位置。

网络和服务治理才是混合云的核心难题之一

假设一个企业把前端服务部署在 GKE，把内部支付服务部署在本地 Kubernetes。

这时需要解决的已经不仅是 Pod 能不能访问另一个 Pod，而包括服务发现、TLS 加密、身份认证、访问控制、流量路由、故障切换以及监控等问题。

Google Cloud 当前的 Cloud Service Mesh 可以用于多集群服务治理，fleet 也可以作为多个 Kubernetes 集群实施统一策略和服务治理的基础。Google 的 fleet 文档显示，相关能力可以用于跨集群路由、服务身份以及统一的授权策略。

Connect Gateway 则解决了另外一个非常实际的问题：管理员不一定需要直接进入每一个企业内部网络，才能访问已经注册到 fleet 的 Kubernetes 集群。Google 的文档显示，Connect Gateway 可以让用户通过一致的方式连接 Google Cloud、本地以及其他公有云中的 fleet 集群。

存储问题往往比 Kubernetes 本身更加棘手

混合云架构中，另一个容易被低估的问题是持久化数据。

例如，一个应用运行在本地 Kubernetes，而数据库位于 Google Cloud。如果应用的数据需要频繁跨环境读写，网络延迟和连接可靠性就会直接影响数据库性能。

反过来，如果应用部署在 GKE，而数据库必须留在本地，企业也需要认真设计连接方式、缓存、消息队列和故障处理机制。

尤其需要注意的是，Google Cloud 的 Persistent Disk 并不是一种可以让同一个 Kubernetes PersistentVolume 自动跨本地数据中心和其他云环境自由移动的“万能硬盘”。存储通常与具体云环境、区域、集群以及网络架构紧密相关。因此，混合云项目不能只设计 Kubernetes YAML 文件，而必须把数据库、对象存储、备份、灾难恢复和数据同步一起考虑。

什么时候值得使用混合云 Kubernetes

如果企业只有几个应用，而且全部运行在 Google Cloud，那么直接使用 GKE 往往比建立复杂的混合云平台更加合理。

如果企业已经拥有大型本地 Kubernetes 环境，同时又需要把部分工作负载扩展到 Google Cloud，那么 GKE、Fleet Management、Google Distributed Cloud 以及相关的多集群能力才具有更明显的价值。

对于大型企业来说，真正的收益也不是“把所有 Kubernetes 集群变成一个集群”，而是让不同环境中的 Kubernetes 保持相对独立，同时让企业在配置、安全、身份、监控和运维流程上尽可能标准化。

今天再理解 Anthos 与 GKE 的关系，最准确的方式已经不是简单地说“GKE 是 Anthos 的一个组件”。GKE 是 Google Cloud 的 Kubernetes 核心运行平台，而 Anthos 曾经代表 Google Cloud 在混合云、多云 Kubernetes 领域的一整套产品能力，这些能力后来逐渐融入 GKE Enterprise、Fleet Management 和 Google Distributed Cloud 等体系。

对于企业架构师来说，真正值得关注的也不再只是产品名称，而是一个更加实际的问题：哪些工作负载应该运行在哪里，以及企业有没有能力让这些分散的 Kubernetes 集群保持统一的安全、配置、身份和运维标准。混合云 Kubernetes 的价值，并不是把不同的数据中心强行变成一个集群，而是在保持基础设施独立性的同时，让应用平台尽可能保持一致。做到这一点，才是混合云架构真正的工程价值。