一、網絡組件的作用

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

三、知識小結