tencent cloud

容器服务

动态与公告
产品动态
公告
产品发布记录
产品简介
产品概述
产品优势
产品架构
应用场景
产品功能
基本概念
原生 Kubernetes 名词对照
容器服务高危操作
地域和可用区
开源组件
购买指南
购买指引
购买 TKE 标准集群
购买原生节点
购买超级节点
快速入门
新手指引
快速创建一个标准集群
入门示例
容器应用部署 Check List
集群配置
标准集群概述
集群管理
网络管理
存储管理
节点管理
GPU 资源管理
远程终端
应用配置
工作负载管理
服务和配置管理
组件和应用管理
弹性伸缩
容器登录方式
可观测配置
运维可观测性
成本洞察和优化
调度配置
调度组件概述
资源利用率优化调度
业务优先级保障调度
Qos 感知调度
安全和稳定性
容器服务安全组设置
身份验证和授权
应用安全
多集群管理
计划升级
备份中心
云原生服务指南
云原生 etcd
Prometheus 监控服务
TKE Serverless 集群指南
TKE 注册集群指南
实践教程
集群
Serverless 集群
调度
安全
服务部署
网络
发布
日志
监控
运维
Terraform
DevOps
弹性伸缩
容器化
微服务
成本管理
混合云
AI
故障处理
节点磁盘爆满排障处理
节点高负载排障处理
节点内存碎片化排障处理
集群 DNS 解析异常排障处理
集群 Kube-Proxy 异常排障处理
集群 API Server 网络无法访问排障处理
Service&Ingress 网络无法访问排障处理
Service&Ingress 常见报错和处理
Nginx Ingress 偶现 Connection Refused
CLB Ingress 创建报错排障处理
Pod 网络无法访问排查处理
Pod 状态异常与处理措施
授权腾讯云售后运维排障
CLB 回环问题
API 文档
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
常见问题
TKE 标准集群
TKE Serverless 集群
运维类
隐患处理
服务类
镜像仓库类
远程终端类
事件类
资源管理类
服务协议
TKE Service Level Agreement
TKE Serverless Service Level Agreement
联系我们
词汇表
文档容器服务故障处理Pod 状态异常与处理措施Pod 处于 CrashLoopBackOff 状态

Pod 处于 CrashLoopBackOff 状态

PDF
聚焦模式
字号
最后更新时间： 2024-12-13 11:32:48
本文档介绍可能导致 Pod 处于 CrashLoopBackOff 状态的几种情形，以及如何通过排查步骤定位异常原因。请按照以下步骤依次进行排查，定位问题后恢复正确配置即可。

现象描述

Pod 处于 CrashLoopBackOff 状态，说明该 Pod 在正常启动过后异常退出过，此状态下 Pod 的 restartPolicy 如果不是 Never 就可能会被重启拉起，且 Pod 的 RestartCounts 通常大于0。可首先参考 通过 Exit Code 定位 Pod 异常退出原因 查看对应容器进程的退出状态码，缩小异常问题范围。

可能原因

容器进程主动退出
系统 OOM
cgroup OOM
节点内存碎片化
健康检查失败

排查步骤

检查容器进程是否主动退出

容器进程主动退出时，退出状态码通常在0 - 128之间，导致异常的原因可能是业务程序 Bug，也可能是其他原因。请参考 容器进程主动退出 进一步定位异常问题。

检查是否发生系统 OOM

问题分析

如果发生系统 OOM，Pod 中容器退出状态码为137，表示其被 SIGKILL 信号停止，同时内核将会出现以下报错信息。
Out of memory: Kill process ...
该异常是由于节点上部署了其他非 K8S 管理的进程消耗了较多的内存，或是 kubelet 的 --kube-reserved 和 --system-reserved 所分配的内存太小，没有足够的空间运行其他非容器进程。
说明：
节点上所有 Pod 的实际内存占用总量不会超过 /sys/fs/cgroup/memory/kubepods 中的 cgroup 值（ cgroup = capacity - "kube-reserved" - "system-reserved"）。通常情况下，如果预留空间设置合理，且节点上其他非容器进程（例如 kubelet、dockerd、kube-proxy 及 sshd 等）内存占用没有超过 kubelet 配置的预留空间，是不会发生系统 OOM 的。

解决方法

为确保不再发生此类问题，您可以根据实际需求对预留空间进行合理的调整。

检查是否发生 cgroup OOM

现象描述

如果是因 cgroup OOM 而停止的进程，可看到 Pod 事件下 Reason 为 OOMKilled，说明容器实际占用的内存已超过 limit，同时内核日志会报 Memory cgroup out of memory 错误信息。

解决方法

请根据需求调整 limit。

节点内存碎片化

如果节点出现内存碎片化严重、缺少大页内存问题，即使总体剩余内存较多，但仍会出现申请内存失败的情况。请参考 内存碎片化 进行异常定位及解决。

健康检查失败

请参考 Pod 健康检查失败 进一步定位异常问题。
上一篇: Pod 健康检查失败下一篇: Pod 无限重启且流量异常

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈