Kube-controller-manager(OverView)
Kube-controller-manager(OverView) 基于1.25 什么是kube-controller-managerK8s Controller Manager 主要由kube-controller-manager和cloud-controller-manager组件组成。它们通过监控集群中资源对象的变化,确保资源对象从当前状态到期望状态 控制器状态模型K8s使用资源清单(mainfest),控制器通过Reconcile调谐机子把资源对象的实际状态更新为期望状态 Spec:记录期望状态 Status:实际状态 控制器执行原理kube-controller-manager运行了多个控制器。控制器通过Informer机制监听资源对象的Add、Update、Delete事件 Watch资源对象的Add、Update、Delete事件并且缓存资源对象 控制器通过K8s的Informer、Watch机制,监听集群中资源对象的Add、Update、Delete事件,为不同的事件注册不同的回调函数,并且将监听的资源缓存对象在Informer中 将资源对象的Ke...
Kube-scheduler(优先级和抢占式调度)
Kube-scheduler(优先级和抢占式调度) 基于1.25 K8s支持Pod优先级设置 抢占:把优先级低的Pod驱逐,高优先级的Pod先运行 Pod优先级pod优先级通过spec.priority字段定义,该字段为int32整数指针,数字越大,标识Pod优先级等级越大 通过PriorityClass可以为某个优先级定一个名称 通过spec.prioityClassName就可以自动载入优先级 K8s默认提供了俩种PriorityClass: system-cluster-critial:优先级2000000000 system-node-critial:优先级2000001000 PriorityClass主要注意把某个globalDefault设置为true,那么没有指定的都会使用这个 一个集群只有一个globalDefault可以设置为true 允许被设置为PreemptLowerPrioity或者Never,设置为Never,该PrioityClass的Pod无法被调度,也不会被触发对低优先级低Pod驱逐 Pod驱逐抢占机制当调度器无法为高优先级的P...
Kube-scheduler(SchedulingFramework&调度器运行流程)
Kube-scheduler(SchedulingFramework&调度器运行流程) 基于1.25 SchedulingFramework是调度器中一个核心概念,支持Pod调度过程中定义为一系列的拓展点 SchedulingFramework背景K8s不断强大, 调度日渐复杂,以前版本支持了Webhook Extender拓展原生调度但是存在以下的限制 拓展点数量和调用位置限制 Filter Extender只能在内置的预选算法结束之后才能调用 Preempt Extender只能在内置驱逐算法完成之后才被调用 Bind Extender只能用于Pod绑定节点,同一时刻只能使用一个Bind Exender,启用了Webhook的Bind插件,内置的Bind不再使用 网络调用降低调度器性能 每次调用Webhook都会产生HTTP请求响应过程,有多次数据的JSON序列化和反序列化 难以通知外部的Extender内部的调度已经被终止 外部的Extender难以和内置的调度器恭喜那个缓存 基于以上问题,设计了SchedulingFramework,插件化的架构模式...
Kube-scheduler(启动流程)
Kube-scheduler(启动流程) 基于1.25 Cobra命令参数解析 Ref:https://github.com/kubernetes/kubernetes/blob/810e9e212ec5372d16b655f57b9231d8654a2179/cmd/kube-scheduler/app/server.go#L80 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152// NewSchedulerCommand creates a *cobra.Command object with default parameters and registryOptionsfunc NewSchedulerCommand(registryOptions ...Option) *cobra.Command { // explicitly register (if not already registered) the kube ...
Kube-scheduler(OverView)
Kube-scheduler(OverView) 基于1.25 Kube-schedule是K8s的控制平面组件之一,负责调度整个集群的Pod kube-scheduler调度模型kube-schedule的调度过程主要可以分为两个周期、三个阶段 两个周期主要是调度周期和绑定周期 三个阶段主要是预选(Filter)、优选(score)、绑定(Bind)三个阶段 kube-schedule在调度周期使用出串行策略,每次调度一个Pod 在绑定周期,使用并行策略 kube-scheduler调度Pod有俩种最优解: 全局最优解:执行调度策略会遍历所有的节点,找出全局最优节点 局部最优解,执行调度策略只遍历部分你节点,找出部分最优解 kube-schduler通过自动调度方法执行调度最优解,默认节点小于等于100,寻找最优解 kube-scheduler内部架构主要包含Informer、Scheduling Quque,Cache以及Scheduling Framework组件 Scheduling Queue主要是用于缓存待调度的Pod,以便在调度的时候高效获取...
K8s-kube-apiserver(List-Watch实现原理)
K8s-kube-apiserver(List-Watch实现原理) 基于1.25 List-Watch是K8s的核心机制,基于List-Watch实现了资源变化的感知 List调用ListAPI列出所有资源,基于HTTP短链实现 Watch调用WatchAPI监听资源变更事件,基于HTTP长连接事件 长连接通信协议支持Watch操作碧玺实现客户端和服务端的长连接。 kube-apiserver的Watch支持3种类型的长连接 HTTP/1.1 Chunked Transfer Encoding HTTP/2 WebSocket HTTP/1.1 Chunked Transfer EncodingHTTP/1.1 Chunked Transfer Encoding(分块传输编码)是HTTP中数据传输的一种机制,允许吧服务端发送给客户端的数据分为多个部分,分批次发送 12345# 验证支持HTTP/1.1 Chunkedcurl -ik --http1.1 \--cert /etc/kubernetes/pki/apiserver-...
K8s-kube-apiserver(信号处理机制)
K8s-kube-apiserver(信号处理机制) 基于1.25 K8s基于UNIX信号实现常驻进程以及进程的优雅退出 例如,当kube-apiserver进程接收到SIGTERM或SIGINT信号时,先通知kube-apiserver内部的Gouroutine协程优先退出,再退出主线程退出 例如,Prometheus基于监听SIGHUP信号,实现热加载配置文件 常驻进程实现Kube-apiserver的实现如下,其他类似: Ref:https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/cmd/kube-apiserver/app/server.go#L93 123456789101112131415161718192021222324252627282930313233343536373839404142// NewAPIServerCommand creates a *cobra.Command object with default parame...
K8s-kube-apiserver(准入控制器)
K8s-kube-apiserver(准入控制器) 基于1.25 准入控制器会通过在请求经过认证、授权等前置检查后,对象被真正持久化前行最后的拦截,对请求的资源对象进行存储前的变更或验证 准入控制器以插件的形式,支持有命令行参数动态启用(–enable-adminssion-plugins)或禁用(–disable-adminssion-pkugins)指定准入控制器插件 内置插件介绍 名称 说明 AlwaysAdmit 已弃用,允许所有的请求 NamespaceAutoProvsion 检查所有进入的具备命名空间的资源请求,如果引用的命令空间不存在,则自动创建命名空间 NamespaceLifecycle 禁止在一个正在被终止的空间中创建新对象,确保对不存在的命名空间的请求被拒绝。在删除一个命名空间时,触发删除该命名空间下的所有对象(如Pod、Service等)的操作。同时,禁止删除系统保留的命令空间(default、kube-system、kube-public) NamespaceExists 检查所有进入的具备命名空间的资源请求,如果其引用的命...
K8s-kube-apiserver(授权)
K8s-kube-apiserver(授权) 基于1.25 kube-apiserver的授权客户端请求通过认证之后,进入授权阶段,校验对应用户是否具有对应数据读写的权限 支持多种授权机制,并且支持开启多个授权功能 如果开启多个授权,按照授权顺序执行 只要有一个授权器通过,授权就成功 目前支持六种授权模式: AlwaysAllow:允许所有请求 AlwaysDeny:阻止所有请求 ABAC:基于属性的访问控制 Webhook:基于Webhook的一种HTTP回调,远程授权管理 RBAC:基于角色的访问控制 Node:节点模式,专门授权kubelet发出的API请求 集群默认开启Node和RBAC模式 在kube-apiserver中,Authorization授权有三个概念,分别是Decision决策状态、授权器接口和Rule Resolver规则解析器 Decision决策状态 Decision决策状态类似于身份认证中的true和false,用来表示授权是否成功 Ref:https://github.com/kubernetes/apiserver/blob/ba...
K8s-kube-apiserver(请求与认证)
K8s-kube-apiserver(请求与认证) 基于1.25 kube-apiserver请求处理流程: 权限控制体系 认证kube-apiserver支持多种认证机制,并且支持同时开启多个认证功能,组成认证链路 目前支持8种: RequestHeader ClientCA TokenAuth ServiceAccountAuht BootstrrapToken OIDC WebHookTokenAuth Anonymous RequestHeader认证kubeapiserver通过制定以下参数开启RequestHeader认证 --requestheader-client-ca-file制定认证代理客户端证书签发所使用的CA证书,必选 --requestheader-allowed-names:指定允许的通用名称(CN)列表。如果设置则客户端中列表中,不然任选 --requestheader-username-headers:指定HTTP Header中用于设置用户名的字段名称列表,API Server按照顺序检查用户身份,第一个匹配结果作为用户名,必选 --r...

