【k8s网络组件及关系】

核心网络K8s组件一、所有组件的核心定义一基础网络核心组件网桥Bridge软件层面的二层交换机将多个物理/虚拟网卡连接到同一广播域基于MAC地址转发以太网帧如Docker的docker0、K8s的cni0。路由Routing三层网络功能基于IP地址转发报文通过路由表匹配目的IP实现不同网段主机通信Linux主机开启ip_forward后可作为软路由。TCP传输控制协议面向连接、可靠的传输层协议支持重传、拥塞控制、流量控制适用于对数据完整性要求高的场景HTTP/HTTPS、SSH。UDP用户数据报协议无连接、不可靠的传输层协议低延迟、头部开销小适用于实时性场景视频流、DNS、DHCP。VXLAN虚拟可扩展局域网二层覆盖网络协议将二层以太网帧封装在UDP报文中实现跨三层网络的二层连通K8s跨节点Pod通信核心。二防火墙核心组件netfilter 框架Linux内核底层报文处理框架在协议栈中设置5个钩子点PRE_ROUTING/LOCAL_IN/FORWARD/LOCAL_OUT/POST_ROUTING为上层工具提供内核级报文处理能力无直接操作接口。br_netfilter 模块Linux内核模块解决网桥中报文无法被netfilter处理的问题将二层帧解封装为三层IP报文注入netfilter钩子点K8s网络必备依赖。nftables 框架基于netfilter的新一代内核框架Linux 3.13替代iptables的内核模块采用树状规则存储支持多协议、高并发是当前主流底层防火墙框架。iptables基于netfilter的“用户态工具旧内核模块ip_tables”组合提供表filter/nat等-链INPUT/FORWARD等-规则体系实现报文过滤、NAT等功能传统防火墙工具。nftnftables框架的官方用户态工具用于编写、管理nftables内核规则语法简洁支持集合、变量等高级特性替代iptables命令。firewalld基于netfilter/nftables的用户态动态防火墙管理工具支持动态更新规则无需重启提供更友好的配置方式RHEL/CentOS 7默认防火墙。zone区域firewalld的核心组织单元按安全级别划分网络接口/源IP如public、work、trusted每个区域绑定独立规则实现分区域访问控制。预定义服务Predefined Servicefirewalld对常见服务的标准化封装如http、ssh、mysql将端口、协议打包为服务名简化防火墙配置。三K8s网络核心组件IPVSIP Virtual ServerLinux内核四层负载均衡模块基于netfilter实现为K8s Service提供高性能负载均衡支持轮询、源IP哈希等算法替代iptables模式。CNI插件Container Network InterfaceK8s网络标准化接口为Pod配置网络资源IP地址、虚拟网卡、路由、网桥/VXLAN解决不同网络方案的兼容性问题如Calico、Flannel、Cilium。ServiceK8s服务抽象为一组相同功能的Pod提供固定访问入口VIP和四层负载均衡通过标签选择器绑定Pod解决Pod IP动态变化问题。ClusterIP ServiceService默认类型分配集群内私有VIP仅允许集群内部访问适用于集群内服务通信。NodePort Service在ClusterIP基础上在所有节点开放固定端口30000-32767外部通过“节点IP:NodePort”访问服务测试环境常用。Headless Service无头服务无VIP的ServiceCoreDNS直接解析Pod真实IP列表适用于需要直接访问Pod的场景如StatefulSet集群。LoadBalancer Service对接云平台负载均衡器CLB/ELB外部通过云LB访问服务适用于公有云生产环境高可用。Ingress 控制器K8s七层负载均衡组件如Nginx Ingress基于Ingress资源定义的域名/路径规则将外部请求转发到后端Service支持SSL终止、路径重写等。Gateway APIK8s新一代网络路由规范替代传统Ingress通过GatewayClass/Gateway/HTTPRoute等CRD实现更灵活的七层路由支持多租户、多集群。kube-proxyK8s节点上的网络守护进程监控Service/Endpoint变化在节点上创建转发规则iptables/IPVS实现Service到Pod的流量转发。二、组件间的核心关联关系按“底层依赖→上层应用→K8s封装”的逻辑分三层梳理结合数据流转路径理解一第一层基础网络内核底层所有组件的依赖根基核心依赖链所有网络通信依赖TCP/UDP传输层 路由三层转发/网桥二层转发跨三层的二层通信如K8s跨节点Pod依赖VXLAN封装二层帧为UDP报文防火墙功能的底层根基是netfilter框架br_netfilter模块让网桥报文能被netfilter处理K8s必备。关键关联开启ip_forward三层转发 br_netfilter网桥报文注入netfilter是K8s网络的“内核前提”无二者则Service转发、CNI网桥模式无法生效。二第二层防火墙层基于基础网络的安全控制核心依赖链底层框架netfilter → 上层内核实现旧ip_tables模块新nftables框架用户态工具ip_tables模块→iptables命令nftables框架→nft命令管理工具firewalld上层→ 底层调用iptables/nftables可切换通过zone和预定义服务简化配置。关键关联nftables是iptables的升级替代解决规则过多的性能瓶颈nft命令兼容部分iptables语法firewalld不直接操作内核规则而是通过iptables/nftables工具将配置转换为内核规则核心优势是动态更新规则。三第三层K8s网络层基于基础网络防火墙的容器编排封装核心依赖链Pod网络基础CNI插件 → 依赖网桥创建cni0、VXLAN跨节点通信、路由Pod网段转发Service负载均衡Service → 依赖kube-proxy → 底层调用iptables/IPVS内核模块→ 依赖netfilter框架外部访问外部请求 → Ingress控制器/Gateway API → 后端Service → kube-proxy转发 → Pod关键关联按数据流转理解同节点Pod通信Pod→cni0网桥二层转发→ 目标Pod依赖网桥路由跨节点Pod通信Pod→cni0网桥→VXLAN隧道封装为UDP报文→ 目标节点VTEP→解封装→目标Pod依赖VXLAN路由集群内访问ServicePod→CoreDNS解析Service的ClusterIP→kube-proxy的iptables/IPVS规则→目标Pod依赖Servicekube-proxynetfilter外部访问Service测试环境外部客户端→节点IP:NodePort→kube-proxy规则→Service→Pod依赖NodePort Servicekube-proxy生产环境外部客户端→云LBLoadBalancer Service→Ingress控制器→Service→kube-proxy规则→Pod依赖LoadBalancerIngressServiceK8s组件内部关联Service与EndpointService通过标签选择器绑定PodK8s自动生成EndpointPod IP:端口列表kube-proxy基于Endpoint创建转发规则CNI插件与kube-proxyCNI负责Pod的网络配置IP/网卡kube-proxy负责Service的流量转发二者配合实现Pod的通信与服务暴露Ingress与Gateway APIGateway API是Ingress的升级兼容Ingress规则提供更细粒度的路由控制如多集群、多协议二者均依赖后端Service。三、核心关联总结基础网络TCP/UDP路由/网桥是通信根基netfilter/br_netfilter是内核底层支撑iptables/nftables/firewalld是安全控制工具K8s通过CNIPod网络、kube-proxyService转发、Ingress/Gateway API外部访问封装这些能力实现容器的网络通信与服务暴露。