Kubernetes网络：CNI插件与网络策略

理解Kubernetes网络模型与CNI插件职责

Kubernetes的网络模型建立在扁平化网络假设之上，要求所有Pod能够直接通过IP相互通信，且Pod与Node之间、Service与Pod之间均无NAT转换。这一模型并非由Kubernetes核心组件直接实现，而是完全依赖CNI（Container Network Interface）插件。当kubelet创建Pod时，会调用CNI插件完成网络命名空间的配置、虚拟网卡（veth pair）的创建以及IP地址的分配（通常通过IPAM模块）。CNI插件还需负责跨节点通信的路由或隧道封装。在架构关系上，kubelet作为调度与生命周期管理者，通过CRI调用容器运行时，再由运行时触发CNI二进制程序。选择CNI时需综合考量性能（如eBPF加速）、功能（是否支持NetworkPolicy、多租户隔离）、运维复杂度及与底层基础设施的兼容性，常见方案包括Calico（BGP路由）、Flannel（VXLAN/Host-GW）和Cilium（eBPF）。

部署与检查CNI插件，确认Pod网络正常

部署CNI插件后，必须通过系统化检查确认网络平面就绪。首先，在kube-system命名空间下执行kubectl get daemonset -n kube-system，确认CNI组件（如calico-node或flannel）的READY状态为期望值，且无CrashLoopBackOff。接着登录任意工作节点，使用ip a查看是否生成CNI网桥（如cni0或flannel.1）及对应的veth接口。通过kubectl get pods -o wide获取Pod IP后，应在不同节点间执行ping或nc -zv验证跨节点连通性。若通信失败，需重点排查/etc/cni/net.d/目录下的CNI配置文件是否被意外覆盖或格式错误，以及容器运行时（如containerd的config.toml）是否正确指定了CNI插件路径。此外，节点防火墙规则若拦截了VXLAN UDP端口或BGP TCP 179端口，也会导致底层隧道断裂，需逐一放行。

设计NetworkPolicy：从默认放行到最小权限

NetworkPolicy是Kubernetes实现微服务网络隔离的核心资源，但其生效强依赖于底层CNI插件的策略执行能力（如Calico、Cilium支持，而基础版Flannel不支持）。策略主要作用于OSI模型的L3/L4层，通过podSelector、namespaceSelector、ipBlock定义流量源或目标，并利用ingress（入站）和egress（出站）规则控制协议与端口。构建最小权限模型的第一步是创建“默认拒绝”策略：在目标命名空间部署仅包含空podSelector的NetworkPolicy，此时该空间内所有Pod的入站与出站流量将被隐式阻断。随后，通过精确匹配业务标签编写放行规则，仅允许特定命名空间或CIDR网段访问指定端口。需注意，NetworkPolicy仅声明期望状态，实际拦截由CNI在节点iptables或eBPF链中动态生成规则实现，未匹配任何策略的Pod将回退到默认放行状态，因此必须显式定义拒绝策略以收敛攻击面。

验证网络策略效果与排查访问异常

验证NetworkPolicy需构建可复现的测试闭环。首先创建目标服务Pod并应用默认拒绝策略，随后在允许和禁止的命名空间分别部署带不同标签的测试Pod。使用kubectl exec curl-allow -- curl -s --connect-timeout 3 http://<target-ip>应返回HTTP 200，而curl-deny则应触发连接超时或拒绝。通过kubectl get networkpolicy -o yaml可核对策略对象是否已正确下发至节点。排查高频故障时，首要检查标签选择器是否拼写错误或遗漏matchLabels；其次确认当前CNI是否真正支持NetworkPolicy；最后需严格区分ingress与egress方向，若策略仅定义了入站规则，出站流量仍可能不受控。官方测试范式强调使用独立标签的Pod进行双向验证，结合kubectl describe networkpolicy查看事件日志，可快速定位策略未生效或误拦截的根因。