一种与OpenStack Neutron融合的Kubernetes网络插件方法
文献发布时间：2023-06-19 13:46:35
技术领域
本发明属于云计算技术领域，涉及一种容器网络插件，具体涉及一种与OpenStackNeutron融合的Kubernetes网络插件方法。
背景技术
据报道，随着互联网己经融入了人们的日常生活中，云计算技术也将在未来将迎来继续发展的大潮。随着容器技术的发展，容器技术和虚拟化技术已经成为一种被公众广泛认可的容器技术服务器资源共享方式，容器技术可以在按需构建容器技术操作系统实例的过程当中，为操作人员提供极大的灵活性。
实践显示，在有关技术发展的同时，安全也是急需解决的问题，如何保证云平台环境中数据安全，防止信息泄露和网络攻击带来的损失，将是云计算技术面临的重要挑战。
现有技术公开了大型云计算集群管理平台的主要功能包括管理众多的分布式计算机物理节点，按照用户的需求自动分配计算，存储，网络等物理资源，对用户而言，使用云计算环境与使用单一大型服务器的感受是相同的，其中不同的是，云环境可以根据不同的需求，或用户的申请动态调整所划分的资源量，资源得以更加高效的利用。
作为新一代的轻量化云计算技术，容器技术采用的是操作系统层面的虚拟化技术，Docker是其中的典型代表，它构建与Linux系统的命名空间机制由于其良好的封装性，无需反复的配置运行环境，避免了因为运行环境不一致而造成的应用无法正常部署运行的错误，几乎成为了容器技术的代名词。本申请以下讨论的容器技术，在没有特殊指明的情况下，即是Docker技术。
容器虚拟化技术的出现好解决了以上的问题。Docker为每个应用提供了一个完整、独立的运行环境，有其独立的文件系统，但是共享操作系统内核，这就在保证了虚拟机所带来的隔离性的基础之上，同时也降低了虚拟机搭载完整的客户端操作系统所带来的虚拟化层对性能的消耗。基于容器的云计算技术在今后势必成为业内的主流技术，目前将容器技术与虚拟机技术的融合计算模式还鲜有尝试，这种模式可以提高数据分析的效率，增强业务的灵活度，将是大数据技术发展的下一个方向。
OpenStack和Kubernetes均是目前主流的虚拟化资源平台，社区十分活跃，而两者又有明显不同。OpenStack是虚拟机技术平台的代表，而Kubernetes则是容器化技术的代表。实践显示，经过多年的发展，虚拟机技术和容器技术各有其优缺点和独特的适用场景。一般情况下，业内公识，认为基于Hypervisor的虚拟机技术因为拥有其独立的客户操作系统，运行在客户操作系统上的应用和软件享有完全独立且隔离的物理资源池，架构安全，隔离性高，而容器技术则是依托于主机操作系统，在此基础之上加以隔离，启动速度快，开销小，易于快速部署。
基于虚拟机和容器的虚拟化技术各有优势，可以预见，虚拟机与容器未来在云数据中心环境内必然是共同存在的，如何实现虚拟机与容器的融合部署是当前云平台建设的关键研究方向，在这种虚拟机与容器融合部署平台下，如何实现网络资源的融合和管理，也正是本申请拟解决的问题。
发明内容
本发明的目的是基于现有技术的基础与现状，提供一种容器网络插件，具体涉及一种与OpenStack Neutron融合的Kubernetes网络插件方法。
本发明结合OpenStack的Neutron组件在虚拟化网络方面的先天优势和Kubernetes在容器集群编排管理方面的发展，进行深度的融合，为容器应用部署的融合平台提供一个灵活的，可靠的网络解决方案。本发明以所述网络方案为基础，能为项目前期的开发人员和测试人员，以及项目上线之后的运维人员，提供简单有效部署和管理容器应用的功能。本发明中，在所述的容器虚拟机的融合平台中，虚拟机和容器的虚拟网络均由Neutron实现，体现了网络资源融合的特点。在此基础之上，能充分发挥Kubernetes提供对容器编排的监视功能，故障替换，弹性伸缩，负载均衡的功能。
本发明中基于现有技术中，Kubernetes使用了一种相对简单的网络架构，每个容器组被分配到属于物理机docker网桥内的IP地址，因此位于同一物理机节点的容器组之间可以互相连通；在小规模的云计算环境中，这种模式可以被使用，减少开发成本，降低管理难度，但是在大型，复杂的云环境之中，这种依赖于物理机网络的解决方案无法满足实际项目的需求；因此本申请基于Neutron虚拟网络，为Kubernetes提供一种容器网络插件的设计方案。
具体的，本发明的目的通过下述技术方案实现：
本发明提供一种容器网络插件，尤其是一种与OpenStack Neutron融合的Kubernetes网络插件方法，其特征在于，通过结合OpenStack的Neutron组件和Kubernetes在容器集群编排管理，为容器应用部署的融合平台提供一个灵活的，可靠的网络解决方案；具体包括：
(1)虚拟机与容器的网络融合
对于由OpenStack创建的容器，Kubernetes可以接管并发布容器应用，二者融合实现高效的容器编排调度；
(2)实现Kubernetes服务发现机制
基于OpenStack的负载均衡实例，创建Kubernetes service服务，向外提供服务发现的功能；
(3)租户隔离
同一租户下的Pod可以互相访问，不同租户下的Pod相互之间不可见，保证平台网络的隔离性；
(4)负载均衡策略的优化
基于后端容器的负载，实现动态的负载均衡策略。
本发明中，虚拟机与容器网络融合，所述的Neutron容器网络插件能实现Kubernetes中pod和service资源对象向OpenStack的转化；
所述的插件功能划分成两个模块：其中，
控制模块(Controller)：监听Kubernetes中关于pod和service的创建，更新，删除事件，并调用工作模块在Neutron中进行相应的操作；
工作模块(Neutron CNI)：调用Neutron API，完成容器网络和service的创建。
本发明中，所述的容器网络插件方法能实现Kubernetes服务发现机制，其中，由Load Balancer实例取代iptables负责流量的转发规则和具体实现，该种方式也为后续的功能拓展提供了基础，Load Balancer也同样提供一个虚拟的VIP作为外部访问服务的入口，endpoint的角色则由Neutron中的port来担当，负责容器与网络的连接。
本发明中，所述的租户隔离，利用OpenStack平台的Neutron组件，基于Open-vSwitch和Linux内核的网桥功能，形成一个功能丰富的从二层三层网络的虚拟SDN，其中主要借助于Neutron网络底层采用的Network Namespace机制，为每个虚拟网络提供一整套的虚拟网络设备，为每个用户提供一套独立虚拟的网络环境。
本发明中，所述的负载均衡策略的优化，采用根据后端系统的实时负载，动态规划流量转发规则的负载均衡策略。
本发明提供了一种与OpenStack Neutron融合的Kubernetes网络插件方法，其中包括：设计的基于Neutron的容器网络插件，从Kubernetes的CNI容器网络模型出发，为Neutron实现CNI模型接口，在Kubernetes中使用该插件，可以将容器网络建立在Neutron的虚拟网络之中，实现Kubernetes与OpenStack的网络融合；本发明在网络插件的基础上，提供了基于Load Balancer实例实现Kubernetes中service服务的解决方案，以OpenStack的Octavia项目为基础，将Kubernetes中的service服务转化为Load Balance实例，为后端容器提供了对外稳定的访问入口，实现了前后端解耦，提高了系统的可靠性。
本发明能解决在虚拟机与容器资源融合的应用场景下网络资源的融合问题，并保障高并发情况下云平台的资源吞吐量。
附图说明
图1为Neutron CNI的启动流程。
图2为Neutron CNI获取网络流程。
图3为Neutron CNI设置网络流程。
图4为Neutron CNI删除网络流程。
图5为Service和LoadBalancer的关系。
图6为容器网络插件工作模式。
图7为Kubernetes更新时间处理流程。
图8为租户隔离示意图。
图9为创建RepicationController资源的配置文件。
图10为Pod创建的结果。
图11为同租户同宿主机下Pod创建结果。
图12为同租户同宿主机下Ping测试结果。
图13为不同租户同宿主机下Pod创建结果。
图14为不同租户同宿主机下Ping测试结果。
图15为同租户不同宿主机下Pod创建结果。
图16为同租户不同宿主机下Ping测试结果。
图17为service对象配置文件。
图18为service创建结果。
图19为loadbalancer创建结果。
图20为外部访问Load Balancer VIP结果。
具体实施方式
实施例1
本发明结合OpenStack的Neutron组件在虚拟化网络方面的先天优势和Kubernetes在容器集群编排管理方面的发展，进行深度的融合，为容器应用部署的融合平台提供灵活的，可靠的网络解决方案；其中包括：
1)、虚拟机和容器网络融合
Kubernetes的网络采用了CNI的架构，为了解决容器网络问题，在已有的Neutron网络服务基础之上，以网络插件的形式整合Kubernetes，使用Neutron建立Pod网络。为了符合系统设计的维护和升级，因此遵循Kubernetes生态规范，以CNI网络模型为基础，将Neutron以第三方网络插件的形式接管Kubernetes的网络。本发明实现了Neutron CNI容器网络插件。使用该插件作为Kubernetes的网络插件，Neutron就可以接管Kubernetes集群中的容器网络。从Pod创建开始，apiserver向工作节点发送创建Pod的请求，工作节点的kubelet调用Neutron CNI容器网络插件，网络插件根据namespace，在Neutron中找到对应的子网，在子网上为容器分配相应的端口，完成容器网络的建立。
为了使Kubernetes能够正确地使用专利中开发的Neutron容器网络插件，当工作节点的kubelet启动时，需要对其启动配置流程加以改进，如图1所示，在kubelet启动过程中，默认情况下，kubelet会在/opt/cni/目录下寻找可用的cni插件，在此目录下添加10-Neutron-cni.conf文件，内容如下：
{
"cniVersion":"0.1.0",
"name":"Neutron",
"type":"Neutron-cni",
"conf":"/etc/Neutron/Neutron-cni.conf",
"debug":true
}
当kubelet启动时，会自动在/opt/cni/目录下寻找可用的CNI网络插件，顺序为文件名按字符串顺序由小到大的第一个文件，在本系统中即是10-Neutron-cni.conf文件，配置文件中conf字段写明了Neutron容器网络插件的详细配置文件路径；
容器网络的CNI模型要求提供网络的查询，创建，删除，等一系列操作。包括获取网络，设置网络，删除网络三个模块；
获取网络：
Kubernetes的租户可以拥有多个命名空间(namespace)，每个命名空间对应OpenStack的一个子网(subnet)，如图2所示，该接口接受一个pod的信息，根据pod所属的命名空间，返回对应OpenStack中的子网，并在pod的信息中指定该子网；
通过调用获取网络接口，可以获得pod所属命名空间对应的子网网络信息。网络信息的数据结构如下表所示：
设置网络：
该方法用于将pod与pod所属的子网进行绑定，根据pod所属的命名空间信开始获取Namespace数据在子网上为pod创建端口返回网络信息获得Namespace对应的subnet信息绑定pod到指定端口；
如图3所示，在pod对应的子网上通过创建端口，将pod和子网相连，完成pod的网络设置，设置完成之后pod的网络信息中包含了pod的IP地址，以及pod所属命名空间对应子网的网络信息，具体如下表所示：
删除网络：
如图4所示，该方法会删除一个命名空间对应的子网，在删除之前需要清理其绑定的网络信息，如Pod，端口；如果删除之前仍有未清理的信息，删除不能继续进行，该方法会返回失败；所以在删除一个网络之前，其绑定的网络资源也要被释放。
2)实现Kubernetes服务发现机制
根据service和load balancer的概念，可以发现两者在功能和结构上有一定相似之处，这也是本申请选择用load balancer实现service的基础，两者的对应关系如下表所示：
(1)具体设计：
Neutron容器网络插件实现了Kubernetes中pod和service资源对象向OpenStack的转化，在具体设计时，将插件的功能划分成两个模块：
控制模块(Controller)：监听Kubernetes中关于pod和service的创建，更新，删除事件，并调用工作模块在Neutron中进行相应的操作；
工作模块(Neutron CNI)：调用Neutron API，完成容器网络和service的创建；
如图5所示，本申请中由Load Balancer实例取代iptables负责流量的转发规则和具体实现，该方式也为后续的功能拓展提供了基础；Load Balancer也同样提供一个虚拟的VIP作为外部访问服务的入口，endpoint的角色则由Neutron中的port担当，负责容器与网络的连接。而容器网络对应Neutron中的子网(subnet)，相比直接使用docker容器网络，Neutron网络插件所创建的网络可以进行更多的定制，比如租户隔离功能；
Neutron容器网络插件实现了Kubernetes中pod和service资源对象向OpenStack的转化；在具体设计时，本申请将插件的功能划分成两个模块：
控制模块(Controller)：监听Kubernetes中关于pod和service的创建，更新，删除事件，并调用工作模块在Neutron中进行相应的操作；
工作模块(Neutron CNI)：调用Neutron API，完成容器网络和service的创建；
所述容器网络插件与Kubernetes和OpenStack结合的工作模式如图6所示；
所述控制模块监听Kubernetes的api-server，对于Pod的更新，删除事件，工作模块调用Neutron API，为容器完成网络的创建与配置；对于service的更新，删除时间，工作模块会调用Octavia的API创建Load Balancer，并根据service的配置设置相应的负载均衡规则；当Kubernetes创建Pod成功后，将会通过api-server监听到Pod创建的信息，该个信息以POST的HTTP请求的方式发送，所有关于Pod的配置信息都以json的形式封装在请求体当中；
在收到所述创建事件的信息之后，监听器会从上述HTTP请求事件中提取容器组网络相关配置，并将其放入共享字典中；所述服务器是一个常规的WSGI服务器，它将回答CNI驱动程序调用，当CNI请求到来时，Server正在等待VIF对象出现在共享字典中，由于注释是从Kubernetes API读取的，并通过Watcher线程添加到注册表中，因此Server最终将获得它需要连接到给定Pod的VIF，然后等待VIF在返回到CNI驱动程序之前变为活动状态，从Pod对象注释加载VIF对象后，网络插件程序调用ov_vif库执行Pod插入和拔出操作，当Pod的插入和拔出作业完成，并且所有网络的插接均完成后，控制权将会返回给kubelet，在Neutron最初创建端口处于“停止”状态的情况下，CNI驱动程序将插入Pod，但必须在将控制权返回给调用者之前，将Pod注释的vif状态更改为“激活”；
(2)启动流程
在启动时，控制模块需要分别经过OpenStack和Kubernetes的认证，与平台建立通信，在此之后API正常工作；
首先向OpenStack Identity API发送POST请求，请求认证token，这里的IdentityAPI实际上就是keystone认证接口，请求体中需要提供用户名，密码和用户所属的域，
如果认证成功，将获得200OK响应报文，其中响应body包含了一个token和过期时间，前者格式为"id":"token"，后者格式为"expires":"datetime"；在获得了这个token之后，就可以向service endpoint发送请求，在请求header里添加token就可以通过keystone的认证，这里token只是管控用户对服务的进入，但是不管控用户在服务里面的具体操作类型，请求的头部内容如下：
在成功通过Kubernetes认证并建立链接之后，还要再Kubernetes集群中为容器网络的控制模块进行授权，在授权环节中，具体的访问对象是KubernetesAPI的各种属性所对应的路径，包括：用户，组，路径(比如：/api/v1、/healthz、/version等)，以及具体的请求动作类型(比如：get、list、create等)，APIServer会将这些属性值与事先配置好的访问策略(access policy)相比较，APIServer支持多种认证模式，包括Node、RBAC、Webhook等；
APIServer启动时，可以指定一种认证模式，也可以指定多种模式，如果是后者，只要API收到的请求通过了其中一种模式的授权，那么该环节的最终结果就是授权成功；在本申请中启动的Kubernetes集群的apiserver初始配置中，认证模式的默认配置是”Node,RBAC”，Node授权器主要用于各个工作节点上的kubelet访问apiserver时使用的，其他一般均由RBAC授权器来授权；
(3)工作流程
在启动并认证成功之后，控制模块会持续监听Kubernetes的api-server，监听的内容是pod和service资源的变化情况，包括新对象的生产，以及已有对象的动态变化，对于监听器收到的每一个新的Kubernetes事件，控制模块都会生成一个单独的EventHandler类进行处理，EventHandler具有以下表所示统一的接口：
async():
EventHandler以异步的方式调用API接口，所有的线程会首先提交到任务队列，提交之后由线程池从队列中取出任务分配线程处理；对于pod和service这两种资源有各自的任务队列和线程池。上述操作的有益效果为在处理大量的并发请求时，不会引起大量的线程调用和线程间切换，减少系统资源的消耗；
retry():
在异步处理过程中，如果调用API的返回的结果为失败，或者API调用超时，调用retry接口会首先回滚之前失败之前的所有改动，回滚完成之后重新开始任务的处理，重试超过一定次数之后停止重试，报告任务失败信息；
logException():
用于任务失败时的处理；
当一个Kubernetes事件来到时，首先判断事件所对应的资源对象类型，分别提交到对应的任务队列，当线程池中有空闲线程时，会从任务队列中取出为处理的任务分发到空闲线程当中，最终返回处理结果；
2、租户网络隔离
由于本发明所设计的系统是基于OpenStack平台之上的，而OpenStack的Neutron组件，基Open-vSwitch和Linux内核的网桥功能，形成了一个功能丰富的从二层三层网络的虚拟SDN，引入容器之后，借助于OpenStack平台现有的功能支持，可以实现容器网络的构建和用户隔离，主要借助于Neutron网络底层采用的Network Namespace机制，能够为每个虚拟网络提供一整套的虚拟网络设备，这些虚拟网络设备都认为其是独自占用了整个物理机的网络资源，这样就能够为每个用户提供一套独立虚拟的网络环境；
Kubernetes中一个租户下可有多个命名空间，容器组则位于这些命名空间之下，原生的Kubernetes系统中，同一命名空间下所有的容器组都可以互通，在本申请所述系统中，Kubernetes的网络由Neutron负责，租户对应Neutron中的网络，租户下的命名空间对应Neutron中网络下的子网，基于这种规则，可以实现租户之间的网络隔离；
默认情况下，同一租户下的命名空间处于不同的子网，因此，这些命名空间之间是三层隔离的，互相不可见；如果想要同一租户下的不同命名空间的pod可以互相访问，只需在为不同的子网之间配置路由规则，即可实现不同命名空间之间的通信。
实施例2
1、实验环境
容器网络插件是基于一个虚拟机和容器混合的工作场景，所以首先需要分别搭建Kubernetes和OpenStack平台。本次实验在三台物理机上进行，具体的角色分工如下表：
以controller作为OpenStack的控制节点，compute作为计算节点，另有一台服务器作为Kubernetes集群的master节点；
1、使用Neutron网络插件提供容器网络
Kubernetes使用TLS证书进行身份认证和授权，首要需要配置Kubernetes证书信息，参数如下：
[kubernetes]
api_root＝https://10.10.87.63:6443
ssl_ca_crt_file＝/etc/Neutron/ca.crt
ssl_verify_server_crt＝True
ssl_client_crt_file＝/etc/Neutron/kubelet-client.crt
ssl_client_key_file＝/etc/Neutron/kubelet-client.key
能够成功监听了Kubernetes的API server后，还需要通过OpenStack认证以调用OpenStack API，参数如下：
[Neutron]
auth_uri＝http://10.10.87.61:5000
auth_url＝http://10.10.87.61:35357
project_domain_name＝Default
project_name＝service
user_domain_name＝Default
project_domain_id＝default
user_domain_id＝default
auth_uri指定了OpenStack的认证API，auth_url指定了Neutron的调用API。配置成功之后，就可以启动容器网络插件的监听模块；
在Kubernetes中创建一个容器组，需要首先创建RepicationController资源，该资源根据定义的副本数创建相应数量的容器组。创建RepicationController资源的配置文件如图9所示；
图10中的结果验证了容器组的创建，以及容器组IP地址的分配；
2、租户隔离验证
验证网络连通性，采用PING的方法进行测试，从A容器组向B容器组发起PING测试，如果可达则认为网络是连通的，不可达则认为网络是隔离的，相互不可见；实验分别从同租户同宿主机，不同租户同宿主机，同租户不同宿主机，这三种情况加以验证；验证同租户之间的网络相通，而不同租户之间网络隔离；
图11，图12显示了同租户同宿主机下测试结果，实验结果说明同租户同宿主机下容器组可以相互通信；
图13，图14显示了不同租户同宿主机下测试结果，实验结果说明不同租户下容器组不可以相互通信，租户之间网络是相互隔离的；
图15，图16显示了同租户不同宿主机下测试结果，实验结果说明同租户不同宿主机下容器组可以相互通信；
3、负载均衡实例验证
在Kubernetes中将容器组对外发布为service之后，监听API server的控制模块会收到service创建的事件信息，读取service中的endpoint，pod等信息，调用OpenStackAPI，创建对应的资源，用Load Balancer实例实现service资源对象，所述流程的功能如下述，
首先创建一个deployment对象，并将其发布为service对象，配置如图17所示，该个deployment对象负责创建副本数为2的容器组，容器的标签命名为“app:nginx”，在service的定义中，选择所有标签为app:nginx”的容器，将容器的80端口与service IP的80端口进行了映射，访问
创建了Cluster IP为10.2.247.122的service对象，与此同时，容器网络插件控制模块会监听到此次service创建的事件信息，并调用OpenStackAPI，创建Load Balancer实例，创建结果如图19所示；
在Load Balancer实例创建完成之后，结果发现，Load Balancer实例的VIP与前文Kubernetes中的service IP是一致的，10.2.247.122，保证了Load Balancer能够向外提供service服务；
附图20所示的结果表明能够从外部访问service暴露的虚拟service IP。