ユーザーガイド


OpenShift sandboxed containers 1.6

OpenShift Container Platform での Sandboxed Container のデプロイ

Red Hat Customer Content Services

概要

ベアメタル、パブリッククラウド、および IBM プラットフォームの OpenShift Container Platform への OpenShift sandboxed containers のデプロイ

はじめに

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

Jira で Create Issue フォームを送信することで、フィードバックを提供したり、エラーを報告したりできます。Jira の課題は、Red Hat Hybrid Cloud Infrastructure Jira プロジェクトに作成されるため、フィードバックの進行状況を追跡できます。

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

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

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

第1章 OpenShift Sandboxed Containers について

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

1.1. Features

OpenShift Sandboxed Containers は、次の機能を提供します。

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

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

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

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

機密性の高いワークロードの分離を確保する
Red Hat OpenShift Container Platform の OpenShift サンドボックスコンテナーは、Kata コンテナーをオプションのランタイムとして統合し、軽量仮想マシンでコンテナー化されたアプリケーションを実行することでセキュリティーと分離を強化します。この統合により、既存の OpenShift ワークフローに大きな変更を加えずに、機密性の高いワークロードのよりセキュアなランタイム環境が提供されます。このランタイムは、専用の仮想マシン (VM) でコンテナーをサポートし、ワークロードの分離を改善します。
各ワークロードのカーネルを確実に分離する
カスタムカーネルチューニング (sysctl、スケジューラーの変更、キャッシュチューニングなど) とカスタムカーネルモジュール (ツリー外 または特別な引数など) の作成を必要とするワークロードを実行できます。
テナント全体で同じワークロードを共有する
同じ 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 との互換性

OpenShift Container Platform プラットフォームに必要な機能は、2 つの主要コンポーネントでサポートされます。

  • Kata Runtime: これには、Red Hat Enterprise Linux CoreOS (RHCOS)およびすべての OpenShift Container Platform リリースの 更新 が含まれます。
  • Web コンソールまたは OpenShift CLI (oc) のいずれかを使用して OpenShift Sandboxed Containers Operator をインストールできます。

OpenShift Sandboxed Containers Operator は Rolling Stream Operator です。つまり、サポートされる最新バージョンは最新バージョンのみです。これは、現在サポートされているすべてのバージョンの OpenShift Container Platform で動作します。詳細は、OpenShift Container Platform ライフサイクルポリシー を参照してください。

Operator は、RHCOS ホストで提供される機能と、それが実行される環境によって異なります。

注記

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

OpenShift サンドボックスコンテナーと OpenShift Container Platform リリース間の以下の互換性マトリックスは、互換性のある機能や環境を識別します。

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

x86_64

18.0 以降

s390x

4.14 以降

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

  • ベアメタル
  • ピア Pod

ピア Pod テクノロジーは OpenShift サンドボックスコンテナー 1.5/OpenShift Container Platform 4.14 で開始され、パブリッククラウドに OpenShift Sandboxed Containers をデプロイメントできるようになります。

Expand
表1.2 OpenShift バージョンによる機能の可用性
機能デプロイメント方法OpenShift Container Platform 3.11OpenShift Container Platform 3.11

Confidential Containers[1]

ベアメタル

いいえ

いいえ

ピア Pod

開発者プレビュー

開発者プレビュー

GPU サポート[2]

ベアメタル

いいえ

いいえ

ピア Pod

開発者プレビュー

開発者プレビュー

  1. Confidential Containers は、AMD SEV-SNP でのみサポートされます。
  2. GPU 機能は s390x では利用できません。
Expand
表1.3 OpenShift Sandboxed Containers でサポートされているプラットフォーム
プラットフォームピア PodGPU機密コンテナー

AWS Cloud Computing Services

はい

開発者プレビュー

いいえ

Microsoft Azure Cloud Computing Services

はい

開発者プレビュー

開発者プレビュー

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

OpenShift Sandboxed Containers をデプロイする前に、クラスター内のノードが 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

Operator は、人間のオペレーターがシステムで実行できるアクション、つまり操作を自動化するソフトウェアコンポーネントです。

OpenShift Sandboxed Containers Operator は、クラスター上で Sandboxed Containers のライフサイクルを管理してタスクを実行します。OpenShift Sandboxed Containers Operator を使用して、Sandboxed Containers のインストールと削除、ソフトウェア更新、ステータス監視などのタスクを実行できます。

Kata Container
Kata Container は OpenShift サンドボックスコンテナーの構築に使用されるコアアップストリームプロジェクトです。OpenShift サンドボックスコンテナーは Kata Container と OpenShift Container Platform を統合します。
KataConfig
KataConfig オブジェクトは Sandboxed Containers の設定を表します。ソフトウェアのデプロイ先のノードなど、クラスターの状態に関する情報を保存します。
ランタイムクラス
RuntimeClass オブジェクトは、指定のワークロード実行に使用可能なランタイムを記述します。kata という名前のランタイムクラスは、OpenShift の Sandboxed Containers Operator によってインストールされ、デプロイされます。ランタイムクラスには、ランタイムが Pod オーバーヘッド など、動作に必要なリソースを記述するランタイムに関する情報が含まれます。
ピア Pod
OpenShift Sandboxed Containers のピア Pod は、標準 Pod の概念を拡張します。ピア Pod 内のワーカーノード自体に仮想マシンが作成される標準の Sandboxed Containers とは異なり、サポートされているハイパーバイザーまたはクラウドプロバイダー API を使用して、リモートハイパーバイザー経由で仮想マシンが作成されます。ピア Pod はワーカーノード上で通常の Pod として機能し、対応する VM が別の場所で実行されます。VM のリモートの場所はユーザーに対して透過的であり、Pod 仕様のランタイムクラスによって指定されます。ピア Pod 設計により、ネストされた仮想化の必要性が回避されます。

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 はこのメカニズムを使用して、Sandboxed Containers をクラスターにデプロイします。

Sandboxed Containers の 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. ストレージに関する考慮事項

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

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
volumeModeBlock に設定して、この PV が raw ブロックボリュームであることを示します。
2
この値を、LocalVolume リソース by-id への実際のローカルディスクファイルパスに置き換えます。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。OpenShift サンドボックスコンテナーをデプロイするときに、ブロックデバイスを使用するノードにラベルを付ける場合にも、このパスを使用する必要があります。

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 セキュリティーガイド のリスク管理および規制対応の章を参照してください。

第2章 ベアメタルへのワークロードのデプロイ

ワーカーノードに Red Hat Enterprise Linux CoreOS (RHCOS) がインストールされたオンプレミスのベアメタルサーバーに、OpenShift sandboxed containers ワークロードをデプロイできます。

注記
  • RHEL ノードはサポートされていません。
  • ネストされた仮想化はサポートされていません。

ユーザーによってプロビジョニングされるインストーラーでプロビジョニングされる、または Assisted Installer によるインストールなどのインストール方法を使用してクラスターをデプロイできます。

Amazon Web Services (AWS) ベアメタルインスタンスに OpenShift Sandboxed Containers のインストールもできます。他のクラウドプロバイダーが提供するベアメタルインスタンスはサポートされません。

デプロイメントワークフロー

次の手順を実行して、OpenShift Sandboxed Containers のワークロードをデプロイします。

  1. 環境を準備します。
  2. KataConfig カスタムリソースを作成します。
  3. kata ランタイムクラスを使用するようにワークロードオブジェクトを設定します。

2.1. 環境の準備

環境を準備するには、以下の手順を実行します。

  1. クラスターに十分なリソースがあることを確認します。
  2. OpenShift Sandboxed Containers Operator を再インストールします。
  3. オプション: ワーカーノードが OpenShift sandboxed containers をサポートするように ノード適格性チェック を設定します。

    1. Node Feature Discovery (NFD) Operator をインストールします。詳細は、NFD Operator のドキュメント を参照してください。
    2. NodeFeatureDiscovery カスタムリソース (CR) を作成して、NFD Operator がチェックするノード設定パラメーターを定義します。

2.1.1. リソース要件

OpenShift サンドボックスコンテナーを使用すると、ユーザーはサンドボックスランタイム (Kata) 内の OpenShift Container Platform クラスターでワークロードを実行できます。各 Pod は仮想マシン (VM) で表されます。各仮想マシンは QEMU プロセスで実行され、コンテナーワークロードおよびこれらのコンテナーで実行されているプロセスを管理するためのスーパーバイザーとして機能する kata-agent プロセスをホストします。2 つのプロセスを追加すると、オーバーヘッドがさらに増加します。

  • containerd-shim-kata-v2。これは Pod との通信に使用されます。
  • virtiofsd。これはゲストの代わりにホストファイルシステムのアクセスを処理します。

各仮想マシンには、デフォルトのメモリー容量が設定されます。コンテナーでメモリーが明示的に要求された場合に、メモリーが追加で仮想マシンにホットプラグされます。

メモリーリソースなしで実行されているコンテナーは、仮想マシンによって使用される合計メモリーがデフォルトの割り当てに達するまで、空きメモリーを消費します。ゲストやその I/O バッファーもメモリーを消費します。

コンテナーに特定のメモリー量が指定されている場合には、コンテナーが起動する前に、メモリーが仮想マシンにホットプラグされます。

メモリー制限が指定されている場合には、上限より多くメモリーが消費された場合に、ワークロードが終了します。メモリー制限が指定されていない場合、仮想マシンで実行されているカーネルがメモリー不足になる可能性があります。カーネルがメモリー不足になると、仮想マシン上の他のプロセスが終了する可能性があります。

デフォルトのメモリーサイズ

以下の表は、リソース割り当てのデフォルト値を示しています。

Expand
リソース

デフォルトで仮想マシンに割り当てられるメモリー

2Gi

起動時のゲスト Linux カーネルのメモリー使用量

~110Mi

QEMU プロセスで使用されるメモリー (仮想マシンメモリーを除く)

~30Mi

virtiofsd プロセスで使用されるメモリー (VM I/O バッファーを除く)

~10Mi

containerd-shim-kata-v2 プロセスで使用されるメモリー

~20Mi

Fedora で dnf install を実行した後のファイルバッファーのキャッシュデータ

~300Mi* [1]

ファイルバッファーが表示され、このバッファーは以下の複数の場所に考慮されます。

  • ファイルバッファーキャッシュとして表示されるゲスト。
  • 許可されたユーザー空間ファイルの I/O 操作をマッピングする virtiofsd デーモン。
  • ゲストメモリーとして使用される QEMU プロセス。
注記

メモリー使用量の合計は、メモリー使用率メトリックによって適切に考慮され、そのメモリーを 1 回だけカウントします。

Pod のオーバーヘッド では、ノード上の Pod が使用するシステムリソースの量を記述します。以下のように、oc describe runtimeclass kata を使用して、Kata ランタイムクラスの現在の Pod オーバーヘッドを取得できます。

$ oc describe runtimeclass kata
Copy to Clipboard Toggle word wrap

出力例

kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
  name: kata
overhead:
  podFixed:
    memory: "500Mi"
    cpu: "500m"
Copy to Clipboard Toggle word wrap

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

注記

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

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

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

2.1.2. OpenShift Sandboxed Containers Operator のインストール

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

2.1.2.1. Web コンソールを使用した Operator のインストール

Red Hat OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
  3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
  4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
  5. Installed NamespaceOperator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

    注記

    OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

  6. Approval StrategyAutomatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
  7. Install をクリックします。

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  1. OperatorsInstalled Operators に移動します。
  2. OpenShift Sandboxed Containers Operator が表示されることを確認します。
2.1.2.2. CLI を使用した Operator のインストール

CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。

前提条件

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

手順

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

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

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

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

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

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-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.6.0
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

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

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  • 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ 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.6.0    1.5.3        Succeeded
    Copy to Clipboard Toggle word wrap

2.1.3. NodeFeatureDiscovery CR の作成

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.2. Web コンソールを使用したワークロードのデプロイ

Web コンソールを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

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

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

kata ランタイムクラスは、デフォルトですべてのワーカーノードにインストールされます。特定のノードにのみ kata をインストールする場合は、それらのノードにラベルを追加し、KataConfig CR でラベルを定義できます。

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

重要

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

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

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • オプション: ノードの適格性チェックを有効にする場合は、Node Feature Discovery Operator をインストールしておきます。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. OpenShift sandboxed containers Operator を選択します。
  3. KataConfig タブで、Create KataConfig をクリックします。
  4. 以下の詳細を入力します。

    • Name: オプション: デフォルト名は example-kataconfig です。
    • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
    • checkNodeEligibility : オプション: Node Feature Discovery Operator (NFD) を使用してノードの適格性を検出する場合に選択します。
    • kataConfigPoolSelector。オプション: 選択したノードに kata をインストールするには、選択したノードのラベルに一致する式を追加します。

      1. kataConfigPoolSelector エリアを展開します。
      2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
      3. Add matchExpressions をクリックします。
      4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
      5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、InNotInExistsDoesNotExist です。
      6. Values エリアを展開し、Add value をクリックします。
      7. Value フィールドで、true または falsekey ラベル値として入力します。
    • logLevel: ランタイムクラスが kata のノードに対して取得されるログデータのレベルを定義します。
  5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata ランタイムクラスをインストールします。

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

検証

  1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。
  2. YAML タブをクリックして status スタンザを表示します。

    status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

  3. Reload をクリックして、YAML を更新します。

    status.kataNodes 配列内のすべてのワーカーに、installed の値と、理由が指定されていない conditions.InProgress: False が表示される場合、kata がクラスターにインストールされています。

詳細は、KataConfig ステータスメッセージ を参照してください。

2.2.2. ワークロードオブジェクトの設定

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

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの config map を作成している。
  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. OpenShift Container Platform Web コンソールで、Workloads → workload type (例: Pods) に移動します。
  2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
  3. YAML タブをクリックします。
  4. 次の例のように、spec.runtimeClassName: kata を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata
    # ...
    Copy to Clipboard Toggle word wrap

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

検証

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

2.3. コマンドラインを使用したワークロードの展開

コマンドラインを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

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

前提条件

  • ローカルストレージ 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 プロビジョニングに使用できるようにする winefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。
    5
    選択するローカルストレージデバイスの一覧を含むパスです。ブロックデバイスにサンドボックス化されたコンテナーノードをデプロイする場合は、このパスを使用する必要があります。
    6
    この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: /dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
  2. OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。

    $ oc create -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 サンドボックスコンテナー用にローカルブロックボリュームをプロビジョニングした場合は、定義されたボリュームリソースで指定されたパスにある任意のブロックデバイスにノードをデプロイすることを選択できます。

前提条件

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

手順

  • ブロックデバイスを使用してデプロイする各ノードに対して、次のコマンドを実行します。
$ 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. KataConfig カスタムリソースの作成

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

KataConfig CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。

  • QEMU や kata-containers などの必要な RHCOS 拡張機能を RHCOS ノードにインストールします。
  • CRI-O ランタイムが正しいランタイムハンドラーで設定されていることを確認してください。
  • デフォルト設定で kata という名前の RuntimeClass CR を作成します。これにより、ユーザーは、RuntimeClassName フィールドで CR を参照することにより、kata をランタイムとして使用するようにワークロードを設定できます。この CR は、ランタイムのリソースオーバーヘッドも指定します。

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

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • オプション: ノードの適格性チェックを有効にする場合は、Node Feature Discovery Operator をインストールしておきます。

手順

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

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      checkNodeEligibility: false 
    1
    
      logLevel: info
    Copy to Clipboard Toggle word wrap
    1
    オプション: ノード適格性チェックを実行するには、`checkNodeEligibility` を true に設定します。
  2. オプション: 選択したノードに kata をインストールするには、次の例に従ってノードラベルを指定します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    選択したノードのラベルを指定します。
  3. KataConfig CR を作成します。

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

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

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

検証

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

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

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

詳細は、KataConfig ステータスメッセージ を参照してください。

2.3.4. オプション: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

2.3.5. ワークロードオブジェクトの設定

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

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの config map を作成している。
  • KataConfig カスタムリソース (CR) を作成している。

手順

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

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata
    # ...
    Copy to Clipboard Toggle word wrap

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

検証

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

第3章 パブリッククラウドへのワークロードのデプロイ

OpenShift Sandboxed Containers のワークロードを AWS Cloud Computing Services および Microsoft Azure Cloud Computing Services にデプロイできます。

クラスターの要件

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

3.1. AWS へのワークロードのデプロイ

OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して、OpenShift sandboxed containers のワークロードを AWS クラウドコンピューティングサービスにデプロイできます。

デプロイメントワークフロー

  1. ポートを有効にします。
  2. AWS のシークレットを作成します。
  3. AWS の config map を作成します。
  4. KataConfig カスタムリソースを作成します。
  5. オプション: ノードごとのピア Pod 仮想マシン制限を変更します。
  6. kata-remote ランタイムクラスを使用するようにワークロードオブジェクトを設定します。

3.1.1. 環境の準備

環境を準備するには、以下の手順を実行します。

  1. クラスターに十分なリソースがあることを確認します。
  2. OpenShift Sandboxed Containers Operator を再インストールします。
  3. ピア Pod との内部通信を許可するには、ポート 15150 と 9000 を有効にします。
3.1.1.1. リソース要件

ピア 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 ノード拡張リソースとして定義されます。この制限はノードごとであり、peerpodConfig カスタムリソース (CR) の limit 属性によって設定されます。

peerpodconfig-openshift という名前の peerpodConfig CR は、kataConfig CR を作成してピア Pod を有効にするときに作成され、openshift-sandboxed-containers-operator namespace に配置されます。

次の peerpodConfig CR の例は、デフォルトの spec 値を示しています。

apiVersion: confidentialcontainers.org/v1alpha1
kind: PeerPodConfig
metadata:
  name: peerpodconfig-openshift
  namespace: openshift-sandboxed-containers-operator
spec:
  cloudSecretName: peer-pods-secret
  configMapName: peer-pods-cm
  limit: "10" 
1

  nodeSelector:
    node-role.kubernetes.io/kata-oc: ""
Copy to Clipboard Toggle word wrap
1
デフォルトの制限は、ノードごとに 10 VM です。

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

ご使用の環境の要件に基づいて、ノードごとの制限を編集できます。詳細は、「ピア Pod のノードごとの VM 制限の変更」を参照してください。

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 の作成を許可するクラスター全体のポリシーを定義します。

3.1.1.2. 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.1.1.3. OpenShift Sandboxed Containers Operator のインストール

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

3.1.1.3.1. Web コンソールを使用した Operator のインストール

Red Hat OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
  3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
  4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
  5. Installed NamespaceOperator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

    注記

    OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

  6. Approval StrategyAutomatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
  7. Install をクリックします。

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  1. OperatorsInstalled Operators に移動します。
  2. OpenShift Sandboxed Containers Operator が表示されることを確認します。
3.1.1.3.2. CLI を使用した Operator のインストール

CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。

前提条件

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

手順

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

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

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

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

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

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-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.6.0
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

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

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  • 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ 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.6.0    1.5.3        Succeeded
    Copy to Clipboard Toggle word wrap

3.1.2. Web コンソールを使用したワークロードのデプロイ

Web コンソールを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

3.1.2.1. シークレットの作成

OpenShift Container Platform クラスターに Secret オブジェクトを作成する必要があります。シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するためのクラウドプロバイダーの認証情報が保存されます。デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。

前提条件

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

    これらの値は、AWS コンソールで生成できます。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. OpenShift sandboxed containers Operator タイルをクリックします。
  3. 右上隅のインポートアイコン (+) をクリックします。
  4. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      AWS_ACCESS_KEY_ID: "<aws_access_key>" 
    1
    
      AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>" 
    2
    Copy to Clipboard Toggle word wrap
    1
    AWS_ACCESS_KEY_ID 値を指定します。
    2
    AWS_SECRET_ACCESS_KEY 値を指定します。
  5. Save をクリックして変更を適用します。
注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon DaemonSet を再起動して変更を適用する必要があります。

シークレットを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

デーモンセットを再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

検証

  • WorkloadsSecrets に移動して、シークレットを表示します。
3.1.2.2. config map の作成

クラウドプロバイダーの OpenShift Container Platform クラスターに config map を作成する必要があります。

Amazon Machine Image (AMI) ID を設定する必要があります。この値は、config map を作成する前に取得できます。

手順

  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 text)
      && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""
      Copy to Clipboard Toggle word wrap
  2. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  3. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  4. 右上隅にあるインポートアイコン (+) をクリックします。
  5. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: peer-pods-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      CLOUD_PROVIDER: "aws"
      VXLAN_PORT: "9000"
      PODVM_INSTANCE_TYPE: "t3.medium" 
    1
    
      PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 
    2
    
      PROXY_TIMEOUT: "5m"
      DISABLECVM: "true"
      PODVM_AMI_ID: "<podvm_ami_id>" 
    3
    
      AWS_REGION: "<aws_region>" 
    4
    
      AWS_SUBNET_ID: "<aws_subnet_id>" 
    5
    
      AWS_VPC_ID: "<aws_vpc_id>" 
    6
    
      AWS_SG_IDS: "<aws_sg_ids>" 
    7
    Copy to Clipboard Toggle word wrap
    1
    ワークロードでタイプが定義されていない場合に使用されるデフォルトのインスタンスタイプを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスタイプを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスタイプを定義したり、ワークロードが大きい場合は大きいインスタンスタイプを定義したりすることができます。
    3
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく AMI ID を使用して KataConfig CR を実行するときに入力されます。独自の AMI を作成する場合は、正しい AMI ID を指定します。
    4
    取得した AWS_REGION 値を指定します。
    5
    取得した AWS_SUBNET_ID 値を指定します。
    6
    取得した AWS_VPC_ID 値を指定します。
    7
    取得した AWS_SG_IDS 値を指定します。
  6. Save をクリックして変更を適用します。

    クラウドプロバイダー用の config map が作成されます。

注記

ピア Pod config map を更新する場合、変更を適用するために peerpodconfig-ctrl-caa-daemon デーモンセットを再起動する必要があります。

config map を更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

daemonset を再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

検証

  • 新しい config map を表示するには、WorkloadsConfigMaps に移動します。
3.1.2.3. KataConfig カスタムリソースの作成

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

kata-remote ランタイムクラスは、デフォルトですべてのワーカーノードにインストールされます。kata-remote を特定のノードにのみインストールする場合は、それらのノードにラベルを追加し、KataConfig CR でラベルを定義できます。

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

重要

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

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

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. OpenShift sandboxed containers Operator を選択します。
  3. KataConfig タブで、Create KataConfig をクリックします。
  4. 以下の詳細を入力します。

    • Name: オプション: デフォルト名は example-kataconfig です。
    • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
    • enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。
    • kataConfigPoolSelector。オプション: 選択したノードに kata-remote をインストールするには、選択したノードのラベルに一致する式を追加します。

      1. kataConfigPoolSelector エリアを展開します。
      2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
      3. Add matchExpressions をクリックします。
      4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
      5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、InNotInExistsDoesNotExist です。
      6. Values エリアを展開し、Add value をクリックします。
      7. Value フィールドで、true または falsekey ラベル値として入力します。
    • logLevel: ランタイムクラスが kata-remote のノードに対して取得されるログデータのレベルを定義します。
  5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata-remote ランタイムクラスをインストールします。

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

検証

  1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。
  2. YAML タブをクリックして status スタンザを表示します。

    status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata-remote インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

  3. Reload をクリックして、YAML を更新します。

    status.kataNodes 配列内のすべてのワーカーに、値 installed と、理由が指定されていない conditions.InProgress: False が表示される場合、kata-remote はクラスターにインストールされています。

詳細は、KataConfig ステータスメッセージ を参照してください。

3.1.2.3.1. オプション: Pod 仮想マシンイメージの検証

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

手順

  1. WorkloadsConfigMaps に移動します。
  2. プロバイダー config map をクリックすると、詳細が表示されます。
  3. YAML タブをクリックします。
  4. 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.1.2.4. オプション: ノードあたりのピア 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. 次のコマンドを実行して、peerpodConfig CR の limit 属性を変更します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    --type merge --patch '{"spec":{"limit":"<value>"}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <value> は、定義する制限に置き換えます。
3.1.2.5. ワークロードオブジェクトの設定

次の Pod テンプレートされたオブジェクトのランタイムクラスとして kata-remote を設定して、OpenShift Sandboxed Containers のワークロードをデプロイします。

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

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

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの config map を作成している。
  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. OpenShift Container Platform Web コンソールで、Workloads → workload type (例: Pods) に移動します。
  2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
  3. YAML タブをクリックします。
  4. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap
  5. 手動で定義されたインスタンスタイプまたは自動インスタンスタイプを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。

    • 手動で定義されたインスタンスタイプを使用するには、次のアノテーションを追加します。

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

      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

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

  6. Save をクリックして変更を適用します。

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

検証

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

3.1.3. コマンドラインを使用したワークロードの展開

コマンドラインを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

3.1.3.1. シークレットの作成

OpenShift Container Platform クラスターに Secret オブジェクトを作成する必要があります。シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するためのクラウドプロバイダーの認証情報が保存されます。デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。

前提条件

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

    これらの値は、AWS コンソールで生成できます。

手順

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

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      AWS_ACCESS_KEY_ID: "<aws_access_key>" 
    1
    
      AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>" 
    2
    Copy to Clipboard Toggle word wrap
    1
    AWS_ACCESS_KEY_ID 値を指定します。
    2
    AWS_SECRET_ACCESS_KEY 値を指定します。
  2. マニフェストを適用して secret オブジェクトを作成します。

    $ oc apply -f peer-pods-secret.yaml
    Copy to Clipboard Toggle word wrap
注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon DaemonSet を再起動して変更を適用する必要があります。

シークレットを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

デーモンセットを再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

3.1.3.2. config map の作成

クラウドプロバイダーの OpenShift Container Platform クラスターに config map を作成する必要があります。

Amazon Machine Image (AMI) ID を設定する必要があります。この値は、config map を作成する前に取得できます。

手順

  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 text)
      && 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"
      PODVM_INSTANCE_TYPE: "t3.medium" 
    1
    
      PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 
    2
    
      PROXY_TIMEOUT: "5m"
      DISABLECVM: "true"
      PODVM_AMI_ID: "<podvm_ami_id>" 
    3
    
      AWS_REGION: "<aws_region>" 
    4
    
      AWS_SUBNET_ID: "<aws_subnet_id>" 
    5
    
      AWS_VPC_ID: "<aws_vpc_id>" 
    6
    
      AWS_SG_IDS: "<aws_sg_ids>" 
    7
    Copy to Clipboard Toggle word wrap
    1
    ワークロードでタイプが定義されていない場合に使用されるデフォルトのインスタンスタイプを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスタイプを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスタイプを定義したり、ワークロードが大きい場合は大きいインスタンスタイプを定義したりすることができます。
    3
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく AMI ID を使用して KataConfig CR を実行するときに入力されます。独自の AMI を作成する場合は、正しい AMI ID を指定します。
    4
    取得した AWS_REGION 値を指定します。
    5
    取得した AWS_SUBNET_ID 値を指定します。
    6
    取得した AWS_VPC_ID 値を指定します。
    7
    取得した AWS_SG_IDS 値を指定します。
  3. マニフェストを適用して config map を作成します。

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

    クラウドプロバイダー用の config map が作成されます。

注記

ピア Pod config map を更新する場合、変更を適用するために peerpodconfig-ctrl-caa-daemon デーモンセットを再起動する必要があります。

config map を更新した後、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

daemonset を再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

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

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

KataConfig CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。

  • デフォルト設定で kata-remote という名前の RuntimeClass CR を作成します。これにより、RuntimeClassName フィールドの CR を参照して、kata-remote をランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。

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

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

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

手順

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

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      enablePeerPods: true
      logLevel: info
    Copy to Clipboard Toggle word wrap
  2. オプション: 選択したノードに kata-remote をインストールするには、次の例に従ってノードラベルを指定します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    選択したノードのラベルを指定します。
  3. KataConfig CR を作成します。

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

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

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

検証

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

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

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

詳細は、KataConfig ステータスメッセージ を参照してください。

3.1.3.3.1. オプション: 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.1.3.4. オプション: ノードあたりのピア 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. 次のコマンドを実行して、peerpodConfig CR の limit 属性を変更します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    --type merge --patch '{"spec":{"limit":"<value>"}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <value> は、定義する制限に置き換えます。
3.1.3.5. ワークロードオブジェクトの設定

次の Pod テンプレートされたオブジェクトのランタイムクラスとして kata-remote を設定して、OpenShift Sandboxed Containers のワークロードをデプロイします。

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

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

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの 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. 手動で定義されたインスタンスタイプまたは自動インスタンスタイプを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。

    • 手動で定義されたインスタンスタイプを使用するには、次のアノテーションを追加します。

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

      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

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

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

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

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

検証

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

3.2. Azure へのワークロードのデプロイ

OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して、Microsoft Azure クラウドコンピューティングサービスに OpenShift sandboxed containers ワークロードをデプロイできます。

デプロイメントワークフロー

  1. Azure アクセスキーのシークレットを作成します。
  2. Azure インスタンスのサイズやその他のパラメーターを定義する config map を作成します。
  3. SSH キーシークレットを作成します。
  4. KataConfig カスタムリソースを作成します。
  5. オプション: ノードごとのピア Pod 仮想マシン制限を変更します。
  6. kata-remote ランタイムクラスを使用するようにワークロードオブジェクトを設定します。

3.2.1. 環境の準備

環境を準備するには、以下の手順を実行します。

  1. クラスターに十分なリソースがあることを確認します。
  2. OpenShift Sandboxed Containers Operator を再インストールします。
3.2.1.1. リソース要件

ピア 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 ノード拡張リソースとして定義されます。この制限はノードごとであり、peerpodConfig カスタムリソース (CR) の limit 属性によって設定されます。

peerpodconfig-openshift という名前の peerpodConfig CR は、kataConfig CR を作成してピア Pod を有効にするときに作成され、openshift-sandboxed-containers-operator namespace に配置されます。

次の peerpodConfig CR の例は、デフォルトの spec 値を示しています。

apiVersion: confidentialcontainers.org/v1alpha1
kind: PeerPodConfig
metadata:
  name: peerpodconfig-openshift
  namespace: openshift-sandboxed-containers-operator
spec:
  cloudSecretName: peer-pods-secret
  configMapName: peer-pods-cm
  limit: "10" 
1

  nodeSelector:
    node-role.kubernetes.io/kata-oc: ""
Copy to Clipboard Toggle word wrap
1
デフォルトの制限は、ノードごとに 10 VM です。

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

ご使用の環境の要件に基づいて、ノードごとの制限を編集できます。詳細は、「ピア Pod のノードごとの VM 制限の変更」を参照してください。

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 の作成を許可するクラスター全体のポリシーを定義します。

3.2.1.2. OpenShift Sandboxed Containers Operator のインストール

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

3.2.1.2.1. Web コンソールを使用した Operator のインストール

Red Hat OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
  3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
  4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
  5. Installed NamespaceOperator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

    注記

    OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

  6. Approval StrategyAutomatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
  7. Install をクリックします。

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  1. OperatorsInstalled Operators に移動します。
  2. OpenShift Sandboxed Containers Operator が表示されることを確認します。
3.2.1.2.2. CLI を使用した Operator のインストール

CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。

前提条件

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

手順

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

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

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

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

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

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-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.6.0
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

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

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  • 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ 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.6.0    1.5.3        Succeeded
    Copy to Clipboard Toggle word wrap

3.2.2. Web コンソールを使用したワークロードのデプロイ

Web コンソールを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

3.2.2.1. シークレットの作成

OpenShift Container Platform クラスターに Secret オブジェクトを作成する必要があります。シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するためのクラウドプロバイダーの認証情報が保存されます。デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。

前提条件

  • Azure CLI ツールをインストールして設定している。

手順

  1. Azure サブスクリプション ID を取得します。

    $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
    Copy to Clipboard Toggle word wrap
  2. RBAC コンテンツを生成します。これにより、クライアント ID、クライアントシークレット、およびテナント ID が生成されます。

    $ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID --query "{ client_id: appId, client_secret: password, tenant_id: tenant }
    Copy to Clipboard Toggle word wrap

    出力例:

    {
      "client_id": `AZURE_CLIENT_ID`,
      "client_secret": `AZURE_CLIENT_SECRET`,
      "tenant_id": `AZURE_TENANT_ID`
    }
    Copy to Clipboard Toggle word wrap
  3. secret オブジェクトで使用する RBAC 出力を記録します。
  4. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  5. OpenShift sandboxed containers Operator タイルをクリックします。
  6. 右上隅のインポートアイコン (+) をクリックします。
  7. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      AZURE_CLIENT_ID: "<azure_client_id>" 
    1
    
      AZURE_CLIENT_SECRET: "<azure_client_secret>" 
    2
    
      AZURE_TENANT_ID: "<azure_tenant_id>" 
    3
    
      AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>" 
    4
    Copy to Clipboard Toggle word wrap
    1
    AZURE_CLIENT_ID 値を指定します。
    2
    AZURE_CLIENT_SECRET 値を指定します。
    3
    AZURE_TENANT_ID 値を指定します。
    4
    AZURE_SUBSCRIPTION_ID 値を指定します。
  8. Save をクリックして変更を適用します。
注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon DaemonSet を再起動して変更を適用する必要があります。

シークレットを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

デーモンセットを再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

検証

  • WorkloadsSecrets に移動して、シークレットを表示します。
3.2.2.2. config map の作成

クラウドプロバイダーの OpenShift Container Platform クラスターに config map を作成する必要があります。

手順

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

    1. 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 を取得するために使用されます。

    2. 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
    3. 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
    4. 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
    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. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  3. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  4. 右上隅にあるインポートアイコン (+) をクリックします。
  5. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: peer-pods-cm
      namespace: openshift-sandboxed-containers-operator
    data:
      CLOUD_PROVIDER: "azure"
      VXLAN_PORT: "9000"
      AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 
    1
    
      AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 
    2
    
      AZURE_SUBNET_ID: "<azure_subnet_id>" 
    3
    
      AZURE_NSG_ID: "<azure_nsg_id>" 
    4
    
      PROXY_TIMEOUT: "5m"
      DISABLECVM: "true"
      AZURE_IMAGE_ID: "<azure_image_id>" 
    5
    
      AZURE_REGION: "<azure_region>" 
    6
    
      AZURE_RESOURCE_GROUP: "<azure_resource_group>" 
    7
    Copy to Clipboard Toggle word wrap
    1
    ワークロードでタイプが定義されていない場合に使用されるデフォルトのインスタンスサイズを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスサイズを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスサイズを定義したり、ワークロードが大きい場合は大きいインスタンスサイズを定義したりすることができます。
    3
    取得した AZURE_SUBNET_ID 値を指定します。
    4
    取得した AZURE_NSG_ID 値を指定します。
    5
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく Azure イメージ ID を使用して KataConfig CR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。
    6
    取得した AZURE_REGION 値を指定します。
    7
    取得した AZURE_RESOURCE_GROUP 値を指定します。
  6. Save をクリックして変更を適用します。

    クラウドプロバイダー用の config map が作成されます。

注記

ピア Pod config map を更新する場合、変更を適用するために peerpodconfig-ctrl-caa-daemon デーモンセットを再起動する必要があります。

config map を更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

daemonset を再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

検証

  • 新しい config map を表示するには、WorkloadsConfigMaps に移動します。
3.2.2.3. SSH キーシークレットの作成

Azure の SSH キー secret オブジェクトを作成する必要があります。

手順

  1. OpenShift Container Platform クラスターにログインします。
  2. 次のコマンドを実行して、SSH キーペアを生成します。

    $ ssh-keygen -f ./id_rsa -N ""
    Copy to Clipboard Toggle word wrap
  3. OpenShift Container Platform Web コンソールで、WorkloadsSecrets に移動します。
  4. Secrets ページで、openshift-sandboxed-containers-operator プロジェクトにいることを確認します。
  5. Create をクリックし、Key/value secret を選択します。
  6. Secret name フィールドに ssh-key-secret と入力します。
  7. Key フィールドに id_rsa.pub と入力します。
  8. Value フィールドに、公開 SSH 鍵を貼り付けます。
  9. Create をクリックします。

    SSH キーシークレットが作成されます。

  10. 作成した SSH 鍵を削除します。

    $ shred -remove id_rsa.pub id_rsa
    Copy to Clipboard Toggle word wrap
3.2.2.4. KataConfig カスタムリソースの作成

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

kata-remote ランタイムクラスは、デフォルトですべてのワーカーノードにインストールされます。kata-remote を特定のノードにのみインストールする場合は、それらのノードにラベルを追加し、KataConfig CR でラベルを定義できます。

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

重要

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

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

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. OpenShift sandboxed containers Operator を選択します。
  3. KataConfig タブで、Create KataConfig をクリックします。
  4. 以下の詳細を入力します。

    • Name: オプション: デフォルト名は example-kataconfig です。
    • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
    • enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。
    • kataConfigPoolSelector。オプション: 選択したノードに kata-remote をインストールするには、選択したノードのラベルに一致する式を追加します。

      1. kataConfigPoolSelector エリアを展開します。
      2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
      3. Add matchExpressions をクリックします。
      4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
      5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、InNotInExistsDoesNotExist です。
      6. Values エリアを展開し、Add value をクリックします。
      7. Value フィールドで、true または falsekey ラベル値として入力します。
    • logLevel: ランタイムクラスが kata-remote のノードに対して取得されるログデータのレベルを定義します。
  5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata-remote ランタイムクラスをインストールします。

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

検証

  1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。
  2. YAML タブをクリックして status スタンザを表示します。

    status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata-remote インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

  3. Reload をクリックして、YAML を更新します。

    status.kataNodes 配列内のすべてのワーカーに、値 installed と、理由が指定されていない conditions.InProgress: False が表示される場合、kata-remote はクラスターにインストールされています。

詳細は、KataConfig ステータスメッセージ を参照してください。

3.2.2.4.1. オプション: Pod 仮想マシンイメージの検証

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

手順

  1. WorkloadsConfigMaps に移動します。
  2. プロバイダー config map をクリックすると、詳細が表示されます。
  3. YAML タブをクリックします。
  4. 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 サポートケースを送信し、両方のログの出力を添付してください。

3.2.2.5. オプション: ノードあたりのピア 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. 次のコマンドを実行して、peerpodConfig CR の limit 属性を変更します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    --type merge --patch '{"spec":{"limit":"<value>"}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <value> は、定義する制限に置き換えます。
3.2.2.6. ワークロードオブジェクトの設定

次の Pod テンプレートされたオブジェクトのランタイムクラスとして kata-remote を設定して、OpenShift Sandboxed Containers のワークロードをデプロイします。

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

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

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの config map を作成している。
  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. OpenShift Container Platform Web コンソールで、Workloads → workload type (例: Pods) に移動します。
  2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
  3. YAML タブをクリックします。
  4. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap
  5. 手動で定義されたインスタンスサイズまたは自動インスタンスサイズを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。

    • 手動で定義されたインスタンスサイズを使用するには、次のアノテーションを追加します。

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

      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

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

  6. Save をクリックして変更を適用します。

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

検証

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

3.2.3. コマンドラインを使用したワークロードの展開

コマンドラインを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

3.2.3.1. シークレットの作成

OpenShift Container Platform クラスターに Secret オブジェクトを作成する必要があります。シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するためのクラウドプロバイダーの認証情報が保存されます。デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。

前提条件

  • Azure CLI ツールをインストールして設定している。

手順

  1. Azure サブスクリプション ID を取得します。

    $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
    Copy to Clipboard Toggle word wrap
  2. RBAC コンテンツを生成します。これにより、クライアント ID、クライアントシークレット、およびテナント ID が生成されます。

    $ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID --query "{ client_id: appId, client_secret: password, tenant_id: tenant }
    Copy to Clipboard Toggle word wrap

    出力例:

    {
      "client_id": `AZURE_CLIENT_ID`,
      "client_secret": `AZURE_CLIENT_SECRET`,
      "tenant_id": `AZURE_TENANT_ID`
    }
    Copy to Clipboard Toggle word wrap
  3. secret オブジェクトで使用する RBAC 出力を記録します。
  4. 次の例に従って peer-pods-secret.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      AZURE_CLIENT_ID: "<azure_client_id>" 
    1
    
      AZURE_CLIENT_SECRET: "<azure_client_secret>" 
    2
    
      AZURE_TENANT_ID: "<azure_tenant_id>" 
    3
    
      AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>" 
    4
    Copy to Clipboard Toggle word wrap
    1
    AZURE_CLIENT_ID 値を指定します。
    2
    AZURE_CLIENT_SECRET 値を指定します。
    3
    AZURE_TENANT_ID 値を指定します。
    4
    AZURE_SUBSCRIPTION_ID 値を指定します。
  5. マニフェストを適用して secret オブジェクトを作成します。

    $ oc apply -f peer-pods-secret.yaml
    Copy to Clipboard Toggle word wrap
注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon DaemonSet を再起動して変更を適用する必要があります。

シークレットを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

デーモンセットを再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

3.2.3.2. config map の作成

クラウドプロバイダーの OpenShift Container Platform クラスターに config map を作成する必要があります。

手順

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

    1. 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 を取得するために使用されます。

    2. 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
    3. 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
    4. 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
    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"
      AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 
    1
    
      AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 
    2
    
      AZURE_SUBNET_ID: "<azure_subnet_id>" 
    3
    
      AZURE_NSG_ID: "<azure_nsg_id>" 
    4
    
      PROXY_TIMEOUT: "5m"
      DISABLECVM: "true"
      AZURE_IMAGE_ID: "<azure_image_id>" 
    5
    
      AZURE_REGION: "<azure_region>" 
    6
    
      AZURE_RESOURCE_GROUP: "<azure_resource_group>" 
    7
    Copy to Clipboard Toggle word wrap
    1
    ワークロードでタイプが定義されていない場合に使用されるデフォルトのインスタンスサイズを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスサイズを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスサイズを定義したり、ワークロードが大きい場合は大きいインスタンスサイズを定義したりすることができます。
    3
    取得した AZURE_SUBNET_ID 値を指定します。
    4
    取得した AZURE_NSG_ID 値を指定します。
    5
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく Azure イメージ ID を使用して KataConfig CR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。
    6
    取得した AZURE_REGION 値を指定します。
    7
    取得した AZURE_RESOURCE_GROUP 値を指定します。
  3. マニフェストを適用して config map を作成します。

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

    クラウドプロバイダー用の config map が作成されます。

注記

ピア Pod config map を更新する場合、変更を適用するために peerpodconfig-ctrl-caa-daemon デーモンセットを再起動する必要があります。

config map を更新した後、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

daemonset を再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

3.2.3.3. SSH キーシークレットの作成

Azure の SSH キー secret オブジェクトを作成する必要があります。

手順

  1. OpenShift Container Platform クラスターにログインします。
  2. 次のコマンドを実行して、SSH キーペアを生成します。

    $ ssh-keygen -f ./id_rsa -N ""
    Copy to Clipboard Toggle word wrap
  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

    SSH キーシークレットが作成されます。

  4. 作成した SSH 鍵を削除します。

    $ shred -remove id_rsa.pub id_rsa
    Copy to Clipboard Toggle word wrap
3.2.3.4. KataConfig カスタムリソースの作成

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

KataConfig CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。

  • デフォルト設定で kata-remote という名前の RuntimeClass CR を作成します。これにより、RuntimeClassName フィールドの CR を参照して、kata-remote をランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。

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

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

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

手順

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

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      enablePeerPods: true
      logLevel: info
    Copy to Clipboard Toggle word wrap
  2. オプション: 選択したノードに kata-remote をインストールするには、次の例に従ってノードラベルを指定します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    選択したノードのラベルを指定します。
  3. KataConfig CR を作成します。

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

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

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

検証

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

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

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

詳細は、KataConfig ステータスメッセージ を参照してください。

3.2.3.4.1. オプション: 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 サポートケースを送信し、両方のログの出力を添付してください。

3.2.3.5. オプション: ノードあたりのピア 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. 次のコマンドを実行して、peerpodConfig CR の limit 属性を変更します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    --type merge --patch '{"spec":{"limit":"<value>"}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <value> は、定義する制限に置き換えます。
3.2.3.6. ワークロードオブジェクトの設定

次の Pod テンプレートされたオブジェクトのランタイムクラスとして kata-remote を設定して、OpenShift Sandboxed Containers のワークロードをデプロイします。

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

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

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの 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. 手動で定義されたインスタンスサイズまたは自動インスタンスサイズを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。

    • 手動で定義されたインスタンスサイズを使用するには、次のアノテーションを追加します。

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

      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

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

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

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

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

検証

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

第4章 IBM へのワークロードのデプロイ

OpenShift Sandboxed Containers のワークロードを IBM Z® および IBM® LinuxONE にデプロイできます。

重要

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

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

クラスターの前提条件

  • Red Hat OpenShift Container Platform 4.14 以降がインストールされている。
  • クラスターには 3 つのコントロールノードと 2 つのワーカーノードがある。

デプロイメントフロー

このドキュメントは IBM Z® のみを対象としていますが、すべての手順は IBM® LinuxONE にも適用されます。

次の手順を実行して、OpenShift Sandboxed Containers のワークロードをデプロイします。

  1. KVM ホストで libvirt ボリュームを設定します。
  2. KVM ゲストイメージを作成し、libvirt ボリュームにアップロードします。
  3. ピア Pod 仮想マシンイメージを作成し、libvirt ボリュームにアップロードします。
  4. libvirt プロバイダーのシークレットを作成します。
  5. libvirt プロバイダーの config map を作成します。
  6. KVM ホストの SSH キーシークレットを作成します。
  7. KataConfig CR を作成します。
  8. オプション: ノードごとのピア Pod 仮想マシン制限を変更します。
  9. kata-remote ランタイムクラスを使用するようにワークロードオブジェクトを設定します。
注記
  • クラスターノードとピア Pod は、同じ IBM Z® KVM ホスト論理パーティション (LPAR) 内に存在する必要があります。
  • クラスターノードとピア Pod は同じサブネットに接続されている必要があります。

4.1. 環境の準備

環境を準備するには、以下の手順を実行します。

  1. クラスターに十分なリソースがあることを確認します。
  2. OpenShift Sandboxed Containers Operator を再インストールします。

4.1.1. リソース要件

ピア 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 ノード拡張リソースとして定義されます。この制限はノードごとであり、peerpodConfig カスタムリソース (CR) の limit 属性によって設定されます。

peerpodconfig-openshift という名前の peerpodConfig CR は、kataConfig CR を作成してピア Pod を有効にするときに作成され、openshift-sandboxed-containers-operator namespace に配置されます。

次の peerpodConfig CR の例は、デフォルトの spec 値を示しています。

apiVersion: confidentialcontainers.org/v1alpha1
kind: PeerPodConfig
metadata:
  name: peerpodconfig-openshift
  namespace: openshift-sandboxed-containers-operator
spec:
  cloudSecretName: peer-pods-secret
  configMapName: peer-pods-cm
  limit: "10" 
1

  nodeSelector:
    node-role.kubernetes.io/kata-oc: ""
Copy to Clipboard Toggle word wrap
1
デフォルトの制限は、ノードごとに 10 VM です。

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

ご使用の環境の要件に基づいて、ノードごとの制限を編集できます。詳細は、「ピア Pod のノードごとの VM 制限の変更」を参照してください。

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 の作成を許可するクラスター全体のポリシーを定義します。

4.1.2. OpenShift Sandboxed Containers Operator のインストール

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

4.1.2.1. Web コンソールを使用した Operator のインストール

Red Hat OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
  3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
  4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
  5. Installed NamespaceOperator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

    注記

    OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

  6. Approval StrategyAutomatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
  7. Install をクリックします。

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  1. OperatorsInstalled Operators に移動します。
  2. OpenShift Sandboxed Containers Operator が表示されることを確認します。
4.1.2.2. CLI を使用した Operator のインストール

CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。

前提条件

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

手順

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

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

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

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

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

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-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.6.0
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、サブスクリプションを作成します。

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

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  • 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ 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.6.0    1.5.3        Succeeded
    Copy to Clipboard Toggle word wrap

4.2. コマンドラインを使用したワークロードの展開

コマンドラインを使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。

4.2.1. libvirt ボリュームの設定

KVM ホストに libvirt ボリュームを設定する必要があります。ピア Pod は、Cloud API アダプターの libvirt プロバイダーを使用して仮想マシンを作成および管理します。

前提条件

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

手順

  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=<target_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    libvirt に読み取りおよび書き込みアクセス権限があることを確認するには、libvirt ストレージディレクトリーのサブディレクトリーを使用します。デフォルトは /var/lib/libvirt/images/ です。
  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

4.2.2. KVM ゲストイメージの作成

KVM ゲストイメージを作成し、libvirt ボリュームにアップロードする必要があります。

前提条件

  • IBM z15 以降、または IBM® LinuxONE III 以降。
  • KVM を備えた RHEL 9 以降で実行している少なくとも 1 つの LPAR。

手順

  1. OpenShift Container Platform クラスターにログインします。
  2. RHEL サブスクリプションをお持ちの場合は、Red Hat Subscription Management のサブスクリプション環境変数を設定します。

    • 次のコマンドを実行して組織 ID を設定します。

      $ export ORG_ID=$(cat ~/.rh_subscription/orgid)
      Copy to Clipboard Toggle word wrap
    • 次のコマンドを実行してアクティベーションキーを設定します。

      $ export ACTIVATION_KEY=$(cat ~/.rh_subscription/activation_key)
      Copy to Clipboard Toggle word wrap
  3. RHEL サブスクリプションがない場合は、RHEL のサブスクリプション値を設定します。

    • 次のコマンドを実行して組織 ID を設定します。

      $ export ORG_ID=<RHEL_ORGID_VALUE> 
      1
      Copy to Clipboard Toggle word wrap
      1
      RHEL 組織 ID を指定します。
    • 次のコマンドを実行してアクティベーションキーを設定します。

      $ export ACTIVATION_KEY=<RHEL_ACTIVATION_KEY> 
      1
      Copy to Clipboard Toggle word wrap
      1
      RHEL アクティベーションキーを指定します。
  4. IBM Z® システムにログインします。
  5. libvirt に正しいアクセス権を付与するには、Red Hat カスタマーポータル から s390x RHEL KVM ゲストイメージを libvirt ストレージディレクトリーにダウンロードします。

    デフォルトのディレクトリーは /var/lib/libvirt/images です。このイメージは、関連するバイナリーを含むピア Pod 仮想マシンイメージを生成するために使用されます。

  6. 次のコマンドを実行して、ダウンロードしたイメージの IMAGE_URL を設定します。

    $ export IMAGE_URL=<path/to/image> 
    1
    Copy to Clipboard Toggle word wrap
    1
    KVM ゲストイメージのパスを指定します。
  7. 次のコマンドを実行して、ゲスト KVM イメージを登録します。

    $ export REGISTER_CMD="subscription-manager register --org=${ORG_ID} \
      --activationkey=${ACTIVATION_KEY}"
    Copy to Clipboard Toggle word wrap
  8. 次のコマンドを実行して、ゲスト KVM イメージをカスタマイズします。

    $ virt-customize -v -x -a ${IMAGE_URL} --run-command "${REGISTER_CMD}"
    Copy to Clipboard Toggle word wrap
  9. 次のコマンドを実行して、イメージのチェックサムを設定します。

    $ export IMAGE_CHECKSUM=$(sha256sum ${IMAGE_URL} | awk '{ print $1 }')
    Copy to Clipboard Toggle word wrap

4.2.3. ピア Pod 仮想マシンイメージのビルド

ピア Pod 仮想マシン (VM) イメージをビルドし、libvirt ボリュームにアップロードする必要があります。

手順

  1. OpenShift Container Platform クラスターにログインします。
  2. 以下のコマンドを実行して cloud-api-adaptor リポジトリーのクローンを作成します。

    $ git clone --single-branch https://github.com/confidential-containers/cloud-api-adaptor.git
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、podvm ディレクトリーに移動します。

    $ cd cloud-api-adaptor && git checkout 8577093
    Copy to Clipboard Toggle word wrap
  4. 最終的な QCOW2 イメージの生成元となるビルダーイメージを作成します。

    • サブスクライブしている RHEL システムがある場合は、次のコマンドを実行します。

      $ podman build -t podvm_builder_rhel_s390x \
        --build-arg ARCH="s390x" \
        --build-arg GO_VERSION="1.21.3" \
        --build-arg PROTOC_VERSION="25.1" \
        --build-arg PACKER_VERSION="v1.9.4" \
        --build-arg RUST_VERSION="1.72.0" \
        --build-arg YQ_VERSION="v4.35.1" \
        --build-arg YQ_CHECKSUM="sha256:4e6324d08630e7df733894a11830412a43703682d65a76f1fc925aac08268a45" \
        -f podvm/Dockerfile.podvm_builder.rhel .
      Copy to Clipboard Toggle word wrap
    • サブスクライブされていない RHEL システムがある場合は、以下のコマンドを実行します。

      $ podman build -t podvm_builder_rhel_s390x \
        --build-arg ORG_ID=$ORG_ID \
        --build-arg ACTIVATION_KEY=$ACTIVATION_KEY \
        --build-arg ARCH="s390x" \
        --build-arg GO_VERSION="1.21.3" \
        --build-arg PROTOC_VERSION="25.1" \
        --build-arg PACKER_VERSION="v1.9.4" \
        --build-arg RUST_VERSION="1.72.0" \
        --build-arg YQ_VERSION="v4.35.1" \
        --build-arg YQ_CHECKSUM="sha256:4e6324d08630e7df733894a11830412a43703682d65a76f1fc925aac08268a45" \
        -f podvm/Dockerfile.podvm_builder.rhel .
      Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、ピア Pod を実行するために必要なバイナリーを含む中間イメージパッケージを生成します。

    $ podman build -t podvm_binaries_rhel_s390x \
      --build-arg BUILDER_IMG="podvm_builder_rhel_s390x:latest" \
      --build-arg ARCH=s390x \
      -f podvm/Dockerfile.podvm_binaries.rhel .
    Copy to Clipboard Toggle word wrap

    このプロセスにはかなりの時間がかかります。

  6. 次のコマンドを実行して、バイナリーを抽出し、ピア Pod QCOW2 イメージを構築します。

    $ podman build -t podvm_rhel_s390x \
      --build-arg ARCH=s390x \
      --build-arg CLOUD_PROVIDER=libvirt \
      --build-arg BUILDER_IMG="localhost/podvm_builder_rhel_s390x:latest" \
      --build-arg BINARIES_IMG="localhost/podvm_binaries_rhel_s390x:latest" \
      -v ${IMAGE_URL}:/tmp/rhel.qcow2:Z \
      --build-arg IMAGE_URL="/tmp/rhel.qcow2" \
      --build-arg IMAGE_CHECKSUM=${IMAGE_CHECKSUM} \
      -f podvm/Dockerfile.podvm.rhel .
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、イメージディレクトリー環境変数を作成します。

    $ export IMAGE_OUTPUT_DIR=<image_output_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    イメージのディレクトリーを指定します。
  8. 次のコマンドを実行してイメージディレクトリーを作成します。

    $ mkdir -p $IMAGE_OUTPUT_DIR
    Copy to Clipboard Toggle word wrap
  9. 次のコマンドを実行して、展開したピア Pod QCOW2 イメージを保存します。

    $ podman save podvm_rhel_s390x | tar -xO --no-wildcards-match-slash '*.tar' | tar -x -C ${IMAGE_OUTPUT_DIR}
    Copy to Clipboard Toggle word wrap
  10. ピア Pod QCOW2 イメージを libvirt ボリュームにアップロードします。

    $ virsh -c qemu:///system vol-upload \
      --vol $LIBVIRT_VOL_NAME \
      $IMAGE_OUTPUT_DIR/podvm-*.qcow2 \
      --pool $LIBVIRT_POOL --sparse
    Copy to Clipboard Toggle word wrap

4.2.4. シークレットの作成

OpenShift Container Platform クラスターに Secret オブジェクトを作成する必要があります。

前提条件

  • LIBVIRT_POOL。KVM ホストで libvirt を設定したときに設定した値を使用します。
  • LIBVIRT_VOL_NAME。KVM ホストで libvirt を設定したときに設定した値を使用します。
  • 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}')
    Copy to Clipboard Toggle word wrap

手順

  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
    
      LIBVIRT_POOL: "<libvirt_pool>" 
    2
    
      LIBVIRT_VOL_NAME: "<libvirt_volume>" 
    3
    Copy to Clipboard Toggle word wrap
    1
    libvirt URI を指定します。
    2
    libvirt プールを指定します。
    3
    libvirt ボリューム名を指定します。
  2. マニフェストを適用して secret オブジェクトを作成します。

    $ oc apply -f peer-pods-secret.yaml
    Copy to Clipboard Toggle word wrap
注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon DaemonSet を再起動して変更を適用する必要があります。

シークレットを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

デーモンセットを再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

4.2.5. config map の作成

libvirt プロバイダー用に OpenShift Container Platform クラスター上に 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"
      PROXY_TIMEOUT: "15m"
    Copy to Clipboard Toggle word wrap
  2. マニフェストを適用して config map を作成します。

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

    libvirt プロバイダー用の config map が作成されます。

注記

ピア Pod config map を更新する場合、変更を適用するために peerpodconfig-ctrl-caa-daemon デーモンセットを再起動する必要があります。

config map を更新した後、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
Copy to Clipboard Toggle word wrap

daemonset を再起動すると、ピア Pod が再作成されます。既存の Pod は更新されません。

4.2.6. SSH キーシークレットの作成

KVM ホスト用に SSH 鍵の secret オブジェクトを作成する必要があります。

手順

  1. OpenShift Container Platform クラスターにログインします。
  2. 次のコマンドを実行して、SSH キーペアを生成します。

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

    $ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_IP>
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行して 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

    SSH キーシークレットが作成されます。

  5. 作成した SSH 鍵を削除します。

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

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

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

KataConfig CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。

  • デフォルト設定で kata-remote という名前の RuntimeClass CR を作成します。これにより、RuntimeClassName フィールドの CR を参照して、kata-remote をランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。

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

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

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

手順

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

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      enablePeerPods: true
      logLevel: info
    Copy to Clipboard Toggle word wrap
  2. オプション: 選択したノードに kata-remote をインストールするには、次の例に従ってノードラベルを指定します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    選択したノードのラベルを指定します。
  3. KataConfig CR を作成します。

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

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

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

検証

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

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

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

詳細は、KataConfig ステータスメッセージ を参照してください。

4.2.8. オプション: ノードあたりのピア 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. 次のコマンドを実行して、peerpodConfig CR の limit 属性を変更します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    --type merge --patch '{"spec":{"limit":"<value>"}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <value> は、定義する制限に置き換えます。

4.2.9. ワークロードオブジェクトの設定

次の Pod テンプレートされたオブジェクトのランタイムクラスとして kata-remote を設定して、OpenShift Sandboxed Containers のワークロードをデプロイします。

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

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

前提条件

  • プロバイダーのシークレットオブジェクトを作成している。
  • プロバイダーの config map を作成している。
  • KataConfig カスタムリソース (CR) を作成している。

手順

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

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
    Copy to Clipboard Toggle word wrap

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

検証

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

第5章 モニタリング

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

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

5.1. メトリクスについて

OpenShift Sandboxed Containers メトリックにより、管理者は Sandboxed Containers の実行状況を監視できます。OpenShift Container Platform Web コンソールのメトリクス UI でこれらのメトリクスを照会できます。

OpenShift Sandboxed Containers のメトリックは、次のカテゴリーで収集されます。

Kata エージェントの指標
カタエージェントメトリックには、Sandboxed Containers に埋め込まれた VM で実行しているカタエージェントプロセスに関する情報が表示されます。これらのメトリックには、/proc/<pid>/[io, stat, status] からのデータが含まれます。
Kata ゲストオペレーティングシステムのメトリクス
Kata ゲストのオペレーティングシステムメトリクスには、サンドボックス化されたコンテナーで実行しているゲストオペレーティングシステムのデータが表示されます。これらのメトリクスには、/proc/[stats, diskstats, meminfo, vmstats] および /proc/net/dev からのデータが含まれます。
ハイパーバイザーメトリック
ハイパーバイザーメトリックには、Sandboxed Containers に埋め込まれた仮想マシンを実行しているハイパーバイザーに関するデータが表示されます。これらのメトリックには、主に /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] からのデータと詳細なリソース使用メトリクスが含まれます。

5.2. メトリクスの表示

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

前提条件

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

手順

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

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

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

第6章 アンインストール

OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、OpenShift sandboxed containers をアンインストールできます。

ワークフローのアンインストール

  1. ワークロード Pod を削除します。
  2. KataConfig カスタムリソースを削除します。
  3. OpenShift Sandboxed Containers Operator をアンインストールします。
  4. KataConfig カスタムリソース定義を削除します。

6.1. Web コンソールを使用したアンインストール

OpenShift Container Platform Web コンソールを使用して OpenShift サンドボックスコンテナーをアンインストールできます。

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

OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers のワークロード Pod を削除できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Sandboxed Containers のランタイムクラスを使用する Pod のリストがあります。

手順

  1. OpenShift Container Platform Web コンソールで、WorkloadsPods に移動します。
  2. Search by name フィールドに、削除する Pod の名前を入力します。
  3. Pod 名をクリックして開きます。
  4. Details ページで、Runtime classkata または kata-remote が表示されていることを確認します。
  5. Options メニュー kebab をクリックし、Delete Pod を選択します。
  6. Delete をクリックします。

6.1.2. KataConfig CR の削除

Web コンソールを使用して、KataConfig カスタムリソース (CR) を削除できます。KataConfig CR を削除すると、kata ランタイムと関連リソースがクラスターから削除され、アンインストールされます。

重要

KataConfig CR を削除すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • kataruntimeClass として使用する実行中の Pod がすべて削除されている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. Search by name フィールドを使用して、OpenShift Sandboxed Containers Operator を検索します。
  3. Operator をクリックして開き、KataConfig タブを選択します。
  4. KataConfig リソースの Options メニュー kebab をクリックし、Delete KataConfig を選択します。
  5. 確認ウィンドウで Delete をクリックします。

kata ランタイムとリソースがアンインストールされ、ワーカーノードが再起動されるまで待ってから、次の手順に進みます。

6.1.3. Operator のアンインストール

OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をアンインストールできます。Operator をアンインストールすると、その Operator のカタログサブスクリプション、Operator グループ、およびクラスターサービスバージョン (CSV) が削除されます。次に、openshift-sandboxed-containers-Operator namespace を削除します。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. Search by name フィールドに、OpenShift Sandboxed Containers Operator 名を入力します。
  3. Operator の Options メニュー kebab をクリックし、Uninstall Operator を選択します。
  4. 確認ウィンドウで Uninstall をクリックします。
  5. Search by name フィールドに openshift-sandboxed-containers-Operator の名前を入力します。
  6. namespace の Options メニュー kebab をクリックし、Delete Namespace を選択します。

    注記

    Delete Namespace オプションが選択できない場合には、namespace を削除するパーミッションがありません。

  7. Delete Namespace ウィンドウで、openshift-sandboxed-containers-operator と入力し、Delete をクリックします。
  8. Delete をクリックします。

6.1.4. KataConfig CRD の削除

OpenShift Container Platform Web コンソールを使用して、KataConfig カスタムリソース定義 (CRD) を削除できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • KataConfig CR が削除されている。
  • OpenShift Sandboxed Containers Operator をアンインストールしている。

手順

  1. Web コンソールで、AdministrationCustomResourceDefinitions に移動します。
  2. Search by name フィールドに KataConfig 名を入力します。
  3. KataConfig CRD の Options メニュー kebab をクリックし、Delete CustomResourceDefinition を選択します。
  4. 確認ウィンドウで Delete をクリックします。
  5. KataConfig CRD がリストから消えるまで待ちます。これには数分の時間がかかる場合があります。

6.2. CLI を使用したアンインストール

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

6.2.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' 
    1
    Copy to Clipboard Toggle word wrap
    1
    ベアメタルデプロイメントの場合は kata を指定します。パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合は kata-remote を指定します。
  2. 次のコマンドを実行して、各 Pod を削除します。

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

6.2.2. KataConfig CR の削除

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

KataConfig CR を削除すると、ランタイムと関連リソースがクラスターから削除されます。

重要

KataConfig CR を削除すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

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

手順

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

    $ oc delete kataconfig <kataconfig>
    Copy to Clipboard Toggle word wrap

    OpenShift Sandboxed Containers Operator は、クラスターでランタイムを有効化するために初期に作成されていたリソースをすべて削除します。

検証

KataConfig CR を削除すると、すべてのワーカーノードが再起動するまで CLI は応答を停止します。検証を実行する前に、削除プロセスを完了する必要があります。

  • KataConfig カスタムリソースが削除されたことを確認するには、以下のコマンドを実行します。

    $ oc get kataconfig <kataconfig>
    Copy to Clipboard Toggle word wrap

    出力例

    No KataConfig instances exist
    Copy to Clipboard Toggle word wrap

6.2.3. Operator のアンインストール

CLI を使用して、OpenShift Sandboxed Containers Operator をアンインストールできます。Operator をアンインストールするには、Operator サブスクリプション、Operator グループ、クラスターサービスバージョン (CSV)、および namespace を削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • コマンドライン JSON プロセッサー (jq) をインストールしました。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 次のコマンドを実行して、サブスクリプションから OpenShift Sandboxed Containers のクラスターサービスバージョン (CSV) 名を取得します。

    CSV_NAME=$(oc get csv -n openshift-sandboxed-containers-operator -o=custom-columns=:metadata.name)
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Operator Lifecyle Manager (OLM) から Operator サブスクリプションを削除します。

    $ oc delete subscription sandboxed-containers-operator -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  3. 以下のコマンドを実行して、OpenShift Sandboxed Containers の CSV 名を削除します。

    $ oc delete csv ${CSV_NAME} -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、Operator グループ名を取得します。

    $ OG_NAME=$(oc get operatorgroup -n openshift-sandboxed-containers-operator -o=jsonpath={..name})
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、Operator グループ名を削除します。

    $ oc delete operatorgroup ${OG_NAME} -n openshift-sandboxed-containers-operator
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、Operator namespace を削除します。

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

6.2.4. KataConfig CRD の削除

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

前提条件

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

手順

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

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

検証

  • KataConfig CRD が削除されたことを確認するには、次のコマンドを実行します。

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

    出力例

    Unknown CR KataConfig
    Copy to Clipboard Toggle word wrap

第7章 アップグレード

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

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

以下に示す 1 つの例外を除いて、OpenShift サンドボックスコンテナー Operator のアップグレードの前または後に OpenShift Container Platform をアップグレードできます。OpenShift Sandboxed Containers Operator をアップグレードした直後に、常に KataConfig パッチを適用します。

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

OpenShift Sandboxed Containers アーティファクトは、Red Hat Enterprise Linux CoreOS (RHCOS) 拡張機能を使用してクラスターにデプロイされます。

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

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

7.2. Operator のアップグレード

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

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

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

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

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

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

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

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

迅速なサポートのために、OpenShift Container Platform と OpenShift サンドボックスコンテナーの両方の診断情報を提供してください。

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.6.0
    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.6.0
Copy to Clipboard Toggle word wrap

8.2. ログデータの収集

次の機能とオブジェクトは、OpenShift サンドボックスコンテナーに関連付けられています。

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

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

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

8.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

8.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 ステータスメッセージ
Status説明

Initial installation

KataConfig CR が作成され、両方のワーカーに kata のインストールが開始されると、次のステータスが数秒間表示されます。

 conditions:
    message: Performing initial installation of kata 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 のインストールを開始し、他方のノードが待機状態であることを示します。これは、常に 1 つのノードだけが使用不能になる可能性があるためです。両方のノードが最終的に kata を受信するため、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 ワークロードを実行する準備ができたことを示します。インストールプロセスの最後にランタイムクラスが作成されるまで、kata ワークロードのスケジュールや実行はできません。

 kataNodes:
   installed:
   - worker-1
   installing:
   - worker-0
   nodeCount: 2
   readyNodeCount: 1
Copy to Clipboard Toggle word wrap

Installed

インストールされると、両方のワーカーがインストール済みとしてリストされ、理由を指定せずに InProgress 条件が False に移行し、クラスターへの kata のインストールが成功したことを示します。

 conditions:
    message: ""
    reason: ""
    status: 'False'
    type: InProgress
 kataNodes:
   installed:
   - worker-0
   - worker-1
   nodeCount: 2
   readyNodeCount: 2
Copy to Clipboard Toggle word wrap
Expand
Status説明

Initial uninstall

kata が両方のワーカーにインストールされていて、KataConfig を削除してクラスターから kata を削除すると、両方のワーカーが数秒間待機状態になります。

 conditions:
    message: Removing kata 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 のアンインストール中に kata ランタイムを使用するクラスター上で実行している Pod がある場合に報告されます。status フィールドは False で、messageExisting pods using "kata" RuntimeClass found.Please delete the pods manually for KataConfig deletion to proceed です。クラスターコントロールプレーンとの通信が失敗した場合は、Failed to list kata pods: <error_message> のような技術的なエラーメッセージが報告される場合もあります。

法律上の通知

Copyright © 2024 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