ワーカー・ノードの再起動

Kubernetes Engine (OKE)を使用して作成したKubernetesクラスタでワーカー・ノードを再起動する方法を確認します。

ノート

拡張クラスタを使用している場合、ワーカー・ノードを再起動するためにノードのみを循環できます。拡張クラスタおよび基本クラスタの使用を参照してください。

ノードをサイクルして、仮想マシン・シェイプとベア・メタル・シェイプの両方でノードを再起動できます。

ノードを循環して、管理対象ノードと自己管理ノードの両方を再起動できます。

ワーカー・ノードをリブートすることが、ワーカー・ノードをホストしているコンピュート・インスタンスの問題を解決する最適な方法です。ワーカー・ノードを再起動すると、コンピュート・インスタンスの電源が再投入されます。これにより、たとえば、コンピュート・インスタンスのiptables内のすべてのルールがクリアされます。ベア・メタルGPUコンピュート・インスタンスの場合、ワーカー・ノードを再起動すると、次のような問題が解決される可能性があります:

  • GPUメモリーの温度が高いことが原因で、ジョブ・パフォーマンスまたはサーマル・スロットルの低下。
  • 予想されるGPU数より少ない数のレポート。
  • NVLinkエラー。NVIDIA Fabric Managerの起動に失敗するか、NCCLジョブの実行に失敗します。

Kubernetes Engineを使用すると、次のことができます:

  • 特定の管理対象ノードを再起動します。
  • 特定の自己管理ノードを再起動します。

ワーカー・ノードをサイクルして再起動すると、Kubernetes Engineはワーカー・ノードを停止する前に、ワーカー・ノードを自動的にコード化およびドレインします。その後、ワーカー・ノードをホストしているコンピュート・インスタンスが再起動されます。ワーカー・ノードをホストするコンピュート・インスタンスに送信されるshutdownコマンドは、削除猶予期間として指定した分数(ワーカー・ノードをコード化およびドレインできる時間の長さ)によって異なります。

  • ゼロ分の削除猶予期間を指定すると、RESETコマンドがコンピュート・インスタンスに送信されます。インスタンスの電源がただちに切断され、再び投入されます。
  • ゼロ分を超える削除猶予期間を指定すると、SOFTRESETコマンドがコンピュート・インスタンスに送信されます。オペレーティング・システムを停止するまで15分間待った後、インスタンスの電源が切断されて投入されます。

インスタンス自体は終了せず、同じOCIDとネットワーク・アドレスを保持することに注意してください。

ワーカー・ノードを再起動するためにサイクリングする場合、次の考慮事項に注意してください。

  • 管理対象ノードは個別にサイクルおよび再起動する必要があります。管理対象ノード・プールを選択してサイクルし、その中のすべての管理対象ノードを再起動することはできません。
  • コンソール、CLIまたはAPIを使用して、管理対象ノードをサイクルおよび再起動できます。
  • 自己管理ノードをサイクルおよび再起動するには、CLIまたはAPIを使用する必要があります。コンソールを使用して自己管理ノードをサイクルおよび再起動することはできません。

ノードのサイクリングおよびリブート時のコード付けおよびドレイン

個々のワーカー・ノード(管理対象ノードまたは自己管理ノードのいずれか)を選択し、そのノードをサイクルして再起動することを指定する場合は、「コードとドレイン」オプションを指定できます。管理対象ノードの場合、管理対象ノードに指定した「コードとドレイン」オプションは、ノード・プールに指定した「コードとドレイン」オプションをオーバーライドします。

詳細は、「停止または終了前の管理対象ノードのコード化とドレイン」を参照してください。

ワーカー・ノードの再起動

  • 特定の管理対象ノードを再起動するには:

    1. 「クラスタ」リスト・ページで、再起動するワーカー・ノードを含むクラスタの名前を選択します。リスト・ページまたはクラスタの検索に関するヘルプが必要な場合は、クラスタのリストを参照してください。
    2. 「リソース」で、「ノード・プール」を選択し、再起動するワーカー・ノードを含むノード・プールの名前を選択します。
    3. リブートするノードの横にある「アクション」メニューから「サイクル・ノード」を選択します。

    4. 「サイクル・ノード」ダイアログで:
      1. 「サイクリング・オプション」リストから「再起動ノード」を選択します。
      2. 再起動アクションを実行する前に、ワーカー・ノードをコード化およびドレインするタイミングと方法を指定し、次を指定します。

        • 削除猶予期間(分):アクションを実行する前にワーカー・ノードをコード化およびドレインできる時間の長さ。デフォルト値(60分)を受け入れるか、または別の値を指定します。たとえば、ワーカー・ノードをコード化し、ワークロードから排出する時間を30分に許可できます。ワーカー・ノードをコード化およびドレインせずにすぐにアクションを実行するには、0分を指定します。
        • 猶予期間の後にアクションを強制:ワーカー・ノードが正常にコード化および排出されていない場合でも、削除猶予期間の終了時にアクションを実行するかどうか。デフォルトでは、このオプションは選択されていません。

        「停止または終了前の管理対象ノードのコード化とドレイン」を参照してください。

      3. 「サイクル・ノード」を選択して、再起動操作を開始します。
    5. 「クラスタ詳細」ページで、関連する作業リクエストのステータスを表示して、操作の進行状況をモニターします(作業リクエストの詳細の取得を参照)。

  • 特定の管理対象ノードまたは自己管理ノードを再起動するには

    特定の管理対象ノードまたは自己管理ノードを再起動するには、oci ce cluster reboot-cluster-nodeコマンドと必要なパラメータを使用します:

    oci ce cluster reboot-cluster-node --cluster-id <cluster-ocid> --node-id <instance-ocid> [OPTIONS]

    例:

    oci ce cluster reboot-cluster-node --cluster-id ocid1.cluster.oc1.iad.aaaaaaaaaf______jrd --node-id ocid1.instance.oc1.iad.anu__flq --node-eviction-settings "{\"evictionGraceDuration\": \"PT0M\",\"isForceActionAfterGraceDuration\": true}"
  • OCI APIを使用して特定の管理対象ノードを再起動するには:

    RebootClusterNode操作を実行して、OCI APIを使用して特定の管理対象ノードを再起動します。

    Kubernetes APIを使用して管理対象ノードまたは自己管理ノードを再起動するには:

    ノート

    Kubernetes APIを使用して、(プラットフォーム・イメージまたはOKEイメージではなく)カスタム・イメージを使用する管理対象ノードまたは自己管理ノードを再起動するには、IAMポリシーがカスタム・イメージへのアクセスを提供する必要があります。そのようなポリシーがまだ存在しない場合は、次のポリシー・ステートメントを使用してポリシーを作成します。

    ALLOW any-user to read instance-images in TENANCY where request.principal.type = 'cluster'

    クラスタの作成とデプロイメントのためのポリシー構成を参照してください。

    1. 次のように、NodeOperationRuleカスタム・リソースを定義するyamlファイルを作成します。
      apiVersion: oci.oraclecloud.com/v1beta1
      kind: NodeOperationRule
      metadata:
        name: <rule-name>
      spec:
        actions:
          - "reboot"
        nodeSelector:
          matchTriggerLabel:
            oke.oraclecloud.com/node_operation: "<value>"
          matchCustomLabels:
            <custom-key>: "<value>"
        maxParallelism: <n>
        nodeEvictionSettings:
          evictionGracePeriod: <number-of-minutes>
          isForceActionAfterGraceDuration: <true|false>
      

      ここでは:

      • name: <rule-name>は、NodeOperationRuleカスタム・リソースに選択した名前を指定します。たとえば、name: my-reboot-ruleです
      • oke.oraclecloud.com/node_operation: "<value>"は、 oke.oraclecloud.com/node_operationラベル・キーに選択した値を指定します。リブートするノードには、このラベルのキーと値のペアがアタッチされている必要があります。例:
            matchTriggerLabel:
              oke.oraclecloud.com/node_operation: "my-reboot-value"

        oke.oraclecloud.com/node_operationラベル・キーに指定する値は、Kubernetesドキュメントの「ラベルおよびセレクタ」トピックの要件に準拠している必要があります。Kubernetes等価性ベースの要件のみがサポートされています。

      • matchCustomLabelsでは、オプションで、選択したキーと値のペアを含むカスタム・ラベルを<custom-key>: "<value>"の形式で指定します。オプションで、カスタム・ラベルのキーと値のペアを指定して、独自のユースケースに対応できます。例:
            matchCustomLabels:
              deployment: "green"

        指定するカスタム・ラベルのキーと値のペアは、Kubernetesドキュメントの「ラベルとセレクタ」トピックの要件に準拠している必要があります。Kubernetes等価性ベースの要件のみがサポートされています。

        マニフェストでカスタム・ラベルのキーと値のペアを指定した場合、ノードは、このカスタム・ラベルとoke.oraclecloud.com/node_operation: "<value>"ラベルの両方がある場合にのみ再起動されます。

      • maxParallelism: <n>は、パラレルに再起動するワーカー・ノードの数(最大20)を指定します。
      • evictionGracePeriod: <number-of-minutes>は、ワーカー・ノードを再起動する前に、ワーカー・ノードをコード化およびドレインできる時間の長さを指定します。デフォルト値(60分)を受け入れるか、または別の値を指定します。たとえば、ワーカー・ノードをコード化してワークロードから排出するために、30分を許可できます。ワーカー・ノードをコード化およびドレインせずにすぐに再起動するには、0分を指定します。
      • isForceActionAfterGraceDuration: <true|false>は、ワーカー・ノードが正常にコード化および排出されていない場合でも、削除猶予期間の終了時に再起動するかどうかを指定します。指定しない場合、falseにデフォルト設定されます。

      例:

      apiVersion: oci.oraclecloud.com/v1beta1
      kind: NodeOperationRule
      metadata:
        name: my-reboot-rule
      spec:
        actions:
          - "reboot"
        nodeSelector:
          matchTriggerLabel:
            oke.oraclecloud.com/node_operation: "my-reboot-value"
          matchCustomLabels:
            deployment: "green"
        maxParallelism: 2
        nodeEvictionSettings:
          evictionGracePeriod: 300
          isForceActionAfterGraceDuration: true
      
    2. 次のように入力して、kubectlを使用してyamlファイルをクラスタに適用します。

      kubectl apply -f <filename>.yaml
    3. 次のように入力して、kubectlを使用して、NodeOperationRuleカスタム・リソースが正常に作成されたことを確認します。

      kubectl get nor
    4. kubectlを使用して、次のように入力して、oke.oraclecloud.com/node_operationラベル・キーの値を指定するラベルをノードに追加します。

      kubectl label node <node-name> oke.oraclecloud.com/node_operation=<value>

      例:

      kubectl label node 10.0.10.53 oke.oraclecloud.com/node_operation=my-reboot-value
    5. カスタム・ラベルのキーと値のペアを指定するためにマニフェストにmatchCustomLabels要素を含めた場合は、kubectlを使用して、次のように入力して、キーと値のペアを指定するノードにラベルを追加します。
      kubectl label node <node-name> <custom-key>=<value>

      例:

      kubectl label node 10.0.10.53 deployment=green
    6. (オプション)次を入力して、進行中のノード再起動アクションを表示できます:

      kubectl describe nor <rule-name>
      例:
      kubectl describe nor my-reboot-rule
      出力例:
      Name:         my-reboot-rule
      Namespace:   
      Labels:       <none>
      Annotations:  <none>
      API Version:  oci.oraclecloud.com/v1beta1
      Kind:         NodeOperationRule
      Metadata:
        Creation Timestamp:  2025-02-11T00:11:11Z
        Finalizers:
          nodeoperationrule.oci.oraclecloud.com/finalizers
        Generation:        1
        Resource Version:  244259806
        UID:               xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      Spec:
        Actions:
          reboot
        Max Parallelism:  2
        Node Eviction Settings:
          Eviction Grace Period:                 300
          Is Force Action After Grace Duration:  true
        Node Selector:
          Match Trigger Label:
            oke.oraclecloud.com/node_operation:  my-reboot-value
          Match Custom Label:
            deployment: green
      Status:
        Back Off Nodes:
        Canceled Nodes:
        In Progress Nodes:
        	Node Name:        10.0.10.53
          Work Request Id:  ocid1.clustersworkrequest.oc1.phx.aaaa______jda
        Pending Nodes:
        Succeeded Nodes:
      Events:
        Type    Reason                  Age   From               Message
        ----    ------                  ----  ----               -------
        Normal  StartedNodeOperation    1m   NodeOperationRule  Started node operation on node with work request ID: 10.0.10.105: ocid1.clustersworkrequest.oc1.phx.aaaa______jda
      ```