kubernetes权威指南阅读笔记
笔记来自kubernetes权威指南，如需更详细的教程还请阅读原书，笔记只记录相关重要知识点，当然一下总结也包含一些自己的总结，有异议可以留言交流
Kubernetes API Server原理分析：
1.Kubernetes API Server通过一个进程名为kube-apiserver的进程提供服务，默认进程在本机端口(--insecure-port)提供REST 服务，同时通过HTTPS安全端口(--secure-port=6443)来启动安全机制
2.如果只想对外提供部分REST服务，则可以在master或者其他任何节点通过运行kubectl proxy进程启动一个内部代理实现，支持--reject-paths、--accept=hosts限制访问路径和访问来源
3.Kubernetes API Server最主要的REST接口是资源对象的增、删、改、查，除此之外，它还提供了一类特殊的REST接口——Kubernetes Proxy API 接口，这类接口的作用是代理请求，即Kubernetes API Server把收到的REST请求转发到某个Node上的kubelet守护进程的REST端口上，由kubelet进程负责响应，部分接口列表：/api/v1/proxy/nodes/{name}/pods/ #列出指定节点内所有Pod信息 /api/v1/proxy/nodes/{name}/stats/ #列出指定节点物理资源统计信息 /api/v1/proxy/nodes/{name}/spec/ #列出指定节点的概要信息 /api/v1/proxy/nodes/{name}/run #在指定节点运行某个容器 /api/v1/proxy/nodes/{name}/metrics # 列出指定节点相关的Metics信息等还可以直接访问某个Pod里容器运行的服务...
4.集群功能模块之间的通信，Kubernetes API Server作为集群的核心，负责各功能模块之间的通信，集群内各功能模块通过API Server将信息写入etcd，需要这些数据时，又通过API Server提供的REST接口(GET/LIST/WATCH)来实现，从而实现各模块之间的信息交互
5.kubelet与API Server交互。每个Node节点上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server收到这些信息后会更新到etcd中。此外kubelet也会通过API Server的WATCH接口监听Pod信息，如果监听到新的Pod副本被调度绑定到本几点，则执行Pod对应的容器的创建和启动逻辑，只有会详细更新此部分内容。删除和修改同理
6.API Server和kube-scheduler的交互。Scheduler通过API Server的Watch接口监听到新pod副本信息后，它会检索所以符合Pod要求的Node列表，开始执行Pod调度逻辑，调度成后将Pod绑定到目标节点
7.为了缓解集群各模块对API Server的访问压力，各功能模块都采用了缓存机制来缓存数据，各功能模块定时从API Server获取指定的资源对象信息(通过LIST及WATCH方法)，然后将这些信息保存到本地缓存，功能模块在某些情况下不直接访问API Server，而是通过访问缓存数据间接访问API Server，后面会详细介绍
Controller Manager原理分析(重点)
1.Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额(ResourceQuota)等的管理，当某个Node意外宕机时，Conroller Manager会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态
2.Controller Manager包含： Replication Controller、Node Controller、Ingress Controller、ResourceQuto Controller、Namespace Controller、Service Controller、ServiceAccount Controller、Token Controller、Endpoint Controller等，每个Controller都是一种具体的控制流程，而Controller正式这些Controller的核心管理者
3.一般我们俗称的自动系统和智能系统通常都会被一个"操纵系统"的机构不断修正系统的工作状态。所以我们可以把每个Controller都理解为这样一个个"操纵系统"，它们通过API Server提供的接口实时监控整个集群里的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试着将系统状态从"现有状态"修正到"预期状态"。
a) Replication Controller（副本控制器）本节不讨论资源对象Replication Controller
1.Replication Controller的核心作用是确保任何时候集群中一个RC所关联的Pod副本数量保持预设值。如果发现Pod副本数量少于或者超过预期值，则会自动创建或减少Pod副本，知道符合条件的Pod副本数量达到预设值(注意：只有当Pod的重启策略是Always即RestartPolicy=Always)，Replication Controller才会管理该Pod的操作。通常情况下Pod对象被设置成功创建后不会消失，唯一的例外是当Pod处于successed或failed状态的时间过长时该Pod会被系统自动回收，管理该Pod的副本控制器将在其他工作节点重新创建、运行该Pod副本
2.RC中的Pod模板就像模具，模具制作出来的东西一旦离开模具，它们之间就再没关系了。同样一旦Pod被创建完毕，无论模板如何变化，都不会影响已创建的Pod
3.Pod可以通过修改它的标签来实现脱离RC的管控，该方法可以用于将Pod从集群中千亿、数据修复等调试。对于被迁移的副本RC会自动创建一个副本替换
4.RC职责： 确保当前集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数 当通过调整RC的spec.relicas属性值来实现系统扩容和收缩 通过实现RC中的Pod模板(主要是镜像版本)来实现系统的滚动升级
b) Node Controller
1.kubelet进程在启动时通过API Server注册自身的节点信息，并定时向API Server汇报状态信息。API Server接收到这些信息后，将这些信息更新到etcd中，etcd存储节点信息包含节点健康状况、节点资源、节点名称、节点地质信息、节点操作版本、Docker版本、kubelet版本。节点健康状况包含"就绪""未就绪""Unknow"三种
2.Node Controller通过API Server实时获取Node相关信息，实现管理和监控集群中的各个Node节点的相关控制功能
3.Node Controller核心工作流程如下：如果Controller Manager设置了"--cluster-cidr"参数---->则为每个Node配置"Spec.PodCIDR"--->逐个读取node信息，并和本地nodeStatusMap做比较--->没有收到节点信息或第一次收到节点信息，或在该处理过程中节点状态变成非"健康"状态(用Master节点的系统时间作为探测时间和节点状态变化时间) || 在指定时间内收到信的节点信息，且节点状态发生变化(用Master节点的系统时间作为探测时间和节点状态变化时间) || 在指定时间内收到新的节点信息，但节点状态没发生变化(用Master节点的系统时间作为探测时间，用上次节点信息中的节点状态变化时间作为该节点的状态变化时间) ---> 如果在某一段时间内没有收到节点状态信息，则设置节点状态未"未知" --- > 删除节点或同步节点信息
4.Controller Manger设置--cluster-cidr参数，是为每个没有设置Spec.PodCIDR的node节点生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR属性，这样做的目的是防止不同节点的CIDR地址发生冲突，这相当于每个节点的唯一标识符
5.逐个读取节点信息，多次尝试修改nodeStatusMap中的节点信息状态，将该节点和nodeStatusMap中保存的节点信息做比较。如果判断出kubelet发送的节点信息、第1次收到节点kubelet发送的节点信息或者在处理过程中节点状态变为非"健康"状态，则在nodeStatusMap中保存的节点信息，并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息，且节点状态发生变化，则在nodeStatusMap保存节点的状态信息。如果判断出在指定时间内收到新的节点信息，但节点状态没发生变化，则在nodeStatusMap中保存节点信息，并用Node Controller节点所在系统时间作为探测时间和节点状态变化时间，用上次节点信息中的节点状态变化时间作为该节点的状态变化时间。如果在某一段时间内(gracePeriod)没有收到节点状态信息，则设置节点状态为"未知"，并通过API Server保存节点状态
6.逐个读取节点信息，如果节点状态为非"就绪"状态，则将节点加入待删除队列，否则将节点从该队列中删除。如果节点状态为非"就绪"状态，且系统指定了Cloud Provider，则Node Controller调用Cloud Provider查看节点，若发现节点故障，则删除etcd中的节点信息，并删除和该节点相关的Pod等资源信息
c) ResourceQuota Controller
1.ResourceQuota Controller(资源配额管理)确保了指定的资源对象在任何时候都不会超量占用系统物理资源，避免了某些业务进程的设计或实现导致整个系统运行崩溃，地整个集群的文档运行和稳定性有非常重要的作用
2.Kubernetes支持三个层次的资源配额管理： 容器级别，可以对CPU和Memory进行限制 Pod级别，可以对Pod内所以容器的可用资源进行限制 Namespace级别，为Namespace级别的资源限制包括：Pod数量、Replication Controller数量、Service数量、ResourceQuota数量、secret数量、可持有的PV数量
3.Kubernetes的资源配额管理是通过Admission Control(准入控制)来控制的，Admission Control当前提供了两种方式的配额约束，分别是LimitRanger与ReourceQuota，其中LimitRanger作用于Pod和Container上，而ResourceQuota则作用于Namespace上，限制一个Namespace里的各类资源的使用总额
4.如果在Pod定义中声明了LimitRanger，则用户通过API Server请求创建或修改资源时，Admission Controller会计算当前配额使用情况，如果不符合配额约束则会创建对象失败。对于定义了ResourceQuota的Namespace，ResourceQuota Controller组件负责定期统计和生成该Namespace下的各类对象资源的使用总量，以及改Namespace下所有Container实例所使用的资源量(目前包括CPU和内存)，然后将这些统计结果写入etcd的resourceQuotaStatusStorage目录(resourceQuotas/status)中。随后这些信息被Admission Control使用，以确保相关namespace下的资源peie总量不会超过ResourceQuota
中设定的值
d) Namespace Controller
1.用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息。如果Namespace被API标识为优雅删除(通过设置删除期限，即DeletionTimestamp属性被设置)，则将该Namespace的状态设置成Terminating并保存etcd中。同时删除Namespace下的ServiceAccount、RC、Pod、Secret、PersistenVolume、ListRange、ResourceQuota和Event等资源对象
2.当Namespace状态被设置成Terminating后，有Admission Controller的NamespaceLifecycle插件来阻止为该Namespace创建新的资源。同时在Namespace Controller删除完该Namespace中的所有资源对象后，Namespace Controller对该Namespace执行finalize操作，删除Namespace的spec.finalizers。如果Namespace Controller观察到Namespace设置了删除期限，同时Namespace的spec.finalizers域值是空的，那么Namespace Controller将通过API Server删除该Namespace资源
e) Service Controller 和 Endpoint Controller
1.Endpoints表示一个Service对应的所有Pod副本的访问地址，而Endpoint Controller就是负责生成和维护所有Endpoints对象的控制器
2.Endpoint Controller监听了Service和对应的Pod副本的变化，它如果监听到Service被删除，则删除该Service同名的Endpoint对象，同理更新或者创建
3.Endpoints对象是被每个Node上的kube-proxy进程所使用的，kube-proxy进程获取每个Service的Endpoints，实现了Service的负载均衡功能，之后会有相关详解
4.Service Controller它是属于Kubernetes集群与外部的云平台之间的一个接口控制器，之后会详解
Scheduler原理分析(重要)
1.Kubernetes Scheduler在整个系统中承担的是"承上启下"的重要功能，承上是指它负责接收Controller Manger创建新的Pod，为其安排一个落脚的"家"(node节点)，启下是指安置工作完成之后，目标Node上的kubelet服务进程接管后续工作
2.Kubernetes Scheduler具体作用是将待调度的Pod(API Server新创建、Controller Manager为补足副本而创建的Pod等)按照特定的调度算法和调度策略绑定到集群中某个合适的Node上，并将绑定信息写入etcd中，整个调度过程涉及三个对象：待调度Pod列表、可用Node列表、以及调度算法和调度策略。简单来说，就是通过调度算法调度为待调度Pod列表的每个Pod从Node列表中选择一个最合适的Node，随后目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像，并启动容器
3.Kubernetes Scheduler当前提供的默认调度流程分为如下两步：a:预选调度过程，即遍历所有目标Node，筛选出符合要求的候选节点，为此，Kubernetes内置了多种预选策略(xxx Predicates)供用户选择
b:确定最优节点，在第一步的基础上，采用优选策略(xxx Priority)计算出每个候选节点的积分，积分高者胜出
4.Kubernetes Scheduler的调度流程是通过插件方式加载的"调度算法提供者"(AlgorithmProvider)具体实现的，一个AlogorithmProvider其实就是包括了一组预选策略与一组优选策略的结构体
5.Kubernetes Scheduler中可用的预选策略包含：NoDiskConflict、PodFitsResources、PodSelectorMathes、PodFitsHost、CheckNodeLabelPresence、CheckServiceAffinity、和PodFitsPorts策略等。默认的AlgorithmProvider加载的预选策略Predicates包括：PodFitsPorts(PodFitsPorts)、PodFitsResources(PodFitsResources)、NoDiskConflict(NoDiskConflict)、MatchNodeSelector(PodSelectorMatches)、HostName(PodFitsHost),即每个节点只有通过以上五个默认预选策略后，才能初步被选中。
6.NoDiskConflict: 判断备选Pod的gcePresistentDisk或AWSElasticBlockStore和备选节点中已存在的Pod是否存在冲突，检测过程如下：a): 首先读取备选Pod的所以Volume的信息(即pod.spec.Volume)的信息
7.PodFitsResource:判断备选节点的资源是否满足备选Pod的需求，检测过程：计算备选Pod和几点已存在Pod的所有容器需求资源(内存和CPU)的总和；获得备选节点的状态信息，其中包含节点资源信息；如果备选Pod和节点中已存在的所有容器资源总和超过了备选节点拥有的资源，则返回false，表明备选节点不适合备选Pod，否则返回true，表明备选节点适合备选Pod
8.PodSelectorMatches:判断备选节点是否包含备选Pod的标签悬着器指定的标签。如果Pod没有指定spec.nodeSelector标签选择器，则返回true；否则根据备选节点是否含有备选pod的spec.nodeSelector所指定的所有标签，有则返回true，反正则返回false
9.PodFitsHost：判断备选Pod的spec.nodeName域指定的节点名称和备选节点的名称是否一致
10.CHeckNodeLabelpRresence：如果用户在配置文件中指定了该策略，则Scheduler会通过RegisterCustomFitPredicate方法注册该策略。该策略用于判断策略列出的标签在备选节点存在时，是否选择该节点: a):读取备选节点中的标签列表 b):如果策略配置的标签列表在备选节点的标签列表中，且策略配置的Presence为false，则返回false ，否则返回true； 如果策略配置的标签列表在备选节点的标签列表中不存在，Presence 的值为true， 则返回false， 否则返回true
11.CheckServiceAffinity:如果用户指定了该策略，则Scheduler会通过RegisterCustomFitPredicate方法注册该策略，该策略用于判断备选节点是否包含策略指定的标签，或包含和备选Pod在相同Service和Namespace下的Pod所在节点的标签列表。如果存在，则返回true，反之返回false
12.PodFitsPorts:判断备选Pod所用的端口列表中的端口是否在备选节点中已被占用，如果被占用，则返回false
13.Scheduler 中的优选策略包含： LeastRequestedPriority、CalculateNodeLabelPriority和BalancedResourceAllocation等，每个接单通过优选选择策略时都会算出一个得分，计算各项得分，最终选出分值自大的节点作为优选的结果(也就是调度算法的结果)
a):LeastRequestedPriority:该优选策略用于从备选节点列表中选出资源消耗最小的节点 1：计算出所以备选节点上运行的Pod和备选Pod的CPU占用量totalMilliCPU 2:计算出所有备选节点上运行的Pod和备选Pod的内存占用量totalMemory 3:计算每个节点的得分： NodeCPUCapacity为CPU计算能力，NodeMemoryCapacity为内存大小： score=int(((NodeCPUCapacity-totalMilliCPU )*10) / NodeCPUCapacity+((NodeMemoryCapacity-totalMemory )*10) / NodeMemoryCapacity) / 2)
13.CalculateNodeLabelPriority:如果用户指定了该策略，则scheduler会通过RegisterCustomPriorityFunction方法注册该策略
14.BalancedResouceAllocation：该优选策略用于从备选节点列表选出各项资源使用率最均衡的节点：1：计算所有备选节点上运行的Pod和备选Pod的CPU占用量totalMilliCPU 2: 计算出所有备选节点上运行的Pod和备选Pod的内存占用量totalMemory 3：计算每个节点的得分： score=int(10-math.Abs(totalMilliCPU/nodeCpuCapacity-totalMemory/nodeMemoryCapacity)*10)
Kubelet运行机制分析
1.定义：每个Node节点上都会启动一个kubelet服务进程，该进程用于处理节点下发到本节点的任务，管理Pod及Pod中的容器。每个kubelet进程会在API Server上注册节点自身信息，定期向Master节点汇报节点资源的使用情况
2.节点管理： kubelet可以通过启动参数 "--register-node"来决定是否想API Server注册自己。如果该参数为true，那么kubelet将试着通过API Server注册自己。当前每个kubelet被授予创建和修改任何节点的权限，kubelet通过启动参数"--node-status-update-frequency"设置每隔多长时间向API Server报告节点状态，默认为10s
3.Pod管理：kubelet通过以下自己方式获取自身Node上所运行的Pod清单 1：文件：kubelet启动参数--config指定的配置文件目录下的文件(默认为/etc/kubernetes/manifests/).通过--file-check-frequency设置检查文件目录的间隔时间，默认为20s 2：HTTP端点(URL):通过"--manifest-url"参数设置。通过--http-check-frequency设置检查该HTTP端点数据的时间间隔，默认为20s 3：API Server: kubelet通过API Server监听etcd目录，同步Pod列表
4.以非API Server方式创建的Pod都叫作Static Pod。kubelet将static pod的状态汇报给API Server，API Server为该Static Pod创建一个Mirror Pod和其相匹配。Mirror Pod的状态将真实反映Static Pod的状态。当Static Pod被删除时，与之对应的Mirror Pod也会被删除也会被删除；静态Pod是由kubelet进行管理的仅存于特定Node上的Pod。他们不能通过API Server管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet也无法对他们进行健康检查。静态Pod总是由kubectl进行创建，并且总是在kubelet所在的Node上运行。注意静态Pod的数据是不会存在etcd的
5.kubelet通过API Server Client使用WATCH加LIST方式监听"/registry/nodes/$"获得当前节点的名称和"/registry/pods"目录，将获取的信息同步到本地缓存
今天先写这么多吧，之后再更新......
原文：https://www.cnblogs.com/qinghe123/p/12001473.html