Below you will find pages that utilize the taxonomy term “Kubelet”
📎Posts
Kubelet StatusManager机制流程分析
Kubelet StatusManager机制流程分析#
主要功能将Pod状态信息同步到ApiServer,并不会主动监控Pod状态,提供接口供其他Manager调用,当其他组件需要改变 pod 的状态时会将 pod 的 status 信息发送到 statusManager 进行同步。主要使用方
probeManager,podWorkers

type manager struct {
kubeClient clientset.Interface
podManager kubepod.Manager
// Map from pod UID to sync status of the corresponding pod.
// statusManager 的 cache,保存 pod 与状态的对应关系;
podStatuses map[types.UID]versionedPodStatus
podStatusesLock sync.RWMutex
// 当其他组件调用 statusManager 更新 pod 状态时,会将 pod 的状态信息发送到podStatusesChannel 中;
podStatusChannel chan podStatusSyncRequest
// Map from (mirror) pod UID to latest status version successfully sent to the API server.
// apiStatusVersions must only be accessed from the sync thread.
apiStatusVersions map[kubetypes.MirrorPodUID]uint64
// 删除 pod 的接口
podDeletionSafety PodDeletionSafetyProvider
podStartupLatencyHelper PodStartupLatencyStateHelper
}
Start#
// 设置定时触发,时间为10s
syncTicker := time.NewTicker(syncPeriod).C
go wait.Forever(func() {
for {
select {
// 监听到一个pod状态变更的场景
case syncRequest := <-m.podStatusChannel:
klog.V(5).InfoS("Status Manager: syncing pod with status from podStatusChannel",
"podUID", syncRequest.podUID,
"statusVersion", syncRequest.status.version,
"status", syncRequest.status.status)
m.syncPod(syncRequest.podUID, syncRequest.status)
-> func (m *manager) needsUpdate(uid types.UID, status versionedPodStatus) bool {
// 1. 判断版本号信息
// 2. 获取pod
// 3. 判断是否处于删除状态
-> PodResourcesAreReclaimed // 检查 pod 在 node 上占用的所有资源是否已经被回收
}
// 触发定时器(定时器,syncPeriod 默认为 10s)
case <-syncTicker:
klog.V(5).InfoS("Status Manager: syncing batch")
// remove any entries in the status channel since the batch will handle them
for i := len(m.podStatusChannel); i > 0; i-- {
<-m.podStatusChannel
}
m.syncBatch()
}
}
}, 0)
syncPod#
- 基本流程
- 判断是否需要同步状态, 判断版本号信息是否已经增加,若不需要同步则继续检查 pod 是否处于删除状态
- 合并状态信息并更新记录到cache
- 如果可以删除pod,执行删除动作
func (m *manager) syncPod(uid types.UID, status versionedPodStatus) {
// 判断是否需要同步状态,以及是否处于删除状态
if !m.needsUpdate(uid, status) {
...
}
// 判断ResolvedPodUID是否一致,不一致则为删除后重建出来的pod,需要删除statusmanager保存的旧状态信息
if len(translatedUID) > 0 && translatedUID != kubetypes.ResolvedPodUID(uid) {
// 删除保存的状态信息,以及启动延时处理的状态
m.deletePodStatus(uid)
return
}
// 根据实际运行状态以及其他组件设置的状态合并出最终状态信息
mergedStatus := mergePodStatus(pod.Status, status.status, m.podDeletionSafety.PodCouldHaveRunningContainers(pod))
// 更新pod状态信息以及所记录状态
// 如果pod处理删除状态,删除pod以及记录信息
if m.canBeDeleted(pod, status.status) {
// 设置GracePeriodSecond为0,同时避免删除一个同名同命名空间的资源,传递Uid做precondition
...
err = m.kubeClient.CoreV1().Pods(pod.Namespace).Delete(context.TODO(), pod.Name, deleteOptions)
...
m.deletePodStatus(uid)
}
}
syncBatch#
定期将statusManager 缓存 podStatuses 中的数据同步到 apiserver,定时同步的时候会清理channel内容
📎Posts
Kubelet VolumeManager机制流程分析
Kubelet VolumeManager机制流程分析#
Kubelet Volume相关逻辑主要在VolumeManager模块

- Mount 阶段则由对应节点的 kubelet 中的 volume manager 处理。
- volume manager 获取 node.Status.VolumesAttached 属性值,发现 volume 已被标记为 attached, 就会进行 mount 操作
- k8s中涉及存储的组件主要有:attach/detach controller、pv controller、volume manager、volume plugins、scheduler。每个组件分工明确:
- attach/detach controller:负责对 volume 进行 attach/detach
- persistent volume controller:负责处理 pv/pvc 对象,包括 pv 的 provision/delete
- kubelet volume manager:主要负责对 volume 进行 mount/unmount
- volume plugins:包含 k8s 原生的和各厂商的的存储插件
挂载流程#
第一步是在准备 volume(宿主机目录),第二步才是真正的挂载操作。