クラスター・マスターを更新するための手順

作業を始める前に、 オペレーター または「 管理者 」IAMプラットフォームのアクセスロール がインストールされていることを確認してください。 ご自身のアクセス権限がわからない場合は、 IBM Cloud コンソールで [ 管理] → [アクセス (IAM)] → [ユーザー ] に移動するか、 アカウント管理者に問い合わせてください。

認証局（CA）の証明書ローテーションが進行中の場合、ローテーションが完了するまでマスターの更新はブロックされます。 作業を開始する前に、進行中のローテーションの状況を確認してください。

Red Hat OpenShift マスター メジャー バージョンまたは マイナー バージョンを更新するには、以下のようにします。

1. Red Hat OpenShift on IBM Cloud バージョン情報 を確認し、 _「マスターの前に更新」_のマークが付いた更新を行います。

2. Kubernetes の有用な警告 （非推奨の通知など）を確認してください。

3. クラスターのバージョンを更新することによって発生する可能性のある影響については、クラスターにインストールされているアドオンおよびプラグインを確認してください。

   • アドオンの確認

     1. クラスター内のアドオンをリストします。

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. インストールされているアドオンごとに、サポートされている Red Hat OpenShift バージョンを確認してください。

        ibmcloud oc addon-versions
        

     3. クラスターの更新後の Red Hat OpenShift バージョンで実行するようにアドオンを更新する必要がある場合は、アドオンの更新を行います。

   • プラグインの検査

     1. 「 Helm 」カタログで、クラスタにインストールしたプラグインを探してください。
     2. サイド・メニューから、ソース & TAR ファイル セクションを展開します。
     3. ソース・コードをダウンロードして開きます。
     4. サポートされるバージョンについては、README.md または RELEASENOTES.md ファイルを確認します。
     5. クラスターの更新後の Red Hat OpenShift バージョンで実行するようにプラグインを更新する必要がある場合は、プラグインの説明に従ってプラグインを更新します。

4. IBM Cloud コンソールを使用するか CLI ibmcloud oc cluster master update コマンドを実行して、API サーバーと、関連するマスター・コンポーネントを更新します。

5. 数分待ってから、更新が完了したことを確認します。 IBM Cloud クラスター・ダッシュボードで API サーバーのバージョンを確認するか、ibmcloud oc cluster ls を実行します。

6. マスターで実行されている API サーバーと同じバージョンの oc cli をインストールします。 Kubernetes サーバー版と2バージョン以上（n ± 2）の差がある oc クライアント版はサポートされていません。 ローカルの設定を更新するには、 ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID を実行し、その後 oc version --client で確認してください。

マスターの更新が完了したら、ワーカーノードを更新してください。 この方法は、ご利用のインフラストラクチャの種類によって異なります：

1. 従来のワーカーノードの更新 — 「 ConfigMap 」と「 worker update 」コマンドによって制御されるローリング更新を使用します。
2. VPC ワーカーノードの更新 — VPC ベアメタルワーカーは、 worker reload を使用してその場で更新されます。VPC VSI ワーカーは、 worker replace --update を使用する必要があります。 ConfigMap のローリングアップデート手順は、VPCワーカーノードではまだサポートされていません。

前提条件

クラシック・インフラストラクチャーワーカーノードを更新する前に、以下の前提条件となる手順を完了してください。

ワーカーノードの更新時には、ワーカーノードのマシンに新しいイメージが適用され、 永続ストレージに保存 されていないすべてのデータは完全に削除されます。 作業を開始する前に、保存が必要なデータがすべてワーカーノードの外に保存されていることを確認してください。

クラスタに Portworx がインストールされている場合は、 ワーカーノードを更新する前に、 Portworx の設定を更新 する必要があります。

構成マップを使用した CLI でのクラシック・ワーカー・ノードの更新

ConfigMap を使用して、クラシック・ワーカーノードのローリングアップデートを実行します。 ConfigMap を使用すると、ゾーンまたはリージョンごとに、同時に利用不能になるノードの数を制御できます。 お使いのクラスタにおいて、デフォルトの「20%の可用性低下」ルールで問題がない場合は、手順3および4（ ConfigMap の作成）をスキップし、手順5に直接進んで、デフォルトの動作を使用して更新を適用することができます。

1. 前提条件手順を実行します。

2. 使用可能なワーカー・ノードのリストを表示し、それらのプライベート IP アドレスをメモします。

   ibmcloud oc worker ls --cluster CLUSTER
   

3. ワーカー・ノードのラベルを表示します。 ワーカー・ノード・ラベルは、CLI 出力の Labels セクションにあります。 ラベルはすべて NodeSelectorKey と NodeSelectorValue で構成されます。

   oc describe node PRIVATE-WORKER-IP
   

   出力例

   NAME:               10.184.58.3
   Roles:              <none>
   Labels:             arch=amd64
                   beta.kubernetes.io/arch=amd64
                   beta.kubernetes.io/os=linux
                   failure-domain.beta.kubernetes.io/region=us-south
                   failure-domain.beta.kubernetes.io/zone=dal12
                   ibm-cloud.kubernetes.io/encrypted-docker-data=true
                   ibm-cloud.kubernetes.io/iaas-provider=softlayer
                   ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                   kubernetes.io/hostname=10.123.45.3
                   privateVLAN=2299001
                   publicVLAN=2299012
   Annotations:        node.alpha.kubernetes.io/ttl=0
                   volumes.kubernetes.io/controller-managed-attach-detach=true
   CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
   Taints:             <none>
   Unschedulable:      false
   

4. 構成マップを作成し、ワーカー・ノードの非可用性ルールを定義します。 ConfigMap は、最大15個の名前付きチェックをサポートしています。 各チェックでは、ラベルに基づいて一連のワーカーノードを対象とし、それらのノードのうち、同時に利用不能となってもよい最大割合を設定します。 以下の例では、ゾーンチェック（zonecheck.json ）、リージョンチェック（regioncheck.json ）、デフォルトのフォールバックチェック（defaultcheck.json ）、およびカスタムチェック用のテンプレートを示しています。 各チェックを行う際は、前の手順で取得したワーカーノードのラベルから1つを選択し、対象となるノードを特定してください。

   どのチェックでも、NodeSelectorKey と NodeSelectorValue に値を 1 つだけ設定できます。 複数のリージョン、ゾーン、またはその他のワーク・ノード・ラベルに対するルールを設定する場合は、新しいチェックを作成します。 1つのConfigMap内で、最大15個のチェックを定義できます。 さらにチェックを追加すると、要求されたすべてのワーカーが更新されるまで、一度に 1 つのワーカー・ノードのみが再ロードされます。

   例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     zonecheck.json: |
       {
         "MaxUnavailablePercentage": 30,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
         "NodeSelectorValue": "dal13"
       }
     regioncheck.json: |
       {
         "MaxUnavailablePercentage": 20,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
         "NodeSelectorValue": "us-south"
       }
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   オプション： ドレインが完了するまで待つタイムアウト時間（秒単位）。 ワーカー・ノードの排出を行うと、そのワーカー・ノードから既存のポッドがすべて安全に削除され、クラスター内のその他のワーカー・ノード上にスケジュール変更されます。 指定可能な値は、1 から 180 の範囲の整数です。 デフォルト値は 30 です。

   zonecheck.json および regioncheck.json

   指定された NodeSelectorKey および NodeSelectorValue で識別できる一連のワーカー・ノードのルールを定義する 2 つのチェック。 zonecheck.json は、ワーカー・ノードをゾーン・ラベルに基づいて識別します。regioncheck.json は、プロビジョニング時にすべてのワーカー・ノードに追加されたリージョン・ラベルを使用します。 この例では、ゾーン・ラベルとして dal13 を持つすべてのワーカー・ノードの 30% と、us-south 内のすべてのワーカー・ノードの 20% を更新中に使用不可にすることができます。

   defaultcheck.json

   構成マップを作成しない場合、またはマップが正しく構成されていない場合は、Kubernetes のデフォルトが適用されます。 デフォルトでは、同時に使用不可にできるのは、クラスターのワーカー・ノードの 20% のみです。 デフォルトのチェックを構成マップに追加して、このデフォルト値をオーバーライドできます。 この例では、ゾーンとリージョンのチェック (dal13 または us-south) で指定されていないすべてのワーカー・ノードを更新中に使用できない可能性があります。

   MaxUnavailablePercentage

   指定したラベルのキーと値について使用不可にできるノードの最大数 (パーセンテージで指定)。 ワーカー・ノードが使用不可になるのは、デプロイ、再ロード、またはプロビジョニングのプロセス中です。 定義した使用不可ノードの最大パーセンテージを超える場合、待機中のワーカー・ノードの更新はブロックされます。

   NodeSelectorKey

   ルールを設定するワーカー・ノードのラベル・キー。 IBM 提供のデフォルト・ラベルと、自分で作成したワーカー・ノード・ラベルにルールを設定できます。 1 つのワーカー・プールに属するワーカー・ノードのルールを追加する場合は、ibm-cloud.kubernetes.io/machine-type ラベルを使用できます。

   NodeSelectorValue

   定義したルールの対象になるワーカー・ノードのラベル値。

5. クラスター内に構成マップを作成します。

   oc apply -f <filepath/configmap.yaml>
   

6. 構成マップが作成されたことを確認します。

   oc get configmap --namespace kube-system
   

7. ワーカー・ノードを更新します。

   ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

8. オプション: 構成マップによってトリガーされたイベントと、発生した検証エラーを確認します。 これらのイベントは、CLI 出力内の Events セクションで確認できます。

   oc describe -n kube-system cm ibm-cluster-update-configuration
   

9. ワーカー・ノードの Kubernetes バージョンを確認して、更新が完了したことを確認します。

   oc get nodes
   

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

コンソールでのクラシック・ワーカー・ノードの更新

ConfigMap を初めてセットアップした後、 IBM Cloud コンソールを使用してワーカーノードを更新できます。 コンソールは、 ConfigMap で定義した利用不可ルールを順守します。

1. 前提条件の手順を 完了し、ワーカーノードの更新方法を制御するために ConfigMap を設定してください。
2. IBM Cloud から をクリックし、 コンテナ > クラスター の順にクリックします。
3. **「クラスター」**ページから、クラスターを選択します。
4. **「ワーカー・ノード」**タブから、更新する各ワーカー・ノードのチェック・ボックスを選択します。 アクション・バーがテーブル・ヘッダー行の上に表示されます。
5. アクション・バーで**「更新」**をクリックします。

クラスターに Portworx がインストールされている場合は、更新されたワーカーノード上の Portworx ポッドを再起動する必要があります。 詳しくは、Portworx の制限を参照してください。

前提条件

VPC インフラストラクチャのワーカーノードを更新する前に、以下の前提条件となる手順を完了してください。

VPC VSI ワーカーの場合、ワーカーノードが削除され、新しいノードに置き換えられます。 VPCのベアメタルワーカーの場合、ノードはその場で再読み込みされます。 いずれの場合も、 永続ストレージに保存 されていないデータは完全に削除されます。 作業を開始する前に、保存が必要なデータがすべてワーカーノードの外に保存されていることを確認してください。

クラスターに Portworx がデプロイされている場合は、このページの手順ではなく、 Portworx ボリュームを使用してVPCワーカーノードを更新する 手順に従ってください。

VPCベアメタルワーカーの再起動中のファームウェア更新

VPCベアメタルワーカーノードを再起動すると、 IBM Cloud インフラストラクチャは、そのサーバーに対してファームウェアの更新が保留中かどうかを自動的に確認し、再起動プロセスの一環としてその更新を適用します。 ファームウェアの更新を開始するために、追加の手順は必要ありません。

VPCのベアメタルワーカーノードを再起動する際は、以下の点に留意してください：

リロード時間の延長

リロード中にファームウェアの更新が行われると、リロードにかかる合計時間が、通常のリロード所要時間よりも大幅に（30分以上）長くなる可能性があります。 それに応じて、メンテナンスの実施時期を計画してください。

今後予定されている更新内容について、事前に確認することはできません

reload コマンドを実行するまでは、ワーカーノードに対してファームウェアの更新が保留中であるかどうかを確認する方法はありません。

データ損失のリスク

すべてのVPCベアメタルワーカーの再読み込みと同様に、ファームウェアの更新が適用されるかどうかに関わらず、再読み込み中にローカルディスク上のデータは削除されます。 再読み込みを行う前に、永続ストレージに保存されていないデータはすべてバックアップしてください。

ファームウェアの更新によるリロードの失敗

場合によっては、ファームウェアの更新に失敗することがあり、その結果、ワーカーノードが「 reload_failed 」状態（Failed to reload worker ）に入り、ステータスの詳細が「 The infrastructure firmware update has failed. (P4056) 」となることがあります。 次のような状況が発生した場合は：

1. 数分待ってから、 ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID を再度実行して、リロードをやり直してください。
2. 2～3回試してもエラーが解消されない場合は、 IBM Cloud のサポートチケット を開いてください。

開始前に

• Red Hat OpenShift クラスターにアクセスします。
• 保存が必要なデータはすべて、ワーカーノード外の 永続ストレージ に格納されていることを確認してください。 ワーカーノードにのみ保存されているデータは失われ、復元することはできません。
• オペレーター または、 管理者 IAMプラットフォームのアクセスロール がインストールされていることを確認してください。 ご自身のアクセス権限がわからない場合は、 IBM Cloud コンソールで [ 管理] → [アクセス (IAM)] → [ユーザー ] に移動するか、 アカウント管理者に問い合わせてください。

フレーバーを更新するには

1. 使用可能なワーカー・ノードのリストを表示し、それらのプライベート IP アドレスをメモします。

   1. クラスターで使用可能なワーカー・プールをリストします。

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. ワーカー・プール内のワーカー・ノードをリストします。 **ID** と**プライベート IP** をメモします。
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. ワーカー・ノードの詳細を取得します。 出力に表示されているゾーンをメモし、クラシック・クラスターのプライベート VLAN ID とパブリック VLAN ID、または VPC クラスターのサブネット ID をメモしてください。
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. ゾーンで使用可能なフレーバーをリストします。

   ibmcloud oc flavors --zone <zone>
   

3. 新しいマシン・タイプのワーカー・ノードを作成します。

   1. 置き換えるワーカー・ノードと同じ数のワーカー・ノードを含むワーカー・プールを作成します。
      • クラシック・クラスター:

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • VPC 第 2 世代クラスター:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. ワーカー・プールが作成されたことを確認します。

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. 前の手順で取得したワーカー・プールにゾーンを追加します。 ゾーンを追加すると、ワーカー・プールに定義したワーカー・ノードがそのゾーンにプロビジョンされ、今後のワークロード・スケジュールの対象に含められます。 ワーカー・ノードを複数のゾーンに分散させる場合は、[クラシック用](/docs/openshift?topic=openshift-regions-and-zones#zones-mz)のマルチゾーン・ロケーションまたは [VPC 用](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc)のマルチゾーン・ロケーションを選択します。
       * クラシック・クラスター:
           ```sh {: pre}
           ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * VPC クラスター:
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. ワーカー・ノードがデプロイされるまで待ちます。 ワーカー・ノードの状態が**「正常」**に変わったら、デプロイメントは終了です。

   ibmcloud oc worker ls --cluster CLUSTER
   

5. 古いワーカープールを削除します。 Classic ベアメタル・フレーバー（月額課金制）を解約する場合、たとえ月の途中で解約しても、その月の利用料金は全額請求されます。 VPCワーカー（ベアメタルを含む）は、時間単位で課金されます。

   1. 古いマシン・タイプのワーカー・プールを削除します。 ワーカー・プールを削除すると、そのプールのすべてのゾーンのすべてのワーカー・ノードが削除されます。 このプロセスは、完了まで数分かかることがあります。

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. ワーカー・プールが削除されたことを確認します。
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. ワーカー・ノードがクラスターから削除されたことを確認します。

   ibmcloud oc worker ls --cluster CLUSTER
   

7. 上記の手順を繰り返して、他のワーカー・プールまたはスタンドアロン・ワーカー・ノードを別のフレーバーに更新します。

Fluentd の自動更新の管理

クラスター内のソースに対して、外部サーバーに転送するためのロギング構成を作成すると、Fluentd コンポーネントがクラスター内に作成されます。 ロギング構成またはフィルター構成を変更するには、Fluentd コンポーネントが最新バージョンでなければなりません。 デフォルトでは、このコンポーネントに対する自動更新は有効になっています。

以下のコマンドを実行するには、そのクラスターに対して「 Administrator IBM Cloud 」というIAMプラットフォームアクセスロール を持っている必要があります。

Fluentd コンポーネントの自動更新は、以下の方法で管理できます。

• ibmcloud oc logging autoupdate get --cluster CLUSTER コマンド を実行して、自動更新が有効になっているかどうかを確認します。
• ibmcloud oc logging autoupdate disable コマンドを実行して、自動更新を無効にします。
• 自動更新が無効になっている場合に、構成を変更する必要がある場合は、以下の 2 つのオプションがあります。
  • Fluentd ポッドの自動更新をオンにします。

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * `--force-update` オプションを指定したロギング・コマンドを使用して、一回限りの更新を強制実行します。 ポッドは Fluentd コンポーネントの最新バージョンに更新されますが、今後 Fluentd は自動的に更新されなくなります。
          コマンド例
  
  ```sh {: pre}
      ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

Ingress ALB の自動更新の管理

Ingress アプリケーション・ロード・バランサー (ALB) コンポーネントを更新するタイミングを制御してください。 ALB を最新の状態に保つ方法については、Ingress ALB ライフサイクルの管理を参照してください。