健康狀態檢查可用來測試及監控現有叢集的運作情形。健康狀態檢查會定期自行執行。您也可以使用 gkectl diagnose cluster
視需要執行健康狀態檢查。本文將說明各項檢查、自動執行的情況、手動執行的時間和方式,以及如何解讀結果。
檢查項目
Google Distributed Cloud 健康狀態檢查分為兩類:
節點機器檢查
叢集範圍檢查
以下各節將說明每個類別的檢查內容。這些檢查可用於定期和隨選健康狀態檢查。
節點機器檢查
本節說明節點機器的健康狀態檢查會評估哪些項目。這些檢查會確認節點機器的設定是否正確,以及節點機器是否有足夠的資源和連線能力,可供建立、升級及運作叢集。
這些檢查作業對應至叢集命名空間中,管理員叢集內執行的 Bare Metal HealthCheck
自訂資源,名稱為 bm-system-NODE_IP_ADDRESS-machine
(例如 bm-system-192.0.2.54-machine
)。如要進一步瞭解健康狀態檢查資源,請參閱HealthCheck
自訂資源。
常見的機器檢查包括:
叢集機器使用支援的作業系統 (OS)。
支援的 OS 版本。
作業系統使用支援的核心版本。
核心已啟用 BPF Just In Time (JIT) 編譯器選項 (
CONFIG_BPF_JIT=y
)。Ubuntu 的 Uncomplicated Firewall (UFW) 已停用。
節點電腦符合最低 CPU 需求。
節點機器的可用 CPU 資源超過 20%。
節點機器符合最低記憶體需求。
節點電腦符合最低磁碟儲存空間需求。
在節點電腦上設定時間同步。
節點中存在將封包轉送至預設閘道的預設路徑。
網域名稱系統 (DNS) 運作正常 (如果叢集設定為透過 Proxy 執行,系統會略過這項檢查)。
如果叢集已設定為使用登錄檔鏡像,則可連上登錄檔鏡像。
機器 Google Cloud 檢查包括下列項目:
Artifact Registry
gcr.io
可存取 (如果叢集已設定為使用登錄檔鏡像,則會略過這項檢查)。可連線到 Google API。
機器健康狀態檢查包含下列項目:
kubelet
已啟用,且正在節點機器上執行。containerd
已啟用,且正在節點機器上執行。容器網路介面 (CNI) 健康狀態端點狀態良好。
Pod CIDR 不會與節點機器的 IP 位址重疊。
叢集範圍檢查
本節說明叢集的健康狀態檢查會評估哪些項目。
預設檢查
預設叢集檢查會定期自動執行,您也可以視需要執行,做為叢集健康狀態檢查的一部分。這些檢查可確保 Kubernetes 叢集資源設定正確無誤,且運作正常。
這些檢查項目對應於叢集命名空間中管理員叢集內執行的 Bare Metal HealthCheck
自訂資源,名稱為 bm-system-default-*
。如要進一步瞭解健康狀態檢查資源,請參閱HealthCheck
自訂資源。
預設叢集檢查會稽核下列資源類型和條件:
DaemonSet
- 設定有效
- DaemonSet 運作狀態良好
部署作業
- 設定有效
- 部署作業的健康狀態良好
節點 (以下為所有節點條件)
- 節點就緒狀態
- kubelet 磁碟壓力
- kubelet 記憶體壓力
- kubelet 程序 ID (PID) 壓力
- kubelet 重新啟動頻率
- kubelet 狀態良好
- 網路可用性
- containerd 函式
- containerd 重新啟動頻率
- Docker Overlay2 函式
- Docker 重新啟動頻率
- 網路裝置取消註冊事件頻率
- 核心死結
- KubeProxy 狀態良好
- 唯讀檔案系統
Pod
- 設定有效
- Pod 狀態良好
- 容器健康狀態良好
PodDisruptionBudget (PDB)
- 設定有效
- PDB 執行階段函式
- PDB 與 Pod 相符
- Pod 不受多個 PDB 管理
資源要求
- 目標節點上的 Pod 已設定 CPU 和記憶體要求
- 每個節點的平均資源要求在追蹤限制內
服務
- 設定有效
- 服務健康狀態良好
StatefulSet
- 設定有效
- StatefulSet
網路檢查
下列用戶端叢集節點網路檢查會自動執行,做為定期健康狀態檢查的一部分。無法視需求執行網路檢查。這些檢查會對應至叢集命名空間中,在管理員叢集執行的 Bare Metal HealthCheck
自訂資源 (名為 bm-system-network
)。如要進一步瞭解健康狀態檢查資源,請參閱HealthCheck
自訂資源。
如果叢集使用隨附的負載平衡,負載平衡節點集區中的節點必須具備第 2 層位址解析通訊協定 (ARP) 連線能力。ARP 是探索 VIP 的必要條件。
控制層節點已開啟通訊埠 8443 和 8444,供 GKE Identity Service 使用。
控制層節點已開啟通訊埠 2382 和 2383,供
etcd-events
執行個體使用。
Kubernetes
Kubernetes 檢查會自動執行,是預檢和定期健康檢查的一環,您也可以視需要執行。如果缺少任何列出的控制平面元件,這些健康狀態檢查不會傳回錯誤。只有在元件存在且在指令執行時發生錯誤,檢查才會傳回錯誤。
這些檢查項目對應於叢集命名空間中管理員叢集內執行的 Bare Metal HealthCheck
自訂資源,名稱為 bm-system-kubernetes
。如要進一步瞭解健康狀態檢查資源,請參閱HealthCheck
自訂資源。
API 伺服器運作正常。
已正確設定
anetd
運算子。所有控制層節點都能運作。
下列控制層元件運作正常:
anthos-cluster-operator
controller-manager
cluster-api-provider
ais
capi-kubeadm-bootstrap-system
cert-manager
kube-dns
外掛程式
外掛程式檢查會自動執行,是預檢檢查和定期健康狀態檢查的一環,也可以視需要執行。如果缺少任何列出的外掛程式,這項健康狀態檢查不會傳回錯誤。只有在執行指令時,外掛程式存在且發生錯誤,檢查才會傳回錯誤。
這些檢查項目對應於叢集命名空間中,在管理員叢集內執行的 Bare Metal HealthCheck
自訂資源,名稱為 bm-system-add-ons*
。如要進一步瞭解健康狀態檢查資源,請參閱HealthCheck
自訂資源。
Cloud Logging Stackdriver 元件和 Connect Agent 可運作:
stackdriver-log-aggregator
stackdriver-log-forwarder
stackdriver-metadata-agent
stackdriver-prometheus-k8
gke-connect-agent
Google Distributed Cloud 管理的資源不會顯示任何手動變更 (設定差異):
欄位值未更新
未新增或移除選填欄位
資源未刪除
如果健康狀態檢查偵測到設定差異,bm-system-add-ons
Bare MetalHealthCheck
自訂資源 Status.Pass
值會設為 false
。Failures
區段中的 Description
欄位包含任何已變更資源的詳細資料,包括下列資訊:
Version
:資源的 API 版本。Kind
:資源的物件結構定義,例如Deployment
。Namespace
:資源所在的命名空間。Name
:資源名稱。Diff
:以字串格式比較記錄中的資源資訊清單,以及變更資源的資訊清單差異。
HealthCheck
自訂資源
執行健康狀態檢查時,Google Distributed Cloud 會建立HealthCheck
自訂資源。HealthCheck
自訂資源會持續存在,並提供健康狀態檢查活動和結果的結構化記錄。HeathCheck
自訂資源分為兩類:
Bare Metal
HealthCheck
自訂資源 (API Version: baremetal.cluster.gke.io/v1
):這些資源提供定期健康檢查的詳細資料。這些資源位於叢集命名空間中的管理員叢集。Bare MetalHealthCheck
資源負責建立健康狀態檢查的 Cron 工作和工作。這些資源會持續更新,提供最新結果。Anthos
HealthCheck
自訂資源 (API Version: anthos.gke.io/v1
): 這些資源用於回報健康檢查指標。這些資源位於每個叢集的kube-system
命名空間。我們會盡力更新這些資源。如果更新問題失敗 (例如暫時性網路錯誤),系統會忽略失敗。
下表列出為 HealthCheck
類別建立的資源類型:
Bare Metal 健康檢查 | Anthos 健康檢查 | 嚴重性 |
---|---|---|
類型:預設 名稱: 名稱: 名稱: 名稱: 名稱: 名稱: 名稱: 名稱: |
類型:預設 名稱: 名稱: 名稱: 名稱: 名稱: 名稱: 名稱: 名稱: |
重大 |
類型:機器
名稱: |
類型:機器
名稱: |
重大 |
類型:網路
名稱: |
類型:網路
名稱: |
重大 |
類型:kubernetes
名稱: |
類型:kubernetes
名稱: |
重大 |
類型:外掛程式
名稱: |
類型:外掛程式
名稱:
名稱: |
選用 |
如要擷取 HealthCheck
狀態,請按照下列步驟操作:
如要讀取定期健康狀態檢查的結果,可以取得相關聯的自訂資源:
kubectl get healthchecks.baremetal.cluster.gke.io \ --kubeconfig ADMIN_KUBECONFIG \ --all-namespaces
將
ADMIN_KUBECONFIG
替換為管理員叢集 kubeconfig 檔案的路徑。以下範例顯示定期執行的健康狀態檢查,以及上次執行檢查時是否通過:
NAMESPACE NAME PASS AGE cluster-test-admin001 bm-system-192.0.2.52-machine true 11d cluster-test-admin001 bm-system-add-ons true 11d cluster-test-admin001 bm-system-kubernetes true 11d cluster-test-admin001 bm-system-network true 11d cluster-test-user001 bm-system-192.0.2.53-machine true 56d cluster-test-user001 bm-system-192.0.2.54-machine true 56d cluster-test-user001 bm-system-add-ons true 56d cluster-test-user001 bm-system-kubernetes true 56d cluster-test-user001 bm-system-network true 56d
如要查看特定健康狀態檢查的詳細資料,請使用
kubectl describe
:kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
更改下列內容:
HEALTHCHECK_NAME
:健康狀態檢查的名稱。ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。CLUSTER_NAMESPACE
:叢集的命名空間。
查看資源時,
Status:
區段會包含下列重要欄位:Pass
:指出上次健康狀態檢查作業是否通過。Checks
:包含最近一次健康檢查作業的相關資訊。Failures
:包含最近一次失敗作業的相關資訊。Periodic
:包含健康檢查作業的排程和執行時間等資訊。
以下
HealthCheck
範例顯示機器檢查成功:Name: bm-system-192.0.2.54-machine Namespace: cluster-test-user001 Labels: baremetal.cluster.gke.io/periodic-health-check=true machine=192.0.2.54 type=machine Annotations: <none> API Version: baremetal.cluster.gke.io/v1 Kind: HealthCheck Metadata: Creation Timestamp: 2023-09-22T18:03:27Z ... Spec: Anthos Bare Metal Version: 1.16.0 Cluster Name: nuc-user001 Interval In Seconds: 3600 Node Addresses: 192.168.1.54 Type: machine Status: Check Image Version: 1.16.0-gke.26 Checks: 192.168.1.54: Job UID: 345b74a6-ce8c-4300-a2ab-30769ea7f855 Message: Pass: true ... Cluster Spec: Anthos Bare Metal Version: 1.16.0 Bypass Preflight Check: false Cluster Network: Bundled Ingress: true Pods: Cidr Blocks: 10.0.0.0/16 Services: Cidr Blocks: 10.96.0.0/20 ... Conditions: Last Transition Time: 2023-11-22T17:53:18Z Observed Generation: 1 Reason: LastPeriodicHealthCheckFinished Status: False Type: Reconciling Node Pool Specs: node-pool-1: Cluster Name: nuc-user001 ... Pass: true Periodic: Last Schedule Time: 2023-11-22T17:53:18Z Last Successful Instrumentation Time: 2023-11-22T17:53:18Z Start Time: 2023-09-22T18:03:28Z Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal HealthCheckJobFinished 6m4s (x2 over 6m4s) healthcheck-controller health check job bm-system-192.0.2.54-machine-28344593 finished
以下
HealthCheck
範例適用於機器檢查失敗的情況:Name: bm-system-192.0.2.57-machine Namespace: cluster-user-cluster1 ... API Version: baremetal.cluster.gke.io/v1 Kind: HealthCheck ... Status: Checks: 192.0.2.57: Job UID: 492af995-3bd5-4441-a950-f4272cb84c83 Message: following checks failed, ['check_kubelet_pass'] Pass: false Failures: Category: AnsibleJobFailed Description: Job: machine-health-check. Details: Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn]. Reason: following checks failed, ['check_kubelet_pass'] Pass: false Periodic: Last Schedule Time: 2023-10-24T23:04:21Z Last Successful Instrumentation Time: 2023-10-24T23:31:30Z ...
如要取得指標的健康狀態檢查清單,請使用下列指令:
kubectl get healthchecks.anthos.gke.io \ --kubeconfig CLUSTER_KUBECONFIG \ --namespace kube-system
將
CLUSTER_KUBECONFIG
替換為目標叢集 kubeconfig 檔案的路徑。以下範例顯示回應格式:
NAMESPACE NAME COMPONENT NAMESPACE STATUS LAST_COMPLETED kube-system bm-system-add-ons-add-ons Healthy 48m kube-system bm-system-add-ons-configdrift Healthy 48m kube-system bm-system-default-daemonset Healthy 52m kube-system bm-system-default-deployment Healthy 52m kube-system bm-system-default-node Healthy 52m kube-system bm-system-default-pod Healthy 52m kube-system bm-system-default-poddisruptionbudget Healthy 52m kube-system bm-system-default-resource Healthy 52m kube-system bm-system-default-service Healthy 52m kube-system bm-system-default-statefulset Healthy 57m kube-system bm-system-kubernetes Healthy 57m kube-system bm-system-network Healthy 32m kube-system component-status-controller-manager Healthy 5s kube-system component-status-etcd-0 Healthy 5s kube-system component-status-etcd-1 Healthy 5s kube-system component-status-scheduler Healthy 5s
健康狀態檢查 Cron 工作
如果是定期健康狀態檢查,每個裸機 HealthCheck
自訂資源都有對應的 CronJob
,名稱相同。這個 CronJob
會負責排定在設定的時間間隔執行相應的健康狀態檢查。CronJob
也包含 ansible-runner
容器,可透過建立與節點的安全殼層 (SSH) 連線,執行健康狀態檢查。
如要擷取 Cron 工作相關資訊:
取得特定叢集執行的 Cron 工作清單:
kubectl get cronjobs \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
更改下列內容:
ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。CLUSTER_NAMESPACE
:叢集的命名空間。
以下範例顯示一般回應:
NAMESPACE NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE cluster-test-admin bm-system-10.200.0.3-machine 17 */1 * * * False 0 11m 25d cluster-test-admin bm-system-add-ons 25 */1 * * * False 0 3m16s 25d cluster-test-admin bm-system-kubernetes 16 */1 * * * False 0 12m 25d cluster-test-admin bm-system-network 41 */1 * * * False 0 47m 25d
SCHEDULE
欄中的值會以排程語法,指出各項健康檢查工作的執行排程。舉例來說,bm-system-kubernetes
工作會在每天每小時的第 17 分鐘 (17
) 執行 (*/1
),每天都會執行 (* * *
)。定期健康狀態檢查的時間間隔無法編輯,但瞭解檢查的執行時間有助於進行疑難排解。擷取特定
CronJob
自訂資源的詳細資料:kubectl describe cronjob CRONJOB_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
更改下列內容:
ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。CLUSTER_NAMESPACE
:叢集的命名空間。
以下範例顯示成功的
CronJob
:Name: bm-system-network Namespace: cluster-test-admin Labels: AnthosBareMetalVersion=1.16.1 baremetal.cluster.gke.io/check-name=bm-system-network baremetal.cluster.gke.io/periodic-health-check=true controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613 type=network Annotations: target: node-network Schedule: 41 */1 * * * Concurrency Policy: Forbid Suspend: False Successful Job History Limit: 1 Failed Job History Limit: 1 Starting Deadline Seconds: <unset> Selector: <unset> Parallelism: <unset> Completions: 1 Active Deadline Seconds: 3600s Pod Template: Labels: baremetal.cluster.gke.io/check-name=bm-system-network Annotations: target: node-network Service Account: ansible-runner Containers: ansible-runner: Image: gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5 Port: <none> Host Port: <none> Command: cluster Args: -execute-command=network-health-check -login-user=root -controlPlaneLBPort=443 Environment: <none> Mounts: /data/configs from inventory-config-volume (ro) /etc/ssh-key from ssh-key-volume (ro) Volumes: inventory-config-volume: Type: ConfigMap (a volume populated by a ConfigMap) Name: bm-system-network-inventory-bm-system-ne724a7cc3584de0635099 Optional: false ssh-key-volume: Type: Secret (a volume populated by a Secret) SecretName: ssh-key Optional: false Last Schedule Time: Tue, 14 Nov 2023 18:41:00 +0000 Active Jobs: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 48m cronjob-controller Created job bm-system-network-28333121 Normal SawCompletedJob 47m cronjob-controller Saw completed job: bm-system-network-28333121, status: Complete Normal SuccessfulDelete 47m cronjob-controller Deleted job bm-system-network-28333061
健康狀態檢查記錄
健康狀態檢查執行時會產生記錄。無論您是使用gkectl diagnose cluster
執行健康狀態檢查,還是系統自動執行定期健康狀態檢查,記錄檔都會傳送至 Cloud Logging。視需要執行健康狀態檢查時,系統會在 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
中建立記錄檔。
在本地查看記錄
您可以透過 kubectl
查看定期健康狀態檢查的記錄:
取得 Pod,然後找出感興趣的特定健康檢查 Pod:
kubectl get pods \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
更改下列內容:
ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。CLUSTER_NAMESPACE
:叢集的命名空間。
下列範例回應顯示部分健康狀態檢查 Pod:
NAME READY STATUS RESTARTS AGE bm-system-10.200.0.4-machine-28353626-lzx46 0/1 Completed 0 12m bm-system-10.200.0.5-machine-28353611-8vjw2 0/1 Completed 0 27m bm-system-add-ons-28353614-gxt8f 0/1 Completed 0 24m bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c 0/1 Completed 0 75m bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk 0/1 Completed 0 74m bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj 0/1 Completed 0 67m bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj 0/1 Completed 0 77m bm-system-kubernetes-28353604-4tc54 0/1 Completed 0 34m bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn 0/1 Completed 0 63m bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z 0/1 Completed 0 77m ... bm-system-network-28353597-cbwk7 0/1 Completed 0 41m bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd 0/1 Completed 0 76m bm-system-network-preflight-check-create275a0fdda700cb2b44b264c 0/1 Completed 0 77m
擷取 Pod 記錄:
kubectl logs POD_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
更改下列內容:
POD_NAME
:健康狀態檢查 Pod 的名稱。ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。CLUSTER_NAMESPACE
:叢集的命名空間。
以下範例顯示節點機器健康狀態檢查成功時,部分 Pod 記錄的內容:
... TASK [Summarize health check] ************************************************** Wednesday 29 November 2023 00:26:22 +0000 (0:00:00.419) 0:00:19.780 **** ok: [10.200.0.4] => { "results": { "check_cgroup_pass": "passed", "check_cni_pass": "passed", "check_containerd_pass": "passed", "check_cpu_pass": "passed", "check_default_route": "passed", "check_disks_pass": "passed", "check_dns_pass": "passed", "check_docker_pass": "passed", "check_gcr_pass": "passed", "check_googleapis_pass": "passed", "check_kernel_version_pass": "passed", "check_kubelet_pass": "passed", "check_memory_pass": "passed", "check_pod_cidr_intersect_pass": "passed", "check_registry_mirror_reachability_pass": "passed", "check_time_sync_pass": "passed", "check_ubuntu_1804_kernel_version": "passed", "check_ufw_pass": "passed", "check_vcpu_pass": "passed" } } ...
以下範例顯示節點機器健康狀態檢查 Pod 記錄的部分內容,範例顯示
kubelet
檢查 (check_kubelet_pass
) 失敗,表示kubelet
未在這個節點上執行。... TASK [Reach a final verdict] *************************************************** Thursday 02 November 2023 17:30:19 +0000 (0:00:00.172) 0:00:17.218 ***** fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"} ...
在 Cloud Logging 中查看記錄
健康狀態檢查記錄會串流至 Cloud Logging,並可在記錄檔探索工具中查看。在控制台記錄中,定期健康狀態檢查會歸類為 Pod。
前往 Google Cloud 控制台的「Logging」選單,然後點選「Logs Explorer」頁面。
在「Query」(查詢) 欄位中,輸入下列基本查詢:
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"
「Query results」(查詢結果) 視窗會顯示節點電腦健康狀態檢查的記錄。
以下是定期健康狀態檢查的查詢清單:
預設
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.default-*"
節點機器
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"
網路
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-network.*"
Kubernetes
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-kubernetes.*"
外掛程式
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-add-ons.*"
定期健康狀態檢查
根據預設,系統每小時會執行一次定期健康狀態檢查,並檢查下列叢集元件:
您可以查看管理員叢集上的 Bare Metal HealthCheck
(healthchecks.baremetal.cluster.gke.io
) 自訂資源,瞭解叢集健康狀態。「網路」、「Kubernetes」和「外掛程式」檢查屬於叢集層級檢查,因此每項檢查都只有一個資源。系統會為目標叢集中的每個節點執行機器檢查,因此每個節點都有資源。
如要列出特定叢集的 Bare Metal
HealthCheck
資源,請執行下列指令:kubectl get healthchecks.baremetal.cluster.gke.io \ --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE
更改下列內容:
ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。CLUSTER_NAMESPACE
:健康檢查目標叢集的命名空間。
下列範例回應顯示格式:
NAMESPACE NAME PASS AGE cluster-test-user001 bm-system-192.0.2.53-machine true 56d cluster-test-user001 bm-system-192.0.2.54-machine true 56d cluster-test-user001 bm-system-add-ons true 56d cluster-test-user001 bm-system-kubernetes true 56d cluster-test-user001 bm-system-network true 56d
healthchecks.baremetal.cluster.gke.io
的Pass
欄位會指出上次健康狀態檢查是通過 (true
) 還是失敗 (false
)。
如要進一步瞭解如何檢查定期健康狀態檢查的狀態,請參閱HealthCheck
自訂資源和健康狀態檢查記錄。
隨選健康檢查
如要視需要執行健康狀態檢查,請使用 gkectl diagnose cluster
指令。使用 gkectl diagnose cluster
執行健康狀態檢查時,適用下列規則:
使用
gkectl diagnose cluster
指令檢查使用者叢集時,請使用--kubeconfig
旗標指定管理員叢集的 kubeconfig 檔案路徑。記錄會產生在管理員工作站叢集記錄資料夾中,以時間戳記命名的目錄 (預設為
/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
)。健康狀態檢查記錄也會傳送至 Cloud Logging。如要進一步瞭解記錄,請參閱「健康狀態檢查記錄」。
偵測設定偏移
執行外掛程式健康狀態檢查時,系統會檢查 Google Distributed Cloud 管理的資源是否出現非預期的變更。具體來說,這項檢查會評估這些資源的資訊清單,判斷外部實體是否進行變更。這些檢查可協助您預先發現可能對叢集健康狀態造成負面影響的無意變更。還能提供實用的疑難排解資訊。
檢查哪些資訊清單
除了少數例外狀況,外掛程式健康檢查會檢查叢集的所有 Google Distributed Cloud 管理資源。這些資源是由 Google Distributed Cloud 軟體安裝及管理。這類資源有數百個,且大多數資源的資訊清單都會檢查設定偏移。資訊清單適用於所有類型的資源,包括但不限於:
|
|
|
不會檢查哪些資訊清單
根據設計,我們不會審查部分資訊清單。基於隱私權和安全性考量,我們會忽略特定類型的資源,例如憑證、密鑰和 ServiceAccount。外掛程式檢查也會忽略部分資源和資源欄位,因為我們預期這些項目會變更,且不希望變更觸發設定漂移錯誤。舉例來說,這項檢查會忽略 Deployment 中的 replicas
欄位,因為自動配置器可能會修改這個值。
如何從審查中排除其他資訊清單或部分資訊清單
一般而言,我們建議您不要變更 Google Distributed Cloud 管理的資源,也不要忽略對這些資源所做的變更。不過,我們瞭解有時需要修改資源,才能因應特殊情況或修正問題。因此,我們會為機群中的每個叢集提供 ignore-config-drift
ConfigMap。您可以使用這些 ConfigMap 指定要從評估中排除的資源和特定資源欄位。
Google Distributed Cloud 會為每個叢集建立 ignore-config-drift
ConfigMap。這些 ConfigMap 位於管理 (管理或混合式) 叢集,且位於對應的叢集命名空間下。舉例來說,如果您有一個管理兩個使用者叢集 (user-one
和 user-two
) 的管理叢集 (admin-one
),您可以在 admin-one
叢集的 cluster-user-one
命名空間中,找到 user-one
叢集的 ignore-config-drift
ConfigMap。
如要排除資源或資源欄位,請按照下列步驟操作:
在
ignore-config-drift
ConfigMap 中新增data.ignore-resources
欄位。這個欄位會採用 JSON 字串陣列,每個字串都會指定資源,以及資源中的特定欄位 (選用)。
在字串陣列中,以 JSON 物件形式指定要忽略的資源和特定欄位 (選用):
資源和欄位的 JSON 物件結構如下:
{ "Version": "RESOURCE_VERSION", "Kind": "RESOURCE_KIND", "Namespace": "RESOURCE_NAMESPACE", "Name": "RESOURCE_NAME", "Fields": [ "FIELD_1_NAME", "FIELD_2_NAME", ... "FIELD_N_NAME" ] }
更改下列內容:
RESOURCE_VERSION
:(選用) 資源的apiVersion
值。RESOURCE_KIND
:(選用) 資源的kind
值。RESOURCE_NAMESPACE
:(選用) 資源的metadata.namespace
值。RESOURCE_NAME
:(選用) 資源的metadata.name
值。FIELD_NAME
:(選用) 指定要忽略的資源欄位陣列。如未指定任何欄位,外掛程式檢查會忽略資源的所有變更。
JSON 物件中的每個欄位都是選填,因此允許各種排列組合。您可以排除整個資源類別,也可以精確排除特定資源的特定欄位。
舉例來說,如果您希望外掛程式檢查忽略管理員叢集上
ais
Deployment 的command
區段變更,JSON 可能會如下所示:{ "Version": "apps/v1", "Kind": "Deployment", "Namespace": "anthos-identity-service", "Name": "ais", "Fields": [ "command" ] }
您會將這個 JSON 物件新增至
config-drift-ignore
ConfigMap 中的ignore-resources
,做為陣列中的字串值,如下列範例所示:apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: "2024-09-24T00:39:45Z" name: config-drift-ignore namespace: cluster-example-admin ownerReferences: - apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster name: example-admin ... data: ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]' ...
這個 ConfigMap 設定範例可讓您在
ais
Deployment 中新增、移除或編輯command
欄位,而不會觸發任何設定差異錯誤。不過,如果編輯「部署」中的command
區段以外的欄位,外掛程式檢查仍會偵測到,並回報為設定漂移。如要排除所有部署作業,
ignore-resources
值可能如下所示:... data: ignore-resources: '[{"Kind":"Deployment"}]' ...
由於
ignore-resources
接受 JSON 字串陣列,因此您可以指定多個排除模式。如果您正在排解叢集問題或進行叢集實驗,且不想觸發設定差異錯誤,可以靈活地從差異偵測中排除特定資源和資源欄位,或更廣泛的資源類別,這時這項功能就非常實用。
後續步驟
如要瞭解詳情,請參考下列資源:
如需其他協助,請與 Cloud Customer Care 團隊聯絡。
如要進一步瞭解支援資源,包括下列項目,請參閱「取得支援」: