Anthos clusters on bare metal は、ベアメタル向け Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

このページは Cloud Translation API によって翻訳されました。

ヘルスチェック

ヘルスチェックは、既存のクラスタの動作をテストしてモニタリングする方法です。ヘルスチェックは定期的かつ自動的に実行されます。bmctl を使用して、オンデマンドでヘルスチェックを実行することもできます。このドキュメントでは、各チェックの内容、どのような状況で自動的に実行されるか、手動で実行する方法とタイミング、結果の解釈方法について説明します。

チェック対象

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 チェックは次のとおりです。

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

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

kubelet がアクティブで、ノードマシンで実行中である。
containerd はアクティブで、ノードマシンで実行中であること。
Container Network Interface（CNI）ヘルスエンドポイントのステータスが正常。
Pod CIDR がノードマシンの IP アドレスと重複しません。

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

クラスタ全体のチェック

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

ネットワークチェック

次のクライアントサイドのクラスタノードでのネットワークチェックは、定期的なヘルスチェックの一環として自動的に実行されます。ネットワークチェックはオンデマンドで実行できません。これらのチェックは、クラスタの 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-operator
- controller-manager
- cluster-api-provider
- ais
- capi-kubeadm-bootstrap-system
- cert-manager
- kube-dns

アドオン

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

これらのチェックは、クラスタの Namespace の管理クラスタで実行されている bm-system-add-ons* という名前のベアメタル 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: リソースが存在する 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-system Namespace にあります。これらのリソースの更新はベストエフォートです。一時的なネットワークエラーなど、更新が失敗した場合、その失敗は無視されます。

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

ベアメタル HealthCheck GKE Enterprise HealthCheck 重大度

ベアメタル HealthCheck	GKE Enterprise HealthCheck	重大度
タイプ: マシン名前: `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`	省略可

タイプ: マシン

名前: 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 のステータスを取得するには:

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

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-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 は、設定された間隔で実行される対応するヘルスチェックのスケジュールを設定します。CronJob には、ノードへの Secure Shell（SSH）接続を確立してヘルスチェックを実行する ansible-runner コンテナも含まれています。

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

特定の 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 を使用すると、定期的なヘルスチェックのログを表示できます。

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 コンソールで、[ロギング] メニューの [ログエクスプローラ] ページに移動します。

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

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

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

[クエリ結果] ウィンドウに、ノードマシンの健全性チェックのログが表示されます。

以下に、定期的なヘルスチェックのクエリを示します。

ノードマシン

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
アドオン

クラスタの状態を確認するには、管理クラスタのベアメタル 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    56d
```
healthchecks.baremetal.cluster.gke.io の Pass フィールドは、最後のヘルスチェックが合格（true）か失敗（false）かを示します。

定期的なヘルスチェックのステータスの確認方法については、HealthCheck カスタムリソースとヘルスチェックログをご覧ください。

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

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

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

クラスタ構成ファイルを編集し、Cluster 仕様に 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
  ...

次の bmctl update コマンドを実行して、クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: 更新するクラスタの名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
定期的なヘルスチェックが無効になっていることを確認するには、次のコマンドを実行して、対応する healthchecks.baremetal.cluster.gke.io リソースが削除されていることを確認します。
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
次のように置き換えます。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
- CLUSTER_NAMESPACE: ヘルスチェックのターゲットクラスタの Namespace。

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

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

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

クラスタ構成ファイルを編集し、Cluster 仕様に 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
  ...

次の bmctl update コマンドを実行して、クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: 更新するクラスタの名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
定期的なヘルスチェックが有効になっていることを確認するには、次のコマンドを実行して、対応する healthchecks.baremetal.cluster.gke.io リソースが存在することを確認します。
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
次のように置き換えます。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
- CLUSTER_NAMESPACE: ヘルスチェックのターゲットクラスタの 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 は bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml のクラスタ構成ファイルを検索します。

クラスタの健全性を確認するには:
```
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 にも送信されます。ログの詳細については、ヘルスチェックログをご覧ください。

Google Cloud との接続性

すべてのクラスタノードマシンが 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 ランタイムのプリフライトチェック

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

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

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

構成ドリフトの検出

アドオンのヘルスチェックが実行されると、Google Distributed Cloud によって管理されるリソースの予期しない変更がチェックされます。具体的には、これらのリソースのマニフェストを評価して、外部エンティティによって変更が加えられたかどうかを判断します。これらのチェックは、クラスタの健全性に悪影響を及ぼす可能性のある意図しない変更を事前に警告するのに役立ちます。また、トラブルシューティングに役立つ情報も提供します。

チェックされるマニフェスト

いくつかの例外を除き、アドオンのヘルスチェックでは、クラスタのすべての Google Distributed Cloud マネージドリソースが確認されます。これらは、Google Distributed Cloud ソフトウェアによってインストールおよび管理されるリソースです。このようなリソースは数百あり、そのマニフェストのほとんどで構成ドリフトがチェックされます。マニフェストは、次のようなあらゆる種類のリソースに使用できます（ただし、これらに限定されません）。

ClusterRole
ClusterRoleBinding
CustomResourceDefinitions
DaemonSet
デプロイ
HorizontalPodAutoscalers
発行元

MetricsServers
MutatingWebhookConfigurations
Namespace
ネットワーク
NetworkLoggings
PodDisruptionBudgets
プロバイダ

ロール
RoleBinding
サービス
StorageClass
ValidatingWebhookConfigurations

チェックされないマニフェスト

設計上、一部のマニフェストは審査の対象外です。Google は、プライバシーとセキュリティ上の理由から、証明書、シークレット、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-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 フィールドを追加、削除、編集できます。ただし、Deployment の command セクション外のフィールドの編集は、アドオンチェックによって検出され、構成ドリフトとして報告されます。

すべての Deployment を除外する場合、ignore-resources の値は次のようになります。
```
...
data:
  ignore-resources: '[{"Kind":"Deployment"}]'
...
```
ignore-resources は JSON 文字列の配列を受け入れるため、複数の除外パターンを指定できます。問題のトラブルシューティングやクラスタのテスト中に構成ドリフトエラーをトリガーしたくない場合は、特定のリソースとリソースフィールド、またはより広範なリソースカテゴリの両方をドリフト検出から除外できるこの柔軟性が役立ちます。

ヘルスチェック

チェック対象

ノードマシンのチェック

クラスタ全体のチェック

ネットワークチェック

Kubernetes

アドオン

`HealthCheck`　カスタムリソース

ヘルスチェックの cron ジョブ

ヘルスチェックログ

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

Cloud Logging でログを確認する

定期的なヘルスチェック

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

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

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

アドオン

クラスタ

構成

Google Cloud との接続性

Kubernetes

ノード

プリフライト

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

最新のヘルスチェックを実行する

構成ドリフトの検出

チェックされるマニフェスト

チェックされないマニフェスト

追加のマニフェストまたはマニフェストの一部を審査から除外する方法

次のステップ

ヘルスチェック

チェック対象

ノードマシンのチェック

クラスタ全体のチェック

ネットワークチェック

Kubernetes

アドオン

HealthCheck カスタム リソース

ヘルスチェックの cron ジョブ

ヘルスチェック ログ

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

Cloud Logging でログを確認する

定期的なヘルスチェック

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

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

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

アドオン

クラスタ

構成

Google Cloud との接続性

Kubernetes

ノード

プリフライト

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

最新のヘルスチェックを実行する

構成ドリフトの検出

チェックされるマニフェスト

チェックされないマニフェスト

追加のマニフェストまたはマニフェストの一部を審査から除外する方法

次のステップ

`HealthCheck`　カスタムリソース

ヘルスチェックログ

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

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