CN114615268A - 基于Kubernetes集群的服务网络、监控节点、容器节点及设备 - Google Patents

Abstract

一种基于Kubernetes集群的服务网络、监控节点、容器节点及设备，所述服务网络包括：主控节点，至少一个监控节点，以及至少一个容器节点；其中，所述监控节点包括kube‑proxy组件，所述容器节点包括Pod；所述监控节点用于通过kube‑proxy组件监控所述主控节点接收到的服务访问请求，以及将所述服务访问请求分发给与所述服务访问请求对应的至少一个所述容器节点中的所述Pod进行处理。每个容器节点均通过监控节点中的kube‑proxy组件和主控节点进行通信，因此，主控节点的API Server只需要和数量相对较少的监控节点通信即可，无需与大量的容器节点进行通信，降低了API Server的负担，使得该服务网络具有更强的扩展性，可以支持更大规模的Kubernetes集群。

Description

基于Kubernetes集群的服务网络、监控节点、容器节点及设备

技术领域

本说明书实施例涉及云原生技术领域，尤其涉及一种基于Kubernetes集群的服务网络、监控节点、容器节点及设备。

背景技术

随着云原生的快速发展，基于Kubernetes的容器服务应用越来越广泛。而Serverless容器服务由于无需管理服务端，具有高度的商业价值，受到了越来越多的关注。

而利用安全容器实例，可以实现Serverless容器服务，进一步提升资源利用的效率。对于Serverless场景下的安全容器实例，摆脱了Node节点的约束的同时，也带来新的问题。基于Node部署的服务网络，在Serverless场景下，常规的做法是将kube-proxy组件、Pod等部署到同一安全容器实例中，每个Pod通过所在安全容器实例内的专属kube-proxy组件管理，每个安全容器实例通过kube-proxy组件直接和主控节点的API Server通信。然而，当集群中存在大量容器实例的时候，每个实例均需要向API Server拉取数据，API Server可能不堪重负，造成集群崩溃。

发明内容

为克服相关技术中存在的问题，本申请提供一种基于Kubernetes集群的服务网络、监控节点、容器节点及设备，用以解决相关技术中的缺陷。

根据本申请的第一方面，提供一种基于Kubernetes集群的服务网络，所述服务网络包括：

主控节点，至少一个监控节点，以及至少一个容器节点；

其中，所述监控节点包括kube-proxy组件，所述容器节点包括Pod；

所述监控节点用于通过kube-proxy组件监控所述主控节点接收到的服务访问请求，以及将所述服务访问请求分发给与所述服务访问请求对应的至少一个所述容器节点中的所述Pod进行处理。

根据本申请的第二方面，提供一种上述任一实施例所述的服务网络中的监控节点，所述监控节点包括kube-proxy组件；所述kube-proxy组件用于监控主控节点接收到的服务访问请求，以及将所述服务访问请求分发给与所述服务访问请求对应的至少一个容器节点中的Pod进行处理。

根据本申请的第三方面，提供一种上述任一实施例所述的服务网络中的容器节点，所述容器节点包括Pod，所述Pod用于接收并处理监控节点分发的所述服务访问请求；所述服务访问请求由所述监控节点中的kube-proxy组件在监控到所述主控节点接收到的服务访问请求后发送。

根据本申请的第四方面，提供一种计算机设备，所述计算机设备至少包括上述任一实施例所述的服务网络中的主控节点、监控节点和容器节点中的至少一种。

在上述技术方案中，将kube-proxy组件不在放置在Pod所在的容器节点上，监控节点作为主控节点和容器节点的中间层，实现每个容器节点均通过监控节点中的kube-proxy组件和主控节点进行通信，通过这种网络架构使得kube-proxy组件与Pod不再是同一专属容器内的对应关系，控节点的API Server只需要和数量相对较少的监控节点通信即可，无需与大量的容器节点进行通信，降低了API Server的负担，使得该服务网络具有更强的扩展性，可以支持更大规模的Kubernetes集群。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

图1是一示例性实施例提供的一种传统的基于Kubernetes集群的服务网络的架构图。

图2是一示例性实施例提供的一种Serverless场景下的基于Kubernetes集群的服务网络的架构图。

图3是一示例性实施例提供的一种基于Kubernetes集群的服务网络的架构图。

图4是一示例性实施例提供的一种基于Kubernetes集群的服务网络的通信机制的架构图。

图5是一示例性实施例提供的服务网络中通信服务端向通信客户端进行数据推送的示意图。

图6是一示例性实施例提供的服务网络中通信服务端与各个客户端之间的通信的示意图。

图7是一示例性实施例提供的服务网络中通过通信命令字与通信服务端进行交互的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书实施例的一些方面相一致的装置和方法的例子。

在本说明书实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书实施例。在本说明书实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

Kubernetes(K8S)，是一个开源的容器自动化运维平台，它消除了容器化应用程序在部署、调度和伸缩时涉及到的许多手动操作。一般来说，可以将多台主机组合成集群来运行容器，而Kubernetes则可以简单高效地管理这些集群。构成这些集群的主机可以跨越公有云、私有云以及混合云。因此，对于要求快速扩展的云原生应用而言，Kubernetes是一个理想的托管平台。

一个Kubernetes集群中，一般由一个主控节点(Master)和多个工作节点(Node)组成，其中，Master主要负责管理和控制容器，而Node则是工作负载节点，用于部署和运行具体的容器。Master和Node均运行在Linux的操作系统上，具体地，其可以运行在物理机上，也可以运行在虚拟机上。在一些实施例中，为了实现高可用，在一些Kubernetes集群中，还可以运行有多个Master。

在Master上，运行着集群管理相关的一组进程etcd、API Server、ControllerManager和Scheduler，其中，etcd组件用于持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；而后三个组件则构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成的。其中，API Server是集群控制的入口进程，也是所有资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据的全量查询和变化监控，其他组件可以实时地完成相关的业务功能。

在Node上，Kubernetes管理的最小运行单元是一个容器集(Pod)。另外，Node上还运行着Kubernetes的Kubelet、kube-proxy等组件，这些组件负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。

Pod是Kubernetes最基本的操作单元，包含一个或多个紧密相关的容器，一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”，Pod中的容器会作为一个整体被Master调度到一个Node上运行。每个Pod里运行多个应用容器，且这些应用容器之间共享同一组资源，例如PID命名空间、网络命名空间、IPC命名空间、UTS命名空间和共享存储卷(Volumes)等，因此这些应用容器之间的通信和数据交换更为高效，在设计时可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。Pod的生命周期通过ReplicationController来管理。首先，Pod通过模板进行定义，然后分配到一个Node上运行，在Pod所包含的容器运行结束后，Pod才结束并销毁。Kubernetes还为Pod设计了一套独特的网络配置，为每个Pod分配一个IP地址，并使用Pod名作为容器间通信的主机名等。

在Kubernetes集群中，应用是通过Pod去部署的。传统的应用是部署在给定机器上，并通过该机器的IP地址进行访问的。而与传统的部署在给定机器上的应用不同，由于Pod的生命周期是短暂的，在Pod创建或销毁时，它的IP地址都会发生变化，因此，不能使用传统的部署方式，即通过指定的IP去访问指定的应用。而且，在Kubernetes集群中，Pod所属的网络和物理机器所属的网络并不是同一个段的网络，外部的用户没法通过机器的网络访问和调用Pod中的应用服务，因此，Kubernetes集群中需要通过服务发现将Pod网络暴露到外部网络去，提供给外部的用户去调用。

另外，在Kubernetes集群中，有一些Pod提供的是相同的服务，因此，可以将提供相同服务的Pod组成一个Pod组。对于一个外部的用户来讲，对于提供同一个服务的Pod组，访问其中的任意一个Pod的结果都是一样的，因此，在Kubernetes集群中，需要负载均衡去控制流量负载均衡到Pod组中的各个Pod上，以提供高可用的服务。

在Kubernetes集群中，服务发现是通过Service实现的。一个Service可以看作一组提供相同服务的Pod的对外访问接口，是Pod提供的真实服务的抽象。一个Service向上提供了外部网络以及集群内部Pod网络的访问接口，向下则对接了一组Pod。每个Service都拥有一个虚拟IP(Cluster IP、Service IP或VIP)和端口号，集群内部的通过该虚拟IP或端口号访问这个Service，并通过负载均衡后调用这个Service对应的其中一个Pod执行相关的应用服务。而如果Service需要提供面向网络外部的服务，则需要指定公共IP个NodePort，或者外部负载均衡器。

Service是Kubernetes的一种资源对象，在Kubernetes集群中，是通过Node上部署的kube-proxy实现Service的通信代理和服务网络的负载均衡机制的。在一些实施例中，kube-proxy可以通过iptables或者IPVS(IP Virtual Server)实现负载均衡。

如图1所示，图1示出了一种传统的基于Kubernetes集群的服务网络的架构图。其中，整个Kubernetes集群划分为主控节点11(Master)和工作节点13(Node)两个层次，Master 11中至少包括有API Server 14组件，而Node 13中则至少包括有kube-proxy组件15和多个Pod 16。其中，所有服务(Service)的创建和销毁都是通过调用API Server 14上的相关API进行操作的，而每个Node13上的kube-proxy组件15会注册到API Server 14上，监控Service和Pod等资源对象的变化，然后实际去配置集群中的Pod 16的服务访问，并将Service对象的访问流量负载均衡到各个Pod 16上执行。

由于Kubernetes的容器应用服务是部署在云中的，因此Kubernetes可能需要同时面向很多的用户，不同的容器可能归属于不同的用户，因此，容器之间的安全性就十分重要。而容器作为一种操作系统虚拟化技术，同一台宿主机上的容器之间是共享操作系统内核的，因此，容器并未实现完全隔离，如果虚拟化软件存在漏洞，或者宿主机遭受到攻击，均可能会造成容器逃逸或资源隔离失败等问题，以致于影响某个容器或多个容器的安全。

在容器技术领域中，为了进一步增强容器的安全性，在容器的基础上发展出了安全容器。安全容器是一种容器运行时的技术，为容器应用提供一个完整的操作系统执行环境，将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。

而由于安全容器本身为容器应用提供了一个完整的操作系统执行环境，因此安全容器实例可以不需要运行在Node中，而基于安全容器实例的Kubernetes集群也可以不再需要管理Node，可以实现Serverless(无服务端)模式的容器服务，进一步提升资源利用的效率。Serverless是指一种无需关心服务端等基础设施的管理，而是专注到应用程序的业务逻辑中的架构模式。Serverless场景下的Kubernetes产品，即Serverless Kubernetes产品，由于用户无需购买节点即可直接部署容器应用，也无需对集群进行节点维护和容量规划，并且可以根据应用配置的CPU和内存资源量进行按需付费，因此，ServerlessKubernetes产品也受到了越来越多的关注和更加广泛的使用。

在基于安全容器的Serverless场景下，由于不需要再管理Node节点，Kubernetes集群直接通过安全容器实例中的Pod来运行和提供容器应用服务，而由于没有了Node节点，用于管理服务网络的kube-proxy组件等服务进程，需要在每个容器实例中都部署一套，再通过在Master节点中的API Server上注册并监控Service等资源对象的变化，实现容器应用服务的访问。

如图2所示，图2示出了一种Serverless场景下的基于Kubernetes集群的服务网络的架构图。其中，整个Kubernetes集群被划分为主控节点21(Master)和容器节点23两个层次，Master 21中至少包括有API Server 24组件。在一些实施例中，容器节点23可以是一个安全容器实例，其中至少包括有一个用于运行具体的容器应用的Pod 26，以及一个用于管理服务网络的kube-proxy组件25。其中，所有服务(Service)的创建和销毁都是通过调用API Server 24上的相关API进行操作的，而每个安全容器实例上的kube-proxy组件25会注册到API Server 24上，监控Service和Pod等资源对象的变化，然后实际去配置集群中的Pod的服务访问，并将Service对象的访问流量负载均衡到各个Pod 26上执行。

在上述的服务网络中，由于所有安全容器实例都通过kube-proxy组件25直接和Master节点21的API Server 24通信和拉取数据，安全容器实例的数量很多，而Master节点21及其上的API Server 24则都只有一个，因此，唯一的一个Master 21的API Server 24需要去和每一个安全容器的kube-proxy 25进行通信，其开销非常的高。而且当集群中存在着大量的容器实例时，API Server 24的开销和负担将攀升到一个很高的高度，API Server24很可能不堪重负，最终导致整个Kubernetes集群的崩溃。因此，API Server 24的性能将大大地限制了容器节点数量地扩展。

另外，在上述的服务网络中，由于安全容器内部部署的kube-proxy组件25可以直接和API Server 24进行通信，也可以存在一定的安全隐患。

有鉴于此，本说明书实施例提出了一种基于Kubernetes集群的服务网络，可以支持更大规模的Serverless Kubernetes集群。

如图3所示，图3是本说明书实施例示出的一种基于Kubernetes集群的服务网络的架构图。其中，整个Kubernetes集群被划分为主控节点31(Master)、监控节点32和容器节点33三个层次。其中，监控节点32中包括kube-proxy组件35，而容器节点33中则包括Pod 36。具体地，监控节点32中的kube-proxy组件35用于监控Master接收到的服务请求，以及将该服务请求分发给与该服务请求对应的至少一个容器节点33中的Pod 36进行处理。

在一些实施例中，本说明书实施例的服务网络中的主控节点31可以与传统的基于Kubernetes集群的服务网络中的主控节点31(Master)具有相同的功能和结构，用于接收外部的服务访问请求，以及管理容器节点33及其中的Pod 36。在一些实施例中，主控节点31中至少运行有API Server 34进程，API Server 34组件是提供HTTP Rest接口的关键服务进程，是Kubernetes集群中所有资源的增、删、改、查等操作的唯一入口，Service资源对象的创建和销毁也是通过API Server 34上的API接口实现的。因此，当有外部的或集群内部的服务访问请求时，会触发主控节点31上的API Server 34上与该服务访问请求对应的Service发生变化，而监控节点32中的kube-proxy组件35在监控到这些Service发生变化后，会将该服务访问请求的流量负载均衡到与该Service对应的安全容器实例上的Pod 36上，通过对应的容器应用执行该服务访问请求的相关服务。

在一些实施例中，本说明书实施例的监控节点32是指独立部署有kube-proxy组件35的节点，监控节点32通过kube-proxy组件35管理一个或多个容器节点33。在一些实施例中，监控节点32中的kube-proxy组件35注册在主控节点31的API Server 34中，监控Service和Pod等资源对象的变化，当kube-proxy组件35监控到API Server 34中某一Service由于服务访问请求产生对应的变化后，kube-proxy组件35会拉取该Service的对应数据和服务访问请求的流量数据，并解析出该Service对应的几个Pod 36负载当前的运行状态，从中均衡选择出最合适的Pod 36，再将服务访问请求的流量数据发送至该Pod 36所属的容器节点33中，使该容器节点33中的Pod 36执行服务访问请求所请求的应用服务。

在一些实施例中，本说明书实施例中的监控节点32可以是通过安全容器实例实现。在一些实施例中，实现该监控节点32的安全容器实例上可以是只部署有kube-proxy组件35以及其他相关的服务网络管理进程，而没有运行任意的Pod36。

在一些实施例中，本说明书实施例的容器节点33可以是搭载和运行容器程序的工作节点，其上至少包括用于运行容器程序的Pod 36。与传统的Kubernetes集群中的工作节点Node不同，本说明书实施例的容器节点33不是以Node形式实现的，而是以安全容器实例的形式实现的。而且，传统的Kubernetes集群中的Node节点上一般可以运行有一个或多个Pod 36，同一个Node节点上各个Pod36之间共享一定的资源，而本说明书实施例的容器节点33上只运行有一个Pod36，与其他容器节点33上的Pod 36之间不共享资源，隔离性更强。而且，传统的Kubernetes集群中的Node节点除了运行Pod 36外，还部署有如kube-proxy组件35等管理组件，以及如IPVS等辅助功能组件，而本说明书实施例的容器节点33上除了运行Pod 36外，只部署有如IPVS等辅助功能组件，而不部署有如kube-proxy组件35等管理组件。

在本说明书实施例所提供的服务网络中，由于各个容器节点33是通过监控节点32中的kube-porxy组件和主控节点31的API Server 34进行通信的，而一个监控节点32又可以同时管理多个容器节点33，因此，当集群的规模持续扩大时，只需要动态的增加部署有kube-proxy组件35的监控节点32的数量即可，主控节点31中的API Server 34只需要和监控节点32中的kube-proxy组件35通信，而不需要直接和容器节点33通信，而监控节点32的数量远远少于容器节点33的数量，例如，在一个具有10000个容器实例的服务网络中，现有的服务网络中的API Server 34需要和这10000个容器实例去通信，对API Server 34的负担很高；而本说明书实施例的服务网络中，一个kube-proxy组件35可以管理100个容器实例，则API Server 34只需要和100个kube-proxy组件35进行通信，即可实现容器应用服务的服务网络，大大减小了API Server 34的负担。因此，与现有的服务网络相比，本说明书实施例的服务网络可以支持更大规模的Serverless Kubernetes集群。

另外，由于本说明书实施例的服务网络中的API Server 34是先和监控节点32的kube-proxy组件35通信，而kube-proxy组件35再和容器节点33进行通信，因此，容器节点33不再需要直接地和API Server 34进行通信，解除了可能存在的安全风险，在一定程度上增强了服务网络的安全性。

在一些实施例中，监控节点32中的kube-proxy组件35还可以从API Server34拉取配置数据，再把相关的配置数据分发给各个容器节点33，从而更新各个容器节点33的配置。

在一些实施例中，kube-proxy组件35可以先从API Server 34中拉取到对应的配置数据，再将该配置数据发送至与之对应的容器节点33中；而容器节点33在接收到kube-proxy组件35发来的配置数据后，则利用该配置数据完成所属安全容器实例的配置设置和配置变更，例如配置安全容器实例的IPVS规则等。

在一些实施例中，kube-proxy组件35发送给容器节点33的配置数据可以是全量数据。全量数据是指一个容器实例完成配置所需要的所有配置数据，包括初始的配置数据以及每次配置变更时新增的配置数据，通过全量数据，容器实例可以实现所有配置的设置并将配置更新至当前的配置终态。

然而，随着运行时间的增长，每次配置变更后，全量数据所包含的数据量都会增多，而到了一定程度后，每次收发都使用全量数据的话，会导致每次通信的数据量都很大，而很多容器节点33实际需要的数据可能只是小部分后面更新的配置数据，因此可能造成大量的资源浪费。

在一些实施例中，kube-proxy组件35发送给容器节点33的配置数据还可以是增量数据。增量数据是指每一次数据变更时新增的配置数据，其中只包含了完整的配置数据的一部分，而没有包含全部的配置数据。然而，由于容器节点33本身可能已经存在有部分配置数据，因此，通过将部分容器节点33上没有的新增数据对应的增量数据发给对应的容器节点33，该容器节点33也可以完成配置设置并将配置更新至当前的配置终态。因此，除了初次建立通信时需要将全量数据发送给对应容器节点33外，对于保持通信的容器节点33，每次发送配置数据时可以只发送该容器节点33所需要的增量数据即可，以保证每次通信的数据量无需太大，减小资源浪费。在一些实施例中，容器节点33与监控节点32的kube-proxy组件35保持通信连接的状态可以称为订阅状态，在订阅状态下，每次容器节点33接收到kube-proxy组件35从API Server 34拉取到的新的配置数据并生成对应的增量数据时，可以立即将容器节点33所需的增量数据发送至该容器节点33，而容器节点33在接收到增量数据时可以立即通过该增量数据完成容器节点33的配置更新，实现实时的消息发送机制。

在一些实施例中，kube-proxy组件35发送给容器节点33的增量数据可以携带有本次分发的增量数据的版本号，该版本号可以是顺序递增的形式生成的，且每个增量数据均具有唯一的版本号。例如，若当前容器节点33上最新的增量数据的版本号为100时，则在下一次有数据变更时，变更的数据生成的新的增量数据的版本号则记为101，以此类推。通过有序的版本号，监控节点32上的kube-proxy组件35能够准确的判断出各个容器节点33所需要的增量数据，从而将对应的增量数据发送至对应的容器节点33。

在一些实施例中，该版本号还可以用于记录容器节点33，当容器节点33接收到一次全量数据或增量数据后，可以使用其接收到的配置数据中最新的配置数据对应的增量数据对应的版本号标记自身，用以表示该容器节点33当前的配置版本。

在本说明书实施例的服务网络中，监控节点32的kube-proxy组件35和主控节点31的API Server 34进行通信的机制可以沿用传统的服务网络的Kubernetes集群中的kube-proxy组件35和API Server 34的通信方式。而监控节点32的kube-proxy组件35和容器节点33之间进行通信的机制则可以是另外设计的通信机制，使得单个的kube-proxy组件35可以管理大量的容器实例。

在一些实施例中，监控节点32的kube-proxy组件35和容器节点33之间的通信机制可以实现实时的数据推送，以保证配置变更等能够实时生效，避免配置变更不及时导致的运行错误。

在一些实施例中，监控节点32的kube-proxy组件35和容器节点33之间的通信机制还可以支持配置数据聚合，使配置数据能够适应多种配置变更场景，例如大量新建Pod 36实例等大规模配置变更的场景。

在一些实施例中，监控节点32的kube-proxy组件35和容器节点33之间的通信机制还可以具有一定的可靠性，即能够使得所有的容器实例上的配置数据的终态都是一致的。而当发生网络中断等异常后重新建立连接时，可以快速地恢复为完整地配置数据。

在一些实施例中，监控节点32的kube-proxy组件35和容器节点33之间的通信机制还可以满足轻量的要求，该通信机制是需要部署在安全容器实例上的，需要尽可能的降低其在安全容器实例上的资源开销。

如图4所示，图4是本说明书实施例示出的一种基于Kubernetes集群的服务网络的通信机制的架构图。在一些实施例中，本说明书实施例中监控节点32的kube-proxy组件35和容器节点33之间的通信机制可以是如下的通信机制：

在监控节点32中还包括有通信服务端37，而在容器节点33中则包括有通信客户端38。监控节点32中的kube-proxy组件35通过该通信服务端37和容器节点33中的通信客户端38建立通信，并将从API Server 34中监听和拉取的服务访问请求的流量数据分发给与该服务请求对应的各个容器节点33中的Pod 36进行处理。

在一些实施例中，kube-proxy组件35可以先从API Server 34中拉取到对应的服务访问请求的流量数据，再将该服务访问请求的流量数据发送至监控节点32中的通信服务端37中；而通信服务端37在接收到kube-proxy组件35发来的服务访问请求的流量数据后，通过与容器节点33中的通信客户端38建立的通信信道，将该服务访问请求的流量数据发送到容器节点33中的通信客户端38中；而容器节点33中的通信客户端38在接收到通信服务端37发来的服务访问请求的流量数据后，直接调用容器节点33中的Pod 36实例对该服务访问请求进行处理，执行相关的容器应用，完成相关的应用服务。

在一些实施例中，监控节点32中的kube-proxy组件35通过该通信服务端37和容器节点33中的通信客户端38建立通信后，还可以从API Server 34拉取配置数据，再把相关的配置数据分发给各个安全容器实例，从而更新各个安全容器实例的配置。

在一些实施例中，kube-proxy组件35可以先从API Server 34中拉取到对应的配置数据，再将该配置数据发送至监控节点32中的通信服务端37中；而通信服务端37在接收到kube-proxy组件35发来的配置数据后，通过与容器节点33中的通信客户端38建立的通信信道，将该配置数据发送到容器节点33中的通信客户端38中；而容器节点33中的通信客户端38在接收到通信服务端37发来的配置数据后，则利用该配置数据完成所属安全容器实例的配置设置和配置变更，例如配置安全容器实例的IPVS规则等。

在一些实施例中，通信服务端37发送给通信客户端38的配置数据可以是全量数据。全量数据是指一个容器实例完成配置所需要的所有配置数据，包括初始的配置数据以及每次配置变更时新增的配置数据，通过全量数据，容器实例可以实现所有配置的设置并将配置更新至当前的配置终态。

然而，随着运行时间的增长，每次配置变更后，全量数据所包含的数据量都会增多，而到了一定程度后，每次收发都使用全量数据的话，会导致每次通信的数据量都很大，而很多容器实例实际需要的数据可能只是小部分后面更新的配置数据，因此可能造成大量的资源浪费。

在一些实施例中，通信服务端37发送给通信客户端38的配置数据还可以是增量数据。增量数据是指每一次数据变更时新增的配置数据，其中只包含了完整的配置数据的一部分，而没有包含全部的配置数据。然而，由于通信客户端38对应的容器实例本身可能已经存在有部分配置数据，因此，通过将部分容器实例上没有的新增数据对应的增量数据发给对应的通信客户端38，其所属的容器实例也可以完成配置设置并将配置更新至当前的配置终态。因此，除了初次建立通信时需要将全量数据发送给对应容器实例的通信客户端38外，对于保持通信的通信客户端38，每次发送配置数据时可以只发送该通信客户端38所属的容器实例所需要的增量数据即可，以保证每次通信的数据量无需太大，减小资源浪费。在一些实施例中，通信客户端38与通信服务端37保持通信连接的状态可以称为订阅状态，在订阅状态下，每次通信客户端38接收到kube-proxy组件35从API Server 34拉取到的新的配置数据并生成对应的增量数据时，可以立即将容器实例所需的增量数据发送至对应的通信客户端38，而通信客户端38在接收到增量数据时可以立即通过该增量数据完成容器实例的配置更新，实现实时的消息发送机制。

在一些实施例中，通信服务端37中的增量数据可以携带有本次分发的增量数据的版本号，该版本号可以是顺序递增的形式生成的，且每个增量数据均具有唯一的版本号。例如，若当前通信服务端37上最新的增量数据的版本号为100时，则在下一次有数据变更时，变更的数据生成的新的增量数据的版本号则记为101，以此类推。通过有序的版本号，通信服务端37能够准确的判断出各个通信客户端38所需要的增量数据，从而将对应的增量数据发送至对应的通信客户端38。

在一些实施例中，该版本号还可以用于记录通信客户端38，当客户端接收到一次全量数据或增量数据后，可以使用其接收到的配置数据中最新的配置数据对应的增量数据对应的版本号标记自身，用以表示该通信客户端38当前的版本。

在一些实施例中，通信客户端38还可以用于从指定版本号开始，向通信服务端37订阅指定版本号后的增量数据。例如，当通信客户端38初次与通信服务端37建立连接，并将其所属的容器实例的配置信息更新至当前通信服务端37最新的增量数据后，此通信客户端38可以向通信服务端37进行交互，使该通信客户端38进入订阅状态。而之后通信服务端37每次生成新版本的增量数据时，都会将这些新版本的增量数据发给订阅状态中的该通信客户端38，实时的实现容器实例的配置更新。

在一些实施例中，通信服务端37还可以用于在配置数据更新时，将更新数据推送至各个通信客户端38，即将更新数据包含在新一个版本号的增量数据中，再将该版本号的增量数据推送至各个订阅状态中的通信客户端38。

在一些实施例中，通信服务端37上可以存储有一定数量的增量数据，当通信客户端38当前配置的配置数据对应的增量数据的版本号距离通信服务端37上最新的版本号之间存在多个版本号，即所需要的增量数据不止一个时，可以将连续的多个增量数据一齐发送至对应的通信客户端38，以使得该通信客户端38能够将配置变更至当前的终态配置，保证各个通信客户端38配置的一致性。

在一些实施例中，通信服务端37上存储的增量数据的最大数量可以是指定的数量，例如通信服务端37上最多存储有版本号最新的50个增量数据，以保证通信服务端37不占用太大的存储资源。

在一些实施例中，当通信客户端38发生网络中断等异常导致较长时间再重新与通信服务端37建立通信连接时，通信客户端38对应的容器实例当前的配置数据对应的增量数据的版本号远低于通信客户端38上存储的最小版本号对应的增量数据的版本号时，即即使将所有的增量数据全部发送给对应的通信客户端38，也无法使该通信客户端38对应的容器实例恢复至当前的配置终态，仍然存在缺失的配置数据时，可以将全量数据发送至对应的通信客户端38，以使得该通信客户端38能够将配置变更至当前的终态配置，保证各个通信客户端38配置的一致性。

如图5所示，图5是本说明书实施例示出的服务网络中通信服务端37向通信客户端38进行数据推送的示意图。其中，监控节点32上的kube-proxy组件35将接收到的配置数据分为全量数据和增量数据进行存储，其中，存储的增量数据包括版本号为53至102的50个版本号对应的增量数据，且当前最新的配置数据对应的版本号为102。而图中，存在4个容器节点33的通信客户端38与该监控节点32的通信服务端37建立了通信，且这四个容器节点33当前的配置信息对应的版本号分别99、101、102和30。为了保证各个容器节点33的配置数据的一致性，通信服务端37需要分别向这四个通信客户端38发送对应的新增数据，以使得这四个容器节点33的通信客户端38的配置数据的版本均能够更新至版本号为102对应的增量数据。对于第一个容器节点33，由于该节点当前的版本为99，因此需要向该节点的通信客户端38发送版本号为100、101和102的增量数据；对于第二个容器节点33，由于该节点当前的版本为101，因此只需要向该节点的通信客户端38发送版本号为102的增量数据；对于第三个容器节点33，由于该节点当前的版本为102，与最新的增量数据版本号一致，因此不需要向该节点的通信客户端38发送任何增量数据；对于第四个容器节点33，由于该节点当前的版本为30，远低于通信服务端37存储的增量数据的最小版本号53，因此需要向该节点的通信客户端38发送全量数据。

在一些实施例中，本说明书实施例中的通信服务端37可以是一个通信命令的执行引擎，即通信服务端37基于接收到的通信命令执行对应的操作，而不需要去感知发起通信命令的客户端具体的类型。其优点在于这种基于通信命令的通信服务端37的逻辑比较简单，而且对测试也比较方便，基于通信命令字就能够进行独立的测试。

在一些实施例中，通信服务端37的通信命令字可以是基于请求响应方式的通信命令字，当任意客户端向通信服务端37发起请求的通信命令字时，通信服务端37会执行相关的命令操作，再向发起请求的客户端回以响应消息。

在一些实施例中，通信服务端37中的通信命令字可以包括以下几个通信命令字中的一个或多个：list命令，用于指示拉取全量数据；subscribe命令，用于从指定的版本号开始，订阅增量数据，特别地，在该命令执行完成之后通信服务端37和客户端之间不会中断连接，而是进入订阅状态，保持通信连接；unsubscibe命令，用于在订阅状态下关闭连接，并推出订阅状态；report命令，用于通告客户端的信息，例如客户端当前配置数据的版本号等，并获取通信服务端37的版本号等信息；broadcast命令，用于在数据源有更新时，触发实时推送命令，使通信服务端37将更新的数据发送至所有订阅状态中的客户端中；push命令，用于在接收到broadcast命令之后，推送消息到订阅状态中的客户端中，特别地，该命令字不是请求响应式的通信命令字，而是通信服务端37单方面发送给客户端的。

如图6所示，图6是本说明书实施例示出的服务网络中通信服务端37与各个客户端之间的通信的示意图。其中，通信客户端38的类型不止是部署在容器节点33上的通信客户端38，与通信服务端37进行通信的还包括部署在kube-proxy组件35中的通信客户端38，以及部署在命令行界面(CLI)或监控器(monitor)39中的通信客户端38，其中，前一个通信客户端38用于实现kube-proxy组件35和通信服务端37之间的通信连接，而后一个通信客户端38可以用于对通信服务端37进行测试。其中，部署在容器节点33上的通信客户端38可以向通信服务端37发起subscribe命令，从而与通信服务端37建立连接，并进入订阅状态中。其中，当kube-proxy组件35监听到配置数据有更新时，kube-proxy组件35中的通信客户端38可以向通信服务端37发起broadcast命令，进而使通信服务端37向订阅状态中的部署在容器节点33上的通信客户端38发起push命令，推送更新的配置数据，同时，通信服务端37还会回复响应消息给kube-proxy组件35中的通信客户端38，以告知执行结果。

如图7所示，图7是本说明书实施例示出的服务网络中通过通信命令字与通信服务端37进行交互的示意图。其中，通信客户端38-1可以先向通信服务端37发起report命令，向通信服务端37通告该通信客户端38-1当前的版本号version1以及该通信客户端38-1对应的执行编号runid，而通信服务端37在执行完该report命令后，会向该通信客户端38-1回复响应消息，并携带通信服务端37当前的版本号version2。接着，通信客户端38-1可以向通信服务端37发起list命令，向通信服务端37拉取全量数据，通信服务端37回复响应消息，并将全量数据发送给该通信客户端38--1。接着，通信客户端38-1可以向该通信服务端37发起subscribe命令，请求进入订阅状态，通信服务端37回复响应消息后，该通信客户端38-1即可进行订阅状态，与通信服务端37保持持续的通信。另外，kube-proxy组件35监听到配置数据发生变更后，向通信服务端37发起broadcast命令，通信服务端37在回复响应消息后，会向所有订阅状态中的通信客户端38，例如包括通信客户端38-1和通信客户端38-N，发送更新的数据，并携带更新的数据msg。

另外，本说明书实施例还提供一种基于Kubernetes集群的服务网络的监控节点32，所述监控节点32可以是上述的服务网络的任意实施例中的监控节点32，所述监控节点32至少包括kube-proxy组件35；该监控节点32可以通过kube-proxy组件35监控主控节点31接收到的服务访问请求，并将该服务访问请求分发给与该服务访问请求对应的至少一个容器节点33中的Pod 36进行处理。

该监控节点32的功能和作用的实现过程具体详见上述服务网络中对应的监控节点32的实现过程，在此不再赘述。

另外，本说明书实施例还提供一种基于Kubernetes集群的服务网络的容器节点33，所述容器节点33可以是上述的服务网络的任意实施例中的容器节点33，所述容器节点33包括Pod 36，所述Pod 36用于接收并处理监控节点32分发的所述服务访问请求；所述服务访问请求由所述监控节点32中的kube-proxy组件35在监控到所述主控节点31接收到的服务访问请求后发送。

该容器节点33的功能和作用的实现过程具体详见上述服务网络中对应的监控节点32的实现过程，在此不再赘述。

本说明书实施例还提供一种计算机设备，其至少包括前述任一实施例所述的服务网络中的主控节点31、监控节点32和容器节点33中的至少一种。

其中主控节点31、监控节点32和容器节点33的功能和作用的实现过程具体详见上述服务网络中对应的节点的实现过程，在此不再赘述。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (10)

1.一种基于Kubernetes集群的服务网络，所述服务网络包括：

主控节点，至少一个监控节点，以及至少一个容器节点；

其中，所述监控节点包括kube-proxy组件，所述容器节点包括Pod；

所述监控节点用于通过kube-proxy组件监控所述主控节点接收到的服务访问请求，以及将所述服务访问请求分发给与所述服务访问请求对应的至少一个所述容器节点中的所述Pod进行处理。

2.根据权利要求1所述的服务网络，所述kube-proxy组件还用于将配置数据分发给各个所述容器节点。

3.根据权利要求2所述的服务网络，所述配置数据包括全量数据和增量数据。

4.根据权利要求3所述的服务网络，所述增量数据携带有本次分发的增量数据的版本号。

5.根据权利要求4所述的服务网络，所述监控节点还包括通信服务端，所述容器节点还包括通信客户端，所述通信服务端用于与所述通信客户端建立通信；

所述服务访问请求和所述配置数据通过所述通信客户端分发给各个所述容器节点中的所述Pod。

6.根据权利要求5所述的服务网络，所述通信客户端还用于，从指定版本号开始，向所述通信服务端订阅所述指定版本号后的所述增量数据。

7.根据权利要求5所述的服务网络，所述通信服务端还用于在配置数据更新时，将所述增量数据推送至各个通信客户端，所述增量数据包括所述更新数据。

8.一种权利要求1-7任一项所述的服务网络中的监控节点，所述监控节点包括kube-proxy组件；所述kube-proxy组件用于监控主控节点接收到的服务访问请求，以及将所述服务访问请求分发给与所述服务访问请求对应的至少一个容器节点中的Pod进行处理。

9.一种权利要求1-7任一项所述的服务网络中的容器节点，所述容器节点包括Pod，所述Pod用于接收并处理监控节点分发的所述服务访问请求；所述服务访问请求由所述监控节点中的kube-proxy组件在监控到所述主控节点接收到的服务访问请求后发送。

10.一种计算机设备，所述计算机设备至少包括权利要求1-7任意一项所述的服务网络中的主控节点、监控节点和容器节点中的至少一种。

Images