ヘルスチェック

ヘルスチェックは、既存のクラスタのオペレーションのテストとモニタリングの方法です。ヘルスチェックは、単独で定期的に実行されます。bmctl を使用して、オンデマンドでヘルスチェックを実行することもできます。このドキュメントでは、それぞれのチェック、自動的に実行される状況、手動で実行する方法とタイミング、結果の解釈方法について説明します。

チェック対象

Google Distributed Cloud のヘルスチェックには、次の 2 つのカテゴリがあります。

• ノードマシンのチェック

• クラスタ全体のチェック

以下のセクションでは、各カテゴリのチェック項目の概要を説明します。これらのチェックは、定期的なヘルスチェックとオンデマンドの両方のヘルスチェックで使用されます。

ノードマシンのチェック

このセクションでは、ノードマシンのヘルスチェックで評価される内容について説明します。これらのチェックにより、ノードマシンが正しく構成され、クラスタの作成、クラスタのアップグレード、クラスタ オペレーションのための十分なリソースと接続があることを確認します。

これらのチェックは、クラスタの Namespace の管理クラスタで実行される bm-system-NODE_IP_ADDRESS-machine という名前の Bare Metal HealthCheck カスタム リソース（bm-system-192.0.2.54-machine など）に対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。

注: 一般的なマシンチェックとマシン Google Cloud チェックは、プリフライト チェックにも使用されます。

一般的なマシンチェックは、次のものから構成されます。

• クラスタマシンが、サポートされているオペレーティング システム（OS）を使用しています。

• OS バージョンがサポートされています。

• OS はサポートされているカーネル バージョンを使用しています。

• カーネルで、BPF Just In Time（JIT）コンパイラ オプションが有効（CONFIG_BPF_JIT=y）になっています。

• Ubuntu の場合、Uncomplicated Firewall（UFW）が無効になっています。

• ノードマシンが最小 CPU 要件を満たしていること。

• ノードマシンの CPU リソースが 20% 以上利用できる。

• ノードマシンが最小メモリ要件を満たしていること。

• ノードマシンが最小ディスク ストレージ要件を満たしていること。

• ノードマシンで時刻同期が構成されていること。

• デフォルト ゲートウェイにパケットをルーティングするためのデフォルト ルートはノード内に存在します。

• ドメイン ネーム システム（DNS）が機能している場合（クラスタがプロキシの背後で実行するように構成されている場合、このチェックはスキップされます）。

• クラスタがレジストリ ミラーを使用するように構成されている場合、そのレジストリ ミラーにアクセスできます。

マシンの Google Cloud チェックは、次のもので構成されています。

• Container Registry の gcr.io に到達可能（クラスタがレジストリ ミラーを使用するように構成されている場合、このチェックはスキップされます）。

• Google API に到達可能です。

マシンのヘルスチェックは、次のものから構成されます。

• kubelet はアクティブで、ノードマシンで実行中です。

• containerd はアクティブで、ノードマシンで実行中であること。

• Container Network Interface（CNI）のヘルス エンドポイントのステータスが正常です。

• Pod CIDR がノードマシンの IP アドレスと重複しません。

ノードマシンの要件の詳細については、クラスタノード マシンの前提条件をご覧ください。

クラスタ全体のチェック

このセクションでは、クラスタのヘルスチェックで評価される内容について説明します。

ネットワークチェック

次のクライアント側のクラスタノード ネットワーク チェックは、定期的なヘルスチェックの一環として自動的に実行されます。ネットワーク チェックをオンデマンドで実行することはできません。これらのチェックは、クラスタの名前空間の管理クラスタで実行される bm-system-network という名前の Bare Metal HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。

• クラスタでバンドル型ロード バランシングを使用する場合、ロード バランシング ノードプール内のノードにはレイヤ 2 アドレス解決プロトコル（ARP）接続が必要です。VIP の検出には ARP が必要です。

• コントロール プレーン ノードでは、GKE Identity Service で使用するためにポート 8443 と 8444 が開いています。

• コントロール プレーン ノードでは、etcd-events インスタンスで使用するためにポート 2382 と 2383 が開いています。

Google Distributed Cloud クラスタのプロトコルとポートの使用については、ネットワーク要件をご覧ください。

プリフライト チェックとしてのネットワーク チェックは、ネットワーク ヘルスチェックとは異なります。プリフライト チェックのネットワーク チェックのリストについては、クラスタ作成のプリフライト チェックまたはクラスタ アップグレードのプリフライト チェックをご覧ください。

Kubernetes

Kubernetes チェックは、プリフライト チェックと定期的なヘルスチェックの一環として自動的に実行されますが、オンデマンドで実行することもできます。リストされたコントロール プレーン コンポーネントのいずれかが欠落していても、これらのヘルスチェックはエラーを返しません。コンポーネントが存在し、コマンド実行時にエラーが発生した場合にのみ、チェックでエラーが返されます。

これらのチェックは、クラスタの Namespace の管理クラスタで実行されている bm-system-kubernetes リソースという名前の Bare Metal HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、HealthCheck カスタム リソースをご覧ください。

• API サーバーが機能しています。

• anetd 演算子が正しく構成されています。

• すべてのコントロール プレーン ノードが動作可能です。

• 次のコントロール プレーン コンポーネントは正常に動作しています。

  • anthos-cluster-operator

  • controller-manager

  • cluster-api-provider

  • ais

  • capi-kubeadm-bootstrap-system

  • cert-manager

  • kube-dns

アドオン

アドオン チェックは、プリフライト チェックと定期的なヘルスチェックの一環として自動的に実行され、オンデマンドで実行できます。リストされたアドオンのいずれかが見つからない場合、このヘルスチェックはエラーを返しません。このチェックでは、アドオンが存在し、コマンド実行時にエラーが発生した場合にのみ、エラーが返されます。

これらのチェックは、クラスタの Namespace の管理クラスタで実行されている bm-system-add-ons* リソースという名前の Bare Metal HealthCheck カスタム リソースに対応しています。ヘルスチェック リソースの詳細については、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 ベアメタル HealthCheck カスタム リソースの Status.Pass 値は false に設定されます。Failures セクションの Description フィールドには、変更されたリソースの詳細として、次の情報が含まれています。

• Version: リソースの API バージョン。
• Kind: リソースのオブジェクト スキーマ（Deployment など）。
• Namespace: リソースが存在する名前空間。
• Name: リソースの名前。
• Diff: レコードのリソース マニフェストと変更されたリソースのマニフェストの違いの文字列形式の比較。

HealthCheck　カスタム リソース

ヘルスチェックが実行されると、Google Distributed Cloud は HealthCheck カスタム リソースを作成します。HealthCheck カスタム リソースは永続的で、ヘルスチェックのアクティビティと結果の構造化レコードを提供します。HeathCheck カスタム リソースには、次の 2 つのカテゴリがあります。

• ベアメタル HealthCheck カスタム リソース（API Version: baremetal.cluster.gke.io/v1）: これらのリソースは、定期的なヘルスチェックの詳細を提供します。これらのリソースは、クラスタ Namespace の管理クラスタにあります。Bare Metal HealthCheck リソースは、ヘルスチェック cron ジョブとジョブの作成を担当します。これらのリソースは、最新の結果で一貫して更新されます。

• Anthos HealthCheck カスタム リソース（API Version: anthos.gke.io/v1）: これらのリソースは、ヘルスチェック指標のレポートに使用されます。これらのリソースは、各クラスタの kube-system 名前空間にあります。これらのリソースの更新はベスト エフォートです。一時的なネットワーク エラーなどの問題で更新が失敗した場合、その失敗は無視されます。

次の表に、いずれかの HealthCheck カテゴリ用に作成されるリソースの種類を示します。

ベアメタル ヘルスチェック	GKE Enterprise ヘルスチェック	重大度
タイプ: マシン 名前: bm-system-NODE_IP_ADDRESS-machine	タイプ: マシン 名前: bm-system-NODE_IP_ADDRESS-machine	重大
タイプ Network 名前: bm-system-network	タイプ Network 名前: bm-system-network	重大
タイプ: kubernetes 名前: bm-system-kubernetes	タイプ: kubernetes 名前: bm-system-kubernetes	重大
タイプ: アドオン 名前: bm-system-add-ons	タイプ: アドオン 名前: bm-system-add-ons-add-ons 名前: bm-system-add-ons-configdrift	省略可

HealthCheck ステータスを取得するには:

1. 定期的なヘルスチェックの結果を読み取るには、関連するカスタム リソースを取得します。

   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
   

   注: 定期的なヘルスチェック リソースには、baremetal.cluster.gke.io/periodic-health-check=true というラベルが付いています。

2. 特定のヘルスチェックの詳細を読み取るには、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
     ...
   

3. 指標のヘルスチェックのリストを取得するには、次のコマンドを使用します。

   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-10.200.0.3-machine                                            Healthy   56m
   kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
   kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
   kube-system   bm-system-kubernetes                                                    Healthy   57m
   kube-system   bm-system-kubernetes-1.16.1-non-periodic                                Healthy   25d
   kube-system   bm-system-network                                                       Healthy   32m
   kube-system   check-kubernetes-20231114-190445-non-periodic                           Healthy   3h6m
   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 は、対応するヘルスチェックが設定した間隔で実行されるようにスケジュールします。

cron ジョブに関する情報を取得するには:

1. 特定のクラスタに対して実行された 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 ジョブは毎日（* * *）毎時（*/1）17分過ぎ（17）に実行されます。定期的なヘルスチェックの時間間隔は編集できませんが、いつ実行されるかを知ることはトラブルシューティングの際に役立ちます。

2. 特定の 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
   

ヘルスチェック ログ

ヘルスチェックが実行されると、ログが生成されます。bmctl でヘルスチェックを実行する場合でも、定期的なヘルスチェックの一環として自動的に実行する場合でも、ログは Cloud Logging に送信されます。ヘルスチェックをオンデマンドで実行する場合、ログファイルは、管理ワークステーションのクラスタ フォルダの log/ ディレクトリ内のタイムスタンプ付きフォルダに作成されます。たとえば、test-cluster という名前のクラスタに対して bmctl check kubernetes コマンドを実行すると、bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923 のようなディレクトリにログが表示されます。

ローカルでログを表示する

kubectl を使用すると、定期的なヘルスチェックのログを表示できます。

1. 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
   

2. 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 に分類されます。

1. Google Cloud コンソールで、[ロギング] メニューの [ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

2. [クエリ] フィールドに次のベーシック クエリを入力します。

   resource.type="k8s_container"
   resource.labels.pod_name=~"bm-system.*-machine.*"
   

3. [クエリ結果] ウィンドウに、ノードマシンのヘルスチェックのログが表示されます。

定期的なヘルスチェックのクエリの一覧は次のとおりです。

• ノードマシン

  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 時間ごとに実行され、次のクラスタ コンポーネントをチェックします。

• マシン
• ネットワーク
• Kubernetes
• アドオン

クラスタの健全性は、管理クラスタの Bare Metal HealthCheck（healthchecks.baremetal.cluster.gke.io）カスタム リソースで確認できます。ネットワーク、Kubernetes、アドオンのチェックはクラスタレベルのチェックであるため、チェックごとに 1 つのリソースがあります。マシンチェックは、ターゲット クラスタ内の各ノードに対して実行されるため、各ノードにリソースがあります。

• 特定のクラスタの 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 カスタム リソースとヘルスチェックのログをご覧ください。

定期的なヘルスチェックを無効にする

デフォルトでは、すべてのクラスタで定期的なヘルスチェックが有効になっています。クラスタの定期的なヘルスチェックを無効にするには、Cluster リソースの periodicHealthCheck.enable フィールドを false に設定します。

定期的なヘルスチェックを無効にするには:

1. クラスタ構成ファイルを編集して、periodicHealthCheck.enable フィールドをクラスタ仕様に追加し、その値を false に設定します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user-basic
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user-basic
     namespace: cluster-user-basic
   spec:
     type: user
     profile: default
     ...
     periodicHealthCheck:
       enable: false
     ...
   

2. 次の bmctl update コマンドを実行して、クラスタを更新します。

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   次のように置き換えます。

   • CLUSTER_NAME: 更新するクラスタの名前。

   • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

3. 定期的なヘルスチェックが無効になっていることを確認するには、次のコマンドを実行して、対応する healthchecks.baremetal.cluster.gke.io リソースが削除されたことを確認します。

   kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
       --namespace=CLUSTER_NAMESPACE
   

   次のように置き換えます。

   • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

   • CLUSTER_NAMESPACE: ヘルスチェックのターゲット クラスタの名前空間。

定期的なヘルスチェックを再度有効にする

デフォルトでは、すべてのクラスタで定期的なヘルスチェックが有効になっています。定期的なヘルスチェックを無効にした場合は、クラスタ リソースの periodicHealthCheck.enable フィールドを true に設定することで再び有効にできます。

定期的なヘルスチェックを再度有効にするには:

1. クラスタ構成ファイルを編集して、periodicHealthCheck.enable フィールドをクラスタ仕様に追加し、その値を true に設定します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user-basic
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user-basic
     namespace: cluster-user-basic
   spec:
     type: user
     profile: default
     ...
     periodicHealthCheck:
       enable: true
     ...
   

2. 次の bmctl update コマンドを実行して、クラスタを更新します。

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   次のように置き換えます。

   • CLUSTER_NAME: 更新するクラスタの名前。

   • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

3. 定期的なヘルスチェックが有効になっていることを確認するには、次のコマンドを実行して、対応する healthchecks.baremetal.cluster.gke.io リソースが存在することを確認します。

   kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
       --namespace=CLUSTER_NAMESPACE
   

   次のように置き換えます。

   • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

   • CLUSTER_NAMESPACE: ヘルスチェックのターゲット クラスタの名前空間。

   （リソースが表示されるまでに数分かかることがあります。）

オンデマンド ヘルスチェック

以降のセクションでは、bmctl check を使用してオンデマンドで実行できるヘルスチェックについて説明します。bmctl check を使用してヘルスチェックを実行する場合、次のルールが適用されます。

• bmctl check コマンドでユーザー クラスタを確認する場合は、--kubeconfig フラグを使用して管理クラスタの kubeconfig ファイルのパスを指定します。

• ログは、管理ワークステーションのクラスタログ フォルダ内のタイムスタンプ付きのディレクトリ（デフォルトでは bmctl-workspace/CLUSTER_NAME/log）に生成されます。

• ヘルスチェックのログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェック ログをご覧ください。

bmctl コマンドのオプションの詳細については、bmctl コマンド リファレンスをご覧ください。

アドオン

指定したクラスタに対して指定した Kubernetes アドオンが動作可能であることを確認します。

• クラスタのアドオンを確認するには:

  bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  次のように置き換えます。

  • CLUSTER_NAME: 確認するクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

チェックされる項目のリストについては、このドキュメントの「チェック対象の項目」のアドオンをご覧ください。

このチェックにより、管理ワークステーションのクラスタログ フォルダにある check-addons-TIMESTAMP ディレクトリにログファイルが生成されます。ログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェックのログをご覧ください。

クラスタ

指定したクラスタのすべてのクラスタノード、ノード ネットワーキング、Kubernetes、アドオンを確認します。クラスタ名を指定すると、デフォルトでは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml のクラスタ構成ファイルを bmctl で検索します。

• クラスタの状態を確認するには、次のコマンドを実行します。

  bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  次のように置き換えます。

  • CLUSTER_NAME: 確認するクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

チェックされる項目のリストについては、このドキュメントの「チェック対象の項目」セクションの次のセクションをご覧ください。

• ノードマシンレベルのチェック
• ネットワークチェック
• Kubernetes
• アドオン

このチェックにより、管理ワークステーションのクラスタログ フォルダにある check-cluster-TIMESTAMP ディレクトリにログファイルが生成されます。ログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェックのログをご覧ください。

構成

クラスタ構成ファイルを確認します。このチェックは、構成ファイルが生成され、編集されてクラスタのクラスタ構成の詳細が指定されていることを前提としています。このコマンドの目的は、構成設定が正しくない、欠落している、または構文エラーがあるかどうかを判断することです。クラスタ名を指定すると、デフォルトで bmctl は bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml のクラスタ構成ファイルを検索します。

• クラスタ構成ファイルを確認するには、次のコマンドを実行します。

  bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  次のように置き換えます。

  • CLUSTER_NAME: 確認するクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

このコマンドは、クラスタ構成ファイルの YAML 構文、Google Cloud アクセス、クラスタ構成ファイルで指定されたサービス アカウントの権限を確認します。

このチェックにより、管理ワークステーションのクラスタログ フォルダにある check-config-TIMESTAMP ディレクトリにログファイルが生成されます。ログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェックのログをご覧ください。

GCP

すべてのクラスタノード マシンが Container Registry（gcr.io）と Google API エンドポイント（googleapis.com）にアクセスできることを確認します。

• 必要な Google Cloud リソースへのクラスタ アクセスを確認するには:

  bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  次のように置き換えます。

  • CLUSTER_NAME: 確認するクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

このチェックにより、管理ワークステーションのクラスタログ フォルダにある check-gcp-TIMESTAMP ディレクトリにログファイルが生成されます。ログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェックのログをご覧ください。

Kubernetes

コントロール プレーンで実行されている重要な Kubernetes オペレータの正常性を確認します。このチェックでは、重要なオペレーターが正常に動作していることと、Pod がクラッシュしていないことを確認します。コントロール プレーン コンポーネントのいずれかが欠落していても、このヘルスチェックはエラーを返しません。コンポーネントが存在し、コマンド実行時にエラーが発生した場合にのみ、エラーが返されます。

• クラスタ内の Kubernetes コンポーネントの正常性を確認するには、次のコマンドを実行します。

  bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  次のように置き換えます。

  • CLUSTER_NAME: チェックするノードが含まれているクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

確認する内容のリストについては、このドキュメントの「チェックする項目」の Kubernetes をご覧ください。

このチェックにより、管理ワークステーションのクラスタログ フォルダにある check-kubernetes-TIMESTAMP ディレクトリにログファイルが生成されます。ログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェックのログをご覧ください。

ノード

クラスタノード マシンが正しく構成されていること、およびクラスタのアップグレードとクラスタのオペレーションに十分なリソースと接続があることを確認します。

• クラスタ内のノードマシンの正常性を確認するには:

  bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
  

  次のように置き換えます。

  • CLUSTER_NAME: チェックするノードが含まれているクラスタの名前。
  • NODE_IP_ADDRESSES: ノードマシンの IP アドレスのカンマ区切りのリスト。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

確認する内容のリストについては、このドキュメントの「チェック」セクションのノードマシンのチェックをご覧ください。

このチェックでは、管理ワークステーションのクラスタログフォルダ内の check-nodes-TIMESTAMP ディレクトリに、各クラスタノード マシンのログファイルが生成されます。ログは Cloud Logging にも送信されます。ログの詳細については、ヘルスチェックのログをご覧ください。

プリフライト

Google Ads API（AdWords API）のbmctlプリフライト チェックを実行するには、クラスタ作成に対するオンデマンド プリフライト チェックの実行および クラスタ アップグレード用のオンデマンド プリフライト チェックを実行するをご覧ください。

VM ランタイムのプリフライト チェック

Google Distributed Cloud の VM ランタイムのプリフライト チェックは、Google Distributed Cloud と VM で VM ランタイムを使用する前に、ノードマシンの前提条件のセットを検証します。Google Distributed Cloud の VM ランタイムのプリフライト チェックが失敗すると、VM の作成はブロックされます。VMRuntime カスタム リソースで spec.enabled が true に設定されている場合、Google Distributed Cloud の VM ランタイムのプリフライト チェックは自動的に実行されます。

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

詳細については、Google Distributed Cloud の VM ランタイムのプリフライト チェックをご覧ください。

次のステップ

• ノードの問題の検出機能

• nettest でクラスタ接続を確認する

• クラスタの問題の診断に活用できるスナップショットを作成する