OpenShift sandboxed containers のデプロイ


OpenShift sandboxed containers 1.10

コンテナーワークロードのセキュリティーと分離の強化

Red Hat Customer Content Services

概要

Red Hat OpenShift sandboxed containers は、コンテナー化されたアプリケーションを軽量の仮想マシンで実行することで、セキュリティーと分離を強化します。OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールします。その後、オプションの "kata" ランタイムを使用するようにワークロード Pod を設定します。

はじめに

Red Hat ドキュメントへのフィードバック (英語のみ)

Jira で Create Issue フォームを送信することで、フィードバックを提供したり、エラーを報告したりできます。

  1. Jira にログインしていることを確認してください。Jira アカウントをお持ちでない場合は、Red Hat Jira アカウント を作成する必要があります。
  2. Create Issue フォーム を起動します。
  3. Summary フィールド、Description フィールド、および Reporter フィールドに入力します。

    Description フィールドに、ドキュメントの URL、章またはセクション番号、および問題の詳しい説明を入力します。

  4. Create をクリックします。

第1章 OpenShift sandboxed containers について

Red Hat OpenShift sandboxed containers は、Kata containers をオプションのランタイムとして統合し、コンテナー化されたアプリケーションを軽量の仮想マシンで実行することで、セキュリティーと分離を強化します。この統合により、既存の OpenShift Container Platform ワークフローに大きな変更を加えることなく、機密性の高いワークロードに対してよりセキュアなランタイム環境が提供されます。このランタイムは、専用の仮想マシン (VM) でコンテナーをサポートし、ワークロードの分離を改善します。

1.1. 機能

OpenShift sandboxed containers は、次の機能を提供します。

特権または信頼できないワークロードを実行する

特権コンテナーを実行することでクラスターノードが危険にさらされることなく、特定の特権を必要とするワークロードを安全に実行できます。特別な権限を必要とするワークロードには、次のものがあります。

  • たとえば、低レベルのネットワーク機能にアクセスするために、CRI-O などの標準コンテナーランタイムによって付与されるデフォルトの機能を超えて、カーネルからの特別な機能を必要とするワークロード。
  • 特定の物理デバイスにアクセスする場合など、ルート権限の昇格が必要なワークロード。OpenShift sandboxed containers を使用すると、特定のデバイスのみを仮想マシン (VM) に渡すことができるため、ワークロードがシステムの残りの部分にアクセスしたり、設定を誤ったりすることはありません。
  • set-uid ルートバイナリーをインストールまたは使用するためのワークロード。これらのバイナリーは特別な権限を付与するため、セキュリティーリスクが生じる可能性があります。OpenShift sandboxed containers を使用すると、追加の権限は仮想マシンに制限され、クラスターノードへの特別なアクセスは許可されません。

    一部のワークロードでは、特にクラスターノードを設定するための特権が必要です。このようなワークロードは、仮想マシンで実行すると機能しなくなるため、引き続き特権コンテナーを使用する必要があります。

機密性の高いワークロードを分離する
Red Hat OpenShift Container Platform の OpenShift sandboxed containers は、Kata containers をオプションのランタイムとして統合します。これにより、コンテナー化されたアプリケーションを軽量の仮想マシンで実行することで、セキュリティーと分離を強化します。このインテグレーションにより、既存の OpenShift ワークフローに大きな変更を加えることなく、機密性の高いワークロードに対してより安全なランタイム環境が提供されます。このランタイムは、専用の仮想マシン (VM) でコンテナーをサポートし、ワークロードの分離を改善します。
各ワークロードのカーネルを確実に分離する
カスタムカーネルチューニング (sysctl、スケジューラーの変更、キャッシュチューニングなど) とカスタムカーネルモジュール (out of tree または特別な引数など) の作成を必要とするワークロードを実行できます。
テナント全体で同じワークロードを共有する
同じ OpenShift Container Platform クラスターを共有するさまざまな組織のユーザー (テナント) を多数サポートするワークロードを実行できます。このシステムは、コンテナーネットワーク機能 (CNF) やエンタープライズアプリケーションなど、複数のベンダーからのサードパーティーワークロードの実行もサポートします。たとえば、サードパーティーの CNF は、カスタム設定がパケットチューニングや他のアプリケーションによって設定された sysctl 変数に干渉することを望まない場合があります。完全に分離されたカーネル内で実行すると、"ノイジーネイバー" 設定の問題を防ぐのに役立ちます。
ソフトウェアのテストに適した分離とサンドボックスがあることを確認する
既知の脆弱性がある、コンテナー化されたワークロードを実行したり、レガシーアプリケーションの問題を処理したりできます。この分離により、管理者は Pod に対する管理制御を開発者に付与することができます。これは、開発者が、管理者が通常許可する設定を超えて設定をテストまたは検証したい場合に役立ちます。たとえば、管理者はカーネルパケットフィルタリング (eBPF) を安全かつ確実に開発者に委譲できます。eBPF には CAP_ADMIN または CAP_BPF 権限が必要となるため、標準の CRI-O 設定では許可されません。Container Host ワーカーノード上のすべてのプロセスへのアクセスを許可することになるためです。同様に、管理者は SystemTap などの侵入型ツールへのアクセスを許可したり、開発中にカスタムカーネルモジュールの読み込みをサポートしたりできます。
仮想マシン境界によるデフォルトのリソースの封じ込めを確保する
デフォルトでは、OpenShift sandboxed containers は、CPU、メモリー、ストレージ、ネットワークなどのリソースを堅牢かつ安全な方法で管理します。OpenShift sandboxed containers は仮想マシンにデプロイされるため、分離とセキュリティーのレイヤーを追加することで、リソースへのアクセスをよりきめ細かく制御できます。たとえば、コンテナーが誤っている場合は、仮想マシンで使用できる以上のメモリーを割り当てることができません。逆に、ネットワークカードまたはディスクへの専用アクセスが必要なコンテナーは、他のデバイスにアクセスすることなく、そのデバイスを完全に制御できます。

1.2. OpenShift Container Platform との互換性

Red Hat OpenShift Container Platform に必要な機能は、次の 2 つの主要コンポーネントによってサポートされています。

Kata ランタイム
Kata ランタイムは Red Hat Enterprise Linux CoreOS (RHCOS) に含まれており、OpenShift Container Platform がリリースされるたびに更新されます。Kata ランタイムでピア Pod を有効にする場合、OpenShift sandboxed containers Operator では、Pod 仮想マシン (VM) イメージを作成するために必要なイメージコンポーネントとヘルパーユーティリティーをプルするための外部ネットワーク接続が必要です。
OpenShift sandboxed containers Operator
OpenShift sandboxed containers Operator は Rolling Stream Operator です。そのため、サポートされるのは最新バージョンのみです。これは、現在サポートされているすべてのバージョンの OpenShift Container Platform で動作します。

Operator は、RHCOS ホストに含まれる機能とホストが実行される環境に依存します。

注記

ワーカーノードには RHCOS をインストールする必要があります。Red Hat Enterprise Linux (RHEL) ノードはサポートされていません。

OpenShift sandboxed containers と OpenShift Container Platform リリースの次の互換性に関する表は、互換性のある機能と環境を示しています。

Expand
表1.1 サポート対象のアーキテクチャー
アーキテクチャーOpenShift Container Platform バージョン

x86_64

4.16 以降

s390x

4.16 以降

Kata コンテナーランタイムをデプロイするには、次の 2 つの方法があります。

  • ベアメタル
  • ピア Pod

ピア Pod を使用することで、Microsoft Azure Cloud Computing Services、AWS Cloud Computing Services、または Google Cloud 上で OpenShift sandboxed containers をデプロイできます。OpenShift sandboxed containers 1.10 のリリースにより、OpenShift sandboxed containers Operator には OpenShift Container Platform バージョン 4.16 以降が必要になりました。

Expand
表1.2 OpenShift Container Platform バージョン別の機能の提供状況
機能デプロイメント方法OpenShift Container Platform 4.16OpenShift Container Platform 4.17OpenShift Container Platform 4.18OpenShift Container Platform 4.19

機密コンテナー

ベアメタル

該当なし

該当なし

該当なし

該当なし

Azure ピア Pod

GA

GA

GA

GA

GPU サポート

ベアメタル

該当なし

該当なし

該当なし

該当なし

IBM Z

該当なし

該当なし

該当なし

該当なし

Azure

開発者プレビュー

開発者プレビュー

開発者プレビュー

開発者プレビュー

AWS

開発者プレビュー

開発者プレビュー

開発者プレビュー

開発者プレビュー

Google Cloud

開発者プレビュー

開発者プレビュー

開発者プレビュー

開発者プレビュー

重要

ピア Pod の GPU サポートは、開発者プレビュー機能のみです。開発者プレビュー機能は、Red Hat ではいかなる形でもサポートされていません。また、機能的には完全ではなく、実稼働環境に対応していません。開発者プレビュー機能は、実稼働ワークロードまたはビジネスクリティカルなワークロードには使用しないでください。開発者プレビュー機能は、Red Hat 製品オファリングに含まれる可能性がある前に、今後の製品機能への早期アクセスを提供し、お客様が機能をテストし、開発プロセス中にフィードバックを提供できるようにします。これらの機能にはドキュメントがない可能性があり、いつでも変更または削除される可能性があり、テストは制限されています。Red Hat は、関連する SLA なしで、開発者プレビュー機能に関するフィードバックを送信する方法を提供する場合があります。

Expand
表1.3 OpenShift sandboxed containers でサポートされているクラウドプラットフォーム
プラットフォームGPU機密コンテナー

Azure

開発者プレビュー

GA

AWS

開発者プレビュー

該当なし

Google Cloud

開発者プレビュー

該当なし

1.3. ノードの適格性チェック

ノードの適格性チェックを実行して、ベアメタルクラスターノードが OpenShift sandboxed containers をサポートすることを確認できます。ノードが不適格となる最も一般的な理由は、仮想化サポートの欠如です。不適格なノードでサンドボックス化されたワークロードを実行すると、エラーが発生します。

ワークフローの概要

  1. Node Feature Discovery Operator をインストールします。
  2. NodeFeatureDiscovery カスタムリソース (CR) を作成します。
  3. Kataconfig CR を作成するときにノード適格性チェックを有効にします。すべてのワーカーノードまたは一部のノードでノード適格性チェックを実行できます。

1.4. 一般的な用語

以下の用語は、このドキュメント全体で使用されています。

サンドボックス

サンドボックスとは、プログラムが実行可能な分離された環境のことです。サンドボックスでは、ホストマシンやオペレーティングシステムに悪影響を及ぼすことなく、テストされていないプログラムまたは信頼できないプログラムを実行できます。

OpenShift sandboxed containers のコンテキストでは、仮想化を使用して異なるカーネルでワークロードを実行し、同じホストで実行される複数のワークロードとの間の対話を強化することでサンドボックス化を図ります。

Pod

Pod は Kubernetes および OpenShift Container Platform から継承されるコンストラクトです。Pod とは、コンテナーのデプロイが可能なリソースを表します。コンテナーは Pod 内で実行されます。Pod は複数のコンテナー間で共有できるリソースを指定するために使用されます。

OpenShift sandboxed containers のコンテキストでは、Pod が仮想マシンとして実装されます。同じ仮想マシンにある同じ Pod でコンテナーを複数実行できます。

OpenShift sandboxed containers Operator
OpenShift sandboxed containers Operator は、クラスター上のサンドボックスコンテナーのライフサイクルを管理します。OpenShift sandboxed containers Operator を使用すると、サンドボックスコンテナーのインストールと削除、ソフトウェアの更新、ステータスの監視などのタスクを実行できます。
Kata containers
Kata containers は、OpenShift sandboxed containers の構築に使用されるコアアップストリームプロジェクトです。OpenShift sandboxed containers は Kata containers を OpenShift Container Platform と統合します。
KataConfig
KataConfig オブジェクトは、サンドボックスコンテナーの設定を表します。ソフトウェアのデプロイ先のノードなど、クラスターの状態に関する情報を保存します。
ランタイムクラス
RuntimeClass オブジェクトは、特定のワークロードを実行するために使用するランタイムを記述したものです。OpenShift sandboxed containers Operator によってインストールおよびデプロイされるのは、kata ランタイムクラスです。このランタイムクラスには、Pod オーバーヘッド など、ランタイムが動作するために必要なリソースを示すランタイムに関する情報が含まれています。
ピア Pod

OpenShift sandboxed containers のピア Pod は、標準 Pod の概念を拡張します。標準のサンドボックスコンテナーでは仮想マシンはワーカーノード自体に作成されますが、ピア Pod では、サポートされているハイパーバイザーまたはクラウドプロバイダーの API を使用してリモートハイパーバイザー経由で仮想マシンが作成されます。

ピア Pod はワーカーノード上で通常の Pod として機能し、対応する VM が別の場所で実行されます。VM のリモートの場所はユーザーに対して透過的であり、Pod 仕様のランタイムクラスによって指定されます。ピア Pod 設計により、ネストされた仮想化の必要性が回避されます。

IBM Secure Execution
Linux の IBM Secure Execution は、IBM z15® および LinuxONE III で導入された高度なセキュリティー機能です。この機能は、広範囲な暗号化によって提供される保護を拡張します。IBM Secure Execution は、保存中、転送中、使用中のデータを保護します。ワークロードを安全にデプロイでき、ライフサイクル全体にわたってデータを保護できます。詳細は、Introducing IBM Secure Execution for Linux を参照してください。
機密コンテナー
機密コンテナーは、ワークロードが Trusted Execution Environment (TEE) で実行されていることを検証することで、コンテナーとデータを保護します。この機能をデプロイして、ビッグデータ分析および機械学習推論のプライバシーを保護することができます。
Red Hat build of Trustee
Red Hat build of Trustee は、ワークロードを実行する予定の場所、または機密情報を送信する予定の場所の信頼性を検証するアテステーションサービスです。Red Hat build of Trustee には、信頼できる側にデプロイされ、リモートワークロードが Trusted Execution Environment (TEE) で実行されているかどうかを確認するために使用されるコンポーネントが含まれます。Red Hat build of Trustee は柔軟性が高く、さまざまなアプリケーションやハードウェアプラットフォームをサポートするために、さまざまな設定でデプロイできます。
Red Hat build of Trustee Operator
Red Hat build of Trustee Operator は、Red Hat build of Trustee のインストール、ライフサイクル、および設定を管理します。

1.5. OpenShift sandboxed containers Operator

OpenShift sandboxed containers Operator は、Kata containers からのコンポーネントをすべてカプセル化します。インストール、ライフサイクル、設定タスクを管理します。

OpenShift sandboxed containers Operator は、次の 2 つのコンテナーイメージとして Operator バンドル形式 でパッケージ化されています。

  • バンドルイメージはメタデータを含んでおり、Operator を OLM に対応させるために必要です。
  • 2 つ目のコンテナーイメージには、KataConfig リソースを監視および管理する実際のコントローラーが含まれています。

OpenShift sandboxed containers Operator は Red Hat Enterprise Linux CoreOS (RHCOS) 拡張機能の概念に基づいています。RHCOS 拡張機能は、オプションの OpenShift Container Platform ソフトウェアをインストールするためのメカニズムです。OpenShift sandboxed containers Operator は、このメカニズムを使用してクラスターにサンドボックスコンテナーをデプロイします。

サンドボックスコンテナー RHCOS 拡張機能には、Kata、QEMU、およびその依存関係の RPM が含まれています。これらは、Machine Config Operator が提供する MachineConfig リソースを使用して有効にできます。

1.6. OpenShift Virtualization

OpenShift Virtualization を使用してクラスターで OpenShift sandboxed containers をデプロイできます。

OpenShift Virtualization と OpenShift sandboxed containers を同時に実行するには、ノードの再起動がブロックされないように、仮想マシンがライブマイグレーション可能である必要があります。詳細は、OpenShift Virtualization ドキュメントの ライブマイグレーションについて を参照してください。

1.7. ブロックボリュームのサポート

OpenShift Container Platform は、raw ブロックボリュームを静的にプロビジョニングできます。これらのボリュームにはファイルシステムがなく、ディスクに直接書き込むアプリケーションや、独自のストレージサービスを実装するアプリケーションにはパフォーマンス上の利点があります。

OpenShift サンドボックスコンテナーでは、ローカルブロックデバイスを永続ボリューム (PV) ストレージとして使用できます。このブロックデバイスは、Local Storage Operator (LSO) を使用してプロビジョニングできます。

ローカルストレージ Operator はデフォルトで OpenShift Container Platform にインストールされません。インストール手順は、Local Storage Operator のインストール を参照してください。

OpenShift サンドボックスコンテナーの Raw ブロックボリュームは、PV 仕様で volumeMode: Block を指定してプロビジョニングされます。

ブロックボリュームの例

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "local-disks"
  namespace: "openshift-local-storage"
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - worker-0
  storageClassDevices:
    - storageClassName: "local-sc"
      forceWipeDevicesAndDestroyAllData: false
      volumeMode: Block 
1

      devicePaths:
        - /path/to/device 
2
Copy to Clipboard Toggle word wrap

1
この PV が生のブロックボリュームであることを示すには、volumeModeBlock に設定します。
2
この値を、LocalVolume リソース by-id へのファイルパスに置き換えます。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。OpenShift sandboxed containers をデプロイするときに、ブロックデバイスを使用するノードにラベルを付ける場合にも、このパスを使用する必要があります。

1.8. FIPS コンプライアンス

OpenShift Container Platform は、Federal Information Processing Standards (FIPS) 140-2 および 140-3 向けに設計されています。FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

NIST の検証プログラムの詳細は、Cryptographic Module Validation Program を参照してください。検証のために提出された RHEL 暗号化ライブラリーの個別バージョンの最新の NIST ステータスは、コンプライアンスアクティビティーおよび政府標準 を参照してください。

OpenShift sandboxed containers は、FIPS 対応クラスターで使用できます。

FIPS モードで実行している場合、OpenShift sandboxed containers コンポーネント、仮想マシン、および VM イメージは、FIPS に準拠するように調整されます。

注記

OpenShift sandboxed containers の FIPS コンプライアンスは、kata ランタイムクラスにのみ適用されます。ピア Pod ランタイムクラス kata-remote はまだ完全にはサポートされておらず、FIPS 準拠のテストも行われていません。

FIPS コンプライアンスは、安全な環境で必要とされる最も重要なコンポーネントの 1 つであり、サポートされている暗号化技術のみがノード上で許可されるようにします。

重要

FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64 アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。

OpenShift Container Platform コンプライアンスフレームワークに関する Red Hat のアプローチは、OpenShift セキュリティーガイド のリスク管理および規制対応の章を参照してください。

1.9. ピア Pod のリソース要件

クラスターに十分なリソースがあることを確認する。

ピア Pod 仮想マシン (VM) には、次の 2 つの場所にリソースが必要です。

  • ワーカーノード。ワーカーノードは、メタデータ、Kata shim リソース (containerd-shim-kata-v2)、リモートハイパーバイザーリソース (cloud-api-adaptor)、およびワーカーノードとピア Pod VM 間のトンネル設定を保存します。
  • クラウドインスタンス。これは、クラウド内で実行されている実際のピア Pod VM です。

Kubernetes ワーカーノードで使用される CPU およびメモリーリソースは、ピア Pod の作成に使用される RuntimeClass (kata-remote) 定義に含まれる Pod オーバーヘッド によって処理されます。

クラウド内で実行されているピア Pod VM の合計数は、Kubernetes ノード拡張リソースとして定義されます。この制限はノードごとに設定され、peer-pods-cm config map の PEERPODS_LIMIT_PER_NODE 属性によって設定されます。

拡張リソースの名前は kata.peerpods.io/vm で、Kubernetes スケジューラーが容量の追跡とアカウンティングを処理できるようにします。

OpenShift sandboxed containers Operator のインストール後に、環境の要件に基づいてノードごとの制限を編集できます。

mutating Webhook により、拡張リソース kata.peerpods.io/vm が Pod 仕様に追加されます。また、リソース固有のエントリーが存在する場合は、Pod 仕様から削除されます。こうすることで、Kubernetes スケジューラーがこれらの拡張リソースを考慮できるようになり、リソースが利用可能な場合にのみピア Pod がスケジュールされるようになります。

mutating Webhook は、次のように Kubernetes Pod を変更します。

  • mutating Webhook は、TARGET_RUNTIME_CLASS 環境変数で指定された RuntimeClassName の想定値であるか、Pod をチェックします。Pod 仕様の値が TARGET_RUNTIME_CLASS の値と一致しない場合、Webhook は Pod を変更せずに終了します。
  • RuntimeClassName の値が一致する場合、Webhook は Pod 仕様に次の変更を加えます。

    1. この Webhook は、Pod 内のすべてのコンテナーおよび初期化コンテナーの resources フィールドからすべてのリソース仕様を削除します。
    2. Webhook は、Pod 内の最初のコンテナーのリソースフィールドを変更して、拡張リソース (kata.peerpods.io/vm) を仕様に追加します。拡張リソース kata.peerpods.io/vm は Kubernetes スケジューラーによってアカウンティング目的で使用されます。
注記

mutating Webhook は、OpenShift Container Platform の特定のシステム namespace が変更されないように除外します。これらのシステム namespace でピア Pod が作成された場合、Pod の仕様に拡張リソースが含まれていない限り、Kubernetes 拡張リソースを使用したリソースアカウンティングは機能しません。

ベストプラクティスとして、特定の namespace でのみピア Pod の作成を許可するクラスター全体のポリシーを定義します。

第2章 OpenShift sandboxed containers のベアメタルへのデプロイ

OpenShift sandboxed containers はベアメタル上にデプロイできます。

OpenShift sandboxed containers をデプロイするには、次のステップを実行します。

  1. OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールします。
  2. オプション: ローカルブロックストレージデバイスを設定するには、Local Storage Operator をインストールします。
  3. オプション: ノード適格性チェックを設定するには、Node Feature Discovery (NFD) Operator をインストールします。
  4. KataConfig カスタムリソースを作成します。
  5. オプション: 各ワーカーノードで実行する仮想マシンの数を変更します。
  6. オプション: Pod のオーバーヘッドを変更します。
  7. OpenShift sandboxed containers のワークロードを設定します。

2.1. 前提条件

  • Red Hat OpenShift Container Platform 4.16 以降がインストールされている。
  • OpenShift Container Platform クラスターに少なくとも 1 つのワーカーノードがある。

2.2. OpenShift sandboxed containers Operator のインストール

OpenShift sandboxed containers Operator は、コマンドラインインターフェイス (CLI) を使用してインストールします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して namespace を作成します。

    $ oc apply -f osc-namespace.yaml
    Copy to Clipboard Toggle word wrap
  3. osc-operatorgroup.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Operator グループを作成します。

    $ oc apply -f osc-operatorgroup.yaml
    Copy to Clipboard Toggle word wrap
  5. osc-subscription.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.10.1
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    $ oc apply -f osc-subscription.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    $ watch oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.10.1    1.9.0        Succeeded
    Copy to Clipboard Toggle word wrap

2.3. 任意の設定

OpenShift sandboxed containers Operator をインストールした後に、次のオプションを設定できます。

2.3.1. ローカルブロックボリュームのプロビジョニング

OpenShift sandboxed containers でローカルブロックボリュームを使用できます。まず、Local Storage Operator (LSO) を使用してローカルブロックボリュームをプロビジョニングする必要があります。次に、ローカルブロックボリュームを持つノードを有効にして、OpenShift sandboxed containers ワークロードを実行する必要があります。

Local Storage Operator (LSO) を使用して、OpenShift sandboxed containers のローカルブロックボリュームをプロビジョニングできます。ローカルボリュームプロビジョナーは、定義されたリソースで指定されたパスにあるブロックボリュームデバイスを検索します。

前提条件

  • Local Storage Operator がインストールされている。
  • 以下の条件を満たすローカルディスクがある。

    • ノードに接続されている。
    • マウントされていない。
    • パーティションが含まれていない。

手順

  1. ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

    注記

    同じデバイスに別のストレージクラス名を使用しないでください。こうすることで、複数の永続ボリューム (PV) が作成されます。

    例: ブロック

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 
    1
    
    spec:
      nodeSelector: 
    2
    
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-136-143
              - ip-10-0-140-255
              - ip-10-0-144-180
      storageClassDevices:
        - storageClassName: "local-sc" 
    3
    
          forceWipeDevicesAndDestroyAllData: false 
    4
    
          volumeMode: Block
          devicePaths: 
    5
    
            - /path/to/device 
    6
    Copy to Clipboard Toggle word wrap

    1
    ローカルストレージ Operator がインストールされている namespace。
    2
    オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。
    3
    永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。
    4
    この設定は、パーティションテーブルの署名 (マジックストリング) を削除してディスクを Local Storage Operator プロビジョニングに使用できるようにする wipefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。
    5
    選択するローカルストレージデバイスの一覧を含むパスです。ローカルブロックデバイスを持つノードを有効にして OpenShift sandboxed containers ワークロードを実行する場合は、このパスを使用する必要があります。
    6
    この値を、LocalVolume リソース by-id へのファイルパス (/dev/disk/by-id/wwn など) に置き換えます。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
  2. OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。

    $ oc apply -f <local-volume>.yaml
    Copy to Clipboard Toggle word wrap
  3. プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。

    $ oc get all -n openshift-local-storage
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                          READY   STATUS    RESTARTS   AGE
    pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
    pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
    pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
    pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
    
    NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
    
    NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/local-storage-operator   1/1     1            1           14m
    
    NAME                                                DESIRED   CURRENT   READY   AGE
    replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m
    Copy to Clipboard Toggle word wrap

    デーモンセットプロセスの desired 数と current 数をメモします。desired 数が 0 の場合、これはラベルセレクターが無効であることを示します。

  4. 永続ボリュームが作成されていることを確認します。

    $ oc get pv
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
    local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
    local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m
    Copy to Clipboard Toggle word wrap

重要

LocalVolume オブジェクトを編集しても、破壊的な操作になる可能性があるため、既存の永続ボリュームは変更されません。

2.3.2. ノードがローカルブロックデバイスを使用できるようにする

定義されたボリュームリソースで指定されたパスで OpenShift sandboxed containers ワークロードを実行するように、ローカルブロックデバイスを持つノードを設定できます。

前提条件

  • Local Storage Operator (LSO) を使用してブロックデバイスをプロビジョニングしている

手順

  • 次のコマンドを実行して、ローカルブロックデバイスを持つ各ノードが OpenShift sandboxed containers ワークロードを実行できるようにします。

    $ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
    Copy to Clipboard Toggle word wrap

    /path/to/device は、ローカルストレージリソースを作成するときに定義したパスと同じである必要があります。

    出力例

    system_u:object_r:container_file_t:s0 /host/path/to/device
    Copy to Clipboard Toggle word wrap

2.3.3. NodeFeatureDiscovery カスタムリソースの作成

NodeFeatureDiscovery カスタムリソース (CR) を作成して、Node Feature Discovery (NFD) Operator がチェックする設定パラメーターを定義して、ワーカーノードが OpenShift sandboxed containers をサポートできるかどうかを判断します。

注記

適格であることがわかっている一部のワーカーノードにのみ kata ランタイムをインストールするには、一部のノードに feature.node.kubernetes.io/runtime.kata=true ラベルを適用し、KataConfig CR で checkNodeEligibility: true を設定します。

すべてのワーカーノードに kata ランタイムをインストールするには、KataConfig CR で checkNodeEligibility: false を設定します。

どちらのシナリオでも、NodeFeatureDiscovery CR を作成する必要はありません。ノードが OpenShift sandboxed containers を実行する資格があることが確実な場合にのみ、feature.node.kubernetes.io/runtime.kata=true ラベルを手動で適用する必要があります。

次の手順では、feature.node.kubernetes.io/runtime.kata=true ラベルをすべての適格なノードに適用し、ノードの適格性を確認するように KataConfig リソースを設定します。

前提条件

  • NFD Operator がインストールされている。

手順

  1. 以下の例に従って、nfd.yaml マニフェストファイルを作成します。

    apiVersion: nfd.openshift.io/v1
    kind: NodeFeatureDiscovery
    metadata:
      name: nfd-kata
      namespace: openshift-nfd
    spec:
      workerConfig:
        configData: |
          sources:
            custom:
              - name: "feature.node.kubernetes.io/runtime.kata"
                matchOn:
                  - cpuId: ["SSE4", "VMX"]
                    loadedKMod: ["kvm", "kvm_intel"]
                  - cpuId: ["SSE4", "SVM"]
                    loadedKMod: ["kvm", "kvm_amd"]
    # ...
    Copy to Clipboard Toggle word wrap
  2. NodeFeatureDiscovery CR を作成します。

    $ oc create -f nfd.yaml
    Copy to Clipboard Toggle word wrap

    NodeFeatureDiscovery CR は、feature.node.kubernetes.io/runtime.kata=true ラベルをすべての認定ワーカーノードに適用します。

  1. 次の例に従って、kata-config.yaml マニフェストファイルを作成します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      checkNodeEligibility: true
    Copy to Clipboard Toggle word wrap
  2. KataConfig CR を作成します。

    $ oc create -f kata-config.yaml
    Copy to Clipboard Toggle word wrap

検証

  • クラスター内の適格なノードに正しいラベルが適用されていることを確認します。

    $ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           STATUS                     ROLES    AGE     VERSION
    compute-3.example.com          Ready                      worker   4h38m   v1.25.0
    compute-2.example.com          Ready                      worker   4h35m   v1.25.0
    Copy to Clipboard Toggle word wrap

2.4. KataConfig カスタムリソースの作成

ワーカーノードに kata をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

OpenShift sandboxed containers は、プライマリーランタイムとしてではなく クラスター上のセカンダリーのオプション ランタイムとして kata をインストールします。

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • 多数のワーカーノードを備えた大規模な OpenShift Container Platform デプロイメントである。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

手順

  1. 以下の例に従って example-kataconfig.yaml マニフェストファイルを作成します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      checkNodeEligibility: false 
    1
    
      logLevel: info
    #  kataConfigPoolSelector:
    #    matchLabels:
    #      <label_key>: '<label_value>' 
    2
    Copy to Clipboard Toggle word wrap
    1
    オプション: Node Feature Discovery Operator がインストールされている場合は、`checkNodeEligibility` を true に設定してノードの適格性チェックを実行します。
    2
    オプション: 特定のノードに OpenShift sandboxed containers をインストールするためにノードラベルを適用した場合は、キーと値を指定します。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml
    Copy to Clipboard Toggle word wrap

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

    kata のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
    Copy to Clipboard Toggle word wrap

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

2.5. Pod オーバーヘッドの変更

Pod のオーバーヘッド では、ノード上の Pod が使用するシステムリソースの量を記述します。RuntimeClass カスタムリソースの spec.overhead フィールドを変更して、Pod のオーバーヘッドを変更できます。たとえば、コンテナーに対する設定が QEMU プロセスおよびゲストカーネルデータでメモリー 350Mi 以上を消費する場合に、RuntimeClass のオーバーヘッドをニーズに合わせて変更できます。

ゲストで種類にかかわらず、ファイルシステム I/O を実行すると、ファイルバッファーがゲストカーネルに割り当てられます。ファイルバッファーは、virtiofsd プロセスだけでなく、ホスト上の QEMU プロセスでもマッピングされます。

たとえば、ゲストでファイルバッファーキャッシュ 300Mi を使用すると、QEMU と virtiofsd の両方が、追加で 300Mi を使用するように見えます。ただし、3 つのケースすべてで同じメモリーが使用されています。したがって、合計メモリー使用量は 3 つの異なる場所にマップされた 300Mi のみです。これは、メモリー使用量メトリクスを報告するときに正しく考慮されます。

注記

Red Hat はデフォルト値をサポートします。デフォルトのオーバーヘッド値の変更はサポートされておらず、値を変更すると技術的な問題が発生する可能性があります。

手順

  1. 次のコマンドを実行して、RuntimeClass オブジェクトを取得します。

    $ oc describe runtimeclass kata
    Copy to Clipboard Toggle word wrap
  2. overhead.podFixed.memory および cpu の値を更新し、ファイルを runtimeclass.yaml として保存します。

    kind: RuntimeClass
    apiVersion: node.k8s.io/v1
    metadata:
      name: kata
    overhead:
      podFixed:
        memory: "500Mi"
        cpu: "500m"
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して変更を適用します。

    $ oc apply -f runtimeclass.yaml
    Copy to Clipboard Toggle word wrap

2.6. OpenShift sandboxed containers のワークロードの設定

OpenShift sandboxed containers のワークロードを設定するには、次の Pod テンプレートオブジェクトのランタイムクラスとして kata を設定します。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. 次の例のように、spec.runtimeClassName: kata を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata
    # ...
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

    $ oc apply -f <object.yaml>
    Copy to Clipboard Toggle word wrap

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata の場合、ワークロードは OpenShift sandboxed containers 上で実行されています。

第3章 OpenShift sandboxed containers の AWS へのデプロイ

OpenShift sandboxed containers は、AWS Cloud Computing Services にデプロイできます。

重要

AWS Cloud Computing Services 上の Red Hat OpenShift sandboxed containers は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OpenShift sandboxed containers をデプロイするには、次のステップを実行します。

  1. OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールします。
  2. ピア Pod との内部通信を可能にするためのポートを有効にします。
  3. オプション: カスタムの Pod 仮想マシンイメージを選択した場合は、ピア Pod のプルシークレットを設定する必要があります。
  4. オプション: カスタム Pod 仮想マシンイメージを選択します。
  5. ピア Pod の config map を作成します。
  6. オプション: Kata エージェントポリシーをカスタマイズします。
  7. KataConfig カスタムリソースを作成します。
  8. オプション: 各ワーカーノードで実行する仮想マシンの数を変更します。
  9. OpenShift sandboxed containers のワークロードを設定します。

3.1. 前提条件

  • Red Hat OpenShift Container Platform 4.16 以降がインストールされている。
  • OpenShift Container Platform クラスターに少なくとも 1 つのワーカーノードがある。
  • ワーカーノードと Pod 仮想マシン (VM) に使用するサブネット内の通信用に、ポート 15150 と 9000 が有効になっている。これらのポートにより、ワーカーノードで実行されている Kata shim と Pod 仮想マシンで実行されている Kata エージェント間の通信が可能になります。

3.2. OpenShift sandboxed containers Operator のインストール

OpenShift sandboxed containers Operator は、コマンドラインインターフェイス (CLI) を使用してインストールします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して namespace を作成します。

    $ oc apply -f osc-namespace.yaml
    Copy to Clipboard Toggle word wrap
  3. osc-operatorgroup.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Operator グループを作成します。

    $ oc apply -f osc-operatorgroup.yaml
    Copy to Clipboard Toggle word wrap
  5. osc-subscription.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.10.1
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    $ oc apply -f osc-subscription.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    $ watch oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.10.1    1.9.0        Succeeded
    Copy to Clipboard Toggle word wrap

3.3. AWS のポートの有効化

AWS で実行されるピア Pod との内部通信を許可するには、ポート 15150 および 9000 を有効にする必要があります。

前提条件

  • OpenShift sandboxed containers Operator をインストールしている。
  • AWS コマンドラインツールがインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. OpenShift Container Platform クラスターにログインし、インスタンス ID を取得します。

    $ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \
      -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
    Copy to Clipboard Toggle word wrap
  2. AWS リージョンを取得します。

    $ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
    Copy to Clipboard Toggle word wrap
  3. セキュリティーグループ ID を取得し、配列に保存します。

    $ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
      --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \
      --output text --region $AWS_REGION))
    Copy to Clipboard Toggle word wrap
  4. 各セキュリティーグループ ID について、ピア Pod シムが kata-agent 通信にアクセスできるように承認し、ピア Pod トンネルを設定します。

    $ for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \
      aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION; \
      aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION; \
    done
    Copy to Clipboard Toggle word wrap

これでポートが有効になりました。

3.4. ピア Pod の config map の作成

ピア Pod の config map を作成する必要があります。

前提条件

  • クラスター認証情報に基づくデフォルトの AMI ID を使用していない場合は、Amazon Machine Image (AMI) ID がある。

手順

  1. AWS インスタンスから以下の値を取得します。

    1. インスタンス ID を取得して記録します。

      $ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \
        -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
      Copy to Clipboard Toggle word wrap

      これは、シークレットオブジェクトの他の値を取得するために使用されます。

    2. AWS リージョンを取得して記録します。

      $ AWS_REGION=$(oc get infrastructure/cluster \
        -o jsonpath='{.status.platformStatus.aws.region}') \
        && echo "AWS_REGION: \"$AWS_REGION\""
      Copy to Clipboard Toggle word wrap
    3. AWS サブネット ID を取得して記録します。

      $ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
        --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} \
          --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""
      Copy to Clipboard Toggle word wrap
    4. AWS VPC ID を取得して記録します。

      $ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
        --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} \
          --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""
      Copy to Clipboard Toggle word wrap
    5. AWS セキュリティーグループ ID を取得して記録します。

      $ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
        --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \
        --region  $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") \
          && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""
      Copy to Clipboard Toggle word wrap
  2. 以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: peer-pods-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      CLOUD_PROVIDER: "aws"
      VXLAN_PORT: "9000"
      PROXY_TIMEOUT: "5m"
      PODVM_INSTANCE_TYPE: "t3.medium"
      PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large"
      PODVM_AMI_ID: "<podvm_ami_id>"
      AWS_REGION: "<aws_region>"
      AWS_SUBNET_ID: "<aws_subnet_id>"
      AWS_VPC_ID: "<aws_vpc_id>"
      AWS_SG_IDS: "<aws_sg_ids>"
      TAGS: "key1=value1,key2=value2"
      PEERPODS_LIMIT_PER_NODE: "10"
      ROOT_VOLUME_SIZE: "6"
      DISABLECVM: "true"
    Copy to Clipboard Toggle word wrap
    PODVM_INSTANCE_TYPE
    ワークロードオブジェクトでインスタンスタイプが定義されていない場合に使用される、デフォルトのインスタンスタイプを定義します。
    PODVM_INSTANCE_TYPES
    Pod を作成するためのインスタンスタイプをスペースなしで指定します。必要なメモリーや CPU が少ないワークロードには小さいインスタンスタイプを定義し、大きなワークロードには大きいインスタンスタイプを定義できます。
    PODVM_AMI_ID
    この値は、クラスターの認証情報に基づく AMI ID を使用して、KataConfig CR を実行するときに入力されます。独自の AMI を作成する場合は、正しい AMI ID を指定します。
    TAGS
    Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。
    PEERPODS_LIMIT_PER_NODE
    この値を増やすと、ノード上でより多くのピア Pod を実行できます。デフォルト値は 10 です。
    ROOT_VOLUME_SIZE
    コンテナーイメージが大きい Pod の場合はこの値を増やします。Pod 仮想マシンのルートボリュームのサイズをギガバイト単位で指定します。デフォルトおよび最小サイズは 6 GB です。
  3. 以下のコマンドを実行して config map を作成します。

    $ oc create -f peer-pods-cm.yaml
    Copy to Clipboard Toggle word wrap

3.5. ピア Pod のプルシークレットの設定

プライベートレジストリーから Pod 仮想マシンイメージをプルするには、ピア Pod のプルシークレットを設定する必要があります。

設定したら、プルシークレットをデフォルトのサービスアカウントにリンクするか、ピア Pod のマニフェストでプルシークレットを指定できます。

手順

  1. NS 変数を、ピア Pod をデプロイする namespace に設定します。

    $ NS=<namespace>
    Copy to Clipboard Toggle word wrap
  2. プルシークレットをピア Pod の namespace にコピーします。

    $ oc get secret pull-secret -n openshift-config -o yaml \
      | sed "s/namespace: openshift-config/namespace: ${NS}/" \
      | oc apply -n "${NS}" -f -
    Copy to Clipboard Toggle word wrap

    この例のようにクラスターのプルシークレットを使用することも、カスタムのプルシークレットを使用することもできます。

  3. オプション: プルシークレットをデフォルトのサービスアカウントにリンクします。

    $ oc secrets link default pull-secret --for=pull -n ${NS}
    Copy to Clipboard Toggle word wrap
  4. または、プルシークレットをピア Pod マニフェストに追加します。

    apiVersion: v1
    kind: <Pod>
    spec:
      containers:
      - name: <container_name>
        image: <image_name>
      imagePullSecrets:
      - name: pull-secret
    # ...
    Copy to Clipboard Toggle word wrap

3.6. カスタムピア Pod 仮想マシンイメージの選択

Pod マニフェストにアノテーションを追加することで、ワークロード要件に合わせてカスタマイズされたカスタムピア Pod 仮想マシン (VM) イメージを選択できます。カスタムイメージは、ピア Pod config map で指定されたデフォルトイメージをオーバーライドします。

前提条件

  • お使いのクラウドプロバイダーまたはハイパーバイザーと互換性のあるカスタム Pod 仮想マシンイメージの ID がある。

手順

  1. 次の例に従って、my-pod-manifest.yaml ファイルを作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod-manifest
      annotations:
        io.katacontainers.config.hypervisor.image: "<custom_image_id>"
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <example_container>
        image: registry.access.redhat.com/ubi9/ubi:9.3
        command: ["sleep", "36000"]
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して Pod を作成します。

    $ oc create -f my-pod-manifest.yaml
    Copy to Clipboard Toggle word wrap

3.7. Kata エージェントポリシーのカスタマイズ

Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。

セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーでオーバーライドできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。

  • ポリシーを Pod VM イメージに組み込む。
  • ピア Pod の config map にパッチを適用する。
  • ワークロード Pod YAML にアノテーションを追加する。

実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。

注記

カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。

手順

  1. カスタムポリシーを含む policy.rego ファイルを作成します。次の例は、設定可能なすべての API を示しています。

    package agent_policy
    
    default AddARPNeighborsRequest := true
    default AddSwapRequest := true
    default CloseStdinRequest := true
    default CopyFileRequest := true
    default CreateContainerRequest := true
    default CreateSandboxRequest := true
    default DestroySandboxRequest := true
    default ExecProcessRequest := true
    default GetMetricsRequest := true
    default GetOOMEventRequest := true
    default GuestDetailsRequest := true
    default ListInterfacesRequest := true
    default ListRoutesRequest := true
    default MemHotplugByProbeRequest := true
    default OnlineCPUMemRequest := true
    default PauseContainerRequest := true
    default PullImageRequest := true
    default ReadStreamRequest := true
    default RemoveContainerRequest := true
    default RemoveStaleVirtiofsShareMountsRequest := true
    default ReseedRandomDevRequest := true
    default ResumeContainerRequest := true
    default SetGuestDateTimeRequest := true
    default SetPolicyRequest := true
    default SignalProcessRequest := true
    default StartContainerRequest := true
    default StartTracingRequest := true
    default StatsContainerRequest := true
    default StopTracingRequest := true
    default TtyWinResizeRequest := true
    default UpdateContainerRequest := true
    default UpdateEphemeralMountsRequest := true
    default UpdateInterfaceRequest := true
    default UpdateRoutesRequest := true
    default WaitProcessRequest := true
    default WriteStreamRequest := true
    Copy to Clipboard Toggle word wrap

    デフォルトのポリシーでは、すべての API 呼び出しが許可されます。必要に応じて、true または false の値を調整してポリシーをさらにカスタマイズします。

  2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

    $ base64 -w0 policy.rego
    Copy to Clipboard Toggle word wrap

    yaml ファイルで使用するために出力を保存します。

  3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: <pod_name>
      annotations:
        io.katacontainers.config.agent.policy: <base64_encoded_policy>
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <container_name>
        image: registry.access.redhat.com/ubi9/ubi:latest
        command:
        - sleep
        - "36000"
        securityContext:
          privileged: false
          seccompProfile:
            type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Pod マニフェストを適用します。

    $ oc apply -f my-pod.yaml
    Copy to Clipboard Toggle word wrap

3.8. KataConfig カスタムリソースの作成

ワーカーノードに kata-remote をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

OpenShift sandboxed containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • 多数のワーカーノードを備えた大規模な OpenShift Container Platform デプロイメントである。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

手順

  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
    Copy to Clipboard Toggle word wrap
    1
    オプション: 特定のノードに kata-remote をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例: osc: 'true')。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             HANDLER          AGE
    kata-remote      kata-remote      152m
    Copy to Clipboard Toggle word wrap

3.9. ノードあたりのピア Pod 仮想マシン数の変更

peerpodConfig カスタムリソース (CR) を編集することで、ノードあたりのピア Pod 仮想マシン (VM) 数の制限を変更できます。

手順

  1. 次のコマンドを実行して、現在の制限を確認します。

    $ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      -o jsonpath='{.spec.limit}{"\n"}'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、limit キーの新しい値を指定します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      --type merge --patch '{"spec":{"limit":"<value>"}}'
    Copy to Clipboard Toggle word wrap

3.10. Pod 仮想マシンイメージの検証

kata-remote がクラスターにインストールされると、OpenShift sandboxed containers Operator は、ピア Pod の作成に使用される Pod 仮想マシンイメージを作成します。イメージがクラウドインスタンス上に作成されるため、このプロセスには時間がかかる場合があります。クラウドプロバイダー用に作成した config map を確認し、Pod 仮想マシンイメージが正常に作成されたことを確認できます。

手順

  1. ピア Pod 用に作成した config map を取得します。

    $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
    Copy to Clipboard Toggle word wrap
  2. YAML ファイルの status スタンザを確認します。

    PODVM_AMI_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

  1. 次のコマンドを実行してイベントログを取得します。

    $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ジョブログを取得します。

    $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
    Copy to Clipboard Toggle word wrap

問題を解決できない場合は、Red Hat サポートケースを送信し、両方のログの出力を添付してください。

3.11. OpenShift sandboxed containers のワークロードの設定

OpenShift sandboxed containers のワークロードを設定するには、次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote を設定します。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

YAML ファイルにアノテーションを追加することで、config map で定義したデフォルトのインスタンスタイプを使用してワークロードをデプロイするかどうかを定義できます。

インスタンスタイプを手動で定義しない場合は、使用可能なメモリーに基づいて自動インスタンスタイプを使用するようにアノテーションを追加できます。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap
  2. オプション: 手動で定義したインスタンスタイプを使用するには、次のアノテーションを追加し、config map で定義したインスタンスタイプを指定します。

    apiVersion: v1
    kind: <object>
    metadata:
      annotations:
        io.katacontainers.config.hypervisor.machine_type: <machine_type>
    # ...
    Copy to Clipboard Toggle word wrap
  3. オプション: 自動インスタンスタイプを使用するには、次のアノテーションを追加します。

    apiVersion: v1
    kind: <Pod>
    metadata:
      annotations:
        io.katacontainers.config.hypervisor.default_vcpus: <vcpus>
        io.katacontainers.config.hypervisor.default_memory: <memory>
    # ...
    Copy to Clipboard Toggle word wrap

    ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスタイプで実行されます。

  4. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

    $ oc apply -f <object.yaml>
    Copy to Clipboard Toggle word wrap

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata-remote の場合、ワークロードは OpenShift sandboxed containers 上で実行されています。

第4章 OpenShift sandboxed containers の Azure へのデプロイ

OpenShift sandboxed containers を Microsoft Azure Cloud Computing Services にデプロイできます。

OpenShift sandboxed containers をデプロイするには、次のステップを実行します。

  1. Azure のピア Pod サブネットの送信接続を設定します。
  2. OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールします。
  3. オプション: カスタムの Pod 仮想マシンイメージを選択した場合は、ピア Pod のプルシークレットを設定する必要があります。
  4. オプション: カスタム Pod 仮想マシンイメージを選択します。
  5. ピア Pod の config map を作成します。
  6. オプション: Azure シークレットを作成します。
  7. オプション: Kata エージェントポリシーをカスタマイズします。
  8. KataConfig カスタムリソースを作成します。
  9. オプション: 各ワーカーノードで実行する仮想マシンの数を変更します。
  10. OpenShift sandboxed containers のワークロードを設定します。

4.1. 前提条件

  • Red Hat OpenShift Container Platform 4.16 以降がインストールされている。
  • OpenShift Container Platform クラスターに少なくとも 1 つのワーカーノードがある。
  • ワーカーノードと Pod 仮想マシン (VM) に使用するサブネット内の通信用に、ポート 15150 と 9000 が有効になっている。これらのポートにより、ワーカーノードで実行されている Kata shim と Pod 仮想マシンで実行されている Kata エージェント間の通信が可能になります。

4.2. 送信接続の設定

ピア Pod がパブリックインターネットなどの外部ネットワークと通信できるようにするには、Pod 仮想マシン (VM) サブネットの送信接続を設定する必要があります。これには、NAT ゲートウェイの設定と、オプションでサブネットを Azure のクラスターの仮想ネットワーク (VNet) と統合する方法の定義が含まれます。

ピア Pod とサブネット
ピア Pod は、送信アクセス用に明示的な設定を必要とする専用の Azure サブネットで動作します。このサブネットは、OpenShift Container Platform ノードによって使用されるデフォルトのワーカーサブネット、またはピア Pod 専用に作成された別のカスタムサブネットのいずれかになります。
VNet ピアリング
別のサブネットを使用する場合、VNet ピアリングはピア Pod VNet をクラスターの VNet に接続し、分離を維持しながら内部通信を確保します。これには、CIDR 範囲が VNet 間で重複しないようにする必要があります。

送信接続は次の 2 つの方法で設定できます。

  • デフォルトのワーカーサブネット: 既存のワーカーサブネットを変更して、NAT ゲートウェイを含めます。これはより単純で、クラスターリソースを再利用しますが、分離性は低くなります。
  • ピア Pod VNet: ピア Pod 専用の VNet とサブネットを設定し、NAT ゲートウェイを接続して、クラスター VNet とピアリングします。これにより、複雑さは増しますが、分離性と柔軟性が向上します。

4.2.1. 送信接続用のデフォルトのワーカーサブネットの設定

デフォルトのワーカーサブネットを NAT ゲートウェイで設定できます。

前提条件

  • Azure CLI (az) がインストールされ、認証されている。
  • Azure リソースグループと VNet への管理者アクセス権がある。

手順

  1. 次のコマンドを実行して、AZURE_RESOURCE_GROUP 環境変数を設定します。

    $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \
        -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、AZURE_REGION 環境変数を設定します。

    $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP}\
        --query "{Location:location}" --output tsv) && \
        echo "AZURE_REGION: \"$AZURE_REGION\""
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、AZURE_VNET_NAME 環境変数を設定します。

    $ AZURE_VNET_NAME=$(az network vnet list \
        -g "${AZURE_RESOURCE_GROUP}" --query '[].name' -o tsv)
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、AZURE_SUBNET_ID 環境変数を設定します。

    $ AZURE_SUBNET_ID=$(az network vnet subnet list \
        --resource-group "${AZURE_RESOURCE_GROUP}" \
        --vnet-name "${AZURE_VNET_NAME}" --query "[].{Id:id} \
        | [? contains(Id, 'worker')]" --output tsv)
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、ピア Pod サブネットの NAT ゲートウェイ環境変数を設定します。

    $ export PEERPOD_NAT_GW=peerpod-nat-gw
    Copy to Clipboard Toggle word wrap
    $ export PEERPOD_NAT_GW_IP=peerpod-nat-gw-ip
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、NAT ゲートウェイのパブリック IP アドレスを作成します。

    $ az network public-ip create -g "${AZURE_RESOURCE_GROUP}" \
        -n "${PEERPOD_NAT_GW_IP}" -l "${AZURE_REGION}" --sku Standard
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、NAT ゲートウェイを作成し、パブリック IP アドレスに関連付けます。

    $ az network nat gateway create -g "${AZURE_RESOURCE_GROUP}" \
        -l "${AZURE_REGION}" --public-ip-addresses "${PEERPOD_NAT_GW_IP}" \
        -n "${PEERPOD_NAT_GW}"
    Copy to Clipboard Toggle word wrap
  8. 以下のコマンドを実行して、NAT ゲートウェイを使用するように VNet サブネットを更新します。

    $ az network vnet subnet update --nat-gateway "${PEERPOD_NAT_GW}" \
        --ids "${AZURE_SUBNET_ID}"
    Copy to Clipboard Toggle word wrap

検証

  • 以下のコマンドを実行して、NAT ゲートウェイが VNet サブネットに割り当てられていることを確認します。

    $ az network vnet subnet show --ids "${AZURE_SUBNET_ID}" \
        --query "natGateway.id" -o tsv
    Copy to Clipboard Toggle word wrap

    出力には NAT ゲートウェイリソース ID が含まれます。NAT ゲートウェイが接続されていない場合、出力は空になります。

    出力例

    /subscriptions/12345678-1234-1234-1234-1234567890ab/resourceGroups/myResourceGroup/providers/Microsoft.Network/natGateways/myNatGateway
    Copy to Clipboard Toggle word wrap

4.2.2. 送信接続用のピア Pod VNet の作成

パブリックインターネットアクセスを有効にするには、ピア Pod 専用の仮想ネットワーク (VNet) を作成して、ネットワークアドレス変換 (NAT) ゲートウェイの接続およびサブネットの作成を行い、重複しないアドレス空間で VNet ピアリングを有効にします。

前提条件

  • Azure CLI (az) がインストールされている、
  • Azure にサインインしている。Azure CLI を使用した Azure の認証 を参照してください。
  • クラスターをホストする Azure リソースグループおよび VNet への管理者アクセスがある。
  • クラスターの VNet classless inter-domain routing (CIDR) アドレスを検証した。デフォルト値は 10.0.0.0/14 です。デフォルト値をオーバーライドした場合は、CIDR アドレスがピア Pod の VNet と重複していないことを確認してください。たとえば、192.168.0.0/16 です。

手順

  1. ピア Pod ネットワークの環境変数を設定します。

    1. 次のコマンドを実行して、ピア Pod VNet 環境変数を設定します。

      $ export PEERPOD_VNET_NAME="${PEERPOD_VNET_NAME:-peerpod-vnet}"
      Copy to Clipboard Toggle word wrap
      $ export PEERPOD_VNET_CIDR="${PEERPOD_VNET_CIDR:-192.168.0.0/16}"
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、ピア Pod サブネット環境変数を設定します。

      $ export PEERPOD_SUBNET_NAME="${PEERPOD_SUBNET_NAME:-peerpod-subnet}"
      Copy to Clipboard Toggle word wrap
      $ export PEERPOD_SUBNET_CIDR="${PEERPOD_SUBNET_CIDR:-192.168.0.0/16}"
      Copy to Clipboard Toggle word wrap
  2. Azure の環境変数を設定します。

    $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \
        -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
    Copy to Clipboard Toggle word wrap
    $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP}\
        --query "{Location:location}" --output tsv) && \
        echo "AZURE_REGION: \"$AZURE_REGION\""
    Copy to Clipboard Toggle word wrap
    $ AZURE_VNET_NAME=$(az network vnet list \
        -g "${AZURE_RESOURCE_GROUP}" --query '[].name' -o tsv)
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、ピア Pod の NAT ゲートウェイ環境変数を設定します。

    $ export PEERPOD_NAT_GW="${PEERPOD_NAT_GW:-peerpod-nat-gw}"
    Copy to Clipboard Toggle word wrap
    $ export PEERPOD_NAT_GW_IP="${PEERPOD_NAT_PUBLIC_IP:-peerpod-nat-gw-ip}"
    Copy to Clipboard Toggle word wrap
  4. VNET を設定します。

    1. 次のコマンドを実行して、ピア Pod VNet を作成します。

      $ az network vnet create --resource-group "${AZURE_RESOURCE_GROUP}" \
          --name "${PEERPOD_VNET_NAME}" \
          --address-prefixes "${PEERPOD_VNET_CIDR}"
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、ピア Pod VNet のパブリック IP アドレスを作成します。

      $ az network public-ip create -g "${AZURE_RESOURCE_GROUP}" \
          -n "${PEERPOD_NAT_GW_IP}" -l "${AZURE_REGION}"
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを実行して、ピア Pod VNet の NAT ゲートウェイを作成します。

      $ az network nat gateway create -g "${AZURE_RESOURCE_GROUP}" \
          -l "${AZURE_REGION}" \
          --public-ip-addresses "${PEERPOD_NAT_GW_IP}" \
          -n "${PEERPOD_NAT_GW}"
      Copy to Clipboard Toggle word wrap
    4. 次のコマンドを実行して、ピア Pod VNet にサブネットを作成し、NAT ゲートウェイを接続します。

      $ az network vnet subnet create \
          --resource-group "${AZURE_RESOURCE_GROUP}" \
          --vnet-name "${PEERPOD_VNET_NAME}" \
          --name "${PEERPOD_SUBNET_NAME}" \
          --address-prefixes "${PEERPOD_SUBNET_CIDR}" \
          --nat-gateway "${PEERPOD_NAT_GW}"
      Copy to Clipboard Toggle word wrap
  5. 仮想ネットワークピアリング接続を設定します。

    1. 次のコマンドを実行してピアリング接続を作成します。

      $ az network vnet peering create -g "${AZURE_RESOURCE_GROUP}" \
          -n peerpod-azure-vnet-to-peerpod-vnet \
          --vnet-name "${AZURE_VNET_NAME}" \
          --remote-vnet "${PEERPOD_VNET_NAME}" --allow-vnet-access \
          --allow-forwarded-traffic
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行してピアリング接続を同期します。

      $ az network vnet peering sync -g "${AZURE_RESOURCE_GROUP}" \
          -n peerpod-azure-vnet-to-peerpod-vnet \
          --vnet-name "${AZURE_VNET_NAME}"
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを実行してピアリング接続を完了します。

      $ az network vnet peering create -g "${AZURE_RESOURCE_GROUP}" \
          -n peerpod-peerpod-vnet-to-azure-vnet \
          --vnet-name "${PEERPOD_VNET_NAME}" \
          --remote-vnet "${AZURE_VNET_NAME}" --allow-vnet-access \
          --allow-forwarded-traffic
      Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、クラスター VNet からのピアリング接続ステータスを確認します。

    $ az network vnet peering show -g "${AZURE_RESOURCE_GROUP}" \
        -n peerpod-azure-vnet-to-peerpod-vnet \
        --vnet-name "${AZURE_VNET_NAME}" \
        --query "peeringState" -o tsv
    Copy to Clipboard Toggle word wrap

    これにより、Connected が返されるはずです。

  2. 次のコマンドを実行して、NAT ゲートウェイがピア Pod サブネットに接続されていることを確認します。

    $ az network vnet subnet show --resource-group "${AZURE_RESOURCE_GROUP}" \
        --vnet-name "${PEERPOD_VNET_NAME}" --name "${PEERPOD_SUBNET_NAME}" \
        --query "natGateway.id" -o tsv
    Copy to Clipboard Toggle word wrap

4.3. OpenShift sandboxed containers Operator のインストール

OpenShift sandboxed containers Operator は、コマンドラインインターフェイス (CLI) を使用してインストールします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して namespace を作成します。

    $ oc apply -f osc-namespace.yaml
    Copy to Clipboard Toggle word wrap
  3. osc-operatorgroup.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Operator グループを作成します。

    $ oc apply -f osc-operatorgroup.yaml
    Copy to Clipboard Toggle word wrap
  5. osc-subscription.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.10.1
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    $ oc apply -f osc-subscription.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    $ watch oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.10.1    1.9.0        Succeeded
    Copy to Clipboard Toggle word wrap

4.4. ピア Pod の config map の作成

ピア Pod の config map を作成する必要があります。

手順

  1. Azure インスタンスから以下の値を取得します。

    1. Azure リソースグループを取得して記録します。

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \
        -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') \
        && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
      Copy to Clipboard Toggle word wrap
    2. Azure VNet 名を取得し、記録します。

      $ AZURE_VNET_NAME=$(az network vnet list \
        --resource-group ${AZURE_RESOURCE_GROUP} \
        --query "[].{Name:name}" --output tsv)
      Copy to Clipboard Toggle word wrap

      この値は、Azure サブネット ID を取得するために使用されます。

    3. Azure サブネット ID を取得して記録します。

      $ AZURE_SUBNET_ID=$(az network vnet subnet list \
        --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME \
        --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) \
         && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""
      Copy to Clipboard Toggle word wrap
    4. Azure ネットワークセキュリティーグループ (NSG) ID を取得して記録します。

      $ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} \
        --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""
      Copy to Clipboard Toggle word wrap
    5. Azure リージョンを取得して記録します。

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} \
        --query "{Location:location}" --output tsv) \
        && echo "AZURE_REGION: \"$AZURE_REGION\""
      Copy to Clipboard Toggle word wrap
  2. 以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: peer-pods-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      CLOUD_PROVIDER: "azure"
      VXLAN_PORT: "9000"
      PROXY_TIMEOUT: "5m"
      AZURE_INSTANCE_SIZE: "Standard_B2als_v2"
      AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5"
      AZURE_SUBNET_ID: "<azure_subnet_id>"
      AZURE_NSG_ID: "<azure_nsg_id>"
      AZURE_IMAGE_ID: "<azure_image_id>"
      AZURE_REGION: "<azure_region>"
      AZURE_RESOURCE_GROUP: "<azure_resource_group>"
      TAGS: "key1=value1,key2=value2"
      PEERPODS_LIMIT_PER_NODE: "10"
      ROOT_VOLUME_SIZE: "6"
      DISABLECVM: "true"
    Copy to Clipboard Toggle word wrap
    AZURE_INSTANCE_SIZE
    ワークロードオブジェクトでインスタンスサイズが定義されていない場合に使用される、デフォルトのインスタンスサイズを定義します。
    AZURE_INSTANCE_SIZES
    Pod を作成するためのインスタンスサイズをスペースなしで指定します。必要なメモリーや CPU が少ないワークロードには小さいインスタンスサイズを定義し、大きなワークロードには大きいインスタンスサイズを定義できます。
    TAGS
    Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。
    PEERPODS_LIMIT_PER_NODE
    この値を増やすと、ノード上でより多くのピア Pod を実行できます。デフォルト値は 10 です。
    ROOT_VOLUME_SIZE
    コンテナーイメージが大きい Pod の場合はこの値を増やします。Pod 仮想マシンのルートボリュームのサイズをギガバイト単位で指定します。デフォルトおよび最小サイズは 6 GB です。
  3. 以下のコマンドを実行して config map を作成します。

    $ oc create -f peer-pods-cm.yaml
    Copy to Clipboard Toggle word wrap

4.5. ピア Pod のプルシークレットの設定

プライベートレジストリーから Pod 仮想マシンイメージをプルするには、ピア Pod のプルシークレットを設定する必要があります。

設定したら、プルシークレットをデフォルトのサービスアカウントにリンクするか、ピア Pod のマニフェストでプルシークレットを指定できます。

手順

  1. NS 変数を、ピア Pod をデプロイする namespace に設定します。

    $ NS=<namespace>
    Copy to Clipboard Toggle word wrap
  2. プルシークレットをピア Pod の namespace にコピーします。

    $ oc get secret pull-secret -n openshift-config -o yaml \
      | sed "s/namespace: openshift-config/namespace: ${NS}/" \
      | oc apply -n "${NS}" -f -
    Copy to Clipboard Toggle word wrap

    この例のようにクラスターのプルシークレットを使用することも、カスタムのプルシークレットを使用することもできます。

  3. オプション: プルシークレットをデフォルトのサービスアカウントにリンクします。

    $ oc secrets link default pull-secret --for=pull -n ${NS}
    Copy to Clipboard Toggle word wrap
  4. または、プルシークレットをピア Pod マニフェストに追加します。

    apiVersion: v1
    kind: <Pod>
    spec:
      containers:
      - name: <container_name>
        image: <image_name>
      imagePullSecrets:
      - name: pull-secret
    # ...
    Copy to Clipboard Toggle word wrap

4.6. カスタムピア Pod 仮想マシンイメージの選択

Pod マニフェストにアノテーションを追加することで、ワークロード要件に合わせてカスタマイズされたカスタムピア Pod 仮想マシン (VM) イメージを選択できます。カスタムイメージは、ピア Pod config map で指定されたデフォルトイメージをオーバーライドします。

前提条件

  • お使いのクラウドプロバイダーまたはハイパーバイザーと互換性のあるカスタム Pod 仮想マシンイメージの ID がある。

手順

  1. 次の例に従って、my-pod-manifest.yaml ファイルを作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod-manifest
      annotations:
        io.katacontainers.config.hypervisor.image: "<custom_image_id>"
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <example_container>
        image: registry.access.redhat.com/ubi9/ubi:9.3
        command: ["sleep", "36000"]
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して Pod を作成します。

    $ oc create -f my-pod-manifest.yaml
    Copy to Clipboard Toggle word wrap

4.7. Azure シークレットの作成

Azure 仮想マシン (VM) 作成 API に必要な SSH 鍵シークレットを作成する必要があります。Azure では SSH 公開鍵のみが必要です。OpenShift sandboxed containers は仮想マシン内の SSH を無効にするため、鍵は仮想マシン内では効果がありません。

手順

  1. 次のコマンドを実行して、SSH キーペアを生成します。

    $ ssh-keygen -f ./id_rsa -N ""
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して Secret オブジェクトを作成します。

    $ oc create secret generic ssh-key-secret \
      -n openshift-sandboxed-containers-operator \
      --from-file=id_rsa.pub=./id_rsa.pub \
      --from-file=id_rsa=./id_rsa
    Copy to Clipboard Toggle word wrap
  3. 作成した SSH 鍵を削除します。

    $ shred --remove id_rsa.pub id_rsa
    Copy to Clipboard Toggle word wrap

4.8. Kata エージェントポリシーのカスタマイズ

Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。

セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーでオーバーライドできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。

  • ポリシーを Pod VM イメージに組み込む。
  • ピア Pod の config map にパッチを適用する。
  • ワークロード Pod YAML にアノテーションを追加する。

実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。

注記

カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。

手順

  1. カスタムポリシーを含む policy.rego ファイルを作成します。次の例は、設定可能なすべての API を示しています。

    package agent_policy
    
    default AddARPNeighborsRequest := true
    default AddSwapRequest := true
    default CloseStdinRequest := true
    default CopyFileRequest := true
    default CreateContainerRequest := true
    default CreateSandboxRequest := true
    default DestroySandboxRequest := true
    default ExecProcessRequest := true
    default GetMetricsRequest := true
    default GetOOMEventRequest := true
    default GuestDetailsRequest := true
    default ListInterfacesRequest := true
    default ListRoutesRequest := true
    default MemHotplugByProbeRequest := true
    default OnlineCPUMemRequest := true
    default PauseContainerRequest := true
    default PullImageRequest := true
    default ReadStreamRequest := true
    default RemoveContainerRequest := true
    default RemoveStaleVirtiofsShareMountsRequest := true
    default ReseedRandomDevRequest := true
    default ResumeContainerRequest := true
    default SetGuestDateTimeRequest := true
    default SetPolicyRequest := true
    default SignalProcessRequest := true
    default StartContainerRequest := true
    default StartTracingRequest := true
    default StatsContainerRequest := true
    default StopTracingRequest := true
    default TtyWinResizeRequest := true
    default UpdateContainerRequest := true
    default UpdateEphemeralMountsRequest := true
    default UpdateInterfaceRequest := true
    default UpdateRoutesRequest := true
    default WaitProcessRequest := true
    default WriteStreamRequest := true
    Copy to Clipboard Toggle word wrap

    デフォルトのポリシーでは、すべての API 呼び出しが許可されます。必要に応じて、true または false の値を調整してポリシーをさらにカスタマイズします。

  2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

    $ base64 -w0 policy.rego
    Copy to Clipboard Toggle word wrap

    yaml ファイルで使用するために出力を保存します。

  3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: <pod_name>
      annotations:
        io.katacontainers.config.agent.policy: <base64_encoded_policy>
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <container_name>
        image: registry.access.redhat.com/ubi9/ubi:latest
        command:
        - sleep
        - "36000"
        securityContext:
          privileged: false
          seccompProfile:
            type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Pod マニフェストを適用します。

    $ oc apply -f my-pod.yaml
    Copy to Clipboard Toggle word wrap

4.9. KataConfig カスタムリソースの作成

ワーカーノードに kata-remote をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

OpenShift sandboxed containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • 多数のワーカーノードを備えた大規模な OpenShift Container Platform デプロイメントである。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

手順

  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
    Copy to Clipboard Toggle word wrap
    1
    オプション: 特定のノードに kata-remote をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例: osc: 'true')。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             HANDLER          AGE
    kata-remote      kata-remote      152m
    Copy to Clipboard Toggle word wrap

4.10. ノードあたりのピア Pod 仮想マシン数の変更

peerpodConfig カスタムリソース (CR) を編集することで、ノードあたりのピア Pod 仮想マシン (VM) 数の制限を変更できます。

手順

  1. 次のコマンドを実行して、現在の制限を確認します。

    $ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      -o jsonpath='{.spec.limit}{"\n"}'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、limit キーの新しい値を指定します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      --type merge --patch '{"spec":{"limit":"<value>"}}'
    Copy to Clipboard Toggle word wrap

4.11. Pod 仮想マシンイメージの検証

kata-remote がクラスターにインストールされると、OpenShift sandboxed containers Operator は、ピア Pod の作成に使用される Pod 仮想マシンイメージを作成します。イメージがクラウドインスタンス上に作成されるため、このプロセスには時間がかかる場合があります。クラウドプロバイダー用に作成した config map を確認し、Pod 仮想マシンイメージが正常に作成されたことを確認できます。

手順

  1. ピア Pod 用に作成した config map を取得します。

    $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
    Copy to Clipboard Toggle word wrap
  2. YAML ファイルの status スタンザを確認します。

    AZURE_IMAGE_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

  1. 次のコマンドを実行してイベントログを取得します。

    $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ジョブログを取得します。

    $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
    Copy to Clipboard Toggle word wrap

問題を解決できない場合は、Red Hat サポートケースを送信し、両方のログの出力を添付してください。

4.12. OpenShift sandboxed containers のワークロードの設定

OpenShift sandboxed containers のワークロードを設定するには、次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote を設定します。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

YAML ファイルにアノテーションを追加することで、config map で定義したデフォルトのインスタンスサイズを使用してワークロードをデプロイするかどうかを定義できます。

インスタンスサイズを手動で定義しない場合は、使用可能なメモリーに基づいて自動インスタンスサイズを使用するようにアノテーションを追加できます。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap
  2. オプション: 手動で定義したインスタンスサイズを使用するには、次のアノテーションを追加し、config map で定義したインスタンスサイズを指定します。

    apiVersion: v1
    kind: <object>
    metadata:
      annotations:
        io.katacontainers.config.hypervisor.machine_type: <machine_type>
    # ...
    Copy to Clipboard Toggle word wrap
  3. オプション: 自動インスタンスサイズを使用するには、次のアノテーションを追加します。

    apiVersion: v1
    kind: <Pod>
    metadata:
      annotations:
        io.katacontainers.config.hypervisor.default_vcpus: <vcpus>
        io.katacontainers.config.hypervisor.default_memory: <memory>
    # ...
    Copy to Clipboard Toggle word wrap

    ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスサイズで実行されます。

  4. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

    $ oc apply -f <object.yaml>
    Copy to Clipboard Toggle word wrap

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata-remote の場合、ワークロードは OpenShift sandboxed containers 上で実行されています。

第5章 Google Cloud への OpenShift sandboxed containers のデプロイ

OpenShift sandboxed containers を Google Cloud にデプロイできます。

重要

Google Cloud 上の Red Hat OpenShift sandboxed containers は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OpenShift sandboxed containers をデプロイするには、次のステップを実行します。

  1. OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールします。
  2. ピア Pod との内部通信を可能にするためのポートを有効にします。
  3. ピア Pod の config map を作成します。
  4. Pod 仮想マシンイメージ config map を作成します。
  5. オプション: Kata エージェントポリシーをカスタマイズします。
  6. KataConfig カスタムリソースを作成します。
  7. オプション: 各ワーカーノードで実行する仮想マシンの数を変更します。
  8. OpenShift sandboxed containers のワークロードを設定します。

5.1. 前提条件

  • Red Hat OpenShift Container Platform 4.17 以降がインストールされている。
  • OpenShift Container Platform クラスターに少なくとも 1 つのワーカーノードがある。
  • ワーカーノードと Pod 仮想マシン (VM) に使用するサブネット内の通信用に、ポート 15150 と 9000 が有効になっている。これらのポートにより、ワーカーノードで実行されている Kata shim と Pod 仮想マシンで実行されている Kata エージェント間の通信が可能になります。

5.2. OpenShift sandboxed containers Operator のインストール

OpenShift sandboxed containers Operator は、コマンドラインインターフェイス (CLI) を使用してインストールします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して namespace を作成します。

    $ oc apply -f osc-namespace.yaml
    Copy to Clipboard Toggle word wrap
  3. osc-operatorgroup.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Operator グループを作成します。

    $ oc apply -f osc-operatorgroup.yaml
    Copy to Clipboard Toggle word wrap
  5. osc-subscription.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.10.1
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    $ oc apply -f osc-subscription.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    $ watch oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.10.1    1.9.0        Succeeded
    Copy to Clipboard Toggle word wrap

5.3. Google Cloud のポート 15150 の有効化

Compute Engine で実行されているピア Pod との内部通信を許可するには、ポート 15150 を有効にする必要があります。

前提条件

  • Google Cloud コマンドラインインターフェイス (CLI) ツールがインストールされている。
  • roles/container.admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。

手順

  1. 次のコマンドを実行して、プロジェクト ID 変数を設定します。

    $ export GCP_PROJECT_ID="<project_id>"
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して Google Cloud にログインします。

    $ gcloud auth login
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、Google Cloud プロジェクト ID を設定します。

    $ gcloud config set project ${GCP_PROJECT_ID}
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行してポート 15150 を開きます。

    $ gcloud compute firewall-rules create allow-port-15150-restricted \
       --project=${GCP_PROJECT_ID} \
       --network=default \
       --allow=tcp:15150 \
       --source-ranges=<external_ip_cidr-1>[,<external_ip_cidr-2>,...] 
    1
    Copy to Clipboard Toggle word wrap
    1
    1 つ以上の IP アドレスまたは範囲を CIDR 形式でコンマで区切って指定します。たとえば、203.0.113.5/32,198.51.100.0/24 です。

検証

  • 次のコマンドを実行して、ポート 15150 が開いていることを確認します。

    $ gcloud compute firewall-rule list
    Copy to Clipboard Toggle word wrap

5.4. ピア Pod の config map の作成

ピア Pod の config map を作成する必要があります。

手順

  1. Compute Engine インスタンスにログインして、次の環境変数を設定します。

    1. 次のコマンドを実行してプロジェクト ID を取得します。

      $ GCP_PROJECT_ID=$(gcloud config get-value project)
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行してゾーンを取得します。

      $ GCP_ZONE=$(gcloud config get-value compute/zone)
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを実行して、ネットワーク名のリストを取得します。

      $ gcloud compute networks list --format="value(name)"
      Copy to Clipboard Toggle word wrap
    4. 次のコマンドを実行してネットワークを指定します。

      $ GCP_NETWORK=<network_name>
      Copy to Clipboard Toggle word wrap

      自動モードのネットワークのみがサポートされます。現時点ではカスタムネットワークはサポートされていません。

  2. 以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: peer-pods-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      CLOUD_PROVIDER: "gcp"
      VXLAN_PORT: "9000"
      PROXY_TIMEOUT: "5m"
      GCP_MACHINE_TYPE: "e2-medium"
      GCP_PROJECT_ID: "<project_id>"
      GCP_ZONE: "<gcp_zone>"
      GCP_NETWORK: "<gcp_network>"
      TAGS: "key1=value1,key2=value2"
      PEERPODS_LIMIT_PER_NODE: "10"
      ROOT_VOLUME_SIZE: "6"
      DISABLECVM: "true"
    Copy to Clipboard Toggle word wrap
    GCP_MACHINE_TYPE
    ワークロードオブジェクトでマシンタイプが定義されていない場合に使用される、デフォルトのマシンタイプを定義します。
    TAGS
    Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。
    PEERPODS_LIMIT_PER_NODE
    この値を増やすと、ノード上でより多くのピア Pod を実行できます。デフォルト値は 10 です。
    ROOT_VOLUME_SIZE
    コンテナーイメージが大きい Pod の場合はこの値を増やします。Pod 仮想マシンのルートボリュームのサイズをギガバイト単位で指定します。デフォルトおよび最小サイズは 6 GB です。
  3. 以下のコマンドを実行して config map を作成します。

    $ oc create -f peer-pods-cm.yaml
    Copy to Clipboard Toggle word wrap

5.5. ピア Pod 仮想マシンイメージの作成

QCOW2 ピア Pod 仮想マシン (VM) イメージを作成する必要があります。

前提条件

  • podman がインストールされている。
  • コンテナーレジストリーにアクセスできる。

手順

  1. 次のコマンドを実行して、OpenShift sandboxed containers リポジトリーのクローンを作成します。

    $ git clone https://github.com/openshift/sandboxed-containers-operator.git
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、sandboxed-containers-operator/config/peerpods/podvm/bootc に移動します。

    $ cd sandboxed-containers-operator/config/peerpods/podvm/bootc
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、registry.redhat.io にログインします。

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap

    podman build プロセスはレジストリーでホストされる Containerfile.rhel コンテナーイメージにアクセスする必要があるため、registry.redhat.io にログインする必要があります。

  4. 次のコマンドを実行して、コンテナーレジストリーのイメージパスを設定します。

    $ IMG="<container_registry_url>/<username>/podvm-bootc:latest"
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、Pod 仮想マシン bootc イメージをビルドします。

    $ podman build -t ${IMG} -f Containerfile.rhel .
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、コンテナーレジストリーにログインします。

    $ podman login <container_registry_url>
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、イメージをコンテナーレジストリーにプッシュします。

    $ podman push ${IMG}
    Copy to Clipboard Toggle word wrap

    テストや開発のために、イメージを公開できます。

  8. 次のコマンドを実行して、podvm-bootc イメージを確認します。

    $ podman images
    Copy to Clipboard Toggle word wrap

    出力例

    REPOSITORY                               TAG     IMAGE ID      CREATED         SIZE
    example.com/example_user/podvm-bootc     latest  88ddab975a07  2 seconds ago   1.82 GB
    Copy to Clipboard Toggle word wrap

5.6. ピア Pod 仮想マシンイメージの config map の作成

Pod 仮想マシン (VM) イメージの config map を作成します。

手順

  1. 次の内容を含む podvm-image-cm.yaml マニフェストを作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: podvm-image-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      IMAGE_TYPE: pre-built
      PODVM_IMAGE_URI: <container_registry_url>/<username>/podvm-bootc:latest
      IMAGE_BASE_NAME: "podvm-image"
      IMAGE_VERSION: "0-0-0"
    
      INSTALL_PACKAGES: "no"
      DISABLE_CLOUD_CONFIG: "true"
      UPDATE_PEERPODS_CM: "yes"
      BOOT_FIPS: "no"
    
      BOOTC_BUILD_CONFIG: |
        [[customizations.user]]
        name = "peerpod"
        password = "peerpod"
        groups = ["wheel", "root"]
    
        [[customizations.filesystem]]
        mountpoint = "/"
        minsize = "5 GiB"
    
        [[customizations.filesystem]]
        mountpoint = "/var/kata-containers"
        minsize = "15 GiB"
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して config map を作成します。

    $ oc create -f podvm-image-cm.yaml
    Copy to Clipboard Toggle word wrap

5.7. Kata エージェントポリシーのカスタマイズ

Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。

セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーでオーバーライドできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。

  • ポリシーを Pod VM イメージに組み込む。
  • ピア Pod の config map にパッチを適用する。
  • ワークロード Pod YAML にアノテーションを追加する。

実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。

注記

カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。

手順

  1. カスタムポリシーを含む policy.rego ファイルを作成します。次の例は、設定可能なすべての API を示しています。

    package agent_policy
    
    default AddARPNeighborsRequest := true
    default AddSwapRequest := true
    default CloseStdinRequest := true
    default CopyFileRequest := true
    default CreateContainerRequest := true
    default CreateSandboxRequest := true
    default DestroySandboxRequest := true
    default ExecProcessRequest := true
    default GetMetricsRequest := true
    default GetOOMEventRequest := true
    default GuestDetailsRequest := true
    default ListInterfacesRequest := true
    default ListRoutesRequest := true
    default MemHotplugByProbeRequest := true
    default OnlineCPUMemRequest := true
    default PauseContainerRequest := true
    default PullImageRequest := true
    default ReadStreamRequest := true
    default RemoveContainerRequest := true
    default RemoveStaleVirtiofsShareMountsRequest := true
    default ReseedRandomDevRequest := true
    default ResumeContainerRequest := true
    default SetGuestDateTimeRequest := true
    default SetPolicyRequest := true
    default SignalProcessRequest := true
    default StartContainerRequest := true
    default StartTracingRequest := true
    default StatsContainerRequest := true
    default StopTracingRequest := true
    default TtyWinResizeRequest := true
    default UpdateContainerRequest := true
    default UpdateEphemeralMountsRequest := true
    default UpdateInterfaceRequest := true
    default UpdateRoutesRequest := true
    default WaitProcessRequest := true
    default WriteStreamRequest := true
    Copy to Clipboard Toggle word wrap

    デフォルトのポリシーでは、すべての API 呼び出しが許可されます。必要に応じて、true または false の値を調整してポリシーをさらにカスタマイズします。

  2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

    $ base64 -w0 policy.rego
    Copy to Clipboard Toggle word wrap

    yaml ファイルで使用するために出力を保存します。

  3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: <pod_name>
      annotations:
        io.katacontainers.config.agent.policy: <base64_encoded_policy>
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <container_name>
        image: registry.access.redhat.com/ubi9/ubi:latest
        command:
        - sleep
        - "36000"
        securityContext:
          privileged: false
          seccompProfile:
            type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Pod マニフェストを適用します。

    $ oc apply -f my-pod.yaml
    Copy to Clipboard Toggle word wrap

5.8. KataConfig カスタムリソースの作成

ワーカーノードに kata-remote をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

OpenShift sandboxed containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • 多数のワーカーノードを備えた大規模な OpenShift Container Platform デプロイメントである。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

手順

  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
    Copy to Clipboard Toggle word wrap
    1
    オプション: 特定のノードに kata-remote をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例: osc: 'true')。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             HANDLER          AGE
    kata-remote      kata-remote      152m
    Copy to Clipboard Toggle word wrap

5.9. ノードあたりのピア Pod 仮想マシン数の変更

peerpodConfig カスタムリソース (CR) を編集することで、ノードあたりのピア Pod 仮想マシン (VM) 数の制限を変更できます。

手順

  1. 次のコマンドを実行して、現在の制限を確認します。

    $ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      -o jsonpath='{.spec.limit}{"\n"}'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、limit キーの新しい値を指定します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      --type merge --patch '{"spec":{"limit":"<value>"}}'
    Copy to Clipboard Toggle word wrap

5.10. Pod 仮想マシンイメージの検証

kata-remote がクラスターにインストールされると、OpenShift sandboxed containers Operator は、ピア Pod の作成に使用される Pod 仮想マシンイメージを作成します。イメージがクラウドインスタンス上に作成されるため、このプロセスには時間がかかる場合があります。クラウドプロバイダー用に作成した config map を確認し、Pod 仮想マシンイメージが正常に作成されたことを確認できます。

手順

  1. ピア Pod 用に作成した config map を取得します。

    $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
    Copy to Clipboard Toggle word wrap
  2. YAML ファイルの status スタンザを確認します。

    PODVM_IMAGE_NAME パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

  1. 次のコマンドを実行してイベントログを取得します。

    $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ジョブログを取得します。

    $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
    Copy to Clipboard Toggle word wrap

問題を解決できない場合は、Red Hat サポートケースを送信し、両方のログの出力を添付してください。

5.11. OpenShift sandboxed containers のワークロードの設定

OpenShift sandboxed containers のワークロードを設定するには、次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote を設定します。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

    $ oc apply -f <object.yaml>
    Copy to Clipboard Toggle word wrap

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata-remote の場合、ワークロードは OpenShift sandboxed containers 上で実行されています。

第6章 IBM Z および IBM LinuxONE への OpenShift sandboxed containers のデプロイ

OpenShift sandboxed containers を IBM Z® および IBM® LinuxONE にデプロイできます。

OpenShift sandboxed containers をデプロイするには、次のステップを実行します。

  1. OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールします。
  2. オプション: libvirt ボリュームを設定します。
  3. オプション: カスタムピア Pod 仮想マシンイメージを作成します。
  4. ピア Pod シークレットを作成します。
  5. ピア Pod の config map を作成します。
  6. Pod 仮想マシンイメージ config map を作成します。
  7. KVM ホストシークレットを作成します。
  8. オプション: カスタムピア Pod 仮想マシンイメージを選択します。
  9. オプション: Kata エージェントポリシーをカスタマイズします。
  10. KataConfig カスタムリソースを作成します。
  11. オプション: 各ワーカーノードで実行する仮想マシンの数を変更します。
  12. OpenShift sandboxed containers のワークロードを設定します。
重要

IBM Z® および IBM® LinuxONE 上の OpenShift sandboxed containers は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

6.1. 前提条件

  • Red Hat OpenShift Container Platform 4.16 以降がインストールされている。
  • OpenShift Container Platform クラスターに、3 つのコントロールプレーンノードと 2 つ以上のワーカーノードがある。
  • クラスターノードとピア Pod が、同じ IBM Z® KVM ホストの論理パーティション内にある。
  • クラスターノードとピア Pod が同じサブネットに接続されている。

6.2. OpenShift sandboxed containers Operator のインストール

OpenShift sandboxed containers Operator は、コマンドラインインターフェイス (CLI) を使用してインストールします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して namespace を作成します。

    $ oc apply -f osc-namespace.yaml
    Copy to Clipboard Toggle word wrap
  3. osc-operatorgroup.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Operator グループを作成します。

    $ oc apply -f osc-operatorgroup.yaml
    Copy to Clipboard Toggle word wrap
  5. osc-subscription.yaml マニフェストファイルを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.10.1
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    $ oc apply -f osc-subscription.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    $ watch oc get csv -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.10.1    1.9.0        Succeeded
    Copy to Clipboard Toggle word wrap

6.3. libvirt ボリュームの設定

OpenShift sandboxed containers Operator は、インストール中に KVM ホスト上の libvirt ボリュームとプールを自動的に設定します。必要に応じて、追加の libvirt ボリュームおよびプールを手動で設定または作成できます。

前提条件

  • OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールしている。
  • KVM ホストの管理者権限がある。
  • KVM ホストに podman がインストールされている。
  • KVM ホストに virt-customize がインストールされている。
  • イメージ用の /var/lib/libvirt/images/ ディレクトリーがある。

手順

  1. KVM ホストにログインします。
  2. 次のコマンドを実行して、libvirt プールの名前を設定します。

    $ export LIBVIRT_POOL=<libvirt_pool>
    Copy to Clipboard Toggle word wrap

    libvirt プロバイダーのシークレットを作成するには、LIBVIRT_POOL 値が必要です。

  3. 次のコマンドを実行して、libvirt ボリュームの名前を設定します。

    $ export LIBVIRT_VOL_NAME=<libvirt_volume>
    Copy to Clipboard Toggle word wrap

    libvirt プロバイダーのシークレットを作成するには、LIBVIRT_VOL_NAME 値が必要です。

  4. 次のコマンドを実行して、デフォルトのストレージプールの場所のパスを設定します。

    $ export LIBVIRT_POOL_DIRECTORY="/var/lib/libvirt/images/"
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、libvirt プールを作成します。

    $ virsh pool-define-as $LIBVIRT_POOL --type dir --target "$LIBVIRT_POOL_DIRECTORY"
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、libvirt プールを開始します。

    $ virsh pool-start $LIBVIRT_POOL
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、プールの libvirt ボリュームを作成します。

    $ virsh -c qemu:///system \
      vol-create-as --pool $LIBVIRT_POOL \
      --name $LIBVIRT_VOL_NAME \
      --capacity 20G \
      --allocation 2G \
      --prealloc-metadata \
      --format qcow2
    Copy to Clipboard Toggle word wrap

6.4. カスタムピア Pod 仮想マシンイメージの作成

デフォルトの Operator ビルドイメージを使用する代わりに、カスタムピア Pod 仮想マシン (VM) イメージを作成できます。

ピア Pod QCOW2 イメージを使用して Open Container Initiative (OCI) コンテナーを構築します。後で、コンテナーレジストリー URL とイメージパスをピア Pod 仮想マシンイメージ config map に追加します。

手順

  1. Dockerfile.podvm-oci ファイルを作成します。

    FROM scratch
    
    ARG PODVM_IMAGE_SRC
    ENV PODVM_IMAGE_PATH="/image/podvm.qcow2"
    
    COPY $PODVM_IMAGE_SRC $PODVM_IMAGE_PATH
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Pod 仮想マシン QCOW2 イメージを含むコンテナーを構築します。

    $ docker build -t podvm-libvirt \
      --build-arg PODVM_IMAGE_SRC=<podvm_image_source> \ 
    1
    
      --build-arg PODVM_IMAGE_PATH=<podvm_image_path> \ 
    2
    
      -f Dockerfile.podvm-oci .
    Copy to Clipboard Toggle word wrap
    1
    ホスト上の QCOW2 イメージソースを指定します。
    2
    オプション: デフォルトの /image/podvm.qcow2 を使用しない場合は、QCOW2 イメージのパスを指定します。

6.5. ピア Pod シークレットの作成

ピア Pod シークレットを作成する必要があります。シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するための認証情報が保存されます。

前提条件

  • LIBVIRT_URI。この値は、libvirt ネットワークのデフォルトのゲートウェイ IP アドレスです。この値を取得するには、libvirt ネットワーク設定を確認してください。

    注記

    libvirt がデフォルトのブリッジ仮想ネットワークを使用する場合は、以下のコマンドを実行して LIBVIRT_URI を取得できます。

    $ virtint=$(bridge_line=$(virsh net-info default | grep Bridge);  echo "${bridge_line//Bridge:/}" | tr -d [:blank:])
    
    $ LIBVIRT_URI=$( ip -4 addr show $virtint | grep -oP '(?<=inet\s)\d+(\.\d+){3}')
    
    $ LIBVIRT_GATEWAY_URI="qemu+ssh://root@${LIBVIRT_URI}/system?no_verify=1"
    Copy to Clipboard Toggle word wrap
  • REDHAT_OFFLINE_TOKENRed Hat API トークン で RHEL イメージをダウンロードするためにこのトークンを生成している。

手順

  1. 次の例に従って peer-pods-secret.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      CLOUD_PROVIDER: "libvirt"
      LIBVIRT_URI: "<libvirt_gateway_uri>" 
    1
    
      REDHAT_OFFLINE_TOKEN: "<rh_offline_token>" 
    2
    Copy to Clipboard Toggle word wrap
    1
    libvirt URI を指定します。
    2
    Operator ビルドイメージに必要な Red Hat オフライントークンを指定します。
  2. 以下のコマンドを実行してシークレットを作成します。

    $ oc create -f peer-pods-secret.yaml
    Copy to Clipboard Toggle word wrap

6.6. ピア Pod の config map の作成

ピア Pod の config map を作成する必要があります。

手順

  1. 以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: peer-pods-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      CLOUD_PROVIDER: "libvirt"
      LIBVIRT_POOL: "<libvirt_pool>"
      LIBVIRT_VOL_NAME: "<libvirt_volume>"
      LIBVIRT_DIR_NAME: "/var/lib/libvirt/images/<directory_name>"
      LIBVIRT_NET: "default"
      PEERPODS_LIMIT_PER_NODE: "10"
      ROOT_VOLUME_SIZE: "6"
      DISABLECVM: "true"
    Copy to Clipboard Toggle word wrap
    LIBVIRT_POOL
    libvirt プールを手動で設定した場合は、KVM ホスト設定と同じ名前を使用します。
    LIBVIRT_VOL_NAME
    libvirt ボリュームを手動で設定した場合は、KVM ホスト設定と同じ名前を使用します。
    LIBVIRT_DIR_NAME
    .qcow2.raw ファイルなどの仮想マシンのディスクイメージを保存するための libvirt ディレクトリーを指定します。libvirt に読み取りおよび書き込みアクセス権限があることを確認するには、libvirt ストレージディレクトリーのサブディレクトリーを使用します。デフォルトは /var/lib/libvirt/images/ です。
    LIBVIRT_NET
    デフォルトのネットワークを使用しない場合は、libvirt ネットワークを指定します。
    PEERPODS_LIMIT_PER_NODE
    この値を増やすと、ノード上でより多くのピア Pod を実行できます。デフォルト値は 10 です。
    ROOT_VOLUME_SIZE
    コンテナーイメージが大きい Pod の場合はこの値を増やします。Pod 仮想マシンのルートボリュームのサイズをギガバイト単位で指定します。デフォルトおよび最小サイズは 6 GB です。
  2. 以下のコマンドを実行して config map を作成します。

    $ oc create -f peer-pods-cm.yaml
    Copy to Clipboard Toggle word wrap

6.7. ピア Pod 仮想マシンイメージの config map の作成

ピア Pod 仮想マシン (VM) イメージの config map を作成する必要があります。

前提条件

  • Red Hat Hybrid Cloud Console を使用してアクティベーションキーを作成する。
  • オプション (Cloud API アダプターのカスタムイメージを使用する場合): イメージの名前、URL、ブランチまたはタグ。

手順

  1. 次の例に従って、libvirt-podvm-image-cm.yaml マニフェストを作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: libvirt-podvm-image-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      PODVM_DISTRO: "rhel"
      DOWNLOAD_SOURCES: "no" 
    1
    
      CAA_SRC: "https://github.com/confidential-containers/cloud-api-adaptor" 
    2
    
      CAA_REF: "main" 
    3
    
      CONFIDENTIAL_COMPUTE_ENABLED: "yes"
      UPDATE_PEERPODS_CM: "yes"
      ORG_ID: "<rhel_organization_id>"
      ACTIVATION_KEY: "<rhel_activation_key>" 
    4
    
      PODVM_IMAGE_URI: "oci::<image_repo_url>:<image_tag>::<image_path>" 
    5
    
      SE_BOOT: "true" 
    6
    
      BASE_OS_VERSION: "<rhel_image_os_version>" 
    7
    
      SE_VERIFY: "false" 
    8
    Copy to Clipboard Toggle word wrap
    1
    カスタム Cloud API アダプターソースを使用して Pod 仮想マシンイメージを構築する場合は、yes を指定します。
    2
    オプション: Cloud API アダプターのカスタムイメージの URL を指定します。
    3
    オプション: Cloud API アダプターのカスタムイメージのブランチまたはタグを指定します。
    4
    RHEL アクティベーションキーを指定します。
    5
    オプション: カスタムピア Pod 仮想マシンイメージを作成した場合は、コンテナーレジストリー URL、イメージタグ、およびイメージパス (デフォルト: /image/podvm.qcow2) を指定します。それ以外の場合は、値を "" に設定します。
    6
    デフォルト値 true は、デフォルトの Operator ビルドイメージに対して IBM Secure Execution を有効にします。カスタムピア Pod 仮想マシンイメージを使用する場合は、false に設定します。
    7
    RHEL イメージのオペレーティングシステムのバージョンを指定します。IBM Z® Secure Execution は RHEL 9.5 以降のバージョンをサポートします。
    8
    digicert CA 証明書を使用して Secure Execution を検証しない場合は、false を指定します。デフォルト値は true です。
  2. 以下のコマンドを実行して config map を作成します。

    $ oc apply -f libvirt-podvm-image-cm.yaml
    Copy to Clipboard Toggle word wrap

    libvirt プロバイダー用に libvirt Pod 仮想マシンイメージ config map が作成されます。

6.8. KVM ホストシークレットの作成

KVM ホストのシークレットを作成する必要があります。

手順

  1. 次のコマンドを実行して、SSH キーペアを生成します。

    $ ssh-keygen -f ./id_rsa -N ""
    Copy to Clipboard Toggle word wrap
  2. SSH 公開鍵を KVM ホストにコピーします。

    $ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_IP> 
    1
    Copy to Clipboard Toggle word wrap
    1
    ピア Pod 仮想マシンが実行されている KVM ホストまたは LPAR の IP アドレスを指定します。たとえば、192.168.122.1 です。
  3. 以下のコマンドを実行して Secret オブジェクトを作成します。

    $ oc create secret generic ssh-key-secret \
      -n openshift-sandboxed-containers-operator \
      --from-file=id_rsa.pub=./id_rsa.pub \
      --from-file=id_rsa=./id_rsa
    Copy to Clipboard Toggle word wrap
  4. 作成した SSH 鍵を削除します。

    $ shred --remove id_rsa.pub id_rsa
    Copy to Clipboard Toggle word wrap

6.9. カスタムピア Pod 仮想マシンイメージの選択

Pod マニフェストにアノテーションを追加することで、ワークロード要件に合わせてカスタマイズされたカスタムピア Pod 仮想マシン (VM) イメージを選択できます。カスタムイメージは、ピア Pod config map で指定されたデフォルトイメージをオーバーライドします。

libvirt プールに新しい libvirt ボリュームを作成し、カスタムピア Pod 仮想マシンイメージを新しいボリュームにアップロードします。次に、カスタムピア Pod 仮想マシンイメージを使用するように Pod マニフェストを更新します。

手順

  1. 次のコマンドを実行して LIBVIRT_POOL 変数を設定します。

    $ export LIBVIRT_POOL=<libvirt_pool>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、LIBVIRT_VOL_NAME 変数を新しい libvirt ボリュームに設定します。

    $ export LIBVIRT_VOL_NAME=<new_libvirt_volume>
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、プールの libvirt ボリュームを作成します。

    $ virsh -c qemu:///system \
      vol-create-as --pool $LIBVIRT_POOL \
      --name $LIBVIRT_VOL_NAME \
      --capacity 20G \
      --allocation 2G \
      --prealloc-metadata \
      --format qcow2
    Copy to Clipboard Toggle word wrap
  4. カスタムピア Pod 仮想マシンイメージを新しい libvirt ボリュームにアップロードします。

    $ virsh -c qemu:///system vol-upload \
      --vol $LIBVIRT_VOL_NAME <custom_podvm_image.qcow2> \
      --pool $LIBVIRT_POOL --sparse
    Copy to Clipboard Toggle word wrap
  5. 次の例に従って、my-pod-manifest.yaml ファイルを作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod-manifest
      annotations:
        io.katacontainers.config.hypervisor.image: "<new_libvirt_volume>"
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <example_container>
        image: registry.access.redhat.com/ubi9/ubi:9.3
        command: ["sleep", "36000"]
    Copy to Clipboard Toggle word wrap
  6. 以下のコマンドを実行して Pod を作成します。

    $ oc create -f my-pod-manifest.yaml
    Copy to Clipboard Toggle word wrap

6.10. Kata エージェントポリシーのカスタマイズ

Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。

セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーでオーバーライドできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。

  • ポリシーを Pod VM イメージに組み込む。
  • ピア Pod の config map にパッチを適用する。
  • ワークロード Pod YAML にアノテーションを追加する。

実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。

注記

カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。

手順

  1. カスタムポリシーを含む policy.rego ファイルを作成します。次の例は、設定可能なすべての API を示しています。

    package agent_policy
    
    default AddARPNeighborsRequest := true
    default AddSwapRequest := true
    default CloseStdinRequest := true
    default CopyFileRequest := true
    default CreateContainerRequest := true
    default CreateSandboxRequest := true
    default DestroySandboxRequest := true
    default ExecProcessRequest := true
    default GetMetricsRequest := true
    default GetOOMEventRequest := true
    default GuestDetailsRequest := true
    default ListInterfacesRequest := true
    default ListRoutesRequest := true
    default MemHotplugByProbeRequest := true
    default OnlineCPUMemRequest := true
    default PauseContainerRequest := true
    default PullImageRequest := true
    default ReadStreamRequest := true
    default RemoveContainerRequest := true
    default RemoveStaleVirtiofsShareMountsRequest := true
    default ReseedRandomDevRequest := true
    default ResumeContainerRequest := true
    default SetGuestDateTimeRequest := true
    default SetPolicyRequest := true
    default SignalProcessRequest := true
    default StartContainerRequest := true
    default StartTracingRequest := true
    default StatsContainerRequest := true
    default StopTracingRequest := true
    default TtyWinResizeRequest := true
    default UpdateContainerRequest := true
    default UpdateEphemeralMountsRequest := true
    default UpdateInterfaceRequest := true
    default UpdateRoutesRequest := true
    default WaitProcessRequest := true
    default WriteStreamRequest := true
    Copy to Clipboard Toggle word wrap

    デフォルトのポリシーでは、すべての API 呼び出しが許可されます。必要に応じて、true または false の値を調整してポリシーをさらにカスタマイズします。

  2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

    $ base64 -w0 policy.rego
    Copy to Clipboard Toggle word wrap

    yaml ファイルで使用するために出力を保存します。

  3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: <pod_name>
      annotations:
        io.katacontainers.config.agent.policy: <base64_encoded_policy>
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <container_name>
        image: registry.access.redhat.com/ubi9/ubi:latest
        command:
        - sleep
        - "36000"
        securityContext:
          privileged: false
          seccompProfile:
            type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して Pod マニフェストを適用します。

    $ oc apply -f my-pod.yaml
    Copy to Clipboard Toggle word wrap

6.11. KataConfig カスタムリソースの作成

ワーカーノードに kata-remote をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

OpenShift sandboxed containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • 多数のワーカーノードを備えた大規模な OpenShift Container Platform デプロイメントである。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

手順

  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
    Copy to Clipboard Toggle word wrap
    1
    オプション: 特定のノードに kata-remote をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例: osc: 'true')。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
    Copy to Clipboard Toggle word wrap

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

  4. 次のコマンドを実行して、ピア Pod イメージが構築され、libvirt ボリュームにアップロードされたことを確認します。

    $ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    Name: peer-pods-cm
    Namespace: openshift-sandboxed-containers-operator
    Labels: <none>
    Annotations: <none>
    
    Data
    ====
    CLOUD_PROVIDER: libvirt
    
    BinaryData
    ====
    Events: <none>
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、kata-oc マシン設定プールの進行状況を監視し、UPDATEDMACHINECOUNTMACHINECOUNT と等しいときに UPDATED 状態であることを確認します。

    $ watch oc get mcp/kata-oc
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行してデーモンセットを確認します。

    $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             HANDLER          AGE
    kata-remote      kata-remote      152m
    Copy to Clipboard Toggle word wrap

6.12. ノードあたりのピア Pod 仮想マシン数の変更

peerpodConfig カスタムリソース (CR) を編集することで、ノードあたりのピア Pod 仮想マシン (VM) 数の制限を変更できます。

手順

  1. 次のコマンドを実行して、現在の制限を確認します。

    $ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      -o jsonpath='{.spec.limit}{"\n"}'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、limit キーの新しい値を指定します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
      --type merge --patch '{"spec":{"limit":"<value>"}}'
    Copy to Clipboard Toggle word wrap

6.13. OpenShift sandboxed containers のワークロードの設定

OpenShift sandboxed containers のワークロードを設定するには、次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote を設定します。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

    $ oc apply -f <object.yaml>
    Copy to Clipboard Toggle word wrap

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata-remote の場合、ワークロードは OpenShift sandboxed containers 上で実行されています。

!:ibm-osc:

第7章 モニタリング

OpenShift Container Platform Web コンソールを使用して、サンドボックス化されたワークロードおよびノードのヘルスステータスに関連するメトリクスを監視できます。

OpenShift sandboxed containers には、OpenShift Container Platform Web コンソールで事前に設定されたダッシュボードがあります。管理者は Prometheus を通じて生のメトリクスにアクセスし、クエリーを実行することもできます。

7.1. メトリクスについて

OpenShift sandboxed containers のメトリクスを使用すると、管理者はサンドボックスコンテナーの実行状況を監視できます。OpenShift Container Platform Web コンソールのメトリクス UI でこれらのメトリクスを照会できます。

OpenShift sandboxed containers のメトリクスは、次のカテゴリーについて収集されます。

Kata エージェントのメトリクス
Kata エージェントメトリクスは、サンドボックスコンテナーに埋め込まれた仮想マシンで実行されている kata エージェントプロセスに関する情報を示します。これらのメトリクスには、/proc/<pid>/[io, stat, status] からのデータが含まれます。
Kata ゲストオペレーティングシステムのメトリクス
Kata ゲストオペレーティングシステムのメトリクスは、サンドボックスコンテナーで実行されているゲストオペレーティングシステムのデータを示します。これらのメトリクスには、/proc/[stats, diskstats, meminfo, vmstats] および /proc/net/dev からのデータが含まれます。
ハイパーバイザーのメトリクス
ハイパーバイザーのメトリクスは、サンドボックスコンテナーに埋め込まれた仮想マシンを実行しているハイパーバイザーに関するデータを示します。このメトリクスには、主に /proc/<pid>/[io, stat, status] からのデータが含まれます。
Kata モニターのメトリクス
Kata モニターは、メトリクスデータを収集し、それを Prometheus で利用できるようにするプロセスです。kata モニターのメトリクスは、kata-monitor プロセス自体のリソース使用状況に関する詳細情報を示します。これらのメトリクスには、Prometheus データコレクションからのカウンターも含まれます。
Kata containerd shim v2 メトリクス
Kata containerd shim v2 メトリクスには、kata shim プロセスに関する詳細情報が表示されます。これらのメトリクスには、/proc/<pid>/[io, stat, status] からのデータと詳細なリソース使用メトリクスが含まれます。

7.2. メトリクスの表示

OpenShift Container Platform Web コンソールの Metrics ページから、OpenShift sandboxed containers のメトリクスにアクセスできます。

前提条件

  • cluster-admin ロールまたはすべてのプロジェクトの表示パーミッションを持つユーザーとしてクラスターにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールで、ObserveMetrics に移動します。
  2. 入力フィールドに、監視するメトリクスのクエリーを入力します。以下に例を示します。

    kata 関連のメトリクスはすべて kata で始まります。kata と入力すると、使用可能なすべての kata メトリクスのリストが表示されます。

クエリーのメトリクスがページに視覚化されます。

第8章 OpenShift sandboxed containers のアンインストール

以下のタスクを実行して、OpenShift sandboxed containers をアンインストールします。

  1. ワークロード Pod を削除します。
  2. KataConfig カスタムリソース (CR) を削除します。
  3. OpenShift sandboxed containers Operator をアンインストールします。
  4. KataConfig カスタムリソース定義 (CRD) を削除します。
重要

KataConfig CR を削除する前に、ワークロード Pod を削除する必要があります。Pod 名には通常、接頭辞 podvm と、カスタムタグが指定されている場合はカスタムタグが付きます。クラウドプロバイダーに OpenShift sandboxed containers をデプロイした場合は、上記の手順を実行した後もリソースが残っていると、クラウドプロバイダーからそのリソースに対する予期しない請求を受ける可能性があります。クラウドプロバイダーで OpenShift sandboxed containers のアンインストールが完了したら、クラウドプロバイダーのコンソールをチェックして、この手順ですべてのリソースが削除されたことを確認してください。

8.1. ワークロード Pod の削除

CLI を使用して、OpenShift sandboxed containers のワークロード Pod を削除できます。

前提条件

  • JSON プロセッサー (jq) ユーティリティーがインストールされている。

手順

  1. 次のコマンドを実行して、Pod を検索します。

    $ oc get pods -A -o json | jq -r '.items[] | \
      select(.spec.runtimeClassName == "<runtime>").metadata.name'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、各 Pod を削除します。

    $ oc delete pod <pod>
    Copy to Clipboard Toggle word wrap
重要

クラウドプロバイダーを使用してデプロイされた OpenShift sandboxed containers をアンインストールする場合は、すべての Pod を削除する必要があります。Pod リソースが残っていると、クラウドプロバイダーから予期しない請求が発生する可能性があります。

8.2. KataConfig カスタムリソースの削除

コマンドラインを使用して、KataConfig カスタムリソース (CR) を削除します。

手順

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

    $ oc delete kataconfig example-kataconfig
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、CR が削除されたことを確認します。

    $ oc get kataconfig example-kataconfig
    Copy to Clipboard Toggle word wrap

    出力例

    No example-kataconfig instances exist
    Copy to Clipboard Toggle word wrap

重要

すべての Pod が削除されていることを確認する必要があります。Pod リソースが残っていると、クラウドプロバイダーから予期しない請求が発生する可能性があります。

8.3. OpenShift sandboxed containers Operator のアンインストール

コマンドラインを使用して、OpenShift sandboxed containers Operator をアンインストールします。

手順

  1. 次のコマンドを実行して、サブスクリプションを削除します。

    $ oc delete subscription sandboxed-containers-operator -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して namespace を削除します。

    $ oc delete namespace openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

8.4. KataConfig CRD の削除

コマンドラインを使用して、KataConfig カスタムリソース定義 (CRD) を削除します。

前提条件

  • KataConfig カスタムリソースが削除されている。
  • OpenShift sandboxed containers Operator がアンインストールされている。

手順

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

    $ oc delete crd kataconfigs.kataconfiguration.openshift.io
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、CRD が削除されたことを確認します。

    $ oc get crd kataconfigs.kataconfiguration.openshift.io
    Copy to Clipboard Toggle word wrap

    出力例

    Unknown CRD kataconfigs.kataconfiguration.openshift.io
    Copy to Clipboard Toggle word wrap

第9章 アップグレード

OpenShift sandboxed containers コンポーネントのアップグレードは、次の手順で構成されます。

  1. OpenShift Container Platform をアップグレードして、Kata ランタイムとその依存関係を更新します。
  2. OpenShift sandboxed containers Operator をアップグレードして、Operator サブスクリプションを更新します。

以下に示す 1 つの例外を除いて、OpenShift sandboxed containers Operator のアップグレードの前または後に OpenShift Container Platform をアップグレードできます。OpenShift sandboxed containers Operator をアップグレードした直後に、常に KataConfig パッチを適用します。

9.1. リソースのアップグレード

Red Hat Enterprise Linux CoreOS (RHCOS) 拡張機能は、OpenShift sandboxed containers リソースをクラスターにデプロイします。

RHCOS 拡張機能の sandboxed containers には、Kata containers ランタイム、ハイパーバイザーの QEMU、その他の依存関係など、OpenShift sandboxed containers を実行するために必要なコンポーネントが含まれています。クラスターを OpenShift Container Platform の新しいリリースにアップグレードすることで、拡張機能をアップグレードします。

OpenShift Container Platform のアップグレードの詳細は、クラスターの更新 を参照してください。

9.2. Operator のアップグレード

Operator Lifecycle Manager (OLM) を使用して、OpenShift sandboxed containers Operator を手動で設定するか、自動的にアップグレードできます。初期導入時に手動アップグレードか自動アップグレードかを選択することで、将来のアップグレードモードが決まります。手動アップグレードの場合、OpenShift Container Platform Web コンソールに、クラスター管理者がインストールできる利用可能な更新が表示されます。

Operator Lifecycle Manager (OLM) での OpenShift sandboxed containers Operator のアップグレードに関する詳細は、インストール済み Operator の更新 を参照してください。

9.3. Pod 仮想マシンイメージの更新

ピア Pod のデプロイメントの場合、Pod 仮想マシンイメージを更新する必要があります。enablePeerpods: の値が true の場合に OpenShift sandboxed containers Operator をアップグレードしても、Pod 仮想マシンイメージは自動的に更新されません。KataConfig カスタムリソース (CR) を削除して再作成する必要もあります。

注記

AWS および Azure デプロイメントのピア Pod config map を確認して、KataConfig CR を再作成する前にイメージ ID が空であることを確認することもできます。

9.3.1. KataConfig カスタムリソースの削除

コマンドラインを使用して、KataConfig カスタムリソース (CR) を削除します。

手順

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

    $ oc delete kataconfig example-kataconfig
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、CR が削除されたことを確認します。

    $ oc get kataconfig example-kataconfig
    Copy to Clipboard Toggle word wrap

    出力例

    No example-kataconfig instances exist
    Copy to Clipboard Toggle word wrap

重要

すべての Pod が削除されていることを確認する必要があります。Pod リソースが残っていると、クラウドプロバイダーから予期しない請求が発生する可能性があります。

9.3.2. イメージ ID が空であることを確認する

AWS および Azure デプロイメントの場合、KataConfig カスタムリソース (CR) を削除した後、ピア Pod config map 内のイメージ ID が空であることを確認する必要があります。

手順

  1. 次のコマンドを実行して、ピア Pod config map を取得します。

    $ oc get configmap -n openshift-sandboxed-containers-operator peer-pods-cm -o jsonpath="{.data.<image_id>}" 
    1
    Copy to Clipboard Toggle word wrap
    1
    AWS の場合、<image_id>PODVM_AMI_ID に置き換えます。Azure の場合、<image_id>AZURE_IMAGE_ID に置き換えます。
  2. 値が空でない場合は、次のコマンドを実行して値を更新し、config map にパッチを適用します。

    $ oc patch configmap peer-pods-cm -n openshift-sandboxed-containers-operator -p '{"data":{"<image_id>":""}}'
    Copy to Clipboard Toggle word wrap

9.3.3. KataConfig カスタムリソースの作成

ワーカーノードに kata-remote をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

OpenShift sandboxed containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • 多数のワーカーノードを備えた大規模な OpenShift Container Platform デプロイメントである。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

手順

  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
    Copy to Clipboard Toggle word wrap
    1
    オプション: 特定のノードに kata-remote をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例: osc: 'true')。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
    Copy to Clipboard Toggle word wrap

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

  4. 次のコマンドを実行して、ピア Pod イメージが構築され、libvirt ボリュームにアップロードされたことを確認します。

    $ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap

    出力例

    Name: peer-pods-cm
    Namespace: openshift-sandboxed-containers-operator
    Labels: <none>
    Annotations: <none>
    
    Data
    ====
    CLOUD_PROVIDER: libvirt
    
    BinaryData
    ====
    Events: <none>
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、kata-oc マシン設定プールの進行状況を監視し、UPDATEDMACHINECOUNTMACHINECOUNT と等しいときに UPDATED 状態であることを確認します。

    $ watch oc get mcp/kata-oc
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行してデーモンセットを確認します。

    $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             HANDLER          AGE
    kata-remote      kata-remote      152m
    Copy to Clipboard Toggle word wrap

第10章 トラブルシューティング

OpenShift sandboxed containers のトラブルシューティングを行う場合、サポートケースを開き、must-gather ツールを使用してデバッグ情報を提供できます。

クラスター管理者は、自分でログを確認して、より詳細なレベルのログを有効にすることもできます。

10.1. Red Hat サポート用のデータ収集

サポートケースを作成する際、ご使用のクラスターに関するデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。

must-gather ツールを使用すると、仮想マシンや OpenShift sandboxed containers に関連するその他のデータを含む、OpenShift Container Platform クラスターに関する診断情報を収集できます。

迅速なサポートのために、OpenShift Container Platform と OpenShift sandboxed containers の両方の診断情報を提供してください。

must-gather ツールの使用

oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。

  • リソース定義
  • サービスログ

デフォルトで、oc adm must-gather コマンドはデフォルトのプラグインイメージを使用し、./must-gather.local に書き込みを行います。

または、以下のセクションで説明されているように、適切な引数を指定してコマンドを実行すると、特定の情報を収集できます。

  • 1 つ以上の特定の機能に関連するデータを収集するには、以下のセクションに示すように、イメージと共に --image 引数を使用します。

    以下に例を示します。

    $ oc adm must-gather --image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel9:1.10.1
    Copy to Clipboard Toggle word wrap
  • 監査ログを収集するには、以下のセクションで説明されているように -- /usr/bin/gather_audit_logs 引数を使用します。

    以下に例を示します。

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    Copy to Clipboard Toggle word wrap
    注記

    ファイルのサイズを小さくするために、監査ログはデフォルトの情報セットの一部として収集されません。

oc adm must-gather を実行すると、ランダムな名前を持つ新規 Pod がクラスターの新規プロジェクトに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

以下に例を示します。

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...
Copy to Clipboard Toggle word wrap

任意で、--run-namespace オプションを使用して、特定の namespace で oc adm must-gather コマンドを実行できます。

以下に例を示します。

$ oc adm must-gather --run-namespace <namespace> --image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel9:1.10.1
Copy to Clipboard Toggle word wrap

10.2. ログデータの収集

次の機能とオブジェクトは、OpenShift sandboxed containers に関連付けられています。

  • OpenShift sandboxed containers リソースに属するすべての namespace とその子オブジェクト
  • すべての OpenShift sandboxed containers のカスタムリソース定義 (CRD)

kata ランタイムで実行されている各 Pod の以下のコンポーネントログを収集できます。

  • Kata エージェントログ
  • Kata ランタイムログ
  • QEMU ログ
  • 監査ログ
  • CRI-O ログ

10.2.1. CRI-O ランタイムのデバッグログの有効化

KataConfig CR の logLevel フィールドを更新することで、デバッグログを有効にできます。これにより、OpenShift sandboxed containers を実行しているワーカーノードの CRI-O ランタイムのログレベルが変更されます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 既存の KataConfig CR の logLevel フィールドを debug に変更します。

    $ oc patch kataconfig <kataconfig> --type merge --patch '{"spec":{"logLevel":"debug"}}'
    Copy to Clipboard Toggle word wrap
  2. UPDATED の値が True になり、すべてのワーカーノードが更新されたことが示されるまで kata-oc マシン設定プールを監視します。

    $ oc get mcp kata-oc
    Copy to Clipboard Toggle word wrap

    出力例

    NAME     CONFIG                 UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
    kata-oc  rendered-kata-oc-169   False    True      False     3             1                  1                    0                     9h
    Copy to Clipboard Toggle word wrap

検証

  1. マシン設定プールのノードでデバッグセッションを開始します。

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap
  2. ルートディレクトリーを /host に変更します。

    # chroot /host
    Copy to Clipboard Toggle word wrap
  3. crio.conf ファイルの変更を確認します。

    # crio config | egrep 'log_level
    Copy to Clipboard Toggle word wrap

    出力例

    log_level = "debug"
    Copy to Clipboard Toggle word wrap

10.2.2. コンポーネントのデバッグログの表示

クラスター管理者は、デバッグログを使用して問題のトラブルシューティングを行うことができます。各ノードのログは、ノードジャーナルに出力されます。

次の OpenShift sandboxed containers コンポーネントのログを確認できます。

  • Kata エージェント
  • Kata ランタイム (containerd-shim-kata-v2)
  • virtiofsd

QEMU は警告ログとエラーログのみを生成します。これらの警告とエラーは、追加の qemuPid フィールドとともに Kata ランタイムログと CRI-O ログの両方でノードジャーナルに出力されます。

QEMU ログの例

Mar 11 11:57:28 openshift-worker-0 kata[2241647]: time="2023-03-11T11:57:28.587116986Z" level=info msg="Start logging QEMU (qemuPid=2241693)" name=containerd-shim-v2 pid=2241647 sandbox=d1d4d68efc35e5ccb4331af73da459c13f46269b512774aa6bde7da34db48987 source=virtcontainers/hypervisor subsystem=qemu

Mar 11 11:57:28 openshift-worker-0 kata[2241647]: time="2023-03-11T11:57:28.607339014Z" level=error msg="qemu-kvm: -machine q35,accel=kvm,kernel_irqchip=split,foo: Expected '=' after parameter 'foo'" name=containerd-shim-v2 pid=2241647 qemuPid=2241693 sandbox=d1d4d68efc35e5ccb4331af73da459c13f46269b512774aa6bde7da34db48987 source=virtcontainers/hypervisor subsystem=qemu

Mar 11 11:57:28 openshift-worker-0 kata[2241647]: time="2023-03-11T11:57:28.60890737Z" level=info msg="Stop logging QEMU (qemuPid=2241693)" name=containerd-shim-v2 pid=2241647 sandbox=d1d4d68efc35e5ccb4331af73da459c13f46269b512774aa6bde7da34db48987 source=virtcontainers/hypervisor subsystem=qemu
Copy to Clipboard Toggle word wrap

Kata ランタイムは、QEMU が起動すると Start logging QEMU を出力し、QEMU が停止すると Stop Logging QEMU を出力します。エラーは、qemuPid フィールドが含まれる、これら 2 つのログメッセージの間に表示されます。QEMU からの実際のエラーメッセージは赤色で表示されます。

QEMU ゲストのコンソールはノードジャーナルにも出力されます。ゲストコンソールログを Kata エージェントログと一緒に表示できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  • Kata エージェントログとゲストコンソールログを確認するには、次のコマンドを実行します。

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata -g “reading guest console”
    Copy to Clipboard Toggle word wrap
  • Kata ランタイムログを確認するには、次のコマンドを実行します。

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata
    Copy to Clipboard Toggle word wrap
  • virtiofsd ログを確認するには、次のコマンドを実行します。

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t virtiofsd
    Copy to Clipboard Toggle word wrap
  • QEMU ログを確認するには、次のコマンドを実行します。

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata -g "qemuPid=\d+"
    Copy to Clipboard Toggle word wrap

付録A KataConfig ステータスメッセージ

次の表は、2 つのワーカーノードを持つクラスターの KataConfig カスタムリソース (CR) のステータスメッセージを示しています。

Expand
表A.1 KataConfig ステータスメッセージ
ステータス説明

Initial installation

KataConfig CR が作成され、両方のワーカーに kata-remote のインストールが開始されると、次のステータスが数秒間表示されます。

 conditions:
    message: Performing initial installation of kata-remote on cluster
    reason: Installing
    status: 'True'
    type: InProgress
 kataNodes:
   nodeCount: 0
   readyNodeCount: 0
Copy to Clipboard Toggle word wrap

インストール

数秒以内にステータスが変わります。

 kataNodes:
   nodeCount: 2
   readyNodeCount: 0
   waitingToInstall:
   - worker-0
   - worker-1
Copy to Clipboard Toggle word wrap

Installing (Worker-1 インストール開始)

短期間、ステータスが変化し、一方のノードが kata-remote のインストールを開始し、他方のノードが待機状態であることを示します。これは、常に 1 つのノードだけが使用不能になる可能性があるためです。両方のノードが最終的に kata-remote を受信するため、nodeCount は 2 のままですが、どちらのノードもまだその状態に達していないため、readyNodeCount は現在 0 です。

 kataNodes:
   installing:
   - worker-1
   nodeCount: 2
   readyNodeCount: 0
   waitingToInstall:
   - worker-0
Copy to Clipboard Toggle word wrap

Installing (Worker-1 がインストールされ、Worker-0 のインストールが開始されました)

しばらくすると、worker-1 がインストールを完了し、ステータスを変更します。readyNodeCount が 1 に更新され、worker-1kata-remote ワークロードを実行する準備が整ったことを示します。インストールプロセスの最後にランタイムクラスが作成されるまで、kata-remote ワークロードのスケジュールや実行はできません。

 kataNodes:
   installed:
   - worker-1
   installing:
   - worker-0
   nodeCount: 2
   readyNodeCount: 1
Copy to Clipboard Toggle word wrap

Installed

インストールされると、両方のワーカーがインストール済みとしてリストされ、理由を指定せずに InProgress 条件が False に移行し、クラスターへの kata-remote のインストールが成功したことを示します。

 conditions:
    message: ""
    reason: ""
    status: 'False'
    type: InProgress
 kataNodes:
   installed:
   - worker-0
   - worker-1
   nodeCount: 2
   readyNodeCount: 2
Copy to Clipboard Toggle word wrap
Expand
ステータス説明

Initial uninstall

kata-remote が両方のワーカーにインストールされていて、KataConfig を削除してクラスターから kata-remote を削除すると、両方のワーカーが数秒間待機状態になります。

 conditions:
    message: Removing kata-remote from cluster
    reason: Uninstalling
    status: 'True'
    type: InProgress
 kataNodes:
   nodeCount: 0
   readyNodeCount: 0
   waitingToUninstall:
   - worker-0
   - worker-1
Copy to Clipboard Toggle word wrap

アンインストール

数秒後、ワーカーの 1 つがアンインストールを開始します。

 kataNodes:
   nodeCount: 0
   readyNodeCount: 0
   uninstalling:
   - worker-1
   waitingToUninstall:
   - worker-0
Copy to Clipboard Toggle word wrap

アンインストール

Worker-1 が終了し、worker-0 がアンインストールを開始します。

 kataNodes:
   nodeCount: 0
   readyNodeCount: 0
   uninstalling:
   - worker-0
Copy to Clipboard Toggle word wrap
注記

reason フィールドには、次のような原因も報告されます。

  • Failed: これは、ノードが移行を完了できない場合に報告されます。statusTrue と報告し、messageNode <node_name> Degraded: <error_message_from_the_node> です。
  • BlockedByExistingKataPods: これは、kata-remote のアンインストール中に kata-remote ランタイムを使用するクラスター上で実行している Pod がある場合に報告されます。status フィールドは False で、messageExisting pods using "kata-remote" RuntimeClass found.Please delete the pods manually for KataConfig deletion to proceed です。クラスターコントロールプレーンとの通信が失敗した場合は、Failed to list kata pods: <error_message> のような技術的なエラーメッセージが報告される場合もあります。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat