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 ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 次のコマンドを実行して、KataConfig CR を削除します。

    $ oc delete kataconfig example-kataconfig
  2. 以下のコマンドを実行して、カスタムリソースが削除されたことを確認します。

    $ 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 が空であることを確認します。

手順

  1. ピア 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 を使用します。

  2. YAML ファイルの status スタンザを確認します。
  3. AWS の PODVM_AMI_ID パラメーターまたは Azure の AZURE_IMAGE_ID パラメーターに値が含まれている場合は、値を "" に設定します。
  4. 値を "" に設定した場合は、ピア 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 ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 以下の例に従って 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
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml

    新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

    インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

  3. 次のコマンドを実行して、インストールの進行状況を監視します。

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata-remote はクラスターにインストールされます。

  4. 次のコマンドを実行してデーモンセットを確認します。

    $ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon
  5. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass

    出力例

    NAME             HANDLER          AGE
    kata             kata             152m
    kata-remote      kata-remote      152m

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.