应用程序故障排查(kubectl)

常见问题

故障诊断

--- 排查Pods的故障

Pod始终处于Pending状态
Pod始终处于Waiting状态
Pod一直崩溃或运行不正常

--- 排查Replication Controllers的故障

--- 排查Services的故障

服务没有端点信息

故障诊断

故障排查的第一步是对故障进行分类。一般来说，应用程序的故障可以分为下面几个方面：

Pods的故障
ReplicationControllers的故障
Services的故障

插入一些比较常用的命令：

Kubectl get nodes:获取所有kubenetes的节点
Kubectl get namespace:获取所有
kubectl –n testnm get svc:获取namesapce为testnm下所有的service
Kubectl –n testnm get pods –o wide: 获取namesapce为testnm下的所有的pod,并可现实pod实例化在哪个kubectl的节点上
Kubectl –n testnm get pods:获取namesapce为testnm下的所有的pod
Kubectl –n testnm logs [podName]:查看pod的日志
Kubectl –n testnm logs –f [podName]:实时查看pod的日志
Kubectl –n testnm describe pod [podName]:查看pod的状态
kubectl -n testnm exec -it [podName] /bin/bash:进入到指定的容器内

排查Pods的故障

检查Pod的问题首先应该了解Pod所处的状况。下面这个命令能够获得Pod当前的状态和近期的事件列表：
$ kubectl describe pods ${POD_NAME}

确认清楚在Pod以及其中每一个容器的状态，是否都处于Runing？通过观察容器的已运行时间判断它是否刚刚才重新启动过？

根据不同的运行状态，用户应该采取不同的调查措施。

注解：

  Name:容器的名称

  Ready：1/1    前1为可用的有多少个，后1为总共多少个

  Status:运行状态（pending，waiting，running…）

  Restarts：重启的次数

  Age：启动的总时间

  Ip:容器的ip地址

  Node：容器在kubenetes的哪个节点上启动

Pod始终处于Pending状态

如果Pod保持在Pending的状态，这意味着它无法被正常的调度到一个节点上。通常来说，这是由于某种系统资源无法满足Pod运行的需求。观察刚才kubectl describe命令的输出内容，其中应该包括了能够判断错误原因的消息。常见的原因有以下这些：

系统没有足够的资源：你也许已经用尽了集群中所有的CPU或内存资源。对于这种情况，你需要清理一些不在需要的Pod，调整它们所需的资源量，或者向集群中增加新的节点。在计算资源文档有更详细的说明。

用户指定了hostPort：通过hostPort用户能够将服务暴露到指定的主机端口上，但这样会限制Pod能够被调度运行的节点。在大多数情况下，hostPort配置都是没有必要的，用户应该采用Service的方式暴露其对外的服务。如果用户确实必须使用hostPort的功能，那么此Pod最多只能部署到和集群节点相同的数目

Pod始终处于Waiting状态

Pod处在Waiting的状态，说明它已经被调度分配到了一个工作节点，然而它无法在那个节点上运行。同样的，在刚才kubectl describe命令的输出内容中，应该包含有更详细的错误信息。最经常导致Pod始终Waiting的原因是无法下载所需的镜像（译者注：由于国内特殊的网络环境，这类问题出现得特别普遍）。用户可以从下面三个方面进行排查：

请确保正确书写了镜像的名称

请检查所需镜像是否已经推送到了仓库中

手工的在节点上运行一次docker pull <镜像名称>检测镜像能否被正确的拉取下来

Pod一直崩溃或运行不正常

首先，查看正在运行容器的日志。

$ kubectl logs

如果容器之前已经崩溃过，通过以下命令可以获得容器前一次运行的日志内容。

$ kubectl logs --previous

此外，还可以使用exec命令在指定的容器中运行任意的调试命令。

$ kubectl exec -c -- <任意命令> <命令参数列表...>

Kubectl –n testnm exec -it [podName] /bin/bash 这条命令可以进入到pod容器中

排查Replication Controllers的故障

Replication Controllers的逻辑十分直白，它的作用只是创建新的Pod副本，仅仅可能出现的错误便是它无法创建正确的Pod，对于这种情况，应该参考上面的『排查Pods的故障』部分进行检查。
也可以使用kubectl describe rc <控制器名称>来显示与指定Replication Controllers相关的事件信息。

排查Services的故障

Service为一系列后端Pod提供负载均衡的功能。有些十分常见的故障都可能导致Service无法正常工作，以下将提供对调试Service相关问题的参考。

首先，检查Service连接的服务提供端点（endpoint），对于任意一个Service对象，apiserver都会为其创建一个端点资源（译者注：即提供服务的IP地址和端口号）。

这个命令可以查看到Service的端口资源：

$ kubectl get endpoints 
$ Kubectl –n testnm get pods –o wide
$ Kubectl –n testnm get endpoints [podName]

请检查这个命令输出端点信息中的端口号与实际容器提供服务的端口号是否一致。例如，如果你的Service使用了三个Nginx容器的副本（replicas），这个命令应该输出三个不同的IP地址的端点信息。

服务没有端点信息

如果刚刚的命令显示Service没有端点信息，请尝试通过Service的选择器找到具有相应标签的所有Pod。假设你的Service描述选择器内容如下：

Kubectl –n testnm describe svc [svcName]

公共应用技术部-内部 > kubectl 常见问题排查方法 > image2019-1-23_9-48-5.png

可以使用以下命令找出相应的Pod：

$ kubectl get pods --selector=name=nginx,type=frontend

找到了符合标签的Pod后，首先确认这些被选中的Pod是正确，有无错选、漏选的情况。

如果被选中的Pod没有问题，则问题很可能出在这些Pod暴露的端口没有被正确的配置好。要是一个Service指定了containerPort，但被选中的Pod并没有在配置中列出相应的端口，它们就不会出现在端点列表中。

请确保所用Pod的containerPort与Service的containerPort配置信息是一致的。

应用程序故障排查(kubectl)