k8s网络通信
k8s网络通信
K8s 网络通信的核心是解决Pod 间、Pod 与外部、Pod 内部三个层面的互联互通问题，其设计遵循 “每个 Pod 拥有独立 IP” 的原则，即 “IP-per-Pod”。
要理解 K8s 网络，关键是掌握它如何通过不同组件协作，实现上述三个层面的通信。
K8s 网络的核心通信场景
K8s 网络主要围绕以下 4 种场景设计，覆盖了从容器内部到集群外部的全链路。
Pod 内部通信同一 Pod 内的多个容器（如业务容器 + Sidecar 容器）共享一个网络命名空间（Network Namespace）。它们可通过
localhost直接通信，无需经过网络转发，性能等同于单机进程间通信。同一 Node 内的 Pod 通信每个 Node 会为其上的 Pod 分配一个独立的 “Pod IP”，并通过
cni0（CNI 插件创建的网桥）实现转发。流程：Pod1 → cni0 网桥 → Pod2，无需跨节点路由，延迟极低。跨 Node 的 Pod 通信这是 K8s 网络的核心难点，需解决 “不同 Node 上的 Pod IP 如何互通”。关键依赖CNI 网络插件（如 Calico、Flannel），通过以下方式实现：
Flannel：用 VXLAN/Host-GW 封装数据包，在 Node 间建立 “隧道” 转发。
Calico：基于 BGP 协议直接路由，无需封装，性能更高，还支持网络策略。
Pod 与外部网络通信外部网络（如用户浏览器、其他集群服务）无法直接访问 Pod IP（Pod IP 是集群内部地址，且 Pod 重建后 IP 会变化），需通过以下两种方式暴露服务：
Service（ClusterIP）：仅集群内部可访问，用于 Pod 间服务发现（如前端 Pod 访问后端 Pod）。
Service（NodePort/LoadBalancer）：将 Pod 服务暴露到集群外部，NodePort 通过 “Node IP + 固定端口” 访问，LoadBalancer 则依赖云厂商负载均衡器（如 AWS ELB、阿里云 SLB）。
关键网络组件解析
K8s 网络并非单一组件，而是由多个模块协同工作，核心组件包括 CNI 插件、Service 和 Ingress。
| 组件 | 核心作用 | 解决的问题 |
|---|---|---|
| CNI 插件 | 实现 Pod 网络的创建、IP 分配、跨 Node 路由 | Pod IP 分配、跨 Node Pod 通信 |
| Service | 为一组 Pod 提供 “固定访问地址” 和负载均衡 | Pod IP 动态变化、Pod 集群负载均衡 |
| Ingress | 管理外部访问的 HTTP/HTTPS 路由（七层负载） | 多 Service 共享域名、SSL 终结、路径路由 |
flannel网络插件
Flannel 是 K8s 中最常用的 CNI 网络插件之一，主打轻量、易部署，核心作用是解决跨 Node 的 Pod 通信问题，通过在集群 Node 间建立虚拟网络隧道，让不同 Node 上的 Pod 能像在同一局域网内一样互通。
Flannel 的核心原理
Flannel 的设计非常简洁，核心逻辑是：
为集群分配一个全局唯一的 Pod 子网段（如
10.244.0.0/16），并为每个 Node 分配一个子网段（如 Node1 分配10.244.1.0/24，Node2 分配10.244.2.0/24），确保 Pod IP 不会冲突。在每个 Node 上运行
flanneld
进程，负责：
与 K8s APIServer 通信，同步集群 Node 的子网信息（存储在
kube-system命名空间的configmap/flannel-config中）。在 Node 间建立数据转发隧道，将跨 Node 的 Pod 流量封装后通过主机网络传输。
Flannel 的常用后端（隧道模式）
Flannel 支持多种数据转发方式（后端），不同后端的性能和适用场景不同，最常用的两种是：
| 后端模式 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| VXLAN | 对 Pod 数据包进行 VXLAN 封装（加外层 UDP 头），通过 Node IP 跨节点传输 | 无需底层网络支持，兼容性强（跨云、跨网段均可） | 封装 / 解封装会消耗额外 CPU，性能中等 | 大多数通用场景（如混合云、跨网段集群） |
| Host-GW | 直接将其他 Node 的子网段路由指向对应 Node 的 IP（无需封装） | 无额外封装，性能接近原生网络 | 要求所有 Node |
Flannel 的网络流程（跨 Node 通信示例）
假设场景：
Node1（IP：192.168.1.10）上的 Pod1（IP：10.244.1.2）要访问 Node2（IP：192.168.1.11）上的 Pod2（IP：10.244.2.3）。
流程（VXLAN 后端）：
Pod1 发送数据包（目标 IP：10.244.2.3），通过
cni0网桥转发到 Node1 的主机网络。Node1 上的
flanneld进程通过路由表识别到目标 IP 属于 Node2 的子网，将数据包封装成 VXLAN 格式（外层源 IP：192.168.1.10，目标 IP：192.168.1.11）。封装后的数据包通过 Node1 的物理网卡发送到 Node2 的物理网卡。
Node2 上的
flanneld进程解封装 VXLAN 数据包，得到原始 Pod 数据包，通过cni0网桥转发到 Pod2。
Flannel 的局限性
不支持网络策略（NetworkPolicy）：无法限制 Pod 间的通信（如需网络隔离，需用 Calico 等插件）。
性能中等：VXLAN 模式的封装会带来额外开销，Host-GW 虽性能好但依赖底层网络。
功能简单：仅解决跨 Node 通信，无负载均衡、IPAM 高级配置等功能（需依赖 K8s Service）。
calico网络架构
Calico 是 K8s 中功能强大的 CNI 网络插件，以 “纯三层路由” 为核心设计理念，不仅能解决跨 Node 的 Pod 通信问题，还原生支持 网络策略（NetworkPolicy），适用于对网络性能、安全性有较高要求的场景（如生产环境、多租户集群）。
Calico 的核心架构组件
Calico 的架构由多个组件协同工作，覆盖网络路由、策略控制、配置管理等核心功能：
| 组件 | 作用 | 部署位置 |
|---|---|---|
| calico/node | 核心组件，运行在每个 Node 上，负责路由规则维护、BGP 协议交互、网络策略执行。 | 所有 Node（DaemonSet） |
| BGP 路由反射器 | 大型集群中，替代 Node 间全量 BGP 互联，减少网络复杂度（类似 “路由中枢”）。 | 可选（独立 Pod 或节点） |
| Felix | 运行在 calico/node 内部的代理，负责配置 Linux 内核的路由表、iptables 规则（实现网络策略）。 | 嵌入 calico/node |
| Typha | 优化 etcd 访问的代理（减少 calico/node 对 etcd 的直接请求，降低集群负载）。 | 大型集群建议部署 |
| etcd/ Kubernetes API | 存储 Calico 的网络配置（如 IP 池、BGP 配置、网络策略）。 | 复用 K8s 集群的 etcd 或 API |
Calico 的核心工作原理
1. 网络通信：基于 BGP 协议的三层路由
Calico 摒弃了 Flannel 的隧道封装（如 VXLAN），直接通过 BGP（边界网关协议） 实现跨 Node 的 Pod 通信，流程如下：
IP 分配：Calico 从预定义的 IP 池中为每个 Node 分配一段子网（如
10.244.1.0/24），Pod 启动时从 Node 子网中获取独立 IP。路由学习：每个 Node 上的
calico/node进程作为 BGP 客户端，通过 BGP 协议向其他 Node 广播 “本机 Pod 子网” 与 “本机 IP” 的对应关系（如 “10.244.1.0/24 可通过 192.168.1.10 访问”）。跨 Node 通信：当 Pod1（Node1 上）访问 Pod2（Node2 上）时，数据包通过 Node1 的路由表直接转发到 Node2 的物理网卡（无封装），再由 Node2 转发到 Pod2，性能接近原生网络。
注：小规模集群中，Node 间直接建立 BGP 连接（全互联模式）；大规模集群（超过 100 节点）需部署 BGP 路由反射器，避免 “N²” 连接复杂度。
2. 网络策略：基于 iptables 的精细化控制
Calico 是 K8s 中网络策略的主流实现，通过 Felix 组件在每个 Node 上配置 iptables 规则，实现对 Pod 进出流量的精确限制：
策略规则：支持基于 Pod 标签、命名空间、IP 地址、端口、协议（TCP/UDP/ICMP）等维度定义规则（如 “仅允许 frontend 命名空间的 Pod 访问 backend 命名空间的 8080 端口”）。
执行逻辑：当 Pod 流量经过 Node 的网络栈时，Felix 配置的 iptables 链会拦截并匹配策略规则，允许或拒绝流量通过。
优势：相比其他插件，Calico 策略支持更复杂的规则组合（如多条件逻辑、端口范围、IP 段），且性能损耗低。
Calico 的部署模式
Calico 支持两种主要部署模式，适应不同网络环境：
| 模式 | 原理 | 适用场景 |
|---|---|---|
| BGP 模式（纯路由） | 依赖 BGP 协议路由 Pod 流量，无封装，性能最优。 | 所有 Node 处于同一三层网络（可路由），如物理机集群、同 VPC 内的虚拟机。 |
| IPIP 模式（隧道） | 对跨子网的 Pod 流量进行 IPIP 封装（外层 IP 为 Node IP），解决跨二层网络通信。 | Node 分布在不同子网（如跨机房、混合云），底层网络不支持 BGP 路由。 |
Calico 与 Flannel 的核心差异
| 特性 | Calico | Flannel |
|---|---|---|
| 通信方式 | BGP 路由（无封装）或 IPIP 隧道 | VXLAN 隧道或 Host-GW |
| 网络策略 | 原生支持（功能丰富） | 不支持 |
| 性能 | 更高（BGP 模式无封装损耗） | 中等（VXLAN 有封装损耗） |
| 适用规模 | 支持大规模集群（需路由反射器） | 适合中小规模集群 |
| 部署复杂度 | 稍高（需配置 BGP/IPIP 模式） | 简单（一键部署） |
1.3.3 部署calico
删除flannel插件
[root@k8s-master ~]# kubectl delete -f kube-flannel.yml删除所有节点上flannel配置文件,避免冲突
[root@k8s-master & node1-2 ~]# rm -rf /etc/cni/net.d/10-flannel.conflist下载部署文件
[root@k8s-master calico]# curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico-typha.yaml -o calico.yaml下载镜像上传至仓库：
[root@k8s-master ~]# docker pull docker.io/calico/cni:v3.28.1[root@k8s-master ~]# docker pull docker.io/calico/node:v3.28.1[root@k8s-master ~]# docker pull docker.io/calico/kube-controllers:v3.28.1[root@k8s-master ~]# docker pull docker.io/calico/typha:v3.28.1更改yml设置
[root@k8s-master calico]# vim calico.yaml4835 image: calico/cni:v3.28.14835 image: calico/cni:v3.28.14906 image: calico/node:v3.28.14932 image: calico/node:v3.28.15160 image: calico/kube-controllers:v3.28.15249 - image: calico/typha:v3.28.14970 - name: CALICO_IPV4POOL_IPIP4971 value: "Never"4999 - name: CALICO_IPV4POOL_CIDR5000 value: "10.244.0.0/16"5001 - name: CALICO_AUTODETECTION_METHOD5002 value: "interface=eth0"[root@k8s-master calico]# kubectl apply -f calico.yaml[root@k8s-master calico]# kubectl -n kube-system get podsNAME READY STATUS RESTARTS AGEcalico-kube-controllers-6849cb478c-g5h5p 1/1 Running 0 75scalico-node-dzzjp 1/1 Running 0 75scalico-node-ltz7n 1/1 Running 0 75scalico-node-wzdnq 1/1 Running 0 75scalico-typha-fff9df85f-vm5ks 1/1 Running 0 75scoredns-647dc95897-nchjr 1/1 Running 1 (139m ago) 4d7hcoredns-647dc95897-wjbg2 1/1 Running 1 (139m ago) 4d7hetcd-k8s-master 1/1 Running 1 (139m ago) 4d7hkube-apiserver-k8s-master 1/1 Running 1 (139m ago) 3d10hkube-controller-manager-k8s-master 1/1 Running 3 (139m ago) 4d7hkube-proxy-9g5z2 1/1 Running 1 (139m ago) 3d10hkube-proxy-cd5wk 1/1 Running 1 (139m ago) 3d10hkube-proxy-mvq4c 1/1 Running 1 (139m ago) 3d10hkube-scheduler-k8s-master 1/1 Running 3 (139m ago) 4d7h测试：
[root@k8s-master calico]# kubectl run web --image myapp:v1pod/web created[root@k8s-master calico]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESweb 1/1 Running 0 5s 10.244.169.129 k8s-node2 <none> <none>[root@k8s-master calico]# curl 10.244.169.129Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>