Google Kubernetes Engine (GKE) 网络基于 Google 的全球 VPC 构建而成,可为容器化应用提供强大、可扩缩且安全的基础。它将抽象的 Kubernetes 网络模型转换为具体的、高性能的资源,例如全球负载均衡器和高吞吐量虚拟机网络。
本文档及本套文档的其余部分适用于为组织设计网络架构的云架构师和网络专家。
Kubernetes 网络配置为何不同
在使用 Kubernetes 编排应用时,您需要以不同的方式考虑网络设计。使用 Kubernetes 时,您需要重点关注 Pod、Service 和外部客户端的通信方式,而不是管理单个主机或虚拟机 (VM) 网络。这种抽象化消除了手动端口映射等复杂性,从而简化了应用部署和扩缩。
前提条件
在了解 GKE 中的网络之前,您应该了解以下内容:
- 一般网络、 Google Cloud和 Kubernetes 中的关键概念。
- 请参阅开始了解 GKE。
核心网络和 Google Cloud 基础知识
GKE 基于标准网络原则构建。如需了解 GKE 如何管理和路由集群内和集群间的流量,您应熟悉以下核心网络概念。
网络层和协议
如需了解数据在网络中的传输方式,请先了解网络层。GKE 广泛使用网络栈的传输层、互联网层和应用层的概念。您应该熟悉它们的基本功能和常见协议,例如 HTTP、DNS 和 TCP/IP 套件。如需了解详情,请参阅 OSI 模型。
传输层 - 传输控制协议 (TCP) 或用户数据报协议 (UDP):处理应用之间的端到端通信。 传输控制协议 (TCP) 可提供可靠、有序且经过错误检查的传送,这对于大多数应用流量至关重要。用户数据报协议 (UDP) 提供更快速的无连接通信,通常用于流式传输或游戏。GKE 同时使用这两种协议进行 Pod 和服务通信。
网络层 - 互联网协议 (IP):在不同网络之间寻址和路由数据包。GKE 中的每个 Pod 和节点都会获得一个 IP 地址,而 IP 地址路由决定了流量在集群和 VPC 网络中的传输方式。
应用层 - 超文本传输协议 (HTTP) 和域名系统 (DNS):此层是应用与网络交互的地方。HTTP 和 HTTPS 是 Web 通信的基础,Ingress 控制器和负载均衡器通常使用它们来公开应用。DNS 对于 Kubernetes 中的服务发现至关重要,它可以将人类可读的服务名称转换为 IP 地址。
IP 地址和 CIDR 表示法
您必须了解 IP 地址和 CIDR(无类别域间路由)表示法,因为 Kubernetes 网络模型广泛使用 IP 地址来实现所有组件之间的通信。CIDR 对于规划集群在 Google CloudVPC 网络中的 IP 地址分配至关重要。借助此功能,您可以为 Pod、Service 和节点定义 IP 地址块。例如,为 Pod 分配 10.10.0.0/16 会预留 65,536 个 IP 地址。适当的 CIDR 规划有助于防止集群扩缩时 IP 地址用尽的情况。
Linux 网络实用程序
GKE 使用底层 Linux 内核功能在集群内实现流量路由和负载均衡。您应该熟悉基本的 Linux 网络管理概念和实用程序,例如路由表和 iptables。传统上,kube-proxy(每个节点上的一个关键 Kubernetes 组件)会通过编程方式使用这些实用程序来拦截发往服务的流量,并将其重定向到某个后端 Pod。使用 GKE Dataplane V2 的新版 GKE 集群会使用 eBPF 替换 iptables,以提升性能和可观测性。
了解 Kubernetes 网络模型
Kubernetes 网络模型定义了容器化应用在集群内的通信方式。与侧重于虚拟机的传统模型不同,Kubernetes 强调基于 Pod 到 Pod 和 Service 的通信。此模型通过抽象化动态 Pod IP 地址的不可靠性,使应用联网更具可预测性。由于 Pod 是临时性的,并且可以随时使用新的 IP 地址重新创建,因此直接与 Pod IP 地址通信本质上是不稳定的。Kubernetes 通过将 Pod 分组到服务中来解决此问题。服务提供稳定的虚拟 IP 地址 (ClusterIP) 和一致的 DNS 名称,应用可以可靠地连接到这些地址和名称。此稳定端点与允许所有 Pod 直接通信而无需 NAT 的扁平网络相结合,为现代容器化应用奠定了坚实的基础。
Kubernetes 网络模型的关键原则
每个 Pod 都有唯一的 IP 地址:Kubernetes 集群中的每个 Pod 都有自己的 IP 地址,该地址由相应 Pod 中的所有容器共享。借助此唯一 IP 地址,Pod 可以像网络上的各个主机一样运行,类似于虚拟机。
无需 NAT 的扁平 Pod 到 Pod 通信:所有 Pod 都可以使用其 IP 地址直接相互通信,无论它们在哪个节点上运行。在 GKE 中,这种直接通信是通过使用 VPC 原生集群实现的,其中 Pod IP 地址是 VPC 网络中的别名 IP 地址。借助这些别名 IP 地址,Pod 可直接在 VPC 中路由,从而无需进行网络地址转换 (NAT),并简化了跨节点通信。
Service 提供稳定的端点:由于 Pod 是临时性的,并且可以随时使用新的 IP 地址重新创建,因此直接与 Pod IP 地址通信并不可靠。Kubernetes 服务通过将一组 Pod 分组并公开稳定的 IP 地址 (
ClusterIP) 和 DNS 名称来解决此问题。此问题抽象可实现对动态 Pod 集的一致访问。通过 DNS 进行内置服务发现:Kubernetes 包含一个内置 DNS 服务,可自动为服务分配 DNS 名称。应用可以使用这些名称(例如
my-service.my-namespace.svc.cluster.local)来可靠地定位其他服务并与之通信。集成式负载均衡。当客户端将流量发送到服务的
ClusterIP地址时,节点上的网络规则(由kube-proxy或 GKE Dataplane V2 编程)会拦截流量,并将其在相应服务中的所有运行状况良好的 Pod 之间进行负载均衡。这种分发在源处进行,因此效率很高,有助于确保高可用性。
总而言之,Kubernetes 网络模型将许多传统的网络复杂性抽象为一组更简单、更强大的容器化应用基本组件。通过实现直接 Pod 通信、稳定的服务端点以及集成的 DNS 和负载均衡,它为现代容器化应用提供了强大且可扩缩的基础。
GKE 与 Google Cloud 的关系
GKE 网络充当 Kubernetes 网络概念模型与 Google Cloud物理基础设施之间的桥梁:
Kubernetes 网络模型:Kubernetes 定义了规则,规定每个 Pod 都有自己的 IP 地址,从而实现直接的 Pod 到 Pod 通信,而无需 NAT。
Google Cloud 网络:这是底层基础架构,包括 VPC、子网、防火墙和负载均衡器。
GKE 网络:此连接层使用 Google Cloud的基础架构来实现 Kubernetes 模型。
容器网络接口 (CNI):GKE 在每个节点上使用 CNI 插件来处理 Pod IP 地址分配,并将 Pod 连接到节点的网络。
GKE 控制平面:这些组件会与Google Cloud 互动,以自动配置 Pod IP 范围的 VPC 路由、管理防火墙规则,并根据您的 Kubernetes 部署预配负载均衡器。
为什么 Google Cloud 网络知识对 GKE 至关重要
GKE 基于 Google Cloud网络基础设施构建。GKE 不会创建单独的网络层,而是使用现有的 Google Cloud 网络组件。因此,了解 Google Cloud 网络对于设计和保护 GKE 集群至关重要。
以下是 Google Cloud 网络基础知识至关重要的原因:
集群在 VPC 中运行:每个 GKE 集群都在 VPC 中运行。所有 IP 地址(包括节点、Pod 和 Service 的 IP 地址)都来自 VPC 子网中定义的 IP 地址范围。为了正确分配 IP 地址并避免用尽 IP 地址,您需要具备有关 VPC 和子网设计的实用知识。如需了解详情,请参阅 VPC 文档。
应用公开使用 Google Cloud 负载均衡器:当您使用 LoadBalancer Service 或 Ingress 将应用公开到集群外部时,GKE 会预配内置的 Google Cloud 负载均衡器。LoadBalancer 服务通常用于第 4 层流量,而 Ingress 用于第 7 层 HTTP(S) 流量。了解这些负载均衡器的工作方式有助于您管理外部流量、设置健康检查并有效排查连接问题。如需了解详情,请参阅 Cloud Load Balancing 文档。
通过 Google Cloud 防火墙规则强制执行安全性:GKE 会自动创建一些防火墙规则,以允许必要的集群流量。不过,要保护工作负载的安全,需要定义自定义 VPC 防火墙规则。错误配置可能会阻止关键流量,因此请务必了解这些规则的运作方式。如需了解详情,请参阅 Cloud Next Generation Firewall 文档。
后续步骤
- 如需深入了解架构,请阅读有关 GKE 网络的三大支柱的文章。
- 了解 GKE NetworkPolicy 和 Kubernetes 网络政策。
- 了解如何使用 Service 公开应用以及 Kubernetes Service 的概念。
- 了解 GKE 的 Ingress 和 Kubernetes Ingress。
- 深入了解 VPC 原生集群。
- 了解 GKE Dataplane V2 的优势。
- 排查 GKE 网络问题。