iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 4
0

本文同步刊登於 k2r2bai.com Blog。

前言

近幾年來容器的興起,重塑了我們對於開發、部署與維運軟體的方式。容器允許我們透過打包應用程式成容器映像檔,並透過容器引擎部署到一組虛擬或實體的機器上執行。也正因為這樣過程與需求,產生了所謂的容器編排系統(Container Orchestration),以自動化、基於容器應用程式的方式部署、管理與擴展。其中 Kubernetes 就是近年來的一套容器編排系統標準,它能允許大規模部署與管理基於容器的應用程式,而 Kubernetes 的特性還能實現分散式的應用程式,以帶來更高的可靠性與穩定性。但是,當 Kubernetes 重要元件或是其主節點(Master Node)發生故障時,那 Kubernetes 會發生什麼事呢?又該如何確保 Kubernetes 本身保持正常運行呢?

前幾天分享部署工具章節,可以了解在生產環境中,部署一座高可靠(HA, Highly Available)架構的 Kubernetes 是非常重要的一件事。因為當服務在一座非高可靠的 Kubernetes 叢集上執行時,發生了節點故障的話,將會造成正在執行的服務受影響,嚴重甚至中斷整個服務的運行,除此之外還可能發生 Kubernetes 叢集狀態不一致、叢集功能全失效等等問題,既而造成維運人員負擔,以及造成公司損失。

也正因此,今天想針對 Kubernetes 高可靠架構進行探討,希望帶大家了解 Kubernetes 高可靠架構如何規劃與實現。

高可靠架構

在開始談 Kubernetes 高可靠架構時,我們先來複習 Kubernetes 的節點角色,以及其元件:

  • 主節點(Master node): 該節點主要運行 Kubernetes 的控制平面元件,如: kube-apiserver、kube-controller-manager、kube-scheduler、kubelet 與容器 runtime 等等元件,目的是用於維護整個 Kubernetes 的運作,從接收 API 請求、容器排程、執行容器等等事情。另外根據架構不同還有可能運行 etcd 作為整個叢集狀態儲存用,這表示任何 Kubernetes 的 API resources 都會被儲存至 etcd 中。

事實上,目前架構中主節點也被視為工作節點,但預設會透過一些機制來確保容器不會被排程到這些節點。

Kubernetes Master

  • 節點(Node): 又稱 Worker node 或 Minion node,該節點主要運行 kubelet、容器 runtime 等等。主要被用於執行應用程式容器,會定期與主節點回報目前節點資訊。

Kubernetes Node

而 Kubernetes 的高可靠旨在使用一種沒有單點故障(SPOF, Single Point of Failure)的方式,設定與建構 Kubernetes 元件與支援的元件(etcd)。當使用單一主節點叢集時,很容易因為節點或元件發生錯誤,導致叢集故障; 而多主節點叢集則可以利用每個主節點元件來存取相同的工作節點,因此能更提升叢集的穩定性與可靠性。

在單個主叢集中,kube-apiserver 與 kube-controller-manager 等等重要元件都僅在單一節點上,如果故障的話,則無法建立或執行 Kubernetes 的功能。但在 Kubernetes HA 架構中,這些重要元件會在多個節點各執行一組(通常最小為 3 個主節點),因此有主節點故障時,就會有正常的主節點來確保叢集的運作。其架構如下圖所示:

Kubernetes HA
(圖片擷取自:kubernetes.io)

而在 Kubernetes HA 的架構實現中,etcd 會根據需求有不同的拓樸架構,分別為:

  • Stacked etcd topology: 該拓樸是將 etcd 連同 Kubernetes 控制平面放同一個節點上。這時 etcd 可能會透過 kubelet 以 Static Pod 方式來管理,或者以作業系統的背景行程管理機制進行(如 Linux systemd)。雖然這種架構只需要最少三台就能達到 HA,但由於放一起,所以故障域不會分離。


(圖片擷取自:kubernetes.io)

  • External etcd topology: 該拓樸是讓 kube-apiserver 存取外部的 etcd 叢集,這種架構將叢集資料儲存系統與叢集功能系統做分離,因此可靠性比 Stacked etcd 架構來的好些,不會因為一個節點故障,而同時影響到 Kubernetes 控制平面與 etcd。相反的,這種架構需要更多的機器來支撐。


(圖片擷取自:kubernetes.io)

結語

今天主要再次複習 Kubernetes HA 架構是如何實現的,因為在 On-Premise(Custom) Kubernetes 中,不像公有雲服務會幫你管理主節點的元件,因此適當地了解對於部署 On-Premise(Custom) Kubernetes 有很多幫助,也可以再發生問題時,更快的知道問題點在哪裡。

而除了今天提到的事情外,究竟建立 HA 架構還有什麼好處呢?

  • 透過負載平衡器來分散 Kubernetes API server 的負載。
  • Kubernetes 狀態資料的故障轉移(etcd)。
  • 在 Multi-zones 中執行,確保跨不同故障域(Failure domains)。
  • 實現安全地更新 Kubernetes 叢集元件。

更新 Kubernetes 叢集元件部分,在之後文章我也會說明如何進行,並需要注意哪些事情,以確保更新版本時不會出太大錯誤。

最後明天我們將實際利用工具來建立一套 Kubernetes HA 架構的環境,並在過程中說明如何做最佳實踐,一但完成後,也將嘗試驗證功能。

Reference


上一篇
[Day3] 淺談 Kubernetes 的部署工具選擇 Part3
下一篇
[Day5] 實現 Kubernetes 高可靠架構部署
系列文
其實我真的沒想過要利用研替剩餘的 30 天分享那些年 On-premise Container & Kubernetes 經驗30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言