k8s 開船記：升級為豪華郵輪（高可用叢集）與遇到奇怪故障（dns解析異常）
之前我們搭建的 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），不管怎麼樣，船還得繼續開。