ノードプールに対してマネージドノードプール機能を有効にすると、自動修復機能を有効にすることができます。Container Service for Kubernetes (ACK) は、ノードのステータスを自動的に監視し、ノードが期待どおりに動作しない場合に自動修復タスクを自動的に実行します。これにより、ノードの運用保守が簡素化されます。障害の複雑さのため、自動修復タスクではすべての障害を修復することはできず、特定の複雑な障害は手動で修復する必要があります。
前提条件
Kubernetes イベントセンターが有効になっており、ノードプールからのアラートイベントを受信し、 ack-node-problem-detector コンポーネントがインストールされてノードの例外を検出します。詳細については、「イベント監視」をご参照ください。
手順
新しいノードプールまたは既存のノードプールに対して [マネージドノードプール] パラメーターを設定できます。[障害のあるノードを再起動する] スイッチをオンにすると、ディスクのドレインや交換などの操作が自動修復プロセスに含まれる場合があります。ビジネスデータをディスクに保存することをお勧めします。
ノードプールを作成するときに自動修復を有効にする
ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[ノードプール] ページで、[ノードプールを作成] をクリックし、[マネージドノードプールを設定] で [マネージドノードプール] を選択し、[自動リカバリルール] を展開し、[障害のあるノードを再起動する] チェックボックスをオンにして、必要に応じて手順に従ってノードプールを作成します。
パラメーターの詳細については、「ノードプールを作成および管理する」をご参照ください。
既存のノードプールに対して自動修復を有効にする
ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
ノードプール リストで、管理するノードプールを見つけ、
> [マネージドノードプールを有効にする] (通常のノードプール) または [マネージドノードプールを構成する] (マネージドノードプール) を [アクション] 列で選択します。表示されるダイアログボックスで、[マネージドノードプールを構成する] 領域の [マネージドノードプール] を選択し、[自動復旧ルール] を展開して、[障害のあるノードを再起動する] を選択します。
自動修復をトリガーする条件
ACK は、ノードのステータス (condition) に基づいて、自動修復タスクを実行するかどうかを判断します。ノードのステータスを確認するには、kubectl describe node コマンドを実行し、コマンド出力の condition フィールドの値を確認します。ノードが [しきい値] を超える期間にわたって異常な状態のままになっている場合、ACK はノードで自動修復タスクを自動的に実行します。
ノードプールは、ノードの実行ステータスを監視します。ノードのステータスが 10 分以上報告されない場合、またはノードが NotReady 状態の場合、ACK はノードを再起動してノードの障害を修復します。この場合、ノード上のポッドが再起動されます。
次の表に、トリガー条件を示します。
項目 | 説明 | 重大度 | しきい値 | 操作 |
KubeletNotReady(KubeletHung) | kubelet の実行が停止したため、ノードは NotReady 状態です。 | 高 | 180s |
|
KubeletNotReady(PLEG) | Pod Lifecycle Event Generator (PLEG) モジュールがヘルスチェックに合格しなかったため、ノードは NotReady 状態です。 | 中 | 180s |
|
KubeletNotReady(SandboxError) | サンドボックス化されたポッドが見つからなかったため、kubelet を起動できません。 | 高 | 180s |
|
RuntimeOffline | Docker または containerd の実行が停止し、ノードが使用できません。 | 高 | 90s |
|
NTPProblem | 時刻同期サービス (ntpd または chronyd) が異常な状態です。 | 高 | 10s | ntpd または chronyd を再起動します。 |
SystemdOffline | Systemd が異常な状態であり、コンテナーを起動または破棄できません。 | 高 | 90s | [障害のあるノードを再起動する] が選択されている場合、Elastic Compute Service (ECS) インスタンスを再起動します。 |
ReadonlyFilesystem | ノードファイルシステムは読み取り専用です。 | 高 | 90s | [障害のあるノードを再起動する] が選択されている場合、Elastic Compute Service (ECS) インスタンスを再起動します。 |
自動修復イベント
自動修復がトリガーされると、ACK は関連イベントを [Kubernetes イベントセンター] に書き込みます。Kubernetes イベントセンターで修復レコードと操作を表示するには、クラスター詳細ページに移動し、左側のナビゲーションウィンドウで を選択します。イベントの詳細については、「イベント監視」をご参照ください。
原因 | レベル | 説明 |
NodeRepairStart | 標準 | システムがノードの修復を開始します。 |
NodeRepairAction | 標準 | kubelet の再起動など、ノードでの修復操作。 |
NodeRepairSucceed | 標準 | 修復操作の完了後、ノードは例外から回復します。 |
NodeRepairFailed | 警告 | 修復操作の完了後、ノードは例外から回復できません。詳細については、「FAQ」をご参照ください。 |
NodeRepairIgnore | 標準 | ノードは修復操作をスキップします。ECS ノードが Running 状態ではない場合、システムはノードで自動修復操作を実行しません。 |
実行ルールとプロセス
次のセクションでは、完全な自動修復プロセスについて説明します。
ノードが異常な状態になり、一定期間その状態のままになっている場合、ACK はノードがエラー状態であると判断します。
ノードがエラー状態であると見なされると、ACK は特定の自動修復タスクを実行して例外を修正し、イベントを生成します。
自動修復タスクの実行中は、ノードは修復中状態です。
自動修復タスクの完了後にノードの例外が修正された場合、ノードは標準状態になります。
修復タスクの完了後もノードの例外が解決しない場合、ノードは回復失敗状態になります。
ノードの修復に失敗した場合、自動修復タスクはトリガーされなくなります。つまり、ノードの自動修復は、ノードが例外から回復した後にのみ再開されます。
クラスターに複数のノードプールが含まれている場合、各ノードプールのノードで自動修復タスクを並行して実行できます。
ノードプール内の複数のノードで例外が発生した場合、ACK はノードで自動修復タスクを順番に実行します。ACK がノードの 1 つの修復に失敗した場合、ACK は残りのノードでの自動修復タスクの実行を停止します。
FAQ
ノードが自動的に修復されない場合はどうすればよいですか？
自動修復機能では、特定のシナリオで複雑なノードの例外を修正できない場合があります。ノードの自動修復タスクが失敗した場合、または自動修復タスクの完了後もノードの例外が解決しない場合、ノードは回復失敗状態になります。
ACK がノードプール内のノードの修復に失敗した場合、ACK はノードが例外から回復するまで、ノードプール内のすべてのノードで自動修復タスクの実行を停止します。テクニカルサポートに連絡するには、チケットを送信 してください。
関連情報
障害のあるノードを削除して新しいノードを追加して問題を解決する場合は、ACK コンソール の標準化されたプロセスを使用してノードを削除および追加する必要があります。これにより、予期しないエラーを防ぎます。詳細については、「ノードを削除する」および「既存の ECS インスタンスを追加する」をご参照ください。
クラスターの自動更新を有効にすることができます。詳細については、「クラスターを自動的に更新する」をご参照ください。