当前位置：首页 > news >正文

在K8S中，网络通信模式有哪些？

news 2025/9/24 11:59:50

好的，这是一个非常核心的问题。Kubernetes 的网络模型是一个复杂的体系，但我们可以将其分解为几个清晰的层次来理解。

Kubernetes 网络通信模式可以分为四大类，下图清晰地展示了这四类通信的全景：

    A[Kubernetes 网络通信] --> A1[容器间通信]A --> A2[Pod 间通信]A --> A3[Pod 与 Service 通信]A --> A4[外部流量接入]A1 --> A1_1[同一 Pod 内共享网络命名空间<br>通过 localhost 直接通信]A2 --> A2_1[跨节点 Pod 通信<br>依赖 CNI 网络插件实现]A2 --> A2_2[同一节点 Pod 通信<br>通常通过网桥]A3 --> A3_1[ClusterIP]A3 --> A3_2[NodePort]A3 --> A3_3[LoadBalancer]A3 --> A3_4[ExternalName]A4 --> A4_1[Ingress]A4 --> A4_2[Gateway API]

下面我们详细解析每一种模式。

模式一：容器间通信（同一 Pod 内）

这是最简单的一种模式。

原理：Pod 是 K8S 的最小调度单元，一个 Pod 内的所有容器共享同一个网络命名空间。这意味着它们共享同一个 IP 地址、端口空间，并且可以通过 localhost 直接访问对方。
通信方式：直接通过 localhost 和端口号进行通信。
示例：一个 Pod 包含一个主应用容器（监听 8080 端口）和一个日志收集 Sidecar 容器。Sidecar 可以直接通过 localhost:8080 访问主应用。
关键点：无需任何额外的网络配置，由 K8S 底层容器运行时（如 Docker、containerd）自动保证。

模式二：Pod 与 Pod 间通信

这是 K8S 网络模型的核心，也是容器网络接口（CNI） 插件主要解决的问题。K8S 本身不提供网络实现，只制定规则，具体实现由 CNI 插件完成。

核心要求（K8S 网络模型）：
1. 所有 Pod 都可以在不使用网络地址转换（NAT）的情况下与所有其他 Pod 通信。
2. 每个 Pod 都有一个独立的、唯一的 IP 地址（Pod IP），这个 IP 地址本身可以被其他 Pod 直接访问。
子模式 2.1：同一节点上的 Pod 间通信
- 原理：通常由节点上的一个虚拟网桥（如 docker0、cni0）实现。Pod 的虚拟网络设备（veth pair）一端在 Pod 内，另一端连接到网桥上。网桥充当一个虚拟交换机，转发同一网段内的流量。
- 通信方式：通过网桥直接进行二层通信。
子模式 2.2：不同节点上的 Pod 间通信
- 原理：这是 CNI 插件大显身手的地方。不同插件有不同的实现方式，但目标都是建立一个覆盖网络 或利用底层云网络，使不同节点上的 Pod 看起来在同一个大网络中。
- 常见实现技术：
  - Overlay 网络（如 Flannel 的 VXLAN、Calico 的 IPIP 模式）：将 Pod 的网络数据包封装在节点的网络数据包中进行传输。适用于任何底层网络环境。
  - 纯三层路由（如 Calico 的 BGP 模式）：要求底层网络支持路由，每个节点作为一个路由器，通过 BGP 协议交换路由信息，告知其他节点“来我这里的 Pod 的网段，请发给我”。
  - 云提供商集成（如 AWS VPC CNI）：直接为每个 Pod 分配一个云 VPC 中的真实 IP 地址，性能最好，但受限于云厂商和 IP 地址数量。

模式三：Pod 与 Service 通信

Pod 是短暂的，它们的 IP 地址会随着重启、调度而变化。Service 提供了一个稳定的网络端点（固定 IP 和 DNS 名称）来访问一组动态变化的 Pod（由 Label Selector 控制）。

原理：Service 的 IP（ClusterIP）是一个虚拟 IP，它不会绑定在任何网络接口上。当 Pod 访问这个 VIP 时，工作节点上的 kube-proxy 组件会介入，负责将流量负载均衡到后端的健康 Pod。
kube-proxy 的三种实现模式（决定了具体的流量转发方式）：
1. userspace 模式（已废弃）：流量需要从内核空间转到用户空间的 kube-proxy 进程，再由它转发，性能差。
2. iptables 模式（长期默认）：kube-proxy 直接配置 iptables 规则，实现 NAT 和负载均衡。全程在内核态完成，性能好。但当 Service 数量巨大时，iptables 规则链过长会影响性能。
3. IPVS 模式（生产推荐）：使用 Linux 内核的 IPVS（IP Virtual Server）模块，专为负载均衡设计。它使用哈希表，即使有上万个 Service，性能也几乎无损，并支持更丰富的负载均衡算法（如 rr, lc, dh等）。
Service 的类型：
- ClusterIP：默认类型，仅在集群内部可访问。
- NodePort：在 ClusterIP 基础上，在每个节点上开放一个静态端口（如 30000-32767）。访问任何节点的这个端口，流量都会被转发到 Service。
- LoadBalancer：在 NodePort 基础上，与云提供商集成，自动创建一个外部负载均衡器，将外部流量引导到 Service。
- ExternalName：通过返回一个 CNAME 记录，将 Service 映射到外部域名。

模式四：外部流量接入集群

这是将集群内服务暴露给公网或外部网络访问的模式。

方式 4.1：NodePort / LoadBalancer
- 如上所述，这两种 Service 类型可以直接暴露服务，但通常用于暴露粗粒度的服务。
方式 4.2：Ingress（最重要的方式）
- 原理：Ingress 不是一种 Service，而是一个 API 对象，它充当集群的“智能路由入口”或“七层负载均衡器”。它基于 HTTP/HTTPS 主机名和路径规则，将外部流量路由到集群内部相应的 Service。
- 关键：Ingress 本身需要 Ingress Controller 才能工作。Ingress Controller 是一个实际运行在集群中的 Pod（如 Nginx Ingress Controller、Traefik、HAProxy），它监听 Ingress 规则的变化，并动态配置其内部的负载均衡器。
- 示例：www.example.com/api 的流量被路由到 api-service，www.example.com/web 的流量被路由到 web-service。它还负责处理 TLS 终止。
方式 4.3：Gateway API（Ingress 的演进）
- 这是 K8S SIG-NETWORK 社区推出的新一代官方标准，旨在弥补 Ingress 在灵活性、表达能力和角色分离方面的不足。它更强大，是未来的趋势。

总结与对比

通信模式	核心组件	关键特点
容器间通信	Pod 网络命名空间	`localhost` 直连，最简单
Pod 与 Pod 通信	CNI 网络插件（如 Calico, Flannel）	扁平的 Pod IP 网络，无 NAT
Pod 与 Service 通信	Service + kube-proxy	虚拟 IP（ClusterIP），负载均衡，服务发现
外部流量接入	Ingress Controller / Gateway API	七层路由、基于主机名和路径、TLS 终止