ヘルスチェックは、既存のクラスタの動作をテストしてモニタリングする方法です。ヘルスチェックは定期的かつ自動的に実行されます。gkectl diagnose cluster を使用して、オンデマンドでヘルスチェックを実行することもできます。このドキュメントでは、各チェックの内容、どのような状況で自動的に実行されるか、手動で実行する方法とタイミング、結果の解釈方法について説明します。
チェック対象
Google Distributed Cloud ヘルスチェックには、次の 2 つのカテゴリがあります。
ノードマシンのチェック
クラスタ全体のチェック
以下のセクションでは、各カテゴリでチェックされる内容について概説します。これらのチェックは、定期的なヘルスチェックとオンデマンド ヘルスチェックの両方に使用されます。
ノードマシンのチェック
このセクションでは、ノードマシンのヘルスチェックで評価される内容について説明します。これらのチェックでは、ノードマシンが正しく構成され、クラスタの作成、アップグレード、運用に十分なリソースと接続があることを確認します。
これらのチェックは、クラスタの Namespace の管理クラスタで実行される bm-system-NODE_IP_ADDRESS-machine という名前の Bare Metal HealthCheck カスタム リソース（bm-system-192.0.2.54-machine など）に対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。
一般的なマシンチェックは次のとおりです。
クラスタマシンが、サポートされているオペレーティング システム（OS）を使用している。
OS バージョンがサポートされている。
OS でサポート対象のカーネル バージョンが使用されている。
カーネルで、BPF Just In Time（JIT）コンパイラ オプションが有効（
CONFIG_BPF_JIT=y）になっている。Ubuntu の場合、Uncomplicated Firewall（UFW）が無効になっている。
ノードマシンが最小 CPU 要件を満たしている。
ノードマシンで使用可能な CPU リソースが 20% を超えている。
ノードマシンが最小メモリ要件を満たしている。
ノードマシンがディスク ストレージの最小要件を満たしている。
ノードマシンで時刻同期が構成されていること。
デフォルト ゲートウェイにパケットをルーティングするためのデフォルト ルートがノード内に存在する。
ドメイン ネーム システム（DNS）が機能している（クラスタがプロキシの背後で実行するように構成されている場合、このチェックはスキップされます）。
クラスタがレジストリ ミラーを使用するように構成されている場合、そのレジストリ ミラーにアクセスできる。
マシン Google Cloud チェックは次のとおりです。
Artifact Registry、
gcr.ioに到達可能である（クラスタがレジストリ ミラーを使用するように構成されている場合、このチェックはスキップされます）。Google API に到達できる。
マシンのヘルスチェックは次のもので構成されます。
kubeletがアクティブで、ノードマシンで実行中である。containerdはアクティブで、ノードマシンで実行中であること。Container Network Interface（CNI）ヘルス エンドポイントのステータスが正常。
Pod CIDR がノードマシンの IP アドレスと重複しないこと。
クラスタ全体のチェック
このセクションでは、クラスタのヘルスチェックで評価される内容について説明します。
デフォルトのチェック
定期的なヘルスチェックの一環として自動的に実行されるデフォルトのクラスタ チェックは、クラスタ ヘルスチェックの一環としてオンデマンドで実行することもできます。これらのチェックにより、Kubernetes クラスタ リソースが正しく構成され、正常に機能していることを確認します。
これらのチェックは、クラスタの Namespace の管理クラスタで実行されている bm-system-default-* リソースという名前のベアメタル HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。
デフォルトのクラスタは、次のリソースタイプと条件をチェックします。
DaemonSet
- 構成が有効
- DaemonSet が正常
デプロイ
- 構成が有効
- デプロイが正常
ノード（以下はすべてノードの状態です）
- ノードの準備完了ステータス
- kubelet ディスク圧力
- kubelet のメモリ負荷
- kubelet プロセス ID（PID）の負荷
- kubelet の再起動頻度
- kubelet が正常
- ネットワークの可用性
- containerd 関数
- containerd の再起動頻度
- Docker Overlay2 関数
- Docker の再起動頻度
- ネットワーク デバイスの登録解除イベントの頻度
- カーネルのデッドロック
- KubeProxy が正常
- 読み取り専用ファイル システム
Pod
- 構成が有効
- Pod が正常
- コンテナが正常
PodDisruptionBudget（PDB）
- 構成が有効
- PDB ランタイム関数
- PDB が Pod と一致
- 複数の PDB によって管理されていない Pod
リソース リクエスト
- ターゲット ノードの Pod に CPU リクエストとメモリ リクエストが設定されている
- ノードあたりの平均リソース リクエストがトラッキングされた上限内である
サービス
- 構成が有効
- サービスが正常
StatefulSet
- 構成が有効
- StatefulSet
ネットワーク チェック
次のクライアントサイドのクラスタ ノードでのネットワーク チェックは、定期的なヘルスチェックの一環として自動的に実行されます。ネットワーク チェックはオンデマンドで実行できません。これらのチェックは、クラスタの Namespace の管理クラスタで実行される bm-system-network という名前のベアメタル HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。
クラスタがバンドルされたロード バランシングを使用する場合、ロード バランシング ノードプールのノードにレイヤ 2 アドレス解決プロトコル（ARP）接続が必要です。VIP の検出には ARP が必要です。
コントロール プレーン ノードでは、GKE Identity Service が使用できるようにポート 8443 と 8444 が開いています。
コントロール プレーン ノードでは、
etcd-eventsインスタンスで使用できるようにポート 2382 と 2383 が開いています。
Kubernetes
プリフライト チェックと定期的なヘルスチェックの一環として自動的に実行される Kubernetes チェックは、オンデマンドで実行することもできます。これらのヘルスチェックは、リストされているコントロール プレーン コンポーネントのいずれかが欠落していてもエラーを返しません。このチェックは、コンポーネントが存在し、コマンド実行時にエラーがある場合にのみエラーを返します。
これらのチェックは、クラスタの Namespace の管理クラスタで実行されている bm-system-kubernetes リソースという名前のベアメタル HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。
API サーバーが機能している。
anetdオペレーターが正しく構成されています。すべてのコントロール プレーン ノードが動作可能です。
次のコントロール プレーン コンポーネントが正常に機能しています。
anthos-cluster-operatorcontroller-managercluster-api-provideraiscapi-kubeadm-bootstrap-systemcert-managerkube-dns
アドオン
アドオン チェックは、プリフライト チェックと定期的なヘルスチェックの一部として自動的に実行され、オンデマンドで実行することもできます。このヘルスチェックでは、リストに表示されているアドオンが不足していてもエラーは返されません。チェックは、アドオンが存在し、コマンド実行時にエラーが発生した場合にのみエラーを返します。
これらのチェックは、クラスタの Namespace の管理クラスタで実行されている bm-system-add-ons* という名前のベアメタル HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。
以下に示す Cloud Logging の Stackdriver コンポーネントと Connect Agent は動作可能です。
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-connect-agent
Google Distributed Cloud マネージド リソースでは、次のような手動変更の結果（構成ファイルのずれ）が表示されます。
フィールド値が更新されていない
オプションのフィールドが追加または削除されていない
リソースが削除されていない
ヘルスチェックで構成のずれが検出されると、bm-system-add-ons ベアメタル HealthCheck カスタム リソースの Status.Pass 値が false に設定されます。Failures セクションの Description フィールドには、変更されたリソースに関する詳細情報が含まれます。これには、次の情報が含まれます。
Version: リソースの API バージョン。Kind: リソースのオブジェクト スキーマ（Deploymentなど）。Namespace: リソースが存在する Namespace。Name: リソースの名前。Diff: レコードのリソース マニフェストと変更されたリソースのマニフェストの違いを文字列形式で比較します。
HealthCheck カスタム リソース
ヘルスチェックが実行されると、Google Distributed Cloud は HealthCheck カスタム リソースを作成します。HealthCheck カスタム リソースは永続的であり、ヘルスチェックのアクティビティと結果の構造化されたレコードが記録されます。HeathCheck カスタム リソースには次の 2 つのカテゴリがあります。
ベアメタル
HealthCheckカスタム リソース（API Version: baremetal.cluster.gke.io/v1）: これらのリソースには、定期的なヘルスチェックの詳細が提供されます。これらのリソースは、クラスタの Namespace の管理クラスタにあります。ベアメタルHealthCheckリソースは、ヘルスチェックの cron ジョブとジョブの作成を担当します。これらのリソースは、最新の結果で継続的に更新されます。Anthos
HealthCheckカスタム リソース（API Version: anthos.gke.io/v1）: これらのリソースは、ヘルスチェック指標のレポートに使用されます。これらのリソースは、各クラスタのkube-systemNamespace にあります。これらのリソースの更新はベスト エフォートです。一時的なネットワーク エラーなど、更新が失敗した場合、その失敗は無視されます。
次の表に、HealthCheck カテゴリのいずれかに作成されるリソースのタイプを示します。
| ベアメタル HealthCheck | Anthos HealthChecks | 重大度 |
|---|---|---|
|
タイプ: デフォルト 名前: 名前: 名前: 名前: 名前: 名前: 名前: 名前: |
タイプ: デフォルト 名前: 名前: 名前: 名前: 名前: 名前: 名前: 名前: |
重大 |
|
タイプ: マシン 名前: |
タイプ: マシン 名前: |
重大 |
|
タイプ: ネットワーク 名前: |
タイプ: ネットワーク 名前: |
重大 |
|
タイプ: Kubernetes 名前: |
タイプ: Kubernetes 名前: |
重大 |
|
タイプ: アドオン 名前: |
タイプ: アドオン 名前: 名前: |
省略可 |
HealthCheck のステータスを取得するには:
定期的なヘルスチェックの結果を読み取るには、関連するカスタム リソースを取得します。
kubectl get healthchecks.baremetal.cluster.gke.io \ --kubeconfig ADMIN_KUBECONFIG \ --all-namespacesADMIN_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: クラスタの 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-systemCLUSTER_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 には、ノードへの Secure Shell（SSH）接続を確立してヘルスチェックを実行する ansible-runner コンテナも含まれています。
cron ジョブに関する情報を取得するには:
特定のクラスタで実行された cron ジョブのリストを取得します。
kubectl get cronjobs \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE次のように置き換えます。
ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。CLUSTER_NAMESPACE: クラスタの 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 25dSCHEDULE列の値は、スケジュール構文で実行される各ヘルスチェック ジョブのスケジュールを示します。たとえば、bm-system-kubernetesジョブは毎日（* * *）毎時（*/1）17 分過ぎ（17）に実行されます。定期的なヘルスチェックの時間間隔は編集できませんが、いつ実行されるかを知ることはトラブルシューティングに役立ちます。特定の
CronJobカスタム リソースの詳細を取得します。kubectl describe cronjob CRONJOB_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE次のように置き換えます。
ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。CLUSTER_NAMESPACE: クラスタの 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: クラスタの 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 77mPod のログを取得します。
kubectl logs POD_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE次のように置き換えます。
POD_NAME: ヘルスチェック Pod の名前。ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。CLUSTER_NAMESPACE: クラスタの 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 コンソールで、[ロギング] メニューの [ログ エクスプローラ] ページに移動します。
[クエリ] フィールドに次の基本クエリを入力します。
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"[クエリ結果] ウィンドウに、ノードマシンの健全性チェックのログが表示されます。
以下に、定期的なヘルスチェックのクエリを示します。
デフォルト
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.*"
定期的なヘルスチェック
デフォルトでは、定期的なヘルスチェックは 1 時間ごとに実行され、次のクラスタ コンポーネントをチェックします。
クラスタの状態を確認するには、管理クラスタのベアメタル HealthCheck（healthchecks.baremetal.cluster.gke.io）カスタム リソースを確認します。ネットワーク、Kubernetes、アドオンのチェックは、クラスタレベルのチェックであるため、チェックごとに 1 つのリソースがあります。マシンチェックはターゲット クラスタ内のノードごとに実行されるため、ノードごとにリソースがあります。
特定のクラスタのベアメタル
HealthCheckリソースを一覧表示するには、次のコマンドを実行します。kubectl get healthchecks.baremetal.cluster.gke.io \ --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE次のように置き換えます。
ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。CLUSTER_NAMESPACE: ヘルスチェックのターゲット クラスタの 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 56dhealthchecks.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 ソフトウェアによってインストールおよび管理されるリソースです。このようなリソースは数百あり、マニフェストのほとんどで構成ドリフトがチェックされます。マニフェストは、次のようなあらゆる種類のリソースに使用できます（ただし、これらに限定されません）。
|
|
|
チェックされないマニフェスト
設計上、一部のマニフェストはチェックの対象外です。Google は、プライバシーとセキュリティ上の理由から、Certificate、Secret、ServiceAccount といった特定の種類のリソースを無視します。また、アドオンのチェックでは、一部のリソースとリソース フィールドが無視されます。これは、これらのリソースとリソース フィールドは変更されることが想定されており、変更によって構成ドリフト エラーが発生しないようにするためです。たとえば、オートスケーラーがこの値を変更する可能性があるため、Deployment の replicas フィールドは無視されます。
追加のマニフェストまたはマニフェストの一部をチェックから除外する方法
一般に、Google Distributed Cloud で管理されるリソースに変更を加える、または、変更を無視しないことをおすすめします。ただし、リソースを変更して固有のケースの要件に対応、または、問題を解決する必要がある場合もあります。このため、フリート内の各クラスタに ignore-config-drift ConfigMap が用意されています。これらの ConfigMap を使用して、チェックから除外するリソースと特定のリソース フィールドを指定します。
Google Distributed Cloud は、クラスタごとに ignore-config-drift ConfigMap を作成します。これらの ConfigMap は、管理（管理またはハイブリッド）クラスタの対応するクラスタ Namespace にあります。たとえば、2 つのユーザー クラスタ（user-one と user-two）を管理する管理クラスタ（admin-one）がある場合、user-one クラスタの ignore-config-drift ConfigMap は、cluster-user-one Namespace の admin-one クラスタにあります。
リソースまたはリソース フィールドをチェックから除外するには:
ignore-config-driftConfigMap に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 オブジェクトの各フィールドは省略可能であるため、さまざまな組み合わせが可能です。リソースのカテゴリ全体を除外することも、特定のリソースから特定のフィールドを除外することもできます。
たとえば、管理クラスタの
aisDeployment のcommandセクションの変更のみを無視するようにアドオン チェックを設定する場合、JSON は次のようになります。{ "Version": "apps/v1", "Kind": "Deployment", "Namespace": "anthos-identity-service", "Name": "ais", "Fields": [ "command" ] }次の例に示すように、この JSON オブジェクトを配列内の文字列値として
config-drift-ignoreConfigMap の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 設定の例では、構成ドリフトのエラーをトリガーすることなく、
aisDeployment のcommandフィールドを追加、削除、編集できます。ただし、Deployment のcommandセクション外のフィールドの編集はアドオン チェックによって検出され、構成ドリフトとして報告されます。すべての Deployment を除外する場合、
ignore-resourcesの値は次のようになります。... data: ignore-resources: '[{"Kind":"Deployment"}]' ...ignore-resourcesは JSON 文字列の配列を受け入れるため、複数の除外パターンを指定できます。問題のトラブルシューティングやクラスタのテスト中に構成ドリフトエラーをトリガーしたくない場合に、特定のリソースとリソースのフィールド、またはより広範なリソースのカテゴリの両方をドリフト検出から除外できるこの柔軟性が役立ちます。
次のステップ
詳しくは以下をご覧ください。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。
サポート リソースの詳細（以下の内容など）については、サポートの利用もご覧ください。
- サポートケースを登録するための要件。
- ログや指標など、トラブルシューティングに役立つツール。
- VMware 用 Google Distributed Cloud（ソフトウェアのみ）のサポートされているコンポーネント、バージョン、機能。