我的kubernetes连播不断通过“ CrashLoopBackOff”崩溃，但我找不到任何日志

106

这就是我不断得到的：

[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日志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文件

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（kube版本）上运行kubernetes集群：

[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运行镜像而不会出现任何问题。

有人可以帮我吗，如何在不看到任何日志的情况下进行调试？

kubernetes 
— 路西法
source
1
您可以尝试向Pod Yaml添加命令吗？
— Sukumar
2
检查日志kubectl logs -f <pod_name>是否可能是（服务器/容器）启动问题。
— Vishrant
您还可以运行kubectl get events查看导致挤压循环的原因。
— 玛格丽丝·克里斯

Answers:

82

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

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

— 史蒂夫·斯洛卡
source
1
如果我们添加了正确的Dockerfile并仍然出现错误，可能是什么原因？即使正确添加了命令，我也会遇到相同的错误。当我在不使用kubernetes部署的情况下测试独立的docker映像时，就会得到输出。因此，Dockerfile并不是问题。它与部署有关吗？在这里，我添加了我面临的整个问题，stackoverflow.com/questions/56001352/…。你能看一下吗？
— 雅各布
2
还有就是那张在深度上有什么CrashLoopBackoff手段和各种情况下，这种情况发生的一个非常好的博客： managedkube.com/kubernetes/pod/failure/crashloopbackoff/k8sbot/...
— 雀鳝
52 
kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name>
— 用户名
source
47
尽管此命令可能会（或可能无法解决）问题，但好的答案应始终包含如何解决问题的说明。
— BDL
第一个命令kubectl -n <namespace-name> describe pod <pod name>描述您的Pod，可用来查看在Pod创建和运行Pod中的任何错误（例如资源不足等）。第二个命令kubectl -n <namespace-name> logs -p <pod name>用于查看Pod中运行的应用程序的日志。
— iamabhishek
13

我需要让Pod继续运行以进行后续的kubectl exec调用，并且正如上面的注释所指出的那样，我的pod已被我的k8s集群杀死，因为它已经完成了所有任务的运行。我设法用一个不会自动停止的命令来踢豆荚，从而使豆荚保持运行：

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null
— hmacias
source
7
tailf不适用于我，但是这样做（在Alpine linux上）：--command /usr/bin/tail -- -f /dev/null
— JakubHolý19年
1
这不是pod名称。它是部署名称。kubectl run <deployment name> -n <namespace> --image <image> --command tailf /dev/null
— 加百利·吴
9

如果您的应用程序需要较慢的引导时间，则它可能与“就绪/活动”探针的初始值有关。initialDelaySeconds当我的SpringBoot应用程序处理大量初始化时，我通过将值增加到120s解决了我的问题。该文档没有提到默认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

initialInlaySeconds的默认值是什么，可以很好地解释这些值。

运行状况或准备情况检查算法的工作原理如下：

  1. 等待 initialDelaySeconds
  2. timeoutSeconds如果连续成功的次数大于successThreshold返回成功的次数，则执行检查并等待超时
  3. 如果连续失败的次数大于failureThreshold返回失败的次数，则等待periodSeconds并开始新的检查

就我而言，我的应用程序现在可以以一种非常清晰的方式进行引导，因此我知道我不会得到定期的崩溃循环回退，因为有时它会处于这些速率的限制之内。

— Marcello de Sales
source
您节省了我很多时间！谢谢。我的探测时间是90年代，甚至连豆荚都无法启动。
— Abhinav Pandey
8

在此页面上，容器在正确运行所有命令后死亡，但由于所有命令结束而崩溃。您可以使服务在前台运行，也可以创建一个保持活动脚本。这样，Kubernetes将显示您的应用程序正在运行。我们必须注意，在Docker环境中不会遇到此问题。只有Kubernetes想要运行的应用程序。

更新（示例）：

这是在启动Netshoot容器时避免CrashLoopBackOff的方法：

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity
— 朱利安·尼亚巴尔（Julien Nyambal）
source
6

我的吊舱不断坠毁，我无法找到原因。幸运的是，kubernetes在其中保存了我的pod崩溃之前发生的所有事件的空间。
（#List事件按时间戳排序）

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

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

确保添加一个 --namespace mynamespace根据需要在命令中参数

命令输出中显示的事件说明了为什么我的pod持续崩溃。

— 马蒂亚斯
source
谢谢！这个技巧帮助我发现秘密安装卷存在问题。
— 雷夫·约翰
还帮助我发现在Pod上分配的托管身份不正确。
— Jorn.Beyers
1

我观察到相同的问题，并在yaml文件中添加了命令和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
— amit23comp
source
0

就我而言，问题是史蒂夫·S。提到的：

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

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

（另一个原因可能是应用程序调用中的某些内容System.exit；您可以使用SecurityManager带有重写的自定义项checkExit来阻止（或记录调用者的）退出；请参阅https://stackoverflow.com/a/5401319/204205。）

— 雅各布·霍利（JakubHolý）
source
0

在对同一问题进行故障排除时，我发现在使用时没有日志 kubeclt logs <pod_id>。因此我将ssh：ed到节点实例中，以尝试使用普通docker运行容器。令我惊讶的是，这也失败了。

使用以下方法进入容器时： 

docker exec -it faulty:latest /bin/sh

闲逛我发现它不是最新版本。

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

当我使用以下命令删除有问题的：最新实例时：

docker rmi faulty:latest

一切开始起作用。

— javabeangrinder
source
0

尝试重新运行Pod并运行

 kubectl get pods --watch

观察Pod进度的状态。

就我而言，我只会看到最终结果“ CrashLoopBackOff”，但Docker容器在本地运行良好。因此，我使用上述命令观看了吊舱，并且看到容器短暂地进入了OOMKilled状态，这对我来说意味着它需要更多的内存。

— 乔什·沃尔夫
source
0

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

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
— 阿琼
source
0

我遇到了类似的问题，但是当我更正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
— 阿什娜
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.