Kubernetes架构
一、k8s的架构（有哪些组件、每个组件负责什么。组件的交互）
·有哪些组件、每个组件负责什么：
一个 Kubernetes 集群由很多节点组成。节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。
工作节点托管作为应用负载的组件的Pod。
控制平面管理集群中的工作节点和 Pod。
为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。
控制平面组件：能对集群做出全局决策，以及检测和响应集群事件。可在任何节点上运行。
注：控制平面是指容器编排层，它暴露API和接口来定义、部署容器和提供容器的生命周期。
kube-apiserver：是整个系统的对外接口，提供一套 RESTful 的 Kubernetes API，供客户端和其它组件调用。提供k8s里对所有资源的增、删、改、查等操作的入口，提供认证、授权、访问控制、API注册和发现等机制。进行集群管理和资源配额控制。
注：所有状态被存储在etcd中。
kube-scheduler：负责进行资源调度，按照相应的调度策略将Pod（新创建的、未指定运行节点node的Pod）调度到相应的node节点。
kube-controller-manager：在主节点上运行控制器（由控制器完成的功能主要包括生命周期功能和API业务逻辑）的组件。所有资源对象的自动化控制中心。负责管理控制器，维护集群的状态。
控制器包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）。
Etcd：作为数据后端，是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
注：通过 Etcd 来存储所有的主节点上的状态信息，很容易实现主节点的分布式扩展。
cloud-controller-manager：指嵌入特定云的控制逻辑的控制平面组件。
Node组件：在每个工作节点Node上运行，维护运行的pod并提供k8s运行环境。
Node节点是k8s的工作节点，Node上的工作负载由Master节点分配，工作负载主要运行容器应用。
kubelet：每个节点（node）上运行的代理。它保证容器（containers）都运行在 Pod中。负责Pod的创建、启动、监控、重启、销毁等工作，同时也负责Volume和网络的管理。kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。（负责具体的容器生命周期管理）
kube-proxy：是节点上的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod（同一类标签）。
容器运行时（Container-Runtime）：是负责运行容器的软件。
除了上述组件，还有一些基本的操作对象：
例如，
Pod（集群操作的最小单位，可容纳一或多个容器，一般不直接操作Pod，而是通过k8s控制器来控制）
Service（一组提供相同服务的Pod的逻辑抽象，定义其逻辑集合并提供Pod的访问入口）。
Namespace：可将系统内不同对象划分到不同命名空间，形成逻辑上不同分组，使每个应用程序独立运行，使得资源配置灵活、方便。
等等……
Master：集群控制管理节点，所有的命令都经由master处理。
Node：是kubernetes集群的工作负载节点。Master为其分配工作，当某个Node宕机时，Master会将其工作负载自动转移到其他节点。
·组件的交互：
- Pod和Service关联：
Pod由Pod控制器创建，由Service提供内部和外部访问。Pod控制器通过YAML文件来定义Pod资源对象，文件中会对Pod对象打标签以辨识Pod。Service可通过标签选择器来关联同一标签类型的Pod资源对象。
- Pod的创建逻辑流程：
- 用户通过REST API创建一个Pod
- apiserver将其写入etcd
- scheduler检测到未绑定Node的Pod，开始调度并更新Pod的Node绑定
- kubelet 检测到有新的 Pod 调度过来，通过 container runtime 运行该 Pod
- kubelet 通过 container runtime 取到 Pod 状态，并更新到 apiserver 中
详细：
- 客户端提交创建请求，可以通过API Server的Restful API，也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML。
- API Server处理用户请求，存储Pod数据到etcd。
- 调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。
- 过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。
- 主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。
- 选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中。
- kubelet根据调度结果执行Pod创建操作：绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器。
- 一个Kubernetes集群由master和node组成。如下图：
Master：是集群的网关和中枢枢纽，主要作用：暴露API接口，跟踪其他服务器的健康状态、以最优方式调度负载，以及编排其他组件之间的通信。单个的Master节点可以完成所有的功能，但是考虑单点故障的痛点，生产环境中通常要部署多个Master节点，组成Cluster。
Node：是Kubernetes的工作节点，负责接收来自Master的工作指令，并根据指令相应地创建和销毁Pod对象，以及调整网络规则进行合理路由和流量转发。生产环境中，Node节点可以有N个。
- scheduler负责哪些工作，大体实现是怎样的？
scheduler负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
控制平面组件，负责接收和监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。安置完成后，目标Node上的kubelet服务进程接管后继工作。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
默认调度流程认为两步：
- 预选调度过程，即遍历所有目标Node，筛选出所有符合要求的候选节点（有多种候选策略）。
- 确定最优节点，在上述基础上，采用优选策略，计算每个候选节点的积分，积分高者胜出。
调度流程的具体实现是通过插件方式加载的调度算法提供者（algorithmProvider），一个algorithmProvider其实就包含了一组预算策略与一组优先选择策略的结构体，注册algorithmProvider的函数如下：
func RegisterAlgorithmProvider(name string, predicateKeys, priorityKeys)
包含三个参数，第一个参数是算法名，第二个参数为算法用到的预选策略集合，第三个为优选策略集合。
可用的预选策略包含：NoDiskConflict、PodFitsResources，PodSelectorMatches，PodFItsHost等。其默认的algorithmProvider加载的预选策略Predicate包括：PodFItsHost，PodFitsResources，NoDiskConflict，MatchNodeSelector和Hostname。
也就是说只有每个节点通过这五个默认预选策略后，才能初步选中，进入下一个流程，也就是优选流程。
下面列出所有预选策略的详细说明：
- NoDiskConflict：判断备选Pod的GCEPresidentDisk（谷歌云）或AWSElasticBlockStore（亚马逊云）和备选节点中已存在的Pod是否存在冲突。
如果检查完备选Pod的所有volume与备选节点上的pod的每个volume均为发现冲突，则返回true，表明不存在冲突。反馈给调度器该备选节点适合备选的Pod。
2.PodFitsResource：判断备选节点的资源是否满足备选Pod的需求。
若备选pod和节点中已存在Pod的所有容器的需求资源的总和超过了备选节点拥有的资源，则返回flase，否则true。
3.PodsSelectorMatches：判断备选节点是否包含备选Pod的标签选择器指定的标签。
如果pod没有指定spec.nodeSelector标签选择器，则返回true。否则，获得备选节点的标签信息，判断节点是否包含备选Pod的标签选择器所指定的标签。若包含则返回true，否则false。
4.PodFitsHost：判断备选Pod的spec.nodename所指定的节点名称与备选节点名称是否一致。若一致，则返回true，否则false。
5.checkNodeLabelPresence
如果用户在配置文件汇总指定了该策略，则scheduler会通过RegisterCustomFitPredicate方法注册该策略，该策略用于判断策略列出的标签在备选节点中存在时，是否选择该备份节点。
首先读取备份节点的标签列表信息，如果策略配置的标签列表存在于备选节点的标签列表中，且策略配置的presence值为false，则返回false，否则返回true；如果策略配置的标签列表不存在于备份节点的标签列表中，且策略配置的presence值为true，则返回false，否则返回true。
6.PodFitsPorts
判断备选pod所用的端口列表中的端口是否在备选节点中已被占用，如果被占用，则返回false，否则返回true。
以上是scheduler的预选策略，那么优选策略包含：LeastRequestdPriority，CalculateNodeLabelPriority和BalancedResourceAllocation等。每个节点通过优选策略时都会计算出一个得分，计算各项得分，最终选出分值最大的节点作为结果。
下面是对所有优选策略的详细说明
1.LeastRequestdPriority：该优选策略用于从备选节点列表中选出资源消耗最小的节点。
首先计算出所有备选节点上运行的Pod和备选Pod的CPU占用量totalmilliCPU
然后计算出所有备选节点上运行的Pod和备选Pod的内存占用量totalMemory
然后计算出每个节点的得分即可。规则大致如下
NodeCpuCapacity为节点CPU计算能力，NodeMemoryCapacity为节点内存大小。
score=int(((nodeCpuCapacity-totalmilliCPU)*10)/ NodeCpuCapacity+ ((NodeMemoryCapacity-
totalMemory)*10)/NodeMemoryCapacity)/2)
2.CalculateNodeLabelPriority：如果用户在配置文件中指定了该策略，则scheduler会通过RegisterCustomPriorityFunction方法注册该策略，该策略用于判断策略列出的标签在备选节点中存在时，是否选择该备选节点。
若备选节点的标签在优选策略的标签列表中且优选策略的presence值为true，或者备选节点的标签不在优选策略的标签列表中且优选策略的presence值为false，则备选节点score=10，否则为0。
3.BalancedResourceAllocation：该优选策略用于从备选节点列表中选出各项资源使用率最为均衡的节点。首先计算出所有备选节点上运行的Pod和备选Pod的CPU占用量totalmilliCPU，计算出计算出所有备选节点上运行的Pod和备选Pod的内存占用量totalMemory
计算得分，规则如下：
NodeCpuCapacity为节点CPU计算能力，NodeMemoryCapacity为节点内存大小。
score=int(10-math.abs(totalmilliCPU/NodeCpuCapacity-totalMemory/NodeMemoryCapacity)*10)