查看叢集自動配置器事件和指標

本頁面提供 Google Kubernetes Engine (GKE) 中叢集自動配置器產生的可見度事件和指標相關資訊。分析這些記錄和指標，即可深入瞭解叢集自動配置器如何管理叢集的資源調度、追蹤節點佈建趨勢，以及瞭解決策背後的原因。

您可以透過下列資訊觀察叢集自動配置器：

• 可見度事件記錄：Cloud Logging 中的事件記錄，提供特定資源調度動作的詳細資訊，例如 scaleUp、scaleDown 和 noScaleUp 決策。本指南所述的事件與叢集自動配置器產生的 Kubernetes 事件不同。
• Cloud Monitoring 指標：匯總時間序列指標，提供各 ComputeClass 節點佈建嘗試、失敗和待處理 Pod 的高階趨勢。

需求條件

如要查看自動配置器事件，您必須在叢集中啟用 Cloud Logging。如果停用 Logging，就不會產生事件。

事前準備

開始之前，請確認您已執行下列工作：

• 啟用 Google Kubernetes Engine API。
啟用 Google Kubernetes Engine API
• 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果先前已安裝 gcloud CLI，請執行 gcloud components update 指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文件中的指令。

• 確認您已有標準叢集。如需建立，請建立 Standard 叢集。

檢視活動

叢集自動配置器的瀏覽權限事件會儲存在 Cloud Logging 記錄檔中，該記錄檔與 GKE 叢集位於同一個專案。您也可以在 Google Cloud 控制台的「Google Kubernetes Engine」頁面中，透過通知查看這些事件。

查看瀏覽權限事件記錄

如要查看記錄，請執行下列操作：

1. 在 Google Cloud 控制台中，前往「Kubernetes Clusters」(Kubernetes 叢集) 頁面。

   開啟 Kubernetes 叢集清單

2. 選取叢集名稱，查看「叢集詳細資料」頁面。

3. 在「Cluster Details」(叢集詳細資料) 頁面，點選「Logs」(記錄) 分頁標籤。

4. 在「記錄」分頁中，按一下「自動配置器記錄」分頁標籤，即可查看記錄。

5. (選用) 如要套用更進階的篩選器來縮小結果範圍，請按一下頁面右側有箭頭的按鈕，在記錄檔探索工具中查看記錄。

查看能見度事件通知

如要在 Google Kubernetes Engine 頁面查看瀏覽權限事件通知，請執行下列操作：

1. 前往 Google Cloud 控制台的「Google Kubernetes Engine」頁面：

   前往「Google Kubernetes Engine」

2. 查看特定叢集的「Notifications」(通知) 欄，找出與資源調度相關的通知。

3. 按一下通知，即可查看詳細資訊、應變措施建議，以及存取這項事件的記錄。

使用 Cloud Monitoring 監控待處理的 Pod 狀態

GKE 1.37 以上版本除了提供觀測事件，GKE 叢集自動配置器也會將 kubernetes.io/autoscaler/cluster_pending_pods_per_ccc 即時指標匯出至 Cloud Monitoring。這項指標會提供叢集自動配置器觀察及處理的 Pending 狀態 Pod 數量，並適用於 k8s_entity 受監控資源類型。

這項指標特別適合用來瞭解不同 ComputeClass 的需求。

重要標籤

這項指標包含下列重要標籤：

• resource.labels.entity_type：實體類型，這項指標一律為 ComputeClass。
• resource.labels.entity_name：Pod 要求的 ComputeClass 名稱。如果 Pod 沒有特定 ComputeClass，則為空白 ("")。
• metric.labels.reason：叢集自動配置器檢視畫面中 Pod 的目前階段 (unprocessed、provisioning_in_progress、unable_to_provision、no_action_taken)。
• metric.labels.type：Pod 類型 (system_pod 或 user_pod)。

應用實例

以下範例說明如何使用 PromQL 查詢這項指標：

• 追蹤每個 ComputeClass 的擴充需求：

  sum by (entity_name) (
    kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass",
      type="user_pod"
    }
  )
  

  這項查詢會顯示每個 ComputeClass 的待處理使用者 Pod 總數，指出目前的擴充需求所在。

• 監控遭封鎖的擴充作業：

  sum by (entity_name, type) (
    kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass",
      reason="unable_to_provision"
    }
  )
  

  這項查詢可快速找出是否有任何 ComputeClass 發生問題，導致叢集自動配置器無法佈建節點。

分析這項指標，即可深入瞭解叢集自動配置器的待處理工作，以及為 ComputeClasses 定義的不同工作負載類型佈建節點的能力。如要排解特定 ComputeClass 排程問題，請參閱「排解 ComputeClass 問題」。

監控節點佈建

下列 Cloud Monitoring 指標適用於 GKE 1.37 以上版本，可讓您依 ComputeClass 查看叢集自動配置器的節點佈建活動。這些指標使用 k8s_entity 受監控資源類型。在這個資源類型中，resource.labels.entity_type 標籤的值為 ComputeClass，resource.labels.entity_name 標籤的值則是定義佈建節點群組的 ComputeClass 名稱。如果 resource.labels.entity_name 標籤的值是空字串 ("")，表示佈建中的節點群組未與任何特定 ComputeClass 建立關聯。

搭配使用指標和記錄

如要監控及診斷叢集自動配置器的潛在問題，您可以結合使用指標和記錄檔，執行下列工作：

• 使用指標找出趨勢並設定快訊：使用 Cloud Monitoring 指標監控匯總佈建健康狀態、以視覺化方式呈現一段時間內的趨勢，以及設定警告政策 (例如佈建失敗次數激增或配額用盡時發出快訊)。
• 使用記錄檔調查根本原因：向上擴充失敗時，也會在 Cloud Logging 中產生瀏覽權限記錄項目 (例如 noScaleUp 或 eventResult 事件)。如果指標顯示某個時間範圍內的失敗次數激增，請檢查對應的記錄，查看特定 Pod、目標節點集區和詳細錯誤訊息。

監控節點佈建嘗試

kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc 指標會追蹤自動配置器嘗試將節點新增至特定 ComputeClass 定義的節點群組的頻率。resource.labels.entity_name 標籤的空字串 ("") 表示佈建活動與任何特定 ComputeClass 無關。

下列 PromQL 範例會追蹤每個 ComputeClass 的擴充活動：

sum by (entity_name) (
  increase(
    kubernetes_io:autoscaler_cluster_node_provisioning_attempts_count_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass"
    }[5m]
  )
)

監控節點佈建失敗

kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc 指標會提供擴充失敗的次數。這項指標可用於找出基礎架構瓶頸或錯誤設定。

這項指標的重要標籤包括：

• resource.labels.entity_name：ComputeClass 的名稱，用於定義佈建失敗的節點群組。如果節點群組並非由特定 ComputeClass 定義，則值為空白 ("")。
• metric.labels.reason：代表失敗原因的字串代碼。

下列 PromQL 範例會找出各 ComputeClass 的主要失敗原因：

sum by (reason, entity_name) (
  increase(
    kubernetes_io:autoscaler_cluster_node_provisioning_failed_attempts_count_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass"
    }[1h]
  )
)

失敗原因 (metric.labels.reason)

kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc 指標上的 metric.labels.reason 標籤會提供字串代碼，指出節點佈建失敗的原因。如需各項原因的詳細說明和可能的修正措施，請參閱解讀失敗原因疑難排解指南。

事件類型

所有記錄的事件都採用 JSON 格式，可在記錄項目的 jsonPayload 欄位中找到。事件中的所有時間戳記都是 UNIX 秒時間戳記。

以下是叢集自動配置器發出的事件類型摘要：

狀態事件

系統會定期發出 status 事件，說明叢集自動配置器觀察到的所有自動調度資源節點集區實際大小，以及所有自動調度資源節點集區的目標大小。

範例

以下記錄範例顯示 status 事件：

{
  "status": {
    "autoscaledNodesCount": 4,
    "autoscaledNodesTarget": 4,
    "measureTime": "1582898536"
  }
}

ScaleUp 活動

叢集自動配置器擴充叢集時，會發出 scaleUp 事件。自動配置器會擴充節點集區的基礎代管執行個體群組 (MIG)，藉此增加叢集節點集區的大小。如要進一步瞭解向上擴充的運作方式，請參閱 Kubernetes 叢集自動配置器常見問題中的「向上擴充的運作方式」一節。

事件包含下列資訊：哪些 MIG 擴充、擴充多少節點，以及哪些無法指派的 Pod 觸發事件。

觸發 Pod 的清單會截斷為 50 個任意項目。觸發 Pod 的實際數量會顯示在 triggeringPodsTotalCount 欄位中。

範例

以下記錄範例顯示 scaleUp 事件：

{
  "decision": {
    "decideTime": "1582124907",
    "eventId": "ed5cb16d-b06f-457c-a46d-f75dcca1f1ee",
    "scaleUp": {
      "increasedMigs": [
        {
          "mig": {
            "name": "test-cluster-default-pool-a0c72690-grp",
            "nodepool": "default-pool",
            "zone": "us-central1-c"
          },
          "requestedNodes": 1
        }
      ],
      "triggeringPods": [
        {
          "controller": {
            "apiVersion": "apps/v1",
            "kind": "ReplicaSet",
            "name": "test-85958b848b"
          },
          "name": "test-85958b848b-ptc7n",
          "namespace": "default"
        }
      ],
      "triggeringPodsTotalCount": 1
    }
  }
}

ScaleDown 事件

叢集自動配置器縮減叢集時，會發出 scaleDown 事件。如要進一步瞭解縮減作業的運作方式，請參閱 Kubernetes 叢集自動配置器常見問題中的「縮減作業的運作方式」一節。

cpuRatio 和 memRatio 欄位會以百分比表示節點的 CPU 和記憶體使用率。這項使用率是 Pod 要求總和除以節點可分配量，而非實際使用率。

遭淘汰的 Pod 清單會截斷為 50 個任意項目。實際遭淘汰的 Pod 數量會顯示在 evictedPodsTotalCount 欄位中。

使用下列查詢，確認叢集自動配置器是否已縮減節點：

resource.type="k8s_cluster" \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
log_id("container.googleapis.com/cluster-autoscaler-visibility") \
( "decision" NOT "noDecisionStatus" )

更改下列內容：

• CLUSTER_NAME：叢集名稱。

• COMPUTE_REGION：叢集的 Compute Engine 區域，例如 us-central1。

範例

以下記錄範例顯示 scaleDown 事件：

{
  "decision": {
    "decideTime": "1580594665",
    "eventId": "340dac18-8152-46ff-b79a-747f70854c81",
    "scaleDown": {
      "nodesToBeRemoved": [
        {
          "evictedPods": [
            {
              "controller": {
                "apiVersion": "apps/v1",
                "kind": "ReplicaSet",
                "name": "kube-dns-5c44c7b6b6"
              },
              "name": "kube-dns-5c44c7b6b6-xvpbk"
            }
          ],
          "evictedPodsTotalCount": 1,
          "node": {
            "cpuRatio": 23,
            "memRatio": 5,
            "mig": {
              "name": "test-cluster-default-pool-c47ef39f-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-f"
            },
            "name": "test-cluster-default-pool-c47ef39f-p395"
          }
        }
      ]
    }
  }
}

您也可以在未執行工作負載的節點上查看 scale-down 事件 (通常只有 DaemonSet 建立的系統 Pod)。

使用下列查詢查看事件記錄：

resource.type="k8s_cluster" \
resource.labels.project_id=PROJECT_ID \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
severity>=DEFAULT \
logName="projects/PROJECT_ID/logs/events" \
("Scale-down: removing empty node")

更改下列內容：

• PROJECT_ID：您的專案 ID。

• CLUSTER_NAME：叢集名稱。

• COMPUTE_REGION：叢集的 Compute Engine 區域，例如 us-central1。

EventResult 事件

當 scaleUp 或 scaleDown 事件成功或失敗時，系統會發出 eventResult 事件。這項事件包含事件 ID 清單 (來自 scaleUp 或 scaleDown 事件中的 eventId 欄位)，以及錯誤訊息。如果錯誤訊息為空白，表示事件已順利完成。eventResult 事件清單會匯總在 results 欄位中。

如要診斷錯誤，請參閱「ScaleUp 錯誤」和「ScaleDown 錯誤」一節。

範例

以下記錄範例顯示 eventResult 事件：

{
  "resultInfo": {
    "measureTime": "1582878896",
    "results": [
      {
        "eventId": "2fca91cd-7345-47fc-9770-838e05e28b17"
      },
      {
        "errorMsg": {
          "messageId": "scale.down.error.failed.to.delete.node.min.size.reached",
          "parameters": [
            "test-cluster-default-pool-5c90f485-nk80"
          ]
        },
        "eventId": "ea2e964c-49b8-4cd7-8fa9-fefb0827f9a6"
      }
    ]
  }
}

NodePoolCreated 事件

如果叢集自動配置器已啟用自動佈建節點功能，則建立新的節點集區時，系統會發出 nodePoolCreated 事件。這類事件包含已建立節點集區的名稱，以及基礎 MIG 清單。如果節點集區是因 scaleUp 事件而建立，則對應 scaleUp 事件的 eventId 會包含在 triggeringScaleUpId 欄位中。

範例

以下記錄範例顯示 nodePoolCreated 事件：

{
  "decision": {
    "decideTime": "1585838544",
    "eventId": "822d272c-f4f3-44cf-9326-9cad79c58718",
    "nodePoolCreated": {
      "nodePools": [
        {
          "migs": [
            {
              "name": "test-cluster-nap-n1-standard--b4fcc348-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-f"
            },
            {
              "name": "test-cluster-nap-n1-standard--jfla8215-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-c"
            }
          ],
          "name": "nap-n1-standard-1-1kwag2qv"
        }
      ],
      "triggeringScaleUpId": "d25e0e6e-25e3-4755-98eb-49b38e54a728"
    }
  }
}

NodePoolDeleted 事件

如果叢集自動配置器已啟用自動佈建節點功能，並刪除節點集區，系統就會發出 nodePoolDeleted 事件。

範例

以下記錄範例顯示 nodePoolDeleted 事件：

{
  "decision": {
    "decideTime": "1585830461",
    "eventId": "68b0d1c7-b684-4542-bc19-f030922fb820",
    "nodePoolDeleted": {
      "nodePoolNames": [
        "nap-n1-highcpu-8-ydj4ewil"
      ]
    }
  }
}

NoScaleUp 事件

如果叢集內有無法排定的 Pod，且叢集自動配置器無法擴充叢集來容納這些 Pod，系統就會定期發出 noScaleUp 事件。

• noScaleUp 事件會盡可能提供資訊，也就是說，這些事件不會涵蓋叢集自動配置器無法向上擴充的所有可能原因。
• noScaleUp 事件會受到節流限制，以限制產生的記錄量。每項持續原因每隔幾分鐘才會發出一次。
• 所有原因都可以任意拆分到多個事件中。舉例來說，我們無法保證單一 Pod 群組的所有 MIG 拒絕原因都會顯示在同一個事件中。
• 未處理的 Pod 群組清單會截斷為 50 個任意項目。如要查看未處理的 Pod 群組實際數量，請參閱 unhandledPodGroupsTotalCount 欄位。

原因欄位

下列欄位有助於說明為什麼向上擴充失敗：

• reason：提供全域原因，說明為什麼叢集自動配置器無法向上擴充。詳情請參閱「NoScaleUp 頂層原因」一節。
• napFailureReason：提供全域原因，說明叢集自動配置器無法佈建其他節點集區的原因 (例如自動佈建節點功能已停用)。詳情請參閱「NoScaleUp 頂層節點自動佈建原因」一節。
• skippedMigs[].reason：提供略過特定 MIG 的原因。在嘗試向上擴充期間，叢集自動配置器會略過某些 MIG，不考慮為任何 Pod 進行擴充 (例如，因為新增其他節點會超出整個叢集的資源限制)。詳情請參閱「NoScaleUp MIG 層級原因」一節。
• unhandledPodGroups：包含特定一組無法排程的 Pod 為何未觸發向上擴充的相關資訊。Pod 會依其直接控制器分組。沒有控制器的 Pod 會自成一組。每個 Pod 群組都包含任意範例 Pod 和群組中的 Pod 數量，以及下列原因：
  • napFailureReasons：叢集自動配置器無法佈建新節點集區來容納這個 Pod 群組的原因 (例如 Pod 有相似限制)。詳情請參閱「NoScaleUp Pod 層級節點自動佈建原因」一節。
  • rejectedMigs[].reason：叢集自動配置器無法增加特定 MIG 大小來容納這個 Pod 群組的個別 MIG 原因 (例如 MIG 的節點太小，無法容納 Pod)。詳情請參閱「NoScaleUp MIG 層級原因」一節。

範例

以下記錄範例顯示 noScaleUp 事件：

{
  "noDecisionStatus": {
    "measureTime": "1582523362",
    "noScaleUp": {
      "skippedMigs": [
        {
          "mig": {
            "name": "test-cluster-nap-n1-highmem-4-fbdca585-grp",
            "nodepool": "nap-n1-highmem-4-1cywzhvf",
            "zone": "us-central1-f"
          },
          "reason": {
            "messageId": "no.scale.up.mig.skipped",
            "parameters": [
              "max cluster cpu limit reached"
            ]
          }
        }
      ],
      "unhandledPodGroups": [
        {
          "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              "parameters": [
                "us-central1-f"
              ]
            }
          ],
          "podGroup": {
            "samplePod": {
              "controller": {
                "apiVersion": "v1",
                "kind": "ReplicationController",
                "name": "memory-reservation2"
              },
              "name": "memory-reservation2-6zg8m",
              "namespace": "autoscaling-1661"
            },
            "totalPodCount": 1
          },
          "rejectedMigs": [
            {
              "mig": {
                "name": "test-cluster-default-pool-b1808ff9-grp",
                "nodepool": "default-pool",
                "zone": "us-central1-f"
              },
              "reason": {
                "messageId": "no.scale.up.mig.failing.predicate",
                "parameters": [
                  "NodeResourcesFit",
                  "Insufficient memory"
                ]
              }
            }
          ]
        }
      ],
      "unhandledPodGroupsTotalCount": 1
    }
  }
}

NoScaleDown 事件

如有節點因叢集自動配置器而無法刪除，系統會定期發出 noScaleDown 事件。

• 如果節點因使用率過高而無法移除，則不會納入 noScaleDown 事件。
• NoScaleDown 事件會盡可能提供資訊，也就是說，這些事件不會涵蓋叢集自動配置器無法縮減的所有可能原因。
• NoScaleDown 事件會受到節流限制，以限制產生的記錄量。每隔幾分鐘才會發出一次持續原因。
• 節點清單會截斷為 50 個任意項目。實際節點數量則會顯示在 nodesTotalCount 欄位中。

原因欄位

下列欄位有助於說明縮減失敗的原因：

• reason：提供全域原因，說明為什麼叢集自動配置器無法縮減 (例如最近向上擴充後的輪詢週期)。詳情請參閱「NoScaleDown 頂層原因」一節。
• nodes[].reason：提供各節點的原因，說明叢集自動配置器無法刪除特定節點的原因 (例如，沒有地方可以移動節點的 Pod)。詳情請參閱「NoScaleDown 節點層級原因」一節。

範例

以下記錄範例顯示 noScaleDown 事件：

{
  "noDecisionStatus": {
    "measureTime": "1582858723",
    "noScaleDown": {
      "nodes": [
        {
          "node": {
            "cpuRatio": 42,
            "mig": {
              "name": "test-cluster-default-pool-f74c1617-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-c"
            },
            "name": "test-cluster-default-pool-f74c1617-fbhk"
          },
          "reason": {
            "messageId": "no.scale.down.node.no.place.to.move.pods"
          }
        }
      ],
      "nodesTotalCount": 1,
      "reason": {
        "messageId": "no.scale.down.in.backoff"
      }
    }
  }
}

訊息

叢集自動配置器發出的事件會使用參數化訊息，提供事件說明。parameters 欄位可與 messageId 欄位搭配使用，例如這個 NoScaleUp 事件記錄範例。

本節說明各種 messageId 及其對應的參數。不過，本節並未列出所有可能的訊息，且隨時可能擴充。

ScaleUp 錯誤

您可以在對應的 eventResult 事件中，找到 scaleUp 事件的事件錯誤訊息，位於 resultInfo.results[].errorMsg 欄位。

如果擴充作業因超出配額而失敗，則會發生節點建立錯誤，觸發系統輪詢延遲期，最長可達 30 分鐘。詳情請參閱「輪詢間隔時間」。

noScaleUp 事件的原因

如果叢集內有無法排定的 Pod，且叢集自動配置器無法擴充叢集來排定 Pod，系統就會定期發出 noScaleUp 事件。noScaleUp 事件會盡可能提供，但無法涵蓋所有可能情況。

NoScaleUp 頂層原因

noScaleUp 事件的最上層原因訊息會顯示在 noDecisionStatus.noScaleUp.reason 欄位中。訊息會包含叢集自動配置器無法向上擴充叢集的頂層原因。

NoScaleUp 頂層自動佈建節點原因

noScaleUp 事件的頂層自動佈建節點原因訊息會顯示在 noDecisionStatus.noScaleUp.napFailureReason 欄位中。訊息中會說明叢集自動配置器無法佈建新節點集區的主要原因。

NoScaleUp MIG 層級原因

noScaleUp 事件的 MIG 層級原因訊息會顯示在 noDecisionStatus.noScaleUp.skippedMigs[].reason 和 noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason 欄位中。訊息會說明叢集自動配置器無法增加特定 MIG 大小的原因。

NoScaleUp Pod 群組層級自動佈建節點原因

noScaleUp 事件的 Pod 群組層級自動佈建節點原因訊息會顯示在 noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[] 欄位中。訊息會說明叢集自動配置器無法佈建新節點集區，來排定特定 Pod 群組的原因。

ScaleDown 錯誤

您可以在對應的 eventResult 事件中，找到 scaleDown 事件的錯誤事件訊息，位於 resultInfo.results[].errorMsg 欄位。

noScaleDown 事件的原因

如果叢集自動配置器無法刪除節點，系統會定期發出 noScaleDown 事件。noScaleDown 事件會盡可能提供，但無法涵蓋所有可能的情況。

NoScaleDown 頂層原因

noScaleDown 事件的最上層原因訊息會顯示在 noDecisionStatus.noScaleDown.reason 欄位中。訊息會包含頂層原因，說明叢集自動配置器無法縮減叢集的原因。

NoScaleDown 節點層級原因

noScaleDown 事件的節點層級原因訊息會顯示在 noDecisionStatus.noScaleDown.nodes[].reason field 中。訊息會說明叢集自動配置器無法移除特定節點的原因。

後續步驟

• 進一步瞭解叢集自動配置器。
• 瞭解如何使用自動佈建節點功能。
• 排解叢集自動配置器未縮減的問題。
• 排解叢集自動配置器未向上擴充的問題。
• 觀看 YouTube 影片，瞭解如何排解及解決資源調度問題。