Kubenetes理解性笔记

Kubenetes理解性笔记

主要package

• admission：权限控制框架，采用责任链模式、插件机制。
• api：Kubernetes所提供的Rest API接口的相关类（MetaData结构、Volume结构、Pod结构、Service结构等），以及数据格式验证转换工具。
• apis：实现了HTTP Rest服务的一个基础性框架，用于Kubernetes的各种Rest API的实现，在apis包里实现了HTTP Proxy，用于转发请求。
• auth：3A认证模块，包括用户认证、鉴权的相关组件。
• client：公用的客户端部分的相关代码，实现协议为HTTP Rest，用于提供一个具体的操作，例如对Pod、Service等的增删改查，这个模块也定义了kubeletClient，同时为了高效地进行对象查询，此模块有一个带缓存功能的存储接口Store。
• cloudprovider：定义了云服务提供商运行Kubernetes所需的接口，包括TCPLoadBalancer的获取与创建，获取当前环境中的节点（云主机）列表和节点的具体星系，获取Zone信息，获取和管理路由的接口等。
• controller：提供了资源控制器的简单框架，用于处理资源的添加、变更、删除等事件的派发和执行，同时实现了Kubernetes的RC的具体逻辑。
• kubectl：命令行工具kubectl的代码模块，包括创建Pod、服务、Pod扩容、Pod滚动升级等各种命令的具体实现代码。
• kubelet：定义了Pod 容器的接口，提供了Docker与rkt两种容器实现类，完成了容器以及Pod的创建，以及容器状态的监控、销毁、垃圾回收等功能。
• master：Master节点代码模块，创建NodeRegistry、PodRegistry、ServiceRegistry、EndpointRegistry等组件，并且启动Kubernetes自身的相关服务，服务的ClusterIP地址的分配及服务的NodePort端口分配工作。
• proxy：服务代理和负载均衡相关代码，实现了round-robin（轮询）的负载均衡算法。
• registry：注册表服务的接口及对应Rest服务的相关代码。
• runtime：让多个API版本共存，完成不同API版本的数据结构的转换，集中化API种数据对象的Encode/Decode逻辑。
• volume：实现Kubernetes的各种volume类型，同时实现Kubernetes容器的Volume卷的挂载、卸载功能。
• cmd：包括了Kubernetes所有后台进程的代码（kube-apiserver、kube-controller-manager、kube-proxy、kubelet），这些进程的业务逻辑代码均在pkg包内。
• scheduler：执行具体的Scheduler的调度。

Kubernetes原理笔记

Scheduler调度原理

• 默认的调度流程：预选调度过程（遍历所有目标Node，筛选出符合要求的候选节点）、确定最优节点（采用优选策略计算出每个候选节点的积分，积分最高者胜出）
• 源码中调度方法：RegisterAlgorithmProvider(name string,predicateKeys,priorityKeys util.StringSet)，参数分别为（算法名、预选策略集合、优选策略集合）
• 预选策略：1.NoDiskConflict，判断备选Pod的gcePersistenetDisk或AWSElasticBlockStore和备选节点中已存在的Pod是否存在冲突；2.PodFitsResources，判断备选节点的资源是否满足备选Pod的需求（计算备选Pod和节点中已存在Pod 的所有容器的需求资源内存+CPU的综合、获得备选节点的资源信息、比较资源是否满足需求）；3.PodSelectorMatches，判断备选节点是否包含备选Pod的标签选择器指定的标签；4.PodFitsHost，判断备选Pod的spec.nodeName所指定的节点名称和备选节点的名称是否一致；5.cheakNodeLabelPresence，判断策略列举出的标签在备选节点中存在时，是否选择该备选节点；6.CheckServiceAffinity，判断备选节点是否包含策略指定的标签，或包含和备选Pod在相同Service和Namespace下的Pod所在节点的标签列表；7.PodFitsPorts，判断备选Pod所用的端口列表中的端口是否在备选节点已被占用。
• 优选策略：1.LeastRequestedPriority：用于从备选节点列表中选出资源消耗最小的节点（计算出所有备选节点运行的Pod 和备选Pod 的CPU和内存占用量，计算每个节点的得分((节点CPU能力-需求CPU能力)*10/节点CPU能力 + (节点内存能力-需求内存能力)*10/节点内存能力)/2）；2.CalculateNodeLabelPriority，判断策略列出的标签在备选节点中存在时，是否选择该备选节点；3.BalancedResourceAllocation，用于从备选节点列表中选出各项资源使用率最均衡的节点（计算所有备选节点运行的Pod 和备选Pod 的CPU和内存占用量，计算每个几点的得分10 - abs(需求CPU能力/节点CPU能力-需求内存能力/节点内存能力)*10）。

kubelet运行原理

• 在API Server上注册节点自身信息，定期向Master汇报节点资源使用情况（默认10s），通过cAdvisor监控容器和管理资源。
• kubelet通过文件（默认检查时间间隔20s）、HTTP端点（检查该HTTP端点数据的时间间隔默认20s）、API Server（通过API Server监听etcd目录，同步Pod列表）获取自身Node上所要运行的Pod的清单。
• kubelet读取监听到的信息为创建和修改Pod任务，流程为：为Pod创建一个数据目录、从API Server读取Pod清单、为Pod挂载存储卷、下载Pod用到的Secret、用kubernetes/pause镜像为每个Pod创建一个容器，用于接管Pod中所有其他容器的网络、为Pod中每个容器做处理（给每个容器计算一个hash值并查询对应Docker容器的hash值进行比较、如果容器被终止则查询是否有重启策略、调用Docker Client下载容器镜像并运行）
• 使用两类探针进行容器健康检查：LivenessProbe（判断容器是否健康，不健康false则删除容器）、ReadinessProbe（判断容器是否启动完成，如果失败则修改Pod状态，Endpoint Controller从Service的Endpoint中删除包含该容器所在的Pod的IP地址的Endpoint条目）
• LivenessProbe的实现方式：ExecAction（内部执行一个命令，如果退出状态码为0则代表健康）、TCPSocketAction（通过容器的IP地址和端口号执行TCP检查）、HTTPGetAction（通过容器的IP地址和端口号及路径调用HTTPGet方法）

kube-proxy运行原理

• kube-proxy在运行过程中动态创建与Service相关的Iptables规则，这些规则实现了Cluster IP及NodePort的请求流量重定向到kube-proxy进程上对应服务的代理端口的功能。
• 目前kube-proxy只支持Round Robin算法，按照成员列表逐个选取成员循环往复，负载均衡器支持Session保持（本地内存中查找是否存在来自该请求IP的affinityState对象）。
• 内部创建一个负载均衡器，保存了Service到对应的后端Endpoint列表的动态转发路由表，具体的路由选择取决于Pound Pobin负载均衡算法及Service的Session会话保持。
• 针对发生变化的Service列表，kube-proxy逐个处理（获取Service的所有端口定义列表、逐个读取服务端口定义列表中的端口信息，根据（端口名称、Service名称、Namespace）判断本地是否已经存在对应的服务代理对象，不存在则新建，存在则先删除再新建、更新负载均衡器组件中对应的Service转发地址列表、清理已删除的Service），针对Endpoint的变化，kube-proxy自动更新负载均衡器中对应的Service的转发地址列表。

kube-apiserver

• 位于cmd目录下的kube-apiserver目录下。
• 最新版代码进程启动流程：新建APIServer命令对象（继承自cobra.Command对象）、设置command对象并设置选项和验证选项来运行指定的APIserver、创建通过委托连接的APIServer并不断回调调用（不会退出）、开始创建server链、创建拨号程序结构连接到各个节点（获取ssh密钥分发功能、代理到Pod和Service是基于IP的，使用nodeTunneler拨号程序、获取代理运输对象（由HTTPS TLS协议继承））、创建运行API服务器的所有资源（网络连接等各种配置信息）、判断是否创建了其他的API服务器、建立一个可行的kube-apiserver、聚合器（通过将API、主服务器和APIServer基础结构绑定在一起实现APIserver）排在链的最后（配置文件创建、建立聚合器server）
• Run方法源码流程：调用vertifyClusterIPFlags方法，验证ClusterIP参数是否已设置及是否有效、验证etcd-servers参数设置、检验CloudProvider参数、根据KubeletConfig配置参数创建kubelet Client对象（HTTPKubelet Client实例）、创建一个restClient对象（完成Pod、RC、Service等对的CRUD操作）、创建用于访问etcd Server的客户端、建立（鉴权、授权、服务许可框架和插件）相关代码逻辑、安装本机SSH Key到集群各主机、用APIServer的数据以及创建的一些对象为参数构造Master的Config结构、创建Master实例创建HTTPS server监听客户端请求。
• server进程一直运行，创建一个HTTPS server，等待请求的建立。
• Master对象包含了一个HTTP Rest服务器（一组Rest服务和一个HTTP多分器mux），在Master构造方法中被初始化，Master结构体中storage为一个以Rest API path为Key、rest.Storage接口为value的map，每个服务接口负责处理一类资源数据（New方法返回该Storage服务所能识别和管理的某种具体的资源数据的一个空实例）
• registry包按照rest.Storage内定义的资源类型划分为不同的子包，实现不同 Rest服务，实现相关的CRUD的操作

kube-scheduler

• 创建一个SchedulerServer对象，将命令行参数传入进入Run方法、创建一个Rest Client对象用于访问API Server提供的API服务、创建一个HTTPS server提供性能分析和性能指标度量的Rest服务、构造ConfigFactory（PodQueue 需要调度的Pod队列、BindPodsRateLimiter 调度过程中限制Pod绑定速度的限速器、modeler 优化调度过程、PodLister 拉取已被调度过以及被假定调度过的Pod列表、NodeLister 拉取Node节点列表、ServiceLister 拉取服务列表、schedulerPodLister和schedulerPodPopulator 定期从API Server上拉取已经调度好的Pod列表并将这些Pod从modeler的假定调度过的队列中删除）、调用createConfig方法创建Config对象、创建一个Pod相关的Reflector对象并定期执行负责查询并监测等待调度的Pod列表放入PodQueue等待调度、启动Controller负责定期从APIServer拉取已经调度好的Pod列表并将这些Pod从modeler的假定调度过的队列中删除、创建Node相关的Reflector对象定期执行负责查询并监测可用的Node列表、创建Service相关的Reflector对象定期执行负责查询并监测已定义的Service列表、创建实现scheduleAlgorithm接口的对象负责完成Pod 到Node的具体调度工作。
• scheduler的Run方法不停执行scheduleOne方法，获取下一个待调度的Pod进行调度。
• Modeler优化原理：Rest Watch API存在延时（已经调度好的Pod未被通知给scheduler），为每个刚刚调度好的Pod安排到Assumed队列，将Assumed队列与Watch缓存队列合并。
• 引入ratelimit组件解决Pod调度的流控问题，使用令牌桶流控算法进行控制。

Kubernetes源码理解

kubectl流程实现

create调用实现

• main方法中创建了kubectl命令的默认参数、进行日志的初始化和退出；
• 传入参数与子命令通过match方法截取标准输入的命令作截取形成参数；
• NewCommand创建主命令、Run运行前初始化性能评估，运行后将性能评估进行保存；
• 变量groups描述子命令的分类包括初级（create、expose、run、set）、中级（explain、get、edit、delete）、部署（rollout、scale、autoscale）、集群管理（cerfificate、cluster-info、top、cordon、drain、taint）、故障排查和调试（describe、logs、attach、exec、port-forward、proxy、cp、auth）、高级（diff、apply、patch、replace、wait、convert、kustomize）、设置相关（label、annotate、completion）；
• runCreate方法，*f为传入的与kube-apiserver交互的客户端，建立builder构建相关参数，最后形成result作为创建结果，并显示在cmd窗口；
• 输入文件参数：标准输入流输入、Http或Https网络文件输入、本机文件输入。

设计模式中Visitor的实现

• 访问者模式：解耦操作与对象本身，允许一个或多个操作应用到对象上，表面某个对象执行了一个方法，对象内部则调用了多个方法并统一返回结果；
• 链式对象处理：VisitorList（封装多个Visitor为一个，出现错误则立即返回error）、EagerVisitorList（封装多个Visitor为一个，出现错误暂存遍历完成后聚合全部错误并返回）；
• 链式方法处理：DecoratedVisitor（使用装饰器模式，将一个Visitor调用多个visitorFunc方法封装为调用一个，有error直接返回）、ContinueOnErrorVisitor（暂存error，聚合返回）；
• 链式抽象多个底层对象处理，逐个调用方法：FilteredVisitor、FlattenListVisitor（对Kubernetes内部对象进行抽象）；
• Visitor各类实现：SteamVisitor（网络流、文件流、输入流等）、FileVisitor（文件对访问，底层使用StreamVisitor）、URLVisitor（HTTP GET方法，底层为复用的SteamVisitor）、KustomizeVisitor（针对自定义文件系统）。

发送创建Pod请求对实现细节

• 采用REST风格交互，传入REST client与资源对象Object交互，资源对象Object通过对读入yaml文件的解析；
• gvk解析：g（group组）、v（version版本）、k（kind资源种类）；
• 命令行采用了cobra库、调用逻辑（cobra匹配子命令、Visitor模式构建Buider、RESTClient将Object发送到kube-apiserver）。

kube-apiserver流程实现

权限相关的核心概念（Authentication认证、Authorization授权、Admission准入机制）

• kube-apiserver是一个常驻的服务器进程监听端口，使用stopCh的channel，实现程序的循环运行，命令行工具也使用cobra；
• createServerChain创建server链路：创建配置文件进而构建server的形式（APIExtension server扩展服务CRD、KubeAPI server API核心服务、Aggregator server API聚合服务）；
• 不同的config基于通用的GenericConfig，加上扩展的ExtraConfig（自身的特性）组成，GenericConfig；
• 认证相关：使用request与token切片做工具，添加header、CA、tokenfile、token添加（service account、bootstrap、oidc、webhook）、组合认证模块；
• 授权相关：确定授权的模式（ABAC、RBAC、Webhook、Always模式、Node），并进入其方法初始化；
• 准入机制：权限相关、以插件形式存在，NewFromPlugins方法进行引入，初始化插件、获取插件、加入注册表；
• 三个权限在config中进行注册并初始化。

GenericAPIServer的初始化

• GenericConfig.New方法传入类型为string的server类型用以初始化，初始化流程（新建Handler处理网络请求（newAPIServerHandler方法，采用emicklei_go-restful的库作为接口设计）、实例化一个Serve、处理钩子hook操作（使容器感知生命周期的事件，在相应对生命周期钩子被调用时运行指定代码，容器创建后PostStart、终止前PostStop，钩子失败容器会被kill））、健康检测（HealthzChecks方法）、安装API相关参数（添加_/index.html路由规则、添加golang pprof的路由规则用于性能分析、添加metrics用于监控指标、添加version用于版本管理、开启服务发现））；
• Apiserver，实例化genericserver、实例化核心KubeAPIserver、注册LegacyAPI（核心资源）、定义REST接口的存储定义、注册API、添加hook；
• InstallLegacyApi：创建restful的存储（使用资源模版的初始化）、初始化配置文件、添加hook、注册LegacyAPIGroup；

Pod数据的保存

• 工厂模式factory返回指定类型的存储（etcd2、ETCD3）；
• 在完成验证后，请求会根据路由规则，触发到对应资源的handler，主要包括数据的预处理和保存；
• kube-apiserver底层存储为etcd v3，被抽象为一种RESTStorage，使得请求和存储操作一一对应。

kube-scheduler调度流程

调度启动流程与算法

• 类似于kube-apiserver，是个常驻进程，命令行使用cobra根据入参返回配置与调度对象sched，然后Run方法运行；
• Run运行调度策略：将配置注册到configz中，会保存在一个全局的map中，开启事件广播广播管理器，涉及到Event事件，开启健康检测的服务切片，goroutine异步执行Informer，如果多个master节点则开启选举机制，选举一个作为leader（设置回调，回调中开启两个钩子hook函数，开启leading时运行调度，结束时打印报错），如果选举成功则持续通信，不参与选举则单节点运行；
• scheduler核心作用为进行调度，涉及到多种调度策略，Informer（kubernetes中的各种类型的资源，包括自定义的资源类型），Informer的实现将调度和资源结合起来；
• 调度器将各种调度算法抽象为一个插件工厂，根据不同选择构建配置文件。

Informer监听资源变化

• 核心功能是获取并监听对应资源的增删改，触发相应的事件操作；
• 工作流程：Reflector中ListAndWatch方法、增删改操作进入Delta队列（FIFO）、queueActionLocked（队列激活与加锁）、Controller进行Pop队列中操作、根据相应命名空间或资源名称选的事件执行，同时将操作对象存储入本地Indexer、将加入工作队列、Handler取到对应对象进行工作；
• 用锁和channel stopCh来保证informer运行并不被重复运行，InformerFor方法通过传入的资源对象，如果找到则直接发返回，为找到则使用传入的newFunc实例化后再返回；
• Informer依赖于reflector模块组件为XXX（pod等）informer，具体资源的Informer包含了一个链接到kube-apiserver到client，通过list和watch接口查询资源变更情况，检测到资源发生变化则通过controller将数据放入队列，完成生产阶段。

Informer保存数据

• indexer，并发数据安全的线程，将数据在本地做一个持久化；
• 消费者不断处理资源变化的事件，将数据存储在本地indexer中，底层是一个并发安全的threadSafeMap，有些组件需要事实关注资源变化，实时监听listen，将事件分发到对应注册来的listener上自行处理。

分配Pod 的大致流程

• Scheduler对象底层实现：调度缓存、调度算法、配置文件、error集合、调度队列、NextPod（优先级Pod队列为参数的顺序）、StopEverything；
• Pod调度通过一个队列SchedulingQueue异步工作的，监听到对应Pod 事件后放入队列、有消费者从队列中获取Pod，进行调度；

• 单个Pod调度步骤：根据Predict和Priority两个阶段，调用各自的算法插件，选择最优的Node、Assume这个Pod被调度到对应的Node，保存到cache、用extender和plugins进行验证，通过则绑定，绑定成功后通过client通知kube- apiserver，更新etcd。

kube-controller-manager

• 资源列表中选择对应创建的资源，异步初始化资源，监听kube-apiserver的资源接口，并选择合适的资源进行整合；
• 根据期望状态和当前状态，管理Kubernetes中的资源，以RS为例，对比了定义声明的Pod数和当前集群中满足条件的Pod数，进行相对应的扩缩容。

kubelet

• Node创建client监听kube-apiserver资源，对Pod进行监听和同步处理，对容器进行管理；
• 是kubernetes上Node节点的管理者，接受来自kube-apiserver上的Pod消息，用Ticker（同步时间过快会对性能有影响）周期性的方式触发同步函数，异步地对容器进行管理，调用对应容器的接口（用插件方式进行管理）。