核心网络&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等功能（传统防火墙工具）。
- nft：nftables框架的官方用户态工具，用于编写、管理nftables内核规则，语法简洁，支持集合、变量等高级特性（替代iptables命令）。
- firewalld：基于netfilter/nftables的用户态动态防火墙管理工具，支持动态更新规则（无需重启），提供更友好的配置方式（RHEL/CentOS 7+默认防火墙）。
- zone（区域）：firewalld的核心组织单元，按安全级别划分网络接口/源IP（如public、work、trusted），每个区域绑定独立规则，实现分区域访问控制。
- 预定义服务（Predefined Service）：firewalld对常见服务的标准化封装（如http、ssh、mysql），将端口、协议打包为服务名，简化防火墙配置。
（三）K8s网络核心组件
- IPVS（IP Virtual Server）：Linux内核四层负载均衡模块，基于netfilter实现，为K8s Service提供高性能负载均衡（支持轮询、源IP哈希等算法，替代iptables模式）。
- CNI插件（Container Network Interface）：K8s网络标准化接口，为Pod配置网络资源（IP地址、虚拟网卡、路由、网桥/VXLAN），解决不同网络方案的兼容性问题（如Calico、Flannel、Cilium）。
- Service：K8s服务抽象，为一组相同功能的Pod提供固定访问入口（VIP）和四层负载均衡，通过标签选择器绑定Pod，解决Pod IP动态变化问题。
- ClusterIP Service：Service默认类型，分配集群内私有VIP，仅允许集群内部访问（适用于集群内服务通信）。
- NodePort Service：在ClusterIP基础上，在所有节点开放固定端口（30000-32767），外部通过"节点IP:NodePort"访问服务（测试环境常用）。
- Headless Service（无头服务）：无VIP的Service，CoreDNS直接解析Pod真实IP列表，适用于需要直接访问Pod的场景（如StatefulSet集群）。
- LoadBalancer Service：对接云平台负载均衡器（CLB/ELB），外部通过云LB访问服务，适用于公有云生产环境（高可用）。
- Ingress 控制器：K8s七层负载均衡组件（如Nginx Ingress），基于Ingress资源定义的域名/路径规则，将外部请求转发到后端Service，支持SSL终止、路径重写等。
- Gateway API：K8s新一代网络路由规范，替代传统Ingress，通过GatewayClass/Gateway/HTTPRoute等CRD实现更灵活的七层路由（支持多租户、多集群）。
- kube-proxy：K8s节点上的网络守护进程，监控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+路由）；
- 集群内访问Service：Pod→CoreDNS解析Service的ClusterIP→kube-proxy的iptables/IPVS规则→目标Pod（依赖Service+kube-proxy+netfilter）；
- 外部访问Service：
- 测试环境：外部客户端→节点IP:NodePort→kube-proxy规则→Service→Pod（依赖NodePort Service+kube-proxy）；
- 生产环境：外部客户端→云LB（LoadBalancer Service）→Ingress控制器→Service→kube-proxy规则→Pod（依赖LoadBalancer+Ingress+Service）；
- K8s组件内部关联 ：
- Service与Endpoint：Service通过标签选择器绑定Pod，K8s自动生成Endpoint（Pod IP:端口列表），kube-proxy基于Endpoint创建转发规则；
- CNI插件与kube-proxy：CNI负责Pod的网络配置（IP/网卡），kube-proxy负责Service的流量转发，二者配合实现Pod的通信与服务暴露；
- Ingress与Gateway API：Gateway API是Ingress的升级，兼容Ingress规则，提供更细粒度的路由控制（如多集群、多协议），二者均依赖后端Service。
三、核心关联总结
基础网络（TCP/UDP+路由/网桥）是通信根基，netfilter/br_netfilter是内核底层支撑，iptables/nftables/firewalld是安全控制工具，K8s通过CNI（Pod网络）、kube-proxy（Service转发）、Ingress/Gateway API（外部访问）封装这些能力，实现容器的网络通信与服务暴露。