ヘルスチェック

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

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

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

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 重大度

タイプ: マシン

名前: 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-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 ジョブに関する情報を取得するには:

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

クラスタの状態を確認するには、管理クラスタのベアメタル HealthCheckhealthchecks.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.ioPass フィールドは、最後のヘルスチェックが合格(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 コマンドを実行して、クラスタを更新します。

    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 コマンドを実行して、クラスタを更新します。

    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、アドオンを確認します。クラスタ名を指定します。デフォルトでは、bmctlbmctl-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 にも送信されます。ログの詳細については、ヘルスチェック ログをご覧ください。

構成

クラスタ構成ファイルを確認します。 このチェックでは、構成ファイルを生成し、クラスタ構成の詳細を指定する構成ファイルを編集していることを前提としています。このコマンドの目的は、構成に誤りがあるか、構成が欠落しているか、構文エラーがあるかどうかを判断することです。クラスタ名を指定します。デフォルトでは、bmctlbmctl-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 にも送信されます。ログの詳細については、ヘルスチェック ログをご覧ください。

プリフライト

bmctl を使用してプリフライト チェックを実行する方法については、クラスタの作成でオンデマンド プリフライト チェックを実行するクラスタ アップグレードでオンデマンド プリフライト チェックを実行するをご覧ください。

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

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

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

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

次のステップ