代管式 Kubernetes 介紹 – GKE:比 K8s 更好用的 DevOps 工具

代管式 Kubernetes 介紹 – GKE:比 K8s 更好用的 DevOps 工具

Google Kubernetes Engine(GKE)是雲端版的代管式 Kubernetes(K8s)。K8s 本身是一項功能強大的 DevOps 工具,那具備「雲端」和「代管」2大特質的 GKE 有什麼優於 K8s 的地方呢?一起來了解吧!

受 COVID-19 疫情影響,許多企業開始重視內部流程的改善與自動化技術,而遠程工作的增加,也讓團隊或部門間的協作成為焦點,以上這些因素都讓 DevOps 成為許多企業關注的議題。其中,K8s 是一個實現 DevOps 的強大工具,但實際搭建環境時因受限於地端環境,難免會碰到諸多不便。例如設備的限制、維護與服務的串接等,而這些不足之處在 Google Cloud 代管的 K8s,也就是 GKE 上都能輕鬆被解決!一起認識這項工具的特色與優勢,還有它能如何搭配 Google Cloud 上的其他工具,建立出更方便好用的 DevOps 實踐架構吧。

延伸閱讀:
DevOps 是什麼?Google 實作 DevOps 的 SRE 方法介紹

代管式 Kubernetes 介紹:Google Kubernetes Engine(GKE)

GKE 的三大特色

GKE 是由 Google Cloud 提供的雲端版代管式 K8s,架構上雖與 K8s 大同小異,但在實際使用上還是有許多區別,以下我們分別從資源調度、安全性與軟硬體設置這三個面向來了解它的特色。

代管式 Kubernetes 介紹 - GKE 三大特色

資源調度

GKE 可依據 CPU 與資源使用率等指標自動調度 Pod 資源與 Node pool 中的 Node 數量,而在分析資源用量上還可透過垂直自動調度 Pod 功能(Vertical Pod Autoscaling),持續分析 Pod 的 CPU 和記憶體用量,以自動調整 CPU 和記憶體要求。最重要的是在資源不足的情況下,GKE 可向上擴充至 15,000 個 Node,等需求下降後也能自動刪減,避免造成多餘的開銷。

安全性

接著在安全性服務上主要可分為三類,包含身分識別、網路安全與應用程式安全。首先在身分識別這塊,GKE 除具備專案層級的使用者身份識別(IAM),也有 Cluster 層級的 Role-Based Access Control(RABC) 可限制使用者的權限。而在網路安全面則有專案層級的 VPC Firewall 和 Cluster 層級的 Private Cluster Mode 與 Network Policy。最後在應用程式安全上則支援映像檔的弱點掃描、應用程式部署時的雙重認證,及第三方應用程式或不受信任的程式碼部署時的 GKE SandBox 等。

軟硬體設置

而在軟硬體設置上 GKE 也提供了諸多功能,以下介紹四項主要功能。第一,GKE 會檢測 Node 的健康狀態,一但有 Node 出問題就會觸發自動修復來確保所有的 Node 能正常運行。第二是每當 Kubernetes 發布新版本,GKE 會自動更新至最新版。第三是 GKE 可在配置時限制每個容器的所需資源,更妥善地管理 Cluster 內的資源消耗。第四,GKE 預設使用由 Google Cloud 打造及管理的 Container-Optimized OS,該系統具有經過強化的安全防護能力。

延伸閱讀:
【K8s 是什麼】比較 Docker 容器、K8s 和 GKE 的架構與優勢

GKE 相較於 K8s 的優勢

在了解完 GKE 的主要特色後,下面我們進一步來認識使用 GKE 和自建 K8s 相比有哪些優勢吧!這部分我們分別從雲端與地端、代管及自建這兩個面向來分析之間的差異。

雲地差異

  1. 設備規格

在雲端上,使用者除可依據需求調整要使用的機器規格,還能根據使用量調整機器的數量。而在地端我們只能使用自行購買的機器,當使用量超出或遠低於當前所擁有的機器承受能力時,就需負擔額外的損失。

  1. 設備維護

在雲端上所有設備都是由雲端供應商維護,使用者不需擔心設備的損壞或折舊。相較之下,地端所有的設備都需自行維護,一但碰上人為疏失或自然災害就可能造成設備的損壞甚至是資料的丟失。

  1. 權限控管

在雲端上使用 GKE,基本權限的控管都可以經由 IAM 結合 RABC 來操作。而在地端,由於多數原生 K8s 使用的服務都是開源的,因此不同服務的權限可能都需各自管理,進而增加權限管理的複雜度。

代管與自建的差異

  1. 軟體的安裝與更新

在雲端代管的環境裡,基礎的 K8s 工具是由雲端供應商負責安裝與更新的,因此在創建 GKE Cluster 的同時,系統會直接在5分鐘內配置好基礎的 K8s。相較之下自建 K8s 的初始配置工作就複雜許多,從最初的 Node、PKI 再到 etcd,繁雜的設置步驟多達十幾步,且每個步驟內要設置的東西又高達十幾種,要讓 K8s 真正能運作基本上得花一兩天的時間。

  1. 服務的串接

雲端代管的另一大特色,就是實行 DevOps 的需求基本上可靠 GKE 串接 Google Cloud 的其他服務一次滿足,包含 CI/CD 工具、監控工具、映像庫、代碼庫和大數據分析等。且如上所述,這些服務都能簡單利用 IAM 執行權限控管,而對於自建的 K8s 來說,所有額外的服務都必須透過其他設置來串接與維護。

  1. 額外的服務

雲端代管的另一個優點是部分 GKE 的組件會由雲端供應商來維護,例如 Cluster 中的 Control Plane。因此操作時我們只需關注 Worker Node 的設置即可,不需煩惱 Master Node 的設置。此外 GKE 還有獨特的 Node Pool 功能,可歸類不同性能的機器,在部署不同性質的應用程式時可以指定合適的 Node Pool 進行部署。最後,Node Pool 甚至還具備 Autosacling 功能,透過監測部署容器的資源使用量,可自動創建合適的 Node Pool。

代管式 Kubernetes 介紹 - GKE 優勢

GKE 為何是優秀的 DevOps 工具?

前段我們分析了許多 GKE 在不同面向上比 K8s 更好使用的特點,但要應用在 DevOps 實踐上,光有前面的那些優勢是不夠的!所以在詳細介紹 GKE 可搭配 Google Cloud 上的哪些服務更有效率地實踐 DevOps 前,先來了解它如何滿足 DevOps 的原則吧。

減少組織間的穀倉效應

在 GKE 環境中,所有的設定如機器、容器、服務與權限管理,都可以用 Yaml 檔進行操作,使部署的框架與流程統一且透明。哪些部門對什麼物件進行了怎樣的配置,透過 Yaml 檔都能一覽無遺。這一方面確定了權責的劃分,另一方面也避免了過往不同部署與管理方式所造成的部門間隔閡。

圖片來源:freepik

持續改善

前文有提到 GKE 是基於 Docker 容器的管理工具,藉由容器化技術在 GKE 中運行的應用程式是經過解耦的(應用程式被拆分成多個不同功能的模組),也就是微服務的概念。輕量化應用程式以提高部署效率的同時,也能針對不同模組進行細部的更新迭代與除錯,解決了以往一體式應用程式牽一髮動全身的缺陷。另外透過 GKE 與 Google Cloud 的串接,所有發布的應用程式版本都會被保存下來,若新版本出現問題,也能立即退回可正常運行的舊版。

任何事情都可被量測

有賴於 GKE 帶來一致性的開發環境, 在與 Google Cloud 串接後整體的運作流程都是清楚且透明的。從前期的應用程式編寫到測試再到部署維運,所有步驟都有各自的服務能保存紀錄,在發生問題時能夠快速找到發生問題的節點,進一步進行故障排除。

應用 GKE 和其他 Google Cloud 工具的 DevOps 實踐架構

透過上文我們已清楚了解 GKE 有許多勝過 K8s 的優勢和滿足 DevOps 原則的特點,但在雲端上,究竟要如何以 GKE 取代 K8s,規劃出一套省時省力的 DevOps 實踐架構呢?一起透過下方的架構圖了解 Google Cloud 上有哪些工具,可搭配 GKE 讓實踐 DevOps 變得更輕鬆簡單吧!

CI/CD 工具

CI/CD 工具是實踐 DevOps 不可或缺的一環,因為它的概念就是要自動化軟體交付與架構變更,讓構建、測試與軟體發布能更敏捷、頻繁且可靠。以下依序簡介四種 Google Cloud 服務如何作為 CI/CD 工具被應用在上圖的架構中。

Cloud Source Repository

首先,Cloud Source Repository 是 Google Cloud 提供的原始碼管理庫,功能與 GitHub 相似,是利於多人協作開發的代碼庫,可用來儲存與同步多個開發人員的程式碼更動。

Cloud Build

Cloud Build 是 Google Cloud 提供的無伺服器 CI/CD 服務,能夠支援各種程式設計語言版本的應用程式。主要的運作模式是透過設定觸發器(Trigger)來監控目標代碼庫(Repository),並根據代碼庫的更動來進行創建、保存與部署 Image 等行為。

圖片來源:pixabay

Artifact Registry

Artifact Registry 的功能是儲存容器要使用的 Image。上述提到 Cloud Build 在偵測到 Source Repository 更新後會自動創建 Image,而這個 Image 就會被存到指定的 Artifact Registry,且每次創建都會留下對應的版本,確保部署新功能導致服務出現問題時能快速退回上一個可正常運行的版本。

Cloud Deploy

Cloud Deploy 是全代管式的 CD 工具,與 Cloud Build 不同的是其主要功能在於建立不同 Cluster 間的 CD Pipeline。透過 Pipeline,正式部屬前我們可先在測試用的 Cluster 確認新服務的運行狀態,當服務順利運行後再推送到用於實際生產環境的 Cluster。

維運監控工具

CI/CD 工具提供的是自動化的整合與部署,但在這之上還須加入維運與監控才是完整的 DevOps,而 Google Cloud 上就有 Cloud Operation Tools 這一系列的維運監控工具,一起來認識當中的具體功能吧。

Cloud Operation Tools

Cloud Operation Tools 在創建 GKE 時會自動被啟用,而其中最主要的工具是 Cloud MointoringCloud Logging。Cloud Monitoring 提供了客製化的指標,使用者可根據需求設置對應的指標來創建 Dashbroad 以進行監控,且能針對各個指標設置對應的閾值,一旦超出範圍就會發出警告。而 Cloud Logging 則保留了所有操作紀錄,讓我們除了發生錯誤時可透過 Log 排除故障,也能針對特定 Log 設置警告,讓相同錯誤發生時能快速收到相關消息。

結論

透過上面的介紹,相信大家已經明白為什麼 GKE 與各類 Google Cloud 服務的結合,能更有效率地實踐 DevOps。GKE 在具備 K8s 功能的同時又兼具雲端的優勢,讓使用者在設備與服務的選擇上有了更多的彈性,另外在維護與管理面的負擔也大幅降低,有效彌補了過往以 K8s 實踐 DevOps 的不足之處。

以上就是 Google Kubernetes Engine 的介紹,與以它為基礎的 DevOps 實踐架構分享。大家對文中內容有任何問題都可留言詢問,如想更了解如何應用 DevOps 實現數位轉型,歡迎參考 DevOps 解決方案。最後,想更認識 Google Cloud 或有技術服務相關需求,也都歡迎聯絡我們獲得更進一步的資訊。

延伸閱讀:

【Google Cloud K8s 教學】第一次用 GKE 就上手
GKE Autopilot 教學―輕鬆管理 K8s,加快軟體開發流程
[DevOps實作] 使用 Google Cloud 全代管服務達成 CI/CD
[DevOps實作] GitLab 部署 asp.Net Core 到 Kubernetes Engine 達成 CI/CD

Cloud Ace 研討會主頁

發佈留言