发生了什么？
静态pod最好被看作是由控制器驱动的API pod,应该由Kubelet持续重启。今天，我们通过准入将静态pod传递过去，它们可以被拒绝，这防止了pod在kubelet重启之前被重新考虑。因为状态管理器是“准入拒绝”的真相来源，所以Kubelet中的其他代码无法区分真正终止的pod和因准入拒绝而被拒绝的pod。
在我们处理#115331的过程中，我们试图始终为已完成的所有pod设置终止阶段 - 这对于镜像pod来说应该是没问题的，因为kubelet可以重启它。然而，由于状态管理器中的终止阶段与准入失败无法区分，因此HandlePodCleanups方法永远不会检查是否需要重启。如果管理员进行了配置更改，那么会触发重新评估,但是如果那个静态pod配置了一个静态uid,那么该pod将永远不会被重新考虑。
我们不应该要求Kubelet重启来重启静态pod,而且导致静态pod无法被接受的kubelet重启应该可以在不进行后续重启的情况下治愈。
/sig node
你期望发生什么？

1. 我们应该能够为镜像pod设置终止阶段，而不会影响静态pod的重启
2. 如果静态pod在准入过程中失败，我们不应该需要重启kubelet才能让它重试
3. 如果静态pod被驱逐(不确定这是否可能),它应该在没有kubelet重启的情况下重新尝试
   为了实现上述任何一点，我们可能需要有一个更好的准入拒绝的真相来源。这可能意味着让pod worker负责准入期间的拒绝，因为pod worker本来就应该是准入的真相来源(#104824)。在此之前，#115331 将忽略静态pod,因为我们不能安全地为静态pod分配终止阶段。
   另外请参阅#116483,它也受到我们如何处理镜像pod阶段的影响。
   如何尽可能精确且最小化地重现？
   参见描述。
   我们需要了解其他什么吗？

• 无响应*

Kubernetes版本

$ kubectl version
# paste output here

云提供商
操作系统版本

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

安装工具
容器运行时(CRI)和版本(如适用)
相关插件(CNI、CSI等)和版本(如适用)