Kubernetes控制器进化之旅

1,259 阅读1分钟

前言

  • 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是由阿里、微软牵头搞的一套规范
  • 目的是将开发、运维的职责解耦,各司其职