controller调用另一个controller_关于deployment的controller执行流程

k8s的几个组件 命令行参数解析到执行这部分都是基于cobra模块, cobra的用法不是本文的重点, 后续有空会单独说一下

随着每次有新的理解 会随时更新此文. 刚开始没什么干货, 只是会粘贴流程

本文仅作为一个开始阅读K8S源码并尝试修改的开头, 只会大致整理 controller-manager 组件的deployment-controller的工作流程. 为后续修改及rbd的controller编写做知识储备

注册 (仅字面意思)

在启动contoller-manager以后 cobra 调用 cmd/kube-controller-manager/app/apps中的Run 函数

Run在经过一系列初始化之后会执行下图中的代码

NewControllerInitializer返回一个map, value为各种自带的controller, 其中包括depcontroller

文中的参数 ctx 也是在Run() 中定义

ctx.ComponentConfig.DeploymentController.ConcurrentDeploymentSyncs  通过 controller-manager的启动参数控制

--concurrent-deployment-syncs int32  默认值为5

意义为允许同时同步deployment的数量  

dc.Run中 通过这个参数来控制启动的goroutine数量

每个Until里面都是一个死循环, 通过 stopCh 来结束, 每次循环都是一次deploy的check工作 (dc.worker)  (待修正  这段代码没太看清, 得理一下是在哪一段做死循环)

在dc的初始化中有一个关于deployment 的 queue, 是一个通过通过BuketRateLimiter 实现的限速队列

队列中 key的形式是 NS/deploy的形式 NS可以为空值

在每次worke工作中都会从queue中取值

通过日志也可以看到 同步 队列的日志

上图为worker的实现, 其中 syscHandler为关键工作内容 与Informer相关, handleErr 处理异常代码 主要是 对失败的deploy队列时间重新放回队列还是 丢弃 (Forget  是否是丢弃还是放到另一个队列 得确认) 

如果像公司这种情况, 如果不希望某些deploy放到其他ns中, 如果没在apiserver 放入队列的地方做拦截的话这块倒是也可以做拦截

dc主要涉及 deployInformer, rsInformer, pod.Informer

deployInformer 负责 dc deploy的 add/update/delete

rsInformer 负责 rs的 dc的 add/update/delete

pod.Informer 负责 dc的deletepod

Informer 是一个Interface 主要实现 Informer() 和 Lister()