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

開始する前に、 Operator または Administrator IAMプラットフォームアクセスロールを持って いることを確認してください。

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

マスターの更新が完了したら、クラスター・インフラストラクチャー・プロバイダーのタイプに応じて、ワーカー・ノードを更新できます。

• クラシック・ワーカー・ノードの更新。
• VPC ワーカー・ノードの更新。

前提条件

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

ワーカー・ノードを更新すると、アプリとサービスにダウン時間が発生する可能性があります。 ワーカー・ノード・マシンが再イメージ化されるので、ポッドの外部に保管していないデータは削除されます。

• 最新のセキュリティー・パッチおよびフィックスについては、使用可能になった後、できるだけ早くワーカー・ノードを最新パッチに更新してください。 最新の更新について詳しくは、 Red Hat OpenShift on IBM Cloud バージョン情報 を参照してください。
• Red Hat OpenShift クラスターにアクセスします。
• マスターを更新します。 ワーカー・ノードのバージョンは、Kubernetes マスターで実行されている API サーバーのバージョンより高くすることはできません。
• Red Hat OpenShift バージョン準備ガイドの_マスターの後に更新_のマークが付けられている変更を行います。
• パッチの更新を適用したい場合は、 Red Hat OpenShift on IBM Cloud バージョン情報を 確認してください。
• 更新中にワークロードの再スケジューリングができるように、クラスタに十分な容量があるようにワーカーノードを追加することを検討してください。 詳しくは、 クラシック・クラスターへのワーカー・ノードの追加 または VPC クラスターへのワーカー・ノードの追加 を参照してください。
• Operator または Administrator IAMプラットフォームアクセスロールを持って いることを確認してください。

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

クラシック・ワーカー・ノードのローリング更新を実行するために構成マップをセットアップします。

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. 構成マップを作成し、ワーカー・ノードの非可用性ルールを定義します。 以下の例は、zonecheck.json、regioncheck.json、defaultcheck.json、チェック・テンプレートの 4 つのチェックを示します。 これらのチェック例を使用して、特定のゾーン内のワーカー・ノード (zonecheck.json)、リージョン内のワーカー・ノード (regioncheck.json)、または構成マップで定義したチェック項目のいずれにも一致しないすべてのワーカー・ノード (defaultcheck.json) に対してルールを定義できます。 チェック・テンプレートを使用して、独自のチェックを作成します。 どのチェックでも、ワーカー・ノードを指定するには、前述の手順で取得したワーカー・ノード・ラベルのいずれかを選択する必要があります。

   どのチェックでも、NodeSelectorKey と NodeSelectorValue に値を 1 つだけ設定できます。 複数のリージョン、ゾーン、またはその他のワーク・ノード・ラベルに対するルールを設定する場合は、新しいチェックを作成します。 コンフィグマップで最大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 状況のワーカー・ノードが重複してリストされることがあります。 重複を削除するには、トラブルシューティングを参照してください。

次のステップ:

• 他のワーカー・プールで更新処理を繰り返します。
• クラスターで作業を行う開発者に、oc CLI を Kubernetes マスターのバージョンに更新するように伝えます。
• Kubernetes ダッシュボードに使用状況グラフが表示されない場合は、kube-dashboard ポッドを削除します。

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

構成マップを初めてセットアップした後に、IBM Cloud コンソールを使用してワーカー・ノードを更新できます。

コンソールからワーカー・ノードを更新するには、以下のようにします。

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

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

前提条件

VPC インフラストラクチャー・ワーカー・ノードを更新する前に、前提条件手順を確認してください。

ワーカー・ノードを更新すると、アプリとサービスにダウン時間が発生する可能性があります。 ワーカー・ノード・マシンは除去され、ポッドの外部に保管していないデータは削除されます。

• 最新のセキュリティー・パッチおよびフィックスについては、使用可能になった後、できるだけ早くワーカー・ノードを最新パッチに更新してください。 最新の更新について詳しくは、 Red Hat OpenShift on IBM Cloud バージョン情報 を参照してください。
• Red Hat OpenShift クラスターにアクセスします。
• マスターを更新します。 ワーカー・ノードのバージョンは、Kubernetes マスターで実行されている API サーバーのバージョンより高くすることはできません。
• Red Hat OpenShift バージョン準備ガイドの_マスターの後に更新_のマークが付けられている変更を行います。
• パッチの更新を適用したい場合は、 Red Hat OpenShift on IBM Cloud バージョン情報を 確認してください。
• Operator または Administrator IAMプラットフォームアクセスロールを持って いることを確認してください。

Fluentd の自動更新の管理

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

Fluentd コンポーネントの自動更新は、以下の方法で管理できます。 注: 以下のコマンドを実行するには、クラスターに対する管理者の IBM Cloud IAM プラットフォーム・アクセス役割が必要です。

• 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 が自動更新されることはありません。 コマンド例

    ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
    

Ingress ALB の自動更新の管理

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