Kubernetes 什么可以触发k8s中的SyncLoop DELETE api调用？

我有一个用于

nginx入口的
replicaset
在集群中运行，有两个实例。两天前晚上，两个容器同时被删除（相隔毫秒），并在同一复制集中创建了两个新实例。我不知道是什么触发了删除。在kubelet日志中，我可以看到以下内容：

kubelet[13317]: I0207 22:01:36.843804 13317 kubelet.go:1918] SyncLoop (DELETE, "api"): "nginx-ingress-public-controller-6bf8d59c4c

仅在日志中稍晚一点，列出了一个失败的活动性探测：

kubelet[13317]: I0207 22:01:42.596603 13317 prober.go:116] Liveness probe for "nginx-ingress-public-controller-6bf8d59c4c (60c3f9e5-e228-44c8-abd5-b0a4a8507b5c):nginx-ingress-controller" failed (failure): HTTP probe failed with statuscode: 500

理论上这可以解释pod的删除，但我对顺序感到困惑。此liveness probe失败是因为delete命令已经杀死了底层docker容器，还是这触发了删除？
要确定是什么导致了您的
nginx
pod的删除，如果没有完整的日志，很难猜测。正如您提到的，它的客户环境可能有很多原因。正如我在评论中所问的，可能是
HPA
或
CA
、可抢占节点、临时网络问题等

关于pod删除和
Liveness
的第二部分，
Liveness
探测失败，因为
nginx
pod处于
删除过程中

Kubernetes
默认设置之一是
宽限期
等于30秒。简而言之，这意味着Pod将处于
终止
状态30秒，然后将被移除

测验
如果你想自己验证，你可以做一些测试来确认。这将需要kubeadm master和更改。您可以通过编辑
/var/lib/kubelet/kubeadm flags.env
文件（必须具有根权限）并添加
--v=X
，其中
X
是数字
0-9
。可以找到显示特定日志的详细级别


至少将详细级别设置为
level=5
，我已经在
level=8
部署Nginx入口控制器
手动删除Nginx入口控制器
使用
$journalctl-u kubelet检查日志，您可以使用
grep
缩小输出范围并将其保存到文件中
（
$journalctl-u kubelet | grep ingres-nginx-controller-s2kfr>nginx.log
）


以下是我测试中的示例：

#Liveness and Readiness probe works properly:
Feb 24 14:18:35 kubeadm kubelet[11922]: I0224 14:18:35.399156   11922 prober.go:126] Readiness probe for "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21):controller" succeeded
Feb 24 14:18:40 kubeadm kubelet[11922]: I0224 14:18:40.587129   11922 prober.go:126] Liveness probe for "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21):controller" succeeded

#Once Deletion process start you can find DELETE api and other information

Feb 24 14:18:46 kubeadm kubelet[11922]: I0224 14:18:46.900957   11922 kubelet.go:1931] SyncLoop (DELETE, "api"): "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21)"
Feb 24 14:18:46 kubeadm kubelet[11922]: I0224 14:18:46.901057   11922 kubelet_pods.go:1482] Generating status for "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21)"
Feb 24 14:18:46 kubeadm kubelet[11922]: I0224 14:18:46.901914   11922 round_trippers.go:422] GET https://10.154.15.225:6443/api/v1/namespaces/ingress-nginx/pods/ingress-nginx-controller-s2kfr
Feb 24 14:18:46 kubeadm kubelet[11922]: I0224 14:18:46.909123   11922 event.go:291] "Event occurred" object="ingress-nginx/ingress-nginx-controller-s2kfr" kind="Pod" apiVersion="v1" type="Normal" reason="Killing" message="Stopping container controller"

# This entry occurs as default grace-period-time was kept
Feb 24 14:18:46 kubeadm kubelet[11922]: I0224 14:18:46.947193   11922 kubelet_pods.go:952] Pod "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21)" is terminated, but some containers are still running

# As Pod was in deletion, Probes failed.
Feb 24 14:18:50 kubeadm kubelet[11922]: I0224 14:18:50.584208   11922 prober.go:117] Liveness probe for "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21):controller" failed (failure): HTTP probe failed with statuscode: 500
Feb 24 14:18:50 kubeadm kubelet[11922]: I0224 14:18:50.584338   11922 event.go:291] "Event occurred" object="ingress-nginx/ingress-nginx-controller-s2kfr" kind="Pod" apiVersion="v1" type="Warning" reason="Unhealthy" message="Liveness probe failed: HTTP probe failed with statuscode: 500"
Feb 24 14:18:52 kubeadm kubelet[11922]: I0224 14:18:52.045155   11922 kubelet_pods.go:952] Pod "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21)" is terminated, but some containers are still running
Feb 24 14:18:55 kubeadm kubelet[11922]: I0224 14:18:55.398025   11922 prober.go:117] Readiness probe for "ingress-nginx-controller-s2kfr_ingress-nginx(9046e404-1b9e-44fd-86f3-5a16ebf27c21):controller" failed (failure): HTTP probe failed with statuscode: 500

在日志中，
SyncLoop（删除，“api”）
和
Liveness
探测之间的时间为4秒。在其他情况下，测试时间为几秒钟（相差4-7秒）

如果您想执行自己的测试，您可以将
准备状态
和
活跃度
探测检查更改为1秒（而不是默认设置的10秒），您将在
删除api
的同一秒内收到探测问题

Feb 24 15:09:40 kubeadm kubelet[11922]: I0224 15:09:40.865718   11922 prober.go:126] Liveness probe for "ingress-nginx-controller-wwrdw_ingress-nginx(427bc9d6-261e-4427-b034-7abe8cbbfea6):controller" succeeded
Feb 24 15:09:41 kubeadm kubelet[11922]: I0224 15:09:41.488819   11922 kubelet.go:1931] SyncLoop (DELETE, "api"): "ingress-nginx-controller-wwrdw_ingress-nginx(427bc9d6-261e-4427-b034-7abe8cbbfea6)"
...
Feb 24 15:09:41 kubeadm kubelet[11922]: I0224 15:09:41.865422   11922 prober.go:117] Liveness probe for "ingress-nginx-controller-wwrdw_ingress-nginx(427bc9d6-261e-4427-b034-7abe8cbbfea6):controller" failed (failure): HTTP probe failed with statuscode: 500

有关
syncLoop
的详细说明，请参见

如注释所示，
syncLoop
功能是
Kubelet
的主要循环。此函数侦听更新，获取最新的
Pod
配置，并
同步运行状态和所需状态。这样，本地节点上的所有
pod
都可以在预期状态下运行。实际上，
syncLoop
只封装了
syncLoopIteration
，而
同步
操作是由
syncLoopIteration
执行的

结论
如果在终止前没有其他日志记录来保存POD的输出，那么在事件发生一段时间后很难确定根本原因

在您提供的设置中，
Liveness
探测失败，因为
nginx入口
pod已经在终止过程中<代码>活性探测失败不会触发pod删除，但它是该删除的结果

此外，您还可以查看和查看源代码。
您是如何部署nginx的？你能分享你的环境细节吗？这是一个内部系统。我不知道你的意思是什么，它是否通过赫尔姆部署？是否有可能提供更多的日志？您是否执行了任何日志记录来检查此容器日志？您使用的是可抢占节点还是自动缩放？我可以提供完整的kubelet日志，但我不想把它留在这里，因为它是一个客户系统。虚拟机和群集节点是“静态”的，没有自动缩放，也没有可抢占节点。谢谢，我想这回答了我的问题。。。