Google Distributed Cloud では、定期的なヘルスチェックとノードの自動修復がデフォルトで有効になっています。
ノードの自動修復機能は、クラスタ内の異常なノードを継続的に検出して修復します。
定期的なヘルスチェックを 15 分ごとに実施します。このチェックは、gkectl diagnose cluster で実施されるチェックと同じです。結果は、管理クラスタ内のクラスタ オブジェクトのログとイベントとして表示されます。
管理クラスタとユーザー クラスタのそれぞれに、自動ノード修復に使用できる追加の IP アドレスがあることを確認します。
高度なクラスタが有効になっている場合、自動修復の一部として定期的なヘルスチェックは実行されません。
高度なクラスタが有効になっていない場合の異常なノードの状態
enableAdvanceCluster が false の場合、次の状態はノードが異常であることを示します。
ノード条件
NotReadyが約 10 分間、trueである。正常に作成されてから、マシンの状態が約 10 分間
Unavailableである。VM が作成されてから、マシンの状態が約 30 分間
Availableにならない。約 10 分間
Available状態のマシンに対応するノード オブジェクトがない（nodeRef がnil）。ノード条件
DiskPressureが約 30 分間、trueである。
高度なクラスタが有効になっている場合の異常なノードの状態
enableAdvanceCluster が true の場合、次の状態はノードが異常であることを示します。
ノード条件
NotReadyが約 10 分間、trueである。ノード条件
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
高度なクラスタが有効になっていない場合のノードの自動修復のデバッグ
ノードの自動修復に関する問題は、管理クラスタ内の Machine オブジェクトと Node オブジェクトを記述することで調査できます。次に例を示します。
マシン オブジェクトの一覧を作成します。
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
高度なクラスタが有効になっている場合のノードの自動修復のデバッグ
ノードの自動修復に関する問題は、管理クラスタと対応するクラスタの Machine オブジェクトと Node オブジェクトの説明を取得することで調査できます。次に例を示します。
マシン オブジェクトの一覧を作成します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get machines
出力例:
NAMESPACE NAME NODEPOOL ci-1f6861fe28cac8fb390bc798927c717b 10.251.172.47 ci-1f6861fe28cac8fb390bc798927c717b-np ci-1f6861fe28cac8fb390bc798927c717b 10.251.173.64 ci-1f6861fe28cac8fb390bc798927c717b-cp ci-1f6861fe28cac8fb390bc798927c717b 10.251.173.66 ci-1f6861fe28cac8fb390bc798927c717b-cp ci-1f6861fe28cac8fb390bc798927c717b 10.251.174.19 ci-1f6861fe28cac8fb390bc798927c717b-np ci-1f6861fe28cac8fb390bc798927c717b 10.251.175.15 ci-1f6861fe28cac8fb390bc798927c717b-np ci-1f6861fe28cac8fb390bc798927c717b 10.251.175.30 ci-1f6861fe28cac8fb390bc798927c717b-cp kube-system 10.251.172.239 gke-admin-bnbp9-cp kube-system 10.251.173.39 gke-admin-bnbp9-cp kube-system 10.251.173.6 gke-admin-bnbp9-cp
Machine オブジェクトに対応するマシンの説明を取得します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine -n ci-1f6861fe28cac8fb390bc798927c717b 10.251.172.47
出力で、auto-repair-controller のイベントを探します。
同様に、ノード オブジェクトの一覧表示と記述を行うことができます。例:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes ... kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe node ci-1f6861fe28cac8fb390bc798927c717b-np
高度なクラスタが有効になっていない場合のノードの手動修復
管理コントロール プレーン ノード
通常の手動修復は管理コントロール プレーン ノードでは機能しないため、専用の修復コマンドが用意されています。
gkectl repair
admin-master を使用して、管理コントロール プレーン ノードを修復します。
Controlplane V2 のユーザー クラスタのコントロール プレーン ノード
Controlplane V2 ユーザー クラスタのコントロール プレーン ノードは、他のノードとは異なる方法で管理されます。
kubeception のユーザー クラスタと同様に、Controlplane V2 のユーザー クラスタのコントロール プレーンの Machine オブジェクトは管理クラスタ内にあります。また、ノードの自動修復は管理クラスタノードの自動修復の対象となります。
管理クラスタノードの自動修復ロジックで解決しないノードの問題がある場合、または管理クラスタノードの自動修復を有効にしていない場合は、手動修復を実施できます。これによりノードが削除され、再作成されます。
ノードに対応する Machine オブジェクトの名前を取得します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get machines
次のように置き換えます。
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。USER_CLUSTER_NAME: 対象とするユーザー クラスタの名前。
Machine オブジェクトに
repairアノテーションを追加します。kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
MACHINE_NAMEは、マシン オブジェクトの名前に置き換えます。Machine オブジェクトを削除します。
kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME
HA コントロール プレーン用にノードを 1 つずつ再作成します。そうしないと、コントロール プレーンが予期せず停止する可能性があります。
その他のノード
自動修復ロジックで解決しないノードの問題がある場合、またはノードの自動修復を有効にしていない場合は、手動修復を実施できます。これによりノードが削除され、再作成されます。
ノードに対応する Machine オブジェクトの名前を取得します。
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
CLUSTER_KUBECONFIG は、管理クラスタまたはユーザー クラスタの kubeconfig ファイルのパスに置き換えます。
Machine オブジェクトに repair アノテーションを追加します。
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
MACHINE_NAME は、Machine オブジェクトの名前に置き換えます。
Machine オブジェクトを削除します。
kubectl delete --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME
高度なクラスタが有効になっている場合のノードの手動修復
管理コントロール プレーン ノード
管理コントロール プレーン ノードの手動修復はサポートされていません
ユーザー クラスタのコントロール プレーン ノード / ワーカーノード
ノードの IP を使用してオブジェクトを照合し、ノードに対応する Inventory Machine オブジェクトの名前を取得します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get inventorymachines
次のように置き換えます。 ADMIN_CLUSTER_KUBECONFIG: 管理 kubeconfig ファイルのパス。USER_CLUSTER_NAME: 対象とするユーザー クラスタの名前。
force-remove アノテーションを Inventory Machine オブジェクトに追加します。
kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME inventorymachine MACHINE_NAME baremetal.cluster.gke.io/force-remove=true
MACHINE_NAME は、Machine オブジェクトの名前に置き換えます。
Inventory Machine オブジェクトを削除します。
kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME inventorymachine MACHINE_NAME
HA コントロール プレーン用にノードを 1 つずつ再作成します。そうしないと、コントロール プレーンが予期せず停止する可能性があります。