10.3. Pod VM イメージの更新
AWS、Azure、および IBM デプロイメントの場合、Pod VM イメージを更新する必要があります。enablePeerpods:
paramter が true
の場合に、OpenShift Sandboxed Containers Operator をアップグレードしても、既存の Pod VM イメージは自動的に更新されません。アップグレード後に Pod VM イメージを更新するには、KataConfig
CR を削除して再作成する必要があります。
AWS および Azure デプロイメントのピア Pod 設定マップを確認して、KataConfig
CR を再作成する前にイメージ ID が空であることを確認することもできます。
10.3.1. KataConfig カスタムリソースの削除
コマンドラインを使用して、KataConfig
カスタムリソース (CR) を削除できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
次のコマンドを実行して、
KataConfig
CR を削除します。$ oc delete kataconfig example-kataconfig
以下のコマンドを実行して、カスタムリソースが削除されたことを確認します。
$ oc get kataconfig example-kataconfig
出力例
No example-kataconfig instances exist
10.3.2. ピア Pod の CM イメージ ID が空であることを確認します。
KataConfig
CR を削除する場合は、ピア Pod の CM イメージ ID を削除する必要があります。AWS および Azure デプロイメントの場合、ピア Pod CM イメージ ID が空であることを確認します。
手順
ピア Pod 用に作成した config map を取得します。
$ oc get cm -n openshift-sandboxed-containers-operator peer-pods-cm -o jsonpath="{.data.AZURE_IMAGE_ID}"
AWS には
PODVM_AMI_ID
を使用します。Azure にはAZURE_IMAGE_ID
を使用します。- YAML ファイルの status スタンザを確認します。
-
AWS の
PODVM_AMI_ID
パラメーターまたは Azure のAZURE_IMAGE_ID
パラメーターに値が含まれている場合は、値を "" に設定します。 値を "" に設定した場合は、ピア Pod 設定マップにパッチを適用します。
$ oc patch configmap peer-pods-cm -n openshift-sandboxed-containers-operator -p '{"data":{"AZURE_IMAGE_ID":""}}'
AWS には
PODVM_AMI_ID
を使用します。Azure にはAZURE_IMAGE_ID
を使用します。
10.3.3. KataConfig カスタムリソースの作成
ワーカーノードに kata-remote
をランタイムクラスとしてインストールするには、KataConfig
カスタムリソース (CR) を作成する必要があります。
KataConfig
CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。
-
デフォルト設定で
kata-remote
という名前のRuntimeClass
CR を作成します。これにより、RuntimeClassName
フィールドの CR を参照して、kata-remote
をランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。
OpenShift Sandboxed Containers は、kata-remote
をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。
KataConfig
CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーが有効である。
- SSD ではなくハードディスクドライブにデプロイしている。
- 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
- CPU とネットワークが遅い。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の例に従って
example-kataconfig.yaml
マニフェストファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: enablePeerPods: true logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>' 1
次のコマンドを実行して、
KataConfig
CR を作成します。$ oc apply -f example-kataconfig.yaml
新しい
KataConfig
CR が作成され、ワーカーノードにkata-remote
がランタイムクラスとしてインストールされます。インストールを確認する前に、
kata-remote
のインストールが完了し、ワーカーノードが再起動するまで待ちます。次のコマンドを実行して、インストールの進行状況を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
kataNodes
の下にあるすべてのワーカーのステータスがinstalled
で、理由を指定せずにInProgress
の条件がFalse
の場合、kata-remote
はクラスターにインストールされます。次のコマンドを実行してデーモンセットを確認します。
$ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon
次のコマンドを実行してランタイムクラスを確認します。
$ oc get runtimeclass
出力例
NAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m