IBM Cloud Docs
ワーカーノードとして割り当てられているホストの更新

ワーカーノードとして割り当てられているホストの更新

クラスタなどの Satellite 対応の IBM Cloud サービスにワーカー ノードとして割り当てられているホストの最新の OpenShift Container Platform、オペレーティング システム、およびセキュリティ パッチを取得するには、以下の手順を確認してください。

すべての IBM Cloud サービスの基盤となるプラットフォームであるサービスクラスタは、 Code Engine や IBM Cloud Object Storage などのサービスによって作成され、 IBM によって保守される。

アップデート中にアプリはどうなりますか?
更新対象のワーカー・ノード上でデプロイメントの一部として実行しているアプリは、クラスター内のその他のワーカー・ノードにスケジュール変更されます。 別のワーカー・プール内のワーカー・ノードにスケジュールされたり、スタンドアロン・ワーカー・ノードがある場合はそのノードにアプリがスケジュールされたりすることもあります。 アプリのダウン時間を回避するには、ワークロードに対応できるだけの十分な容量がクラスター内になければなりません。
アップデートやリロード中に一度にダウンするワーカーノードの数を制御するにはどうすればよいですか?
すべてのワーカー・ノードを稼働させる必要がある場合は、サービスに追加のホストを 接続 して 割り当てる ことを検討してください。 追加のホストを一時的にロケーションに追加し、更新が完了したらそれらを削除することができます。
さらに、 Kubernetes ConfigMap を作成し、更新中などに一度に利用できないワーカーノードの最大数を指定することもできます。 ワーカー・ノードは、ワーカー・ノード・ラベルで識別されます。 IBM 提供のラベルも、ワーカー・ノードに追加したカスタム・ラベルも使用できます。

ワーカー・ノードのホストでバージョン更新が使用可能かどうかを確認する

IBM Cloud CLI または IBM Cloud コンソールを使用して、ワーカー・ノードとして Satellite対応 IBM Cloud サービス に割り当てられているホストのバージョン更新が使用可能かどうかを確認できます。

各バージョン更新に含まれる変更を確認するには、Red Hat OpenShift on IBM Cloud のバージョン変更ログを参照してください。

バージョン更新が利用可能かどうかを IBM Cloud CLI で確認する

  1. IBM Cloud にログインします。 統合されたアカウントがある場合は、--sso オプションを使用します。
    ibmcloud login [--sso]
    
  2. アカウントの Satellite クラスターをリスト表示します。
    ibmcloud ks cluster ls --provider satellite
    
  3. バージョンを更新するクラスター内のワーカー・ノードをリストします。 出力で、バージョン更新が利用可能であることを示すメッセージが付随するアスタリスク * がないか確認します。
    ibmcloud ks worker ls -c <cluster_name_or_ID>
    
    出力例
    ID                Primary IP       Flavor   State    Status   Zone     Version   
    sat-worker-<ID>   <IP_address>     upi      normal   Ready    zone-1   4.5.35_1534_openshift*   
    
    * To update to 4.5.37_1537_openshift version, run 'ibmcloud ks worker replace'. Review and make any required version changes before you update: 'https://ibm.biz/upworker'
    

バージョン更新が利用可能かどうかを IBM Cloud コンソールで確認する

  1. Satellite コンソールにログインします。
  2. 更新するホストが含まれたロケーションをクリックします。
  3. **「ホスト」**タブをクリックします。
  4. ホスト・リストから、更新するホストの**「クラスター」**へのリンクをクリックします。 新しいタブが開いて、Red Hat OpenShift on IBM Cloud クラスターの詳細が表示されます。
  5. **「ワーカー・ノード」**タブをクリックします。
  6. バージョン欄で、アイコンをクリックしたときに「 Update available 」と表示される情報アイコンがあるかどうかを確認する。 利用可能な更新がない場合は、アイコンは表示されません。
  7. バージョン更新がメジャー更新、マイナー更新、パッチ更新のいずれであるかを確認します

ワーカー・ノード・ホストの識別

ホストがコントロール・プレーンの一部であるか、管理対象サービスに割り当てられているか、ロケーションに接続されているかを判別します。

  1. ロケホストをリストアップし、そのIDを控えておく。 ワーカーノードホストには、出力の Cluster 列に infrastructure がありません。

    ibmcloud sat host ls --location <location>
    

    出力例を示します。

    Name           ID                     State      Status   Zone     Cluster          Worker ID                                              Worker IP   
    
    satdemo-cp1    0bc3b92f55968a230985   assigned   Ready    zone-1   infrastructure   sat-satdemocp1-2bda578e901b4047c6e48d766cd99bc11a45fddd   169.62.42.178   
    satdemo-cp2    999cd38c39ddffe4b672   assigned   Ready    zone-2   infrastructure   sat-satdemocp2-940134e69c2609c5421b2426a7640fa80569668d   169.62.42.183   
    satdemo-cp5    6ca4fd8fcad1fa622aa4   assigned   Ready    zone-3   infrastructure   sat-satdemocp5-d46581b509357ea4b429fddc38a18b155463bf1c   169.62.42.181   
    satdemo-cp4    1ac2b92f55968a333335   assigned   Ready    zone-1   satdemo-cluster  sat-satdemocp4-2bda578e901b4047c6e48d766cd99bc11a45fddd   169.62.42.180   
    satdemo-cp6    234cd56c78ddffe4b672   assigned   Ready    zone-2   satdemo-cluster  sat-satdemocp6-940134e69c2609c5421b2426a7640fa80569668d   169.62.42.179   
    satdemo-cp3    8fg4ff8faaa1fa622bb5   assigned   Ready    zone-3   satdemo-cluster  sat-satdemocp3-d46581b509357ea4b429fddc38a18b155463bf1c   169.62.42.182  
    
  2. ワーカー・ノードとして Satellite 対応 IBM Cloud サービスに割り当てられている現在のホストをリストし、それらの ID をメモします。

    ibmcloud ks worker ls -c <cluster_name_or_ID>
    

    出力例を示します。

    ID                                                        Primary IP     Flavor   State    Status   Zone        Version   
    sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7   10.241.0.4     upi      normal   Ready    us-east-2   4.7.55_1575_openshift   
    sat-satellitei-854beae4556401b5761e34ed849ba64c4b0a674c   10.241.128.4   upi      normal   Ready    us-east-1   4.7.55_1575_openshift   
    sat-satellitei-bf1fc9b135011d5c0d9d500855db6e489d15610b   10.241.64.4    upi      normal   Ready    us-east-3   4.7.55_1575_openshift    
    

ワーカー・ノード・ホストを切り離すことなく、ワーカー・ノード・ホストにバージョン更新を適用する

ワーカー・ノード・ホストは、ロケーションから切り離すことなく更新できます。 ConfigMapを使用して、ワーカー・ノード・ホストのローリング更新を実行することもできます。

開始前に

  • すべてのワーカー・ノードが正常な状態であることを確認します。
  • 永続ブロック・ストレージ・ボリュームを使用している場合は、更新を開始する前に、これらのボリュームをノードから切り離す必要があります。 更新の必要がない別のワーカー・ノードに永続ボリュームを移動します。 次に、 kubectl drain NODENAME コマンドを使用して更新するために、ワーカー・ノードからワークロードをコードンおよびドレーンします。 ブロック・ストレージ・ボリュームを移動できない場合は、 ホストを置き換えることによるワーカー・ノードへのバージョン更新の適用 を使用してください。

ワーカーノードにアップデートを適用すると、アプリケーションやサービスにダウンタイムが発生する可能性があります。 更新プロセスの実行中は、ホストに対してアクションを実行しないでください。 全ワーカノードの最大20%が、更新プロセス中に利用できなくなる可能性があります。

ワーカー・ノード・ホストへのバージョン更新の一度に 1 つずつの適用

  1. オプション: 既存のホストの更新中に計算容量を処理するために、サービス・クラスターに 接続 および 割り当て を行います。

  2. ワーカー・ノード・ホストを識別します。 ワーカー・ノード・ホストには、出力の Cluster 列に infrastructure がリストされていませんが、代わりにクラスターの名前が付いています。

  3. ibmcloud ks worker update コマンドを実行して、ワーカー・ノードを個別に更新します。

    ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
    
  4. ワーカー・ノードの Kubernetes バージョンを確認して、更新が完了したことを確認します。

    kubectl get nodes
    

    更新が失敗した場合は、 ホストを置換してバージョン更新を適用する 必要があります。

ConfigMap を使用してワーカー・ノード・ホストにバージョン更新を適用します。

ConfigMapを使用して、すべてのワーカー・ノード・ホストに更新をロールアウトできます。 ラベルを使用して更新するノードを指定します。 以下を指定することもできます。

  1. オプション: 既存のホストの更新中に計算容量を処理するために、サービス・クラスターに 接続 および 割り当て を行います。

  2. ワーカー・ノード・ホストを識別します。 ワーカー・ノード・ホストが Infrastructure としてリストされません。

  3. ワーカー・ノードのラベルを表示します。 ワーカー・ノード・ラベルは、CLI 出力の Labels セクションにあります。 ラベルはすべて NodeSelectorKeyNodeSelectorValue で構成されます。 ラベルを使用して、更新するワーカー・ノードを指定できます。

    kubectl get nodes -o yaml
    

    出力例

    labels:
      arch: amd64
      beta.kubernetes.io/arch: amd64
      beta.kubernetes.io/instance-type: upi
      beta.kubernetes.io/os: linux
      failure-domain.beta.kubernetes.io/region: us-east
      failure-domain.beta.kubernetes.io/zone: us-east-2
      ibm-cloud.kubernetes.io/iaas-provider: upi
      ibm-cloud.kubernetes.io/internal-ip: 10.241.0.4
      ibm-cloud.kubernetes.io/machine-type: upi
      ibm-cloud.kubernetes.io/os: REDHAT_7_64
      ibm-cloud.kubernetes.io/region: us-east
      ibm-cloud.kubernetes.io/worker-id: sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7
      ibm-cloud.kubernetes.io/worker-pool-id: cbtljodw089nltg8k210-9a3f763
      ibm-cloud.kubernetes.io/worker-pool-name: default
      ibm-cloud.kubernetes.io/worker-version: 4.7.59_1583_openshift
      ibm-cloud.kubernetes.io/zone: us-east-2
      kubernetes.io/arch: amd64
      kubernetes.io/hostname: satellite-ibm-host-3
      kubernetes.io/os: linux
      node-role.kubernetes.io/master: ""
      node-role.kubernetes.io/worker: ""
      node.kubernetes.io/instance-type: upi
      node.openshift.io/os_id: rhel
      privateVLAN: "1"
      topology.kubernetes.io/region: us-east
      topology.kubernetes.io/zone: us-east-2
    
  4. ConfigMap を作成し、ワーカーノードの使用不可ルールを定義します。 次の例は、 defaultcheck.json とチェック・テンプレートの2つのチェックを示しています。 このチェック例を使用して、 ConfigMap (defaultcheck.json) で定義したどのチェックにも一致しないすべてのワーカー・ノードのルールを定義できます。 チェック・テンプレートを使用して、独自のチェックを作成します。 どのチェックでも、ワーカー・ノードを指定するには、前述の手順で取得したワーカー・ノード・ラベルのいずれかを選択する必要があります。

    どのチェックでも、NodeSelectorKeyNodeSelectorValue に値を 1 つだけ設定できます。 ConfigMap で最大10個のチェックを定義する。 それ以上チェックを追加しても無視されます。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ibm-cluster-update-configuration
      namespace: kube-system
    data:
      drain_timeout_seconds: "120"
      defaultcheck.json: |
        {
          "MaxUnavailablePercentage": 20
        }
      <check_name>: |
        {
          "MaxUnavailablePercentage": <value_in_percentage>,
          "NodeSelectorKey": "<node_selector_key>",
          "NodeSelectorValue": "<node_selector_value>"
        }
    
    drain_timeout_seconds
    オプション: ドレインが完了するまでのタイムアウト時間(秒)。 ワーカー・ノードの排出を行うと、そのワーカー・ノードから既存のポッドがすべて安全に削除され、クラスター内のその他のワーカー・ノード上にスケジュール変更されます。 指定可能な値は、1 から 180 の範囲の整数です。 デフォルト値は 30 です。
    defaultcheck.json
    Satellite ホストでワーカー・ノードを更新する場合、クラスター内のワーカー・ノードのうち一度に使用不可にできるのは 20% のみです。
    MaxUnavailablePercentage
    指定したラベルのキーと値について使用不可にできるノードの最大数 (パーセンテージで指定)。 ワーカー・ノードが使用不可になるのは、デプロイ、再ロード、またはプロビジョニングのプロセス中です。 定義した使用不可ノードの最大パーセンテージを超える場合、待機中のワーカー・ノードの更新はブロックされます。
    NodeSelectorKey
    ルールを設定するワーカー・ノードのラベル・キー。 IBM 提供のデフォルト・ラベルと、自分で作成したワーカー・ノード・ラベルにルールを設定できます。
    NodeSelectorValue
    定義したルールの対象になるワーカー・ノードのラベル値。
  5. クラスター内に構成マップを作成します。

    kubectl apply -f <filepath/configmap.yaml>
    
  6. ConfigMap が作成されていることを確認する。

    kubectl get configmap --namespace kube-system
    
  7. ワーカー・ノードを ID 別にリストして更新します。

    ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
    
  8. オプション: ConfigMap、発生した検証エラーによってトリガーされるイベントを確認する。 これらのイベントは、CLI 出力内の Events セクションで確認できます。

    kubectl describe -n kube-system cm ibm-cluster-update-configuration
    
  9. ワーカー・ノードの Kubernetes バージョンを確認して、更新が完了したことを確認します。

    kubectl get nodes
    

    更新が失敗した場合は、 ホストを置換してバージョン更新を適用する 必要があります。

  10. ワーカー・ノードが重複していないことを確認します。 場合によっては、古いクラスターで、更新後に NotReady 状況のワーカー・ノードが重複してリストされることがあります。 重複を削除するには、トラブルシューティングを参照してください。

ホストの置換によるワーカー・ノードへのバージョン更新の適用

ロケーションに接続されているホストは自動更新されません。 バージョン アップデートを適用するには、まず Satellite 対応の IBM Cloud サービス に新しいホストをアタッチして割り当て、その後古いホストを削除します。 マイナー・バージョンおよびパッチ・バージョンの更新をインプレースで 適用することもできます。

  1. 現在のホストをリストし、それぞれの ID をメモします。 これらは、更新されたホストを接続した後に削除するホストです。

    ibmcloud ks worker ls -c <cluster_name_or_ID>
    

    出力例を示します。

    ID                                                        Primary IP      Flavor   State    Status   Zone     Version   
    sat-satliberty-5b4c7f3a7bfc14cf58cbb14ad5c08429475274fe   208.43.36.202   upi      normal   Ready    zone-1   4.7.19_1525_openshift*   
    
  2. Satellite ロケーションに新規ホストを接続します。 接続するホストの数は、更新するホストの数と一致している必要があります。

  3. 新規に接続したホストを Satellite リソースに割り当てます。 割り当てると、それらのホストが自動的に更新を受け取るようになります。

  4. 新規ホストが Satellite リソースに正常に割り当てられたら、先ほどメモした古いホストを削除します

Red Hat OpenShift on IBM Cloud コンソールでのワーカー・ノード・ホストの更新

Red Hat OpenShift on IBM Cloud コンソールを使用してワーカー・ノード・ホストを更新できます。

  1. IBM Cloud コンソールにログインし、「OpenShift」>**「クラスター」**をクリックします。
  2. 更新するホストが割り当てられているクラスターをクリックし、**「ワーカー・ノード」**ページにナビゲートします。
  3. 更新する各ホストを選択します。 ホストを選択すると、**「更新」**オプションが表示されます。
  4. 更新 をクリックします。 表示されるダイアログ・ボックスで、もう一度**「更新」**をクリックします。 更新が正常に開始されたというメッセージが表示されます。
  5. ホストが更新されるまで待ちます。 各ホストの更新処理が完了するのは、ホストの**「状況」「正常」に戻り、「バージョン」**列に新規バージョンがリストされたときです。

ワーカー・ノードのバージョン更新がメジャー更新、マイナー更新、パッチ更新のいずれであるかを確認する

ワーカー・ノードを更新するプロセスは、すべてのタイプの更新で同じです。 ただし、更新がメジャー更新なのか、マイナー更新なのか、パッチ更新なのかについての情報を見つけることができます。

使用可能な更新のタイプを判別するには、現在のワーカー・ノードのバージョンを Red Hat OpenShift バージョンの変更ログの最新の worker node fix pack バージョンと比較します。 メジャー更新はバージョン・ラベルの 1 桁目 (4.x.x) で表されます。マイナー更新は 2 桁目 (x.7.x)、パッチ更新は末尾の桁で (x.x.23_1528_openshift) で示されます。 バージョン更新について詳しくは、バージョン情報および更新操作を参照してください。