探索 GKE 网络文档和使用情形

Google Kubernetes Engine (GKE) 中的网络涵盖了广泛的概念，包括 Pod、服务、DNS、负载均衡、安全性和 IP 地址管理。虽然文档详细介绍了每项功能，但在遇到实际问题时，您可能很难知道从何处入手。

本文档通过将常见挑战与解决这些挑战的功能和部分相关联，帮助您浏览 GKE 网络文档。 每个用例都提供了一个场景，指出了挑战，并引导您查看相关文档。本文档适用于必须了解并解决 GKE 中常见网络问题的云架构师、开发者和运营团队。

如果您已经熟悉常见的网络挑战，并希望直接深入了解技术细节，请探索以下资源，以建立 GKE 网络的基础知识：

用例：为 GKE 设计网络基础

在此用例中，您是一位云架构师，需要为新的 GKE 平台设计可伸缩、安全且可靠的网络基础。

挑战：防止 IP 地址耗尽

场景：您的应用复杂性和使用量预计会增加，因此您需要设计一个可扩缩的网络，以处理增加的流量并支持 Pod、服务和节点增长。您还需要规划 IP 地址分配，以避免耗尽

解决方案：规划 IP 地址分配方案，以考虑您需要的节点、Pod 和 Service 的数量。此计划包括为每个网络选择合适的 IP 地址范围、考虑 Pod 密度，以及避免与其他网络重叠。如需了解详情，请参阅管理 GKE 中的 IP 地址迁移。

挑战：强制执行纵深防御安全策略

场景：您需要保护集群边界并强制执行零信任 Pod 到 Pod 规则。

解决方案：为集群边界使用防火墙政策。如需了解详情，请参阅使用网络政策控制 Pod 和服务之间的通信。

挑战：将流量路由到不同类型的应用

场景：您需要确保其他服务和用户可以访问不同类型的应用，例如私有后端和公共 HTTP(S) 应用。

解决方案：为专用后端使用内部负载平衡器。对于公共 HTTP(S) 应用，请使用 Ingress 或 Gateway API。如需了解详情，请参阅 GKE 中的负载均衡简介。

挑战：使用可观测性工具监控和排查工作负载问题

场景：您必须解决网络流量问题，并且需要了解和监控 GKE 流量流，以便有效地诊断问题。

解决方案：实施可观测性工具，以监控网络流量并排查相关问题。如需了解详情，请参阅使用 GKE Dataplane V2 可观测性功能观察流量。

使用情形：公开新的微服务

在此使用情形中，您是一名开发者，需要在 GKE 中部署新的微服务。您需要让微服务可供集群中的其他服务访问，稍后还需要让外部客户端能够访问该微服务。

挑战：为 Pod 到 Pod 的通信提供稳定的端点

场景：您的应用需要 Pod 与其他 Pod 通信，但 Pod 使用的动态 IP 地址使这种通信不可靠。

解决方案：创建 Kubernetes 服务。ClusterIP 服务提供稳定的虚拟 IP 地址和 DNS 名称，并在 Pod 之间实现负载均衡。如需了解详情，请参阅了解 Kubernetes 服务。

挑战：公开服务以供外部访问

场景：微服务必须可从互联网访问，以便进行演示。

解决方案：创建 LoadBalancer 服务。GKE 会预配一个具有公共 IP 地址的区域级外部直通式网络负载平衡器。对于 HTTP(S) 流量，请考虑使用 Ingress 或 Gateway，它们提供第 7 层功能。如需了解详情，请参阅 LoadBalancer Service 简介。

挑战：分配永久的、方便用户使用的网址

场景：服务需要稳定的域名供客户端使用。

解决方案：预留静态 IP 地址并为自定义网域配置 DNS。 如需了解详情，请参阅使用静态 IP 地址配置域名。

挑战：管理高级流量路由

场景：随着应用的发展，您需要更精细地控制流量的路由方式。例如，您可能需要执行以下操作：

  • 在单个负载均衡器上托管多个网站（例如 api.example.com 和 shop.example.com），以节省费用。
  • 根据网址路径将请求路由到不同的服务（例如，将 / 发送到前端工作负载，并将 /api/v1 发送到后端工作负载）。
  • 通过管理 TLS 证书，使用 HTTPS 保护您的应用。
  • 使用 Canary 版本分阶段安全地部署新功能，即在全面推出之前，先将一小部分流量发送到新版本。

解决方案：使用 Gateway API。GKE 对 Gateway API 的实现提供了一种强大而标准化的方式来管理此类南北向流量，支持基于路径的路由、标头匹配和流量拆分等高级功能。如需了解详情，请参阅 Gateway API 简介。

使用情形：针对不断增长的应用扩展服务发现

随着基于微服务的应用的流量和复杂性不断增加，服务之间的 DNS 查询也会显著增加。虽然开发者需要了解如何在此环境中构建弹性应用，但平台和运维团队通常负责实现可伸缩的网络解决方案。

挑战：启用服务间通信

场景：Pod 需要一种可靠的方式来查找其他服务。

解决方案：GKE 提供集群内 DNS 服务（例如 kube-dns 或 Cloud DNS），可解析服务的稳定 DNS 名称，从而实现可靠的 Pod 到 Pod 通信。如需了解详情，请参阅服务发现和 DNS。

挑战：大规模提升 DNS 性能

场景：查询量过高导致查找延迟。

解决方案：启用 NodeLocal DNSCache。每个节点都会在本地缓存 DNS 查询，从而缩短延迟时间。如需了解详情，请参阅 NodeLocal DNSCache 设置概览。

挑战：在整个 VPC 中提供服务发现

场景：Compute Engine 虚拟机需要访问集群内的服务。

解决方案：与 Cloud DNS 集成，以便服务 DNS 记录在整个 VPC 中解析。如需了解详情，请参阅使用 Cloud DNS for GKE。

使用情形：保护多层应用

在此使用情形中，您所在的平台工程团队正在部署三层应用（前端、结算、数据库），并且您必须强制执行零信任通信。

挑战：强制执行严格的流量规则

场景：只有特定服务应彼此通信。

解决方案：启用网络政策强制执行功能并应用 default deny 政策，然后定义明确的允许规则（例如，前端允许流量流向结算，结算允许流量流向数据库）。如需了解详情，请参阅为应用配置网络政策。

挑战：审核和验证网络政策

场景：安全性需要执行证明和可见性。

解决方法：启用网络政策日志记录功能，以记录允许和拒绝的连接。如需了解详情，请参阅使用网络政策日志记录。

挑战：以私密方式向使用方公开服务

应用场景：后端服务（例如数据库或 API）需要可供其他 VPC 网络中的使用者访问，同时避免将其暴露给公共互联网或处理复杂的 VPC 对等互连问题。

解决方案：使用 Private Service Connect 发布服务。 然后，使用方可以在自己的 VPC 中创建 PSC 端点，以私密且安全的方式访问您的服务。如需了解详情，请参阅使用 Private Service Connect 公开服务。

用例：在多个集群中实现高可用性

在此用例中，您是一名 SRE，负责在不同区域的多个 GKE 集群中为一家电子商务公司运行工作负载，以提高可靠性。

挑战：启用跨集群通信

场景：一个集群中的服务必须发现并调用另一个集群中的服务。

解决方案：使用 GKE 多集群服务 (MCS) 创建全局 DNS 名称，并自动将流量路由到运行状况良好的后端。如需了解详情，请参阅多集群服务。

挑战：确保弹性故障切换

场景：如果某个区域服务不可用，流量必须自动重新路由。

解决方案：MCS 提供健康状况感知型服务发现，使客户端能够将单个 DNS 名称解析为最近可用集群中的健康后端。这种方法可实现弹性故障切换。如需了解详情，请参阅多集群服务。

使用场景：构建安全高效的多租户 GKE 环境

作为平台工程团队的一员，您需要向多个应用团队提供 GKE 集群。您需要集中控制网络、节省 IP 地址并强制执行严格的安全措施。

挑战：集中控制网络

场景：多个应用团队需要各自的集群，但网络必须集中管理。

解决方案：使用共享 VPC。网络资源位于宿主项目中，但应用集群在服务项目中运行。如需了解详情，请参阅通过共享 VPC 配置集群。

挑战：高效管理有限的 IP 地址

场景：IP 地址空间有限，需要高效使用。

解决方案：调整每个节点的最大 Pod 数量，并在需要时使用非 RFC 1918 范围作为 Pod IP 地址。如需了解详情，请参阅 在 GKE 中管理 IP 地址迁移。

挑战：使用现代化的安全数据平面，并使用新数据平面预配集群

场景：

  • 企业需要高性能和内置的政策执行功能，以支持要求苛刻的工作负载和零信任安全态势。例如，您可能正在运行对网络延迟非常敏感的大规模微服务，或者您可能需要在多租户集群中的应用之间强制执行严格的安全边界，以满足监管合规性要求。
  • 集群必须配置为使用现代网络数据层，以实现高性能和安全性，并且必须部署在组织集中管理的网络结构中。

解决方案：使用基于 eBPF 的 GKE Dataplane V2，该数据平面可提供高性能和内置的网络政策强制执行功能。如需了解详情，请参阅 GKE Dataplane V2。

应用场景：观察和排查流量问题

作为 SRE，您正在调查结账服务无法连接到付款服务的原因。

挑战：解决连接问题

场景：数据包被丢弃，但原因不明。

解决方案：启用 GKE Dataplane V2 可观测性。hubble_drop_total 等指标会确认数据包被拒绝。如需了解详情，请参阅使用 Hubble 进行问题排查。

挑战：找出丢包的根本原因

场景：确认网络数据包正在被丢弃（例如，通过使用 hubble_drop_total）后，确定哪个特定网络政策正在阻止服务之间的流量。

解决方案：使用 Hubble 命令行界面或界面来跟踪流量。Hubble 界面直观地呈现了流量，并突出显示了拒绝连接的确切错误配置政策。通过这种可视化效果，团队可以快速找出问题的根本原因并更正政策。如需了解详情，请参阅使用 GKE Dataplane V2 可观测性功能观察流量。

端到端使用场景：部署和扩缩安全零售应用

在此端到端场景中，平台工程团队为多个应用团队构建了标准化的 GKE 平台。该团队部署并优化了一个三层零售应用（前端、结算、数据库）。此流程包括保护、伸缩、提升机器学习工作负载的性能，以及集成高级安全设备。

下图展示了部署在 GKE 上的安全多层零售应用的端到端架构。该架构经历了以下几个阶段的演变：

  • 第 1 阶段：使用共享 VPC 和 GKE Dataplane V2 构建基础设置。
  • 第 2 阶段：使用 Gateway API 和多集群服务公开应用，以实现高可用性。
  • 第 3 阶段：使用 gVNIC 和 Tier 1 网络加速机器学习任务。
  • 第 4 阶段：利用多网络支持部署高级安全设备。
图表：展示了 GKE 上安全的多层零售应用的端到端架构，说明了部署和伸缩的六个阶段中的网络组件。
图 1. 一个端到端的架构，用于在 GKE 上构建安全的多层零售应用，重点介绍了在部署和伸缩的每个阶段使用的关键网络组件。以下各部分详细介绍了每个阶段。

第 1 阶段：构建平台基础

挑战：集中管理多个应用团队的网络，并分配足够的 IP 地址来应对伸缩。

解决方案：

第 2 阶段：部署和保护应用

挑战：确保可靠的服务间通信并强制执行零信任安全。

解决方案：

第 3 阶段：公开应用并进行扩容以实现增长

挑战：随着流量增加，提供外部访问权限并缩短 DNS 查找延迟时间。

解决方案：

第 4 阶段：实现高可用性并排查问题

挑战：确保区域故障切换并调试丢弃的流量。

解决方案：

第 5 阶段：加速机器学习工作负载

挑战：消除基于 GPU 的模型训练的网络瓶颈。

解决方案：

  • 启用 gVNIC 以获得更高的带宽。
  • 在关键节点上配置第 1 层级网络，以实现最大吞吐量。

第 6 阶段：部署高级安全设备

挑战：以极低的延迟部署具有单独管理和数据平面流量的第三方防火墙和 IDS。

解决方案：

后续步骤