ヘルスチェック

ヘルスチェックは、既存のクラスタの動作をテストしてモニタリングする方法です。ヘルスチェックは定期的かつ自動的に実行されます。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 チェックは次のとおりです。

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

  • Google API に到達できる。

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

  • kubelet がアクティブで、ノードマシンで実行中である。

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

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

  • Pod CIDR がノードマシンの IP アドレスと重複していない。

  • kubeadm 証明書の有効期限が切れていない。
ノードマシンの要件の詳細については、クラスタ ノード マシンの前提条件をご覧ください。

クラスタ全体のチェック

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

デフォルトのチェック

定期的なヘルスチェックの一環として自動的に実行されるデフォルトのクラスタ チェックは、クラスタ ヘルスチェックの一環としてオンデマンドで実行することもできます。これらのチェックにより、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-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 Anthos HealthChecks 重大度

タイプ: デフォルト

名前: bm-system-default-daemonset

名前: bm-system-default-deployment

名前: bm-system-default-node

名前: bm-system-default-pod

名前: bm-system-default-poddisruptionbudget

名前: bm-system-default-resource

名前: bm-system-default-service

名前: bm-system-default-statefulset

タイプ: デフォルト

名前: bm-system-default-daemonset

名前: bm-system-default-deployment

名前: bm-system-default-node

名前: bm-system-default-pod

名前: bm-system-default-poddisruptionbudget

名前: bm-system-default-resource

名前: bm-system-default-service

名前: bm-system-default-statefulset

 重大

タイプ: マシン

名前: bm-system-NODE_IP_ADDRESS-machine

タイプ: マシン

名前: bm-system-NODE_IP_ADDRESS-machine

 重大

タイプ: ネットワーク

名前: bm-system-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

  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: クラスタの 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-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 ジョブに関する情報を取得するには:

  1. 特定のクラスタで実行された 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             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: クラスタの 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: クラスタの 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: クラスタの 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.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    56d

    healthchecks.baremetal.cluster.gke.io の Pass フィールドは、最後のヘルスチェックが合格（true）か失敗（false）かを示します。

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

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

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

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

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

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

    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: ヘルスチェックのターゲット クラスタの Namespace。

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

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

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

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

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

    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: ヘルスチェックのターゲット クラスタの 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 ファイルのパス。

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

このチェックにより、管理ワークステーションのクラスタログ フォルダの 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への接続性

すべてのクラスタノード マシンが Artifact 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 にも送信されます。ログの詳細については、ヘルスチェック ログをご覧ください。

プリフライト

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 ランタイムのプリフライト チェックをご覧ください。

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

既知の問題が特定されると、ヘルスチェック（とプリフライト チェック）が更新されます。インストールされているマイナー バージョンの最新のパッチイメージからチェックを実行するように bmctl に指示するには、--check-image-version latest オプション フラグを使用します。

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

CLUSTER_NAME は、確認するクラスタの名前に置き換えます。

これにより、クラスタをアップグレードせずに、最近特定された既知の問題を検出できます。

クラスタをインストールまたはアップグレードする前に、最新のプリフライト チェックを実行することもできます。詳細については、最新のプリフライト チェックを実行するをご覧ください。

ドリフトの検出を構成する

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

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

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

  • ClusterRole
  • ClusterRoleBinding
  • CustomResourceDefinition
  • DaemonSet
  • Deployment
  • HorizontalPodAutoscaler
  • Issuer
  • MetricsServer
  • MutatingWebhookConfiguration
  • Namespace
  • Network
  • NetworkLogging
  • PodDisruptionBudget
  • Provider
  • Role
  • RoleBinding
  • Service
  • StorageClass
  • ValidatingWebhookConfiguration

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

設計上、一部のマニフェストはチェックの対象外です。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 クラスタにあります。

リソースまたはリソース フィールドをチェックから除外するには:

  1. ignore-config-drift ConfigMap に data.ignore-resources フィールドを追加します。

    このフィールドには、JSON 文字列の配列を指定する必要があります。各文字列ではリソースを、また必要に応じてリソース内の特定のフィールドも指定します。

  2. リソースを指定し、無視する特定のフィールドを文字列配列内の 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 文字列の配列を受け入れるため、複数の除外パターンを指定できます。問題のトラブルシューティングやクラスタのテスト中に構成ドリフトエラーをトリガーしたくない場合に、特定のリソースとリソースのフィールド、またはより広範なリソースのカテゴリの両方をドリフト検出から除外できるこの柔軟性が役立ちます。

次のステップ

詳しくは以下をご覧ください。

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。サポート リソースの詳細（以下の内容など）については、サポートを受けるもご覧ください。

  • サポートケースを登録するための要件。
  • 環境構成、ログ、指標など、トラブルシューティングに役立つツール。
  • サポート対象のコンポーネント。