要分析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 \

--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 status

查看一下etcd目录的大小

默许etcd存储大小为2G，达到2G将不可写入数据。

使用命令etcdctl defrag对数据进行碎片化整理（如果数据量还很小可不执行defrag命令），碎片化过程中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\

defrag

etcd参数优化

如果是etcd频繁选主，或者磁盘读写慢，那执行上面etcdctl命令响应就会很慢，可以尝试优化一下etcd参数：

文件路径：/etc/kubernetes/manifests/etcd.yaml

修改后etcd配置，etcd组件会自动重启。

参数说明：

election-timeout=10000 # 是follower多久没收到心跳要重新选举的时间，单位是毫秒。

heartbeat-interval=1000 # leader发送心跳的间隔时间，单位是毫秒。

etcd默认heartbeat interval是100ms，election timeout是[1000,2000]ms，heartbeat interval一般小于election timeout。

auto-compaction-retention=1 # 保留1个小时历史数据。由于ETCD数据存储多版本数据，随着写入的主键增加历史版本需要定时清理，默认的历史数据是不会清理的，数据达到2G就不能写入，必须要清理压缩历史数据才能继续写入。

quota-backend-bytes=4294967296 # ETCD数据大小，默认是２G，当数据达到２G的时候就不允许写入，必须对历史数据进行清理压缩才能继续写入。这里设置最大数据是4G。一般K8S集群10个节点，100个容器以内都不需要调整，只需要设置auto-compaction-retention定时清理历史数据就够了。

一般来说etcd组件是影响kube-apiserver稳定性和可用性的最大原因，平时可对etcd主机的磁盘读写性能和cpu使用率进行监控，以及对etcd数据进行备份。

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

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

恭喜您！