背景：
预生产环境，使用kubeadm部署的HA集群如下。
NAME STATUS ROLES AGE VERSION
sbfk1test Ready master 37d v1.15.2
sbfk2test Ready master 37d v1.15.2
sbfk3test Ready <none> 37d v1.15.2
现象：
删除pod后，长时间处于Terminating状态，几分钟到十几分钟不等。
使用kubectl delete pod --force --grace-period=0 <PODNAME>来强制删除。
定位：
1、Terminating慢的定位，看了很多文档，都没有头绪。在网上看到一个疑似的案例，资源使用率较高，导致kubectl在销毁资源的时候被stuck。
2、查看两台宿主机的资源使用，总体资源比较空闲，但是看到etcd的进程cpu大于50%。
推测可能跟etcd的性能或者集群配置更新有关系，于是查看etcd的pod的日志，看到sbfk2test的etcd一直在刷：error "tls: \"<IP地址A>\" does not match any of DNSNames [\"sbfk1test\" \"localhost\"]
这时我想到自己制作证书的时候，地址写了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的主机名都加进去。