32

Kubernetes 核心组件解析

 5 years ago
source link: https://mp.weixin.qq.com/s/Mdr3AkIyDTQKMCZBam9okA?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

众所周知，k ubernetes是 目前最为火热的容器编排工具之一，其背后有如此多的追随者必然是有原因的。首先 kubernetes 非常轻量，通常 kubernetes 都是以容器作为载体，而容器本来就具有轻量级秒级部署的特点；再者 kubernetes 有火热的开源社区，自从 kubernetes 加入 CNCF（Cloud Native Computing Foundation，云原生计算基金会） 后，来自世界各地的许多容器开发者参与其中，其中不乏有像 Redhat 、 IBM 、华为等大厂的开发人员，因此良好的生态圈成为了最受关注的原因之一。

在 kubernetes 中部署应用是一件容易的事，因其有着弹性伸缩，横向扩展的优势并同时提供负载均衡能力以及良好的自愈性（自动部署、自动重启、自动复制、自动扩展等），那么这些 kubernetes 的优势在集群中又是如何被体现出来的呢？

6FNjiqj.jpg!web

图1

kubernetes 的架构分为 Master 和 Node 两部分， 如图 1 所示。 由上图可以看出这两部分由五种主要的组件构成，它们之间协同工作从而完成整个集群的管理，这五种组件分别为API Server、Controller Manager、Scheduler、Kubelet、Etcd。本文主要从一个简单的Pod工作流出发，涉及到架构中的组件并深入讲解其工作机制，下面先简单介绍下kubernetes中组件和资源对象的基本概念。 

1、Pod：kubernetes中运行应用或服务的最小单元，其设计理念是支持多个容器在一个Pod中共享网络地址和文件系统
2、Service：访问Pod的代理抽象服务，主要用于集群内部的服务发现和负载均衡
3、Replication Controller：用于伸缩Pod副本数量的组件
4、API Server：对以上1、2、3资源对象进行增、删、改、查的Rest API服务器
5、Scheduler：集群中资源对象的调度控制器
6、Controller Manager：负责集群中资源对象管理同步的组件
7、Etcd：分布式键值对（k,v）存储服务，存储整个集群的状态信息
8、Kubelet：负责维护Pod容器的生命周期
9、Label：用于Service及Replication Controller 与Pod关联的标签

假设此kubernetes环境包含一个Master节点，若干个Node节点。后面说明一律按照此环境作为假设。接下来给大家展示一个简单的Pod工作流，如图2所示：           

 
（1）提交请求：用户通常提交一个yaml文件，向API Server发送请求创建一个Pod， yaml文件含有此Pod的详细信息，包含此Pod运行副本数、镜像、Labels、名称，端口暴露情况等。API Server接收到请求后将yaml文件中的spec数据存入Etcd中；
（2）资源状态同步：这一步涉及到Replication组件，Replication组件监控着数据库中的数据变化，对已有的Pod进行数量上的同步；
（3）资源分配：Scheduler会检查Etcd数据库中记录的没有被分配的Pod，将此类Pod分配至具有运行能力的Node节点中，并更新Etcd数据库中的Pod分配情况；
（4）新建容器： kubernetes集群节点中的Kubelet对Etcd数据库中的Pod部署状态进行同步，目标Node节点上的Kubelet将Pod相关yaml文件中的spec数据递给后面的容器运行时引擎（如Docker等），后者负责Pod容器的运行停止和更新；Kubelet会通过容器运行时引擎获取Pod的状态并将信息更新至API Server，最后写入Etcd中；
（5）节点通讯：Kube-proxy负责各节点中Pod的网络通信，包括服务发现和负载均衡。

Fjemimq.png!web

图 2

从以上kubernetes工作流可看出，从客户端发送创建Pod请求到Pod最终部署至节点期间参与的主要组件有API Server、 Controller-Manager、 Scheduler、 Kubelet、Etcd。

Etcd组件在整个Pod工作流中主要为其它四个组件提供组件状态存储，不多做解释。下面将分别对其它四个组件的工作机制予以具体说明。

一、API Server

API Server组件在如上Pod工作流中体现的功能主要分为以下几个部分：   

1、 为整个Pod工作流提供了资源对象（Pod, Deployment, Service等）的增、删、改、查以及用于集群管理的Rest API接口，集群管理主要包括认证授权，集群状态管理和数据校验等。
2、 提供集群中各组件的通信以及交互的功能。
3、 提供资源配额控制入口功能。
4、 安全的访问控制机制。

以下是API Server的工作原理图，如图3所示：

B3MjYrU.jpg!web

图3

在kubernetes集群中，API Server运行在Master节点上，默认开放两个端口，分别为本地端口8080（非认证或授权的http请求通过该端口访问API Server）和安全端口6443（ 该端口用于接收https请求并且用于token文件或客户端证书及HTTP Basic的认证同时用于基于策略的授权），kubernetes中默认为不启动https安全访问控制。 

集群组件间通信

API Server在整个Pod工作流中主要负责各个组件间的通信，Scheduler, Controller Manager, Kubelet通过API Server将资源对象信息存入Etcd中，当各组件需要这些数据时又通过API Server的Rest接口来实现信息交互，以下分别说明。

> > > >

1. Kubelet与API Server

在Pod工作流中，位于集群中每个Node节点上的Kubelet会定期调用API Server的Rest接口去告知当前自身状态，API Sever接收到状态信息后，将其更新至Etcd中，Kubelet也同时通过API Server的Watch接口去监听Pod信息，从而对各个Node节点上的Pod进行管理，主要监听信息如表1所示：

表1

监听信息

Kubelet 执行

是否有新的Pod被绑定到Node节点

执行Pod对应容器的创建和启动

是否有Pod对象被删除

删除Node上相应Pod容器

是否有修改Pod信息

修改Node上Pod的信息

> > > >

2. kube-controller-manager与API Server

Controller Manager包含许多控制器，例如Endpoint Controller、Replication Controller、Service Account Controller等, 具体会在后面Controller Manager部分说明，这些控制器通过API Server提供的接口去实时监控当前kubernetes集群中每个资源对象的状态变化并将最新的信息保存在Etcd中，当集群中发生各种故障导致系统发生变化时，各个控制器会从Etcd中获取资源对象信息并尝试将系统状态修复至理想状态。

> > > >

3. kube-scheduler与API Server

Scheduler通过API Server的Watch接口监听Master节点新建的Pod副本信息并检索所有符合该Pod要求的Node列表同时执行调度逻辑，成功后将Pod绑定在目标节点处。

由于在集群中各组件频繁对API Server进行访问，各组件采用了缓存机制来缓解请求量，各组件定时从API Server获取资源对象信息并将其保存在本地缓存中，所以组件大部分时间是通过访问缓存数据来获得信息的。

二、Controller Manager

Controller Manager在Pod工作流中起着管理和控制整个集群的作用，主要对资源对象进行管理，当Node节点中运行的Pod对象或是Node自身发生意外或故障时，Controller Manager会及时发现并处理，以确保整个集群处于理想工作状态。

Controller Manager组成如图4所示：

m2AB3uQ.jpg!web

图4

由图4我们可以看出Controller Manager由8个不同的控制器组成。以下主要对Replication Controller、Endpoint Controller予以说明。

> > > >

1. Replication Controller

Replication Controller称为副本控制器，在Pod工作流中主要用于保证集群中Replication Controller所关联的Pod副本数始终保持在预期值，比如若发生节点故障的情况导致Pod被意外杀死，Replication Controller会重新调度保证集群仍然运行指定副本数，另外还可通过调整Replication Controller中spec.replicas属性值来实现扩容或缩容。

> > > >

2. Endpoint Controller

Endpoint用来表示kubernetes集群中Service对应的后端Pod副本的访问地址，Endpoint Controller则是用来生成和维护Endpoints对象的控制器，其主要负责监听Service和对应Pod副本变化。如果监测到Service被删除，则删除和该Service同名的Endpoints对象；如果监测到新的Service被创建或是被修改，则根据该Service信息获得相关的Pod列表，然后创建或更新对应的Endpoints对象；如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。图5所示为Service、Endpoint、Pod的关系：

VBnYj2R.png!web

图5

三、Scheduler

Scheduler在整个Pod工作流中负责调度Pod到具体的Node节点，Scheduler通过API Server监听Pod状态，如果有待调度的Pod，则根据Scheduler Controller中的预选策略和优选策略给各个预备Node节点打分排序，最后将Pod调度到分数最高的Node上，然后由Node中的Kubelet组件负责Pod的启停。当然如果部署的Pod指定了NodeName属性，Scheduler会根据NodeName属性值调度Pod到指定Node节点。

整个调度流程分为两步，如图6所示：

q6jyAbq.png!web

图6

第一步预选策略（Predicates）

预选策略的主要工作机制是遍历所有当前kubernetes集群中的Node，按照具体的预选策略选出符合要求的Node列表;如果没有符合的Node节点，则该Pod会被暂时挂起，直到有Node节点能满足条件。通用的预选策略筛选规则有：

PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector。

第二步优选策略（Priorities）

有了第一步预选策略的筛选后，再根据优选策略给待选Node节点打分，最终选择一个分值最高的节点去部署 Pod。kubernetes 用一组优先级函数处理每一个待选的主机。每一个优先级函数会返回一个0-10的分数，分数越高表示节点越适应需求，同时每一个函数也会对应一个表示权重的值。最终主机的得分用以下公式计算得出：

FinalScoreNode = (weight1 priorityFunc1) + (weight2 priorityFunc2) + … + (weightn * priorityFuncn)

典型的优选策略规则

> > > >

1. LeastRequestedPriority

如果新的 Pod 要分配一个Node节点，这个节点的优先级就由节点空闲的那部分与总容量的比值（（总容量-节点上Pod的容量总和-新Pod的容量）/总容量）来决定。cpu和 memory权重相当，比值最大的Node节点得分最高。这个优先级函数起到了按照资源消耗来跨Node节点分配 Pods 的作用。计算公式如下：

FinalScoreNode = cpu((capacity – sum(requested)) 10 / capacity) + memory((capacity – sum(requested)) 10 / capacity) / 2

> > > >

2. BalancedResourceAllocation  

优先从备选节点列表中选择各项资源使用率最均衡的Node节点。BalancedResourceAllocation 必须和 LeastRequestedPriority 同时使用而不能单独使用，它们分别计算主机上的 cpu和 memory 的比重，Node节点分值由 cpu 比重和 memory 比重的“距离”决定。计算公式如下：

FinalScoreNode = 10 – abs(cpuFraction-memoryFraction)*10

> > > >

3. SelectorSpreadPriority

对于属于同一个 Service、Replication Controller 的 Pod，尽量分散在不同的Node上。如调度一个 Pod 的时候，先查找 Pod 对应的Service或 Replication Controller，然后查找 Service 或 Replication Controller 中已存在的 Pod，Node节点上运行的已存在的 Pod 越少，Node的打分越高。

四、Kubelet

简而言之，Kubelet在Pod工作流中是为保证它所在的节点Pod能够正常工作，核心为监听API Server，当发现节点的Pod配置发生变化则根据最新的配置执行相应的动作，保证Pod在理想的预期状态，其中对Pod进行启停更新操作用到的是容器运行时（Docker、Rocket、LXD）。另外Kubelet也负责Volume（CVI）和网络（CNI）的管理。

在Pod工作流中，当Pod被分配至Node节点后Kubelet就去管理此Pod的生命周期，流程如下：

VfuA7vI.jpg!web

图7

五、总结

以上是对kubernetes四个重要组件API Server、Controller Manager、Scheduler、Kubelet工作机制的解析，相信大家读完以后对这四种组件一定有了自己的见解，笔者建议在kubernetes环境中部署应用前一定要理解kubernetes的组件架构，这样不仅有益于集群出现问题时的故障排查，也有助于个人理解kubernetes机制。

kubernetes版本迭代十分频繁，目前已更新到v1.11，以上关于kubernetes相关特性在之后的版本中可能会被弃用或更改，笔者的观点也只限于v1.11及之前的版本，希望感兴趣的同学们密切关注官方文档的更新状况以获取最新消息。

参考文献：

[1]. https://blog.qikqiak.com/post/pod-workflow/ 

[2].https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/devel/scheduler_algorithm.md 

[3]. http://cizixs.com/2017/06/06/kubelet-source-code-analysis-part-1 

[4]. https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ 

[5].http://www.huweihuang.com/article/kubernetes/core-principle/kubernetes-core-principle-controller-manager/

[6].http://www.huweihuang.com/article/kubernetes/core-principle/kubernetes-core-principle-api-server/ 

[7].http://www.huweihuang.com/article/kubernetes/core-principle/kubernetes-core-principle-kubelet/ 

内容编辑：云安全实验室 浦明  责任编辑：肖晴

往

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

关于我们

绿盟科技研究通讯由绿盟科技创新中心负责运营，绿盟科技创新中心是绿盟科技的前沿技术研究部门。包括云安全实验室、安全大数据分析实验室和物联网安全实验室。团队成员由来自清华、北大、哈工大、中科院、北邮等多所重点院校的博士和硕士组成。

绿盟科技创新中心作为“中关村科技园区海淀园博士后工作站分站”的重要培养单位之一，与清华大学进行博士后联合培养，科研成果已涵盖各类国家课题项目、国家专利、国家标准、高水平学术论文、出版专业书籍等。

我们持续探索信息安全领域的前沿学术方向，从实践出发，结合公司资源和先进技术，实现概念级的原型系统，进而交付产品线孵化产品并创造巨大的经济价值。

2YzMjqj.jpg!web

长按上方二维码，即可关注我们


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK