K8s底层核心理论复盘：Master/Worker节点架构 + CNI网络基石
对于刚接触K8s或者需要夯实底层基础的同学来说，很多时候会被各种资源对象、命令行、集群配置绕晕，本质原因是没吃透K8s最底层的架构逻辑和核心组件分工。K8s的核心设计理念是解耦控制平面与数据平面，所有集群调度、管理、网络通信的底层逻辑，都围绕Master节点（控制平面）、Worker节点（数据平面）以及CNI容器网络接口展开。
底层理论回顾，聚焦核心组件的职责、定位、工作逻辑，讲透最基础的底层逻辑，筑牢K8s知识根基。
一、K8s整体架构：控制平面 vs 数据平面
K8s集群本质是分布式集群系统，严格拆分控制平面（Master节点）和数据平面（Worker节点），两者分工明确、互不干扰，这是K8s高可用、易扩展的核心前提：
- Master节点（控制平面） ：集群的“大脑”，负责全局调度、集群状态管理、资源管控、决策下发，不直接运行用户业务容器，只做集群的统筹管理；
- Worker节点（数据平面） ：集群的“手脚”，负责实际运行Pod、业务容器，接收Master指令，执行具体的容器生命周期管理、网络代理、负载均衡；
- CNI（容器网络接口） ：集群的“血管”，解决Pod跨节点通信、集群内部网络互通问题，是K8s网络模型的底层标准接口，也是容器网络的核心依赖。
所有组件之间的通信，都遵循K8s的声明式API设计，核心流程是：用户提交期望状态 → Master存储并解析 → 调度到Worker → Worker执行维持状态，全程无中心化单点强依赖（高可用模式下）。
二、Master节点核心组件：集群大脑的四大核心
Master节点是控制平面核心，生产环境通常部署3节点高可用集群，避免单点故障，核心包含四大组件：kube-apiserver、etcd、kube-scheduler、kube-controller-manager，四个组件各司其职，协同完成集群管控。
1. kube-apiserver：集群唯一入口与网关
kube-apiserver是K8s集群的唯一入口，也是所有组件通信的中间枢纽，相当于集群的“网关+API服务器”，没有它，集群内所有组件都无法交互。
核心职责：
- 提供标准化的RESTful API接口，接收所有外部请求（kubectl命令、UI控制台、客户端SDK）和内部组件请求；
- 负责请求认证、授权、准入控制，校验请求合法性，拒绝非法操作，保障集群安全；
- 不存储任何持久化数据，只做请求转发和校验，所有集群状态数据最终落地到etcd；
- 是集群内唯一与etcd直接交互的组件，其他组件必须通过apiserver间接读写数据，保证数据一致性。
简单理解：所有操作都要经过apiserver“审批”，它不干活，只负责传话和把关，是集群的通信中枢。
2. etcd：集群唯一持久化存储
etcd是K8s集群的唯一元数据存储，基于Raft一致性算法的分布式键值数据库，相当于集群的“账本”，所有集群状态、配置、资源信息都存在这里。
核心职责：
- 持久化存储集群所有核心数据：Pod、Service、Node、ConfigMap、Secret等所有资源对象的期望状态和实际状态；
- 通过Raft算法保证多节点数据强一致性，即使部分节点故障，数据也不会丢失，保证集群数据可靠性；
- 提供监听机制，apiserver可实时监听数据变化，触发后续组件逻辑；
- 只与apiserver交互，不直接对接其他组件，数据读写严格受控。
关键结论：etcd挂了，集群就彻底失控，因为所有组件都不知道集群当前状态和期望状态，它是K8s的核心数据基石。
3. kube-scheduler：集群调度器（我称其为死车堵了，需要交警调度））
kube-scheduler是集群的调度决策者，负责给新建的Pod分配合适的Worker节点，相当于集群的“调度官”，决定Pod跑在哪个节点上。
核心职责：
- 监听apiserver，获取未分配节点的Pod（未调度Pod）；
- 通过调度算法筛选节点：先做预选策略（过滤不满足条件的节点，比如资源不足、端口冲突、亲和性规则），再做优选策略（打分排序，选最优节点）；
- 调度完成后，将Pod与节点的绑定关系提交给apiserver，最终写入etcd；
- 只做调度决策，不负责创建Pod，具体创建工作由Worker节点的kubelet执行。
简单理解：scheduler只负责“派活”，告诉Pod去哪个Worker节点，不负责落地执行。
4. kube-controller-manager：集群状态维持者
kube-controller-manager是集群的状态控制器，负责维持集群的期望状态，相当于集群的“运维管家”，确保实际状态和用户提交的期望状态一致。
核心职责：
- 内部包含多个子控制器（Replication Controller、Deployment Controller、Node Controller、Service Controller等），每个控制器负责一类资源的状态管理；
- 持续监听apiserver，对比集群实际状态和期望状态，发现不一致时自动修复；
- 比如Deployment期望运行3个Pod，实际只有2个，控制器会触发扩容，新建1个Pod；节点故障时，Node控制器会标记节点异常，迁移Pod；
- 是K8s声明式API的核心体现：用户只需要定义想要什么，控制器自动完成运维操作。
关键逻辑：K8s不做命令式操作，而是通过控制器循环监听、调谐，保证集群始终符合预期，这也是K8s自动化运维的核心。
三、Worker节点核心组件：集群执行单元
Worker节点是K8s集群的工作负载节点，用户的所有业务Pod都运行在Worker节点上，核心包含两个必备组件：kubelet、kube-proxy，同时依赖容器运行时（Docker、containerd、CRI-O等）。
1. kubelet：节点上的“代理管家”
kubelet是运行在每个Worker节点上的核心代理，是Master节点管控Worker节点的唯一入口，相当于节点的“本地管家”，负责Pod在当前节点的全生命周期管理。
核心职责：
- 定时向Master节点的apiserver上报当前节点的状态（CPU、内存、磁盘、网络资源，节点健康度）；
- 接收apiserver下发的Pod调度指令，调用容器运行时创建、启动、停止、销毁Pod；
- 管理Pod的存储卷、网络配置，监控Pod运行状态，异常时重启Pod；
- 执行Master下发的探针指令（存活探针、就绪探针），反馈Pod运行状态；
- 不负责调度，只负责执行当前节点上的Pod运维，确保Pod正常运行。
简单理解：kubelet是Master在Worker节点的“代言人”，Master的所有指令都靠kubelet落地执行。
2. kube-proxy：节点网络代理
kube-proxy运行在每个Worker节点上，负责集群内部的网络代理和负载均衡，实现Service的网络通信能力，相当于节点的“网络路由器”。
核心职责：
- 监听apiserver的Service和Endpoint变化，维护节点上的网络规则（iptables/ipvs模式）；
- 实现Service的集群内访问，将Service的ClusterIP流量转发到后端对应的Pod；
- 提供负载均衡能力，将流量均匀分发到多个后端Pod，实现服务高可用；
- 处理节点的端口映射、网络转发，保障Pod之间、Pod与Service之间的网络互通。
关键作用：没有kube-proxy，集群内的Service无法访问，Pod之间的跨Pod通信也会受阻，它是K8s服务发现和负载均衡的底层支撑。
四、CNI容器网络接口：K8s网络基石，重点聚焦Flannel
1. CNI核心定位：网络标准接口
CNI全称Container Network Interface，是K8s定义的容器网络标准接口，不是具体的网络实现，而是一套规范。K8s本身不实现容器网络，只定义CNI接口标准，由第三方网络插件实现具体网络能力，解决Pod跨节点通信、IP分配、网络隔离问题。
核心逻辑：K8s通过CNI接口调用网络插件，完成Pod网络创建、IP分配、路由配置，插件遵循CNI规范即可适配K8s，实现网络能力的解耦扩展。
常见CNI插件：Flannel、Calico、Weave、Canal等，其中Flannel是最基础、最常用的入门级CNI插件，也是底层原理最容易理解的。
2. 重点详解：Flannel网络插件
Flannel是CoreOS推出的轻量级CNI插件，专为K8s设计，核心目标是实现跨节点Pod的三层网络互通，让所有节点上的Pod都处于同一个扁平网络空间，拥有独立集群内唯一的IP，直接互通。
Flannel核心原理
- 基于etcd存储集群网络配置：Flannel从etcd获取集群Pod网段，为每个Worker节点分配独立的子网段（比如集群网段10.244.0.0/16，每个节点分配一个/24子网），保证每个节点的Pod IP不冲突；
- 三种工作模式：host-gw（主机网关）、vxlan（虚拟扩展局域网）、UDP（性能差，仅测试），生产环境常用vxlan模式；
- vxlan模式核心：在节点之间构建虚拟隧道，跨节点的Pod网络数据包通过隧道封装转发，实现跨节点Pod直接通信，无需配置复杂路由；
- 轻量级无侵入：Flannel只负责基础网络互通，不支持网络策略，部署简单，资源占用低，适合学习环境和基础业务集群。
Flannel核心价值
作为入门级CNI插件，Flannel完美解决K8s最基础的网络需求：Pod跨节点通信、IP地址管理，是理解K8s网络模型的最佳切入点，也是很多复杂网络插件的基础。
3. 其他CNI插件简要说明
除Flannel外，Calico支持网络策略、三层路由无隧道转发，性能更高，适合生产安全要求高的场景；Weave部署简单，自带网络策略；Canal是Flannel+Calico的组合，但这些插件的核心都是遵循CNI接口标准，只是实现能力和场景不同，入门阶段只需吃透Flannel即可掌握CNI核心逻辑。
五、底层核心逻辑总结
吃透K8s底层基础，抓住这几条核心逻辑就足够：
- Master是控制平面，四大组件管全局、做决策、存数据，不跑业务；
- Worker是数据平面，kubelet执行指令、管Pod，kube-proxy管网络，负责业务运行；
- 所有交互绕不开apiserver，所有数据存在etcd，这两个是集群核心中枢；
- CNI是网络标准，Flannel是基础实现，解决Pod跨节点通信，是网络基石。
底层理论是理解K8s所有高阶特性（弹性伸缩、滚动更新、高可用、网络策略）的前提，把组件分工和核心逻辑吃透，后续学习集群运维、故障排查、高阶配置都会事半功倍。
