20250710-2-Kubernetes 集群部署、配置和验证-网络组件存在的意义？_笔记

一、网络组件的作用

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命令的依赖

三、知识小结