CNI（Container Network Plugin）

喝醉酒的小白

已于 2023-08-05 18:15:01 修改

阅读量981

点赞数 1

分类专栏： K8s 文章标签：网络 linux 运维

于 2022-08-03 23:00:58 首次发布

本文链接：https://blog.csdn.net/hezuijiudexiaobai/article/details/126150284

版权

K8s 专栏收录该内容

185 篇文章 3 订阅

订阅专栏

CNI

容器网络模型

CNI是容器引擎与遵循该规范网络插件的中间层，专用于为容器配置网络子系统，目前由RKT、Docker、Kubernetes、OpenShift和Mesos等相关的容器运行时环境所运行。通常，遵循CNI规范的网络插件是一个可执行程序文件，它们可由容器编排系统（例如Kubernetes等）调用，负责向容器的网络名称空间插入一个网络接口并在宿主机上执行必要的任务以完成虚拟网络配置，因而通常被称为网络管理插件，即NetPlugin。随后，NetPlugin还需要借助IPAM插件为容器的网络接口分配IP地址，这意味着CNI允许将核心网络管理功能与IP地址分配等功能相分离，并通过插件组合的方式堆叠出一个完整的解决方案。简单来说，目前的CNI规范主要由NetPlugin和IPAM两个插件API组成，如图如示：

在这里插入图片描述
CNI（Container Network Plugin）规范由CoreOS提出，并被Kubernetes采纳。当前container networking/cni项目实现了CNI接口规范。containernetworking/cni项目针对Linux container的网络配置提供了指定的接口以及具体的插件实现。宏观上来看，cni所做的很简单，就是将容器加入到一个网络中，并且保证容器之间的连通性。具体的实现方案由底层的不同cni插件来实现。

网络插件 & IPAM

▪网络插件也称Main插件，负责创建/删除网络以及向网络添加/删除容器，它专注于连通容器与容器之间以及容器与宿主机之间的通信，同容器相关的网络设备通常都由该类插件所创建，例如Bridge、IP VLAN、MAC VLAN、loopback、PTP、VETH以及VLAN等虚拟设备。

▪IPAM（IP Address Management），该类插件负责创建/删除地址池以及分配/回收容器的IP地址；目前，该类型插件的实现主要有host-local和dhcp两个，前一个基于预置的地址范围进行地址分配，而后一个通过DHCP协议获取地址。显然，NetPlugin是CNI中最重要的组成部分，它才是执行创建虚拟网络、为Pod生成网络接口设备，以及将Pod接入网络中等核心任务的插件。为了能够满足分布式Pod通信模型中要求的所有Pod必须在同一平面网络中的要求，NetPlugin目前常用的实现方案有Overlay网络（Overlay Network）和Underlay网络（Underlay Network）两类。

显然，NetPlugin是CNI中最重要的组成部分，它才是执行创建虚拟网络、为Pod生成网络接口设备，以及将Pod接入网络中等核心任务的插件。为了能够满足分布式Pod通信模型中要求的所有Pod必须在同一平面网络中的要求，NetPlugin目前常用的实现方案有Overlay网络（Overlay Network）和Underlay网络（Underlay Network）两类。

▪Overlay网络借助VXLAN、UDP、IPIP或GRE等隧道协议，通过隧道协议报文封装Pod间的通信报文（IP报文或以太网帧）来构建虚拟网络。
▪Underlay网络通常使用direct routing（直接路由）技术在Pod的各子网间路由Pod的IP报文，或使用Bridge、MAC VLAN或IP VLAN等技术直接将容器暴露给外部网络。

其实，Overlay网络的底层网络也就是承载网络，因此，Underlay网络的解决方案也就是一类非借助隧道协议而构建的容器通信网络。相较于承载网络，Overlay网络由于存在额外的隧道报文封装，会存在一定程度的性能开销。然而，用户在不少场景中可能会希望创建跨越多个L2或L3的逻辑网络子网，这就只能借助Overlay封装协议实现。为Pod配置网络接口是NetPlugin的核心功能之一，但不同的容器虚拟化网络解决方案中，为Pod的网络名称空间创建虚拟接口设备的方式也会有所不同，目前，较为注流的实现方式有veth（虚拟以太网）设备、多路复用及硬件交换3种

在这里插入图片描述
▪veth设备：创建一个网桥，并为每个容器创建一对虚拟以太网接口，一个接入容器内部，另一个留置于根名称空间内添加为Linux内核桥接功能或OpenvSwitch（OVS）网桥的从设备。

▪多路复用：多路复用可以由一个中间网络设备组成，它暴露多个虚拟接口，使用数据包转发规则来控制每个数据包转到的目标接口；MAC VLAN技术为每个虚拟接口配置一个MAC地址并基于此地址完成二层报文收发，IP VLAN则是分配一个IP地址并共享单个MAC，并根据目标IP完成容器报文转发。

▪硬件交换：现今市面上有相当数量的NIC都支持SR-IOV（单根I/O虚拟化），SR-IOV是创建虚拟设备的一种实现方式，每个虚拟设备自身表现为一个独立的PCI设备，并有着自己的VLAN及硬件强制关联的QoS；SR-IOV提供了接近硬件级别的性能。
在这里插入图片描述

Cilium 部署使用

在这里插入图片描述

cni接口

cat /etc/cni/net.d/05-cilium.conf

组件

ks get pod -o wide |grep cilium

cilium-operator-6dfdc68fff-922lq 
cilium-d5rvk

cilium-operator 是负责管理和操作 Cilium 集群的组件，而 cilium 是实际运行 Cilium 代理的组件。它们一起工作，以确保网络流量的安全和可靠传输，并提供网络策略、路由、负载均衡等功能。

配置

ks get cm cilium-config -o yaml|more

  cluster-pool-ipv4-cidr: 245.0.0.0/8
  cluster-pool-ipv4-mask-size: "24"
  identity-allocation-mode: crd

这是一组关于 IP 地址的配置参数：

cluster-pool-ipv4-cidr：表示集群池的 IPv4 CIDR（无类别域间路由选择），即 IP 地址块的范围。在此示例中，CIDR 是 245.0.0.0/8，表示使用 8 位作为网络前缀，剩下的 24 位可供主机分配。
cluster-pool-ipv4-mask-size：表示子网掩码的大小，也称为网络前缀长度。在此示例中，子网掩码大小为 “24”，意味着前 24 位用于网络标识，后面的 8 位用于主机标识。

综上所述，这些参数配置用于定义一个 IPv4 地址块的范围，并指定了网络前缀和子网掩码的大小。

identity-allocation-mode: crd 是一种身份分配模式，其作用是在 Kubernetes 集群中为自定义资源（Custom Resource）分配唯一的标识符。

在 Kubernetes 中，CRD 是一种扩展机制，允许用户定义自己的资源类型。使用 CRD，用户可以创建和管理与 Kubernetes 内置资源不同的自定义资源。例如，用户可以创建一个名为 “MyApp” 的自定义资源，用于管理应用程序的部署、配置和监视等方面。

当启用 identity-allocation-mode: crd 时，Kubernetes 将为每个创建的 CRD 分配一个唯一的标识符。这些标识符通常采用全局唯一的名称，以确保集群中的每个 CRD 都有一个独立的身份。这对于跟踪和管理自定义资源非常重要，因为它们可以像任何其他 Kubernetes 资源一样由控制器进行操作。

通过为 CRD 分配唯一的身份，Kubernetes 可以确保正确地处理和管理自定义资源，并将其集成到整个集群生态系统中。这使得用户能够根据自己的需求扩展和定制 Kubernetes 功能，同时仍能受益于 Kubernetes 提供的强大特性和功能。

网卡

ip a|grep cilium


cilium_net@cilium_host
cilium_host@cilium_net
cilium_vxlan
lxc7b5f92c34461
lxc_health

cilium_net@cilium_host: 这是一个网络标识符，表示位于cilium_host上的cilium_net。cilium_net可以是一个网络命名空间、容器或者其他类型的网络实体。
cilium_host@cilium_net: 这是一个网络标识符，表示位于cilium_net上的cilium_host。它可能是一个主机、虚拟机或者其他类型的网络实体。
cilium_vxlan: 这是Cilium项目中的一个组件，用于实现基于VXLAN（Virtual Extensible LAN）的网络隔离和通信。VXLAN是一种在底层网络之上创建虚拟网络的技术，可以扩展现有网络的规模，并提供更好的隔离性能。
lxc7b5f92c34461: 这是一个容器的ID，表示一个特定的Linux容器实例。每个容器都有一个唯一的ID，用于标识和管理容器。容器是一个独立运行的进程集合，通过虚拟化技术将其与主机环境隔离开来。
在 Cilium 中，lxc_health 网卡是一个特殊的网络接口，用于实现容器健康检查。它被用作与容器运行时（如Docker或Kubernetes）进行通信的通道。

lxc_health 网卡的作用是收集容器健康状态信息，并将其报告给 Cilium 控制平面。通过监视 lxc_health 接口上的流量，Cilium 可以实时了解容器的健康状况，并针对性地应用网络策略。

具体而言，lxc_health 网卡允许 Cilium：

检测容器是否处于运行状态：通过监视 lxc_health 接口上的数据包，Cilium 可以确定容器是否正在运行。如果容器停止发送或响应 lxc_health 数据包，Cilium 将推断容器已经关闭或者出现故障。
动态更新网络策略：一旦 Cilium 检测到容器健康状态发生变化，它可以根据容器的状态自动调整网络策略。例如，在容器变为不健康状态时，Cilium 可以立即拒绝该容器的网络请求。

总而言之，lxc_health 网卡在 Cilium 中起到了重要的作用，它使得 Cilium 能够实时监控容器的健康状态，并根据需要动态调整网络策略，从而提供更可靠和安全的容器网络环境。

路由

route -n|grep 10.244

常用命令

cilium -h

cilium status

Cilium & Hubble

cilium 学习和安装

eBPF 完美搭档：连接云原生网络的 Cilium

喝醉酒的小白

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
CNI（Container Network Plugin）

CNI（Container Network Plugin）规范由CoreOS提出，并被Kubernetes采纳。当前container networking/cni项目实现了CNI接口规范。containernetworking/cni项目针对Linux container的网络配置提供了指定的接口以及具体的插件实现。宏观上来看，cni所做的很简单，就是将容器加入到一个网络中，并且保证容器之间的连通性。具体的实现方案由底层的不同cni插件来实现。............
复制链接

扫一扫