Kubernetes在夯什麼—K8S基礎介紹

Kubernetes在夯什麼—K8S基礎介紹

Kubernetes在夯什麼—K8S基礎介紹

回顧:Part 1 – 容器服務的世代

Part2 – K8S基礎介紹

最夯的「容器管理平台」基礎架構

「Kubernetes」一名取自於希臘原文,意即「掌舵手、船長」,延續Docker容器的海洋系列命名。而經常見到的「K8s」則是將“ubernete”八個字母縮寫為“8”,是現今資訊界常見的縮寫手法。Kubernetes是一個由Google開發並開源的系統,專門用以自動化部屬、彈性擴充及容器應用管理,而在最一開始便針對分散式叢集架構實現這些功能。

在介紹Kubernetes的強大工具及功能之前,建議讀者先認識它的基礎架構。在一座Kubernetes叢集中,主要存在兩種節點角色:「K8s Master」及「K8s Node」。


【圖一】Master節點元件

【圖二】Node節點元件

Masters提供API Server、叢集資源排程、應用部署管理及Etcd資料庫等工作,而Node則是實際在運行容器的工作節點。在架構設計上相對而言,Master較注重高可用性及穩定性,Node較注重運算資源(CPU、RAM、GPU等…)。若對於這兩個角色之間的關係需要初步認識,推薦Julia Evan’s的這篇文章,以手繪漫畫說明各元件基本功能。

那細節就不多說,直接介紹Kubernetes有哪些特性,並能帶來什麼好處吧!

Part 1文末提及,運行容器雖然有數不勝收的優點,但管理容器可以很令人頭痛,尤其是長期且大量管理的情況。Kubernetes就是來解決這一問題的!目前(2018四月)Kubernetes版本已達1.10+,支援各種容器部署模式、自動化服務、容器網路介面及多樣的儲存介面整合。

以下列出Kubernetes的操作功能特性:

1.管理功能特性

(1) 多租戶管理介面(Multi-tenancy)

Kubernetes的多租戶管理以RBAC系統為基礎,管理者可以定義多個系統角色(Cluster Role),各自擁有不同的叢集權限,操作特定的命名空間(namespace)及資源(Resources)。管理者在建立使用者的系統帳戶(context-user)後,透過ClusterRoleBinding資源,將帳戶與單一或複數角色綁定,讓使用者利用帳戶資訊呼叫API時,得以操作相應角色之權限。
例如:管理者建立一命名空間「Dev」、系統角色「dev-user」、「dev-monitor」、系統帳戶「user」及「monitor」,綁定同名角色及帳戶,並生成相應定義檔(kube-config)。

dev-user角色僅能在Dev命名空間部署、監控、管理容器應用,而非其他命名空間(如default、kube-system等);dev-monitor角色則僅能在Dev命名空間監控容器應用。根據管理者發給使用者的kube-config定義檔,使用者在呼叫叢集API時,無論是透過CLI或kube-dashboard,操作權限將因應上述角色定義。

(2) 平台擴充性(Cluster Scalability)

Kubernetes叢集中,以Node為主要運算節點。當使用者的資源需求增加(CPU、RAM、GPU……),而叢集運算資源不足時,維運人員能夠輕易地擴充運算節點。擴充的節點只要能安裝相應版本之Kubernetes元件即可,故無論是硬體規格或作業系統皆相當彈性。維運人員可以因應當下不足的資源,自由配置新的節點設備。

(3) 高可用性管理介面(Master HA)

無論是管理者或使用者,皆需要取得管理節點(Master)的核心服務(API Server、Scheduler……)才能對叢集進行服務部署及管理。而管理節點的核心元件中,Etcd尤為重要。Etcd保存了叢集中所有的網路配置及節點狀態訊息,而部分訊息是由複數個Etcd服務進行投票獲得,故Etcd服務數量(即Master節點數量)須為單數。

本專案規劃採用3台管理節點實現管理介面的高可用性。正常運作期間,Etcd將選舉出1台Master作為Leader,並由該節點提供用戶端API服務。當該節點崩壞,則由另1台Master接手Leader,持續提供用戶端呼叫API。

(4) 多元儲存介面(Storage Classes)

根據使用者的容器應用,不同應用所搭配的資料或檔案儲存系統,可能有各式各樣的偏好。Kubernetes支援多種儲存介面,供容器應用介接。其中包括公有雲儲存服務GCEPersistentDisk、AzureDisk、AWSElasticBlockStore、NFS檔案共享系統,以及軟體定義儲存CephFS、RBD等等……。

在支援多種儲存介面之餘,根據所選的儲存介面,使用者也可以定義該儲存區的讀寫模式,供單一或複數個服務讀寫檔案資料。

更多儲存類型請參考:
https://kubernetes.io/docs/concepts/storage/storage-classes/

(5) 自定義叢集資源(Custom Resource Definitions)

Kubernetes原生的叢集資源包括Pod、Deployment、DaemonSet、StatefulSet等等……。藉由Kubernetes的apiserver-builder,用戶可以自行定義簡單的叢集資源,用自定義的Controller模式部署容器應用。

2.應用功能特性

(1) 滾動式升級(Rolling Update)

Kubernetes自動以纍進方式更新容器,並且同時監控更新程序,避免在更新工作中一次性停擺所有舊版本容器,而造成服務中斷。若更新過程中發現錯誤訊息,Kubernetes也能夠自動回朔容器至更新前的穩定版本。

(2) 應用服務擴展性(Service Scalability)

根據服務需求,管理人員能夠輕鬆設置該服務的自動擴展(Auto Scaling)。在服務負載量超出正常預期時,Kubernetes將即時增加相應的容器應用,大幅減少維運人員面對臨時超載的工作負擔。

(3) 自動化負載平衡(Service Discovery and Load Balancing)

在部署容器應用時,Kubernetes會發配給容器相應的IP位址,並藉Service叢集資源實現負載平衡的工作。使用者將無需自行設計負載平衡的功能架構與機制。

(4) 自動重啟失能服務(Self-healing)

當容器應用出現錯誤訊息並崩潰,Kubernetes能自主利用相同的容器映像檔及部署定義(YAML檔),排程該容器的重啟,以修復服務。若計算節點出錯當機,Kubernetes也能即時在其他計算節點重新部署容器應用,以恢復服務的提供。

(5) 容器網路管理(Network Policy)

Kubernetes支援多種容器網路介面(CNI),並根據選擇的CNI方案,管理人員能夠自行設置網路管理規則,一方面進一步實現容器間相互溝通的管理,也提供網路安全的解決方案。

作為一個擁有如此眾多且強大管理功能、工具的開源專案,不難想像Kubernetes很快地竄紅,同時造成了容器應用的普及性,甚至促成不少企業的技術轉型。不僅如此,除了社群版本(CE)之外,很多軟體大廠也都開發了自己的企業版本(EE),包括以下:

vPublic Cloud Solutions:
•Google Container Engine (GKE)
•Amazon Elastic Container Service (EKS)
•Azure Container Service (AKS)
vCloud Infrastructure Solutions:
•SUSE Container as a Service (CaaS)
•Pivotal Kubernetes Service (PKS)
•IBM Cloud Private (ICP)
vCloud Platform Solutions:
•Rancher
•RedHat OpenShift

上方提及的解決方案(包括CE版本)皆支援正式環境部署。今天我們不細談這些EE解決方案的優缺及應用,不過迎棧科技曾與其中數個方案合作過,相信未來一定有機會與大家做案例分享!

在下期Part 3中,我將用一些範例情境說明今天介紹的功能、優點,對「維運人員(Operation)」及「開發人員(Development)」各自有什麼切身關係,進而討論基本的「DevOps」概念。

閱讀更多:

Part3-Kubernetes在夯什麼—K8s與DevOps
Part4-Kubernetes在夯什麼—建置一座K8s

撰文: 陳逸凡 迎棧科技解決方案架構師