バージョン更新が利用可能かどうかを 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 つずつの適用

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 セクションにあります。 ラベルはすべて NodeSelectorKey と NodeSelectorValue で構成されます。 ラベルを使用して、更新するワーカー・ノードを指定できます。

   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_8_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) で定義したどのチェックにも一致しないすべてのワーカー・ノードのルールを定義できます。 チェック・テンプレートを使用して、独自のチェックを作成します。 どのチェックでも、ワーカー・ノードを指定するには、前述の手順で取得したワーカー・ノード・ラベルのいずれかを選択する必要があります。

   どのチェックでも、NodeSelectorKey と NodeSelectorValue に値を 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 状況のワーカー・ノードが重複してリストされることがあります。 重複を削除するには、トラブルシューティングを参照してください。