我的 kubernetes pod 不断因“CrashLoopBackOff”而崩溃，但我找不到任何日志答案

【问题标题】：My kubernetes pods keep crashing with "CrashLoopBackOff" but I can't find any log我的 kubernetes pod 不断因“CrashLoopBackOff”而崩溃，但我找不到任何日志
【发布时间】：2017-05-27 01:09:13
【问题描述】：

这是我不断得到的：

[root@centos-master ~]# kubectl get pods
NAME               READY     STATUS             RESTARTS   AGE
nfs-server-h6nw8   1/1       Running            0          1h
nfs-web-07rxz      0/1       CrashLoopBackOff   8          16m
nfs-web-fdr9h      0/1       CrashLoopBackOff   8          16m

下面是describe pods的输出 kubectl describe pods

Events:
  FirstSeen LastSeen    Count   From                SubobjectPath       Type        Reason      Message
  --------- --------    -----   ----                -------------       --------    ------      -------
  16m       16m     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned nfs-web-fdr9h to centos-minion-2
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id d56f34ae4e8f
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id d56f34ae4e8f
  16m       16m     2   {kubelet centos-minion-2}               Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "web" with CrashLoopBackOff: "Back-off 10s restarting failed container=web pod=nfs-web-fdr9h_default(461c937d-d870-11e6-98de-005056040cc2)"

我有两个 pod：nfs-web-07rxz、nfs-web-fdr9h，但如果我使用 kubectl logs nfs-web-07rxz 或使用-p 选项，我在两个 pod 中都看不到任何日志。

[root@centos-master ~]# kubectl logs nfs-web-07rxz -p
[root@centos-master ~]# kubectl logs nfs-web-07rxz

这是我的 replicationController yaml 文件： replicationController yaml file

apiVersion: v1 kind: ReplicationController metadata:   name: nfs-web spec:   replicas: 2   selector:
    role: web-frontend   template:
    metadata:
      labels:
        role: web-frontend
    spec:
      containers:
      - name: web
        image: eso-cmbu-docker.artifactory.eng.vmware.com/demo-container:demo-version3.0
        ports:
          - name: web
            containerPort: 80
        securityContext:
          privileged: true

我的 Docker 镜像是由这个简单的 docker 文件制作的：

FROM ubuntu
RUN apt-get update
RUN apt-get install -y nginx
RUN apt-get install -y nfs-common

我在 CentOs-1611 上运行我的 kubernetes 集群，kube 版本：

[root@centos-master ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

如果我通过docker run 运行 docker 映像，我能够毫无问题地运行映像，但只有通过 kubernetes 我才会崩溃。

谁能帮帮我，我如何在没有看到任何日志的情况下进行调试？

【问题讨论】：

您可以尝试在 pod yaml 中添加 command 吗？
用kubectl logs -f <pod_name>检查日志可能是（服务器/容器）启动问题。
您也可以运行 kubectl get events 来查看导致崩溃循环的原因。

标签： kubernetes

【解决方案1】：

正如@Sukumar 评论的那样，您需要让您的 Dockerfile 有一个 Command 才能运行，或者让您的 ReplicationController 指定一个命令。

Pod 正在崩溃，因为它启动然后立即退出，因此 Kubernetes 重新启动并继续循环。

【讨论】：

如果我们添加了正确的 Dockerfile 但仍然出现错误，可能是什么原因？即使我正确添加了命令，我也会收到同样的错误。当我在不使用 kubernetes 部署的情况下测试独立的 docker 映像时，我得到了输出。所以 Dockerfile 没有问题。它与部署有关吗？在这里，我添加了我面临的整个问题，stackoverflow.com/questions/56001352/…。你能看一下吗？
有一个非常好的博客深入探讨了 CrashLoopBackoff 的含义以及可能发生这种情况的各种情况：managedkube.com/kubernetes/pod/failure/crashloopbackoff/k8sbot/…

【解决方案2】：

我需要为后续的 kubectl exec 调用保持一个 pod 运行，正如上面的 cmets 指出的那样，我的 pod 被我的 k8s 集群杀死了，因为它已经完成了所有任务的运行。我设法通过简单地使用不会自动停止的命令踢 pod 来保持我的 pod 运行，如下所示：

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null

【讨论】：

tailf 对我不起作用，但这样做（在 Alpine linux 上）：--command /usr/bin/tail -- -f /dev/null
这不是 pod 名称。这是部署名称。kubectl run <deployment name> -n <namespace> --image <image> --command tailf /dev/null

【解决方案3】：

kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name>

【讨论】：

尽管此命令可能（或可能不会）解决问题，但好的答案应始终包含问题解决方式的说明。
第一个命令kubectl -n <namespace-name> describe pod <pod name>是描述你的pod，可以用来查看pod创建和运行pod的任何错误，比如缺少资源等。第二个命令kubectl -n <namespace-name> logs -p <pod name>是查看 pod 中运行的应用程序的日志。

【解决方案4】：

从This page 开始，容器在正确运行所有内容后死亡，但由于所有命令都结束而崩溃。要么让你的服务在前台运行，要么创建一个保活脚本。通过这样做，Kubernetes 将显示您的应用程序正在运行。我们要注意，在Docker环境下，是不会遇到这个问题的。只有 Kubernetes 需要一个正在运行的应用程序。

更新（示例）：

以下是在启动 Netshoot 容器时如何避免 CrashLoopBackOff：

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity

【讨论】：

【解决方案5】：

如果您的应用程序启动速度较慢，则可能与就绪/活跃度探测器的初始值有关。我通过将 initialDelaySeconds 的值增加到 120s 解决了我的问题，因为我的 SpringBoot 应用程序处理了大量初始化。文档没有提到默认的 0 (https://kubernetes.io/docs/api-reference/v1.9/#probe-v1-core)

service:
  livenessProbe:
    httpGet:
      path: /health/local
      scheme: HTTP
      port: 8888
    initialDelaySeconds: 120
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10
  readinessProbe:
    httpGet:
      path: /admin/health
      scheme: HTTP
      port: 8642
    initialDelaySeconds: 150
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10

What is the default value of initialDelaySeconds 对这些值进行了很好的解释。

运行状况或就绪检查算法的工作原理如下：

等待initialDelaySeconds

执行检查并等待timeoutSeconds 超时如果持续成功的次数大于successThreshold，则返回成功

如果持续失败的次数大于failureThreshold，则返回失败，否则等待periodSeconds 并开始新的检查

在我的例子中，我的应用程序现在可以以非常清晰的方式引导，因此我知道我不会得到周期性的 crashloopbackoff，因为有时它会受到这些速率的限制。

【讨论】：

你为我节省了很多时间！谢谢你。我的探测时间是 90 年代，它甚至不会让 pod 启动。
大声笑我的是1s所以它立即崩溃了。切换到 300 现在运行良好！

【解决方案6】：

就我而言，问题出在 Steve S. 所提到的：

Pod 正在崩溃，因为它启动然后立即退出，因此 Kubernetes 重新启动并继续循环。

也就是说，我有一个 Java 应用程序，它的 main 抛出了一个异常（并且某些东西覆盖了默认的未捕获异常处理程序，因此没有记录任何内容）。解决方案是将main 的主体放入try { ... } catch 并打印出异常。这样我就可以找出问题所在并修复它。

（另一个原因可能是应用程序调用System.exit；您可以使用自定义SecurityManager 并覆盖checkExit 来防止（或记录调用者）退出；请参阅https://stackoverflow.com/a/5401319/204205。）

【讨论】：

【解决方案7】：

在解决相同问题时，我在使用 kubeclt logs <pod_id> 时没有发现任何日志。因此，我 ssh:ed 进入节点实例以尝试使用普通 docker 运行容器。令我惊讶的是，这也失败了。

当进入容器时：

docker exec -it faulty:latest /bin/sh

四处寻找，我发现它不是最新版本。

实例上已存在错误版本的 docker 映像。

当我删除有故障的：最新实例时：

docker rmi faulty:latest

一切都开始工作了。

【讨论】：

【解决方案8】：

我的 pod 不断崩溃，我无法找到原因。幸运的是there is a space where kubernetes saves all the events that occurred before my pod crashed。
(#List Events 按时间戳排序)

要查看这些事件，请运行以下命令：

kubectl get events --sort-by=.metadata.creationTimestamp

如果需要，请确保在命令中添加 --namespace mynamespace 参数

命令输出中显示的事件显示了我的 pod 不断崩溃的原因。

【讨论】：

谢谢！此提示帮助我检测到使用秘密安装卷时出现问题。
还帮助我发现 pod 上分配的托管标识不正确。

【解决方案9】：

我解决了这个问题我增加了内存资源

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi

【讨论】：

【解决方案10】：

在您的 yaml 文件中，添加命令和参数行：

...
containers:
      - name: api
        image: localhost:5000/image-name 
        command: [ "sleep" ]
        args: [ "infinity" ]
...

为我工作。

【讨论】：

Dockerfile中指定的命令会发生什么，它仍然执行吗？这是可靠的还是黑客攻击？

【解决方案11】：

我有同样的问题，现在我终于解决了。我没有使用 docker-compose 文件。我刚刚在我的 Docker 文件中添加了这一行，它工作了。

ENV CI=true

参考： https://github.com/GoogleContainerTools/skaffold/issues/3882

【讨论】：

【解决方案12】：

尝试重新运行 pod 并运行

 kubectl get pods --watch

查看 pod 的运行状态。

就我而言，我只会看到最终结果“CrashLoopBackOff”，但 docker 容器在本地运行良好。所以我使用上述命令查看了 pod，我看到容器短暂地进展为 OOMKilled state，这对我来说意味着它需要更多内存。

【讨论】：

【解决方案13】：

我观察到同样的问题，并在 yaml 文件中添加了 command 和 args 块。我正在复制我的 yaml 文件的示例以供参考

 apiVersion: v1
    kind: Pod
    metadata:
      labels:
        run: ubuntu
      name: ubuntu
      namespace: default
    spec:
      containers:
      - image: gcr.io/ow/hellokubernetes/ubuntu
        imagePullPolicy: Never
        name: ubuntu
        resources:
          requests:
            cpu: 100m
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello; sleep 10;done"]
      dnsPolicy: ClusterFirst
      enableServiceLinks: true

【讨论】：

可以说这应该在容器内运行的脚本中完成，而不是在主机上

【解决方案14】：

我通过删除数组内的引号和命令值之间的空格解决了这个问题，这是因为容器在启动后退出并且不存在要在容器内运行的可执行命令。

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

【讨论】：

这是一个定时炸弹

【解决方案15】：

我遇到了类似的问题，但是当我更正了服务名称与文件部署的容器名称不匹配的 zookeeper.yaml 文件时得到了解决。通过使它们相同，它得到了解决。

apiVersion: v1
kind: Service
metadata:
  name: zk1
  namespace: nbd-mlbpoc-lab
  labels:
    app: zk-1
spec:
  ports:
  - name: client
    port: 2181
    protocol: TCP
  - name: follower
    port: 2888
    protocol: TCP
  - name: leader
    port: 3888
    protocol: TCP
  selector:
    app: zk-1
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: zk-deployment
  namespace: nbd-mlbpoc-lab
spec:
  template:
    metadata:
      labels:
        app: zk-1
    spec:
      containers:
      - name: zk1
        image: digitalwonderland/zookeeper
        ports:
        - containerPort: 2181
        env:
        - name: ZOOKEEPER_ID
          value: "1"
        - name: ZOOKEEPER_SERVER_1
          value: zk1

【讨论】：

【解决方案16】：

在我的情况下，此错误特定于 hello-world docker 映像。我使用nginx 图像而不是hello-world 图像并且错误已解决。

【讨论】：

【解决方案17】：

就我而言，问题在于命令行参数的误解列表。我在我的部署文件中这样做：

...
args:
  - "--foo 10"
  - "--bar 100"

而不是正确的做法：

...
args:
  - "--foo"
  - "10"
  - "--bar"
  - "100"

【讨论】：

【解决方案18】：

我在执行 'docker run xxx' 命令时终于找到了解决方案，然后我得到了错误。它是由不完整的平台引起的。

【讨论】：

【解决方案19】：

如上所述，容器在创建时退出。

如果您想在不使用 yaml 文件的情况下对此进行测试，可以将 sleep 命令传递给 kubectl create deployment 语句。双连字符-- 表示命令，相当于Pod 或Deployment yaml 文件中的command:。

下面的命令使用sleep 1234为debian创建一个部署，所以它不会立即退出。

kubectl create deployment deb --image=debian:buster-slim -- "sh" "-c" "while true; do sleep 1234; done"

然后你必须创建一个服务等，但你可以kubectl exec -it <pod-name> -- sh（或 -- bash）进入你刚刚创建的 pod 来测试它。

【讨论】：

【解决方案20】：

Pod 应该处于 crashloopbackoff 状态的原因似乎有很多。

In my case, one of the container was terminating continuously due to the missing Environment value.

所以，最好的调试方法是 -

1. check Pod description output i.e. kubectl describe pod abcxxx
2. check the events generated related to the Pod i.e. kubectl get events| grep abcxxx
3. Check if End-points have been created for the Pod i.e. kubectl get ep
4. Check if dependent resources have been in-place e.g. CRDs or configmaps or any other resource that may be required.

【讨论】：