Upgrading Kubernetes to 1.13.X

背景介紹

kubernetes 最近爆出嚴重漏洞 (CVE-2018-1002105)，而且又遇到 v1.13 的釋出，想說剛好是時候安排升級計畫，來關心一下很久沒有更新的 Vishwakarma ，Vishwakarma 為公司 AMIS 及 Maicoin 用來架設 Kubernetes 的開源專案，分為自行架設與 AWS EKS 兩個部分，使用 HashiCorp Terraform 所撰寫而成，這次小弟貢獻的版本 v0.0.11 主要圍繞在自架 Kubernetes 的部分，更詳細介紹可以參考這邊

更新項目

這次主要更新四個部分:

• 將 Kubernetes 從 1.10.5 更新到 v1.13.1
• 把 Kube-DNS 更換成 CoreDNS
• 把 Kubernetes Worker Node 的 AWS ASG 改為使用 Launch Template，並且改採用 Mixed Instance Policy 來實作 Spot Instance 的 Worker Node Group，把有點難用的 Spot Fleet 給換掉XD
• 新增一個 Ignition 讓 Kubernetes 可以支援 Auditing

遭遇問題

野人獻曝一下這次自己把 Kubernetes 升級到 1.13.x 的心得 T_T 感覺不是那麼的輕鬆寫意，希望看到這篇文章的人可以避開我踩到的坑，我主要遇到兩個問題…

1. 因為 1.13.x 的 TaintBasedEvictions 功能預設是開啟的，所以假如有什麼 Pod 是需要在 node 還沒有 ready 就需要啟動的話，請在 Pod 的 toleration 動一下手腳
2. 從官方的升級文件可以得知，必須要整個 Cluster Node 的 kubelet 版本都大於 1.11.x 才可以開始升級到 1.13.x，不然 daemonset 會有問題開不起來，而就算是在所有的 node 都在大於 1.11.x 的情況下升級，還是必須要把 kubelet 重開@@ (這邊有 Kubeadm 的升級做法)，換言之，記得先在 Dev 環境先實驗過再去 Produciton 動手，需要操作得步驟有點多，最好可以先演練一下

解決方法

• 請把一開始就必須要開在 Not Ready Master/Worker Node 的 Pod 加上如下的 Toleration:

...
tolerations:
- operator: "Exists"
...

• 在升級的時候，必須要先把 Kubernetes 升級到全部升級到大於版本 1.11.x，在這邊我是先升級到 1.12.3
• 當版本不一致時，例如有 1.12.3, 1.13.1 同時存在時，這時候 DaemonSet 會遇到 Container 無法開起來的問題，就是你明明看到 Image 拉好了，但卻卡在 ContainerCreating 的狀態，去追 kubelet 的 Log 可以看到 invalid memory address or nil pointer dereference
• 這時候能做的就是重開 kubelet，並且慢慢讓整個 Cluster 的版本趨於一致，我是採用開新的 1.13.1 Worker Node 慢慢替換掉舊的 1.12.3 Worker Node
• 假如有遇到要把 Pod 從舊版本的 Node 趕到新版本的 Node 可以使用 Drain 這個對 System Admin 很方便的 kubectl subcommand
• 等到版本都一致後，之後再 Scale 新的機器時，DeamonSet 就不會遇到問題了，請原諒我沒時間去 Trace 程式碼XD

總結

根據 AWS 新開的 Roadmap Github Repository，AWS EKS 近期將會在多個 Region GA，所以 Vishwakarma 下個版本 v0.0.12 再來弄 AWS EKS了 ！今年就先到這邊了 (嘆)