Joohwan

Kube-controller-manager(Job) 基于1.25 Job Controller是job的控制器 Job Controller会根据Job的并发（Spec.Parallelism)和完成（Spec.Completions)字段，此间一个或者多个Pod。在指定数量（Spec.Completions)的Pod执行成功之后，宣告Job成功，Job默认采用Orphan删除策略，删除Job不会主动删除其关联的Pod 控制器初始化 Job资源 Pod资源 主要执行逻辑 jm.jobLister.Jobs 获取Job资源对象 IsJobFinished 判断Job是否已经执行完成。 Job Controller检查Job.Status.Conditions状态，如果存在Complete或Failed类型的状态且值为true，则Job已经执行完成 Ref:https://github.com/kubernetes/kubernetes/blob/1504f10e7946f95a8b1da35e28e4c7453ff62775/pkg/controller/job/u...

Kube-controller-manager(StatefulSet) 基于1.25 StatefulSet Controller控制器主要控制StatefulSet资源 StatefulSet资源主要包含Pod模版、副本数量（Spec.Replicas)、更新策略、管理策略等部分 StatefulSet在每个关联的Pod的Name会添加一个序号后缀 创建、删除Pod按照固定的顺序操作 当Pod超出期望的副本数量，或以执行滚动更新策略更新，控制器顺序按顺序从高到低依次删除Pod；反之，如果Pod数量低于期望副本数量，控制器低序号到高序号删除Pod 控制器初始化 StatefulSet资源对象：监听Add、Uodtaed、Delete事件 Pod资源对象 主要执行逻辑 ssc.setLister.StatefulSets 获取完整的STS对象 ssc.getPodsForStatefulSet 获取关联的Pod syncStatefulSet 调谐StatefulSet。调用syncStatefulSet func实现STS调谐。内部主要调用...

Kube-controller-manager(DaemonSet) 基于1.25 DaemonSet Controller控制DaemonSet对象 DaemonSet资源对象选中的节点，最终仅仅有一个Pod处于可用 DaemonSet资源对象主要包含Pod模版、更新策略俩部分 控制器初始化 DaemonSet资源对象：监听Add、Update、Delete事件 Pod资源对象 Node资源对象 ControllerRevison资源对象：处理ControllerRevison资源对象同步，记录DS的Pod模版历史重现过的版本 主要执行逻辑 dsc.dsListener.DaemonSets 获取DS资源对象，DS Controller通过DS Informer的Lister获取完整的DS资源对象 dsc.nodeLister.List 获取集群的所有Node资源对象 ds.DeletionTimestamp !=nil 判断资源对象是否处于删除中。如果处于删除中行，不需要进行Reconcile dsc.expections.SatisfiedExpe...

Kube-controller-manager(Deployment) 基于1.25 Deployment控制器主要控制Deployment资源。 Deploymen控制器依旧更新策略调整RS资源 控制器初始化Deployment控制器初始化的时候，会创建工作队列存储Deployment资源对象的Key Deployment资源对象：监听Add、Update、Delete事件，把监听到的RS资源对象的Key加入到工作队列中，等待Worker协程消费处理 RS资源对象 Pod资源对象 主要执行逻辑 dc.Listener.Deployments 获取Deployment资源对象。通过Deployment Informer的Lister接口Get获取完整的Deployment资源对象 dc.getReconcileSetsForDeployment 获取管理的RS对象 d.DeletionTimestamp !=nil 判断是否执行Reconcile d.Spec.Paused 判断是否暂停版本更新。当处于Paused状态时，Deployment Cont...

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 ...