probeManager 的运行

probeManager 检测 pod 中容器的健康状态,目前有两种 probe:readiness 和 liveness。

1. readinessProbe 检测容器是否可以接受请求,如果检测结果失败,则 endpoint controller 将其从 service 的 endpoints 中移除,后续的请求也就不会发送给这个容器;

2. livenessProbe 检测容器是否存活,如果检测结果失败,kubelet 会杀死这个容器,并重启一个新的(除非 RestartPolicy 设置成了 Never)。

并不是所有的 pod 中的容器都有健康检查的探针,如果没有,则不对容器进行检测,默认认为容器是正常的。在每次创建新 pod 的时候,kubelet 都会调用 probeManager.AddPod(pod) 方法。

在每次创建新 pod 的时候,kubelet 都会调用 probeManager.AddPod(pod) 方法,它对应的实现在 pkg/kubelet/prober/prober_manager.go 文件中:

probeManager 的运行_第1张图片

该函数会扫描该Pod的所有containers,检查他们是否有readinessProbe或者livenessProbe。假如有的话,创建一个woker,然后启动一个go routine运行该worker;

probeManager 的运行_第2张图片

接下来看一下 doProbe 方法

1. pod 没有被创建,或者已经被删除了,直接跳过检测,但是会继续检测;

    status, ok := w.probeManager.statusManager.GetPodStatus(w.pod.UID)

    if !ok {

        return true

    }

2. pod 已经退出(不管是成功还是失败),直接返回,并终止 worker;

    if status.Phase == v1.PodFailed || status.Phase == v1.PodSucceeded {

        return false

    }

3. 容器没有创建,或者已经删除了,直接返回,并继续检测,等待更多的信息;

    c, ok := podutil.GetContainerStatus(status.ContainerStatuses, w.container.Name)

    if !ok || len(c.ContainerID) == 0 {

        return true // Wait for more information.

    }

4. pod 更新了容器,那么需要使用最新的容器信息再次进行 probe;

    if w.containerID.String() != c.ContainerID {

        if !w.containerID.IsEmpty() {

            w.resultsManager.Remove(w.containerID)

        }

        w.containerID = kubecontainer.ParseContainerID(c.ContainerID)

        w.resultsManager.Set(w.containerID, w.initialValue, w.pod)

        w.onHold = false

    }

    if w.onHold {

        return true

    }

5. 容器失败退出,并且不会再重启,终止 worker;

    if c.State.Running == nil {

        if !w.containerID.IsEmpty() {

            w.resultsManager.Set(w.containerID, results.Failure, w.pod)

        }

        return c.State.Terminated == nil || w.pod.Spec.RestartPolicy != v1.RestartPolicyNever

    }

6. 容器启动时间太短,没有超过配置的初始化等待时间 InitialDelaySeconds,那么过会儿再次进行 probe;

    if int32(time.Since(c.State.Running.StartedAt.Time).Seconds()) < w.spec.InitialDelaySeconds {

        return true

    }

7. 调用 prober 进行检测容器的状态;

    result, err := w.probeManager.prober.probe(w.probeType, w.pod, status, w.container, w.containerID)

8. 如果容器退出,并且没有超过最大的失败次数,则继续检测;

    if (result == results.Failure && w.resultRun < int(w.spec.FailureThreshold)) ||

        (result == results.Success && w.resultRun < int(w.spec.SuccessThreshold)) {

        // Success or failure is below threshold - leave the probe state unchanged.

        return true

    }

9. 保存最新的检测结果;

    w.resultsManager.Set(w.containerID, result, w.pod)

10. 容器 liveness 检测失败,需要删除容器并重新创建,在新容器成功创建出来之前,暂停检测;

if w.probeType == liveness && result == results.Failure {

        w.onHold = true

        w.resultRun = 1

    }


每次检测的时候都会用 w.resultsManager.Set(w.containerID, result, w.pod) 来保存检测结果,resultsManager 把结果保存在缓存中,并发送到 m.updates 管道。resultsManager 的代码在 pkg/kubelet/prober/results/results_manager.go:

probeManager 的运行_第3张图片

这个检测结果,使用的地方是不一样的。

对于 liveness  来说,因为它关系着pod 的生死,因此需要 kubelet 的处理逻辑。

probeManager 的运行_第4张图片
调用syncPod

但是 readiness 即使失败也不会重新创建 pod,它的处理逻辑是不同的,它的处理代码同样在 pkg/kubelet/prober/prober_manager.go

probeManager 的运行_第5张图片

proberManager 启动的时候,会运行一个 goroutine 定时读取 readinessManager 管道中的数据,并根据数据调用 statusManager 去更新 apiserver 中 pod 的状态信息。负责 Service 逻辑的组件获取到了这个状态,就能根据不同的值来决定是否需要更新 endpoints 的内容,也就是 service 的请求是否发送到这个 pod。

具体执行检测的代码在 pkg/kubelet/prober/prober.go 文件中,它会根据不同的 prober 方法(exec、HTTP、TCP)调用对应的处理逻辑,而这些具体的逻辑代码是在 pkg/probe/ 文件夹中,这里就不再详细说明了。

你可能感兴趣的:(probeManager 的运行)