Joohwan

Kube-controller-manager(ReplicaSet) 基于1.25 ReplicaSet控制器是ReplicaSet资源对象的控制器，通过Informer资源监听ReplicaSet和Pod对象，监听到Add、Update、Delete时，ReplicaSet控制器会对ReplicaSet资源对象进行Reconcile ReplicaSet资源对象主要包含Pod模版（Spec.Template)和副本数（Spec.Replicas) 控制器初始化ReplicaSet控制器初始化的时候，会创建工作队列以存储ReplicaSet资源对象的Key。 ReplicaSet资源对象：监听Add、Update、Delete事件，把监听到的ReplicaSet资源对象的Key加入到工作队列，等待Worker协程消费 Pod资源对象：监听Add、Update、Delete事件，把监听到的Pod资源对象的Key加入到工作队列，等待Worker协程消费 Pod资源对象的OwnerReference记录了父级资源的引用 当触发了Pod的Add或Delete事件，通过OwnerRe...

Kube-controller-manager(启动流程) 基于1.25 kube-controller-manger的启动流程主要分： Cobra命令行参数解析 运行EventBroadcaster事件处理器 运行HTTPS服务 执行Leader选举 启动控制器主循环 Cobra命令行参数解析 Ref:https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/cmd/kube-controller-manager/app/controllermanager.go#L100 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465// NewControllerManagerCommand creates a *cobra.Command object with defaul...

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(优先级和抢占式调度) 基于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&调度器运行流程) 基于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 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) 基于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中数据传输的一种机制，允许吧服务端发送给客户端的数据分为多个部分，分批次发送 12345# 验证支持HTTP/1.1 Chunkedcurl -ik --http1.1 \--cert /etc/kubernetes/pki/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(准入控制器) 基于1.25 准入控制器会通过在请求经过认证、授权等前置检查后，对象被真正持久化前行最后的拦截，对请求的资源对象进行存储前的变更或验证 准入控制器以插件的形式，支持有命令行参数动态启用(–enable-adminssion-plugins)或禁用(–disable-adminssion-pkugins)指定准入控制器插件 内置插件介绍 名称 说明 AlwaysAdmit 已弃用，允许所有的请求 NamespaceAutoProvsion 检查所有进入的具备命名空间的资源请求，如果引用的命令空间不存在，则自动创建命名空间 NamespaceLifecycle 禁止在一个正在被终止的空间中创建新对象，确保对不存在的命名空间的请求被拒绝。在删除一个命名空间时，触发删除该命名空间下的所有对象（如Pod、Service等）的操作。同时，禁止删除系统保留的命令空间（default、kube-system、kube-public） NamespaceExists 检查所有进入的具备命名空间的资源请求，如果其引用的命...