概述

为了跟踪和发现在Kubernetes集群中运行的容器应用出现的问题，我们常用如下排查方法：

  • 查看Kubernetes对象的当前运行时信息，特别是与对象关联的Event事件。这些事件记录了相关主题、发生时间、最近发生时间、发生次数及事件原因等，对排查故障非常有价值。此外，通过查看对象的运行时数据，我们还可以发现参数错误、关联错误、状态异常等明显问题。由于在Kubernetes中多种对象相互关联，因此这一步可能会涉及多个相关对象的排查问题。
  • 对于服务、容器方面的问题，可能需要深入容器内部进行故障诊断，此时可以通过查看容器的运行日志来定位具体问题。
  • 对于某些复杂问题，例如pod调度这种全局性的问题，可能需要结合集群中每个节点上的Kubernetes服务日志来排查。比如搜集Master上的kube-apiserver、kube-schedule、kube-controler-manager服务日志，以及各个Node上的kubelet、kube-proxy服务日志，通过综合判断各种信息，就能找到问题的成因并解决问题。

方法

查看系统Event

Kubernetes提供了以下命令来查看一个Pod的详细信息：

1
kubectl describe pod -n <namespace>

通过以上命令可以显示pod创建时的配置定义、状态等信息，还可以显示与该pod相关的最近的Event事件，事件信息对于查错非常有用。

从Event事件中获知pod失败的原因可能有以下几种：

  • 没有可用的Node以供调度。
  • 开启了资源配额管理，但在当前调度的目标节点上资源不足。
  • 镜像下载失败，镜像下载失败通常为网络问题。

同理，通过kubectl describe命令，还可以查看其他Kubernetes对象，包括Node、RC、Service、Namespace、Secrets等，对每种对象都会显示相关的其他信息。

查看容器日志

在需要排查容器内部应用程序生成的日志时，我们可以使用以下命令：

1
kubectl logs <pod_name> -n <namespace>

如果在某个Pod中包含多个容器，就需要通过-c参数指定容器的名称来查看

1
kubectl logs <pod_name> -c <container_name> -n <namespace>

容器中应用程序生成的日志与容器的生命周期是一致的，所以在容器被销毁之后，容器内部的文件也会被丢弃，包括日志等。如果需要保留容器内应用程序生成的日志，则可以使用挂载的Volume将容器内应用程序生成的日志保存到宿主机，还可以通过一些工具如Fluentd、Elasticsearch等对日志进行采集。

查看Kubernetes服务日志

如果在Linux系统上安装Kubernetes，并且使用systemd系统管理Kubernetes服务，那么systemd的journal系统会接管服务程序的输出日志。在这种环境中，可以通过使用systemd status或journalctl工具来查看系统服务的日志。

例如查看kube-controller-manager服务的日志：

1
systemctl status kube-controller-manager

使用journalctl命令查看：

1
journalctl -u kube-controller-manager

如果不使用systemd系统接管Kubernetes服务的标准输出，则也可以通过日志相关的启动参数来指定日志的存放目录。

  • --logtostderr=false：不输出到stderr。
  • --log-dir=/var/log/kubernetes：日志的存放目录。
  • --alsologtostderr=false：将其设置为true时，表示将日志同时输出到文件和stderr。
  • --v=0：glog的日志级别。
  • --vmodule=gfs*=2,test*=4：glog基于模块的详细日志级别。

在大多数情况下，我们从WARNING和ERROR级别的日志中就能找到问题的成因，但有时还需要排查INFO级别的日志甚至DEBUG级别的详细日志。此外，etcd服务也属于Kubernetes集群的重要组成部分，所以不能忽略它的日志。

如果某个Kubernetes对象存在问题，则可以用这个对象的名字作为关键字搜索Kubernetes的日志来发现和解决问题。在大多数情况下，我们遇到的主要是与Pod对象相关的问题，比如无法创建Pod、Pod启动后就停止或者Pod副本无法增加，等等。此时，可以先确定Pod在哪个节点上，然后登录这个节点，从kubelet的日志中查询该Pod的完整日志，然后进行问题排查。对于与Pod扩容相关或者与RC相关的问题，则很可能在kube-controller-manager及kube-scheduler的日志中找出问题的关键点。

另外，kube-proxy经常被我们忽视，因为即使它意外停止，Pod的状态也是正常的，但会导致某些服务访问异常。这些错误通常与每个节点上的kube-proxy服务有着密切的关系。遇到这些问题时，首先要排查kube-proxy服务的日志，同时排查防火墙服务，要特别留意在防火墙中是否有人为添加的可疑规则。

常见问题

pod 问题

由于无法下载pause镜像导致 Pod 一直处于Pending状态

现象：无法下载pause镜像导致Pod一直处于Pending状态。

解决方法如下：

  • 如果服务器可以访问Internet，并且不希望使用HTTPS的安全机制来访问gcr.io，则可以在Docker Daemon的启动参数中加上--insecure-registry gcr.io，来表示可以匿名下载。
  • 如果Kubernetes集群在内网环境中无法访问gcr.io网站，则可以先通过一台能够访问gcr.io的机器下载pause镜像，将pause镜像导出后，再导入内网的Docker私有镜像库，并在kubelet的启动参数中加上--pod_infra_container_image。

除了pause镜像，其他Docker镜像也可能存在无法下载的情况，与上述情况类似，很可能也是网络配置使得镜像无法下载，解决方法同上。

Pod 创建成功，但RESTARTS数量持续增加

现象：创建一个RC之后，Pod一会儿是Running状态，一会儿是ExitCode:0状态，在READY列中始终无法变成1/1，而且RESTARTS（重启的数量）的数量不断增加。

原因：在Kubernetes中根据RC定义创建Pod，之后启动容器。在容器的启动命令执行完成时，认为该容器的运行已经结束，并且是成功结束（ExitCode=0）的。根据Pod的默认重启策略定义（RestartPolicy=Always），RC将启动这个容器。

解决：新的容器在执行启动命令后仍然会成功结束，之后RC会再次重启该容器，如此往复。其解决方法为将Docker镜像的启动命令设置为一个前台运行的命令。

OOMKilled

原因：Pod 的内存使用超出了 resources.limits 中的限制，被强制杀死。

解决：修改 resources.limits，查看日志排查内存溢出的原因。

Pod 无法删除

原因：可能是某些资源无法被GC，这会导致容器已经 Exited 了，但是 Pod 一直处于 Terminating 状态。

这个问题在网上能搜到很多案例，但大都只是提供了如下的强制清理命令，未分析具体原因：

1
kubectl delete pods <pod> --grace-period=0 --force

Service 问题

通过服务名无法访问服务

在Kubernetes集群中应尽量使用服务名访问正在运行的微服务，但有时会访问失败。由于服务涉及服务名的DNS域名解析、kube-proxy组件的负载分发、后端Pod列表的状态等，所以可通过以下几方面排查问题。

1.查看Service的后端Endpoint是否正常

可以通过kubectl get endpoints <service_name>命令查看某个服务的后端Endpoint列表，如果列表为空，则可能因为：

  • Service的Label Selector与pod的Label不匹配；
  • 后端Pod一直没有达到Ready状态（通过kubectl get pods进一步查看Pod的状态）；
  • Service的targetPort端口号与pod的containerPort不一致等。
2．查看Service的名称能否被正确解析为ClusterIP地址

可以通过在客户端容器中ping <service_name>.<namespace>.svc进行检查，如果能够得到Service的ClusterIP地址，则说明DNS服务能够正确解析Service的名称；如果不能得到Service的ClusterIP地址，则可能是因为Kubernetes集群的DNS服务工作异常。

3．查看kube-proxy的转发规则是否正确

我们可以将kube-proxy服务设置为IPVS或iptables负载分发模式。

对于IPVS负载分发模式，可以通过ipvsadm工具查看Node上的IPVS规则，查看是否正确设置Service ClusterIP的相关规则。

对于iptables负载分发模式，可以通过查看Node上的iptables规则，查看是否正确设置ServiceClusterIP的相关规则。

节点问题

  1. DiskPressure：节点的可用空间不足。（通过df -h 查看，保证可用空间不小于 15%）
  2. The node was low on resource: ephemeral-storage: 同上，节点的存储空间不够了。

网络问题

Ingress/Istio Gateway 返回值

  1. 404：不存在该 Service/Istio Gateway，或者是服务自身返回 404
  2. 500：大概率是服务自身的错误导致 500，小概率是代理（Sidecar/Ingress 等）的错误
  3. 503：服务不可用，有如下几种可能的原因：
    1. Service 对应的 Pods 不存在，endpoints 为空
    2. Service 对应的 Pods 全部都 NotReady，导致endpoints为空
    3. 也有可能是服务自身出错返回的 503
    4. 如果你使用了 envoy sidecar， 503 可能的原因就多了。基本上 sidecar 与主容器通信过程中的任何问题都会使 envoy 返回 503，使客户端重试。
  4. 502：Bad Gateway，通常是由于上游未返回正确的响应导致的，可能的根本原因：
    1. 应用程序未正确处理 SIGTERM 信号，在请求未处理完毕时直接终止了进程。详见 优雅停止（Gracful Shutdown）与 502/504 报错 - K8s 最佳实践
    2. 网络插件 bug
  5. 504：网关请求 upstream 超时，主要有两种可能
    1. 考虑是不是 Ingress Controller 的 IP 列表未更新，将请求代理到了不存在的 ip，导致得不到响应
    2. Service Endpoints 移除不够及时，在 Pod 已经被终止后，仍然有个别请求被路由到了该 Pod，得不到响应导致 504。详见 优雅停止（Gracful Shutdown）与 502/504 报错 - K8s 最佳实践
    3. Pod 响应太慢，代码问题