ノードの自動修復とヘルスチェック

Google Distributed Cloud では、定期的なヘルスチェックとノードの自動修復がデフォルトで有効になっています。

ノードの自動修復機能は、クラスタ内の異常なノードを継続的に検出して修復します。

定期的なヘルスチェックを 15 分ごとに実施します。このチェックは、gkectl diagnose cluster で実施されるチェックと同じです。結果は、管理クラスタ内のクラスタ オブジェクトのログとイベントとして表示されます。

管理クラスタとユーザー クラスタのそれぞれに、自動ノード修復に使用できる追加の IP アドレスがあることを確認します。

異常なノードの状態

次の状態は、ノードが異常であることを示します。

  • ノード条件 NotReady が約 10 分間、true である。

  • 正常に作成されてから、マシンの状態が約 10 分間 Unavailable である。

  • VM が作成されてから、マシンの状態が約 30 分間 Available にならない。

  • 約 10 分間 Available 状態のマシンに対応するノード オブジェクトがない（nodeRef が nil）。

  • ノード条件 DiskPressure が約 30 分間、true である。

ノード修復の戦略

Google Distributed Cloud は、ノードが上記のいずれか 1 つ以上の条件を満たした場合に、ノードの修復を開始します。

修復によって異常なノードがドレインされ、新しい VM が作成されます。ノードのドレインが 1 時間失敗しつづけると、修復プロセスによってドレインが強制され、アタッチされた Kubernetes 管理ディスクが安全にアタッチ解除されます。

同じ MachineDeployment に異常なノードが複数ある場合、一度に修復が行われるのはそのうちのいずれか 1 つのノードに対してのみです。

1 つのノードプールの 1 時間あたりの修復回数は、以下の回数に制限されます。

  • 3
  • ノードプール内のノード数の 10%

新しいクラスタのノードの修復とヘルスチェックの有効化

管理クラスタ、またはユーザー クラスタの構成ファイルで、autoRepair.enabled を true に設定します。

autoRepair:
  enabled: true

管理クラスタ、またはユーザー クラスタの作成手順を続行します。

既存のユーザー クラスタのノードの修復とヘルスチェックの有効化

ユーザー クラスタの構成ファイルで、autoRepair.enabled を true に設定します。

クラスタを更新します。

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

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

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

既存の管理クラスタのノードの修復とヘルスチェックの有効化

管理クラスタ構成ファイルで、autoRepair.enabled を true に設定します。

クラスタを更新します。

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパスで置き換えます。

ヘルス チェッカーから取得したログの表示

管理クラスタ内のすべてのヘルス チェッカー Pod の一覧を作成します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep cluster-health-controller

出力は次のようになります。

kube-system       cluster-health-controller-6c7df455cf-zlfh7   2/2   Running
my-user-cluster   cluster-health-controller-5d5545bb75-rtz7c   2/2   Running

特定のヘルス チェッカーから取得したログを表示するには、いずれかの Pod 内の cluster-health-controller コンテナのログを取得します。たとえば、上に記した出力に示す my-user-cluster のログを取得するには、次のようにします。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster logs \
    cluster-health-controller-5d5545bb75-rtz7c cluster-health-controller

ヘルス チェッカーから取得したイベントの表示

管理クラスタ内のすべてのクラスタ オブジェクトの一覧を作成します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get clusters --all-namespaces

出力は次のようになります。

default            gke-admin-ldxh7   2d15h
my-user-cluster    my-user-cluster   2d12h

特定のクラスタのイベントを表示するには、--show-events フラグを指定して kubectl describe cluster を実行します。たとえば、上の出力にある my-user-cluster のイベントを表示するには、次のようにします。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster \
    describe --show-events cluster my-user-cluster

出力例:

Events:
  Type     Reason             Age   From                                 Message
  ----     ------             ----  ----                                 -------
  Warning  ValidationFailure  17s   cluster-health-periodics-controller  validator for Pod returned with status: FAILURE, reason: 1 pod error(s).

ユーザー クラスタのノードの修復とヘルスチェックの無効化

ユーザー クラスタの構成ファイルで、autoRepair.enabled を false に設定します。

クラスタを更新します。

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

管理クラスタのノードの修復とヘルスチェックの無効化

管理クラスタ構成ファイルで、autoRepair.enabled を false に設定します。

クラスタを更新します。

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

ノードの自動修復のデバッグ

ノードの自動修復に関する問題は、管理クラスタ内のマシン オブジェクトとノード オブジェクトを記述することで調査できます。次に例を示します。

マシン オブジェクトの一覧を作成します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG  get machines

出力例:

default     gke-admin-master-wcbrj
default     gke-admin-node-7458969ff8-5cg8d
default     gke-admin-node-7458969ff8-svqj7
default     xxxxxx-user-cluster-41-25j8d-567f9c848f-fwjqt

マシン オブジェクトのうちの 1 つを記述します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine gke-admin-master-wcbrj

出力で、cluster-health-controller のイベントを探します。

同様に、ノード オブジェクトの一覧表示と記述を行うことができます。例:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe node gke-admin-master-wcbrj

ノードの手動修復

管理コントロール プレーン ノード

通常の手動修復は管理コントロール プレーン ノードでは機能しないため、専用の修復コマンドが用意されています。

gkectl repair admin-master を使用して、管理コントロール プレーン ノードを修復します。

コントロール プレーン V2 のユーザー クラスタのコントロール プレーン ノード

コントロール プレーン V2 ユーザー クラスタのコントロール プレーン ノードは、他のノードとは異なる方法で管理されます。

kubeception のユーザー クラスタと同様に、コントロール プレーン V2 のユーザー クラスタのコントロール プレーン マシン オブジェクトは管理クラスタ内にあります。また、ノードの自動修復は管理クラスタノードの自動修復の対象となります。

管理クラスタノードの自動修復ロジックで解決しないノードの問題がある場合、または管理クラスタノードの自動修復を有効にしていない場合は、手動修復を実施できます。これによりノードが削除され、再作成されます。

  1. ノードに対応するマシン オブジェクトの名前を取得します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get machines

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

    • ADMIN_CLUSTER_KUBECONFIG: 管理 kubeconfig ファイルのパス。
    • USER_CLUSTER_NAME: 対象とするユーザー クラスタの名前。

  2. マシン オブジェクトに repair アノテーションを追加します。

    kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true

    MACHINE_NAME は、マシン オブジェクトの名前に置き換えます。

  3. マシン オブジェクトを削除します。

    kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME

HA コントロール プレーン用にノードを 1 つずつ再作成します。そうしないと、コントロール プレーンが予期せず停止する可能性があります。

その他のノード

自動修復ロジックで解決しないノードの問題がある場合、またはノードの自動修復を有効にしていない場合は、手動修復を実施できます。これによりノードが削除され、再作成されます。

ノードに対応するマシン オブジェクトの名前を取得します。

kubectl --kubeconfig CLUSTER_KUBECONFIG get machines

CLUSTER_KUBECONFIG は、管理クラスタまたはユーザー クラスタの kubeconfig ファイルのパスに置き換えます。

マシン オブジェクトに repair アノテーションを追加します。

kubectl annotate --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true

MACHINE_NAME は、マシン オブジェクトの名前に置き換えます。

マシン オブジェクトを削除します。

kubectl delete --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME