【K8s】专题十五（2）：Kubernetes 网络之 CNI
本文内容均来自个人笔记并重新梳理，如有错误欢迎指正！
如果对您有帮助，烦请点赞、关注、转发、订阅专栏！
专栏订阅入口
| 精选文章 | Kubernetes | Docker | Linux | 羊毛资源 | 工具推荐 |
往期精彩文章
【Docker】（全网首发）Kylin V10 下 MySQL 容器内存占用异常的解决方法
目录
一、基本介绍
在 Kubernetes 中，CNI（Container Network Interface，容器网络接口）是一个标准化的网络模型接口，负责定义容器如何在网络层面进行交互和通信。
CNI 采用一种插件化机制，支持集成不同的网络方案。在容器创建过程中，Kubelet 组件通过调用所需的 CNI 插件，即可使用相应的网络方案完成容器的网络配置，实现灵活的容器网络连接、网络资源释放等功能。常见的 CNI 插件包括 Calico、Flannel、Cilium 等。
由此，CNI 通过标准化接口和插件化机制，为 Container Runtime（容器运行时）和 CNI 插件之间提供了一个通用接口，增强了 Kubernetes 网络的灵活性和可扩展性。
GitHub 地址：containernetworking/cni - GitHub
CNI 规范文档：SPEC.md
二、基本流程
- 创建配置文件：CNI 插件安装完成后，会为每个 Node 节点创建 CNI 配置文件（如 /etc/cni/net.d/xxnet.conf），用于定义 CNI 插件的类型和配置
- 调用插件：Kubelet 组件根据 CNI 配置文件调用相应的 CNI 插件，通常可以完成 ADD、CHECK、DELETE、GC 和 VERSION 五种操作
- 创建接口设备：CNI 插件为 Node 节点和容器的网络命名空间创建 veth-pair 设备，该设备一端位于容器中，命名为 eth0，另一端位于 Node 节点中，命名为 vethxxxx 形式
- 分配地址：CNI 插件调用 IPAM 模块，为 Pod 分配互不冲突的 IP 地址
- IPAM（（IP Address Management，IP 地址管理）模块负责分配和管理 Pod 的 IP 地址
- 配置规则：CNI 插件通过配置必要的路由规则和 iptables 规则，以确保 Pod 之间及 Pod 与外部网络的通信
三、CNI 与 CRI 协作
在 Kubernetes 中，CRI（Container Runtime Interface，容器运行时接口）是负责管理容器运行时的标准化接口。
CRI 通过调用 CNI 插件来配置或清理容器网络，以确保容器网络配置过程与容器生命周期（主要是容器创建、销毁过程）紧密协调。
以容器创建过程为例，CNI 与 CRI 协作流程大致如下：
- Kubelet 到 CRI：Kubelet 组件调用 CRI，为已完成 Node 节点调度的 Pod 创建容器
- CRI 到 Pod：CRI 在 Pod 中创建和启动容器
- Pod 到 CRI：Pod 中的所有容器启动运行后，向 CRI 返回信号
- CRI 到 Kubelet：CRI 通知 Kubelet 组件，容器已准备就绪
- Kubelet 到 CNI：Kubelet 组件调用 CNI 为 Pod 中的容器设置网络
- CNI 到 Pod：CNI 为 Pod 中的容器配置网络，将其连接到网络接口
- Pod 到 CNI：Pod 中的容器网络配置完成后，向 CNI 返回信号
- CNI 到 Kubelet：CNI 通知 Kubelet 组件，Pod 的网络已准备就绪
- Kubelet 到 Pod：Kubelet 组件与 Pod 进行交互，获取 Pod 状态等
四、其他相关
1、CNI 插件网络模式
- 覆盖网络（Overlay Network）
- CNI 插件通过 Overlay Network 模式，以 VXLAN 或 IPIP 等再次封装数据包后进行传输的方式，实现集群内 Pod 之间的互相访问，常见的有：
- Flannel 插件的 VXLAN 模式
- Calico 插件的 VXLAN、IPIP 模式
- CNI 插件通过 Overlay Network 模式，以 VXLAN 或 IPIP 等再次封装数据包后进行传输的方式，实现集群内 Pod 之间的互相访问，常见的有：
- 底层网络（Underlay Network）
- CNI 插件通过 Underlay Network 模式，以节点作为路由设备、Pod 学习路由条目的方式，实现复杂场景下（如跨集群、跨云环境）集群外部直接访问集群内 Pod，常见的有：
- Flannel 插件的 HOST-GW 模式
- Calico 插件的 BGP 模式
- Cilium 插件的 Native-Routing 模式
- CNI 插件通过 Underlay Network 模式，以节点作为路由设备、Pod 学习路由条目的方式，实现复杂场景下（如跨集群、跨云环境）集群外部直接访问集群内 Pod，常见的有：
2、Bridge 与 veth-pair
Bridge 和 veth-pair 都是 Linux 中的虚拟网络接口。
Pod 通过 veth-pair 将自己的 Network Namespace 与 Node 节点的 Network Namespace 打通，然后使用 Bridge 将所有 veth-pair 连接在一起，实现大量 Pod 之间的互通和管理。
常见的 Bridge 有 docker0（Docker 服务启动时自动创建的网桥）、tunl0（由 Calico 插件的 IPIP 模式创建）、vxlan.calico（由 Calico 插件的 VXLAN 模式创建）。
3、kube-proxy
kube-proxy 作为 Node 节点的一个组件，主要作用是监视 Service 对象和 Endpoint 对象的变化（添加、移除）并刷新负载均衡，即通过 iptables 或 IPVS 配置 Node 节点的 Netfilter，实现网络流量在不同 Pod 间的负载均衡，并为 Service 提供内部服务发现。
kube-proxy 和 CNI 插件本质上都只是为 Linux 内核提供配置，而实际的数据包处理仍由内核完成，因此面临以下问题：
- 随着集群中 Service 对象和 Pod 对象数量的增长，iptables 的规则匹配效率会下降，即使 IPVS 进行了优化依然面临性能开销
- 频繁的 Service 对象和 Pod 对象更新会导致规则重新应用，可能带来网络延迟或中断
- 强依赖于 Linux 内核的 Netfilter，一旦内核配置不当或不兼容，可能会引发网络问题
当前，Cilium 等插件通过 eBPF 等技术可以绕过 Linux 内核，直接在用户空间处理数据包，实现了无代理的服务流量转发，完全可以替代 kube-proxy。但需要注意在使用 Istio 的场景下，若出现诸如 Service 对象的 port 与 targetPort 不一致等情况，可能导致 Istio 无法命中对应的路由规则。
原文地址：https://blog.csdn.net/2401_82795112/article/details/143569949
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！