K8S命令kubectl执行响应很慢问题分析与解决

要分析kubectl执行响应很慢的原因，首先要了解kubectl与K8S组件的关系，我们可以简单地梳理如下图的关系：

如果执行kubectl响应慢或者超时，需要查看与kubelet连接的kube-apiserver和etcd组件运行情况。

这里提前说一个结论，命令执行慢，大多情况都与etcd运行状况相关，本文涉及到etcd的操作和优化。

查看Kube-apiserver

1、通过命令查看k8s系统组件的运行情况：

kubectl get pod -n kube-system  # 可能会发现kube-apiserver/controller/schduler组件重启了很多次

2、查看kube-apiserver的运行情况和日志

kubectl describe pod kube-apiserver-xxxx -n kube-system  #执行该命令可能看不出什么异常

kubectl logs -f --tail 100  kube-apiserver-xxxx -n kube-system  #异常原因一般在日志里

注：如果 kube-apiserver未正常运行，kubelet命令是无用的，此时需要使用docker命令替代：

docker ps -a|grep kube-apiserver

docker logs -f --tail 100  【kube-apiserver容器ID】

类似的kube-apiserver日志：

从kube-apiserver日志，可能会发现比较明显的错误原因，常见的错误是连接etcd被拒接或超时，那下一步就是要查看etcd的运行情况了。

还有一种情况是，kube-apiserver没有什么异常日志，就是执行kubelet命令响应比较慢，偶尔卡顿，我们依然要排查etcd。

查看etcd

同样先查看etcd的运行状态和日志

kubectl describe pod etcd-xxxx -n kube-system 

kubectl logs -f --tail 100  etcd-xxxx -n kube-system 

注：如果 kube-apiserver未正常运行，kubelet命令是无用的，此时需要使用docker命令替代：

docker ps -a|grep  etcd

docker logs -f --tail 100  【etcd容器ID】

通过etcd日志，我们可以发现

1、etcd运行异常。需要进一步分析，首先重启etcd，或者重启docker和主机，可以恢复正常。

如果是集群部署，要查看是否是其它的etcd节点停止，无法连接上，则要从etcd集群角度进行etcd集群恢复。

另外，还有可能是etcd的数据损坏了，如果有备份数据，可以进行恢复，没有备份数据，那只能重装k8s。如果是高可用部署，可以简单地删除当前etcd的数据，通过其它节点同步来恢复，具体可参考文章：K8S集群 etcd 异常恢复。

2、etcd频繁选主。

主机cpu使用率太高，影响了etcd运行，这种情况针对cpu利用率高的现象进行解决即可，找到并杀死cpu高的进程，或master节点不要部署业务容器。

另外就是主机的磁盘读写性能差，etcd对磁盘的要求比较高，一般情况要求使用SSD磁盘。如果不能更换磁盘，可以优化一下参数，增加超时和选主的时间，同时设置etcd数据清理参数。

执行etcdctl命令，查看一下etcd或etcd集群的情况。

先把etcdctl 命令从etcd容器里拷出来：

docker ps |grep etcd  #找到etcd容器的ID，比如是bde41e0d3aef

docker cp bde41e0d3aef:/usr/local/bin/etcdctl ./ 

然后查看etcd节点健康情况：

ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \

--cert=/etc/kubernetes/pki/etcd/peer.crt \

--key=/etc/kubernetes/pki/etcd/peer.key \

--endpoints=https://10.200.192.111:2379,https://10.200.192.112:2379,https://10.200.192.113:2379\

--write-out=table endpoint health

或者查看etcd节点状态：

ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \

--cer