kubernetes集群删除pod后长时间处于Terminating状态的案例
2021-01-19 18:14
标签：cpu mes stuck 案例 bsp ready 定位 serve 支持 背景： 预生产环境，使用kubeadm部署的HA集群如下。 NAME STATUS ROLES AGE VERSION 现象： 删除pod后，长时间处于Terminating状态，几分钟到十几分钟不等。 使用kubectl delete pod --force --grace-period=0 定位： 1、Terminating慢的定位，看了很多文档，都没有头绪。在网上看到一个疑似的案例，资源使用率较高，导致kubectl在销毁资源的时候被stuck。 2、查看两台宿主机的资源使用，总体资源比较空闲，但是看到etcd的进程cpu大于50%。 推测可能跟etcd的性能或者集群配置更新有关系，于是查看etcd的pod的日志，看到sbfk2test的etcd一直在刷：error "tls: \" 这时我想到自己制作证书的时候，地址写了IP地址A，而etcd是启用了双向认证的，sbfk1test请求sbfk2test的etcd-api时报错client证书问题。 到这里，我就知道自己配置etcd集群的证书是有问题的。 验证： 修改/etc/kubernetes/manifests/etcd.yaml的： --client-cert-auth=true 改为 --client-cert-auth=false --peer-client-cert-auth=true 改为 --peer-client-cert-auth=false 把client的认证改为false，发现两个master的etcd的pod都不报错了，查看进程消耗，发现etcd的cpu使用率小于5%。 解决： 制作新的etcd证书，且该证书支持多域名或ip地址，把kube-apiserver地址、etcd的主机名都加进去。 kubernetes集群删除pod后长时间处于Terminating状态的案例 标签：cpu mes stuck 案例 bsp ready 定位 serve 支持 原文地址：https://www.cnblogs.com/sxusky/p/13332684.html
sbfk1test Ready master 37d v1.15.2
sbfk2test Ready master 37d v1.15.2
sbfk3test Ready
文章标题：kubernetes集群删除pod后长时间处于Terminating状态的案例
文章链接：http://soscw.com/index.php/essay/44177.html