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），無論怎麼樣，船還得繼續開。