为什么我看到pod在运行，也看到了CrashLoopOff in k8s？

Question

我正在尝试在PostgreSQL上创建k8s荚。在吊舱部署之后，当我使用kubectl获取吊舱时，我看到了

NAME            READY        STATUS        RESTARTS         AGE   

pgadmin         1/1           Running       5                  9m
postgres        1/1           Running       5                8m

然而，当我运行kubectl -o时，我看到了这个输出

pgadmin         0/1           CrashLoopBackOff         4    7m
postgres        0/1           CrashLoopBackOff         4     7  

我不知道为什么我看到两个不同的输出。当我运行kubectl日志pgadmin-63545-634536时，我看到以下输出

pgAdmin 4 - Application Initialisation
======================================

[2022-11-15 14:43:28 +0000] [1] [INFO] Starting gunicorn 20.1.0
[2022-11-15 14:43:28 +0000] [1] [INFO] Listening at: http://[::]:80 (1)
[2022-11-15 14:43:28 +0000] [1] [INFO] Using worker: gthread
[2022-11-15 14:43:28 +0000] [90] [INFO] Booting worker with pid: 90
[2022-11-15 14:44:24 +0000] [1] [INFO] Handling signal: term
[2022-11-15 14:44:25 +0000] [90] [INFO] Worker exiting (pid: 90)
[2022-11-15 14:44:26 +0000] [1] [INFO] Shutting down: Master

你能解释一下这是什么行为以及为什么我的吊舱关闭吗？我对K8s非常陌生。提前谢谢。

我试着检查日志文件

Answer 1

要回答为什么要看到两个不同的输出，您必须了解容器在Kubernetes中是如何运行的。

在停靠库中，容器可以运行然后终止，但除非您告诉码头用户您希望该容器使用--restart yes开关自动重新启动，否则将停止运行。

在Kubernetes部署(https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)中，--restart yes是隐含的--也就是说，当一个容器(或库伯奈茨世界中的“荚”)退出时，不管退出是有意还是无意，库伯内特斯都会重新启动容器并继续尝试重新启动它。

这方面的例外是当您运行一个Job (https://kubernetes.io/docs/concepts/workloads/controllers/job/)或CronJob (https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)时，它们将运行并重新启动，直到它们成功完成，然后终止为止，但这超出了您的问题范围。

从输出中的“重新启动”计数可以看出，重新启动的数量正在增加。Kubernetes将尝试重新启动上述已退出的容器，但如果它检测到正在重复重新启动，它将开始添加一个“后退”期(即在尝试重新启动容器之前添加一个延迟) --在此延迟期间，吊舱的状态将为"CrashLoopBackOff“。

要回答为什么会发生这种情况，您应该使用kubectl describe来描述吊舱。例如：

kubectl describe pod --namespace {name-of-namespace} pgadmin

这将给你的吊舱的细节，看看下面的Events部分-它可能有一些细节发生了什么。活性探针(https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)很可能失败，因此Kubernetes认为吊舱已经死亡，并相应地重新启动它们。