A-A+

K8s 集群对多个 Pod 和多个 Node，它们之间能够自动通信、发现和管理

2025年10月21日 15:23 学习笔记 暂无评论 共5063字 (阅读54 views次)

【注意：此文章为博主原创文章！转载需注意，请带原文链接，至少也要是txt格式！】

我们来系统地讲解一下：K8s 集群中确实可以有多个 Pod 和多个 Node，而且它们之间能够自动通信、发现和管理。

一、K8s 中确实存在多个 Pod 与 Node

在真实集群中：

  • 一个 Node（节点） 类似一台虚拟机或物理机；

  • 每个 Node 上可以运行多个 Pod；

  • 每个 Pod 可以包含一个或多个容器；

  • 集群中往往有几十甚至上千个 Node 与成千上万个 Pod。

✅ 这些 Pod 和 Node 都在一个虚拟化的“统一网络空间”中，通过 Kubernetes 网络模型 互相通信。

二、Pod 与 Node 的网络通信原理

K8s 通过 容器网络接口（CNI, Container Network Interface） 实现网络互通。
其核心目标是：

“每个 Pod 都有自己独立的 IP 地址，Pod 与 Pod（跨 Node）之间可以直接通信。”

1️⃣ 每个 Pod 都有一个独立的 IP（Pod IP）

  • 当 K8s 创建一个 Pod 时，CNI 插件（如 Flannel、Calico、Cilium）会给它分配一个 Pod IP。

  • 这个 IP 在整个集群内是唯一的（Cluster-wide Unique）。

  • Pod 内的容器共享同一个网络命名空间，也就是共享同一个 IP。

举例：

Node A
├─ Pod1: 10.244.1.5
└─ Pod2: 10.244.1.6

Node B
├─ Pod3: 10.244.2.3
└─ Pod4: 10.244.2.4

Pod1（在 Node A）可以直接 ping 通 Pod3（在 Node B），不需要 NAT。

2️⃣ Node 之间的通信（跨主机通信）

这是通过 CNI 网络插件 实现的。
不同插件的实现方式略有不同：

插件 通信机制
Flannel 通过 VXLAN 或 host-gw 封装二层网络数据包
Calico 基于 BGP 路由协议，直接在三层网络上通信
Cilium 使用 eBPF 内核级加速通信
Weave 使用自定义 Overlay 网络连接各 Node

这些插件确保不同 Node 上的 Pod 能像在同一局域网中通信一样直接连通。

3️⃣ Pod 之间如何发现彼此（Service Discovery）

直接使用 Pod IP 通信是不可靠的，因为：

  • Pod 可能会被销毁重建；

  • Pod IP 可能会变化。

因此 K8s 引入了 Service（服务抽象层）。

Service 的作用：

  • 给一组 Pod 提供一个稳定的虚拟 IP（ClusterIP）；

  • 自动负载均衡到后端多个 Pod；

  • 支持 DNS 名称解析（通过 CoreDNS）。

示例：

$ kubectl get svc
NAME    TYPE    CLUSTER-IP  PORT(S)
nginx-svc ClusterIP 10.96.0.1  80/TCP

→ 10.96.0.1 是虚拟的 ClusterIP
→ 实际上 Kube Proxy 会将请求转发给后端 Pod（例如 10.244.1.5、10.244.2.3）

DNS 发现机制：

CoreDNS 自动给 Service 注册域名：

nginx-svc.default.svc.cluster.local

Pod 通过该域名可自动解析到 Service 的 ClusterIP。

4️⃣ Node 与 Pod 的管理通信（Kubelet）

  • 每个 Node 上运行一个 Kubelet，它与控制平面中的 API Server 保持长连接。

  • 控制平面通过 Kubelet 下发调度与健康检查命令；

  • Node 定期汇报 Pod 状态。

流程：

Control Plane -> API Server -> Kubelet (on Node)
Kubelet -> Pod 管理容器生命周期

三、总结：Pod / Node 通信与发现的全景图

层级 通信方式 实现机制
Pod ↔ Pod（同 Node） 共享虚拟网桥 CNI 插件（如 Flannel、Calico）
Pod ↔ Pod（跨 Node） Overlay 或 BGP 路由 CNI 插件实现跨主机通信
Pod ↔ Service 虚拟 IP + DNS 解析 Kube Proxy + CoreDNS
Service ↔ 外部用户 NodePort / LoadBalancer / Ingress K8s 网络边界访问
Control Plane ↔ Node API 通信（HTTPS） Kubelet 定期汇报状态

四、视觉化总结（逻辑结构）

images

五、延伸阅读建议

如果你希望更深入理解：

  • 学习 CNI Plugin 原理（Flannel/Calico）

  • 了解 CoreDNS 与 Service DNS 解析流程

  • 掌握 Kube Proxy 的 IPVS / iptables 模式

是否希望我帮你画一张图，直观展示多 Node + 多 Pod 的通信拓扑结构（包含 Pod IP、Node 网络、Service 与 CoreDNS 的路径）？
那张图可以让你一眼看懂整个 Kubernetes 网络是如何连起来的。

images
ChatGPT 说：

太棒了！我按你图里的模块，一一解释它们在 多 Node 多 Pod 的 K8s 网络与服务发现 中各自负责什么、怎么协作。为了贴合你看图的路线，我从左到右、从上到下讲，并穿插关键数据流（控制流、DNS 流、东西向流量）。

控制平面（Control Plane）

API Server

  • 集群唯一入口：所有读写操作（kubectl/控制器/组件）都必须经过它。

  • 认证鉴权 + 准入控制：RBAC、Admission Webhook 等。

  • 状态读写：把对象（Deployment/Service/EndpointSlice 等）的期望状态写入 etcd，并对外提供查询接口。

Scheduler

  • 调度器：为“待调度”的 Pod 选择最合适的 Node。

  • 核心逻辑：过滤（可运行的节点集合）→ 评分（打分/优先级）→ 绑定（写回 API Server：Pod→Node）。

  • 考虑因素：资源（CPU/内存）、拓扑亲和/反亲和、污点/容忍、节点/Pod 亲和性、拓扑感知等。

Controller（Controller Manager）

  • 期望/实际状态对比与修复：比如 Deployment Controller 期望 5 个副本，它会确保底层 ReplicaSet/Pod 数量匹配；如果 Pod 挂了会触发重建。

  • 典型控制器：Deployment/ReplicaSet、Job/CronJob、Node、EndpointSlice、ServiceAccount 等。

备注：etcd 通常不画在“组件交互图”里，但它是 唯一真相源（SoT），保存集群状态。API Server 与 etcd 读写。

CoreDNS（DNS flow）

CoreDNS

  • 集群 DNS 服务：为 Service/Pod 提供域名解析。

  • Service 解析：my-svc.my-ns.svc.cluster.local → ClusterIP。

  • Pod 解析（可选）：“Pod 名字/Pod IP 反向解析”视配置而定。

  • 与 API Server 的关系：CoreDNS 监听 Service/EndpointSlice 变更，并更新内部解析记录（通常通过 kube-dns 插件或 API 方式）。

DNS flow（虚线）：Pod 在发起到 my-svc 的访问前，会先向 CoreDNS 解析域名 → 得到 ClusterIP → 交给 Service（再由 kube-proxy 转发到后端 Pod）。

Service（服务抽象层）

Service（ClusterIP / NodePort / LoadBalancer）

  • 稳定访问入口：屏蔽 Pod 的动态性（重建/漂移/IP 变化）。

  • 后端目标集合：由 EndpointSlice（或旧版 Endpoints）维护“真实后端 Pod IP + 端口”列表。

  • 负载均衡：请求分配到一个健康的后端 Pod。

  • 类型：

    • ClusterIP：只在集群内可达（默认）。

    • NodePort：在所有 Node 暴露端口，供外部访问。

    • LoadBalancer：由云厂商创建外部 LB，对外暴露公网/私网 VIP。

  • 与 kube-proxy 的关系：kube-proxy 监听 Service/EndpointSlice 变更，编程 iptables/IPVS/bpf 规则，完成 VIP→PodIP 转发。

Ingress（南北向入口）

Ingress（及其 Controller，如 NGINX/HAProxy/Traefik）

  • L7（HTTP/HTTPS）入口：按域名/路径把请求路由到不同 Service。

  • 典型链路：Client → Ingress LoadBalancer → Ingress Controller → Service（ClusterIP）→ 后端 Pod。

  • TLS 终止：常在 Ingress 层完成 HTTPS 证书卸载。

  • 多租户/多域名：适合大规模路由规则集中管理。

图中多个 Ingress 框表示可能的多层或多实例部署（边缘/集群内），或者不同命名空间、不同应用的入口。

External Client（外部客户端）

  • 集群外部访问者：浏览器/移动端/第三方系统。

  • 访问方式：通常走 Ingress/LoadBalancer/NodePort，再进入集群内部的 Service 与 Pod。

各 Node 内的组件

Kube-Proxy

  • 数据平面编程器：把 Service/EndpointSlice 变更同步为本机转发表（iptables/IPVS 或 eBPF）。

  • 作用：把访问 ClusterIP/NodePort 的流量，转发到某个后端 Pod IP:Port。

  • 模式：

    • iptables：基于内核 NAT 表规则。

    • IPVS：内核级虚拟服务更高性能的负载均衡。

    • eBPF（部分插件/发行版）：更灵活高效的内核态转发。

Kubelet

  • 节点代理：与 API Server 通信，拉取镜像、创建容器、上报状态、探针健康检查。

  • 生命周期管理：负责 Pod 的创建、销毁与健康探测（liveness/readiness/startup 探针）。

Pod（含 Pod IP）

  • 最小调度单元：一个或多个容器共享网络命名空间（同一 Pod IP、同一 localhost）。

  • Main Container / Sidecar：主业务 + 辅助功能（代理、日志、指标、mTLS 等）。

  • Pod IP：由 CNI 插件从节点或子网池中分配；在 整个集群内唯一。

CNI-Overlay routes（跨节点连通）

CNI（Flannel/Calico/Cilium/Weave …）

  • 目标：确保“Pod 与 Pod 不经 NAT 跨 Node 直连”。

  • 实现流派：

    • Overlay（如 Flannel VXLAN）：在三层网络上封装二层数据，实现跨主机二层虚拟网络。

    • 路由/BGP（Calico）：给每个 Pod 子网下发三层路由，Node 间按路由直达。

    • eBPF 数据平面（Cilium）：用 eBPF 加速与策略编排。

  • 在图中的位置：标注的 “CNI-Overlay routes” 表示 Node A ↔ Node C（以及其他节点）之间用于 Pod 跨节点通信 的隧道/路由。

east-west traffic（东西向流量）

  • 定义：集群内部服务之间的横向调用（Pod↔Pod，Service↔Service）。

  • 路径：通常 Pod →（DNS 解析）→ Service(ClusterIP) → kube-proxy/数据平面 → 后端 Pod。
    也可能通过 Service Mesh（如 Istio/Linkerd）Sidecar 做可观测性与 mTLS。

  • 与 north-south（南北向）：南北向是外部→集群（Ingress/LoadBalancer）。东西向是集群内服务互调。

把这张图串起来：典型访问与控制流

1）部署与管控（控制流）

  1. kubectl apply → API Server → 写入 etcd；

  2. Controller 发现差异 → 创建/删除底层对象；

  3. Scheduler 选择 Node → Kubelet 在对应节点拉镜像/建容器；

  4. Kube-Proxy 接收 Service/EndpointSlice 变更，编程转发规则。

2）内部服务调用（东西向数据流）

  1. Pod 访问 http://orders.default.svc → CoreDNS 解析 → 得到 ClusterIP；

  2. 流量到 Service（ClusterIP） → 经 kube-proxy（iptables/IPVS/eBPF）→ 命中某个后端 Pod IP；

  3. 如跨节点：走 CNI overlay/路由，到目标 Pod。

3）外部访问（南北向数据流）

  1. External Client → Ingress（LB/NodePort） → Ingress Controller；

  2. Ingress 基于域名/路径路由到 Service；

  3. 再由 kube-proxy 分发到后端 Pod。

常见疑问小结

  • 为什么不直接用 Pod IP？
    Pod 会重建、IP 会变；Service 提供稳定入口与负载均衡。

  • 多个 Node 如何保证 Pod 互通？
    由 CNI 插件 提供跨节点隧道/路由（Overlay/BGP/eBPF）。

  • Service 是真正的负载均衡器吗？
    ClusterIP 是虚拟 IP，本机由 kube-proxy 实现流量分配；对外暴露时通常由 云 LB/Ingress 提供四/七层 LB 能力。

布施恩德可便相知重

微信扫一扫打赏

支付宝扫一扫打赏

×

给我留言