ヘルスチェックは、既存のクラスタの動作をテストしてモニタリングする方法です。ヘルスチェックは定期的かつ自動的に実行されます。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 | 重大度 |
---|---|---|
タイプ: マシン 名前: |
タイプ: マシン 名前: |
重大 |
タイプ: ネットワーク 名前: |
タイプ: ネットワーク 名前: |
重大 |
タイプ: Kubernetes 名前: |
タイプ: Kubernetes 名前: |
重大 |
タイプ: アドオン 名前: |
タイプ: アドオン 名前: 名前: |
省略可 |
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
: クラスタの 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。
次のサンプルは、一般的なレスポンスを示しています。
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
: クラスタの 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
: クラスタの 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
: クラスタの 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 時間ごとに実行され、次のクラスタ コンポーネントをチェックします。
クラスタの状態を確認するには、管理クラスタのベアメタル 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 ファイルのパス。
チェックされる内容のリストについては、このドキュメントの「チェックの対象」の次のセクションをご覧ください。
このチェックにより、管理ワークステーションのクラスタログ フォルダの 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 にも送信されます。ログの詳細については、ヘルスチェック ログをご覧ください。
プリフライト
bmctl
を使用してプリフライト チェックを実行する方法については、クラスタの作成でオンデマンド プリフライト チェックを実行するとクラスタ アップグレードでオンデマンド プリフライト チェックを実行するをご覧ください。
VM ランタイムのプリフライト チェック
Google Distributed Cloud の VM ランタイムのプリフライト チェックでは、Google Distributed Cloud の VM ランタイムと VM を使用する前に、一連のノードマシンの前提条件を検証します。Google Distributed Cloud の VM ランタイムのプリフライト チェックが失敗すると、VM の作成がブロックされます。VMRuntime
カスタム リソースで spec.enabled
が true
に設定されている場合、Google Distributed Cloud 上の VM ランタイムのプリフライト チェックが自動的に実行されます。
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
詳細については、Google Distributed Cloud の VM ランタイムのプリフライト チェックをご覧ください。