问题标签 [crashloopbackoff]

我有一个简单的 spring boot 应用程序，带有以下 liveness probe：

在 health 端点中，我只是抛出了一个异常，导致它返回 500。这是一个新的 Pod 在观看多次重启后的统计数据：

我注意到前几次重新启动就像预期的那样快。然后#3、#4、#5 相隔 1 分钟。到目前为止有点道理。之后，我开始看到 CrashLoopBackOff 并且两次重新启动之间的时间间隔长达 5 分钟。为什么 CrashLoopBackOff？为什么在几次重启后重启相差如此之大？

我看到了吊舱的日志。没有什么不寻常的。日志输出是这样的（这些日志是在多次重启后）：

当我运行 describe 命令时，我看到类似

顺便说一句，在这 5 分钟内，pod 保持在CrashLoopBackOff状态。我已经多次重新启动 pod。我每次都看到相同的行为。

https://kubernetes.io/docs/tasks/administer-cluster/reconfigure-kubelet/

我根据上面的链接配置了我的 k8s 集群，但是 kubelet 服务无法正常启动。

我使用K8S v1.20并通过编辑文件/etc/default/kubelet设置了 kubelet --dynamic-config-dir 标志：

正如/etc/systemd/system/kubelet.service.d/10-kubeadm.conf建议的那样：

如果我删除 /etc/default/kubelet的竞争，一切都会正常工作。

DockerFile

描述命令的输出

在此处输入图像描述

日志输出启动 Jenkins [OK]

anypoint-monitoring：容器 ID：containerd://7db6d053b0e5de839cf06476f3fd0352e5523f538c0361955d1084e5a61eb887 图像：rtf-runtime-registry.kprod.msap.io/mulesoft/dias-anypoint-monitoring-sidecar:v1.3.1 msap.io/mulesoft/dias-anypoint-monitoring-sidecar@sha256:e850cc59bbc96d6f81f82b4d1879173cca1abfcffd0d3a024cf48adc667d391b 端口：主机端口：状态：运行开始：2021 年 6 月 29 日星期二 13:36:34 +0530 准备就绪：真的重新启动50m 内存：70Mi 请求：cpu：0 内存：50Mi 环境：APP_NAME：demo-app NAMESPACE_NAME：abe72b43-09b6-4a91-98e0-48b02a632b4c (v1:metadata.namespace) MASTER_ORG_ID:(v1:metadata.labels['master-org -id']) POD_NAME: demo-app-d894d9d45-fdrhq (v1:metadata.name) ORG_ID:(v1:metadata.labels['organization']) ENV_ID: (v1:metadata.labels['environment']) NODE_NAME: (v1:spec.nodeName) LOG_LOCATION: /mnt/overlay/opt/mule/logs/_* metric.log DATA_PATH：/mnt/overlay/am-data PROXY_URL：<在秘密“custom-properties”中设置为密钥“MONITORING_PROXY”> 可选：true INGEST_HOST：dias-ingestor-router.us-east-1.prod。 cloudhub.io:443 INGEST_HOST_LEGACY: dias-ingestor-nginx.prod.cloudhub.io:5044 挂载: /data/certs from monitoring-certs (rw) /mnt/overlay from overlay (rw) 条件: Type Status Initialized True Ready False ContainersReady False PodScheduled True 卷：podinfo：类型：DownwardAPI（由有关 pod 的信息填充的卷）项目：metadata.annotations ->注释覆盖：类型：EmptyDir（共享 pod 生命周期的临时目录） Medium：SizeLimit：tmp：类型：EmptyDir（共享 pod 生命周期的临时目录） Medium：SizeLimit：mulelicense：类型：Secret（由 a 填充的卷Secret）SecretName：rtf-muleruntime-license 可选：false 监控证书：类型：Secret（由 Secret 填充的卷） SecretName：rtf-monitoring-certificate 可选：true QoS 类：Burstable 节点选择器：Tolerations：node.kubernetes .io/memory-pressure: NoSchedule op=Exists node.kubernetes.io/not-ready: NoExecute op=Exists for 300s node.kubernetes.io/unreachable: NoExecute op=Exists for 300s Events:Type Reason Age From Message ---- ------ ---- ---- -------- Normal Pulled 101m (x62 over 6h31m) kubelet, aks-nodepool-15315347-vmss000001 Container image " rtf-runtime-registry.kprod.msap.io/mulesoft/poseidon-runtime-4.3.0:20210609-4" 已经出现在机器上 警告 BackOff 100s (x1771 over 6h31m) kubelet, aks-nodepool-15315347-vmss000001 Back-off重启失败的容器aks-nodepool-15315347-vmss000001 后退重启失败的容器aks-nodepool-15315347-vmss000001 后退重启失败的容器

我在 minikube 中应用了约束。我已经构建了一个 go 程序作为图像，它将通过应用 pod.yaml 文件作为 pod 执行。当我使用“kubectl get pods”获取 pod 的状态时，几秒钟后它显示“crashloopbackoff”作为状态。然后它显示为警告“后退重新启动失败的容器”。为什么 pod 在没有显示 crashoopbackoff 错误或任何重启警告状态的情况下无法永久成功运行。

豆荚.yaml

Kubernetes 的默认设置是什么CrashLoopBackOff？

说，我有一个豆荚：

我检查了它的状态：

这是“预期的”。Kubernetes 启动一个 pod，它“太快”退出，Kubernetes 再次调度它，然后 Kubernetes 将状态设置为CrashLoopBackOff.

现在，如果我以稍微不同的方式启动一个 pod：

我得到以下

这也是意料之中的。

但是假设我设置了 24 小时，在最初两个 pod 退出之后，然后在每个下一个 pod 退出之后sleep，我仍然会得到相同的结果吗？CrashLoopBackOff

我在部署 .Net Core API 时遇到“CrashLoopBackoff”错误helm upgrade --install flextoeco .：

我已经运行ks describe pod flextoecoapi-6bb7cdd846-r6c67，部分输出如下：

从这里的建议来看，我似乎有很多选项可以修复最值得注意的问题：i）向 Dockerfile 添加一个命令，以确保有一些前台进程正在运行 ii）扩展 LivenessProbe initialDelaySeconds

我选择了第一个并编辑了我的 Dockerfile，如下所示：

进行此更改后，我仍然遇到相同的错误。

更新

跳过：当我不使用 helm 时，部署工作完美，即我可以为部署/服务/nodeport/clusterip 执行 kubectl 申请，并且 API 部署没有问题。

我尝试如下更新 values.yaml 和 service.yaml，但重新部署后 CrashLoopBackOff 错误仍然存​​在：

模板/service.yaml

values.yaml
我在这里明确指定了 CPU 和内存使用情况

模板/deployment.yaml

当我运行 # kubectl run ubuntu --image=ubuntu 或 centos i gt containercrashoff 时，在 kubectl describe pod 中检查时观察到以下错误

警告 4 秒失败（x3 超过 22 秒）kubelet 错误：无法创建容器任务：OCI 运行时创建失败：container_linux.go:380：启动容器进程导致：exec：“ping”：在 $PATH 中找不到可执行文件：未知

请建议解决这个问题