クラスター、ワーカー・ノード、クラスター・コンポーネントの更新

クラスター・マスターとワーカー・ノードを最新の状態に保つ手順については、以下のセクションを参照してください。

マスターの更新

マスターをいつ更新すべきか、どうすればわかりますか？: 更新が使用可能になると、コンソール、発表、および CLI で通知されます。サポートされるバージョンのページを定期的に確認することもできます。
マスターは最新バージョンから最大で何バージョン遅れていてもよいですか？: APIサーバーは、現在のバージョンより1つ先のバージョンにのみ更新できます（n+1 ）。
ワーカーノードは、マスターよりも新しいバージョンを実行できますか？: ワーカー・ノードは、マスターより新しいバージョンの major.minor Kubernetes を実行できません。また、ワーカー・ノードのバージョンは、マスターのバージョン (n-1) より 1 つ下のバージョンでなければなりません。まず、マスターの更新を最新の Kubernetes バージョンにします。その後に、クラスター内のワーカー・ノードを更新してください。

ワーカー・ノードは、セキュリティー更新プログラム用のワーカー・ノードに固有のパッチ・バージョンなど、マスターより新しいパッチ・バージョンを実行できます。

パッチの更新はどのように適用されるのですか？: デフォルトでは、マスターのパッチ更新は数日にわたって自動的に適用されます。そのため、まだマスターに適用されていないパッチ・バージョンが、使用可能なバージョンとして表示されることがあります。また、更新の自動化では、正常な状態でないクラスターや現在進行中の操作があるクラスターはスキップされます。必要に応じて、IBM は特定のマスターのフィックスパック (マスターが 1 つ前のマイナー・バージョンから更新される場合にのみ必要なパッチなど) に対して、自動更新を無効にする場合があります。いずれの場合も、 Red Hat OpenShift on IBM Cloud のバージョン情報を確認して影響の有無を確認し、更新の自動適用を待たずに、ご自身で ibmcloud oc cluster master update コマンドを安全に実行することも可能です。

マスターとは異なり、ワーカーはパッチ・バージョンごとに更新する必要があります。

マスターの更新中はどのような処理が行われるのでしょうか？: マスターは、レプリカ・マスター・ポッドが 3 つあるので高可用性です。使用不可のマスター・ポッドが一度に 1 つだけになるようにローリング更新が行われます。 2 つのインスタンスが稼働しているので、更新中もクラスターにアクセスして変更することができます。ワーカー・ノード、アプリ、リソースは実行され続けます。
このアップデートを元に戻すことはできますか？: いいえ、更新プロセスの実行後にクラスターを前のバージョンにロールバックすることはできません。必ず、テスト・クラスターを使用し、手順に従って潜在する問題に対処してから、実動マスターを更新してください。
マスターを更新するには、どのような手順を踏めばよいですか？: 以下の図は、マスターを更新するときに行えるプロセスを示しています。

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

作業を始める前に、 オペレーター または、 管理者 IAMプラットフォームのアクセスロールがインストールされていることを確認してください。

認証局（CA）証明書のローテーションが進行中の場合、クラスタ・マスターへの更新はブロックされます。クラスタ・マスターを更新する前にローテーションが完了するのを待ちます。

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

Red Hat OpenShift on IBM Cloud バージョン情報を確認し、 _「マスターの前に更新」_のマークが付いた更新を行います。
Kubernetes の有用な警告（非推奨の通知など）を確認してください。
クラスターのバージョンを更新することによって発生する可能性のある影響については、クラスターにインストールされているアドオンおよびプラグインを確認してください。
- アドオンの確認
  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 バージョンで実行するようにプラグインを更新する必要がある場合は、プラグインの説明に従ってプラグインを更新します。
IBM Cloud コンソールを使用するか CLI ibmcloud oc cluster master update コマンドを実行して、API サーバーと、関連するマスター・コンポーネントを更新します。
数分待ってから、更新が完了したことを確認します。 IBM Cloud クラスター・ダッシュボードで API サーバーのバージョンを確認するか、ibmcloud oc cluster ls を実行します。
マスターで実行されている API サーバーと同じバージョンの oc cli をインストールします。 Kubernetes サーバー版と2バージョン以上（n ± 2）の差がある oc クライアント版はサポートされていません。

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

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

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

クラシック・インフラストラクチャー・クラスターのワーカー・ノードの更新が使用可能になっているとします。これはどういうことでしょうか？セキュリティー更新とパッチが API サーバーと他のマスター・コンポーネントに適用されたので、ワーカー・ノードを同期する必要があります。更新には、パッチ・バージョンだけを更新するタイプと、パッチ・バージョンと一緒に major.minor のバージョンを更新するタイプの 2 つがあります。

パッチ: ワーカー・ノードのパッチ更新にはセキュリティー・フィックスが含まれています。 ibmcloud oc worker reload コマンドまたは update コマンドを使用して、クラシック・ワーカー・ノードを最新のパッチに更新することができます。 update バージョンの更新も使用可能になっている場合、major.minor コマンドはさらに、マスターの最新のパッチ・バージョンと同じ major.minor バージョンにワーカー・ノードを更新することに注意してください。
Major.minor: major.minor の更新では、ワーカー・ノードの Kubernetes バージョンがマスターと同じバージョンになります。多くの場合、このタイプの更新には、クラスターの準備が必要になる、Kubernetes API やその他の動作に対する変更が含まれています。ワーカー・ノードのバージョンは、マスターのバージョンより 1 つ下のバージョン (n-1) にしかできないことに注意してください。 ibmcloud oc worker update コマンドを使用して、クラシック・ワーカー・ノードを同じパッチに更新できます。

詳しくは、更新タイプを参照してください。

証明書のローテーションの最も長いステップには、ワーカーノードの再ロードまたは交換が含まれるため、ワーカーノードを更新するたびに CA証明書をローテーションすることは良い習慣です。

アップデート中は、私のアプリはどうなるのですか？: 更新対象のワーカー・ノード上でデプロイメントの一部として実行しているアプリは、クラスター内のその他のワーカー・ノードにスケジュール変更されます。別のワーカー・プール内のワーカー・ノードにスケジュールされたり、スタンドアロン・ワーカー・ノードがある場合はそのノードにアプリがスケジュールされたりすることもあります。アプリのダウン時間を回避するには、ワークロードに対応できるだけの十分な容量がクラスター内になければなりません。
更新や再読み込みの際に、一度に停止するワーカーノードの数をどのように制御すればよいでしょうか？: すべてのワーカー・ノードを稼働状態にする必要がある場合は、ワーカー・プールをサイズ変更するか、スタンドアロン・ワーカー・ノードを追加して、ワーカー・ノードを追加することを検討してください。追加したワーカー・ノードは、更新が完了したら削除できます。

さらに、更新時など、一度に利用不能になってよいワーカーノードの最大数を指定する「 Kubernetes 」という設定マップを作成することもできます。ワーカー・ノードは、ワーカー・ノード・ラベルで識別されます。 IBM 提供のラベルも、ワーカー・ノードに追加したカスタム・ラベルも使用できます。

config Kubernetes mapルールはワーカーノードの更新にのみ使用されます。これらの規則はワーカー・ノードの再ロードに影響しません。つまり、要求されたときに即時に再ロードが行われます。

もしコンフィグマップを定義しないことにした場合はどうなるのでしょうか？: 構成マップを定義しない場合は、デフォルトが使用されます。デフォルトでは、更新処理中に、各クラスター内のすべてのワーカー・ノードの最大 20% を使用不可にすることができます。

前提条件

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

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

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

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

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

前提条件手順を実行します。
使用可能なワーカー・ノードのリストを表示し、それらのプライベート IP アドレスをメモします。
```
ibmcloud oc worker ls --cluster CLUSTER
```

ワーカー・ノードのラベルを表示します。ワーカー・ノード・ラベルは、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

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

どのチェックでも、NodeSelectorKey と NodeSelectorValue に値を 1 つだけ設定できます。複数のリージョン、ゾーン、またはその他のワーク・ノード・ラベルに対するルールを設定する場合は、新しいチェックを作成します。 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

定義したルールの対象になるワーカー・ノードのラベル値。
クラスター内に構成マップを作成します。
```
oc apply -f <filepath/configmap.yaml>
```
構成マップが作成されたことを確認します。
```
oc get configmap --namespace kube-system
```

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

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

オプション: 構成マップによってトリガーされたイベントと、発生した検証エラーを確認します。これらのイベントは、CLI 出力内の Events セクションで確認できます。
```
oc describe -n kube-system cm ibm-cluster-update-configuration
```
ワーカー・ノードの Kubernetes バージョンを確認して、更新が完了したことを確認します。
```
oc get nodes
```
ワーカー・ノードが重複していないことを確認します。場合によっては、古いクラスターで、更新後に NotReady 状況のワーカー・ノードが重複してリストされることがあります。重複を削除するには、トラブルシューティングを参照してください。

次のステップ:

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

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

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

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

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

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

VPC ワーカー・ノードの更新

VPCクラスタ内のワーカーノードに対して、更新プログラムが利用可能になっていることに気づきます。これはどういうことでしょうか？セキュリティー更新とパッチが API サーバーと他のマスター・コンポーネントに適用されたので、ワーカー・ノードを同期する必要があります。更新には、パッチ・バージョンだけを更新するタイプと、パッチ・バージョンと一緒に major.minor のバージョンを更新するタイプの 2 つがあります。

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

OpenShift Data Foundation がクラスターにデプロイされている場合は、OpenShift Data Foundation を使用した VPC ワーカー・ノードの更新の手順に従ってください。

パッチ: ワーカー・ノードのパッチ更新にはセキュリティー・フィックスが含まれています。 VPCのベアメタル環境をご利用のお客様は、 ibmcloud oc worker reload コマンドを使用して最新のパッチを適用できます。 VPC 仮想サーバーインスタンスのワーカーについては、 ibmcloud oc worker replace コマンドを使用してください。
Major.minor: major.minor の更新では、ワーカー・ノードの Kubernetes バージョンがマスターと同じバージョンになります。多くの場合、このタイプの更新には、クラスターの準備が必要になる、Kubernetes API やその他の動作に対する変更が含まれています。ワーカーノードは、マスターバージョンより1バージョンだけ古いバージョンに限定されることにご注意ください（n-1 ）。 ibmcloud oc worker replace コマンドに --update オプションを指定することで、VPCワーカーノードを同じパッチに更新できます。

アップデート中は、私のアプリはどうなるのですか？: 更新対象のワーカー・ノード上でデプロイメントの一部として実行しているアプリは、クラスター内のその他のワーカー・ノードにスケジュール変更されます。それらのワーカー・ノードは別のワーカー・プールのものである可能性があります。アプリのダウンタイムを防ぐためには、ワーカープールのサイズ変更などを行い、クラスターにワークロードを処理するのに十分な容量が確保されていることを確認する必要があります。詳しくは、クラシック・クラスターへのワーカー・ノードの追加または VPC クラスターへのワーカー・ノードの追加を参照してください。
アップデート中は、私のワーカーノードはどうなるのでしょうか？: VPC ワーカー・ノードは置換されます。そのために、古いワーカー・ノードが削除され、更新されたパッチまたは major.minor のバージョンで実行される新しいワーカー・ノードがプロビジョニングされます。後継のワーカー・ノードは、削除されるワーカー・ノードと同じゾーンで同じワーカー・プールに同じフレーバーを使用して作成されます。ただし、後継のワーカー・ノードには新しいプライベート IP アドレスが割り当てられ、古いワーカー・ノードに適用されていたカスタムのラベルやテイントは失われます (ワーカー・プールのラベルおよびテイントは後継のワーカー・ノードにも適用されます)。
複数のワーカーノードを同時に交換した場合はどうなりますか？: 複数のワーカー・ノードを同時に置換すると、それらのノードは 1 つずつではなく、同時に削除されて置換されます。ワーカー・ノードを置換する前に、ワークロードのスケジュールを変更するための十分な容量がクラスター内にあることを確認してください。
代替ワーカーノードが作成されなかった場合はどうなるのでしょうか？: ワーカー・プールの自動リバランスが有効でない場合、後継のワーカー・ノードは作成されません。

前提条件

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

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

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

CLI での VPC ワーカー・ノードの更新

CLI を使用してワーカーノードを更新するには、以下の手順を実行してください。

前提条件手順を実行します。
オプション：ワーカープールのサイズを変更して、クラスターの処理能力を拡張します。ワーカー・ノード上のポッドのスケジュールを変更し、追加したワーカー・ノードで更新中も実行を継続することができます。詳しくは、クラシック・クラスターへのワーカー・ノードの追加または VPC クラスターへのワーカー・ノードの追加を参照してください。
クラスター内のワーカー・ノードをリストして、更新するワーカー・ノードの ID および Primary IP をメモします。
```
ibmcloud oc worker ls --cluster CLUSTER
```

ワーカー・ノードを置換して、マスター・バージョンと同じパッチ・バージョンまたは major.minor バージョンに更新します。

ワーカーノードをマスターと同じ major.minor のバージョンに更新するには、 --update オプションを指定してください。

    ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update
    ```
*  `major.minor` のバージョンを同じまま、ワーカーノードを最新のパッチバージョンに更新するには、 `--update` オプションを指定しないでください。
```sh {: pre}
    ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID
    ```

更新する必要があるワーカー・ノードごとに、この手順を繰り返します。
オプション：交換されたワーカーノードが「 Ready」ステータスになったら、希望するクラスタの容量に合わせてワーカープールのサイズを変更してください。詳しくは、 VPC クラスターへのワーカー・ノードの追加を参照してください。

VPC クラスターで Portworx を実行している場合、manually attach your Block Storage for VPC ボリュームを新規のワーカー・ノードに手動で接続する必要があります。

コンソールでの VPC ワーカー・ノードの更新

コンソールで VPC ワーカー・ノードを更新できます。作業を開始する前に、アプリケーションのダウンタイムを防ぐため、クラスターにワーカーノードを追加することを検討してください。

前提条件手順を実行します。
IBM Cloud からをクリックし、 コンテナ > クラスター の順にクリックします。
**「クラスター」**ページから、クラスターを選択します。
**「ワーカー・ノード」**タブから、更新する各ワーカー・ノードのチェック・ボックスを選択します。アクション・バーがテーブル・ヘッダー行の上に表示されます。
アクション・バーで**「更新」**をクリックします。

フレーバー (マシン・タイプ) の更新

始める前に

Red Hat OpenShift クラスターにアクセスします。
ワーカー・ノード上のデータが削除されます。ワーカー・ノードの外部の永続ストレージにデータを保管することを検討してください。
オペレーター または、 管理者 IAMプラットフォームのアクセスロールがインストールされていることを確認してください。

フレーバーを更新するには、以下のようにします。

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

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

    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
    ```

ゾーンで使用可能なフレーバーをリストします。
```
ibmcloud oc flavors --zone <zone>
```

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

置き換えるワーカー・ノードと同じ数のワーカー・ノードを含むワーカー・プールを作成します。

クラシック・クラスター:

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

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

    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
        ```

ワーカー・ノードがデプロイされるまで待ちます。ワーカー・ノードの状態が**「正常」**に変わったら、デプロイメントは終了です。
```
ibmcloud oc worker ls --cluster CLUSTER
```
古いワーカー・ノードを削除します。注: 月次で請求されるフレーバー (ベアメタルなど) を削除する場合は、その月全体の料金を請求されます。
1. 古いマシン・タイプのワーカー・プールを削除します。ワーカー・プールを削除すると、そのプールのすべてのゾーンのすべてのワーカー・ノードが削除されます。このプロセスは、完了まで数分かかることがあります。
```
    ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
    ```
2. ワーカー・プールが削除されたことを確認します。
```sh {: pre}
    ibmcloud oc worker-pool ls --cluster CLUSTER
    ```
```
ワーカー・ノードがクラスターから削除されたことを確認します。
```
ibmcloud oc worker ls --cluster CLUSTER
```
上記の手順を繰り返して、他のワーカー・プールまたはスタンドアロン・ワーカー・ノードを別のフレーバーに更新します。

ワーカー・プールはどのようにスケールダウンされますか?

ワーカー・プール内のワーカー・ノードの数が減少すると (ワーカー・ノードの更新中や ibmcloud oc worker-pool resize コマンドを使用した場合など)、状態、正常性、バージョンなどのいくつかのプロパティーに基づいて、ワーカー・ノードの削除が優先されます。

この優先順位ロジックは、自動スケーリング機能アドオンには関係ありません。

以下の表は、ワーカー・ノードが削除のために優先順位付けされる順序を示しています。

ibmcloud oc worker ls コマンドを実行すると、表にリストされているすべてのワーカー・ノード・プロパティーを表示できます。

ワーカー・プールのスケールダウン時に削除されるワーカー・ノードの優先度。
優先順位	プロパティー (Property)	説明
1	ワーカー・ノードの状態	機能していない状態または機能していない状態のワーカー・ノードは、削除のために優先順位付けされます。このリストには、 `provision_failed`、 `deploy_failed`、 `deleting`、 `provision_pending`、 `provisioning`、 `deploying`、 `provisioned`、 `reloading_failed`、 `reloading`、 `deployed` の順に状態が表示されます。
2	作業ノードの健康状態	正常でないワーカー・ノードは、正常なワーカー・ノードより優先されます。このリストには、 `critical`、 `warning`、 `pending`、 `unsupported`、 `normal` の順で、正常性の状態が表示されます。
3	ワーカー・ノードのバージョン	古いバージョンで実行されるワーカー・ノードは、削除の優先順位が高くなります。
4	選択された配置設定	専用ホストで実行されているワーカーの場合のみ。 `DesiredPlacementDisabled` オプションが `true` に設定されている専用ホスト上で実行されているワーカー・ノードは、削除の優先順位が高くなります。
5	アルファベット順	ワーカー・ノードは、上記の要因に基づいて優先順位付けされた後、アルファベット順に削除されます。ワーカー・ノードの ID 規則に基づいて、クラシック・クラスターと VPC クラスターのワーカーの ID が年齢と相関するため、古いワーカー・ノードが最初に削除されることに注意してください。

クラスター・コンポーネントの更新

Red Hat OpenShift on IBM Cloud クラスターには Ingress などのコンポーネントが付属していて、クラスターのプロビジョン時に自動的にインストールされます。デフォルトでは、これらのコンポーネントは IBM によって自動的に更新されます。ただし、一部のコンポーネントは、自動更新を無効にして、マスター・ノードおよびワーカー・ノードとは別に手動で更新することができます。

クラスターとは別に、どのデフォルトコンポーネントを更新できますか？

必要に応じて、以下のコンポーネントの自動更新を無効にできます。

ロギング用の Fluentd
Ingress アプリケーション・ロード・バランサー (ALB)

クラスタとは別に更新できないコンポーネントはありますか？

はい。クラスターには、変更できない以下の管理対象コンポーネントおよび関連リソースとともにデプロイされます。ただし、特定のパフォーマンス上の利点を得るためにポッドをスケーリングしたり、構成マップを編集したりする場合は除きます。これらのデプロイメント・コンポーネントはクラスター・マスターと一緒に更新されるので、コンポーネントのいずれかを変更しようとしても、元の設定が定期的に復元されます。ただし、これらのコンポーネントに関連するユーザー作成のリソース (Calico デプロイメント・コンポーネントで実施するために作成した Calico ネットワーク・ポリシーなど) は更新されないことに注意してください。

calico コンポーネント
coredns コンポーネント
ibm-cloud-provider-ip
ibm-file-plugin
ibm-keepalived-watcher
ibm-master-proxy
ibm-storage-watcher
kubernetes-dashboard コンポーネント
metrics-server
olm-operator および catalog コンポーネント (1.16 以降)
vpn

デフォルトのコンポーネント以外のプラグインやアドオンをインストールしたり、追加したりすることはできますか？: はい。 Red Hat OpenShift on IBM Cloud には、クラスターに機能を追加するために選択できる、その他のプラグインやアドオンが用意されています。たとえば、クラスタで IBM 管理アドオンを有効にしたい場合があります。これらのアドオンは、管理されたアドオンを更新する手順に従って、個別に更新する必要があります。

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

```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 ライフサイクルの管理を参照してください。

マネージド・アドオンの更新

IBM Cloud Kubernetes Service のマネージドクラスター用アドオンを利用すれば、 Istio などのオープンソース機能を活用して、クラスターを簡単に強化することができます。クラスターに追加するオープンソース・ツールのバージョンは、IBM によるテストを受け、IBM Cloud Kubernetes Service で使用することを承認されています。クラスター内で有効にしたマネージド・アドオンを最新バージョンに更新するには、マネージド・アドオンの更新を参照してください。