一、K8s 网络模型核心原则1.1 四大基本要求Kubernetes 对网络实现有以下核心要求每个 Pod 拥有独立 IP无论 Pod 在哪个节点上都有唯一的 IP 地址Pod 间可以直接通信不需要 NAT网络地址转换直接使用对方 IP节点上的 agentkubelet可以与该节点上的所有 Pod 通信非容器化的节点进程可以与 Pod 通信┌─────────────────────────────────────────────────────────────────────┐ │ Kubernetes 集群网络 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ Node 1 (192.168.1.101) Node 2 (192.168.1.102) │ │ ┌─────────────────────┐ ┌─────────────────────┐ │ │ │ ┌───────┐ ┌───────┐│ │┌───────┐ ┌───────┐ │ │ │ │ │Pod A │ │Pod B ││ ││Pod C │ │Pod D │ │ │ │ │ │10.244.│ │10.244.││ ││10.244.│ │10.244.│ │ │ │ │ │1.10 │ │1.11 ││ ││2.10 │ │2.11 │ │ │ │ │ └───┬───┘ └───┬───┘│ │└───┬───┘ └───┬───┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │ │ │ │ cni0 │ │ │ │ cni0 │ │ │ │ │ │ (bridge)│ │ │ │ (bridge)│ │ │ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │ └───────────┼─────────┘ └─────────┼────────────┘ │ │ │ │ │ │ └──────────────┬──────────────────┘ │ │ │ │ │ ┌──────┴──────┐ │ │ │ 物理网络 │ │ │ │ (Underlay) │ │ │ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ 通信规则 ✓ Pod A (10.244.1.10) ←→ Pod B (10.244.1.11) [同节点通过网桥] ✓ Pod A (10.244.1.10) ←→ Pod C (10.244.2.10) [跨节点通过路由/overlay] ✓ Pod A (10.244.1.10) ←→ Node 2 (192.168.1.102) [Pod与节点通信]二、Pod 网络实现原理2.1 Pause 容器与网络命名空间每个 Pod 启动时首先会创建一个Pause 容器基础设施容器它的作用是占用并维护一个独立的网络命名空间Network Namespace为 Pod 分配 IP 地址Pod 内的所有业务容器共享 Pause 容器的网络命名空间为什么需要 Pause 容器Linux 的网络命名空间Network Namespace是跟随进程生命周期的——当命名空间里的最后一个进程退出时内核会销毁这个命名空间IP 地址、路由表、iptables 规则全部丢失。这就带来一个问题如果 Pod 里的业务容器比如 nginx直接持有网络命名空间当 nginx 崩溃重启时命名空间会被销毁重建IP 就变了。其他 Pod 通过旧 IP 发的请求全部失败。Pause 容器就是解决这个问题的——它是一个极简的、永远不会退出的进程就一个pause()系统调用专门用来占住网络命名空间类比Pause 容器就像租房合同上的承租人——房子网络命名空间是以他的名义租的。室友业务容器可以搬进搬出但只要承租人不退租房子就一直在地址也不会变。2.2 veth pair 与网桥连接Pod 通过veth pair虚拟以太网对连接到节点上的网桥通常是cni0┌──────────────────────────────────────────────────────────────────┐ │ Node 1 网络结构 │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Pod A │ │ Pod B │ │ │ │ │ │ │ │ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │ │ │ eth0 │ │ │ │ eth0 │ │ │ │ │ │10.244.1.10│ │ │ │10.244.1.11│ │ │ │ │ └─────┬─────┘ │ │ └─────┬─────┘ │ │ │ └────────┼─────────┘ └────────┼─────────┘ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ │ │ │ veth-A │ │ veth-B │ │ │ │ (peer) │ │ (peer) │ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ └──────────┬─────────────────┘ │ │ │ │ │ ┌──────┴──────┐ │ │ │ cni0 │ │ │ │ (bridge) │ │ │ │ 10.244.1.1 │ │ │ └──────┬──────┘ │ │ │ │ │ ┌──────┴──────┐ │ │ │ ens192 │ ← 物理网卡 │ │ │192.168.1.101│ │ │ └─────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘2.3 同节点 Pod 通信流程# 在 Pod A 中 ping Pod B同节点 kubectl exec pod-a -- ping 10.244.1.11 # 通信流程 # 1. Pod A 发送数据包到 10.244.1.11 # 2. 数据包从 Pod A 的 eth0 出发经过 veth pair 到达 cni0 网桥 # 3. cni0 网桥查询 FDBForwarding Database找到目标端口 # 4. 数据包从 cni0 转发到 veth-B进入 Pod B 的 eth02.4 跨节点 Pod 通信流程跨节点通信需要 CNI 插件实现有两种主要模式模式 1Overlay覆盖网络如 Flannel VXLAN、Calico IPIPNode 1 (192.168.1.101) Node 2 (192.168.1.102) ┌──────────────────────┐ ┌──────────────────────┐ │ Pod A (10.244.1.10) │ │ Pod C (10.244.2.10) │ │ │ │ │ │ │ │ cni0 (bridge) │ │ cni0 (bridge) │ │ │ │ │ │ │ │ vxlan/flannel.1 │ │ vxlan/flannel.1 │ │ │ │ │ │ │ └──────┼───────────────┘ └───────┼──────────────┘ │ │ │ 封装原始包 → UDP/VXLAN 封装 │ │ ┌────────────────────┐ │ └────────→│ 物理网络 │──────────→┘ │ (192.168.1.0/24) │ └────────────────────┘ 数据包封装过程 原始包src10.244.1.10 dst10.244.2.10 ↓ VXLAN 封装外层 src192.168.1.101 dst192.168.1.102 ↓ 物理网络传输 ↓ 解封装恢复原始包模式 2Routing路由模式如 Calico BGP# 查看节点路由表 ip route show # 输出示例 # 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 # 10.244.2.0/24 via 192.168.1.102 dev ens192 # 到 Node 2 的路由 # 10.244.3.0/24 via 192.168.1.103 dev ens192 # 到 Node 3 的路由 # 跨节点通信流程 # 1. Pod A 发送数据包到 10.244.2.10 # 2. Node 1 查询路由表发现目标在 Node 2 (192.168.1.102) # 3. 数据包直接路由到 Node 2无需封装 # 4. Node 2 收到包后通过 cni0 网桥转发到 Pod C三、Service 网络原理3.1 kube-proxy 的三种工作模式模式 1userspace已淘汰kube-proxy 在用户空间监听 Service 和 Endpoints所有流量都经过 kube-proxy 进程性能差已废弃模式 2iptables默认模式iptables 模式流量路径 ┌─────────────┐ │ Pod A │ │ 访问 nginx │ │ Service │ └──────┬──────┘ │ ↓ ┌─────────────────────────────────────────────┐ │ PREROUTING/OUTPUT (nat) │ │ ↓ │ │ KUBE-SERVICES 链 │ │ ↓ (匹配 dport80, dst10.96.0.100) │ │ KUBE-SVC-XXX 链 │ │ ↓ (随机选择probability0.5) │ │ KUBE-SEP-XXX 链每个 Endpoint 一个 │ │ ↓ │ │ DNAT: 10.96.0.100:80 → 10.244.1.10:80 │ └──────┬──────────────────────────────────────┘ │ ↓ ┌─────────────┐ │ Pod B │ │ 10.244.1.10 │ │ :80 │ └─────────────┘ 问题规则数量 O(N)N 为 Service/Endpoint 数量 线性查找性能随规模下降模式 3IPVS推荐大规模集群# 启用 IPVS 模式 # 修改 kube-proxy ConfigMap kubectl edit cm kube-proxy -n kube-system # 修改 # mode: ipvs # 重启 kube-proxy kubectl delete pod -n kube-system -l k8s-appkube-proxy # 查看 IPVS 规则 ipvsadm -ln # 示例输出 # IP Virtual Server version 1.2.1 (size4096) # Prot LocalAddress:Port Scheduler Flags # - RemoteAddress:Port Forward Weight MasqPort LibInc # TCP 10.96.0.1:443 rr # - 192.168.1.101:6443 Masq 1 0 0 # - 192.168.1.102:6443 Masq 1 0 0 # - 192.168.1.103:6443 Masq 1 0 0 # TCP 10.96.0.10:53 rr # - 10.244.1.5:53 Masq 1 0 0 # TCP 10.96.0.100:80 rr # - 10.244.1.10:80 Masq 1 0 0 # - 10.244.2.10:80 Masq 1 0 0IPVS vs iptables 对比 iptables - 规则匹配O(N) 线性遍历 - 1000 个 Service → 1000 条规则依次匹配 - 大规模集群性能差 IPVS - 规则匹配O(1) 哈希表查找 - 1000 个 Service → 哈希表直接定位 - 大规模集群性能稳定 - 支持更多负载均衡算法rr, wrr, lc, wlc, sh, sed, nq3.2 DNS 解析流程# 在 Pod 中解析 Service kubectl exec pod-a -- nslookup nginx # 输出 # Server: 10.96.0.10 # Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local # # Name: nginx # Address 1: 10.96.0.100 nginx.default.svc.cluster.localDNS 解析流程 ┌─────────┐ │ Pod A │ │ nslookup│ │ nginx │ └────┬────┘ │ 1. 查询 DNS: 10.96.0.10 (CoreDNS Service) ↓ ┌──────────────────────────────────────┐ │ iptables/IPVS 规则 │ │ DNAT: 10.96.0.10:53 → Pod IP │ └────┬─────────────────────────────────┘ │ 2. 负载均衡到 CoreDNS Pod ↓ ┌─────────────────┐ │ CoreDNS │ │ 10.244.1.5 │ └────┬────────────┘ │ 3. 查询 K8s API获取 nginx Service 的 ClusterIP ↓ 返回10.96.0.100 │ ↓ ┌─────────┐ │ Pod A │ │ 获得 │ │ nginx │ │ IP │ └────┬────┘ │ 4. 访问 10.96.0.100:80 ↓ ┌──────────────────────────────────────┐ │ iptables/IPVS 规则 │ │ DNAT: 10.96.0.100:80 → Pod IP │ │ 负载均衡到后端 Pod │ └────┬─────────────────────────────────┘ │ ↓ ┌─────────────┐ │ nginx Pod │ │ 10.244.1.10 │ └─────────────┘四、CNI 插件工作机制4.1 CNI 接口规范CNIContainer Network Interface是 Kubernetes 定义的标准网络接口规范kubelet 调用 CNI 插件的流程 ┌─────────┐ │ kubelet │ │创建 Pod │ └────┬────┘ │ 1. 创建 Pause 容器网络命名空间 ↓ ┌─────────────────┐ │ Container │ │ Runtime │ │ (containerd) │ └────┬────────────┘ │ 2. 调用 CNI 插件 ↓ ┌─────────────────────────────────────────┐ │ CNI Plugin │ │ /opt/cni/bin/flannel / calico / cilium │ └────┬────────────────────────────────────┘ │ 3. 读取配置 ↓ ┌─────────────────────────────────────────┐ │ CNI Config │ │ /etc/cni/net.d/10-flannel.conflist │ └────┬────────────────────────────────────┘ │ 4. 配置网络 ↓ ┌─────────────────────────────────────────┐ │ 网络设置 │ │ - 创建 veth pair │ │ - 配置 IP 地址 │ │ - 添加路由规则 │ │ - 配置 NAT如需要 │ └────┬────────────────────────────────────┘ │ 5. 返回结果 ↓ ┌─────────┐ │ kubelet │ │ Pod 网络│ │ 就绪 │ └─────────┘4.2 CNI 配置文件rootk8s-master-01:~# cd /etc/cni/net.d/ rootk8s-master-01:/etc/cni/net.d# ls 10-calico.conflist calico-kubeconfig rootk8s-master-01:/etc/cni/net.d# rootk8s-master-01:/etc/cni/net.d# cat 10-calico.conflist { name: k8s-pod-network, cniVersion: 0.3.1, plugins: [{container_settings:{allow_ip_forwarding:false},datastore_type:kubernetes,endpoint_status_dir:/var/run/calico/endpoint-status,ipam:{assign_ipv4:true,assign_ipv6:false,type:calico-ipam},kubernetes:{k8s_api_root:https://10.96.0.1:443,kubeconfig:/etc/cni/net.d/calico-kubeconfig},log_file_max_age:30,log_file_max_count:10,log_file_max_size:100,log_file_path:/var/log/calico/cni/cni.log,log_level:Info,mtu:0,nodename_file_optional:false,policy:{type:k8s},policy_setup_timeout_seconds:0,type:calico},{capabilities:{bandwidth:true},type:bandwidth},{capabilities:{portMappings:true},snat:true,type:portmap}] }4.3 CNI 插件二进制文件rootk8s-master-01:~# ls /opt/cni/bin/ bandwidth calico dhcp firewall host-device ipvlan loopback portmap README.md static tuning vrf bridge calico-ipam dummy flannel host-local LICENSE macvlan ptp sbr tap vlan # 常见插件 # flannel - Flannel CNI 插件 # calico - Calico CNI 插件 # cilium - Cilium CNI 插件 # bridge - 网桥插件 # loopback - 回环接口 # portmap - 端口映射 # bandwidth - 带宽限制五、Calico 部署详解5.1 Calico 架构Calico 核心组件 ┌────────────────────────────────────────────────────────┐ │ Calico 架构 │ ├────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ Felix │ │ BIRD │ │ confd │ │ │ │ │ │ │ │ │ │ │ │ - 编程路由 │ │ - BGP 路由 │ │ - 配置渲染 │ │ │ │ - ACL 规则 │ │ 分发 │ │ - 健康检查 │ │ │ │ - 状态报告 │ │ │ │ │ │ │ └──────┬───────┘ └──────┬───────┘ └─────┬──────┘ │ │ │ │ │ │ │ └─────────────────┼────────────────┘ │ │ │ │ │ ┌──────┴──────┐ │ │ │ Datastore │ │ │ │ │ │ │ │ - etcd │ │ │ │ - K8s API │ │ │ └─────────────┘ │ │ │ └────────────────────────────────────────────────────────┘5.2 数据平面模式模式 1IPIPOverlay# 启用 IPIP 模式 # 修改 calico.yaml 中的 CALICO_IPV4POOL_IPIP: Always # 特点 # - 使用 IPIP 封装IP in IP # - 适用于不同子网的节点 # - 有封装开销约 20 字节头部 # - 需要设置 MTU通常 1480模式 2BGPUnderlay推荐# 启用 BGP 模式 # 修改 calico.yaml # - CALICO_IPV4POOL_IPIP: Never # - CALICO_IPV4POOL_VXLAN: Never # 特点 # - 无封装直接路由 # - 性能更好无封装开销 # - 需要物理网络支持 BGP 或允许路由传播 # - 适合扁平网络所有节点在同一二层5.3 部署步骤# 1. 下载 Calico manifest wget https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml # 2. 可选修改 Pod 网段 # 确保与 kubeadm init --pod-network-cidr 一致 sed -i s/192.168.0.0\/16/10.244.0.0\/16/g calico.yaml # 3. 应用 Calico kubectl apply -f calico.yaml # 4. 验证 Pod 运行 kubectl get pods -n kube-system | grep calico # 期望输出 # calico-kube-controllers-6d58d4c8fd-abc12 1/1 Running 0 5m # calico-node-xyz12 1/1 Running 0 5m # calico-node-xyz34 1/1 Running 0 5m # calico-node-xyz56 1/1 Running 0 5m # calico-node-xyz78 1/1 Running 0 5m # calico-node-xyz90 1/1 Running 0 5m # calico-node-xyz99 1/1 Running 0 5m # 5. 验证节点 BGP 状态需要 calicoctl # 下载 calicoctl wget https://github.com/projectcalico/calico/releases/download/v3.26.1/calicoctl-linux-amd64 chmod x calicoctl-linux-amd64 mv calicoctl-linux-amd64 /usr/local/bin/calicoctl # 查看节点状态 calicoctl node status # 期望输出 # Calico process is running. # # IPv4 BGP status # --------------------------------------------------------------- | NODE NAME | PEER ADDRESS | PEER TYPE| STATE | SINCE | # --------------------------------------------------------------- # | node1 | 192.168.1.102 | node | up | 10:05:00 | # | node1 | 192.168.1.103 | node | up | 10:05:00 | # | node1 | 192.168.1.104 | node | up | 10:05:00 | # --------------------------------------------------------------- # 6. 验证 Pod 网络跨节点 ping 测试 # 在 node1 创建测试 Pod kubectl run test1 --imagebusybox --command -- sleep 3600 kubectl exec test1 -- ip addr show # 在 node2 创建测试 Pod kubectl run test2 --imagebusybox --command -- sleep 3600 --overrides{spec:{nodeName:node2}} kubectl exec test2 -- ip addr show # 跨节点 ping kubectl exec test1 -- ping -c 3 $(kubectl get pod test2 -o jsonpath{.status.podIP}) # 期望输出 # PING 10.244.2.10 (10.244.2.10): 56 data bytes # 64 bytes from 10.244.2.10: seq0 ttl62 time1.234 ms # 64 bytes from 10.244.2.10: seq1 ttl62 time0.987 ms # 64 bytes from 10.244.2.10: seq2 ttl62 time1.056 ms5.4 关键配置参数# calico.yaml 中的关键配置 # 1. Pod 网段必须与 kubeadm --pod-network-cidr 一致 - name: CALICO_IPV4POOL_CIDR value: 10.244.0.0/16 # 2. IPIP 模式 - name: CALICO_IPV4POOL_IPIP value: Always # 所有流量都使用 IPIP 封装 # value: CrossSubnet # 仅跨子网流量使用 IPIP # value: Never # 不使用 IPIP纯 BGP # 3. MTU 设置IPIP 模式需要减小 MTU - name: FELIX_IPINIPMTU value: 1480 # 标准 MTU 1500 - 20IPIP 头部 # 4. 日志级别 - name: FELIX_LOGSEVERITYSCREEN value: info # info/warning/error/debug5.5 NetworkPolicy 示例# network-policy.yaml # 限制 default 命名空间的 Pod 只能访问同命名空间的 Pod apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-except-same-namespace namespace: default spec: podSelector: {} # 匹配所有 Pod policyTypes: - Egress egress: - to: - podSelector: {} # 允许访问同命名空间的 Pod - to: - namespaceSelector: matchLabels: name: kube-system # 允许访问 kube-systemDNS ports: - protocol: UDP port: 53 # DNS --- # 只允许特定标签的 Pod 访问 nginx apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-nginx namespace: default spec: podSelector: matchLabels: app: nginx # 应用于 nginx Pod policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend # 只允许 frontend 标签的 Pod ports: - protocol: TCP port: 80# 应用 NetworkPolicy kubectl apply -f network-policy.yaml # 查看 NetworkPolicy kubectl get networkpolicy # 验证策略生效 # 创建测试 Pod无 frontend 标签 kubectl run test-no-label --imagebusybox --command -- sleep 3600 kubectl exec test-no-label -- wget -T 5 http://nginx # 应该失败 # 创建测试 Pod有 frontend 标签 kubectl run test-frontend --imagebusybox --labelsrolefrontend --command -- sleep 3600 kubectl exec test-frontend -- wget -T 5 http://nginx # 应该成功六、Cilium 部署详解6.1 Cilium 架构Cilium 核心组件eBPF-based ┌────────────────────────────────────────────────────────┐ │ Cilium 架构 │ ├────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ Cilium Agent │ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ │ │ eBPF Data │ │ Policy │ │ │ │ │ │ Path │ │ Engine │ │ │ │ │ │ │ │ │ │ │ │ │ │ - Socket │ │ - L3-L7 │ │ │ │ │ │ - XDP │ │ - Identity │ │ │ │ │ │ - TC │ │ based │ │ │ │ │ └────────────┘ └────────────┘ │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ Cilium Operator │ │ │ │ │ │ │ │ - IPAMIP 地址管理 │ │ │ │ - CRD 管理CiliumNetworkPolicy 等 │ │ │ │ - 集群同步 │ │ │ └──────────────────────────────────────────────┘ │ │ │ └────────────────────────────────────────────────────────┘ eBPF 优势 - 内核级数据包处理性能极高 - 无需 iptables/IPVS减少规则遍历 - 支持 L3-L7 策略HTTP、gRPC 等 - 可编程灵活性高6.2 Cilium vs Calico 对比特性CiliumCalico数据平面eBPFiptables/IPVS性能极高内核级高iptables 有线性开销L7 策略原生支持HTTP/gRPC需要额外组件服务网格集成原生支持需要 Istio 等学习曲线较陡需了解 eBPF相对平缓社区活跃度高Cloud Native 热门高成熟稳定适用场景大规模、高性能、L7 策略通用场景、企业级6.3 部署步骤Helm# 1. 添加 Cilium Helm 仓库 helm repo add cilium https://helm.cilium.io/ helm repo update # 2. 安装 Cilium helm install cilium cilium/cilium --namespace kube-system \ --set kubeProxyReplacementtrue \ --set k8sServiceHost192.168.1.100 \ --set k8sServicePort6443 # 关键参数说明 # kubeProxyReplacementtrue - 完全替代 kube-proxy使用 eBPF # k8sServiceHost - K8s API Server 地址VIP 或 Master IP # k8sServicePort - API Server 端口 # 3. 等待 Pod 就绪 kubectl get pods -n kube-system -l k8s-appcilium -w # 期望输出 # NAME READY STATUS RESTARTS AGE # cilium-abc12 1/1 Running 0 2m # cilium-def34 1/1 Running 0 2m # cilium-ghi56 1/1 Running 0 2m # 4. 验证 Cilium 状态 # 下载 cilium CLI wget https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz tar xzvf cilium-linux-amd64.tar.gz mv cilium /usr/local/bin/ # 查看状态 cilium status # 期望输出 # /¯¯\ # /¯¯\__/¯¯\ Cilium: OK # \__/¯¯\__/ Operator: OK # /¯¯\__/¯¯\ Hubble: disabled # \__/¯¯\__/ ClusterMesh: disabled # \__/ # # DaemonSet cilium Desired: 6, Ready: 6/6, Available: 6/6 # Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2 # Pods: 8 running # Image versions cilium-operator quay.io/cilium/operator-generic:v1.14.2: 2 # Image versions cilium quay.io/cilium/cilium:v1.14.2: 6 # 5. 运行连接测试 cilium connectivity test # 测试内容包括 # - Pod 到 Pod 通信 # - Service 访问 # - DNS 解析 # - NetworkPolicy 验证6.4 Hubble 可视化可选# 安装 Hubble网络观察和可视化工具 cilium hubble enable # 访问 Hubble UI cilium hubble ui # 或者端口转发 kubectl port-forward -n kube-system svc/hubble-ui 12000:80 # 浏览器访问http://localhost:12000 # 命令行查看流量 cilium hubble observe # 过滤特定流量 cilium hubble observe --namespace default cilium hubble observe --pod nginx-abc12 cilium hubble observe --verdict DROPPED # 查看被丢弃的包七、网络排障实战7.1 Pod 无法访问 Service# 问题Pod 访问 Service 超时或失败 # 排查步骤 # 1. 检查 Service 是否存在 kubectl get svc nginx -o wide # 2. 检查 Endpoints 是否有后端 Pod kubectl get endpoints nginx # 如果为空说明没有匹配的 Pod # 3. 检查 Pod 标签是否匹配 Service selector kubectl get pod --show-labels kubectl get svc nginx -o yaml | grep -A 5 selector # 4. 检查 Pod 是否 Ready kubectl get pod -l appnginx # 确保 READY 列为 1/1 或 N/N # 5. 在 Pod 中测试访问 kubectl exec pod-a -- curl -v http://nginx:80 # 6. 检查 kube-proxy 日志 kubectl logs -n kube-system -l k8s-appkube-proxy | tail -50 # 7. 检查 iptables/IPVS 规则 # 在节点上执行 iptables-save | grep KUBE-SVC | grep nginx # 或 ipvsadm -ln | grep -A 5 10.96.0.100 # 8. 检查 CoreDNS kubectl exec pod-a -- nslookup nginx # 如果解析失败检查 CoreDNS Pod 和 Service7.2 跨节点 Pod 不通# 问题Pod A (node1) 无法 ping 通 Pod B (node2) # 排查步骤 # 1. 确认 Pod IP 地址 kubectl get pod pod-a pod-b -o wide # 2. 在 node1 上检查路由表 ssh node1 ip route show # 应该看到到 node2 Pod 网段的路由 # 10.244.2.0/24 via 192.168.1.102 dev ens192 # 如果没有路由说明 CNI 插件有问题 # 3. 在 node1 上 ping node2 的物理 IP ping 192.168.1.102 # 如果物理 IP 不通说明是底层网络问题 # 4. 检查 CNI Pod 状态 kubectl get pods -n kube-system | grep -E calico|flannel|cilium # 5. 查看 CNI 日志 kubectl logs -n kube-system calico-node-xyz12 | tail -50 # 6. 使用 tcpdump 抓包 # 在 node1 上 tcpdump -i any host 10.244.2.10 -n # 在 node2 上 tcpdump -i any host 10.244.2.10 -n # 观察数据包是否到达 node2 # 7. 检查防火墙 iptables -L -n | grep REJECT # 确保没有拒绝规则7.3 DNS 解析失败# 问题Pod 无法解析 Service 名称 # 排查步骤 # 1. 检查 CoreDNS Pod 状态 kubectl get pods -n kube-system -l k8s-appkube-dns # 2. 检查 CoreDNS Service kubectl get svc -n kube-system kube-dns # 3. 检查 Pod 的 DNS 配置 kubectl exec pod-a -- cat /etc/resolv.conf # 期望输出 # nameserver 10.96.0.10 # search default.svc.cluster.local svc.cluster.local cluster.local # options ndots:5 # 4. 手动测试 DNS 解析 kubectl exec pod-a -- nslookup kubernetes.default.svc.cluster.local 10.96.0.10 # 5. 查看 CoreDNS 日志 kubectl logs -n kube-system -l k8s-appkube-dns | tail -50 # 6. 检查 CoreDNS ConfigMap kubectl get cm -n kube-system coredns -o yaml # 确保配置正确 # .:53 { # errors # health # kubernetes cluster.local in-addr.arpa ip6.arpa { # pods insecure # fallthrough in-addr.arpa ip6.arpa # } # prometheus :9153 # forward . /etc/resolv.conf # cache 30 # loop # reload # loadbalance # }7.4 常用排障工具# 1. nsenter - 进入 Pod 的网络命名空间 # 获取 Pod 的容器 PID PID$(docker inspect -f {{.State.Pid}} container-id) # 或 PID$(crictl inspect container-id | jq .info.pid) # 进入网络命名空间 nsenter -n -t $PID # 现在可以执行网络命令如同在 Pod 内 ip addr show ping 10.244.2.10 curl http://10.96.0.100 # 2. tcpdump - 抓包分析 # 抓取特定端口的流量 tcpdump -i cni0 port 80 -n # 抓取特定 IP 的流量 tcpdump -i any host 10.244.1.10 -n # 保存到文件 tcpdump -i cni0 -w /tmp/capture.pcap # 3. conntrack - 查看连接跟踪 # 查看所有连接 conntrack -L # 过滤特定 IP conntrack -L -d 10.96.0.100 # 清除连接跟踪谨慎使用 conntrack -D # 4. hubbleCilium 专用 cilium hubble observe --namespace default7.5 排障决策树网络问题排查流程 ┌─────────────┐ │ 网络问题 │ └──────┬──────┘ │ ┌──────▼──────┐ │ Pod 能 ping │ │ 通网关吗 │ └──────┬──────┘ │ ┌────────────┴────────────┐ │ │ 是 否 │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ 检查 DNS │ │ 检查 CNI │ │ 解析 │ │ Pod 状态 │ └──────┬──────┘ └──────┬──────┘ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ 能解析 │ │ CNI Pod │ └──────┬──────┘ │ Running │ │ └──────┬──────┘ ┌────┴────┐ │ 是 否 ┌────┴────┐ │ │ 是 否 │ ┌────▼────┐ │ │ │ │检查 │ │ ┌────▼────┐ │ │CoreDNS │ │ │查看 CNI │ │ │Pod │ │ │日志 │ │ └─────────┘ │ └─────────┘ │ │ ┌────▼────┐ ┌──────▼──────┐ │检查 │ │ 同节点 Pod │ │Service │ │ 能互通吗 │ │Endpoint │ └──────┬──────┘ └─────────┘ │ ┌────┴────┐ 是 否 │ │ ┌──────▼──────┐ │ │ 跨节点问题 │ │ │ 检查路由/ │ │ │ overlay │ │ └─────────────┘ │ │ ┌──────▼──────┐ │ 同节点问题 │ │ 检查网桥/ │ │ veth pair │ └─────────────┘八、总结与最佳实践8.1 CNI 插件选择建议场景推荐 CNI理由中小规模集群1000 PodFlannel简单稳定开箱即用企业级生产环境Calico功能完善NetworkPolicy 支持好大规模高性能集群CiliumeBPF 性能优势L7 策略强大云服务AWS/Azure/GCP云厂商 CNI与云网络深度集成8.2 网络配置最佳实践Pod 网段规划使用 RFC 1918 私有地址10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16确保 Pod 网段、Service 网段、节点网段不重叠预留足够的 IP 空间考虑未来扩展MTU 设置Overlay 模式MTU 物理网络 MTU - 封装开销通常 1480BGP/路由模式MTU 物理网络 MTU通常 1500DNS 优化使用 NodeLocal DNSCache 减少 CoreDNS 压力调整 ndots 参数默认 5可减少为 2-3监控 DNS 查询延迟NetworkPolicy默认拒绝所有流量按需开放使用标签管理策略而非硬编码 Pod 名称定期审查和清理过期策略监控与排障部署网络监控Prometheus Grafana保留 tcpdump/conntrack 等排障工具建立网络问题应急预案