GKE Enterprise是什麼？企業容器平台GKE Enterprise 監控服務最佳選擇

GKE 得益於雲端資源能有彈性的部署與新增資源，讓 Kubernetes 在 Workload 的設計與使用上更有彈性。然而，隨著客戶部署的服務日益增加，如何有效地在 GCP 上監控各個微服務的狀況便成為我們許多客戶管理上極為注重的任務。我們期待您透過實作此文介紹的方法後，能達成透過 GCP 原生的服務有效且快速的監控所有部署在 GKE 的微服務。

GKE enterprise 環境/服務介紹

透過詳細設定 GCP 原生的監控服務 Cloud Monitoring，用戶可以針對多數 GCP 上的服務自動且全面地進行效能相關的監控，並經由建立的妥善規劃的警示閾值來通知相關部門與人員快速針對異常狀態進行反應與檢查。

透過 Cloud Monitoring 可監控到 GKE 相關的 Metric 可概略分類為以下類別 [1]：

System Metrics: 底層系統元件的 Metrics，如 CPU, Memory 等

Control Plane Metrics: API Server 等 Control Plane 元件的 Metrics
Kube State Metrics: Pods, Deployments 等相關元件的 Metrics

透過完整收集這三類 Metrics，您可以同時針對 Clusters 與 Workload 進行多個面向的監控 [2]

監控 GKE 服務步驟說明

當我們的 GKE 服務產生異常流量時（如服務受到 DDoS 攻擊）若不能夠及時反應，往往會讓我們遭受額外的損失。因此如果能在服務有異常狀態時儘早發現服務，團隊便可以馬上介入，檢查哪些服務發生異常、影響範圍有多大等等，而透過將 GKE Metric 傳入 Cloud Monitoring 的方法就可以讓我們達成這樣的目的，那接著我們就會詳細介紹該如何透過 Cloud Monitoring 完整的監控 GKE 服務的工作狀況：

1. 啟用 System Metrics 並送入 Cloud Monitoring

By default，GKE Enterprise & Autopilot Cluster 建立時系統便會替我們啟用 System Metrics，而若啟用的為 Standard Cluster，使用者也可以透過 --monitoring flag 於 SYSTEM 或 NONE 間切換參數值來決定是否啟用 System Metrics。為了於 Cloud Monitoring 收集上述各種類的 Metrics ，我們首先需要先保持啟用 System Metrics 並選擇將其送入 Cloud Monitoring 中。

啟用 System Metrics 並送入 Cloud Monitoring

如前所述，System Metrics 中包含一些 GKE 底層核心的指標，包含：

CPU usage time: 容器使用的所有內核的累計CPU使用率（以秒為單位）
Limit cores: 容器的限制 CPU 核心數
CPU limit utilization: Instance 使用的 CPU 與限制 CPU 的比率
Request cores: 容器請求的 CPU 核心數
CPU request utilization: Instance 使用的 CPU 與請求的 CPU 的比率
Memory limit: 容器的限制 Memory
Memory limit utilization: Instance 使用的 Memory 與限制 Memory 的比率
Memory request: 容器請求的 Memory
Memory request utilization: Instance 使用的 Memory 與請求的 Memory 的比率

除了上述常用指標外，目前 System Metrics 還有包含其他項目可以呈現在 Cloud Monitoring 中，其他可被收集的 System Metrics 可參考 [3]

2. 啟用 Additional Observability Metrics

那除了監控底層的 System Metrics 之外，啟用 Control Plane Metrics 與 Kube State Metrics 可以讓我們針對 GKE 各類狀態能有更全面的監控，其中 Control Plane Metrics 能讓我們特別監控：

針對 Control Plane 進行操作的相關資訊
API server, scheduler, and controller manager 等元件的相關狀態

而 Kube State Metrics 則：

不僅針對 Deployments, Nodes 與 Pods，Kube State Metrics 甚至是針對 DaemonSet, Storage 與 HorizontalPodAutoscaler 也可以進行 Workloads 層級的監控

透過這兩個 Additional Packages，我們便可以非常方便地監控實務上常用的 Metrics，包含：

apiserver_request_duration_seconds
apiserver_request_total
apiserver_storage_objects
apiserver_current_inflight_requests
kube_pod_status_phase
kube_deployment_status_replicas_available
kube_statefulset_status_replicas_ready
kube_horizontalpodautoscaler_spec_max_replicas
kube_horizontalpodautoscaler_spec_min_replicas
kube_horizontalpodautoscaler_status_current_replicas
kube_horizontalpodautoscaler_status_desired_replicas

透過上述幾個 Metrics，我們可以快速在元件有異常負載的時候回查狀況。

舉例來說，當 API Server 過載的時候 request 的時間相對會變長，這時候我們就可以檢視 apiserver_request_duration_seconds 來初步確認每次 request 所花費的時間是否超過建議的閾值，再透過 apiserver_request_tota 與 apiserver_storage_objects 進一步針對各個 Label 逐一排查是哪些 request 造成狀況 [4]，又或是我們可以透過 kube_horizontalpodautoscaler_status_current_replicas 與 kube_horizontalpodautoscaler_status_desired_replicas 來檢視 controller 是否能夠正常部署我們預期數量的 pod。

其餘這兩個 Additional Packages 可收集的 Metrics，還請參考此文件 [5][6]

其實不只是於 GKE Enterprise 版本的叢集中可以使用 Control Plane Metrics, Kube State Metrics (預設啟用)，使用者若只是 GKE Standard 版本的叢集也可以透過 GCP Console 或是 gcloud 指令來啟用，這些額外的 Metrics 可於建立叢集或是後續再做修改設定，

於建立叢集時：
- 使用者可以透過 Features 內 Cloud Monitoring 下方 Components 選單內勾選希望收集 Metrics 的 Components:

使用者可以透過 Features 內 Cloud Monitoring 下方 Components 選單內勾選希望收集 Metrics 的 Components

或是透過 gcloud 指令，將 API_SERVER, SCHEDULER, CONTROLLER_MANAGER 等參數傳入--monitoring flag 即可於叢集啟用對 Control Plane 與 Workloads 監控

或是透過 gcloud 指令，將 API_SERVER, SCHEDULER, CONTROLLER_MANAGER 等參數傳入--monitoring flag 即可於叢集啟用對 Control Plane 與 Workloads 監控

更新現有的叢集配置
- 使用者可以透過 GCP Console 於建立叢集後，點選 Observability 頁籤再點擊啟用 Feature 內的 Control Plane 與 Kube State 套件：

使用者可以透過 GCP Console 於建立叢集後，點選 Observability 頁籤再點擊啟用 Feature 內的 Control Plane 與 Kube State 套件

或是透過 gcloud 指令，同樣將 API_SERVER, SCHEDULER, CONTROLLER_MANAGER 等參數傳入--monitoring flag 即可於叢集啟用對 Control Plane 與 Workloads 的監控

一般而言，會建議正在使用 GKE 的用戶盡可能收集所有的 Metrics，透過gcloud 指令將便可以一次性地在建立或後續更新叢集時將 SYSTEM, API_SERVER, SCHEDULER, CONTROLLER_MANAGER, STORAGE, POD, DEPLOYMENT, STATEFULSET, DAEMONSET, HPA 這些對應的 Metrics 參數全部傳入 --monitoring flag 當中，會是相對比較簡單快速的操作方式。

3. 透過定義 SLI、SLO 妥善利用收集的 Metrics

當我們將 Metrics 收集至 Cloud Monitoring 後，我們就可以如前一段落所提到的，針對想監測的 Metrics 建立客製化的 Dashborad。透過客製化的 Dashboard，使用者不僅可以快速檢視目前 GKE 系統底層硬體狀態與 Workloads，更可以針對特定 Metrics 建立告警，快速通知對應的負責團隊檢視異常。

為了判斷我們部署的服務是否有預期外的狀況，建立 service-level objective (SLO) service-level Indicator (SLI) 是使用者必須完成的任務。

首先，我們透過選擇選擇要設定 SLO 的服務 [7]，在 Cloud Monitoring 中我們可以根據 GKE namespaces, GKE services, GKE workloads 針對選定對應的範圍分別制定 SLO，那除了透過 Console 篩選設定外，其實我們也可以使用 services.create API 傳入物件來直接定義服務：

我們透過選擇選擇要設定 SLO 的服務 [7]，在 Cloud Monitoring 中我們可以根據 GKE namespaces, GKE services, GKE workloads 針對選定對應的範圍分別制定 SLO

透過 Console 篩選設定外，其實我們也可以使用 services.create API 傳入物件來直接定義服務

在我們定義完服務以後，接著我們可以選擇要針對哪個 Metrics 制定 SLI，GKE-based 的服務需要透過自定義 SLI 對前述收集的 Metrics 訂定閾值 [8]

在我們定義完服務以後，接著我們可以選擇要針對哪個 Metrics 制定 SLI，GKE-based 的服務需要透過自定義 SLI 對前述收集的 Metrics 訂定閾值

而這些 Metrics 會被區分為兩類：

Distribution-cut indicators: 透過定義數值上下區間制定 SLI

Distribution-cut indicators: 透過定義數值上下區間制定 SLI

Time-series ratio indicators: 透過定義特定時間區間內的比率制定 SLI

Time-series ratio indicators: 透過定義特定時間區間內的比率制定 SLI

當我們制定完 SLI 後，我們就可以在 Define SLI Details 的頁籤中看到對應服務的 Performance：

當我們制定完 SLI 後，我們就可以在 Define SLI Details 的頁籤中看到對應服務的 Performance

我們會推薦使用者可以先針對 Control Plane Metrics, HPA Metrics 建立 SLIs，例如我們可以經由 [API server metrics][gke-api-metrics] 來監控 API Server 的負載，或是透過 scheduler metrics 來主動監控服務是否在調度 Pod 上遇到一些狀況。

定義完要監控的服務、選定要作為 SLI 的 Metrics 後，我們接著要做的就是制定我們的 SLO。透過 Compliance period 與 Performance goal 這兩個參數，使用者可以制定出在特定時間區間內至少要保持怎樣的服務閾值 [9]。若是低於 SLO，使用者可以透過整合的告警服務自動通知對應的負責團隊或是同仁。

4. 當服務的 SLO 有異常狀況時，觸發告警機制

當我們制定好 SLO 後，我們接著要設定的就是當服務不如預期時的告警機制 (Alerting Policy) ，在 GCP 上我們可以使用 Console [10] 或是 API [11] 來設定我們要建立的 Alerting Policy，以下會主要以 Console 畫面進行操作示範。

如果要透過 Console 建立 Alerting Policy ，首先我們點選 Service Overview 頁面中我們想監控的服務，再於 Current Status 區塊針對想發出告警的 SLO 點選鈴鐺圖示：

如果要透過 Console 建立 Alerting Policy ，首先我們點選 Service Overview 頁面中我們想監控的服務

，再於 Current Status 區塊針對想發出告警的 SLO 點選鈴鐺圖示

這邊的 Target 值系統會根據我們在建立SLO所設定的閾值帶入。另外，Lockback duration 用來設定追溯 Burn Rate 的區間，這個數值會作為用來計算 Error Budget 使用量的區間，而 Burn Rate Threshold 則用來設定 Error Budget使用量超過哪個數值時需要觸發告警。

接著我們可以設定當這個條件被觸發時需要聯繫的團隊或是人員，目前已經有許多支援的通知方式，我們可以透過點選 MANAGE NOTIFICATION CHANNELS 新增通知方式，並且可以額外撰寫遇到該狀況該如何處理的備忘錄，雖然這些設定都是 Optional，但我們十分建議使用者設定，因為這些設定都能幫助我們更快速解決問題：

我們可以透過點選 MANAGE NOTIFICATION CHANNELS 新增通知方式

可以額外撰寫遇到該狀況該如何處理的備忘錄

在 Alerting Policy 初步制訂完成後，若後續想要再次調整 Threshold 或通知人員名單 or 管道，我們仍舊可以透過點選修改已建立 Policy 中的細部設定，如下二圖所示：

在 Alerting Policy 初步制訂完成後，若後續想要再次調整 Threshold 或通知人員名單 or 管道，我們仍舊可以透過點選修改已建立 Policy 中的細部設定

當後續服務的 SLO 不如預期時，我們先前制定的 Alerting Policy 便會觸發，寄送相關告警給 Notification Channel 中設定的相關人員，達成我們動態監控 GKE 上服務的目的。

當後續服務的 SLO 不如預期時，我們先前制定的 Alerting Policy 便會觸發，寄送相關告警給 Notification Channel 中設定的相關人員，達成我們動態監控 GKE 上服務的目的

透過啟用並收集 GKE 各項的 Metrics，使用者可以對目前部署在 GCP 環境上的 GKE 服務有更全面的掌控，再搭配著為各項服務分別建立對應的 SLIs, SLOs、通知機制，如額外需要針對單一 Metrics 再建立 threshold、通知管道，GCP 也能有對應的設定 [13][14][15]。

經由完整建立 GCP 對 GKE 的監控機制，使用者便能夠在服務指標不如預期時由負責的團隊快速應對、排查原因，讓我們的服務能夠及時快速回到正常的運作狀態。

Hugo Lai, Solution Architect

6x Google Cloud 認證，擅長以雜揉開發者與技術顧問的溝通模式協助客戶規劃最佳雲端解決方案並正在努力準備第7張 Google Cloud 認證的 ex 後端工程師。