ワーカーノードとして割り当てられているホストの更新
クラスタなどの 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 で確認する
- IBM Cloud にログインします。 統合されたアカウントがある場合は、
--sso
オプションを使用します。ibmcloud login [--sso]
- アカウントの Satellite クラスターをリスト表示します。
ibmcloud ks cluster ls --provider satellite
- バージョンを更新するクラスター内のワーカー・ノードをリストします。 出力で、バージョン更新が利用可能であることを示すメッセージが付随するアスタリスク
*
がないか確認します。
出力例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 コンソールで確認する
- Satellite コンソールにログインします。
- 更新するホストが含まれたロケーションをクリックします。
- **「ホスト」**タブをクリックします。
- ホスト・リストから、更新するホストの**「クラスター」**へのリンクをクリックします。 新しいタブが開いて、Red Hat OpenShift on IBM Cloud クラスターの詳細が表示されます。
- **「ワーカー・ノード」**タブをクリックします。
- バージョン欄で、アイコンをクリックしたときに「
Update available
」と表示される情報アイコンがあるかどうかを確認する。 利用可能な更新がない場合は、アイコンは表示されません。 - バージョン更新がメジャー更新、マイナー更新、パッチ更新のいずれであるかを確認します。
ワーカー・ノード・ホストの識別
ホストがコントロール・プレーンの一部であるか、管理対象サービスに割り当てられているか、ロケーションに接続されているかを判別します。
-
ロケホストをリストアップし、その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
-
ワーカー・ノードとして 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 つずつの適用
-
オプション: 既存のホストの更新中に計算容量を処理するために、サービス・クラスターに 接続 および 割り当て を行います。
-
ワーカー・ノード・ホストを識別します。 ワーカー・ノード・ホストには、出力の
Cluster
列にinfrastructure
がリストされていませんが、代わりにクラスターの名前が付いています。 -
ibmcloud ks worker update
コマンドを実行して、ワーカー・ノードを個別に更新します。ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
-
ワーカー・ノードの Kubernetes バージョンを確認して、更新が完了したことを確認します。
kubectl get nodes
更新が失敗した場合は、 ホストを置換してバージョン更新を適用する 必要があります。
ConfigMap を使用してワーカー・ノード・ホストにバージョン更新を適用します。
ConfigMapを使用して、すべてのワーカー・ノード・ホストに更新をロールアウトできます。 ラベルを使用して更新するノードを指定します。 以下を指定することもできます。
-
オプション: 既存のホストの更新中に計算容量を処理するために、サービス・クラスターに 接続 および 割り当て を行います。
-
ワーカー・ノード・ホストを識別します。 ワーカー・ノード・ホストが
Infrastructure
としてリストされません。 -
ワーカー・ノードのラベルを表示します。 ワーカー・ノード・ラベルは、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_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
-
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
- 定義したルールの対象になるワーカー・ノードのラベル値。
-
クラスター内に構成マップを作成します。
kubectl apply -f <filepath/configmap.yaml>
-
ConfigMap が作成されていることを確認する。
kubectl get configmap --namespace kube-system
-
ワーカー・ノードを ID 別にリストして更新します。
ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
-
オプション: ConfigMap、発生した検証エラーによってトリガーされるイベントを確認する。 これらのイベントは、CLI 出力内の Events セクションで確認できます。
kubectl describe -n kube-system cm ibm-cluster-update-configuration
-
ワーカー・ノードの Kubernetes バージョンを確認して、更新が完了したことを確認します。
kubectl get nodes
更新が失敗した場合は、 ホストを置換してバージョン更新を適用する 必要があります。
-
ワーカー・ノードが重複していないことを確認します。 場合によっては、古いクラスターで、更新後に
NotReady
状況のワーカー・ノードが重複してリストされることがあります。 重複を削除するには、トラブルシューティングを参照してください。
ホストの置換によるワーカー・ノードへのバージョン更新の適用
ロケーションに接続されているホストは自動更新されません。 バージョン アップデートを適用するには、まず Satellite 対応の IBM Cloud サービス に新しいホストをアタッチして割り当て、その後古いホストを削除します。 マイナー・バージョンおよびパッチ・バージョンの更新をインプレースで 適用することもできます。
-
現在のホストをリストし、それぞれの 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*
-
Satellite ロケーションに新規ホストを接続します。 接続するホストの数は、更新するホストの数と一致している必要があります。
-
新規に接続したホストを Satellite リソースに割り当てます。 割り当てると、それらのホストが自動的に更新を受け取るようになります。
-
新規ホストが Satellite リソースに正常に割り当てられたら、先ほどメモした古いホストを削除します。
Red Hat OpenShift on IBM Cloud コンソールでのワーカー・ノード・ホストの更新
Red Hat OpenShift on IBM Cloud コンソールを使用してワーカー・ノード・ホストを更新できます。
- IBM Cloud コンソールにログインし、「OpenShift」>**「クラスター」**をクリックします。
- 更新するホストが割り当てられているクラスターをクリックし、**「ワーカー・ノード」**ページにナビゲートします。
- 更新する各ホストを選択します。 ホストを選択すると、**「更新」**オプションが表示されます。
- 更新 をクリックします。 表示されるダイアログ・ボックスで、もう一度**「更新」**をクリックします。 更新が正常に開始されたというメッセージが表示されます。
- ホストが更新されるまで待ちます。 各ホストの更新処理が完了するのは、ホストの**「状況」が「正常」に戻り、「バージョン」**列に新規バージョンがリストされたときです。
ワーカー・ノードのバージョン更新がメジャー更新、マイナー更新、パッチ更新のいずれであるかを確認する
ワーカー・ノードを更新するプロセスは、すべてのタイプの更新で同じです。 ただし、更新がメジャー更新なのか、マイナー更新なのか、パッチ更新なのかについての情報を見つけることができます。
使用可能な更新のタイプを判別するには、現在のワーカー・ノードのバージョンを Red Hat OpenShift バージョンの変更ログの最新の worker node fix pack
バージョンと比較します。 メジャー更新はバージョン・ラベルの 1 桁目 (4.x.x) で表されます。マイナー更新は 2 桁目 (x.7.x)、パッチ更新は末尾の桁で
(x.x.23_1528_openshift) で示されます。 バージョン更新について詳しくは、バージョン情報および更新操作を参照してください。