Appearance
kube 概念
Operator 框架：提供从 CRD 文件到 Operator 框架程序源码的自动生成工具，简化开发 Operator 的工作
kubeconfig 文件
kube-controller-manager 中运行了多个控制器
Kubernetes Watch API
client-go 的 Informer 框架（高性能、缓存）
InformerSynced
Informer
InformerFactory SharedInformerFactory
ResourceEventHandler 回调接口
Lister
Indexer
WorkQueue
reconcile 调谐
理解控制器的运行原理
控制器通过 Informer 机制监听资源对象的 Add、Update、Delete 事件，并且通过 Reconcile 调谐机制更新资源对象的状态
- 不同的控制器监听的资源对象不同：
- Deployment 控制器监听 Deployment、ReplicaSet、 Pod 资源对象
- Endpoint 控制器监听 Service、Endpoints、Pod 资源对象
将资源对象的 Key（namespace/name）加入工作队列
Worker 协程处理 Key 时，会通过 Lister（其实是 Indexer 的封装）来从 Informer 缓存中获取资源对象
有点像 biz/Lister -> store/Indexer
sh
SharedInformer
└── 缓存 Store（其实是一个 Indexer）
└── Indexer
└── 存放资源对象 + 支持索引查找
└── Lister
└── 封装了 Indexer，用于简化查询（支持 namespace + name 查询）- 不同的控制器有不同的调谐逻辑：
- ReplicaSet 控制器会创建或删除一些 Pod
- Endpoint 控制器会统计 与 Service 资源对象关联的 Pod 资源对象的 IP 地址和端口号等信息
在 Worker 协程完成调谐工作之后， 会重新计算资源对象当前的状态， 并且调用 kube-apiserver 完成对资源状态的更新
理解 kube-controller-manager 控制器的架构
理解 kube-controller-manager 的启动流程
Leader 选举
kube-controller-manager 在真正执行主逻辑之前，必须被选举为 Leader，否则会阻塞在选主阶段
在 Kubernetes 中 ， Leader 选举可以通过 leaderelection 工具库完成
Leader 选举机制
Kubernetes 中的许多控制器组件（如 kube-controller-manager、kube-scheduler 等）为了实 现高可用，都使用主备模式，并且使用 Leader 选举（Leader Election）机制来实现故障转移（Fail Over）
Leader 选举机制允许多个副本处于运行状态，但 其他副本处于待命状态并不断尝试获取锁，通过竞争成为领导者。一旦领导者无法继续工作， 其他竞争者就能立即竞争成为新的领导者
使用 Leader 选举机制实现主备模式
选举的租约锁对象 LeaseLock
事件管理机制
Kubernetes 的事件（Event）是一种资源对象，用于展示集群内发生的事件，Kubernetes 中的各个组件会将运行时发生的各种事件上报给 kube-apiserver
在默认情况下只会显示 最近 1 小时内发生的事件。（事件作为资源对象，存储在 kube-apiserver 的 etcd 中。为避免磁盘空间被填满，故强制执行保留策略：在最后一次事件发生后，删除 1 小时之前发生的事件。）
事件广播器（EventBroadcaster）和事件记录器（EventRecorder）
- 事件管理机制的运行原理
- EventRecorder
- EventBroadcaster
- broadcasterWatcher
- EventCorrelator
- EventSink
Informer 机制
Kubernetes 的其他组件都是通过 client-go 的 Informer 机制与 kube-apiserver 进行通信的
client-gen 代码生成器
ClientSet 只能访问 Kubernetes 内置资源（客户端集合内的资源），不能直接访问 CRD 资源。如果需要访问 CRD 资源，则可以通过 client-gen 代码生成器重新生成 ClientSet，在 ClientSet 集合中自动生成与 CRD 操作相关的接口。
协议
- HTTPS
- RPC
- TLS 证书/身份认证 密钥/加密传输
- mTLS
k8s 协议
- CSI
- CNI
- CRI
iptables、ipvs 和 ipset
它们的关系图：
iptables：我负责拦、放、转； ipset：我给 iptables 提速； ipvs：我来搞负载均衡。
相互关系：
| 工具 | 类型 | 跟 iptables 的关系 |
|---|---|---|
| iptables | 核心组件 | 主体、防火墙大哥 |
| ipset | 插件 | 被 iptables 调用，提高效率 |
| ipvs | 独立模块 | 不依赖 iptables，干自己的活（但都在内核搞包） |
现实应用场景举例（Kubernetes 相关）：
| 场景 | 用到谁 |
|---|---|
| Pod 间网络隔离、安全组 | iptables |
| K8s 的 Service（ClusterIP 模式）传统实现 | iptables |
| K8s 的 kube-proxy 使用 ipvs 模式时 | ipvs |
| 你要拉黑一批恶意 IP（不止一个） | ipset + iptables |
Kubernetes 中定义了 4 种类型的 Service，分别是 ClusterIP、NodePort、LoadBalancer 和 ExternalName。
client-go
- clientset
- Watch、Informer、Indexer、Lister、Workqueue
k8s.io/api k8s.io/apimachinery
- sample-controller
- controller-runtime + kubebuilder
- operator-sdk
code-generator 包括 client-gen + informer-gen + lister-gen 等
kubebuilder/controller-gen
EventBroadcaster 乐观锁 多副本选举功能 自定义资源 自定义 Controller controller-runtime Operator Controller
kubectl proxy curl http://localhost:8001/versionhttp://localhost:8001/api/v1/namespaces/default/pods/kubernetes-bootcamp-9bc58d867-b9vmc:8080/proxy/http://localhost:8001/api/v1/namespaces/default/pods/customer-v1-99b4d8bbf-qgkdc:8080/proxy/api/v1/customer
controller / reconciler
webhook
写 controller、operator、dynamic client
GVK 和 GVR
GroupVersionKind（资源类型）
GroupVersionResource（访问路径）
如何使用 kubebuilder 开发一个 自定义 controller
实战建议（送你一套学习路径） ✅ 先掌握 client-go 基础机制：informer、lister、workqueue（掌握 Controller 编程模型）
✅ 再学习 Kubebuilder 或 Operator SDK 来快速构建 Operator
✅ 最好做一个真实业务封装：比如写个 Redis Operator，支持高可用部署 + 自动重启 + 动态配置
Operator 和 Controller 的区别
Operator = CRD + Controller + “Reconcile loop” + 某种业务自动化
ServiceAccount K8s 的权限控制：声明式的 RBAC