圣诞节文案，Kubernetes 的总价构图和各组件的详细总结

---

一、Kubernetes的总架构图

二、Kubernetes各个组件介绍

1.kube-master[控制节点]

master的工作流程图

工作流程：

(1)Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。

(2)Kubernetes Client将请求发送给API server。

(3)API Server根据请求的类型，比如创建Pod时storage类型是pods，
然后依此选择何种REST Storage API对请求作出处理。

(4)REST Storage API对的请求作相应的处理。

(5)将处理的结果存入高可用键值存储系统Etcd中。

(6)在API Server响应Kubecfg的请求后，Scheduler会根据
Kubernetes Client获取集群中运行Pod及Minion/Node信息。

(7)依据从Kubernetes Client获取的信息，Scheduler将未分发的Pod
分发到可用的Minion/Node节点上。

2.API Server[资源操作入口]

2.1 什么是API Server ？

提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据。

只有API Server与存储通信，其他模块通过API Server访问集群状态。

第一，是为了保证集群状态访问的安全。
第二，是为了隔离集群状态访问的方式和后端存储实现的方式：
API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。

作为kubernetes系统的入口，封装了核心对象的增删改查操作

以RESTFul接口方式提供给外部客户和内部组件调用。

对相关的资源数据“全量查询”+“变化监听”，实时完成相关的业务功能。

2.2 API Server 的功能

1.提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；

2.提供其他模块之间的数据交互和通信的枢纽（其他模块通过
API Server查询或修改数据，只有API Server才直接操作etcd）;

3.是资源配额控制的入口；

4.拥有完备的集群安全机制.

2.3 API Server 的工作原理图

2.4 如何访问 API Server

k8s通过kube-apiserver这个进程提供服务，该进程运行在单个
k8s-master节点上。

2.4.1 默认有两个端口

（1）本地端口
1.该端口用于接收HTTP请求；
2.该端口默认值为8080，可以通过API Server的启动参数
“–insecure-port”的值来修改默认值；
3.默认的IP地址为“localhost”，可以通过启动参数
“–insecure-bind-address”的值来修改该IP地址；
4.非认证或授权的HTTP请求通过该端口访问API Server。

（2）安全端口
1.该端口默认值为6443，可通过启动参数“–secure-port”的值来修改默认值；
2.默认IP地址为非本地（Non-Localhost）网络端口，通过启动参数
“–bind-address”设置该值；
3.该端口用于接收HTTPS请求；
4.用于基于Tocken文件或客户端证书及HTTP Base的认证；
5.用于基于策略的授权；
6.默认不启动HTTPS安全访问控制。

2.4.2 访问方式

Kubectl Proxy

Kubectl Proxy代理程序既能作为API Server的反向代理，也能作为普通客户端访问API Server的代理。

通过master节点的8080端口来启动该代理程序。

kubectl proxy --port=8080 &

具体见kubectl proxy --help

2.5 通过API Server访问Node、Pod和Service

k8s API Server最主要的REST接口是资源对象的增删改查。

另外还有一类特殊的REST接口—k8s Proxy API接口，这类接口的作用是代理REST请求。

即kubernetes API Server把收到的REST请求转发到某个Node上的kubelet守护进程的REST端口上，由该kubelet进程负责响应。

2.5.1 Node相关接口

关于Node相关的接口的REST路径为：
/api/v1/proxy/nodes/{name}
其中{name}为节点的名称或IP地址。

这里获取的Pod信息来自Node而非etcd数据库，
两者时间点可能存在偏差。

如果在kubelet进程启动时加–enable-debugging-handles=true参数，
那么kubernetes Proxy API还会增加以下接口：

2.5.2 Pod相关接口

2.5.3 Service相关接口

Pod的proxy接口的作用：在kubernetes集群之外访问某个pod容器的服务（HTTP服务），可以用Proxy API实现，这种场景多用于管理目的。

比如逐一排查Service的Pod副本，检查哪些Pod的服务存在异常问题。

三.集群功能模块之间的通信

kubernetes API Server 作为集群的核心，负责集群各功能模块之间的通信，集群内各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，通过API Server提供的REST接口（GET/LIST/WATCH方法）来实现，从而实现各模块之间的信息交互。

1.kubelet与API Server交互

每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态，API Server接收这些信息后，将节点状态信息更新到etcd中。kubelet也通过API Server的Watch接口监听Pod信息，从而对Node机器上的POD进行管理。

2.kube-controller-manager 与API Server交互

kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口，实时监控Node的信息，并做相应处理。

3.kube-scheduler与API Server交互

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

4.特别说明

为了缓解各模块对API Server的访问压力，各功能模块都采用缓存机制来缓存数据，各功能模块定时从API Server获取指定的资源对象信息（LIST/WATCH方法），然后将信息保存到本地缓存，功能模块在某些情况下不直接访问API Server，而是通过访问缓存数据来间接访问API Server。

四.Controller Manager[内部管理控制中心]

Controller Manager作为集群内部的管理控制中心。

负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理。

当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。

1.Replication Controller

为了区分，将资源对象Replication Controller简称RC,
而本文中是指Controller Manager中的Replication Controller，
称为副本控制器。
副本控制器的作用即保证集群中一个RC所关联的Pod副本数始终保持预设值。

1.只有当Pod的重启策略是Always的时候（RestartPolicy=Always），副本控制器才会管理该Pod的操作（创建、销毁、重启等）。
2.RC中的Pod模板就像一个模具，模具制造出来的东西一旦离开模具，它们之间就再没关系了。一旦Pod被创建，无论模板如何变化，也不会影响到已经创建的Pod。
3.Pod可以通过修改label来脱离RC的管控，该方法可以用于将Pod从集群中迁移，数据修复等调试。
4.删除一个RC不会影响它所创建的Pod，如果要删除Pod需要将RC的副本数属性设置为0。
5.不要越过RC创建Pod，因为RC可以实现自动化控制Pod，提高容灾能力。

1.1. Replication Controller的职责

（1）确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量。
（2）通过调整RC中的spec.replicas属性值来实现系统扩容或缩容。
（3）通过改变RC中的Pod模板来实现系统的滚动升级。

1.2. Replication Controller使用场景

2. Node Controller

kubelet在启动时会通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server接收到信息后将信息更新到etcd中。

Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node节点的相关控制功能。

流程如下

1、Controller Manager在启动时如果设置了–cluster-cidr参数，那么为每个没有设置Spec.PodCIDR的Node节点生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR属性，防止不同的节点的CIDR地址发生冲突。

2、具体流程见以上流程图。

3、逐个读取节点信息，如果节点状态变成非“就绪”状态，则将节点加入待删除队列，否则将节点从该队列删除。

3.ResourceQuota Controller

资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。

支持三个层次的资源配置管理：

1）容器级别：对CPU和Memory进行限制

2）Pod级别：对一个Pod内所有容器的可用资源进行限制

3）Namespace级别：包括

说明：

1.k8s配额管理是通过Admission Control（准入控制）来控制的；
2.Admission Control提供两种配额约束方式：
LimitRanger和ResourceQuota；
3.LimitRanger作用于Pod和Container；
4.ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。

4.Namespace Controller

用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息。

如果Namespace被API标记为优雅删除
（即设置删除期限，DeletionTimestamp）,
则将该Namespace状态设置为“Terminating”,并保存到etcd中。

同时Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod等资源对象。

5.Endpoint Controller

Service、Endpoint、Pod的关系：

Endpoints表示了一个Service对应的所有Pod副本的访问地址，

而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。
它负责监听Service和对应的Pod副本的变化。

1.如果监测到Service被删除，则删除和该Service同名的Endpoints对象；

2.如果监测到新的Service被创建或修改，则根据该Service信息获得相关的Pod列表，然后创建或更新Service对应的Endpoints对象。

3.如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。

kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡功能。

6.Service Controller

Service Controller是属于kubernetes集群与外部的云平台之间的一个接口控制器。

Service Controller监听Service变化。

如果是一个LoadBalancer类型的Service，则确保外部的云平台上对该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。

五. Scheduler[集群分发调度器]

1.Scheduler简介

Scheduler负责Pod调度。在整个系统中起"承上启下"作用，

承上：负责接收Controller Manager创建的新的Pod，
为其选择一个合适的Node；

启下：Node上的kubelet接管Pod的生命周期。

Scheduler：

1）通过调度算法为待调度Pod列表的每个Pod从Node列表中选择一个最适合的Node，并将信息写入etcd中

2）kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应的Pod清单，下载Image，并启动容器。

2.调度流程

1、预选调度过程，即遍历所有目标Node,筛选出符合要求的候选节点，kubernetes内置了多种预选策略（xxx Predicates）供用户选择

2、确定最优节点，在第一步的基础上采用优选策略（xxx Priority）计算出每个候选节点的积分，取最高积分。

调度流程通过插件式加载的“调度算法提供者”（AlgorithmProvider）具体实现，一个调度算法提供者就是包括一组预选策略与一组优选策略的结构体。

3.预选策略

说明：返回true表示该节点满足该Pod的调度条件；返回false表示该节点不满足该Pod的调度条件。

3.1. NoDiskConflict

判断备选Pod的数据卷是否与该Node上已存在Pod挂载的数据卷冲突，如果是则返回false，否则返回true。

3.2. PodFitsResources

判断备选节点的资源是否满足备选Pod的需求，即节点的剩余资源满不满足该Pod的资源使用。

（1）计算备选Pod和节点中已用资源（该节点所有Pod的使用资源）的总和。
（2）获取备选节点的状态信息，包括节点资源信息。
（3）如果（备选Pod+节点已用资源>该节点总资源）则返回false，即剩余资源不满足该Pod使用；否则返回true。

3.3. PodSelectorMatches

判断节点是否包含备选Pod的标签选择器指定的标签，即通过标签来选择Node。

（1）如果Pod中没有指定spec.nodeSelector，则返回true。
（2）否则获得备选节点的标签信息，判断该节点的标签信息中是否包含该Pod的spec.nodeSelector中指定的标签，如果包含返回true，否则返回false。

3.4. PodFitsHost

判断备选Pod的spec.nodeName所指定的节点名称与备选节点名称是否一致，如果一致返回true，否则返回false。

3.5. CheckNodeLabelPresence

检查备选节点中是否有Scheduler配置的标签，如果有返回true，否则返回false。

3.6. CheckServiceAffinity

判断备选节点是否包含Scheduler配置的标签，如果有返回true，否则返回false。

3.7. PodFitsPorts

判断备选Pod所用的端口列表中的端口是否在备选节点中已被占用，
如果被占用返回false，否则返回true。

4.优选策略

4.1 LeastRequestedPriority

优先从备选节点列表中选择资源消耗最小的节点（CPU+内存）。

4.2. CalculateNodeLabelPriority

优先选择含有指定Label的节点。

4.3. BalancedResourceAllocation

优先从备选节点列表中选择各项资源使用率最均衡的节点。