すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:ノード自動修復の有効化

最終更新日:Apr 25, 2026

Container Service for Kubernetes (ACK) は、ノードのヘルス状態を自動的に監視し、障害を検出した際に修復処理を実行します。これにより、ノードの運用とメンテナンスが簡素化されます。ただし、ノード障害の複雑さゆえに、自動修復機能ではすべての障害を修復できるわけではありません。複雑な障害については、引き続き手動での修復が必要となる場合があります。

Lingjun ノードプールのノード自動修復に関する詳細については、「ノード自動修復の有効化」をご参照ください。

仕組み

以下のセクションでは、ノード自動修復プロセスについて説明します。

修復プロセス

次の表は、障害検出、通知、およびノード自動修復のエンドツーエンドのプロセスを示しています。

  1. 障害診断および検出

ACK は Node Problem Detector (NPD) コンポーネントを使用してノードの異常をチェックします。ノードのヘルスステータスが変化し、特定の期間異常な状態が継続した場合、ACK はそのノードを障害ありと判定します。

  1. 障害通知

障害が検出されると、ACK はノードの condition および Kubernetes イベントを生成します。イベントセンターでアラートを設定することで、通知を受け取ることができます。

  1. 排他的 GPU シナリオ)障害隔離

GPU 障害が検出された後、ACK は障害のある GPU カードを隔離します。

GPU 障害検出および自動隔離の詳細については、「GPU 障害検出および自動隔離」をご参照ください。
  1. システムおよび Kubernetes コンポーネント障害に対する自動修復の実行

ACK は、ノードの condition などの情報をもとに、修復タスクを開始するかどうかを判断します。kubectl describe node コマンドを実行することで、condition フィールド内のノードステータスを確認できます。

ACK がシステムまたは Kubernetes コンポーネントの障害を検出し、指定された しきい値(障害検出後にノード自動修復をトリガーするまで待機する時間)を超えて障害が継続している場合、自動的に修復タスクを開始します。ノード自動修復の完全なプロセスは以下のとおりです。

  1. ACK は、障害のあるシステムおよび Kubernetes コンポーネントを修復します。たとえば、kubelet やコンテナランタイムを再起動することがあります。

  2. システムおよびノードコンポーネントの自動修復のみを有効にする (ノードの再起動を許可) を選択しており、かつ初期の修復アクションが効果的でない場合、ACK は以下のステップを実行します。

    1. ACK は、障害のあるノードを自動的にスケジュール不可(unschedulable)に設定します。

    2. ACK は、再起動が必要な障害ノードをドレイン(drain)します。ドレイン操作は 30 分でタイムアウトします。

      ACK がノードをドレインする際には、設定された Pod Disruption Budget (PDB) を尊重しながら、利用可能なノードへ Pod を退避(evict)します。高可用性を確保するため、ワークロードは複数のレプリカで異なるノードにデプロイし、重要なサービスに対して PDB を設定して、同時に中断可能な Pod 数を制御することを推奨します。

      ドレイン操作が失敗した場合でも、ACK は以降のステップを継続します。

    3. ACK はノードを再起動します。

    4. ノードのステータスが正常に戻った後、ACK はノードを再度スケジュール可能(schedulable)にします。

      自動修復プロセス開始前にすでにノードがスケジュール不可に設定されていた場合、タスク完了後もスケジュール不可のまま維持されます。

修復タスク実行に関する注意事項:

  • 修復は一度に 1 つのノードプールに対して実行されます。

  • ノードプール内では、一度に 1 つの障害ノードに対してのみ修復が実行されます。修復が失敗した場合、ACK はそのプール内の他の障害ノードに対する処理を停止します。

自動修復をトリガーするノードの状態

ノードの condition

説明

リスクレベル

しきい値

修復アクション

KubeletNotReady(KubeletHung)

kubelet が予期せず停止し、ノードが NotReady 状態になります。

180s

  1. kubelet を再起動します。

  2. システムおよびノードコンポーネントの自動修復のみを有効にする (ノードの再起動を許可) を選択している場合、ECS インスタンスが再起動されます。

KubeletNotReady(PLEG)

PLEG のヘルスチェックが失敗し、ノードが NotReady 状態になります。

180s

  1. containerd または Docker を再起動します。

  2. kubelet を再起動します。

  3. システムおよびノードコンポーネントの自動修復のみを有効にする (ノードの再起動を許可) を選択している場合、ECS インスタンスが再起動されます。

KubeletNotReady(SandboxError)

PodSandbox が見つからず、kubelet が正しく起動できません。

180s

  1. 対応するサンドボックスコンテナを削除します。

  2. kubelet を再起動します。

RuntimeOffline

containerd または Docker が動作を停止し、ノードが利用できなくなります。

90s

  1. containerd または Docker を再起動します。

  2. システムおよびノードコンポーネントの自動修復のみを有効にする (ノードの再起動を許可) を選択している場合、ECS インスタンスが再起動されます。

NTPProblem

時刻同期サービス(ntpd または chronyd)が異常です。

10s

ntpd または chronyd を再起動します。

SystemdOffline

systemd の状態が異常で、コンテナの起動または停止ができません。

90s

システムおよびノードコンポーネントの自動修復のみを有効にする (ノードの再起動を許可) を選択している場合、ECS インスタンスが再起動されます。

ReadonlyFilesystem

ノードのファイルシステムが読み取り専用になりました。

90s

システムおよびノードコンポーネントの自動修復のみを有効にする (ノードの再起動を許可) を選択している場合、ECS インスタンスが再起動されます。

自動修復中のノードステータス

  • 修復タスクが進行中の間、ノードステータスは「Repairing」となります。

  • 修復タスクが完了し、障害が解消された場合、ノードは正常な状態に戻ります。

  • 修復タスク完了後も障害が継続している場合、ノードステータスは「Recovery failed」と設定されます。

    ノードが「Recovery failed」状態の場合、ACK はそのノードに対して自動修復を再度トリガーしません。基盤となる障害が解消された後でのみ、再度プロセスがトリガーされるようになります。

注意事項

  • この機能を利用するには、ノードプールイベントのアラート受信のためにイベントセンター、およびノード異常検出のための ack-node-problem-detector (NPD) コンポーネントが必要です。詳細については、「イベントモニタリング」をご参照ください。

  • この機能は ACK マネージドクラスター のみで利用可能であり、マネージド機能が有効化されたノードプールでサポートされています。

  • 以下の機能は段階的リリースとなっており、ロールアウトスケジュールが異なる場合があります。ご利用になるには、チケットを送信してください。

    • ノードインスタンス障害の自動修復:この機能はホワイトリストベースで提供されています。

    • アラートルールセット:ノード自動修復を有効化した後は、アラート管理を有効化し、クラスターノードの自己修復アラートルールセット および クラスター GPU モニタリングアラートルールセット を有効化することを推奨します。これにより、障害発生時にアラートを確実に受け取ることができます。これらのルールセットは段階的リリース中です。

      ルールセットの有効化方法については、「Container Service アラート管理」をご参照ください。
    • NPD バージョン:ノードインスタンス障害の自動修復には NPD 1.2.26 以降が必要です。バージョン 1.2.26 は段階的リリース中です。

ノード自動修復の有効化

新規または既存のノードプールに対して、マネージド構成を通じてノード自動修復を有効化および設定できます。

新規ノードプール

  1. ACK クラスター ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、ノード > ノードプール をクリックします。

  2. ノードプールの作成 をクリックします。マネージド設定 セクションで、マネージド型ノードプール を選択し、ノード自動修復を有効化します。さらに、システムまたは Kubernetes コンポーネント障害発生時にノードを再起動するかどうかを選択し、画面上の指示に従ってノードプールを作成します。

    image

    構成オプションの詳細については、「ノードプールの作成と管理」をご参照ください。ノード再起動に関する重要な注意事項については、前述のセクションをご確認ください。

既存ノードプール

  1. ACK クラスター ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、ノード > ノードプール をクリックします。

  2. ノードプール一覧で対象のノードプールを見つけ、アクション 列の image をクリックし、マネージド型ノードプールの有効化(標準ノードプールの場合)または マネージド設定(マネージドノードプールの場合)を選択します。マネージド設定マネージド型ノードプール に設定し、画面上の指示に従ってノード自動修復を有効化します。

    image

    構成オプションの詳細については、「ノードプールの作成と管理」をご参照ください。ノード再起動に関する重要な注意事項については、前述のセクションをご確認ください。

ノード自動修復イベントの確認

ACK がノード自動修復をトリガーすると、関連イベントが イベントセンター に記録されます。クラスター詳細ページで、操作 > イベントセンター を選択します。ノードイベント タブで、自動修復の記録および詳細を確認できます。また、関連イベントをサブスクライブすることも可能です。詳細については、「イベントモニタリング」をご参照ください。

イベント

レベル

説明

NodeRepairStart

Normal

ノード自動修復が開始されました。

NodeRepairAction

Normal

kubelet の再起動など、ノード自動修復アクションが実行されました。

NodeRepairSucceed

Normal

ノード自動修復が成功しました。

NodeRepairFailed

Warning

ノード自動修復が失敗しました。トラブルシューティングについては、「よくある質問」セクションをご参照ください。

NodeRepairIgnore

Normal

ノード自動修復がスキップされました。基盤となる ECS インスタンスが「実行中」状態でない場合、ノードに対してアクションは実行されません。

よくある質問

自動修復が失敗した場合はどうすればよいですか?

一部の障害は複雑であるため、自動修復機能ではすべての障害を修復できるわけではありません。ノード自動修復タスクが失敗した場合、またはタスク完了後も障害が継続している場合、ACK はノードステータスを「Recovery failed」とマークします。

ノードの自動修復が失敗した場合、ACK は基盤となる障害が解消されるまで、そのノードプールに対してさらなる修復をトリガーしません。チケットを送信して、テクニカルサポートにお問い合わせください。

関連ドキュメント