Kubernetes控制平面組件：Kubelet詳解（七）：容器網絡接口 CNI

云原生學習路線導航頁（持續更新中）

kubernetes學習系列快捷鏈接
- Kubernetes架構原則和對象設計（一）
- Kubernetes架構原則和對象設計（二）
- Kubernetes架構原則和對象設計（三）
- Kubernetes控制平面組件：etcd（一）
- Kubernetes控制平面組件：etcd（二）
- Kubernetes控制平面組件：API Server詳解（一）
- Kubernetes控制平面組件：API Server詳解（二）
- Kubernetes控制平面組件：調度器Scheduler（一）
- Kubernetes控制平面組件：調度器Scheduler（二）
- Kubernetes控制平面組件：Controller Manager 之內置Controller詳解
- Kubernetes控制平面組件：Controller Manager 之 NamespaceController 全方位講解
- Kubernetes控制平面組件：Kubelet詳解（一）：架構及 API接口層介紹
- Kubernetes控制平面組件：Kubelet詳解（二）：核心功能層
- Kubernetes控制平面組件：Kubelet詳解（三）：CRI 容器運行時接口層
- Kubernetes控制平面組件：Kubelet詳解（四）：gRPC 與 CRI gRPC實現
- Kubernetes控制平面組件：Kubelet詳解（五）：切換docker運行時為containerd
- Kubernetes控制平面組件：Kubelet詳解（六）：pod sandbox(pause)容器
- Kubernetes控制平面組件：Kubelet 之 Static 靜態 Pod

本文是 kubernetes 的控制面組件 kubelet 系列文章第七篇，主要對 容器網絡接口CNI 進行講解，包括：kubernetes網絡模型的分類、通信原則、CNI發展歷程、主要功能、工作原理、常見插件等，并對Calico插件的實現原理做了詳細講解

希望大家多多點贊關注評論收藏，作者會更有動力繼續編寫技術文章

1.kubernetes網絡模型

1.1.kubernetes網絡模型分類

kubernetes網絡模型大體可以分為三類：
- pod 之間的通信：包括同節點pod通信、跨節點pod通信，這種一般通過CNI實現
- pod 通過service 與別的pod通信：這種并非pod之間的直連通信，而是通過service通信。此類不屬于CNI范疇，由kube-proxy管理
- 外部流量訪問pod：入站流量相關，由Ingress管理

1.2.pod 之間通信的基本原則

1.2.1.pod間通信基本原則

在這里插入圖片描述

Kubernetes 的網絡模型定義了容器間通信的基本規則，核心目標是確保所有 Pod 無論位于哪個節點，均可直接通過 IP 地址相互通信，無需 NAT 轉換。

1.2.2.如何理解 pod 間通信無需NAT轉換

NAT（網絡地址轉換）是一種 將私有網絡內的設備IP地址轉換為公共IP地址的技術，主要用于解決IPv4地址不足問題。它允許多個設備通過一個公網IP共享上網，常見于家庭路由器。
因此pod之間通信不使用NAT，就表示 每個 Pod 擁有集群內全局唯一的 IP 地址，跨節點通信時流量直接通過 Pod IP 尋址，無需經過地址或端口轉換（類似局域網設備直連）。
對比傳統 NAT 場景：若使用 NAT，Pod A 訪問 Pod B 時，B 看到的源 IP 可能是 Pod A 所在的節點 IP，而非 Pod A 的真實 IP，破壞網絡透明性并增加運維復雜度。

2.CNI（Container Network Interface）接口設計

2.1.CNI 的發展歷程

Kubernetes 早期版本中，網絡功能主要依賴 ??kubenet?? 等內置插件實現，存在顯著局限性：
- ??靈活性不足??：網絡方案與特定實現深度綁定，難以支持多樣化的網絡需求（如跨云網絡、安全策略等）。
- ??配置復雜??：手動管理網絡參數（如 IP 分配、路由規則）需要較高的運維成本，且易出錯。
- ??擴展性差??：無法快速集成新興網絡技術，阻礙了 Kubernetes 在復雜場景下的應用。
??為解決上述問題，CoreOS?? 等公司于 2015 年提出了 ??CNI 規范??，CNI最初是由CoreOS為 rkt容器引擎創建的，目前已經成為事實標準。目前絕大部分的容器平臺都采用CNI標準（rkt，Kubernetes，OpenShift等），核心設計原則包括：
- ??插件化架構??：CNI 僅定義接口標準，具體實現由第三方插件完成（如 Flannel、Calico 等）。
- ??功能聚焦??：僅關注容器的網絡創建與銷毀，接口設計簡潔（如 ADD、DELETE 操作）。
- ??兼容性??：支持多種容器運行時（Docker、containerd）和編排系統（Kubernetes、Mesos）。
關鍵里程碑??：??2016年??：Kubernetes 1.5 版本正式集成 CNI，取代原有網絡模型，成為默認網絡接口。
- 標準化流程??：CNI 插件需以可執行文件形式實現，通過配置文件（/etc/cni/net.d）定義網絡參數。

2.2.CNI 的職能

CNI(Container Network Interface) 是 Kubernetes 網絡模型的實現標準，負責實現 pod 之間的直接通信：包括 容器與主機的通信、同節點pod通信、跨節點pod通信
實現手段：
- 網絡配置：在容器創建時分配 IP、配置路由和 DNS。
- 插件鏈：插件化設計，支持多個插件按順序執行（如先分配 IP 再設置防火墻規則）。
- 資源管理：通過 IPAM（IP 地址管理）插件分配和回收 IP。

2.3.CNI 插件分類及常見插件

github：https://github.com/containernetworking/plugins

在這里插入圖片描述

CNI插件大體可以分為三類：
- IPAM：IP Address Manager，負責管理 ip 地址，比如給pod分配ip
- 主插件網卡設置：負責實現 容器與主機的通信、同節點pod通信、跨節點pod通信
- Meta 附加功能：負責cni的擴展功能。比如實現端口映射、容器網絡限流、增加防火墻等

2.4.CNI工作原理

在這里插入圖片描述

2.4.1.CNI 插件配置

CNI 默認配置目錄：/etc/cni/net.d。配置文件中應該包含 插件名稱、CNI版本、插件列表
比如使用calico作為cni插件時，/etc/cni/net.d目錄會存在10-calico.conflist
再比如使用flannel作為CNI插件，配置文件可能是這樣

2.4.2.CNI 插件可執行文件

在 CNI 標準化流程中，規定? CNI 插件需以可執行文件形式實現，默認存放在目錄：/opt/cni/bin。
- 因此，所謂的CNI插件，其實就是一個個編譯好的二進制可執行文件，以供調用
比如使用calico時，/opt/cni/bin 下會包含可執行文件

再比如使用flannel時，/opt/cni/bin 下會包含可執行文件

[/opt/cni/bin]# ls
bandwidth  bridge  dhcp  dummy  firewall  flannel  host-device  host-local  ipvlan  loopback  macvlan  portmap  ptp  sbr  static  tuning  vlan  vrf

2.4.3.CNI插件生效原理

在這里插入圖片描述

/opt/cni/bin 存放所有的插件可執行文件
/etc/cni/net.d 存放cni配置，聲明當前要開啟哪些插件
CNI插件是如何生效的？
- 當調用cni時，kubelet 就相當于執行了一條本地命令，找到這個可執行文件，給出入參，即可使用cni功能
因此如果自己開發CNI插件，應該如何做？
- 自己開發CNI插件，首先要定義清楚 ADD network、Delete network 等操作的實現
- 然后以可執行文件方式放入 /opt/cni/bin，并在 /etc/cni/net.d 配置文件中開啟
調用 CNI插件時，是如何傳參的？
- 通過設置環境變量，將 podId、sandbox net namespace、ADD/DEL 等信息設置為環境變量后，執行cni可執行文件，cni執行過程會讀取這些預定義的env，進而執行特定的操作

2.4.4.CNI 與 kubelet 聯動

在這里插入圖片描述

kubelet 包含兩個參數，分別用來設置 cni可執行文件目錄、cni配置文件目錄

2.5.CNI 插件的設計考量

在這里插入圖片描述

2.6.pod Ip的分配過程簡述

學習了上述cni知識，知道有個IPAM插件用于為pod分配ip，那么pod ip分配后如何讓apiserver知道呢？過程如下。
- 啟動pod時，containerRuntime會調用CNI，CNI插件鏈中包含IPAM，會給pod分配一個ip。
- 然后 CNI主插件會將該ip 配置到 pod的網絡namespace
- 附加功能插件里比如bandwidth就會為之限制帶寬，處理完成后將結果返回給containerRuntime。
- containerRuntime會將ip以及結果返回給kubelet，kubelet上報到apiserver
- apiserver將ip寫入etcd，這樣這個pod就具有ip了

3.CNI 插件

3.1.常見CNI插件

在這里插入圖片描述

Calico、Cilium都是網絡的一攬子解決方案，包括 容器與主機的通信、同節點pod通信、跨節點pod通信
目前生產上 Calico、Cilium 使用的更多，其中 Cilium 性能會更優異

3.2.Flannel

在這里插入圖片描述

Flannel 使用了VxLAN，會引入一些額外的開銷，大約10%，所以注重效率的生產系統不太用Flannel
Flannel 本身只做CNI插件，沒有完備的生態，比如不能做網絡隔離，不如Calico、Cilium都是網絡的一攬子解決方案

3.3.Calico

在這里插入圖片描述

3.3.1.pod ip 規劃方案

在容器ip的分配上，有多種方案：分配真實ip、建立私有網絡

3.3.1.1.直接給pod分配基礎架構中的真實ip

基礎架構中的真實ip 在主機的網卡中都認識，所以pod之間的通信天然就是通的，不需要額外的配置，效率高。
但是一個集群的真實ip很有限，而且非常寶貴，規劃不當的情況下會限制集群的規模。

3.3.1.2.為pod分配虛擬ip

社區為了提供通用方案，假設pod都是私有ip，無法在底層基礎架構中進行路由，只能實現主機內部通信，無法直接實現跨主機通信。
跨主機ping不通，由此帶來跨主機通信的一些解決方案：
- 方案一：封包解包。
  - 為了實現跨主機通信，最直接的方法就是把 pod的 ip數據包再包一層，封包解包。
  - 如果數據包在主機內部流轉，那么直接就可以路由到。
  - 但如果包要出去，就需要在原始包基礎上再加一層包，這就叫 tunnel模式（隧道模式）。
  - 封裝包也有多種方式：
    - IPinIP：在ip包外邊再加一層ip包
    - VxLAN：在ip包外邊增加一層udp包。比如Flannel就是用了這種
  - 不過封包解包本身是有性能開銷的
- 方案二：動態路由協議
  - 既然網卡中的靜態路由協議不認識這些私有的pod ip，那么可以自行維護動態路由協議，讓主機能夠知曉這個ip在哪臺主機
  - 這種路由模式，無需引入額外的封裝層，效率大大提升

3.3.2.Calico的pod通信方案

在這里插入圖片描述

Calico支持上述的三種跨跨主機通信模式，上圖將Calico支持的三種模式都畫了出來：
- IPinIP：
- VxLAN
- BGP路由協議

組件名稱	功能說明
Felix Agent	運行在每個節點（Master/Minion），負責： - 配置本地路由表 - 管理 ACL（安全策略） - 監控容器生命周期
BIRD Agent	基于 BGP 協議的路由守護進程，負責： - 節點間路由信息交換（圖中未顯式展示 BGP 對等連接） - 生成跨主機路由規則
confd Agent	動態生成 BIRD 的配置文件，監聽 Etcd/Kubernetes API 的變更并更新路由策略
IP-in-IP 隧道	封裝 Pod 的原始 IP 包到宿主機 IP 包中，實現跨節點通信（如圖中 `tunnel IPinIP` 連接）

3.3.2.1.Calico 支持 IPinIP 模式

示例：Pod A（Node2）→ Pod B（Node3）
- 封裝：Pod A 的 IP 包被 Felix 封裝到 Node2 的 IP 包中（源 IP：Node2，目標 IP：Node3）。
- 傳輸：通過宿主機的物理網絡傳輸到 Node3。
- 解封裝：Node3 的 Felix 解封裝，將原始 Pod IP 包傳遞給 Pod B。
適用場景
- 底層網絡限制：當底層網絡（如公有云 VPC）不支持直接路由 Pod IP 時，IP-in-IP 通過隧道繞開限制。
- 簡單配置：無需依賴外部路由器或復雜網絡策略。

3.3.2.2. Calico 支持 VxLAN 模式

在這里插入圖片描述

示例：Pod A（Node2）→ Pod B（Node3）
- 封裝：
  1. Pod A 的 IP 包被主機上vxlan.calico 設備封裝為 VxLAN 格式（外層 UDP 頭部，目標端口 4789）。
  2. 外層 IP 頭源地址為 Node2，目標地址為 Node3。
  3. VxLAN 頭部包含 VNI（Virtual Network Identifier），默認值為 4096，用于多租戶隔離。
- 傳輸：通過宿主機的物理網絡傳輸到 Node3（基于 UDP 協議）。
- 解封裝：
  1. Node3 的 vxlan.calico 識別 VxLAN 封裝，剝離外層 UDP 和 VxLAN 頭部。
  2. 將原始 Pod IP 包傳遞給 Pod B。
適用場景
- 多租戶隔離：通過 VNI 實現不同租戶或業務的網絡隔離。
- 復雜網絡環境：適用于需要靈活擴展虛擬網絡且底層網絡支持組播或單播轉發的場景（如混合云）。
查看calico-vxlan設備：ip a

3.3.2.3. Calico 支持 BGP 路由協議模式

示例：Pod A（Node2）→ Pod B（Node3）
- 路由同步：
  1. Node2 和 Node3 的 BIRD Agent 通過 BGP 協議向物理交換機或路由反射器宣告本地 Pod 子網（如 10.244.1.0/24）。
  2. 物理網絡設備生成路由表，標記 Node3 的 Pod 子網下一跳為 Node3 的物理 IP。
- 數據傳輸：
  1. Pod A 的 IP 包根據 Node2 的路由表直接通過物理網絡發送到 Node3（無需封裝）。
  2. Node3 根據本地路由規則將數據包轉發給 Pod B。
適用場景
- 高性能需求：無封裝開銷，延遲最低，適合金融交易、實時計算等場景。
- 私有數據中心：要求底層網絡設備（交換機/路由器）支持 BGP 協議（如企業級網絡架構）。

模式對比總結

模式	封裝方式	性能	網絡要求	典型場景
IP-in-IP	IP-in-IP 隧道（IP 協議）	中等	僅需 IP 可達性	公有云、簡單 Overlay 網絡
VxLAN	VxLAN 隧道（UDP 協議）	中等	支持組播或單播轉發	混合云、多租戶隔離
BGP 路由	無封裝，依賴物理路由	高	需 BGP 兼容的物理網絡設備	私有數據中心、高性能網絡

通過靈活選擇模式，Calico 可適配從公有云到私有數據中心的多樣化網絡需求。

3.3.3.Calico節點初始化

前面我們知道在使用了calico的時候，每個節點的 /etc/cni/net.d 和 /opt/cni/bin 目錄下都會分別包含 calico的配置文件、calico的可執行文件。
那么這些文件是如何被配置到主機上的？
- 答：通過daemonset代替人工，方便高效

3.3.3.1.Calico DaemonSet

在安裝Calico時，一般會創建一個ds，用于啟動Calico，現在看下這個ds都是做了什么
輸出下ds的yaml，可以看到有一些initContainer，其中有個initContainer就負責 calico 的安裝操作，這里實際上做的操作就是把配置文件拷貝到本機的/etc/cni/net.d，把calico相關的插件可執行文件拷貝到 /opt/cni/bin
如何拷貝？
- 通過掛載hostpath，將目錄掛載到容器中，然后就可以直接把文件拷貝進去

3.3.3.2.很多CNI插件采用DaemonSet初始化

除了calico，其他很多cni插件也是通過 daemonset initContainers 實現初始化的，比如Flannel
Flannel 這里更直接，直接用在command中用cp命令做拷貝

[root@VM /opt/cni/bin]# kubectl get ds -n kube-flannel kube-flannel-ds -oyaml
apiVersion: apps/v1
kind: DaemonSet
metadata:annotations:deprecated.daemonset.template.generation: "1"creationTimestamp: "2024-04-17T08:01:53Z"generation: 1labels:app: flannelk8s-app: flanneltier: nodename: kube-flannel-dsnamespace: kube-flannelresourceVersion: "97665682"selfLink: /apis/apps/v1/namespaces/kube-flannel/daemonsets/kube-flannel-dsuid: 8bb85be6-99a6-4896-ace9-11d2f7ecd2da
spec:revisionHistoryLimit: 10selector:matchLabels:app: flanneltemplate:metadata:creationTimestamp: nulllabels:app: flanneltier: nodespec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/osoperator: Invalues:- linuxcontainers:- args:- --ip-masq- --kube-subnet-mgrcommand:- /opt/bin/flanneldenv:- name: POD_NAMEvalueFrom:fieldRef:apiVersion: v1fieldPath: metadata.name- name: POD_NAMESPACEvalueFrom:fieldRef:apiVersion: v1fieldPath: metadata.namespace- name: EVENT_QUEUE_DEPTHvalue: "5000"image: docker.io/flannel/flannel:v0.25.1imagePullPolicy: IfNotPresentname: kube-flannelresources:requests:cpu: 100mmemory: 50MisecurityContext:capabilities:add:- NET_ADMIN- NET_RAWprivileged: falseterminationMessagePath: /dev/termination-logterminationMessagePolicy: FilevolumeMounts:- mountPath: /run/flannelname: run- mountPath: /etc/kube-flannel/name: flannel-cfg- mountPath: /run/xtables.lockname: xtables-lockdnsPolicy: ClusterFirsthostNetwork: trueinitContainers:- args:- -f- /flannel- /opt/cni/bin/flannelcommand:- cpimage: docker.io/flannel/flannel-cni-plugin:v1.4.0-flannel1imagePullPolicy: IfNotPresentname: install-cni-pluginresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilevolumeMounts:- mountPath: /opt/cni/binname: cni-plugin- args:- -f- /etc/kube-flannel/cni-conf.json- /etc/cni/net.d/10-flannel.conflistcommand:- cpimage: docker.io/flannel/flannel:v0.25.1imagePullPolicy: IfNotPresentname: install-cniresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilevolumeMounts:- mountPath: /etc/cni/net.dname: cni- mountPath: /etc/kube-flannel/name: flannel-cfgpriorityClassName: system-node-criticalrestartPolicy: AlwaysschedulerName: default-schedulersecurityContext: {}serviceAccount: flannelserviceAccountName: flannelterminationGracePeriodSeconds: 30tolerations:- effect: NoScheduleoperator: Existsvolumes:- hostPath:path: /run/flanneltype: ""name: run- hostPath:path: /opt/cni/bintype: ""name: cni-plugin- hostPath:path: /etc/cni/net.dtype: ""name: cni- configMap:defaultMode: 420name: kube-flannel-cfgname: flannel-cfg- hostPath:path: /run/xtables.locktype: FileOrCreatename: xtables-lockupdateStrategy:rollingUpdate:maxUnavailable: 1type: RollingUpdate
status:currentNumberScheduled: 1desiredNumberScheduled: 1numberAvailable: 1numberMisscheduled: 0numberReady: 1observedGeneration: 1updatedNumberScheduled: 1

3.3.4.Calico配置一覽

在這里插入圖片描述

3.3.5.Calico實現原理

本節解答問題：Calico是實現ip管理的？

3.3.5.1.Calico 自帶眾多CRD

在這里插入圖片描述

ippools：整個集群的ip池，定義了ip的總量、每個node ip的數量、是否開啟ipip mode等
ipamblocks：在具體一個node上，按照ippools中對node ip 的規定，為當前node的ipamblocks分配ip段，并記錄有哪些ip分配給了哪個pod，還有哪些ip沒有分配等信息
ipamhandles：每一個pod都會有一個具體的ipamhandle，記錄自己分配到的ip

3.3.5.2.如何查看calico的通信模式

在 calico daemonset 中，規定了當前采用的通信模式
比如下圖表示當前采用 bird模式

3.3.5.3.節點內pod通信實踐

演示在一個pod中，ping 同節點另一個pod 的包轉發過程

當前運行了兩個pod，pod分別為：centos 192.168.166.144、nginx 192.168.166.142
我們進入centos 192.168.166.144 的 pod中，ping 一下 nginx 192.168.166.142，是可以ping通的。那么為什么能通呢，中間過程如何？
查看一下當前pod的網絡設備 ip addr/ip a，可以看到自己的ip 192.168.166.144
查看一下當前pod的路由表：ip route/ip r。明顯169.254.1.1和pod ip不屬于同一網段
通過arping查看 ping 過程中的設備mac地址，可以看出是 ee:ee:ee:ee:ee:ee
我們退出容器，回到主機上，查看主機的網絡設備。ip addr/ip a，可以看到，所有calico建出來的網絡設備，mac地址都是 ee:ee:ee:ee:ee:ee。說明只要是從centos網關出來的包都會被calico設備接收到
查看主機的路由表，可以看到有192.168.166.142，即只要在主機上訪問 192.168.166.142，都會轉發到 calico440f455693 的口，這個口的vethpair另一頭正式連接的 nginx 192.168.166.142，包就被轉發過去了

3.3.5.4.跨節點的pod通信實踐：BIRD

如何通過BIRD實現跨節點的pod通信？
每個節點上都會運行一個 BIRD Daemon，所有節點上的BIRD會彼此建立長連接，互相同步路由表。

路由表示例

ipamblock:
10-233-90-0-24
node1
# node1的網段
cidr: 10.233.90.0/24
# 路由表：凡是10.233.96.0/24網段的，都在192.168.34.11節點上
10.233.96.0/24 via 192.168.34.11 dev tunl0 proto bird onlinkipamblock:
10-233-96-0-24
node: node2
# node2的網段
cidr: 10.233.96.0/24
# 路由表：凡是10.233.90.0/24網段的，都在192.168.34.10節點上
10.233.90.0/24 via 192.168.34.10 dev tunl0 proto bird onlink

3.4.CNI plugin 對比

在這里插入圖片描述

生產建議：Calico/Cilium
Cilium性能好，但是需要比較新的 kernel

4.CNI 接口

CNI提供了4個接口，由容器運行時調用，用于管理容器網絡的生命周期
- ADD - 將容器添加到網絡，或修改配置
- DEL - 從網絡中刪除容器，或取消修改
- CHECK - 檢查容器網絡是否正常，如果容器的網絡出現問題，則返回錯誤
- VERSION - 顯示插件的版本

接口	冪等性	必須實現	典型插件邏輯
`ADD`	否	是	創建網卡、分配 IP、配置路由
`DEL`	是	是	刪除網卡、釋放 IP、清理路由
`CHECK`	是	否（可選）	檢查 IP 有效性、路由是否存在
`VERSION`	是	是	返回支持的 CNI 版本列表

4.1.ADD接口

作用：為容器分配網絡資源（如 IP、路由、網卡等），并配置網絡連接。
調用時機：
- 容器創建時（如 Pod 啟動時）
- 容器加入新網絡時（多網絡場景）

輸入參數（JSON 格式）：

{"cniVersion": "1.0.0",        // CNI 版本"name": "mynet",             // 網絡名稱"type": "bridge",            // 插件類型"containerID": "abcd1234",   // 容器唯一 ID"netns": "/proc/1234/ns/net", // 容器的網絡命名空間路徑"ifName": "eth0",            // 容器內的網卡名稱"args": { ... },             // 額外參數（如 Kubernetes 傳遞的 Pod 元數據）"prevResult": { ... }        // 前一個插件的執行結果（插件鏈場景）
}

輸出結果：
- interfaces：分配的網卡列表（如 veth pair）。
- ips：分配的 IP 地址及網關。
- routes：路由規則。
- dns：DNS 配置。

示例輸出：

{"cniVersion": "1.0.0","interfaces": [{"name": "eth0","mac": "0a:58:0a:01:01:02","sandbox": "/proc/1234/ns/net"}],"ips": [{"version": "4","address": "10.1.1.2/24","gateway": "10.1.1.1"}]
}

4.2.DEL 接口

作用：釋放容器占用的網絡資源（如刪除 IP、清理路由、卸載網卡等）。
調用時機：
- 容器刪除時（如 Pod 終止時）。
- 容器離開網絡時（多網絡場景）。
輸入參數：
- 參數與 ADD 接口一致
輸出結果：
- 無特定輸出，但需返回成功（狀態碼 0）或失敗（非零狀態碼）。

4.3.CHECK 接口

作用：驗證容器的網絡配置是否正常（如 IP 是否有效、路由是否存在）。
調用時機：
- 容器運行過程中定期檢查。
- 容器網絡異常時主動觸發。
輸入參數：
- 與 ADD 接口一致，但需要 prevResult 字段（即 ADD 接口的輸出結果）。
輸出結果：
- 無特定輸出，但需返回成功（狀態碼 0）或失敗（非零狀態碼）。

4.4.VERSION 接口

作用：報告插件支持的 CNI 版本列表。
調用方式：
- 容器運行時通過命令行參數 --version 調用插件。

輸出結果：

{"cniVersion": "1.0.0","supportedVersions": ["0.4.0", "1.0.0"]
}

Kubernetes控制平面組件：Kubelet詳解（七）：容器網絡接口 CNI

1.kubernetes網絡模型

1.1.kubernetes網絡模型分類

1.2.pod 之間通信的基本原則

1.2.1.pod間通信基本原則

1.2.2.如何理解 pod 間通信無需NAT轉換

2.CNI（Container Network Interface）接口設計

2.1.CNI 的發展歷程

2.2.CNI 的職能

2.3.CNI 插件分類及常見插件

2.4.CNI工作原理

2.4.1.CNI 插件配置

2.4.2.CNI 插件可執行文件

2.4.3.CNI插件生效原理

2.4.4.CNI 與 kubelet 聯動

2.5.CNI 插件的設計考量

2.6.pod Ip的分配過程簡述

3.CNI 插件

3.1.常見CNI插件

3.2.Flannel

3.3.Calico

3.3.1.pod ip 規劃方案

3.3.1.1.直接給pod分配 基礎架構中的真實ip

3.3.1.2.為pod分配虛擬ip

3.3.2.Calico的pod通信方案

3.3.2.1.Calico 支持 IPinIP 模式

3.3.2.2. Calico 支持 VxLAN 模式

3.3.2.3. Calico 支持 BGP 路由協議模式

3.3.3.Calico節點初始化

3.3.3.1.Calico DaemonSet

3.3.3.2.很多CNI插件采用DaemonSet初始化

3.3.4.Calico配置一覽

3.3.5.Calico實現原理

3.3.5.1.Calico 自帶眾多CRD

3.3.5.2.如何查看calico的通信模式

3.3.5.3.節點內pod通信實踐

3.3.5.4.跨節點的pod通信實踐：BIRD

3.4.CNI plugin 對比

4.CNI 接口

4.1.ADD接口

4.2.DEL 接口

4.3.CHECK 接口

4.4.VERSION 接口

相關文章

3.3.1.1.直接給pod分配基礎架構中的真實ip