K8S中POD节点状态ContainerCreating原因排查

最新推荐文章于 2024-11-30 08:00:00 发布

转载最新推荐文章于 2024-11-30 08:00:00 发布 · 1.1k 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/aresxin/p/K8S-issue1.html

文章标签：

#运维

本文解决了Kubernetes中Dashboard Pod状态一直为ContainerCreating的问题。通过重置节点、停止并重启相关服务，清除网络配置，成功解决了因网络设置冲突导致的Pod启动失败。

现象：

# kubectl get pods -n kube-system |grep dashboard
kubernetes-dashboard-6685cb584f-dqkwk   0/1     ContainerCreating   0          13m

状态一直是ContainerCreating。

查看pod日志：

# kubectl describe pod kubernetes-dashboard-6685cb584f-dqkwk --namespace=kube-system
...
 Warning  FailedCreatePodSandBox  13m                     kubelet, k8s-220   Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "fe44dea0870b79dbf2ae7d6de0eff1583c8ba99566775e70bfc44ca2088a74ce" network for pod "kubernetes-dashboard-6685cb584f-dqkwk": NetworkPlugin cni failed to set up pod "kubernetes-dashboard-6685cb584f-dqkwk_kube-system" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.2.1/24
...

可以看到是网络问题。

原因是node之前反复添加过,添加之前需要清除下网络
node上执行：

# kubeadm reset
# systemctl stop kubelet
# systemctl stop docker
# rm -rf /var/lib/cni/ /var/lib/kubelet/* /etc/cni/
# ifconfig cni0 down
# ifconfig flannel.1 down
# ifconfig docker0 down
# ip link delete cni0
# ip link delete flannel.1
# systemctl start docker
# # kubeadm join xxx

重新加入后问题即可解决。

# kubectl get pods -n kube-system |grep dashboard
kubernetes-dashboard-6685cb584f-dqkwk   1/1     Running   0          14m

可以看到状态变为了Running。

转载于:https://www.cnblogs.com/aresxin/p/K8S-issue1.html

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

aiduo4911

关注关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

K8S故障排查指南：部分节点无法启动Pod资源-Pod处于ContainerCreating状态

江晓龙的博客

05-23

8456

K8S部分节点无法启动Pod资源-Pod处于ContainerCreating状态 1.Pod长时间处于ContainerCreating状态的原因在日常运维中可能会遇到Pod资源长时间处于ContainerCreateing正在创建的状态，Pod维持这种状态在1-2分钟内还可以接受，如果在10分钟以上甚至更长，那么可能就是出问题了，遇到Pod资源处于非Running状态时，首先需要使用kubectl describe命令查看Pod的详情信息，从中获取报错信息。 Pod长时间处于ContainerCrea

K8S集群中Pod资源处于Pending状态排查思路

江晓龙的博客

06-14

9911

Pending状态表示挂起，处于该状态的原因有以下几点：处于Pending状态的原因最有可能的就是调度的Node节点上资源不足了。1）首先去排查节点的资源使用情况，使用命令查看内存的使用情况，命令查看系统的负载及CPU使用情况，查看磁盘的使用情况，快速定位是否是由于节点资源不足而引发的问题。如果资源充足，那么就可以排除是节点自身的问题了。2）被调度的节点可能存在污点配置，当K8S集群安装完成后，Master默认是开启污点的，开启污点的节点不允许被调度，可以进一步使用命令排查节点是否设置了污点操作，如果设置了

参与评论您还未登录，请先登录后发表或查看评论

K8S中Pod节点状态ContainerCreating原因排查

anmo7165的博客

09-11

2993

创建好一个pod之后，STATUS的状态一直是ContainerCreating，然后查看这个pod的详细信息。报错：网上查看了解决方法：可以看到是网络问题。原因是node之前反复添加过,添加之前需要清除下网络 node上执行： # kubeadm reset # systemctl stop kubelet # systemctl stop do...

k8s Pod status ContainerCreating

生命只有一次

11-15

679

pod status ContainerCreating kubectl describe pod my-nginx-86555897f9-d4gc5 reason like below docker run hello-world execute like below resolve : centos v7.4 +

k8s pod一直处于ContainerCreating状态

完颜振江

09-13

669

这两个命令会生成/etc/rhsm/ca/redhat-uep.pem文件.

pods处于ContainerCreating状态

weixin_34358365的博客

03-01

1051

2019独角兽企业重金招聘Python工程师标准>>> ...

解决k8s出现pod服务一直处于ContainerCreating状态的问题的过程

Black Winds的专栏

06-08

1万+

参考于：https://blog.youkuaiyun.com/learner198461/article/details/78036854https://liyang.pro/solve-k8s-pod-containercreating/ 根据实际情况稍微做了修改和说明。在创建Dashborad时，查看状态总是ContainerCreating[root@MyCentos7 k8s]# kubectl ...

【Pod故障处理】Pod 一直处于 ContainerCreating 或 Waiting 状态

2401_89314348的博客

11-30

3848

本文档介绍可能导致 Pod 一直处于 ContainerCreating 或 Waiting 状态的几种情形，以及如何通过排查步骤定位异常原因。请按照以下步骤依次进行排查，定位问题后恢复正确配置即可。

【Kubernetes实战】K8S集群Pod异常状态排查

Friendsofthewind的博客

03-12

1699

docker images本地可以查看到镜像，则需要将其执行：docker push ip:port/soft:v1.0将其推送到私有远程仓库，如果用pod控制器创建的可以删除pod，自动创建方式实现重建pod。因场景而异，有的时候是承载docker的节点物理内存不足，导致进程被杀死，或没被杀死，不能提供正常运行及处理任务所需内存。在事件列信息里确认是哪里出现问题，如果显示和docker有关，则证明还是“docker进程异常”，但是状态并没有死掉。第一步：执行上面两个查看服务状态命令，返回信息显示无异常；

K8S集群中Pod资源处于Terminating或Unknown状态排查思路

江晓龙的博客

06-30

5523

Error状态是CrashLoopBackOff状态之前的一个错误状态，Pod资源处于Error状态的原因可能有以下几种：1）排查Pod的状态 2）查看Pod运行的详细日志从中获取线索 3）排查容器运行的日志获取关键信息 4）排查Kubelet日志以及Node节点系统日志从中获取关键信息...

Kubernetes排错(七)-Pod 状态一直 ContainerCreating

sre救赎之路

06-23

586

会被k8s识别成byte，所以pause容器一起来就会被 cgroup-oom kill 掉，导致pod状态一直处于ContainerCreating。memory limit 单位写错，误将memory的limit单位像request一样设置为小。查看 master 上 kube-controller-manager 状态，异常的话尝试重启。，这个单位在memory不适用，应该用。

k8s的LInux单节点部署(含containerCreating、ImagePullBackOff、CrashLoopBackOff问题的解决方案)

思南的博客

12-27

1481

1、安装etcd和kubernetes 该步骤会默认安装docker。所以建议在原机器上没有安装Docker，否则可能会有冲突导致安装失败。 yum install -y etcd kubernetes 2、配置（1）、修改配置文件：/etc/sysconfig/docker 添加下面一行，使用内网仓库： ADD_REGISTRY='--add-registry reg.docker.lc' （2）修改配置文件：/etc/kubernetes/apiserver KUBE_API_ADDRESS="-

使用kubernetes创建容器一直处于ContainerCreating状态的原因查找与解决

最新发布

06-05

<think>嗯，用户现在遇到了KubernetesPod卡在ContainerCreating状态的问题，我需要帮ta解决这个问题。根据用户的请求，结合引用[1]和[2]的内容，我需要系统性地分析可能的原因和解决方案。首先从问题表现入手。ContainerCreating状态表示Pod已调度到节点，但容器未完成创建。这通常发生在镜像拉取、网络配置或存储挂载阶段。用户可能刚部署新Pod时遇到这个问题，或者运维中突然出现异常。排查思路需要分层展开。第一步是查看Pod描述信息，这是最直接的诊断方式，kubectldescribe命令能显示Pending原因、事件日志和错误详情。引用[2]中第六部分提到查看pod描述信息的方法，这应该作为首要建议。比如显示ImagePullBackoff的话，显然是镜像问题。然后是网络问题排查。Kubernetes网络插件如果异常，会导致CNI配置失败，特别要注意calico或flannel的Pod状态。节点间的网络策略也很关键，比如防火墙是否阻断端口。引用[1]提到要等待Pod进入Running状态，暗示部署过程需要网络连通性。镜像相关因素也不能忽视。如果用户使用了私有镜像仓库，需要检查pullsecret配置是否正确。还遇到过大小写敏感的镜像名拼写错误，或者远程仓库响应超时的情况。底层存储问题方面，PersistentVolumeClaim如果处于Pending会阻塞Pod创建。需要确认StorageClass可用性、节点存储配额，以及NFS服务器连接等细节。特别是StatefulSet类的有状态应用更容易在此处出错。对于kubelet日志的获取方法可能需要具体说明。用journalctl-ukubelet查看日志时，注意加上-f实时过滤关键字"ContainerCreating"或相关容器ID，这样用户能快速定位报错片段。最后给出分步骤流程图很重要。用户可能是新手运维人员，按"查看详情→网络检查→镜像验证→存储排查→插件重启"的路径来操作，能避免遗漏关键点。同时必须提醒kubelet服务健康度检查，这是很多文档容易忽略的基础项。</think> Kubernetes Pod 处于 `ContainerCreating` 状态通常表明容器尚未成功启动。以下是系统化的排查步骤和解决方案： --- ### **排查步骤 & 解决方案** #### **1. 查看 Pod 详细状态（关键）** ```bash kubectl describe pod <pod-name> -n <namespace> # 替换 Pod 名称和命名空间 ``` - **重点关注 `Events` 部分**，常见错误包括： - **`Failed to pull image`**: 镜像拉取失败（权限/路径错误） - **`NetworkPlugin not ready`**: CNI 网络插件未就绪 - **`MountVolume failed`**: 存储卷挂载失败（PVC 不存在/权限不足） - **`ImagePullBackOff`**: 镜像拉取策略错误或镜像仓库不可达 #### **2. 检查网络插件状态** ```bash kubectl get pods -n kube-system | grep -E 'cni|flannel|calico' # 检查 CNI 组件 kubectl logs -n kube-system <cni-pod-name> # 查看 CNI 日志 ``` - **常见问题**: - CNI 组件未运行或崩溃（重启相关 DaemonSet） - 节点防火墙阻止 VXLAN/IPIP 流量（开放 UDP 8472/VXLAN 端口） #### **3. 验证镜像可用性** ```bash kubectl get pod <pod-name> -o yaml | grep image: # 确认镜像名称 ``` - **排查方向**: - 镜像名称是否正确（区分公有/私有仓库） - 私有镜像需正确配置 `imagePullSecret`（引用[2]中提到 YAML 清单） - 执行 `docker pull <image>` 在节点手动测试镜像拉取 #### **4. 检查存储配置（PersistentVolume）** ```bash kubectl get pvc -n <namespace> # 查看 PVC 状态 kubectl describe pvc <pvc-name> -n <namespace> # 检查 PVC 事件 ``` - **解决方案**: - 确保 PVC 处于 `Bound` 状态（引用[2]中存储卷配置） - 验证 StorageClass 是否存在且可用 - NFS/GlusterFS 需确认服务端连通性 #### **5. 查看节点资源状态** ```bash kubectl describe node <node-name> | grep -A 10 "Allocated resources" # 检查资源配额 kubectl get events --field-selector involvedObject.name=<pod-name> # 过滤事件 ``` - **常见问题**: - 节点磁盘空间不足（`df -h` 检查 `/var/lib/docker`） - 内存/CPU 超分导致调度失败 #### **6. Kubelet 服务日志** ```bash journalctl -u kubelet -f | grep -i containercreating # 实时追踪 kubelet 日志 ``` - **关键日志**: - CRI（容器运行时）错误（如 Docker/Containerd 崩溃） - AppArmor/SELinux 安全策略拦截 --- ### **快速修复方案** ```mermaid graph TD A[Pod卡在ContainerCreating] --> B{查看 describe 事件} B --> |镜像问题| C[检查镜像名称/拉取密钥] B --> |存储问题| D[修复 PVC 或 StorageClass] B --> |网络问题| E[重启 CNI 或检查防火墙] B --> |资源不足| F[清理节点磁盘/扩容] C --> G[重新部署 Pod] D --> G E --> G F --> G ``` --- ### **相关问题** 1. **如何诊断 Kubernetes Pod 处于 `ImagePullBackOff` 状态？** 2. **PVC 绑定失败（Pending）的常见原因及解决方法？** 3. **Kubernetes 节点磁盘空间不足时如何自动清理？** 4. **如何为私有镜像仓库配置 `imagePullSecret`？** > 提示：检查 CNI 日志时若发现 `failed to allocate IP`，可能需扩容 Pod 网段（如 Calico IP 池）[^2]。 [^1]: 引用[1]: kubectl create -f busybox.yaml, Wait for pod running state. [^2]: 引用[2]: 【云原生之kubernetes】Pod 配置详解与运维管理实践.