監視叢集性能

在 IBM Cloud® Kubernetes Service 中設定監控，以協助您排除問題，並改善 Kubernetes 群集和應用程式的健康與效能。

持續監視及記載是偵測叢集上攻擊以及疑難排解它們所造成之問題的關鍵。持續監視叢集，即可更充分地瞭解叢集容量以及您應用程式可用的資源可用性。透過此洞察，您可以準備保護應用程式免於發生運作中斷時間。

選擇監視解決方案

度量值可以協助您監視叢集的性能及效能。您可以使用標準 Kubernetes 及容器運行環境特性，來監視叢集及應用程式的性能。

IBM會持續監視每個 Kubernetes 主節點。IBM Cloud Kubernetes Service 會自動掃描每個已部署 Kubernetes 主節點的節點，以找出在 Kubernetes 及 OS 特定安全修正程式中找到的漏洞。如果找到漏洞，IBM Cloud Kubernetes Service 會自動套用修正程式，並代表使用者來解決漏洞以確保主節點保護。您負責監視及分析其餘叢集元件的日誌。

為了避免在使用度量服務時發生衝突，請確定資源群組和地區之間的叢集具有唯一名稱。

IBM Cloud® Monitoring: 將 Monitoring 代理程式部署至工作者節點，以取得應用程式及叢集之效能及性能的作業可見性。代理程式會收集 Pod 及叢集度量值，並將這些度量值傳送至 IBM Cloud Monitoring。如需 IBM Cloud Monitoring的相關資訊，請參閱服務文件。若要在叢集裡設定 Monitoring 代理程式，請參閱使用 IBM Cloud Monitoring。
Kubernetes 儀表板: Kubernetes 儀表板是一種管理 Web 介面，您可以在此介面中檢閱工作者節點的性能、尋找 Kubernetes 資源、部署容器化應用程式，以及使用記載和監視資訊對應用程式進行疑難排解。如需如何存取 Kubernetes 儀表板的相關資訊，請參閱啟動 IBM Cloud Kubernetes Service 的 Kubernetes 儀表板。

將記錄與監控代理遷移至 Cloud Logs

不再支援 Observability CLI 外掛程式 ibmcloud ob 及 v2/observe 端點。雖然無法直接取代，但您現在可以從主控台或透過 Helm 圖表管理記錄與監控整合。如需最新步驟，請參閱管理 IBM Cloud Kubernetes Service 群集的記錄代理程式，以及使用 Kubernetes 監控代理程式。

您不能再使用 ob 外掛、Terraform 或 API 在集群上安裝可觀測性代理或修改現有配置。 Sysdig 代理程式會繼續傳送指標到指定的 IBM Cloud Monitoring 範例。 LogDNA 由於已被 Logs 取代，因此代理無法再傳送記錄。IBM Cloud Log Analysis IBM Cloud

檢閱您的可觀察性代理

可觀察性外掛程式會在 ibm-observe 名稱空間中安裝 Sysdig 和 LogDNA 代理。

登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。

檢視 ibm-observe 命名空間中的 configmaps。

kubectl get cm -n ibm-observe

Example output

NAME                                   DATA   AGE

e405f1fc-feba-4350-9337-e7e249af871c   6      25m

f59851a6-ede6-4719-afa0-eee7ce65eeb5   6      20m

由 Observability 外掛程式安裝的 Observability 代理會使用一個 configmap，該 configmap 含有 IBM Cloud Monitoring 實體的 GUID 或日誌或指標要傳送至的 IBM Cloud Log Analysis 實體的 GUID。如果您的群集在 ibm-observe 以外的命名空間中安裝了代理，或者 ibm-observe 中的 configmaps 沒有以實例 GUID 命名，那麼這些代理沒有安裝 IKS observability (ob) 外掛。

移除可觀察性外掛代理程式

清理 daemonsets 和 configmaps。

kubectl delete daemonset logdna-agent -n ibm-observe
kubectl delete daemonset sysdig-agent -n ibm-observe
kubectl delete configmap <logdna-configmap> -n ibm-observe
kubectl delete configmap <sysdig-configmap> -n ibm-observe

可選：刪除命名空間。在命名空間中沒有其他資源執行之後。
```
kubectl delete namespace ibm-observe
```

移除外掛程式後，請使用群集儀表板、Terraform 或手動在群集中重新安裝記錄和監控代理。

如需相關資訊，請參閱下列鏈結：

設定 IBM Cloud® Monitoring 警報

當您設定警示時，請確保容許叢集有足夠時間自我修復。因為 Kubernetes 具有自我修復功能，所以請僅針對一段時間內發生的問題配置警示。透過觀察叢集一段時間，您可以瞭解 Kubernetes 可以自行解決哪些問題，以及哪些問題需要警示以避免關閉時間。

視叢集大小而定，請考量在下列層次設定警示:

應用程式
工作者節點
叢集
區域
帳戶
Block Storage for VPC

在工作者節點上設定自動回復，以讓叢集自動解決問題。

應用程式警示

檢閱下列應用程式層次度量值及警示臨界值，以協助在叢集裡設定應用程式監視。

要監視的一般應用程式層次條件包括諸如:

在 10 分鐘內重新啟動多個應用程式 Pod 或容器。
應用程式有多個抄本不在執行中。
在 10 分鐘內收到超過 10 個 5XX HTTP 回應碼。
名稱空間中有多個 Pod 處於不明狀態。
在工作者節點上無法排程超過五個 Pod (擱置狀態)。

這些症狀的基本問題包括:

一個以上工作者節點處於不健全狀態。
工作者節點已耗盡 CPU、記憶體或磁碟空間。
已達到每個叢集的 Pod 上限。
應用程式本身有問題。

若要設定這些條件的監視，請根據下列 IBM Cloud Monitoring 度量值來配置警示。請注意，視您的叢集配置而定，您的警示臨界值可能會變更。

應用程式層次度量值
度量	IBM Cloud Monitoring 度量值	警示臨界值
在短時間內多次重新啟動 Pod。	`kubernetes_pod_restart_count`	過去 10 分鐘大於 4
ReplicaSet中沒有執行中的抄本。	`kube_replicaset_status_replicas` 於 `kubernetes_deployment_name`	少於一個。
叢集中有 5 個以上 Pod 擱置中。	`kube_pod_container_status_waiting`	狀態等於 `pending` 大於 5。
部署中沒有可用的抄本。	`kubernetes_deployment_replicas_available`	少於一個。
每個節點的 Pod 數達到臨界值 110。	依 `(kube_cluster_name,kube_node_name)(kube_pod_container_info)` 計數	大於或等於 100。請注意，此查詢是 `promQL` 查詢。
處於不明狀態的工作量。	`(kube_workload_status_unavailable)`	大於或等於 1。請注意，此查詢是 `promQL` 查詢。

工作者節點警示

檢閱工作者節點的下列臨界值及警示。

工作者節點度量值
度量	IBM Cloud Monitoring 度量值	警示臨界值
工作者節點的 CPU 使用率超過臨界值。	`cpu_used_percent`	1 小時大於 80%。
工作者節點的 CPU 使用率超過臨界值。	`cpu_used_percent`	24 小時超過 65%。
工作者節點的記憶體使用率超出臨界值。	`memory_used_percent`	1 小時大於 80%。
工作者節點的記憶體使用率超出臨界值。	`memory_used_percent`	24 小時超過 65%。
透過臨界值使用的記憶體數量。	`memory_bytes_used`	大於 `NUMBER_OF_BYBTES`。
存在具有磁碟壓力的節點。	`kube_node_status_condition`	10 分鐘大於或等於 1。
Kubernetes 節點未備妥。	`kube_node_status_ready >= 1`

解決工作者節點警示

重新載入或重新開機工作者可以解決此問題。不過，您可能需要新增更多工作者，以增加容量。

取得工作者節點並檢閱狀態。
```
kubectl get nodes
```
如果所有工作者節點未處於 Ready 狀態，請將工作者節點新增至叢集。
- 將工作者節點新增至標準叢集。
- 將工作者節點新增至 VPC 叢集。
如果所有工作者節點都處於 Ready 狀態，請重新載入或重新開機工作者節點。
1. 說明工作者節點，並檢閱事件區段，以取得一般錯誤訊息。
```
kubectl describe node <node>
```
2. 封鎖不是 Ready 的節點，以便您可以開始調查。
3. 排除工作者節點。檢閱 Kubernetes 文件，以安全地從工作者節點排除 Pod。
```
kubectl drain <node>
```
4. 重新載入或重新開機工作者節點。

區域警示

若要設定區域層次警示，請編輯 sysdig-agent ConfigMap 以包括必要的標籤過濾器。

執行下列指令編輯 ConfigMap。

kubectl edit configmap sysdig-agent -n ibm-observe

在 k8s_cluster_name: <cluster_name> 之後新增下列 YAML 區塊。將 <cluster_name> 取代為您要監視的叢集名稱。

k8s_labels_filter:
  - include: "kubernetes.node.label.kubernetes.io/hostname"
  - include: "kubernetes.node.label.kubernetes.io/role"
  - include: "kubernetes.node.label.ibm-cloud.kubernetes.io/zone"
  - exclude: "*.kubernetes.io/*"
  - exclude: "*.pod-template-hash"
  - exclude: "*.pod-template-generation"
  - exclude: "*.controller-revision-hash"
  - include: "*"

重新啟動 IBM Cloud Monitoring pod。刪除所有 Pod 並等待它們重新啟動。取得 Pod 清單。
```
kubectl get pods -n ibm-observe
```

刪除 Pod 以重新啟動它們。

kubectl delete pods sysdig-agent-1111 sysdig-agent-2222 sysdig-agent-3333 -n ibm-observe

等待 Pod 重新啟動 5 分鐘。重新啟動 Pod 之後，您先前新增的標籤可在 IBM Cloud Monitoring 中使用
開啟 IBM Cloud Monitoring 儀表板 > 探索 > PromQL 查詢，以驗證現在顯示的標籤。
在查詢欄位中輸入 kube_node_labels，然後按一下 Run Query。

區域層次警示
度量	PromQL 查詢
超出臨界值的每個區域 CPU 使用率	`sum(sysdig_container_cpu_used_percent{agent_tag_cluster="<cluster_name>"}) by (kube_node_label_ibm_cloud_kubernetes_io_zone) / sum (kube_node_info) by (kube_node_label_ibm_cloud_kubernetes_io_zone) > 80`
超出臨界值的每個區域記憶體用量	`sum(sysdig_container_cpu_used_percent{agent_tag_cluster="<cluster_name>"}) by (kube_node_label_ibm_cloud_kubernetes_io_zone)/ sum (kube_node_info) by (kube_node_label_ibm_cloud_kubernetes_io_zone) > 80`

叢集警示

檢閱下列範例臨界值，以在叢集層次建立警示。

地區中的所有工作者節點都達到 80% 的容量臨界值。
超過 50% 的所有工作者節點處於不健全狀態。
達到每個帳戶的檔案及區塊儲存空間磁區數目上限 (250)。
達到每個叢集的工作者節點數目上限 (500)。

帳戶警示

您可以設定警示，指出每個帳戶的叢集數目上限何時達到限制。例如，每個地區/基礎架構提供者 100。

Block Storage for VPC 警示

下列度量值可用於 Block Storage for VPC 警示:

kubelet_volume_stats_available_bytes
kubelet_volume_stats_capacity_bytes
kubelet_volume_stats_inodes
kubelet_volume_stats_inodes_free
kubelet_volume_stats_inodes_used

建立 Block Storage for VPC 警示的監視實例。請參閱將叢集和應用程式指標轉送至IBM Cloud Monitoring 中的說明。
安裝 syslog 代理程式。
1. 在 IBM Cloud 主控台中，從功能表中選取觀察。
2. 選取監視。
3. 在 Block Storage for VPC 警示的實例列中，選取 開啟儀表板。
4. 從功能表中，選取 開始使用。
5. 在「安裝代理程式」區段下，選取 新增來源。
6. 按照指示安裝代理程式。
7. 使用 kubectl get pods -n CLUSTER_NAME | grep syslog 指令，確定代理程式正在執行中。
配置通知通道。
1. 在 IBM Cloud Monitoring 儀表板中，選取 監視作業> 設定。
2. 選取 通知通道 > 新增通知通道，並挑選其中一個可用的通知方法。
3. 完成新通道的設定，然後按一下儲存。
4. 可選擇：重複前面的步驟，新增更多頻道。
建立警示。
1. 在 IBM Cloud Monitoring 儀表板中，選取警示 > 檔案庫。
2. 選擇其中一個範本，然後選取 啟用警示。例如，您可以搜尋 PVC storage 並啟用 PVC Storage Usage Is Reaching The Limit 警示。
3. 自訂範本上的警示設定，並選取 啟用警示 以套用您的設定。

如果 Block Storage for VPC 磁區達到容量，您可以設定磁區擴充。

使用自動回復功能監控工作站節點的健康狀況

「自動回復」系統會使用各種檢查來查詢工作者節點性能狀態。如果「自動回復」根據已配置的檢查偵測到不健全的工作者節點，則「自動回復」會觸發更正動作，例如重新開機 VPC 工作者節點或在標準工作者節點中重新載入作業系統。一次只有一個工作者節點進行一個更正動作。 Worker 節點必須在其他 Worker 節點進行修正動作之前完成修正動作。

自動復原需要至少一個健康的工作節點才能正常運作。只在具有兩個以上工作者節點的叢集裡，配置具有主動檢查的「自動回復」。

開始之前：

請確定您有下列 IBM Cloud IAM 角色：
- 群集的管理員平台存取角色
- kube-system 命名空間的 Writer 或 Manager 服務存取角色
登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。

若要配置 Autorecovery，請執行下列動作：

遵循指示，在本端機器上安裝 Helm 第 3 版用戶端。

以 JSON 格式建立配置對映檔，以定義您的檢查。例如，下列 YAML 檔案定義三個檢查：一個 HTTP 檢查及兩個 Kubernetes API 伺服器檢查。請參閱元件說明和健康檢查元件表，以瞭解三種檢查的相關資訊以及檢查的個別元件資訊。

在配置映射的 data 區段中，將每個檢查定義為唯一的鍵。

kind: ConfigMap
apiVersion: v1
metadata:
  name: ibm-worker-recovery-checks
  namespace: kube-system # The `kube-system` namespace is a constant and can't be changed.
data:
  checknode.json: |
    {
      "Check":"KUBEAPI",
      "Resource":"NODE",
      "FailureThreshold":3,
      "CorrectiveAction":"RELOAD",
      "CooloffSeconds":1800,
      "IntervalSeconds":180,
      "TimeoutSeconds":10,
      "Enabled":true
    }
  checkpod.json: |
    {
      "Check":"KUBEAPI",
      "Resource":"POD",
      "PodFailureThresholdPercent":50,
      "FailureThreshold":3,
      "CorrectiveAction":"RELOAD",
      "CooloffSeconds":1800,
      "IntervalSeconds":180,
      "TimeoutSeconds":10,
      "Enabled":true
    }
  checkhttp.json: |
    {
      "Check":"HTTP",
      "FailureThreshold":3,
      "CorrectiveAction":"REBOOT",
      "CooloffSeconds":1800,
      "IntervalSeconds":180,
      "TimeoutSeconds":10,
      "Port":80,
      "ExpectedStatus":200,
      "Route":"/myhealth",
      "Enabled":false
    }

在叢集裡建立配置對映。

kubectl apply -f ibm-worker-recovery-checks.yaml

使用適當的檢查，驗證您已在 ibm-worker-recovery-checks 名稱空間中建立名稱為 kube-system 的配置對映。
```
kubectl -n kube-system get cm ibm-worker-recovery-checks -o yaml
```

安裝 ibm-worker-recovery Helm Chart，以將「自動回復」部署至叢集。

helm install ibm-worker-recovery iks-charts/ibm-worker-recovery --namespace kube-system

幾分鐘之後，您可以檢查下列指令輸出中的 Events 區段，以查看「自動回復」部署上的活動。
```
kubectl -n kube-system describe deployment ibm-worker-recovery
```
如果您在 Autorecovery 部署上看不到活動，您可以透過執行 Autorecovery 圖表定義中的測試來檢查 Helm 部署。
```
helm test ibm-worker-recovery -n kube-system
```

瞭解 ConfigMap 元件

檢閱性能檢查之個別元件的下列相關資訊。

name:配置名稱 ibm-worker-recovery-checks 是常數，無法變更。
namespace: kube-system 命名空間是常數，不能變更。
checknode.json:定義 Kubernetes API 節點檢查，可檢查每個 Worker 節點是否處於 Ready 狀態。如果特定 Worker 節點未處於 Ready 狀態，則對該 Worker 節點的檢查算作失敗。範例 YAML 中的檢查每 3 分鐘執行一次。如果它連續失敗三次，則會重新載入工作者節點。此動作等同於執行 ibmcloud ks worker reload。節點檢查是啟用的，直到您將啟用欄位設定為 false 或移除檢查。請注意，只有標準基礎架構上的工作者節點才支援重新載入。
checkpod.json:定義 Kubernetes API pod 檢查，根據指派給工作人員節點的總 Pod，檢查 NotReady 工作人員節點上 Pod 的總百分比。如果 NotReady pod 的總百分比大於定義的 PodFailureThresholdPercent，則特定 Worker 節點的檢查算作失敗。範例 YAML 中的檢查每 3 分鐘執行一次。如果它連續失敗三次，則會重新載入工作者節點。此動作等同於執行 ibmcloud ks worker reload。例如，預設 PodFailureThresholdPercent 為 50%。如果 NotReady Pod 的百分比連續三次大於 50%，則會重新載入工作者節點。依預設，檢查會在所有名稱空間上執行。若要將檢查限制為僅指定命名空間中的 pod，請在檢查中加入 Namespace 欄位。 Pod 檢查是啟用的，直到您將啟用欄位設定為 false 或移除檢查。請注意，只有標準基礎架構上的工作者節點才支援重新載入。
checkhttp.json:定義 HTTP 檢查，以檢查在您的工作節點上執行的 HTTP 伺服器是否健康。若要使用此檢查，您必須使用守護程式集，在群集中的每個工作節點上部署 HTTP 伺服器。您必須在 /myhealth 路徑上實作健康檢查，它可以驗證您的 HTTP 伺服器是否健康。您可以透過變更 Route 參數，定義其他路徑。如果 HTTP 伺服器是健康的，您必須傳回 ExpectedStatus 中定義的 HTTP 回應代碼。 HTTP 伺服器必須配置為在工作者節點的專用 IP 位址上接聽。您可以執行 kubectl get nodes 找到私人 IP 位址。例如，請考量叢集裡兩個具有專用 IP 位址 10.10.10.1 及 10.10.10.2 的節點。在這個範例中，有兩個路由會檢查 200 HTTP 回應：http://10.10.10.1:80/myhealth 和 http://10.10.10.2:80/myhealth。範例 YAML 中的檢查每 3 分鐘執行一次。如果它連續失敗三次，則會重新啟動工作者節點。此動作等同於執行 ibmcloud ks worker reboot。 HTTP 檢查被停用，直到您將啟用欄位設定為 true。

瞭解健康檢查的個別組成部分

請檢閱下表，以取得性能檢查個別元件的相關資訊。

性能檢查元件
元件	說明
`Check`	輸入您希望 Autorecovery 使用的檢查類型。 `HTTP` ：自動回復會呼叫在每個節點上執行的 HTTP 伺服器，以確定節點是否正常執行。 `KUBEAPI` ： Autorecovery 會呼叫 Kubernetes API 伺服器，並讀取工作節點報告的健康狀態資料。
`Resource`	當檢查類型為 `KUBEAPI` 時，輸入您要 Autorecovery 檢查的資源類型。可接受的值為 `NODE` 或 `POD`。
`FailureThreshold`	輸入連續失敗檢查次數的臨界值。符合此臨界值時，「自動回復」會觸發指定的更正動作。例如，如果值為 3，且「自動回復」連續三次無法進行配置的檢查，則「自動回復」會觸發與該檢查相關聯的更正動作。
`PodFailureThresholdPercent`	當資源類型為 `POD` 時，請輸入工作者節點上可處於狀態的 Pod 百分比的臨界值。NotReady 狀態。此百分比是以排定給工作者節點的 Pod 總數為基礎。當檢查判定性能不佳之 Pod 的百分比大於臨界值時，此檢查會將其算成一次失敗。
`CorrectiveAction`	輸入當符合失敗臨界值時要執行的動作。修正動作僅在沒有其他 Worker 正在維修，且此 Worker 節點未處於先前動作的冷卻期時執行。 `REBOOT` ：將工作者節點重新開機。 `RELOAD`: 從乾淨的作業系統重新載入 Worker 節點的所有必要設定。
`CooloffSeconds`	輸入「自動回復」必須等待幾秒，才能對已發出更正動作的節點發出另一個更正動作。散熱期間開始於發出更正動作時。
`IntervalSeconds`	輸入連續檢查之間的秒數。例如，如果值為 180，則「自動回復」每 3 分鐘會對每一個節點執行一次檢查。
`TimeoutSeconds`	輸入在「自動回復」終止呼叫作業之前，對資料庫進行檢查呼叫所花費的秒數上限。 `TimeoutSeconds` 的值必須小於 `IntervalSeconds` 的值。
`Port`	當檢查類型為 `HTTP` 時，請輸入 HTTP 伺服器在工作節點上必須綁定的連接埠。此埠必須公開在叢集裡每個工作者節點的 IP 上。「自動回復」需要在所有節點之中固定不變的埠號，以檢查伺服器。當您將自訂伺服器部署到群集時，請使用守護程式集。
`ExpectedStatus`	當檢查類型為 `HTTP` 時，請輸入您期望從檢查傳回的 HTTP 伺服器狀態。例如，值為 200 表示您期望從伺服器獲得 `OK` 回應。
`Route`	當檢查類型為 `HTTP` 時，輸入從 HTTP 伺服器要求的路徑。此值通常是在所有工作節點上執行的伺服器的度量路徑。
`Enabled`	輸入 `true` 啟用檢查，或輸入 `false` 停用檢查。
`Namespace`	可選：若要限制 `checkpod.json` 只能檢查一個命名空間中的 Pod，請新增 `Namespace` 欄位並輸入命名空間。