仮想化サービスクラスタの管理
Virtual Private Cloud 4.21 and later Bare metal worker nodes only RHCOS only
OpenShift Virtualization Service クラスタの管理方法について学びましょう。これには、事前構成済みのコンポーネントの操作、ワーカーノードの管理、およびメンテナンスタスクの実行が含まれます。
管理対象コンポーネントについて
仮想化サービスクラスターには、標準の OpenShift クラスターとは異なる方法で管理される、いくつかの事前構成済みコンポーネントが含まれています。
主要コンポーネント(無効化できません)
以下のコンポーネントは仮想化サービスに不可欠であり、無効にすることはできません:
- OpenShift 仮想化アドオン
- 「
openshift-virtualization」アドオンは、すべてのVirtualization Serviceクラスターで自動的に有効化され、無効にすることはできません。 このアドオンは、 OpenShift Virtualization、NMState、および Node Maintenanceの各オペレーターのインストールと更新を管理します。 詳細については、「 OpenShift 仮想化アドオンの管理 」を参照してください。 - OpenShift Virtualization Operator
- 仮想マシンの管理機能を提供します。 このオペレーターはアドオンによって自動的にインストールされ、クラスターのライフサイクルの一環として更新されます。 Red Hat からのインストール OperatorHub がブロックされています。
- NMStateオペレーター
- 仮想マシンおよびノードのネットワーク設定を管理します。 このオペレーターは、アドオンによって自動的にインストールされます。
- Node 保守オペレーター
- 仮想マシンのワークロードに対するノードのメンテナンス操作を処理します。 このオペレーターは、アドオンによって自動的にインストールされます。
- OpenShift データ・ファウンデーション(ODF)
- VM ディスクのストレージを提供し、ライブマイグレーションを可能にします。 ODFは、ベアメタルノード上のローカルNVMeストレージを使用するようにあらかじめ設定されています。
管理対象アドオンの表示
クラスタ内のすべてのアドオンを表示します:
ibmcloud ks cluster addon ls --cluster CLUSTER_NAME
出力例:
Name Version Health State Health Status
ibm-storage-operator 1.0 normal Addon Ready. For more info: http://ibm.biz/addon-state (H1500)
openshift-virtualization 4.21 normal Addon Ready. For more info: http://ibm.biz/addon-state (H1500)
「 openshift-virtualization 」アドオンは、Virtualization Service クラスターでは自動的に有効化され、無効にすることはできません。
「 OpenShift 」仮想化アドオンの管理(詳細の表示、バージョンの確認、更新など)に関する詳細については、 「 OpenShift 」仮想化アドオンの管理を 参照してください。
ワーカーノードの管理
ワーカーノードの表示
クラスタ内のすべてのワーカーノードを一覧表示するには:
ibmcloud ks workers --cluster CLUSTER_NAME
または、 OpenShift のCLIを使用します:
oc get nodes
ワーカー・ノードの追加
既存のワーカープールにワーカーノードを追加する:
ibmcloud ks worker-pool resize --cluster CLUSTER_NAME \
--worker-pool default \
--size-per-zone NUMBER_OF_WORKERS
Virtualization Service クラスタ内のすべてのワーカーノードは、サポートされているベアメタルフレーバーを使用する必要があります。
ワーカーノードの交換
ワーカーノードを交換する:
ibmcloud ks worker replace --cluster CLUSTER_NAME --worker WORKER_ID
代替のワーカーには、元のワーカーと同じ設定が適用されます。
ワーカーノードの再読み込み
ワーカーノードを再起動する前に、 Node のメンテナンスオペレーターを使用してそのノードをメンテナンス状態にするか、実行中のVMを他のノードに移行してください。 詳細については、「 ノードをメンテナンス状態にする 」および「 VMのライブマイグレーション 」を参照してください。
更新を適用したり、問題を修正したりするためにワーカーノードを再起動します:
ibmcloud ks worker reload --cluster CLUSTER_NAME --worker WORKER_ID
労働者プールの管理
ワーカープールの表示
ibmcloud ks worker-pool ls --cluster CLUSTER_NAME
追加のワーカープールの作成
別のベアメタル・フレーバーを使用して新しいワーカー・プールを作成します:
ibmcloud ks worker-pool create vpc-gen2 \
--name POOL_NAME \
--cluster CLUSTER_NAME \
--flavor BARE_METAL_FLAVOR \
--size-per-zone NUMBER_OF_WORKERS
仮想化サービスクラスタ内のすべてのワーカープールは、 openshift-vs に対応したベアメタルフレーバーを使用する必要があります。
ワーカープールへのゾーンの追加
既存のワーカープールにゾーンを追加する:
ibmcloud ks zone add vpc-gen2 \
--cluster CLUSTER_NAME \
--zone ZONE \
--subnet-id SUBNET_ID \
--worker-pool POOL_NAME
クラスタの更新
更新プログラムのチェック
クラスタの更新プログラムが利用可能かどうかを確認してください:
ibmcloud ks cluster get --cluster CLUSTER_NAME | grep "Master Version"
利用可能なバージョンを表示:
ibmcloud ks versions --show-version openshift
クラスタマスターの更新
クラスタマスターを新しいバージョンに更新します:
ibmcloud ks cluster master update --cluster CLUSTER_NAME --version VERSION
マスターの更新には通常、30分から60分ほどかかります。 この期間中、 Kubernetes API および OpenShift コンソールにはアクセスできません。
ワーカー・ノードの更新
マスターの更新後、ワーカーノードを更新します:
ibmcloud ks worker update --cluster CLUSTER_NAME --worker WORKER_ID
または、ワーカープール内のすべてのワーカーを更新します:
ibmcloud ks worker-pool update --cluster CLUSTER_NAME --worker-pool POOL_NAME
ワーカーノードを更新する前に、「 Node 」のメンテナンスオペレーターを使用して各ノードをメンテナンス状態にするか、実行中のVMを他のノードに移行してください。 詳細については、「 ノードをメンテナンス状態にする 」および「 VMのライブマイグレーション 」を参照してください。
クラスターの正常性のモニタリング
クラスタの状態を確認する
ibmcloud ks cluster get --cluster CLUSTER_NAME
以下を探してください。
- 状態 :~であるべき
normal - マスターステータス :~であるべき
Ready - マスター・ヘルス :~であるべき
normal
コンポーネントの状態監視
OpenShift の仮想化状態を確認する:
oc get hyperconverged -n openshift-cnv
ODFの状態を確認する:
oc get storagecluster -n openshift-storage
クラスタログの表示
クラスタのアクティビティを表示:
ibmcloud ks cluster get --cluster CLUSTER_NAME --show-resources
詳細なログ記録を行うには、 IBM Log Analysis を設定してください。 クラスタのログ記録については、「ログ記録 」を参照してください。
仮想マシンの管理
仮想マシンの表示
クラスタ内のすべてのVMを一覧表示する:
oc get vms -A
特定のネームスペース内のVMを表示する:
oc get vms -n NAMESPACE
ノードをメンテナンス状態にする
ベアメタル・ワーカーノードの更新、再読み込み、または交換などのメンテナンス作業を行う前に、そのノードをメンテナンスモードにしてください。 Node のメンテナンスオペレーターは、ノードを隔離し、対象となるすべての仮想マシンのワークロードを、ワークロードを中断することなく、同じゾーン内の他のノードへ自動的に移行またはライブマイグレーションします。
クラスタで OpenShift Data Foundation (ODF) を使用している場合、ODF ストレージコンポーネントを実行するノードについては、この手順ではなく、ODF のアップグレードおよびメンテナンス手順に従う必要があります。 詳しくは、OpenShift Data Foundation についてを参照してください。
Webコンソールからのノードメンテナンスの開始
Red Hat OpenShift のWebコンソールから直接、ノードのメンテナンスを開始できます。
- OpenShift のWebコンソールで、管理者ビューを開き、「 Compute 」>「 Nodes 」に移動します。
- メンテナンスを行う対象のベアメタルワーカーノードを特定します。
- そのノードのアクションメニュー(縦に並んだ3つのドット)をクリックし、「 メンテナンスを開始 」を選択してください。
- 確認ダイアログで、メンテナンス設定を確認し、「 開始 」をクリックしてください。
- ノードのステータスが「
Scheduling disabled」と表示されていること、およびアクションメニューに「 Start maintenance 」ではなく「 Stop maintenance 」が表示されていることを確認してください。 すべての VM インスタンスが他の利用可能なノードへ移行するまで待ってから、ノードレベルの操作(ibmcloud ks worker reloadやibmcloud ks worker updateなど)を実行してください。 - メンテナンス作業が完了し、ノードの状態が正常になったら、 「Compute 」>「 Nodes 」に戻り、そのノードのアクションメニューをクリックして、「 メンテナンスを停止 」を選択してください。
CLI からのノードメンテナンスの開始
また、 NodeMaintenance というカスタムリソースを作成することで、ノードのメンテナンスを開始することもできます。
-
「
node-maintenance.yaml」という名前のYAMLファイルを作成し、NodeMaintenanceのカスタムリソース定義を記述します。 「nodeName」フィールドに、対象のベアメタル・ワーカーノード名を指定してください。apiVersion: nodemaintenance.medik8s.io/v1beta1 kind: NodeMaintenance metadata: name: nodemaintenance-NODE_NAME spec: nodeName: NODE_NAME reason: Node maintenance for update or reload -
カスタムリソースを適用して、ノードをメンテナンスモードに切り替えます:
oc apply -f node-maintenance.yaml -
NodeMaintenanceリソースのステータスを監視し、ドレイン操作が正常に完了したことを確認します:oc get nodemaintenance nodemaintenance-NODE_NAME -o jsonpath='{.status.phase}'ノードの再読み込み、更新、または置換に進む前に、フェーズが「
Succeeded」と報告されていることを確認してください。 -
ワーカーノードのリロードや更新など、計画したノードレベルの操作を実行します:
ibmcloud ks worker reload --cluster CLUSTER_NAME --worker WORKER_ID -
ノードの再読み込みまたは更新が完了し、
oc get nodesでのノードの状態が「Ready」になったら、NodeMaintenanceリソースを削除して、そのノードをメンテナンス状態から解除しますoc delete nodemaintenance nodemaintenance-NODE_NAME
VMの手動によるライブマイグレーション
Node メンテナンスオペレーターを使用せずに、個々の仮想マシンに対してライブマイグレーションを手動で実行したい場合は、次のようにします
-
移行対象の VM の名前を特定するために、そのネームスペース内の仮想マシンインスタンスの一覧を表示します:
oc get vmi -n NAMESPACE -
VM のライブマイグレーションを実行するには:
virtctl migrate VM_NAME -n NAMESPACE
VM に仮想ネットワークインターフェイス(VNI)が接続されている場合、ライブマイグレーションは同一ゾーン内でのみサポートされます。 このような VM をゾーン間で移行することは可能ですが、VNIはゾーン間でアタッチできないため、 VM のネットワークが機能しなくなってしまいます。
仮想マシンの停止と起動
VM を停止する:
virtctl stop VM_NAME -n NAMESPACE
VM の開始:
virtctl start VM_NAME -n NAMESPACE
ストレージ管理
ストレージ容量の監視
ODFの保存容量を確認する:
oc get cephcluster -n openshift-storage -o jsonpath='{.items[0].status.ceph.capacity}'
ストレージの使用状況を確認する:
oc get cephblockpool -n openshift-storage
永続ボリュームのクレームの管理
VMで使用されているPVCの一覧:
oc get pvc -A | grep virtualmachine
PVCの詳細を表示:
oc describe pvc PVC_NAME -n NAMESPACE
トラブルシューティング
Virtualization Service クラスタに関する一般的な問題のトラブルシューティングについては、以下のトピックを参照してください:
- クラスタのトラブルシューティング- ワーカーノードの問題、クラスタへのアクセス、および一般的なクラスタの問題
- OpenShift 仮想化のトラブルシューティング- 仮想マシンの問題、オペレーターに関する問題、および仮想化特有のエラー
- ストレージのトラブルシューティング- 「 OpenShift 」のData Foundationおよび永続ボリュームに関する問題