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

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

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

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

用例：为 GKE 设计网络基础

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

挑战：防止 IP 地址耗尽

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

解决方案： 规划 IP 地址方案，以考虑您需要的节点、Pod 和服务数量。此计划包括为每个节点选择合适的 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 数，并在需要时为 Pod IP 地址使用非 RFC 1918 范围。 如需了解 详情，请参阅管理 GKE 中的 IP 地址迁移。

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

场景：

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

解决方案： 使用 GKE Dataplane V2，它基于 eBPF，可提供高性能和内置网络政策实施功能。如需了解详情，请参阅 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 和第 1 层网络加快机器学习任务。
  • 第 4 阶段： 使用多网络支持部署高级安全设备。
图表展示了 GKE 上安全的多层零售应用的端到端架构，说明了部署和伸缩的六个阶段中的网络组件。
图 1.GKE 上安全多层零售应用 的端到端架构，突出显示了在部署和伸缩的每个阶段中使用的关键网络组件 。 以下部分介绍了
每个阶段的详细信息。

第 1 阶段：构建平台基础

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

解决方案：

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

挑战： 确保可靠的服务间通信并实施零信任安全措施。

解决方案：

第 3 阶段：公开应用并扩缩以适应增长

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

解决方案：

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

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

解决方案：

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

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

解决方案：

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

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

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

解决方案：

后续步骤