前言在网上搜 Informer 的时候，会经常能刷到下面这张图。这张图分为上下两部分，上半部分是 client-go 中 Informer 相关的实现，下半部分是常见 Controller 相关的实现方式。接下去，我们会用两篇的篇幅来分别进行介绍。基础概念API Server 在 Kubernete

前言针对下面这张图，上半部分是 client-go 中 Informer 相关的实现，下半部分是常见 Controller 相关的实现方式。本篇主要介绍下半部分常见 Controller 的实现，以及常用 Controller 框架的使用。Controller 实现在使用 Informer 的时候，

概述client-go package 的源码结构如下所示，$ tree -L 2 client-goclient-go├── discovery# 提供 DiscoveryClient 类型的客户端。├── dynamic # 提供 DynamicClient 类型的客户端。├── inform

整体概述API Server 的 Watch 机制主要依赖 etcd 的 Watch 机制，整体如下：API Server 针对每种资源都会在本地维护一个 cacher，通过 etcd 提供的 watch 机制实时更新该 cacher 的内容。客户端针对资源的访问请求，都会优先访问该 cacher。

整体流程优雅删除 Pod 时，整体流程如下，这里考虑 APIServer 和 kubelet 两个环节：客户端请求删除 Pod，此次请求删除 GracePeriodSeconds 往往会采用默认值 30s。APIServer 收到此次请求，更新 Pod 的信息，设置 Pod 的 DeletionTi

基础驱逐的方式驱逐 Pod 的方式，主要有 2 大类：基于驱逐 API 主动发起的驱逐行为。kubelet 基于节点压力（kubelet 会不断检查节点资源，比如内存、CPU、磁盘），主动发起的驱逐行为，又分为两种硬驱逐。硬驱逐策略定义了节点上资源消耗的绝对限制。一旦实际使用量超过了这些限制，Kub

基础整体 Pod 创建的核心流程如下，这里只考虑在 kubelet 中的情况。kubelet 收到 Pod 被创建的事件，syncLoop 中按照创建逻辑添加该 Pod。将 Pod 加入 podManager。podManager 子模块负责管理这台机器上的 pod 信息，如果 podManager

基础在客户端发起 exec 请求之后，比如 kubectl exec -it 之后，APIServer 向 pod 所在的 kubelet 发送 Exec 请求。kubelet 向 CRI shim 发送 Exec 请求，请求 Exec 的 URL。CRI shim 给 kubelet 返回 Exe

Kube-Scheduler 的作用是将 Pod 调度到最优的节点上（给 Pod 选择一个最合适的 Node），从而更加合理、更加充分的利用集群的资源基本调度流程整个调度的基本流程如下，Pod 被提交到 API Server，存储到 Etcd 中。调度器会 List&Watch Pod，将

接下去我们简单来看下一个 CSI Plugin 开源项目的实现，github 地址是：https://github.com/alibaba/open-object。这个 CSI Plugin 实现了将 Minio 作为后端存储。以这个项目为例子，主要的考虑是：（1）它的实现不复杂，整体上的代码量就