Kubernetes控制器进化之旅

前言

• k8s的声明式api主要是通过各种控制器的调谐循环（Reconcile）实现
• 调谐循环获取集群的当前状态和用户期望状态
• 通过调整实际状态，不断逼近期望状态
• 本文内容来源于 Kubernetes控制器进化之旅：从资源控制到开放应用模型
• 因文字讲述通俗易懂，看后深受启发，特将文字内容以图片形式展示

第一阶段：控制器直接访问api-server

• 过多的请求，导致api-server压力过大

第二阶段：控制器通过informer访问api-server

• informer提供的List And Watch机制，增量的请求api-server
• wath时，只watch特定的资源

第三阶段：多个控制器共享informer访问api-server

• 受多个控制器管理的资源对象，共享Informer，进一步提高效率。比如：Deployment和DaemonSet两个控制器都管理pod资源
• DeltaFIFO队列用于处理事件通知，并更新本地缓存
• WorkQueue队列用于通知各个控制器处理事件

第四阶段：自定义控制器+自定义资源访问api-server

• crd和crd controller用于自定义业务逻辑
• operator模式提供了一套简易的编程框架，快速实现自定义控制器
• 现在常用的operator框架有：
  • kubebuilder
  • operator-sdk

第五阶段：Open Application Model(OAM)

• OAM是由阿里、微软牵头搞的一套规范
• 目的是将开发、运维的职责解耦，各司其职