7.7. KataConfig カスタムリソースの再作成
Confidential Containers の KataConfig
カスタムリソース (CR) を再作成する必要があります。
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
- 1
- オプション: 特定のノードに
kata-remote
をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例:cc: 'true')
。
次のコマンドを実行して、
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
はクラスターにインストールされます。次のコマンドを実行して、ピア Pod イメージが構築され、libvirt ボリュームにアップロードされたことを確認します。
$ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
出力例
Name: peer-pods-cm Namespace: openshift-sandboxed-containers-operator Labels: <none> Annotations: <none> Data ==== CLOUD_PROVIDER: libvirt DISABLECVM: false 1 LIBVIRT_IMAGE_ID: fa-pp-vol 2 BinaryData ==== Events: <none>
次のコマンドを実行して、
kata-oc
マシン設定プールの進行状況を監視し、UPDATEDMACHINECOUNT
がMACHINECOUNT
と等しいときにUPDATED
状態であることを確認します。$ watch oc get mcp/kata-oc
次のコマンドを実行してデーモンセットを確認します。
$ 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