首页 > Web开发 > 详细

Kubernetes核心原理笔记

时间:2019-12-07 16:50:12      阅读:85      评论:0      收藏:0      [点我收藏+]

                 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当前提供了两种方式的配额约束,分别是LimitRangerReourceQuota,其中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"目录,将获取的信息同步到本地缓存

今天先写这么多吧,之后再更新......

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kubernetes核心原理笔记

原文:https://www.cnblogs.com/qinghe123/p/12001473.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!