一般升版執行流程:
- 先升級Control Plane Node
- 才升Work Nodes
1.當升級Control Plane Node時:
- 亦即Control Plane(Master Node)功能將暫停
- 但是這不表示已經運行於Worker Nodes上的Pods會停止運作
- 也就是Worker Nodes上既有的Pods(含裡面的應用程式)會持續運作
- 但是過程中因為缺少API Server,將無法新增或刪除K8s元件
- 並且若Worker Nodes上的某個Pod運行中斷而結束
- 由於沒有Master Node的Controller Manager與Scheduler的指揮
- 中斷結束的Pod將不會自動重建
考量到今天有複數個Control Plane Nodes的狀況:
- 執行升級的方式將會是ONE BY ONE:
Control Plane Components & its versions:
- 在做Control Plane Node版本升級時,其實就是針對其運行元件升級,如以下
- kube-apiserver(v1.20.1)
- kube-scheduler(v1.20.1)
- kube-proxy(v1.20.1)
- controller-manager(v1.20.1)
- kubelet(v1.20.1)
- kubectl(v1.20.1)
以上運行元件都會是同一個版本
另外可能尚有:
- etcd(可能v3.4.0,但是這個將由kubeadm安裝)
- coredns(可能v1.7.0,但是這個將由kubeadm安裝)
- weave-net(可能v2.2.14,另外安裝)
綜上所述,當提到Control Plane Node升級即代表:
- 如上圖示,雖然weave是裝在一起,但是升級時weave並不一起執行
- 並且針對藍色框相同版本的元件部分,是否一定要維持同一版!?
- 亦即藍色框相同版本的元件部分是否可以分別升即?甚至保持不同版本?
- 答案如下圖:
- 如上圖內說明,i.e. 這些運行元件使用不同版本其實是允許的!
- 另外上圖省略的kubectl元件部分
- 由於是直接跟API-Server溝通的Client端元件
- 所以kubectl元件版本相對於API-Server可以允許新或舊一版或同版
- 為了維運方便,或比較通常情況下
- 一般都會將上述運行元件維持同版本
- 並且也比較方便安裝
如何升級上述各種運行元件?
- 如同建置過程使用kubeadm執行init來完成一樣
- K8s升級也將使用kubeadm來做升級
- 並且透過kubeadm升級將會把上述各種元件盡量維持同一版本!
- 也就是說,升級上述元件前,其實要先把kubeadm軟體進行升級!
- 當kubeadm軟體完成升級後,即可執行類似如下指令,進行"部分"元件升級:
kubeadm upgrade apply 1.21.0
- 上述指令連同前面圖中不同版的etcd,coredns元件也會一併升級對應版本
- 並且注意!過程還會執行憑證(Cluster certificates)更新!!!
- 但是也僅僅是將Pod型式的元件完成升級而已
- 我們還有另外的非Pod軟體(kubelet與kubectl)要另外升級
- 亦即kubelet與kubectl要分開升級
kubelet與kubectl分開升級:
- 先考慮到kubelet,該元件是控制安排Node上運行的Pod
- 所以在執行kubelet升級前要先把該Node上的Pod清除
- 亦即將Node轉為Maintain Mode(維護狀態),該動作又稱drain node,如下:
kubectl drain master
- 也就是Node內的Pods會被安全地移除(evict)
- 並且Node將被註記為"unschedulable",也就是不能起新的Pod
- (下篇demo筆記會看到)
- 此時才分別將kubelet與kubectl分別升級
- 接著才恢復Node的狀態註記調整回為"schedulable",例如執行:
kubectl uncordon master
- 此時才真的完成master的升級(該升級的運行元件都完成升級!)
如何升級Worker Nodes?
- 完成master node升級後,接著就是執行worker node的升級
- 過程也是一台台輪流完成,順序如下
- 1.依樣先升級kubeadm
- 2.驅動升級後的kubeadm來升級kubelet的設定
- 3.執行drain node(暫時排除所有Pod)
- 此時上面的Pod會被deployment等機制重建到其他Worker Node
- 4.趕緊升級kubelet
- 5.回復Node的狀態註記調整回為"schedulable"
- 以上流程即完成一台worker node該做的升級動作!!
- 並且過程中只要有兩台以上worker node,並且定義Pod至少兩個Replica
- 就可以實現無downTime了!!!
關於上面講述的Draining Node:
- 例如執行以下指令:
kubectl drain worker1
- 上述指令效果是,將該node註記為"unschedulable"
- 並(Evict)排除上面既有的Pods
- 但是還有一種指令只單純做該node註記為”unschedulable”,如下執行:
kubectl cordon worker1
- 上述指令並不會排除既有的Pods
- 原則上就是做一些不用動到運行中的Pod的處理才用
- 接著就是上面有提到的恢復Node狀態的指令,執行:
kubectl uncordon worker1
- 將Node狀態恢復為"schedulable"
- 通常就是升即作業完成後就可以做了!!
何時該執行升級(升級頻率)?
- 考量到若有運行上的問題,若新版有修正,即當執行升即
- 並且普遍來說都應該將K8s Cluster保持在最新版本
- 假設目前有K8s Cluster版本v1.18,由於運作需求大,沒空升級
- 但是當下已經出到v1.21版
- Kubernetes官方僅會支援近三代的版本(如下圖)
- 也就是此時v1.18已經不支援了!
- 此時能夠直接將自己的K8s Cluster v1.18直接升級v1.21嗎?
→NO! 沒辦法這樣升
- 升級過程只能一版一版進行,i.e. 先升級到v1.19,才到v1.20最後v1.21
