如何解决kubectl指令返回慢的问题

卡亦克

于 2024-07-29 10:13:00 发布

阅读量442

点赞数 4

文章标签： docker kubernetes 容器

本文链接：https://blog.csdn.net/caryeko/article/details/140764184

版权

一、问题是怎么发现的

近期在预发环境排查问题的时候，使用kubectl指令查询k8s管理的JOB、POD时，kubectl指令总是返回的特别慢，原本秒回的指令，要等7-8秒才有反应。

二、问题带来的影响

影响排查问题的效率，影响工作心情。

三、排查问题的详细过程

1、首先查看了各个节点状态

kubectl describe node master01
 DiskPressure True Fri, 19 Jul 2024 15:34:57 +0800 Sat, 13 Jul 2024 12:52:38 +0800 KubeletHasDiskPressure kubelet has disk pressure

发现Master节点有【 kubelet has disk pressure 】磁盘压力过大的告警，然后通过[docker system prune ]清理了无效的docker镜像。

2、清理无效docker镜像

    [root@master01 ~]# docker system prune 
    WARNING! This will remove: 
     - all stopped containers 
      - all networks not used by at least one container 
       - all dangling images 
        - all dangling build cache 
         
         Are you sure you want to continue? [y/N] y 
         Deleted Containers: 
         09b3ff5ab50054be69f489c13bd267039d6af01905b7be1cfc9639c313e731cf 
         7173d41ccb3f41b563f966eff6c94249505463e0622401781b606fa8fc1f4642 
         7eab1a29fcb7db5e8ef782453a3b3c66fa7d360937e509da4615031e12f7b895 
         ……
         Total reclaimed space: 41.91GB

3、继续查询Master节点状态，发现依旧还是报警磁盘压力，继续通过 lsblk 和 df -h排查磁盘使用情况，一层层文件夹分析，最终找到了/root目录下有个导出的.tar镜像文件，把镜像文件转移到/export目录，磁盘压力的问题解决了。

4、但kubectl命令返回依然很慢，继续通过查看kube-system命名空间下的pod状态。

[root@master01 ~]# kubectl get pod -n kube-system 
 
 NAME READY STATUS RESTARTS AGE 
 coredns-558bd4d5db-6t2tf 1/1 Running 19 480d 
 coredns-558bd4d5db-g9fpb 1/1 Running 17 480d 
 etcd-master01 1/1 Running 10 507d 
 kube-apiserver-master01 1/1 Running 44 507d 
 kube-controller-manager-master01 1/1 Running 120 553d 
 kube-proxy-ctql6 1/1 Running 3 308d 
 kube-proxy-hn58m 1/1 Running 1 553d 
 kube-proxy-sj4s9 1/1 Running 7 548d 
 kube-proxy-v9hl8 1/1 Running 0 65d 
 kube-proxy-zxjvh 1/1 Running 8 552d 
 kube-scheduler-master01 1/1 Running 115 507d 
 metrics-server-755b6f84d4-tt6jj 1/1 Running 2 77d 
 nvidia-device-plugin-daemonset-sfcvs 1/1 Running 2 307d 
 nvidia-device-plugin-daemonset-zg8g5 1/1 Running 0 65d 
 nvidia-device-plugin-daemonset-zhrhq 1/1 Running 3 463d 
 nvidia-device-plugin-daemonset-zkkrm 1/1 Running 45 442d

发现有重启次数较多的几个pod,然后逐一查看pod日志。

kubectl logs -f --tail 100 kube-controller-manager-master01 -n kube-system 
关键日志：
1 resource_quota_controller.go:409] unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request, projectcalico.org/v3: the server is currently unable to handle the request 



kubectl logs -f --tail 100 kube-apiserver-master01 -n kube-system 
关键日志：
controller.go:116] loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: failed to retrieve openAPI spec, http error: ResponseCode: 503, Body: error trying to reach service: dial tcp 10.110.98.31:443: i/o timeout

发现了明确的错误信息[http error: ResponseCode: 503]和重点关键词[v1beta1.metrics.k8s.io]，继续往下排查。

5、百度关键词[v1beta1.metrics.k8s.io]。

kube-apiserver不规律报loading OpenAPI spec for “v1beta1.metrics.k8s.io“ failed with: failed to retrieve_loading openapi spec for "v3.projectcalico.org" fa-CSDN博客

似乎已经找到了解决方案，接下来按照帖子的指引，尝试配置 apiserver配置文件 [–enable-aggregator-routing=true]

四、如何解决问题

修改k8s的apiserver配置文件，保存配置文件，等待服务自动重启~

vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec: 
 containers: 
 - command: 
 - --enable-aggregator-routing=true # 修 复 v1beta1.metrics.k8s.io 503

重启完毕，尝试执行kubectl命令，发现问题已经解决了，kubectl指令终于秒回了，再也不用忍耐那痛苦的等待了~