📚 课程目录第2章 Kubernetes网络基础

2. Kubernetes 网络基础：CNI插件、Pod网络模型、Service与Endpoint、kube-proxy模式

2.1 核心网络模型：每个Pod一个IP

Kubernetes 网络模型的核心原则是：每个 Pod 拥有一个独立的、集群内可路由的 IP 地址。这个模型简化了端口分配、服务发现和网络策略的实施。所有容器共享 Pod 的网络命名空间，通过 localhost 即可通信。

  关键原则：
  Pod-to-Pod 通信：无需 NAT，直接通过 Pod IP 通信。
Node-to-Pod 通信：无需端口映射，直接可达。
Pod-to-Service 通信：通过虚拟 IP (ClusterIP) 进行负载均衡。

2.2 CNI 插件：网络实现的基石

Container Network Interface (CNI) 是 Kubernetes 与网络实现之间的标准接口。kubelet 在创建 Pod 时调用 CNI 插件，完成网络命名空间创建、接口配置和 IP 分配。

CNI 插件	网络模式	特点	适用场景
Calico	BGP / VXLAN	高性能、原生 NetworkPolicy、无封装选项	大规模生产、策略密集型
Flannel	VXLAN / host-gw	简单、轻量、无策略支持	小规模、快速部署
Cilium	eBPF / VXLAN	eBPF 驱动、可观测性、安全策略	云原生、高性能、安全敏感
Weave	VXLAN / fastdp	自动发现、加密、简单运维	混合环境、跨集群
Antrea	OVS / VXLAN	Open vSwitch 集成、细粒度策略	VMware 环境、NFV

巡检要点：检查 CNI 插件版本是否与 Kubernetes 版本兼容，以及 CNI 二进制文件是否存在于 /opt/cni/bin/ 目录。使用 kubectl get nodes -o wide 查看节点网络就绪状态。

2.3 Service 与 Endpoint：服务发现与负载均衡

Service 是 Kubernetes 中稳定的网络抽象层，它为一组 Pod 提供统一的访问入口。Service 通过 Label Selector 动态关联 Pod，并通过 Endpoint 对象维护后端 Pod IP 列表。

Service 类型对比

类型	访问方式	典型用途	外部可达
ClusterIP	集群内部虚拟 IP	内部服务通信	否
NodePort	节点 IP + 静态端口	开发测试、简单暴露	是
LoadBalancer	云厂商 LB + NodePort	生产环境外部访问	是
ExternalName	CNAME 到外部域名	集成外部服务	是

Endpoint 与 EndpointSlice

当 Service 创建后，Kubernetes 自动创建同名的 Endpoint 对象。随着集群规模增长，单个 Endpoint 对象可能包含数千个 Pod IP，导致性能瓶颈。Kubernetes v1.21+ 引入 EndpointSlice，将 Endpoint 按拓扑分布切分为多个切片，每个切片最多 100 个端点。

# 查看 Service 对应的 Endpoint
kubectl get endpoints my-service

# 查看 EndpointSlice（v1.21+）
kubectl get endpointslices

# EndpointSlice 示例输出
# NAME                  ADDRESSES      PORTS   AGE
# my-service-abcde      10.0.1.2,10.0.1.3   80      5m
# my-service-fghij      10.0.2.2,10.0.2.3   80      5m

水位巡检关注点：当 EndpointSlice 数量异常增长或单个 Endpoint 对象包含超过 1000 个端点时，可能影响 kube-proxy 的同步性能，导致 Service 更新延迟。建议监控 endpoint_slice_count 和 endpoint_sync_duration_seconds 指标。

2.4 kube-proxy 模式：数据平面实现

kube-proxy 是运行在每个节点上的网络代理，负责实现 Service 的负载均衡和流量转发。它支持三种模式，各有不同的性能特征和运维复杂度。

模式	实现机制	性能	可观测性	适用版本
userspace	用户态代理 + 轮询	低（内核态切换）	高（日志丰富）	v1.0 起废弃
iptables	Netfilter 规则链	中（规则线性匹配）	中（iptables-save）	默认模式（v1.1+）
IPVS	LVS 内核调度	高（哈希查找）	低（需额外工具）	v1.11+ 稳定

iptables 模式工作原理

kube-proxy 在 iptables 中创建一系列 PREROUTING 和 OUTPUT 链规则。当数据包到达节点时，通过 DNAT 规则将 Service IP 随机转换为后端 Pod IP。每个 Service 对应一组规则，规则数量 = Service 数 × 后端 Pod 数。

# 查看 Service 对应的 iptables 规则（以 my-service 为例）
iptables-save -t nat | grep my-service

# 典型输出片段
# -A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-XXXXX
# -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.25 -j KUBE-SEP-AAAAA
# -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.33 -j KUBE-SEP-BBBBB
# -A KUBE-SEP-AAAAA -p tcp -m tcp -j DNAT --to-destination 10.0.1.2:80

水位巡检风险：iptables 模式在集群规模较大时（Service > 5000 或规则 > 50000）会出现明显的规则同步延迟和 CPU 开销。规则更新是原子操作，大规模更新可能导致 kube-proxy 卡顿。建议监控 iptables_restore_failures_total 和 sync_proxy_rules_duration_seconds。

IPVS 模式优势

IPVS 使用内核哈希表替代 iptables 的线性规则链，在大量 Service 场景下性能显著提升。它支持更多调度算法：rr（轮询）、lc（最少连接）、sh（源哈希）、dh（目标哈希）等。

# 查看 IPVS 规则
ipvsadm -Ln

# 输出示例
# IP Virtual Server version 1.2.1 (size=4096)
# Prot LocalAddress:Port Scheduler Flags
#   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
# TCP  10.96.0.1:80 rr
#   -> 10.0.1.2:80                  Masq    1      0          0
#   -> 10.0.1.3:80                  Masq    1      0          0
#   -> 10.0.2.2:80                  Masq    1      0          0

迁移建议：对于大规模集群（Service > 1000），推荐使用 IPVS 模式。迁移步骤：
1. 在所有节点安装 ipvsadm 和内核模块（ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh、nf_conntrack_ipv4）。
2. 修改 kube-proxy 配置：mode: "ipvs"。
3. 滚动重启 kube-proxy DaemonSet：kubectl rollout restart -n kube-system daemonset kube-proxy。

2.5 网络水位巡检关键指标

作为 SRE，需要持续监控以下网络相关指标，确保连接池水位在安全范围内：

指标名称	来源	告警阈值	说明
`kube_proxy_sync_proxy_rules_duration_seconds`	kube-proxy metrics	> 5s	规则同步耗时，过高表示规则量过大
`iptables_restore_failures_total`	kube-proxy metrics	> 0	iptables 恢复失败，可能导致网络中断
`endpoint_slice_count`	kube-state-metrics	> 1000	EndpointSlice 数量过多，影响 API Server 性能
`node_network_transmit_errors_total`	node_exporter	> 0.1/s	节点网络发送错误，可能影响 Pod 通信
`conntrack_entries`	node_exporter	> 80% of max	连接跟踪表使用率，过高导致丢包

  巡检命令速查：
  kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide — 检查 kube-proxy 运行状态
kubectl get endpointslices --all-namespaces | wc -l — 统计 EndpointSlice 总数
curl -s http://localhost:10249/metrics | grep sync_proxy_rules_duration — 获取 kube-proxy 同步耗时
ipvsadm -Ln --stats — 查看 IPVS 连接统计