Container Service for Kubernetes (ACK) は、マネージドノードプール内のノードのステータスを監視します。 これにより、ACKクラスター内のノードが通常どおりに実行できるようになります。 マネージドノードプール内のノードで例外が発生すると、ACKは自動的にノードを修復します。 ノードプールを管理対象ノードプールとして構成すると、管理対象ノードプール内のノードの自動修復が自動的に有効になります。 このトピックでは、自動修復の使用シナリオと手順について説明します。
前提条件
管理対象ノードプールが作成されます。 詳細については、「ACK管理クラスターの作成」をご参照ください。
Kubernetesイベントセンターが有効になっています。 詳細については、「イベントモニタリング」をご参照ください。
自動修理をトリガーする条件
ノードプールの作成時にCVE脆弱性にパッチを適用するために必要なノードの再起動を有効にした場合、自動修復中にノードの排出やシステムディスクの交換などの操作が実行される可能性があります。 データの損失を避けるため、データをデータディスクに保存することを推奨します。
ACKは、ノードのステータス (条件) に基づいて自動修復タスクを実行するかどうかを決定します。 ノードのステータスを確認するには、kubectl describe nodeコマンドを実行し、出力のconditionフィールドの値を確認します。 ノードがしきい値を超える期間内に異常状態のままである場合、ACKはノードで修復タスクを自動的に実行します。 しきい値は、例外が発生した後、自動修復がトリガーされる前にノードが異常状態にとどまる最大期間です。
次の表に、トリガー条件を示します。
チェックアイテム | 説明 | [重大度] | しきい値 | 修正 |
KubeletNotReady(KubeletHung) | kubeletの実行が停止するため、ノードはNotReady状態になります。 | 高い | 180s |
|
KubeletNotReady(PLEG) | Pod Lifecycle Event Generator (PLEG) モジュールがヘルスチェックに合格しないため、ノードはNotReady状態になります。 | Medium | 180s |
|
KubeletNotReady(SandboxError) | サンドボックスポッドがないため、kubeletを起動できません。 | 高い | 180s |
|
RuntimeOffline | Dockerまたはcontainerdは実行を停止し、ノードは使用できません。 | 高い | 90年代 |
|
NTPProblem | 時刻同期サービス (ntpdまたはchronyd) が異常状態です。 | 高い | 10s | ntpdまたはchronydを再起動します。 |
SystemdOffline | Systemdは異常な状態であり、コンテナを起動または破壊することはできません。 | 高い | 90年代 | CVE脆弱性にパッチを適用する必要がある場合、ECSインスタンスを再起動します。 |
ReadonlyFilesystem | ノードファイルシステムが読み取り専用になります。 | 高い | 90年代 | CVE脆弱性にパッチを適用する必要がある場合、ECSインスタンスを再起動します。 |
手順
自動修復機能には、ノードの例外を診断し、自動修復をトリガーするかどうかを判断し、自動修復タスクを実行するフェーズが含まれます。
ノード診断は、NPDおよびKubernetesイベントセンターによって提供される統計に基づいて実行されます。 自動修復機能を使用する前に、NPDがインストールされ、Kubernetesイベントセンターが有効になっていることを確認してください。 詳細については、「イベントモニタリング」をご参照ください。
完全な自動修復手順中に、ノードは次の状態に遷移します。
Normal: ノードは例外なく実行されます。
エラー: ノードで例外が発生します。
回復に失敗しました: ノードは例外からの回復に失敗します。
ノードが異常状態に入り、閾値よりも長い期間、異常状態のままである場合、ACKは、ノードがエラー状態にあると判定する。
ノードがエラー状態と見なされた後、ACKは特定の自動修復タスクを実行して例外を修正し、イベントを生成します。
修復タスクの完了後にノード例外が修正された場合、ノードは通常状態に変わります。
修復タスクが完了してもノードの例外が続く場合、ノードは [回復に失敗] 状態に変わります。
クラスター内の複数のノードプールでノード例外が発生した場合、ACKはノードプールで自動修復タスクを並行して実行します。
ノードプール内の複数のノードで例外が発生した場合、ACKはノードで自動修復タスクを順番に実行します。 ACKがノードの1つを修復できない場合、ACKは残りのノードでの自動修復タスクの実行を停止します。
ACKがノードの修復に失敗した場合、ACKはそのノードの自動修復のトリガを停止する。 これは、ノードが例外から回復した後にのみ、そのノードの自動修復が再開されることを意味する。
自動修理イベント
自動修復がトリガーされると、ACKは関連するイベントをKubernetesイベントセンターに書き込みます。 Kubernetesイベントセンターで修復レコードと操作を表示するには、クラスターの詳細ページに移動し、左側のナビゲーションウィンドウで を選択します。
原因 | レベル | 説明 |
NodeRepairStart | 正常 | システムがノードの修復を開始します。 |
NodeRepairAction | 正常 | kubeletの再起動など、ノードの修復操作。 |
NodeRepairSucceed | 正常 | ノードは、修復操作が完了した後に例外から回復する。 |
NodeRepairFailed | 警告 | 修復操作が完了した後、ノードは例外からの回復に失敗します。 詳細は、「よくある質問」をご参照ください。 |
NodeRepairIgnore | 正常 | ノードは修復動作をスキップする。 ECSノードが [実行中] 状態でない場合、システムはノードの自動修復操作を実行しません。 |
よくある質問
ACKがノードの修復に失敗した場合はどうすればよいですか?
自動修復機能は、いくつかのシナリオで複雑なノード例外を修正できない場合があります。 自動修復タスクがノードで失敗した場合、または自動修復タスクが完了した後もノードの例外が続く場合、ノードは [回復に失敗] 状態になります。
ACKがノードプール内のノードの修復に失敗した場合、ノードが例外から回復するまで、ノードプール内のすべてのノードの自動修復のトリガーを停止します。 この場合、あなたはことができます
チケットを起票して、ノードを手動で修復するテクニカルサポートを依頼します。ノードの自動修復を無効にするにはどうすればよいですか?
ノードプール内のノードの自動修復を無効にするには、次のラベルをノードに追加します。
alibabacloud.com/repair.policy=disable関連ドキュメント
異常なノードを削除して再追加して問題を解決する場合は、ACKコンソールにログインし、[ノードプール] ページに移動します。 詳細については、「ノードの削除」および「既存のECSインスタンスをACKクラスターに追加」をご参照ください。
次の操作を実行しないでください。
kubectl delete nodeコマンドを実行してノードを削除します。ECSコンソールおよびAuto Scaling (ESS) コンソールでノードを削除および追加します。