一篇文章带你了解kubernetes各组件间的通信机制

我们对kubernetes有了一定的认识，本文我们将继续深入的对kubernetes在系统层面上进行讨论，一起看看kubernetes的各个基本组件，以及各个组件是如何相互配合来撑起如此复杂的集群系统。下面跟随文章内容，一起来领略kubernetes令人惊叹的设计内幕吧。

Kubernetes的基本组件

Kubernetes将整个集群分为控制节点和工作节点，如下图所示。

Kubernetes中的Master是指集群控制节点，每个Kubernetes集群中需要一个Master节点来负责整个集群的管理和控制，Kubernetes中所有的控制指令都是交由Master来进行处理。引起在集群中处于非常重要的地位，因此在部署中需进行多节点单独部署。

Maste节点关键进程

Apiserver：提供kubernetes所有资源增删改查的唯一入口，也是集群控制的入口，提供http Rest接口，完成集群管理，资源配额，访问控制，认证授权，以及对etcd的操作。

Controller-manager：是集群内所有资源对象的自动化控制中心，负责pod和node的管理，节点控制器，服务控制器，副本控制器，服务账户和令牌控制器等

Scheduler：负责资源调度，监听Apiserver，查询是否有未调度的pod。

Etcd：在kubernetes系统中，主要有两个服务需要用到etcd来存储：

网络插件：如flannel等需要存储网络配置信息

Kubernetes本身，包括各种对象的状态和原信息配置。

除Master节点外，集群中其他集群被称为Node节点，较早的版本中也叫Minion。Node节点是集群中具体的工作负载节点，其可以使物理机也可以为虚拟机。

Node节点关键进程(包括但不限于以下进程)

kubelet：处理Master下发到本节点的任务，管理pod及pod的容器，每个kubelet在Apiserver上注册自身信息，定期向Master汇报节点的资源使用情况，并通过cAdvisor监控容器和节点信息。

kube-proxy：将到service的访问转发到后端的多个pod实例上，维护路由信息，对于每一个TCP类型的k8s service，kube-proxy会在本地建立一个sockerserver来负责均衡算法，使用rr负载均衡算法。

CNI网络组件：作为容器平台的网络标准化组件，为容器提供跨网段的通信支持，是kubernetes集群overlay网络的实现关键。

Docker：kubernetes支持多种容器工具，目前Docker作为主流的容器，为kubernetes集群提供容器创建及管理。

集群各组件间的交互

Kubernetes为所有资源增删改查的唯一入口，各组件均以list-watch的方式向Apiserve发送请求。为减少Apiserver的压力，各组件都采用缓存来缓存数据。功能模块在某些情况下不直接访问Apiserver，而是通过访问缓存来间接访问Apiserver。

Kubelet&Apiserver

每个node上的kubelet每个一个时间周期，就会调用Apiserver的REST接口来报告自身状态。Kubelet通过watch接口，监听pod信息。监听创建、删除、修改事件。

Controller-manager&Apiserver

controller-manager中包含多个controller，举例：Node Controller模块通过API server提供的Watch接口，实现监控Node信息，并做相应处理。

Scheduler&Apiserver

Scheduler通过API server的watch接口来监听，监听到新建pod副本后，检索所有符合该Pod要求的Node列表，开始执行Pod调度，调度成功后将pod绑定到具体节点。

以下是一张典型pod创建的流程图，其中可以看到Apiserver处于核心的位置，集群内的各个功能模块的所有原数据正删改查都是通过kube-apiserver操作etcd，当需要获取和操作这些数据时，通过Apiserver的REST接口来实现。

list-watch机制

kubernetes没有像其他分布式系统中额外引入MQ，是因为其设计理念采用了level trigger而非edge trigger。其仅仅通过http+protobuffer的方式，实现list-watcher机制来解决各组件间的消息通知。因此，在了解各组件通信前，必须先了解list-watch机制在kubernetes的应用。

List-watch是k8s统一的异步消息处理机制，list通过调用资源的list API罗列资源，基于HTTP短链接实现;watch则是调用资源的watch API监听资源变更事件，基于HTTP长链接实现。在kubernetes中，各组件通过监听Apiserver的资源变化，来更新资源状态。

这里对watch简要说明，流程如下图所示：

这一部分流程图看起来并不复杂，实际上里面的实现相当精妙。结合这幅图进行简要的解释：

1 首先需要强调一点，list或者watch的数据，均是来自于etcd的数据，因此在Apiserver中，一切的设计都是为了获取最新的etcd数据并返回给client。

2 当Apiserver监听到各组件发来的watch请求时，由于list和watch请求的格式相似，先进入ListResource函数进行分析，若解析为watch请求，便会创建一个watcher结构来响应请求。watcher的生命周期是每个http请求的。

//每一个Watch请求对应一个watcher结构 
func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage,... ... 
…… 
lister, isLister := storage.(rest.Lister) 
watcher, isWatcher := storage.(rest.Watcher) ...(1) ... case "LIST": // List all resources of a kind. 
…… 

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!