k8s常见的排错指南Node,svc,Pod等以及K8s网络不通问题

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
可观测可视化 Grafana 版,10个用户账号 1个月
简介: k8s常见的排错指南Node,svc,Pod等以及K8s网络不通问题

Pod相关问题

1.Pod 无法启动

  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看该 Pod 的状态信息,检查容器的状态和事件信息,判断是否出现问题。
  • 使用 kubectl logs [pod_name] -n [namespace_name] 命令查看该 Pod 容器的日志信息,判断是否有错误或异常信息。
  • 使用 kubectl get events --field-selector involvedObject.name=[pod_name] -n [namespace_name] 查看Pod事件信息,是否有异常事件发生。
示例

查看所有Pod

[root@master ~]# kubectl get pod -A
NAMESPACE     NAME                             READY   STATUS              RESTARTS   AGE
dev           nginx-deploy-7cb7b87f5b-bkhmv    0/1     ContainerCreating   0          22h
kube-system   coredns-7ff77c879f-7kv5d         0/1     Completed           0          3d20h
kube-system   coredns-7ff77c879f-bccps         0/1     Completed           0          3d20h
kube-system   etcd-master                      1/1     Running             2          3d20h
kube-system   kube-apiserver-master            1/1     Running             2          3d20h
kube-system   kube-controller-manager-master   1/1     Running             2          3d20h
kube-system   kube-flannel-ds-5xd95            0/1     CrashLoopBackOff    39         21h
kube-system   kube-flannel-ds-c9zsl            0/1     CrashLoopBackOff    39         21h
kube-system   kube-proxy-9njjj                 1/1     Running             2          3d20h
kube-system   kube-proxy-kwczm                 1/1     Running             2          3d20h
kube-system   kube-scheduler-master            1/1     Running             2          3d20h
查看Pod详细信息
[root@master ~]# kubectl describe pod kube-flannel-ds-5xd95 -n kube-system
Name:                 kube-flannel-ds-5xd95
Namespace:            kube-system
Priority:             2000001000
Priority Class Name:  system-node-critical
Node:                 master/192.168.174.139
Start Time:           Mon, 28 Aug 2023 17:02:55 +0800
Labels:               app=flannel
                      controller-revision-hash=68c5dd74df
                      pod-template-generation=1
                      tier=node
Annotations:          <none>
Status:               Running
IP:                   192.168.174.139
IPs:
  IP:           192.168.174.139
Controlled By:  DaemonSet/kube-flannel-ds
Init Containers:
  install-cni:
    Container ID:  docker://6844b9fdea077d85570c7867c00a49ebdde003c549e97f9730ec8c24528ad875
    Image:         quay.io/coreos/flannel:v0.14.0
    Image ID:      docker-pullable://quay.io/coreos/flannel@sha256:4a330b2f2e74046e493b2edc30d61fdebbdddaaedcb32d62736f25be8d3c64d5
    Port:          <none>
    Host Port:     <none>
    Command:
查看Pod日志
[root@master ~]# kubectl logs -f kube-flannel-ds-c9zsl -n kube-system
I0829 06:34:20.771179       1 main.go:520] Determining IP address of default interface
I0829 06:34:20.773713       1 main.go:533] Using interface with name ens33 and address 192.168.174.138
I0829 06:34:20.773776       1 main.go:550] Defaulting external address to interface address (192.168.174.138)
W0829 06:34:20.869667       1 client_config.go:608] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
E0829 06:34:20.968272       1 main.go:251] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-c9zsl': pods "kube-flannel-ds-c9zsl" is forbidden: User "system:serviceaccount:kube-system:flannel" cannot get resource "pods" in API group "" in the namespace "kube-system"

2.Pod 无法连接到其他服务

  • 使用 kubectl exec -it [pod_name] -n [namespace_name]  /bin/bash 命令进入该 Pod 所在的容器,尝试使用 pingtelnet 等命令测试与其他服务的网络连接情况。
  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod 的 NetworkPolicy 配置,判断是否阻止了该 Pod 访问其他服务。
  • 使用 kubectl describe service [service_name] -n [namespace_name] 命令检查目标服务的配置和状态信息,判断是否存在故障。

3.Pod 运行缓慢或异常

  • 使用 kubectl top pod [pod_name] -n [namespace_name] 命令查看该 Pod 的 CPU 和内存使用情况,判断是否存在性能瓶颈。(top 需要已经安装HPA组件)
  • 使用 kubectl exec -it [pod_name] -n [namespace_name] -- /bin/bash 命令进入该 Pod 所在的容器,使用 tophtop 命令查看容器内部进程的 CPU 和内存使用情况,找出可能存在的瓶颈。
  • 使用 kubectl logs [pod_name] -n [namespace_name] 命令查看该 Pod 容器的日志信息,寻找可能的错误或异常信息。

 

4.Pod 无法被调度到节点上运行

  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看 Pod 的调度情况,判断是否存在资源不足、调度策略等问题。检查 Pod 所需的标签和注释,以及节点的标签和注释,判断是否匹配。
  • 使用 kubectl get nodeskubectl describe node [node_name] 命令查看所有节点的资源使用情况,判断是否存在节点资源不足或故障的情况。

 

5.Pod 状态一直是 Pending

  • 使用 kubectl get pods -n <namespace> 命令检查 Pod 的状态和事件,确定 Pod 处于何种状态以及是否有任何错误或警告信息。
  • 检查 Pod 的描述文件(YAML 或 JSON),确保各项字段(如镜像名称、资源请求、端口等)配置正确。
  • 如果 Pod 需要特定类型的节点(如 GPU 节点),确认集群中是否有符合条件的节点可用。
  • 检查 Pod 所需的资源配额(如 CPU、内存)是否已经达到上限,可以使用 kubectl describe pod <pod-name> -n <namespace> 查看详细信息。
  • 检查 Pod 所需的存储卷是否可用,确保没有引发挂载错误。
  • 如果是调度问题,可以通过以下方式解决:
  • 确保有足够的节点资源满足该 Pod 调度需求
  • 检查该节点的 taints 和 tolerations 是否与 Pod 的 selector 匹配
  • 调整 Pod 的调度策略,如使用 NodeSelector、Affinity 等

 

6.Pod 无法访问外部服务

  • 查看 Pod 中的 DNS 配置是否正确
  • 检查 Pod 所在的命名空间中是否存在 Service 服务
  • 确认该 Pod 是否具有网络访问权限
  • 查看 Pod 所在的节点是否有对外的访问权限
  • 检查网络策略是否阻止了 Pod 对外的访问
[root@node1 ~]# kubectl get svc -A
NAMESPACE     NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes            ClusterIP   10.96.0.1       <none>        443/TCP                  345d
default       mysqldb               NodePort    10.98.23.160    <none>        3306:30063/TCP           131d
default       mysqldb-headless      ClusterIP   None            <none>        3306/TCP                 131d
default       redis-db-headless     ClusterIP   None            <none>        6379/TCP                 131d
default       redis-db-master       NodePort    10.100.133.13   <none>        6379:30919/TCP           131d
dev           content-web-service   NodePort    10.111.76.113   <none>        9000:30001/TCP           142d
dev           mall-wx-service       NodePort    10.102.4.231    <none>        8082:30006/TCP           132d
kube-system   grafana               NodePort    10.101.1.36     <none>        3000:31831/TCP           175d
kube-system   kube-dns              ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP,9153/TCP   345d
kube-system   metrics-server        ClusterIP   10.105.109.21   <none>        443/TCP                  193d
kube-system   node-exporter         NodePort    10.103.179.32   <none>        9100:31672/TCP           175d
kube-system   prometheus            NodePort    10.109.244.79   <none>        9090:30003/TCP           175d

 

7.Pod 启动后立即退出

  • 查看该 Pod 的事件信息:kubectl describe pod <pod-name>
  • 查看该 Pod 的日志:kubectl logs <pod-name>
  • 检查容器镜像是否正确、环境变量是否正确、入口脚本是否正常
  • 尝试在本地使用相同的镜像运行该容器,查看是否有报错信息,如执行 docker run <image-name>

 

8.Pod 启动后无法正确运行应用程序

  • 查看 Pod 中的应用程序日志:kubectl logs <pod-name>
  • 查看该 Pod 的事件信息:kubectl describe pod <pod-name>
  • 检查应用程序的配置文件是否正确
  • 检查应用程序的依赖是否正常
  • 尝试在本地使用相同的镜像运行该容器,查看是否有报错信息,如执行 docker run <image-name>
  • 确认该应用程序是否与 Pod 的资源限制相符

 

9.Kubernetes 集群中的 Service 不可访问

  • 检查coreDNS服务是否可用;
  • 查看dns配置文件是否正确(/etc/resolv.conf);
  • 业务层面svc的port是否正确;
  • svc是否正确关联到后端的pod;
  • 业务pod是否正常工作;
  • CNI网络组件(flannel,calico)组件是否有问题;
  • kube-proxy组件是否正常;
  • 是否已经创建相关iptables规则或ipvs路由;
  • 附:Service工作流程图:

 

10.Pod 启动后立即终止或 CrashLoopBackOff 状态

  • 使用 kubectl get pods -n <namespace> 命令检查 Pod 的状态和事件,查看是否有任何错误或警告信息。
  • 使用 kubectl logs <pod-name> -n <namespace> 命令查看 Pod 的日志输出,尤其关注最后几行的错误信息。
  • 确认 Pod 的生命周期钩子(如 postStart、preStop)是否正确配置,是否有引发异常的操作。
  • 确认 Pod 执行的命令或容器启动命令是否正确,是否会导致容器意外退出。
  • 检查容器的资源使用情况是否超过 Pod 的资源限制,尤其是内存限制。

 

11.Pod 内部服务无法访问或网络连接问题

  • 使用 kubectl get pods -n <namespace> 命令检查 Pod 的状态和事件,查看是否有任何错误或警告信息。
  • 确认 Pod 所属的 Service 是否已经创建,且与 Pod 使用的端口和协议匹配。
  • 检查 Pod 内部的 DNS 配置,确保能够解析其他服务的域名。
  • 使用 kubectl exec <pod-name> -n <namespace> /bin/bash 进入容器Ping Pod的地址

 

12.Pod 与存储卷之间的问题

  • 使用 kubectl get pods -n <namespace> 命令检查 Pod 的状态和事件,查看是否有任何错误或警告信息。
  • 确认存储卷是否已经正确地绑定到 Pod 上,可以使用 kubectl describe pod <pod-name> -n <namespace> 查看详细信息。
  • 使用 kubectl exec <pod-name> -n <namespace> -- <command> 命令进入 Pod 内部,手动测试存储卷是否能够正常挂载和访问。
  • 检查存储卷提供程序(如 NFS、AWS EBS)的配置是否正确,并确保其可用性。
  • 确保存储卷访问模式(如 ReadWriteOnce、ReadOnlyMany)与应用程序的要求相匹配。
  • 查看挂载是否还在
[root@node1 ~]# df -h
文件系统                                                                                                容量  已用  可用 已用% 挂载点
devtmpfs                                                                                                1.9G     0  1.9G    0% /dev
tmpfs                                                                                                   1.9G     0  1.9G    0% /dev/shm
tmpfs                                                                                                   1.9G   16M  1.9G    1% /run
tmpfs                                                                                                   1.9G     0  1.9G    0% /sys/fs/cgroup
/dev/mapper/centos-root                                                                                  50G  6.4G   44G   13% /
/dev/mapper/centos-home                                                                                 245G  4.1G  241G    2% /home
/dev/sda1                                                                                              1014M  241M  774M   24% /boot

 

Node 相关问题及排查

 

1.Node 状态异常

  • 使用 kubectl get nodes 命令查看集群中所有节点的状态和信息,判断是否存在故障。
  • 使用 kubectl describe node [node_name] 命令查看目标节点的详细信息,包括 CPU、内存、磁盘等硬件资源的使用情况,判断是否存在性能瓶颈。
  • 使用 kubectl get pods -o wide --all-namespaces 命令查看集群中所有 Pod 的状态信息,判断是否有 Pod 运行在目标节点上导致资源紧张。
[root@node1 ~]# kubectl get node
NAME     STATUS   ROLES    AGE    VERSION
master   Ready    master   345d   v1.18.0
node1    Ready    <none>   345d   v1.18.0
[root@node1 ~]# kubectl describe node nodes
Error from server (NotFound): nodes "nodes" not found
[root@node1 ~]# kubectl describe node node1
Name:               node1
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=node1
                    kubernetes.io/os=linux

 

2.Node 上的 Pod 无法访问存储

  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod 的 volumes 配置信息,判断是否存在存储挂载失败的情况。
  • 使用 kubectl exec -it [pod_name] -n [namespace_name] /bin/bash 命令进入 Pod 所在的容器,尝试使用 lscat 等命令访问挂载的文件系统,判断是否存在读写错误。
  • 使用 kubectl describe persistentvolumeclaim [pvc_name] -n [namespace_name] 命令查看相关 PVC 配置和状态信息,判断是否存在故障。
  • 进入容器
[root@node1 ~]# kubectl exec -it content-web-deloy-58f6465676-pd5pq -n dev  /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
[root@content-web-deloy-58f6465676-pd5pq /]# ls
anaconda-post.log  bin  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  work
[root@content-web-deloy-58f6465676-pd5pq /]#

 

3.存储卷挂载失败

  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod 的 volumes 配置信息,判断是否存在存储卷定义错误。
  • 使用 kubectl describe persistentvolumeclaim [pvc_name] -n [namespace_name] 命令检查 PVC 的状态和信息,判断是否存在存储配额不足或存储资源故障等原因。
  • 如果是 NFS 或 Ceph 等网络存储,需要确认网络连接是否正常,以及存储服务器的服务是否正常。
  • 下面都是简写
[root@node1 ~]# kubectl get pv -A
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                                  STORAGECLASS   REASON   AGE
pvc-02087f98-25cf-41c4-9d74-810a922d4c65   8Gi        RWO            Delete           Bound      default/redis-data-redis-db-master-0   nfs-client              138d
pvc-c2a8055b-3cee-426e-8838-07d9f156f38a   8Gi        RWO            Delete           Bound      default/data-mysql-db-0                nfs-client              138d
pvc-d138f573-608c-44a0-9f54-9c1e391241b5   8Gi        RWO            Delete           Bound      default/data-mysqldb-0                 nfs-client              138d
pvc-d253f2a3-12ea-40c8-bbb7-298936a80a1e   500Mi      RWO            Delete           Bound      default/my-test                        nfs-client              139d
pvc0001                                    8Gi        RWO            Retain           Released   default/mydb-mysql                                             140d
[root@node1 ~]# kubectl get pvc -A
NAMESPACE   NAME                           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
default     data-mysql-db-0                Bound     pvc-c2a8055b-3cee-426e-8838-07d9f156f38a   8Gi        RWO            nfs-client     138d
default     data-mysqldb-0                 Bound     pvc-d138f573-608c-44a0-9f54-9c1e391241b5   8Gi        RWO            nfs-client     138d
default     data-redis-redis-ha-server-0   Pending                                                                                       139d
default     my-test                        Bound     pvc-d253f2a3-12ea-40c8-bbb7-298936a80a1e   500Mi      RWO            nfs-client     139d
default     redis-data-redis-db-master-0   Bound     pvc-02087f98-25cf-41c4-9d74-810a922d4c65   8Gi        RWO            nfs-client     138d
default     redis-data-redis-master-0      Pending                                                                                       139d
default     redis-data-redis-slave-0       Pending   

 

4.Node 节点加入 Kubernetes 集群后无法被调度

  • 检查该节点的 taints 和 tolerations 是否与 Pod 的 selector 匹配
  • 检查该节点的资源使用情况是否满足 Pod 的调度要求
  • 确保该节点与 Kubernetes API server 的连接正常

 

5.Kubernetes 集群中的 PersistentVolume 挂载失败

  • 检查 PersistentVolume 和 Pod 之间的匹配关系是否正确
  • 检查 PersistentVolumeClaim 中的 storageClassName 是否与 PersistentVolume 的 storageClassName 匹配
  • 检查节点存储配置和 PersistentVolume 的定义是否正确
  • 自动供给层面的权限是否已经给到位,大小是否匹配

 

集群层面问题及排查

 

1.集群中某个服务不可用,如何排查?

  • 使用 kubectl get pods -n [namespace_name] 命令查看相关服务的所有 Pod 的状态信息,判断是否存在故障。
  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod 的网络连接和存储访问等问题,寻找故障原因。
  • 使用 kubectl describe service [service_name] -n [namespace_name] 命令查看服务的配置和状态信息,判断是否存在故障。
[root@node1 ~]# kubectl get svc -A
NAMESPACE     NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes            ClusterIP   10.96.0.1       <none>        443/TCP                  345d
default       mysqldb               NodePort    10.98.23.160    <none>        3306:30063/TCP           131d
default       mysqldb-headless      ClusterIP   None            <none>        3306/TCP                 131d
default       redis-db-headless     ClusterIP   None            <none>        6379/TCP                 131d
default       redis-db-master       NodePort    10.100.133.13   <none>        6379:30919/TCP           131d
dev           content-web-service   NodePort    10.111.76.113   <none>        9000:30001/TCP           142d
dev           mall-wx-service       NodePort    10.102.4.231    <none>        8082:30006/TCP           132d
kube-system   grafana               NodePort    10.101.1.36     <none>        3000:31831/TCP           175d
kube-system   kube-dns              ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP,9153/TCP   345d
kube-system   metrics-server        ClusterIP   10.105.109.21   <none>        443/TCP                  193d
kube-system   node-exporter         NodePort    10.103.179.32   <none>        9100:31672/TCP           175d
kube-system   prometheus            NodePort    10.109.244.79   <none>        9090:30003/TCP           175d
[root@node1 ~]# kubectl describe svc grafana
Error from server (NotFound): services "grafana" not found
[root@node1 ~]# kubectl describe svc grafana -n kube-system
Name:                     grafana
Namespace:                kube-system
Labels:                   app=grafana
                          component=core
Annotations:              Selector:  app=grafana,component=core
Type:                     NodePort
IP:                       10.101.1.36
Port:                     <unset>  3000/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  31831/TCP
Endpoints:                10.244.1.18:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

 

 

2.集群中的 Node 和 Pod 不平衡,如何排查?

  • 使用 kubectl get nodeskubectl get pods -o wide --all-namespaces 命令查看所有 Node 和 Pod 的状态信息,判断是否存在分布不均的情况。
  • 使用 kubectl top pod -n [namespace_name] 命令查看所有 Pod 的 CPU 和内存使用情况,判断是否存在资源瓶颈导致 Pod 分布不均。
  • 使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看 Pod 所运行的节点信息,并使用 kubectl describe node [node_name] 命令查看相关节点的状态信息,判断是否存在节点不平衡的情况。
  • 使用 kubectl describe pod 或者 node [node_name] 查看当前Pod / Node上是否有相关的亲和或反亲和策略导致固定调度。

 

3.集群中某个节点宕机

  • 使用 kubectl get nodes 命令检查节点状态,找到异常节点。
  • 使用 kubectl drain [node_name] --ignore-daemonsets 命令将节点上的 Pod 驱逐出去,并将其部署到其他节点上。添加 --ignore-daemonsets 参数可以忽略 DaemonSet 资源。
  • 如果需要对节点进行维护或替换硬件:
  • 先将节点设置为不可以调度 kubectl cordon [node_name]
  • 再通过 kubectl drain [node_name] --ignore-daemonsets 命令将节点上的 Pod 驱逐出去,并将其部署到其他节点上。
  • 然后再次 kubectl delete node [node_name] 安全的进行节点下线。
[root@node1 ~]# kubectl get node
NAME     STATUS   ROLES    AGE    VERSION
master   Ready    master   345d   v1.18.0
node1    Ready    <none>   345d   v1.18.0

 

3.Kubernetes API Server 不可用

  • 使用 kubectl cluster-info 命令查看集群状态,判断是否存在 API Server 不可用的情况。
  • 使用 kubectl version 命令查看集群版本,确认 Kubernetes API Server 和 kubelet 版本是否匹配。
  • 使用 systemctl status kube-apiserver 命令检查 API Server 运行状态,确认是否存在故障或错误。(二进制安装有效)
  • 结合apiServer所在的节点查看系统层面的日志,进一步定位问题点。(二进制查看)

 

[root@node1 ~]# kubectl cluster-info
Kubernetes master is running at https://192.168.31.119:6443
KubeDNS is running at https://192.168.31.119:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://192.168.31.119:6443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
 
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
[root@node1 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

 

4.Kubernetes 命令执行失败

  • 检查 Kubernetes API server 是否可用:kubectl cluster-info
  • 检查当前用户对集群的权限是否足够:kubectl auth can-i <verb> <resource>
  • 检查 kubeconfig 文件中的登录信息是否正确:kubectl config view
  • ServiceMonitor是Prometheus操作员定义的CRD,用于自动获取Pod中运行容器的指标。
  • Helm Tiller安装在单个名称空间中,RBAC是使用Role和RoleBinding设置的。
[root@node1 ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.31.119:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
[root@node1 ~]# kubectl auth can-i <verb> <resource>
-bash: 未预期的符号 `<' 附近有语法错误
[root@node1 ~]# kubectl auth can-i
error: you must specify two or three arguments: verb, resource, and optional resourceName
[root@node1 ~]# kubectl auth can-i list deployment --as=tiller
no
[root@node1 ~]# kubectl auth can-i list deployment --as=admin
no

 

5.Kubernetes master 节点不可用

  • 检查 kube-apiserver、kube-scheduler、kube-controller-manager 是否都在运行状态
  • 检查 etcd 存储系统是否可用
  • 尝试重新启动 master 节点上的 kubelet 和容器运行时

 

[root@node1 ~]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since 二 2023-08-29 21:00:34 CST; 32min ago
     Docs: https://kubernetes.io/docs/
 Main PID: 747 (kubelet)
    Tasks: 26
   Memory: 125.8M
   CGroup: /system.slice/kubelet.service
           └─747 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/k...
 

 

6.Kubernetes 集群中的 Deployment 自动更新失败

  • 检查更新策略是否设置正确,如 rollingUpdaterecreate
  • 检查 Kubernetes API server 和 kubelet 之间的连接是否正常
  • 检查 Pod 的定义是否正确

 

7.Kubernetes 集群中的状态检查错误

  • 检查节点日志和事件信息,并确认错误类型
  • 确认该状态检查是否与 kubelet 的版本兼容
  • 尝试升级 kubelet 和容器运行时等组件

 

Pod常遇状态异常排查

一般来说,无论 Pod 处于什么异常状态,都可以执行以下命令来查看 Pod 的状态:

kubectl get pod <pod-name> -o yaml     查看 Pod 的配置是否正确
kubectl describe pod <pod-name> -n  namespaces      查看 Pod 的事件
kubectl logs <pod-name> [-c <container-name>]     查看容器日志

如上这些事件和日志通常都会有助于排查 Pod 发生的问题。

1.Pod 一直处于 Pending 状态

Pending 说明 Pod 还没有调度到某个 Node 上面。可以通过 kubectl describe pod <pod-name> 命令查看到当前 Pod 的事件,进而判断为什么没有调度。

可能的原因包括:

  • 资源不足,集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源;
  • HostPort 已被占用,通常推荐使用 Service 对外开放服务端口;

2.Pod 一直处于 Waiting 或 ContainerCreating 状态

首先还是通过 kubectl describe pod <pod-name> 命令查看到当前 Pod 的事件。可能的原因包括:

  • 镜像拉取失败,比如:
  • 配置了错误的镜像;
  • Kubelet 无法访问镜像(国内环境访问 gcr.io 需要特殊处理);
  • 私有镜像的密钥配置错误;
  • 镜像太大,拉取超时(可以适当调整 kubelet 的 --image-pull-progress-deadline--runtime-request-timeout 选项);
  • CNI 网络错误,一般需要检查 CNI 网络插件的配置,比如:
  • 无法配置 Pod 网络;
  • 无法分配 IP 地址;
  • 容器无法启动,需要检查是否打包了正确的镜像或者是否配置了正确的容器参数;

3.Pod 处于 ImagePullBackOff 状态

这通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。

这种情况可以使用 docker pull <image> 来验证镜像是否可以正常拉取。

如果是私有镜像,需要首先创建一个 docker-registry(并且是这个仓库) 类型的 Secret

kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

然后在容器中引用这个 Secret:

spec:
containers:
- name: private-reg-container
  image: <your-private-image>
imagePullSecrets:
- name: my-secret

4.Pod 一直处于 CrashLoopBackOff 状态

CrashLoopBackOff 状态说明容器曾经启动了,但又异常退出了。此时可以先查看一下容器的日志

kubectl logs <pod-name>
kubectl logs --previous <pod-name>

这里可以发现一些容器退出的原因,比如:

  • 容器进程退出;
  • 健康检查失败退出;

此时如果还未发现线索,还可以到容器内执行命令来进一步查看退出原因

kubectl exec cassandra -- cat /var/log/cassandra/system.log

如果还是没有线索,那就需要 SSH 登录该 Pod 所在的 Node 上,查看 Kubelet 或者 Docker 的日志进一步排查了

查询 pod 在哪台 Node:

kubectl get pod <pod-name> -o wide

5.Pod 处于 Error 状态

通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括:

  • 依赖的 ConfigMap、Secret 或者 PV 等不存在;
  • 请求的资源超过了管理员设置的限制,比如超过了 LimitRange 等;
  • 违反集群的安全策略,比如违反了 PodSecurityPolicy 等;
  • 容器无权操作集群内的资源,比如开启 RBAC 后,需要为 ServiceAccount 配置角色绑定;

6.Pod 处于 Terminating 或 Unknown 状态

Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod,而是将其标记为 Terminating 或 Unknown 状态。想要删除这些状态的 Pod 有三种方法:

  • 从集群中删除该 Node。使用公有云时,kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中,需要管理员手动删除 Node(如 kubectl delete node <node-name>
  • Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态,进而再决定删除或者继续运行这些 Pod。
  • 用户强制删除。用户可以执行 kubectl delete pods <pod> --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态(比如 Node 所在 VM 或物理机已经关机),否则不建议使用该方法。特别是 StatefulSet 管理的 Pod,强制删除容易导致脑裂或者数据丢失等问题。

Kubernetes故障排查指南-分析容器退出状态码

1.Pod status 状态解释

CrashLoopBackOff:容器退出,kubelet 正在将它重启
InvalidImageName:无法解析镜像名称
ImageInspectError:无法校验镜像
ErrImageNeverPull:策略禁止拉取镜像
ImagePullBackOff:镜像正在重试拉取
RegistryUnavailable:连接不到镜像中心
ErrImagePull:通用的拉取镜像出错
CreateContainerConfigError:不能创建kubelet使用的容器配置
CreateContainerError: 创建容器失败
m.internalLifecycle.PreStartContainer:执行hook报错
RunContainerError:启动容器失败
PostStartHookError:执行hook报错
ContainersNotInitialized:容器没有初始化完毕
ContainersNotReady:容器没有准备完毕
ContainerCreating:容器创建中
PodInitializing:pod 初始化中
DockerDaemonNotReady:docker还没有完全启动
NetworkPluginNotReady:网络插件还没有完全启动

2.容器 Exit Code

容器退出状态码的区间

  • 必须在 0-255 之间
  • 0 表示正常退出
  • 外界中断将程序退出的时候状态码区间在 129-255,(操作系统给程序发送中断信号,比如 kill -9 是 SIGKILL,Ctrl+c 是 SIGINT)
  • 一般程序自身原因导致的异常退出状态区间在 1-128 (这只是一般约定,程序如果一定要用129-255的状态码也是可以的)注意:有时我们会看到代码中有 exit(-1),这时会自动做一个转换,最终输出的结果还是会在 0-255 之间。

转换公式如下,code 表现退出的状态码:

当指定的退出时状态码为负数,转换公式如下:

256 - (|code| % 256)

当指定的退出时状态码为正数,转换公式如下:

code % 256

常见的容器退出状态码解释

EXIT CODE 0

  • 退出代码0表示特定容器没有附加前台进程
  • 该退出代码是所有其他后续退出代码的例外
  • 如果开发人员想要在容器完成其工作后自动停止其容器,则使用此退出代码。比如:kubernetes job 在执行完任务后正常退出码为0

EXIT CODE 1

  • 程序错误,或者Dockerfile中引用不存在的文件,如 entrypoint 中引用了错误的包
  • 程序错误可以很简单,例如 “除以0”,也可以很复杂,比如空引用或者其他程序 crash

EXIT CODE 137

  • 表明容器收到了 SIGKILL 信号,进程被杀掉,对应kill -9
  • 引发 SIGKILL 的是docker kill。这可以由用户或由docker守护程序来发起,手动执行:docker kill
  • 137 比较常见,如果 pod 中的limit 资源设置较小,会运行内存不足导致 OOMKilled,此时state 中的 ”OOMKilled” 值为true,你可以在系统的 dmesg -T 中看到 oom 日志

EXIT CODE 139

  • 表明容器收到了 SIGSEGV 信号,无效的内存引用,对应kill -11
  • 一般是代码有问题,或者 docker 的基础镜像有问题

EXIT CODE 143

  • 表明容器收到了 SIGTERM 信号,终端关闭,对应kill -15
  • 一般对应 docker stop 命令
  • 有时docker stop也会导致Exit Code 137。发生在与代码无法处理 SIGTERM 的情况下,docker进程等待十秒钟然后发出 SIGKILL 强制退出。

不常用的一些 EXIT CODE

  • Exit Code 126: 权限问题或命令不可执行
  • Exit Code 127: Shell脚本中可能出现错字且字符无法识别的情况
  • Exit Code 1 或 255:因为很多程序员写异常退出时习惯用 exit(1) 或 exit(-1),-1 会根据转换规则转成 255。这个一般是自定义 code,要看具体逻辑。
相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
3天前
|
Kubernetes 应用服务中间件 Docker
Kubernetes学习-集群搭建篇(二) 部署Node服务,启动JNI网络插件
Kubernetes学习-集群搭建篇(二) 部署Node服务,启动JNI网络插件
|
20小时前
|
Kubernetes API 调度
Kubernetes详解(十五)——Pod对象创建过程
Kubernetes详解(十五)——Pod对象创建过程
11 4
|
20小时前
|
Kubernetes API 调度
Kubernetes详解(十四)——Pod对象生命周期
Kubernetes详解(十四)——Pod对象生命周期
9 3
|
20小时前
|
Kubernetes Linux 调度
Kubernetes详解(十三)——Pod详解
Kubernetes详解(十三)——Pod详解
12 3
|
1天前
|
运维 Kubernetes Linux
Kubernetes详解(十)——Pod对象高级控制命令
Kubernetes详解(十)——Pod对象高级控制命令
11 0
|
3天前
|
存储 Kubernetes Docker
容器服务Kubernetes版产品使用合集之集群节点和 pod 实现自动扩缩容如何解决
容器服务Kubernetes版,作为阿里云提供的核心服务之一,旨在帮助企业及开发者高效管理和运行Kubernetes集群,实现应用的容器化与微服务化。以下是关于使用这些服务的一些建议和合集,涵盖基本操作、最佳实践、以及一些高级功能的使用方法。
23 2
|
3天前
|
Kubernetes 应用服务中间件 nginx
Kubernetes学习-深入Pod篇(一) 创建Pod,Pod配置文件详解
Kubernetes学习-深入Pod篇(一) 创建Pod,Pod配置文件详解
|
3天前
|
运维 Kubernetes Linux
Kubernetes详解(九)——资源配置清单创建Pod实战
Kubernetes详解(九)——资源配置清单创建Pod实战
19 2
|
3天前
|
Kubernetes 应用服务中间件 nginx
Kubernetes详解(六)——Pod对象部署和应用
在Kubernetes系列中,本文聚焦Pod对象的部署和管理。首先,通过`kubectl run`命令创建Pod,如`kubectl run pod-test --image=nginx:1.12 --port=80 --replicas=1`。接着,使用`kubectl get deployment`或`kubectl get pods`查看Pod信息,添加`-o wide`参数获取详细详情。然后,利用Pod的IP地址进行访问。最后,用`kubectl delete pods [Pod名]`删除Pod,但因Controller控制器,删除后Pod可能自动重建。了解更多细节,请参阅原文链接。
14 5
|
3天前
|
Kubernetes Perl 容器
在 Kubernetes 中重启 pod 的 3 种方法
【4月更文挑战第25天】
64 1
在 Kubernetes 中重启 pod 的 3 种方法