<aside> ⏰ PodConfig 对象生成

</aside>

PodConfig 定义

Kubelet 启动的时候传入了一个 podCfg.Updates() 参数，podCfg.Updates()方法只返回 PodConfig 对象的 updates channel。然后会将该更新通道传递到 syncLoop 模块去处理 pod 的更新变化。

// cmd/kubelet/app/server.go
func startKubelet(k kubelet.Bootstrap, podCfg *config.PodConfig, kubeCfg *kubeletconfiginternal.KubeletConfiguration, kubeDeps *kubelet.Dependencies, enableServer bool) {
	// start the kubelet
	go k.Run(podCfg.Updates())

	//......
}

// Run 启动 kubelet 以响应配置更新
// pkg/kubelet/kubelet.go
func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) {
	// ......
	kl.syncLoop(updates, kl)
}

这样我们就清楚了 syncLoop 模块属于更新通道的消费者，那么生产者呢？在什么地方产生的该通道？首先我们要先了解下 PodConfig 这个对象是如何定义的，代码位于：

kubernetes/config.go at v1.22.8 · kubernetes/kubernetes

如下所示：

PodConfig 将多个 pod 配置源合并到一个统一的元数据结构中，然后按顺序将增量变更通知到监听器。在初始化 PodConfig 的时候可以看到先创建了一个 updates 对象，这是缓存50个的通道，每个 PodUpdate 主要是存的相同来源(Source)下，相同操作(Op)下的 Pods 列表：

// pkg/kubelet/types/pod_update.go
type PodUpdate struct {
    Pods   []*v1.Pod
    Op     PodOperation
    Source string
}

另外 PodConfig 中还包含一个 podStorage 属性，podStorage 在任何时间点管理当前的 pod 状态，并确保按顺序传递对通道的更新，它的成员中包含一个用于存储 pod 对象的 map：

podStorage 里的 pods 字段是一个二级 map，第一层代表的是来源 source，第二层代表的是 pod 的uuid，value 是 pod 对象，updates 存的就是上面 PodConfig 中的 updates 对象。

然后就是 PodConfig 中的 config.Mux 对象，Mux 是一个用于合并来自多个源的配置类，变更通过 channels 推送并发送给 merge 函数，代码位于：

kubernetes/config.go at v1.22.8 · kubernetes/kubernetes

如下所示是 Mux 结构体的定义：

在 NewMainKubelet 函数中初始化一个 kubelet 对象，会通过一个 makePodSourceConfig 函数来初始化 PodConfig，代码位于：