Google Cloud Anthos 混合雲平台，一窺GCP提供全球化服務的秘訣！

Google Cloud Anthos 技術摘要

從基礎架構、資料庫與資料管理，接著便是談到應用程式現代化。這幾年 Kubernetes (K8S) 已成為顯學，GKE 則是由 GCP 代管的 Kubernetes 服務，而 Anthos 則是以 GKE 為基礎由 Google Cloud 發展出來管理混合雲、多雲的應用服務。整合 Istio 與 Anthos Service Mesh（ASM），Anthos 簡化複雜的設定與管理工作，建構可擴展全球的服務。同時也將提到如何透過 SLO monitoring 及 Cloud monitoring 監管 GCP 上的服務。

GOOGLE ANTHOS － 管理混合雲、多雲及擴展全球化的應用程式管理平台

許多企業在跨出海外後需部署全球化服務，他們都很好奇 Google 是以何種架構提供全球 15 億人使用 Gmail 服務，以下便是 Google 在 Kubernetes Engine 上架構多個叢集（Nodes）、跨區域平台來提供全球化分散式服務的方式。分散式服務讓多個 Pod 跑在不同區域的不同叢集上，即使有Pod 壞掉，服務仍然不會中斷。除了多叢集外，需要透過服務網格（Service Mesh）將商業邏輯容器與網路功能容器切開，如此一來商業邏輯容器能更輕量化，而底層的網路功能容器也就是 Envoy proxy 則可做到更自動化、擴充性高及更安全。（如圖1）

所以實際在 GCP 上建構全球化服務的 App 平台，首先需要建置共享 VPC，所有專案團隊透過統一管理入口，開發者專注部署 App 服務即可。接著可以開立不同的 Project，包括網管 Project、應用程式 Project 等。然後在每個區域建立 Subnet，須做好 IP 位址管理以便不同subnet 溝通。接著部署叢集，每個區域假設有3個叢集，其中2個是應用程式叢集也就是 data plane，1 個是網管叢集也就是 control plane，data plane 與 control plane 切開，彼此不互受影響，這就是區域的服務網格，透過跨區域的資訊共享，每個區域的 control plane 可以了解其他區域的服務，如此便形成全球的服務網格。最後把應用程式放在 namespace 並部署在跨區域多個叢集上，如此一來該服務便能在任一叢集運行，並確保服務不中斷。

而 ASM 平台也推出新功能 — ASM for VM 可用同樣的 Mesh 管理機制整合管理虛擬機器上的微服務。過去透過 MIG（Manager Instance Group）管理 VM 者，在 ASM  for  VM 上也同樣支援 MIG。ASM for VM 透過提供新參數來建立可支援 Service Mesh Instance 的範本，此範本建立的 VM Instance 會自動安裝 Mesh 所需要的軟體。把 MIG 加到 Service Mesh 的步驟，包括設定 Identity mapping、啟動 MIG 並驗證是否正常運作、把 VM 註冊到 Mesh、選擇 Instance 到服務中。藉此 VM 上的微服務便能與其他微服務有一致的管理體驗。

更多關於ASM的中文說明內容，歡迎點選下載「透過多雲管理平台Anthos實現應用程式現代化」白皮書。

GOOGLE ANTHOS － 簡化監控及營運工作的 Cloud Monitoring

GCP 也針對 Google Cloud 微服務的監管推出 SLO (Service-level Objectives) Monitoring。SLO 不只蒐集數值並且一味追求微服務 100% 的穩定，而是讓業務、開發、營運各團隊共同定義衡量組織成功的基礎以反映最終客戶體驗。

消費者信用報告機構 Equifax 選用 GCP 平台開啟其數位轉型之旅，他們使用 GCP 上 Analytics API, Kubernetes Engine, Dataflow, Cloud Monitoring, Cloud Logging 等服務。起初他們從內部資料中心來監管微服務，但沒有 Container Orchestration Platform 很難去掌握應用程式情況也很難營運。原本他們想先移轉應用程式再逐步微服務，後來決定直接用公有雲來轉型，整個重建應用程式架構並使用雲端工具以深入觀察 App。他們選擇使用四大金色指標（Four Golden Signals）做為 SLO。Equifax 的 SRE 主管提出建議：

1. 以預算觀點來考量 SLO 並據以決定進行方式。
2. 在公司內與相關利益關係人溝通概念，並執行小型 Pilot 專案來運行 SLO 以找出試行點。
   選擇正確工具。建議可直接使用 GCP 上四大金色指標來建 SLA。可在 Cloud monitoring、SLO API 平台依四大金色指標建置 SLA。最後所有 SLO 利益關係人都能有統一檢視畫面來監看服務運作績效。

目前除了在 GCP 上使用，不管是在地端的 Kubernetes、VM 或在其他雲端服務平台，透過 Google Cloud 的 API，也能幫助企業在這些環境建立專屬 SLO。

接著深入介紹在 GCP 上用來監控及營運的工具套件 Cloud monitoring。Cloud monitoring 也就是之前大家所熟知的 Stackdriver，它讓你可以設定告警政策，即定義一組條件，當事件觸發時通知相關人員或系統。通知的內容可以包括說明文件或 metadata 來協助接受通報者進一步處理。在建立告警政策並添加條件時，必須先選擇資源與指標（Metrics），資源即想監控的目標，如虛擬機、負載平衡器、URL 或端點等，而指標則是衡量資源的方式，如請求數、延遲或使用特定資源的人數。

例如可設定若 GKE 節點 CPU 使用率過高則發出告警，此處資源類型即 Kubernetes 節點，而 CPU 可配置使用率則為指標。接著可進一步透過設定篩選條件來減少回傳的數據量。而在建立告警政策時最重要的是要校準數據，讓所有數據都是在相同頻率、期間下所蒐集到的樣本數據。例如當條件設定若連續 10 分鐘 CPU 使用率超過 90% 時發出告警，Alignment Period 就是 10 分鐘。而觸發告警的條件也可設定當所有（或某百分比）時間序列超過設定值就觸發告警。Cloud monitoring 的告警提供相當大彈性。（如圖2）

Twitter 選用 GKE 達到部署全球化

最後談到 Google 與 Twitter 如何合作在 GKE 上設計叢集以實現大規模擴展並維持良好效能。Twitter 在 2012 年開始容器化，使用 Linux cgoups 超輕型容器，目前運算架構多在本機端，但也逐步擴展到雲端。僅管在本地與雲端有不同運算介面，他們仍希望能提供 Twitter 工程師透過單一管理平台達到一致性體驗。同時他們也希望延伸標準微服務層到更多元的服務中。經過評選，他們選擇 Kubernetes 作為支援雲端及本地端的下世代運算平台。但這也表示 Kubernetes 與 GKE 必須在可接受遷移路徑下達到Twitter需要的擴展規模。他們目前運行在大型 Mesos 叢集，每個叢集有數百萬個 CPU 核心、數十萬個容器、數萬個主機與數千個服務。而後 Google 投資大量資源以改善 Kubernetes 網路元件，並提升 Kubernetes 與 GKE 的整合，最後滿足 Twitter 的需求。

若企業要進行大規模叢集部署，以下是最佳實務：

1. 在計畫與執行階段測試並擴展系統時，須知如何擴展多維結構（envelope）。
2. 了解自己的工作負載如何擴展Kubernetes的擴展性多維結構。
3. 看工作負載是否增加只適用於你的額外抽象層或特定特性，且需要額外驗證看能否大規模應用。

而在思考叢集、工作負載的各面向時，需要：

1. 驗證如何使用原生Kubernetes資源，及是否遇到瓶頸。
2. 看你安裝的個人化應用程式效能，監控工作負載及他們對API伺服器的影響，以確保大規模運行能成功。
3. 監控應用程式在大規模運作的情況，部署能否水平擴展。
4. 叢集會與其他服務互動，需注意資料庫的配置十分重要。
5. 定義SLI、SLO以監控系統健康狀況。

同時須注意網路層設計的樣貌，包括負載平衡、DNS、IP位址管理。對線上服務使用區域叢集，對大規模服務使用私有叢集。