在问题发生之后，我们重启Kubelet，节点三分钟之后才会变成NotReady状态。这个现象是分析问题的一个关键切入点。在解释它之前，请大家看一下官方PLEG实现架构图，第13章的图13-4。
这幅图片主要展示了两个过程。一方面，Kubelet作为集群控制器，从API Server处获取Pod定义的变化，然后通过创建Worker线程来创建或结束Pod；另一方面，PLEG定期检查容器状态，然后把状态以事件的形式反馈给Kubelet。在这里，PLEG有两个关键的时间参数，一个是检查的执行间隔，另一个是检查的超时。
在默认情况下，PLEG的检查间隔是1秒钟，换句话说，每一次检查过程执行之后，PLEG会等待1秒钟，然后进行下一次检查；而每一次检查的超时是3分钟，如果一次PLEG检查操作不能在3分钟内完成，那么这个状况会被上一节提到的NodeStatus机制当作集群节点NotReady的凭据，同步给API Server。
而我们之所以观察到节点会在重启Kubelet之后处于就绪状态3分钟，是因为Kubelet重启之后第一次PLEG检查操作就没有顺利结束，节点就绪直到3分钟超时之后才被同步到集群中。如图14-4所示，上面一行表示正常情况下PLEG的执行流程，下面一行则表示有问题的情况。relist是检查的主函数。
图14-4 relist操作流程