【Kubernetes】K8s 查看 Pod 的状态

K8s 查看 Pod 的状态

[root@k8s-master1 ~]# kubectl get pods
NAME      READY   STATUS    RESTARTS      AGE
nginx-3   1/1     Running   2 (34m ago)   14h
  • NAME:Pod 的名称。
  • READY:代表 Pod 里面有几个容器,前面是启动的,后面是总数, 1 / 1 1/1 1/1
  • STATUS:就是当前 Pod 状态,最常见的就是 Running 正在运行,最期望的状态,只要不是 Running 的就说明有问题,就算是 Running 的就不一定没有问题。
状态
说明
Pending
挂起
在执行创建 Pod 过程中,命令行已经执行,Pod 已经被 K8s 系统接受,但仍有一个或多个容器未被创建,可以通过 kubectl describe 查看处于 Pending 状态的原因。
Running
运行中
Pod 已经被绑定到一个节点上,并且所有的容器都已经被创建,而且至少有一个是运行状态,或者是正在启动或者重启,可以通过 kubectl logs 查看 Pod 的日志。
Succeeded
成功
所有容器执行成功并终止,并且不会再次重启,可以通过 kubectl logs 查看 Pod 的日志
Failed
失败
至少有一个容器没有正常退出,以失败告终,在 Linux 上每个命令都有个状态值和信号值,状态值正常是 0 − 255 0-255 0255 之间,正常状态值为 0 0 0,容器的创建状态只要是非 0 0 0 就是异常的。
Unknown
未知
通常是是通信出问题了,不知道状态是啥通常是 Uknown
imagePullBackOffErrimagePull
镜像拉取失败
镜像拉取失败,一般是由于镜像不存在、网络不通或者需要登录认证引起的,可以使用 describe 命令查看具体原因。
CrashLoopBackOff
容器启动失败
容器启动失败,有可能是打的镜像文件本身就有问题,不能正常来启动,可以通过 logs 命令查看具体原因,一般为启动命令不正确,健康检查不通过等。
OOMKilled
内存溢出
内存溢出,运行的容器本身出现内存溢出,Tomcat JVM 栈基于 JVM 做各种各样的内存限制,对容器本身要做资源限制,一旦容器本身资源不够了,我们对这个容器本身资源限制和 JVM 那种内存冲突了,比如 JVM 需要 4 个 G,结果容器只给 2 个 G,那这样就出现内存溢出,不够用;还有一种方式,程序本身有问题,JVM 和容器内存限制都够用,还是内存溢出了。JVM 本身给的内存不够用造成的报错叫 OOM 内存溢出错误,一旦出现这种错误,容器或者程序本身会自动 kill 掉,程序一旦自己把自己 kill 掉意味着容器就没了,这个 OOM 就是容器里面的程序内存溢出了,一般是内存限制设置太小。
Terminating
终止
Pod 正在被删除,可以通过 describe 查看状态。
SysctlForbidden
内核启动失败
和 Linux 内核相关,在启动 Pod 的时候加了一些内核的需求,但是没有开放需求,就会造成内核启动失败。
Completed
主进程退出
容器内部主进程退出, 一般计划任务执行结束会显示该状态。
ContainerCreateing
创建容器
Pod 正在创建, 一般为正在下载镜像, 或者有配置不当的地方, 可以通过 describe 查看具体原因。
[root@k8s-master1 ~]# kubectl describe pods nginx-3
Name:             nginx-3
#pod名字
Namespace:        default
#Namespace
Priority:         0
#优先级
Service Account:  default
#默认使用default 
Node:             k8s-node1.guoguo.com/192.168.1.101
#绑定的节点node1
Start Time:       Sun, 06 Aug 2023 17:32:26 +0800
#创建的时间
Labels:           app=nginx
#标签,如果我们没有加标签,会自动加一个标签。如果是pod通常是run=pod名称
                  env=dev
Annotations:      cni.projectcalico.org/containerID: 
#资源注解
a121ada4cbabc46e302ba38008a7d6887f8f4035c8b42f781233f4fa3013bd96
                  cni.projectcalico.org/podIP: 192.26.131.132/32
                                        #pod的ip
                  cni.projectcalico.org/podIPs: 192.26.131.132/32
Status:           Running
#当前状态
IP:               192.26.131.132
#pod ip
IPs:
  IP:  192.26.131.132
Containers:
  nginx:
    Container ID:   containerd://57a204528d873a006134dcb7e58739b6adcbbd1b299d4b7e4984c451d47af86c
    Image:          harbor.guoguo.com/apps/ubuntu-nginx:1.22.1
    #镜像
    Image ID:       harbor.guoguo.com/apps/ubuntu-nginx@sha256:8818a74320ea5451b340d47faadba66cc9f582c9b734526c65076808412803a1
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 07 Aug 2023 07:24:36 +0800
    Last State:     Terminated
      Reason:       Unknown
      Exit Code:    255
      Started:      Sun, 06 Aug 2023 21:17:40 +0800
      Finished:     Mon, 07 Aug 2023 07:23:29 +0800
    Ready:          True
    Restart Count:  2
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-9lwkh (ro)
Conditions:
  Type              Status
  #类型           #状态
  Initialized       True
  #初始化          #成功
  Ready             True
  #准备           #成功
  ContainersReady   True
  #容器准备         #成功
  PodScheduled      True
  #pod调度        #成功
Volumes:
#卷组
  kube-api-access-9lwkh:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
#服务类 
Node-Selectors:              <none>
#没有节点选择                 #为none就说明没有给Node-selectors提特殊的节点选择
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>
  • 24
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
你好!对于 `CrashLoopBackOff` 状态Pod,这通常表示该 Pod 在启动过程中遇到了问题,并且一直处于重启循环中。这个状态意味着 Pod 启动后立即崩溃,然后 Kubernetes 尝试重新启动它,但又崩溃了,如此循环。 要解决这个问题,你可以按照以下步骤进行排查: 1. 查看 Pod 的日志:使用 `kubectl logs <pod-name>` 命令来查看 Pod 的日志,尝试找出何处发生了错误。可能会有一些错误消息或异常堆栈跟踪可供参考。 2. 检查 Pod 的配置:确保你的 Pod 配置正确无误,包括容器镜像、资源限制、环境变量等。一个常见的问题是容器启动所需的依赖项未正确配置或缺失。 3. 检查相关的服务和资源:如果你的应用程序依赖于其他服务或资源(例如数据库),请确保这些服务和资源都正常可用。如果依赖的服务不可用,可能会导致容器启动失败并进入 `CrashLoopBackOff` 状态。 4. 检查 Pod 的健康检查设置:你的应用程序可能配置了健康检查,例如使用 Kubernetes 的 liveness 或 readiness 探针。确保这些探针正确配置,以便检测到应用程序是否健康。如果探针失败,则 Pod 可能会被 Kubernetes 认为是不可用的,从而导致重启循环。 5. 更新容器镜像:如果你的应用程序使用的容器镜像存在已知的 bug 或问题,尝试更新镜像到最新版本或使用一个稳定版本。 通过排查以上问题,你应该能够找到导致 `CrashLoopBackOff` 状态的原因,并采取相应的措施解决问题。希望对你有所帮助!如果你还有其他问题,请随时提问。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

G皮T

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值