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 所在的容器，尝试使用 ping 或 telnet 等命令测试与其他服务的网络连接情况。
使用 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 所在的容器，使用 top 或 htop 命令查看容器内部进程的 CPU 和内存使用情况，找出可能存在的瓶颈。
使用 kubectl logs [pod_name] -n [namespace_name] 命令查看该 Pod 容器的日志信息，寻找可能的错误或异常信息。

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

使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看 Pod 的调度情况，判断是否存在资源不足、调度策略等问题。检查 Pod 所需的标签和注释，以及节点的标签和注释，判断是否匹配。
使用 kubectl get nodes 和 kubectl 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 所在的容器，尝试使用 ls 和 cat 等命令访问挂载的文件系统，判断是否存在读写错误。
使用 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 nodes 和 kubectl 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 自动更新失败

检查更新策略是否设置正确，如 rollingUpdate 或 recreate
检查 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，要看具体逻辑。

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