K8S中 CNI 插件的解读

辰星12个月前技术文章532


一.CNI是什么

首先我们介绍一下什么是 CNI,它的全称是 Container Network Interface,即容器网络的 API 接口。

它是 K8s 中标准的一个调用网络实现的接口。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式,实现了这个接口的就是 CNI 插件,它实现了一系列的 CNI API 接口。常见的 CNI 插件包括 CalicoflannelTerwayWeave Net 以及 Contiv

 

二.k8s中如何使用cni

K8s 通过 CNI 配置文件来决定使用什么 CNI

基本的使用方法为:

1.    首先在每个结点上配置 CNI 配置文件(/etc/cni/net.d/xxnet.conf),其中 xxnet.conf 是某一个网络配置文件的名称;

image.png

 

2.   安装 CNI 配置文件中所对应的二进制插件;

3.   在这个节点上创建 Pod 之后,Kubelet 就会根据 CNI 配置文件执行前两步所安装的 CNI 插件;

4.   上步执行完之后,Pod 的网络就配置完成了。

具体的流程如下图所示:

 image.png

在集群里面创建一个 Pod 的时候,首先会通过 apiserver Pod 的配置写入。apiserver 的一些管控组件(比如 Scheduler)会调度到某个具体的节点上去。Kubelet 监听到这个 Pod 的创建之后,会在本地进行一些创建的操作。当执行到创建网络这一步骤时,它首先会读取刚才我们所说的配置目录中的配置文件,配置文件里面会声明所使用的是哪一个插件,然后去执行具体的 CNI 插件的二进制文件,再由 CNI 插件进入 Pod 的网络空间去配置 Pod 的网络。配置完成之后,Kuberlet 也就完成了整个 Pod 的创建过程,这个 Pod 就在线了。

 

三.如何选择CNI插件

image.png 

1. 环境限制

不同环境中所支持的底层能力是不同的。

  • 虚拟化环境(例如 OpenStack)中的网络限制较多,比如不允许机器之间直接通过二层协议访问,必须要带有 IP 地址这种三层的才能去做转发,限制某一个机器只能使用某些 IP 等。在这种被做了强限制的底层网络中,只能去选择 Overlay 的插件,常见的有 Flannel-vxlan, Calico-ipip, Weave 等等;

  • 物理机环境中底层网络的限制较少,比如说我们在同一个交换机下面直接做一个二层的通信。对于这种集群环境,我们可以选择 Underlay 或者路由模式的插件。Underlay 意味着我们可以直接在一个物理机上插多个网卡或者是在一些网卡上做硬件虚拟化;路由模式就是依赖于 Linux 的路由协议做一个打通。这样就避免了像 vxlan 的封包方式导致的性能降低。这种环境下我们可选的插件包括 clico-bgp, flannel-hostgw, sriov 等等;

  • 公有云环境也是虚拟化,因此底层限制也会较多。但每个公有云都会考虑适配容器,提升容器的性能,因此每家公有云可能都提供了一些 API 去配置一些额外的网卡或者路由这种能力。在公有云上,我们要尽量选择公有云厂商提供的 CNI 插件以达到兼容性和性能上的最优。比如 Aliyun 就提供了一个高性能的 Terway 插件。

环境限制考虑完之后,我们心中应该都有一些选择了,知道哪些能用、哪些不能用。在这个基础上,我们再去考虑功能上的需求。

2. 功能需求

 

  • 首先是安全需求;

K8s 支持 NetworkPolicy,就是说我们可以通过 NetworkPolicy 的一些规则去支持“Pod 之间是否可以访问”这类策略。但不是每个 CNI 插件都支持 NetworkPolicy 的声明,如果大家有这个需求,可以选择支持 NetworkPolicy 的一些插件,比如 Calico, Weave 等等。

  • 第二个是是否需要集群外的资源与集群内的资源互联互通;

大家的应用最初都是在虚拟机或者物理机上,容器化之后,应用无法一下就完成迁移,因此就需要传统的虚拟机或者物理机能跟容器的 IP 地址互通。为了实现这种互通,就需要两者之间有一些打通的方式或者直接位于同一层。此时可以选择 Underlay 的网络,比如 sriov 这种就是 Pod 和以前的虚拟机或者物理机在同一层。我们也可以使用 calico-bgp,此时它们虽然不在同一网段,但可以通过它去跟原有的路由器做一些 BGP 路由的一个发布,这样也可以打通虚拟机与容器。

  • 最后考虑的就是 K8s 的服务发现与负载均衡的能力

K8s 的服务发现与负载均衡就是 K8s 的 Service,但并不是所有的 CNI 插件都能实现这两种能力。比如很多 Underlay 模式的插件,在 Pod 中的网卡是直接用的 Underlay 的硬件,或者通过硬件虚拟化插到容器中的,这个时候它的流量无法走到宿主机所在的命名空间,因此也无法应用 kube-proxy 在宿主机配置的规则。

这种情况下,插件就无法访问到 K8s 的服务发现。因此大家如果需要服务发现与负载均衡,在选择 Underlay 的插件时就需要注意它们是否支持这两种能力。

经过功能需求的过滤之后,能选的插件就很少了。经过环境限制和功能需求的过滤之后,如果还剩下 3、4 种插件,可以再来考虑性能需求。



性能需求

·     Pod 的创建速度

当我们创建一组 Pod 时,比如业务高峰来了,需要紧急扩容,这时比如说我们扩容了 1000 Pod,就需要 CNI 插件创建并配置 1000 个网络资源。Overlay 和路由模式在这种情况下的创建速度是很快的,因为它是在机器里面又做了虚拟化,所以只需要调用内核接口就可以完成这些操作。但对于 Underlay 模式,由于需要创建一些底层的网络资源,所以整个 Pod 的创建速度相对会慢一些。因此对于经常需要紧急扩容或者创建大批量的 Pod 这些场景,我们应该尽量选择 Overlay 或者路由模式的网络插件。

·     Pod 的网络性能

主要表现在两个 Pod 之间的网络转发、网络带宽、PPS 延迟等这些性能指标上。Overlay 模式的性能较差,因为它在节点上又做了一层虚拟化,还需要去封包,封包又会带来一些包头的损失、CPU 的消耗等,如果大家对网络性能的要求比较高,比如说机器学习、大数据这些场景就不适合使用 Overlay 模式。这种情形下我们通常选择 Underlay 或者路由模式的 CNI 插件。

 


相关文章

MongoDB的SQL优化

一、MongoDB查询优化器1、MongoDB查询优化器1)MongoDB查询优化器会选择最优的一条执行计划来执行SQL。2)查询优化器会缓存那些有多条可用索引的SQL的执行计划条目2、查询优化器原理...

Solr常用API详细操作

Solr常用API详细操作

1. 监督集群的状态和统计返回监督器(overseer)的当前状态,各种监督器API的性能统计信息以及每种操作类型的最近10次故障/admin/collections?action=OVERSEERS...

clickhouse对接集群hdfs(二)

clickhouse对接集群hdfs(二)

前提:集群中已经部署了hadoop集群和clickhouse集群,clickhouse集群进行对接hdfs1、调整配置文件将集群中的hdfs-site.xml文件同步到ck集群节点的/etc/clic...

MySQL 复制-半同步搭建及原理

MySQL 复制-半同步搭建及原理

前言MySQL 半同步复制解决了什么问题?在传统主从架构中,主库实例提交事务与发送二进制日志是异步的,也就是说从库是否成功接收到二进制日志不会影响到主库事务提交,因此可能会出现  “主库发生宕机,主库...

可观测未来OpenTelemertry-结构化数据价值

可观测未来OpenTelemertry-结构化数据价值

前言开源软件和云供应商的软件开发模式已经改变了我们构建和部署软件的方式。集成开源软件,我们可以在很短时间内构建和部署一个应用程序。但这并不意味着使用和维护它们也变得更简单,随着应用程序的扩充,程序的调...

磁盘存储和文件系统详解

磁盘存储和文件系统详解

1、磁盘结构设备文件:关联至一个设备驱动程序,进而能够与之对应硬件设备进行通信I/O Ports:I/O 设备地址一切皆文件:open(),read(),write(),close()设备类型:块设备...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。