一、网络组件的作用
1. 部署网络组件的目的
- 核心功能：执行kubectl apply -f calico.yaml命令的主要目的是为Kubernetes集群部署网络组件
- 必要性：
- 解决Pod间的跨节点通信问题
- 建立集群范围的网络平面，使所有Pod处于同一网络层
- 替代Docker默认的bridge网络模式
2. 跨主机网络通信问题
- 基础架构：
- 每台Docker主机默认使用独立的bridge网络
- 容器获得172.17.0.0/16网段的随机IP
- 通信障碍：
- 不同主机上的容器可能分配到相同IP（如都获得172.17.0.2）
- 容器发出的数据包无法识别目标容器所在宿主机
- 缺乏跨主机的路由转发机制
3. 容器IP分配与通信
1）IP冲突问题
- 冲突机制：
- 各Docker主机独立维护IP分配池
- 默认使用相同网段（172.17.0.0/16）
- 有概率（约1/65534）分配相同IP
- 解决方案：
- 修改Docker的bip参数指定不同子网
- 例如：节点1配置172.18.0.1/16，节点2配置172.19.0.1/16
2）路由转发问题
- 通信障碍：
- 即使IP不同（如172.17.0.2和172.17.0.3）
- 容器无法感知目标容器所在宿主机
- 缺乏跨主机路由表配置
- 传统解决方案：
- 手动配置路由表和iptables规则
- 维护复杂度随节点数量指数级增长
- 需要自行开发自动化管理程序
3）网络组件作用
- 核心功能：
- 统一管理集群IP分配，确保全局唯一
- 自动维护跨节点路由规则
- 实现Pod-to-Pod的直接通信
- 实现原理：
- 通过BGP协议同步路由信息
- 使用IPIP隧道或VXLAN封装数据包
- 自动响应节点增减事件
4. 网络组件解决通信问题
- 核心功能：实现跨主机容器通信和节点与容器间通信，形成扁平化网络
- 解决容器间通信需求（如前端调用后端API，后端访问数据库容器）
- 消除IP冲突风险（避免不同主机随机分配相同IP）
- 建立路由机制（解决数据包跨主机传输路径问题）
- 典型场景：当Pod分布在不同节点时，传统Docker网络无法直接通信
- 同节点Pod通过docker0网桥二层通信（类似交换机连接设备）
- 跨节点通信必须依赖网络组件建立路由规则
5. 主流网络组件与CNI接口
- 组件选型：
- Flannel：适合小规模开发集群（几十台规模）
- Calico：适合大规模生产集群，提供更精细的网络策略
- CNI规范：
- 本质：Kubernetes制定的容器网络接口标准（Container Network Interface）
- 作用：统一第三方网络组件接入规范，避免K8s团队单独适配
- 特点：组件需符合标准才能被集成（如Flannel/Calico都支持CNI）
- 部署注意：
- 网络组件是K8s核心依赖，未就绪会导致节点NotReady状态
- 通常只需部署一个网络组件（多组件共存需二次开发）
- Windows节点支持有限，实际生产不建议使用
6. Kubernetes弃用Docker
- 背景：为解决多容器运行时兼容问题
- 早期直接集成Docker导致维护成本高
- 需要支持containerd、CRI-O等其他运行时
- CRI接口：
- 容器运行时接口（Container Runtime Interface）
- 标准化运行时接入方式，dockershim将被逐步淘汰
- 当前架构：
- 过渡方案：
- 推荐直接使用containerd作为运行时
- 现有Docker环境仍可通过shim层兼容
二、Kubernetes将弃用Docker
1. CRI接口的引入背景
- 集成问题背景: Kubernetes早期需要解决与多种容器运行时(如Docker)的集成问题，为此社区推出了CRI(Container Runtime Interface)标准接口。
- 架构演变: 使用Docker作为容器运行时时的架构包含多层调用链：kubelet → CRI(dockershim) → dockerd → containerd → shim → runC → container。
2. dockershim的弃用计划
- 弃用对象: Kubernetes计划移除kubelet中的dockershim组件，该组件是专门为适配Docker Engine开发的桥梁程序。
- 历史原因:
- Docker加入K8s生态早于CRI标准制定
- K8s团队最初直接为Docker编写了专用适配器(dockershim)
- Docker未主动适配后来的CRI标准
3. 弃用的技术原因
- 性能问题:
- Docker内部调用链复杂：kubelet → dockershim → dockerd → containerd → shim → runC，共4-5层调用
- 多层封装导致性能下降约30%，故障率提升且难以排查
- 安全隐患:
- Docker会在宿主机创建网络规则和存储卷
- 存在潜在的安全边界突破风险
- 维护成本:
- 保持dockershim组件增加了K8s代码维护复杂度
- CRI标准成熟后，专用适配器显得冗余
4. 影响与替代方案
- 直接影响:
- 移除dockershim后，K8s将无法直接使用Docker作为运行时
- 需要改用已实现CRI接口的运行时(如containerd、CRI-O)
- 接口标准体系:
- CRI(容器运行时接口)：管理容器生命周期
- CNI(容器网络接口)：管理网络组件接入
- CSI(容器存储接口)：管理存储卷操作
- 过渡建议:
- 生产环境应提前测试containerd等替代方案
- 注意检查自定义脚本中对docker命令的依赖
三、知识小结
|------------------|--------------------------------------------|------------------------------|------|
| 知识点 | 核心内容 | 考试重点/易混淆点 | 难度系数 |
| Kubernetes网络组件作用 | 解决跨主机容器通信问题，实现集群内Pod间网络互通 | 区分Calico/Flannel等不同网络组件的适用场景 | ⭐⭐⭐⭐ |
| Docker默认网络问题 | 独立主机分配相同IP段导致容器IP冲突，无法直接跨主机通信 | 理解Docker默认bridge网络的局限性 | ⭐⭐⭐ |
| 网络组件部署意义 | 保证IP唯一性 + 自动路由管理 + 扁平化网络 | 为什么说手动配置路由表不可扩展 | ⭐⭐⭐⭐ |
| CNI规范 | Kubernetes制定的网络插件接口标准，Calico/Flannel都遵循该标准 | CNI与CRI(容器运行时接口)的区分 | ⭐⭐⭐ |
| Calico核心功能 | 通过BGP协议实现跨节点路由，支持网络策略控制 | 与Flannel的VXLAN方案对比 | ⭐⭐⭐⭐ |
| Pod网络基础 | 同节点Pod通过docker0网桥二层通信，跨节点需网络组件 | 为什么说Pod是K8s最小调度单位 | ⭐⭐⭐ |
| CRI弃用Docker | 移除dockershim适配层，要求容器运行时必须支持CRI标准 | 为什么containerd成为新标准运行时 | ⭐⭐⭐⭐ |
| Windows支持现状 | 官方支持但生态不完善，生产环境推荐Linux方案 | Windows容器与Linux容器的本质差异 | ⭐⭐⭐ |