Joohwan

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中 将资源对象的Key加入 ...

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驱逐抢占机制当调度器无法为高优先级的Pod找 ...

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(启动流程) 基于1.25 Cobra命令参数解析 Ref:https://github.com/kubernetes/kubernetes/blob/810e9e212ec5372d16b655f57b9231d8654a2179/cmd/kube-scheduler/app/server.go#L80 // NewSchedulerCommand creates a *cobra.Command object with default parameters and registryOptionsfunc NewSchedulerCommand(registryOptions ...Option) *cobra.Command { // explicitly register (if not already registered) the kube effective version and feature gate in DefaultComponentGlobalsRegistry, // which will be used in Ne ...

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实现原理) 基于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中数据传输的一种机制，允许吧服务端发送给客户端的数据分为多个部分，分批次发送 # 验证支持HTTP/1.1 Chunkedcurl -ik --http1.1 \--cert /etc/kubernetes/pki/apiserver-kubelet- ...

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 // NewAPIServerCommand creates a *cobra.Command object with default parametersfunc NewAPIServerCommand() *cobra.Command { s := options.NewServerRun ...

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(授权) 基于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/ba592 ...

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按照顺序检查用户身份，第一个匹配结果作为用户名，必选 --requ ...