之前我们搭建的 k8s 集群只用了1台 master ，可用性不高，这两天开始搭建高可用集群，但由于之前用 kubeadm 命令创建集群时没有使用 --control-plane-endpoint 参数，无法直接升级现有集群，只能重新创建高可用（High-Availability）集群。
高可用集群的原理很简单，多台 master ，每台都保存集群数据（etcd），所有 nodes 通过专门搭建的负载均衡访问 api server ，这样当部分 master 宕机时，对集群正常运行无影响。
我们用了 3 台 master ，但是在第 1 台 master 服务器开始创建高可用的集群时，遇到了一个做梦也没想到的问题。
kubeadm init --kubernetes-version v1.16.3 --control-plane-endpoint "k8s-api:6443" --upload-certs --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=192.168.0.0/16 --v=6
为了省事，我们没有自己另外部署负载均衡，而是直接使用了阿里云内网负载均衡（ 四层 tcp 转发），在 master 的 hosts 中将上面的 k8s-api 解析到阿里云负载均衡的 IP 。
但是创建集群总是失败，错误信息如下
[kubelet-check] Initial timeout of 40s passed. I1217 08:39:21.852678 20972 round_trippers.go:443] GET https://k8s-api:6443/healthz?timeout=32s in 30000 milliseconds
排查后发现是因为阿里云四层负载均衡不支持转发请求给同一台服务器，也就是发请求的服务器与转发的后端服务器不能是同一台服务器。
后来我们采用了一个变通的方法解决了问题，在 master 服务器上不将 k8s-api 解析到负载均衡的 IP ，而是解析到 master 自己的 IP ，只在 nodes 上解析到负载均衡 IP 。
当我们搭建好高可用集群，还没来得及享受高上大的豪华邮轮，就遭遇一个奇怪的 dns 解析问题。在容器内解析主机名时速度很慢，有时解析成功，有时解析失败，不管是 k8s 的 service 名称，还是手工添加的 dns 解析记录，还是阿里云的 redis 服务，都有这个问题。dns 解析服务用的是 coredns ，pod 网络用的是 calico 。当时集群中有 3 台 maste 与 1 台 node ，开始以为是 k8s 网络的问题， 搭建这个集群时开始用的是 flannel 网络，后来改为 calico ，但折腾很长时间都无济于事，昨天晚上为此精疲力尽，一气之下在睡觉之前将集群中的所有服务器都关机。
今天开机后，又遇到了一个做梦也没想到的事情，问题竟然神奇的消失了，本以为这只是升级豪华邮轮过程中的一个小插曲。
今天下班前，又又遇到了一个做梦也没想到的事情，线上在用的之前搭建的只有 1 台 master 的非高可用集群中部分 nodes 也出现了同样的 dns 解析问题（用的是 flannel 网络），根据刚刚学到的经久不衰的绝招，将出现问题的 nodes 重启，问题立马消失。
2个不同的集群，使用的是不同的 pod 网络，而且使用的是不同的网络地址段（分别是 192.168.0.0/16 与 10.244.0.0/16），竟然出现了同样的 dns 解析问题，而且都通过重启可以解决，这个诡异的问题给我们的开船记出了一道难题。
但是由俭入奢易，由奢入俭难，豪华邮轮已经准备好了，我们再也不想开渔船了（docke swarm），不管怎么样，船还得继续开。
原文地址：https://www.cnblogs.com/cmt/p/12061089.html