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 一直处于 ImagePullBackOff 状态

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

可能原因

HTTP 类型 Registry 地址未加入 insecure-registry
HTTPS 自签发类型 Registry CA 证书未添加至节点
私有镜像仓库认证失败
镜像文件损坏
镜像拉取超时
镜像不存在

排查方法

检查 HTTP 类型 Registry 地址是否加入 insecure-registry

Dockerd 默认从 HTTPS 类型的 Registry 拉取镜像。当您使用 HTTP 类型的 Registry 时,请确保已将其地址添加到 insecure-registry 参数中,并重启或 reload Dockerd 使其生效。

检查 HTTPS 自签发类型 Registry CA 证书是否未添加至节点

当您使用 HTTPS 类型 Registry 且其证书属于自签发证书时,Dockerd 将会校验该证书,只有校验成功才可以正常使用镜像仓库。
为确保校验成功,需要将 Registry 的 CA 证书放置到以下位置:
/etc/docker/certs.d/<Registry:port>/ca.crt

检查私有镜像仓库配置

若 Pod 未配置 imagePullSecret、配置的 Secret 不存在或者有误都会造成 Registry 认证失败,使 Pod 一直处于 ImagePullBackOff 状态。

检查镜像文件是否损坏

若 Push 的镜像文件损坏,下载成功后也不能正常使用,则需要重新 push 镜像文件。

检查镜像是否拉取超时

现象描述

当节点上同时启动大量 Pod 时,可能会导致容器镜像下载需要排队。假设下载队列靠前位置已有许多大容量镜像且需较长的下载时间,则会导致排在队列靠后的 Pod 拉取超时。
默认情况下,kubelet 支持串行下载镜像。如下所示:
--serialize-image-pulls Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an Aufs storage backend. Issue #10959 has more details. (default true)

解决思路

必要情况下,为避免 Pod 拉取超时,可开启并行下载及控制并发。示例如下:
--Registry-qps int32 If > 0, limit Registry pull QPS to this value. If 0, unlimited. (default 5)
--Registry-burst int32 Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding Registry-qps. Only used if --Registry-qps > 0 (default 10)

检查镜像是否存在

镜像本身不存在也会导致 Pod 一直处于 ImagePullBackOff 状态,可以通过 kubelet 日志进行确认。如下所示:
PullImage "imroc/test:v0.2" from image service failed: rpc error: code = Unknown desc = Error response from daemon: manifest for imroc/test:v0.2 not found

帮助和支持

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

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

文档反馈