OpenShift 向けのサンドボックスコンテナーのサポート
OpenShift サンドボックスコンテナーガイド
概要
第1章 {sandboxed-containers-first} 1.1 リリースノート リンクのコピーリンクがクリップボードにコピーされました!
1.1. 本リリースについて リンクのコピーリンクがクリップボードにコピーされました!
これらのリリースノートは、Red Hat OpenShift Container Platform 4.9 とともに OpenShift サンドボックスコンテナー 1.1 の開発を追跡します。
この製品は現在テクノロジープレビューとして提供されています。OpenShift サンドボックスコンテナーは、実稼働環境での使用を目的としていません。詳細は、テクノロジープレビューの機能に関する Red Hat カスタマーポータルの サポート範囲 を参照してください。
1.2. 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
1.2.1. FIPS 互換性 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーでは、FIPS モードが自動的に有効になっています。FIPS モードでインストールされた OpenShift Container Platform クラスターにデプロイされた OpenShift サンドボックスコンテナーは、クラスターの FIPS サポートをテイントしません。詳細は、コンプライアンスとリスク管理について を参照してください。
1.2.2. must-gather でのリソース収集 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナー Operator には、must-gather イメージが含まれるようになり、診断目的で、この Operator および基盤となるランタイムコンポーネントに固有のカスタムリソースとログファイルを収集できます。詳細は、Red Hat サポート用の OpenShift サンドボックスコンテナーデータの収集 を参照してください。
1.2.3. 非接続環境 リンクのコピーリンクがクリップボードにコピーされました!
非接続環境に OpenShift サンドボックスコンテナー Operator をインストールできるようになりました。詳細は、OpenShift サンドボックスコンテナーワークロードをデプロイするための追加リソース を参照してください。
1.3. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
- 以前のリリースでは、OpenShift サンドボックス化されたコンテナー上で Fedora を実行する場合には、デフォルトで OpenShift Container Platform がコンテナーに割り当てていないファイルのアクセスパーミッションを、パッケージによっては変更する必要がありました。今回のリリースでは、これらの権限がデフォルトで付与されています。(BZ#1915377)
-
以前は、OpenShift Container Platform Web コンソールで
kataConfgPoolSelectorに値を追加すると、空の値でScheduling.nodeSelectorに入力されました。その結果、値がkataのRuntimeClassオブジェクトを使用する Pod は、Kata Containers ランタイムがインストールされていないノードにスケジュールされる可能性がありました。このリリースでは、kataConfigPoolSelectorで定義されているものと同じラベルが付いたノードのみが Kata Containers ランタイムをインストールします。(BZ#2019384) - 以前のリリースには、Operator Hub の OpenShift サンドボックスコンテナー Operator の詳細ページにフィールドがありませんでした。今回のリリースでは、これらのフィールドが追加されています。(BZ#2019383)
-
以前のリリースでは、複数の
KataConfigカスタムリソースを作成すると、OpenShift Container Platform Web コンソールから複数のカスタムリソース作成に失敗した旨を通知するエラーなしに失敗していました。今回のリリースでは、ユーザーが複数のカスタムリソースを作成しようとするとエラーが発生します。(BZ#2019381) - 以前のリリースでは、OpenShift Container Platform Web コンソールの Operator Hub に Operator のアイコンが表示されない場合がありました。今回のリリースでは、アイコンは常に表示されます。(BZ#9019380)
1.4. 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーを使用している場合に、OpenShift Container Platform クラスターの
hostPathボリュームからマウントされているファイルまたはディレクトリーへのアクセスを SELinux が拒否することがありました。特権サンドボックスコンテナーは SELinux チェックを無効にしないため、特権サンドボックスコンテナーを実行している場合でも、このように拒否される可能性があります。ホストで SELinux ポリシーに準拠すると、ホストファイルシステムとサンドボックスのワークロードを完全に分離して、
virtiofsdまたは QEMU で発生する可能性のあるセキュリティーの脆弱性に対してより強力に保護します。マウントされたファイルまたはディレクトリーにホスト上の特定の SELinux 要件がない場合は、代わりにローカル永続ボリュームを使用できます。ファイルは、コンテナーランタイムの SELinux ポリシーに従って、自動的に
container_file_tに再ラベル付けされます。詳細は ローカルボリュームを使用した永続ストレージ を参照してください。マウントされたファイルまたはディレクトリーがホスト上で特定の SELinux ラベルを持つことが予想される場合、自動再ラベル付けはオプションではありません。代わりに、ホストでカスタム SELinux ルールを設定して、virtiofsd がこれらの特定のラベルにアクセスできるようにします。(BZ#1904609)
1.5. エラータの非同期更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナー 4.9 のセキュリティー、バグ修正、および拡張機能の更新は、Red Hat Network を通じて非同期エラータとして発表されます。OpenShift Container Platform 4.9 のすべてのエラータは Red Hat カスタマーポータルから入手 できます。非同期エラータについては、OpenShift Container Platform ライフサイクル を参照してください。
Red Hat カスタマーポータルのユーザーは、Red Hat Subscription Management (RHSM) のアカウント設定でエラータの通知を有効にすることができます。エラータの通知を有効にすると、登録しているシステムに関連するエラータが新たに発表されるたびに、メールで通知が送信されます。
OpenShift Container Platform のエラータ通知メールを生成させるには、Red Hat カスタマーポータルのユーザーアカウントでシステムが登録されており、OpenShift Container Platform エンタイトルメントを使用している必要があります。
以下のセクションは、これからも継続して更新され、今後の OpenShift sandboxed containers 1.1.0 の非同期リリースで発表されるエラータの拡張機能およびバグ修正に関する情報を追加していきます。
1.5.1. RHEA-2021:3941 - OpenShift サンドボックスコンテナー 1.1.0 イメージのリリース、バグ修正、機能強化のアドバイザリー リンクのコピーリンクがクリップボードにコピーされました!
発行日: 2021-10-21
OpenShift サンドボックスコンテナーリリース 1.1.0 が利用可能になりました。このアドバイザリーには、機能強化とバグ修正を含む OpenShift サンドボックスコンテナーの更新が含まれています。
更新に含まれるバグ修正の一覧は、RHEA-2021:3941 アドバイザリーに記載されています。
第2章 OpenShift サンドボックスコンテナーについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の OpenShift サンドボックスコンテナーがサポートされることで、追加のオプションランタイムとして、Kata Container を実行するビルドインサポートが追加されます。これは、以下のタスクを実行するユーザーに特に便利です。
- 特権または信頼できないワークロードを実行する。
- 各ワークロードのカーネルを確実に分離する。
- テナント全体で同じワークロードを共有する。
- ソフトウェアのテストに適した分離とサンドボックスがあることを確認する。
- 仮想マシン境界を使用して、デフォルトのリソースに含まれるようにする。
OpenShift サンドボックスコンテナーには、さまざまなユースケースに対応するために実行するワークロードのタイプから選択する機能も含まれます。
OpenShift サンドボックスコンテナー Operator を使用して、インストール、削除、更新、ステータスの監視などのタスクを実行できます。
サンドボックスコンテナーは、ベアメタルでのみサポートされます。
Red Hat Enterprise Linux CoreOS (RHCOS) は、OpenShift サンドボックスコンテナー 1.0.0 で唯一サポートされているオペレーティングシステムです。
2.1. OpenShift サンドボックスコンテナーの一般的な用語 リンクのコピーリンクがクリップボードにコピーされました!
以下の用語は、本書全体で使用されています。
- サンドボックス
サンドボックスとは、プログラムが実行可能な分離された環境のことです。サンドボックスでは、ホストマシンやオペレーティングシステムに悪影響を及ぼすことなく、テストされていないプログラムまたは信頼できないプログラムを実行できます。
OpenShift サンドボックスコンテナーのコンテキストでは、仮想化を使用して異なるカーネルでワークロードを実行し、同じホストで実行される複数のワークロードとの間の対話を強化することでサンドボックスを実現します。
- Pod
Pod は Kubernetes および OpenShift Container Platform から継承されるコンストラクトです。Pod とは、コンテナーのデプロイが可能なリソースを表します。コンテナーは Pod 内で実行され、Pod を使用して複数のコンテナー間で共有できるリソースを指定します。
OpenShift サンドボックスコンテナーのコンテキストでは、Pod が仮想マシンとして実装されます。同じ仮想マシンにある同じ Pod でコンテナーを複数実行できます。
- OpenShift サンドボックスコンテナー Operator
Operator は、人間のオペレーターがシステムで実行できるアクション、つまり操作を自動化するソフトウェアコンポーネントです。
OpenShift サンドボックスコンテナー Operator は、クラスター上でサンドボックスコンテナーのライフサイクルを管理してタスクを実行します。これは、サンドボックスコンテナーソフトウェアおよびステータスの監視などの操作を処理します。
- Kata Container
- Kata Container は OpenShift サンドボックスコンテナーの構築に使用されるコアアップストリームプロジェクトです。OpenShift サンドボックスコンテナーは Kata Container と OpenShift Container Platform を統合します。
- KataConfig
-
KataConfigオブジェクトはサンドボックスコンテナーの設定を表します。ソフトウェアのデプロイ先のノードなど、クラスターの状態に関する情報を保存します。 - RHCOS 拡張機能
- Red Hat Enterprise Linux CoreOS (RHCOS) 拡張機能は、オプションの OpenShift Container Platform ソフトウェアをインストールするメカニズムです。OpenShift サンドボックスコンテナー Operator はこのメカニズムを使用して、サンドボックスコンテナーをクラスターにデプロイします。
- ランタイムクラス
-
RuntimeClassオブジェクトは、指定のワークロード実行に使用可能なランタイムを記述します。kataという名前のランタイムクラスは、OpenShift のサンドボックスコンテナー Operator によってインストールされ、デプロイされます。ランタイムクラスには、ランタイムが Pod オーバーヘッド など、動作に必要なリソースを記述するランタイムに関する情報が含まれます。
2.2. OpenShift サンドボックスコンテナーのビルディングブロック リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックス化されたコンテナー Operator は、Kata Container からのコンポーネントをすべてカプセル化します。インストール、ライフサイクル、設定タスクを管理します。
OpenShift サンドボックスコンテナー Operator は、2 つのコンテナーイメージとして Operator バンドル形式 でパッケージ化されています。バンドルイメージにはメタデータが含まれ、Operator で OLM が利用できるようにする必要があります。2 つ目のコンテナーイメージには、KataConfig リソースを監視および管理するための実際のコントローラーが含まれています。
2.3. RHCOS 拡張機能 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナー Operator は Red Hat Enterprise Linux CoreOS (RHCOS) 拡張機能の概念に基づいています。サンドボックスコンテナーの RHCOS 拡張には、Kata、QEMU、およびその依存関係の RPM が含まれます。これらは、Machine Config Operator が提供する MachineConfig リソースを使用して有効にできます。
2.4. コンプライアンスおよびリスク管理について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーは、FIPS 対応クラスターで使用できます。
FIPS モードで実行している場合、OpenShift サンドボックスコンテナーコンポーネント、仮想マシン、および VM イメージは、FIPS に準拠するように調整されます。
FIPS コンプライアンスは、安全な環境で必要とされる最も重要なコンポーネントの 1 つであり、サポートされている暗号化技術のみがノード上で許可されるようにします。
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64 アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。
OpenShift Container Platform コンプライアンスフレームワークについての Red Hat のアプローチについては、OpenShift セキュリティーガイド のリスク管理および規制対応の章を参照してください。
第3章 OpenShift サンドボックスコンテナーワークロードのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールまたは OpenShift CLI (oc) のいずれかを使用して OpenShift サンドボックスコンテナー Operator をインストールできます。OpenShift サンドボックスコンテナー Operator をインストールする前に、OpenShift Container Platform クラスターを準備する必要があります。
3.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーをインストールする前に、OpenShift Container Platform クラスターが以下の要件を満たしていることを確認してください。
クラスターは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーを備えたオンプレミスのベアメタルインフラストラクチャーにインストールする必要があります。
重要- OpenShift サンドボックスコンテナーは RHCOS ワーカーノードのみをサポートします。RHEL ノードはサポートされていません。
- ネストされた仮想化はサポートされていません。
3.1.1. OpenShift サンドボックスコンテナーのリソース要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーを使用すると、ユーザーはサンドボックスランタイム (Kata) 内の OpenShift Container Platform クラスターでワークロードを実行できます。各 Pod は仮想マシン (VM) で表されます。各仮想マシンは QEMU プロセスで実行され、コンテナーワークロードおよびこれらのコンテナーで実行されているプロセスを管理するためのスーパーバイザーとして機能する kata-agent プロセスをホストします。2 つのプロセスを追加すると、オーバーヘッドがさらに増加します。
-
containerd-shim-kata-v2。これは Pod との通信に使用されます。 -
virtiofsd。これはゲストの代わりにホストファイルシステムのアクセスを処理します。
各仮想マシンには、デフォルトのメモリー容量が設定されます。コンテナーでメモリーが明示的に要求された場合に、メモリーが追加で仮想マシンにホットプラグされます。
メモリーリソースなしで実行されているコンテナーは、仮想マシンによって使用される合計メモリーが既定の割り当てに達するまで、空きメモリーを消費します。ゲストやその I/O バッファーもメモリーを消費します。
コンテナーに特定のメモリー量が指定されている場合には、コンテナーが起動する前に、メモリーが仮想マシンにホットプラグされます。
メモリー制限が指定されている場合には、上限より多くメモリーが消費された場合に、ワークロードが終了します。メモリー制限が指定されていない場合、仮想マシンで実行されているカーネルがメモリー不足になる可能性があります。カーネルがメモリー不足になると、仮想マシン上の他のプロセスが終了する可能性があります。
デフォルトのメモリーサイズ
以下の表は、リソース割り当てのデフォルト値を示しています。
| リソース | Value |
|---|---|
| デフォルトで仮想マシンに割り当てられるメモリー | 2Gi |
| 起動時のゲスト Linux カーネルのメモリー使用量 | ~110Mi |
| QEMU プロセスで使用されるメモリー (仮想マシンメモリーを除く) | ~30Mi |
|
| ~10Mi |
|
| ~20Mi |
|
Fedora で | ~300Mi* [1] |
ファイルバッファーが表示され、このバッファーは以下の複数の場所に考慮されます。
- ファイルバッファーキャッシュとして表示されるゲスト。
-
許可されたユーザー空間ファイルの I/O 操作をマッピングする
virtiofsdデーモン。 - ゲストメモリーとして使用される QEMU プロセス。
メモリー使用量の合計は、メモリー使用率メトリクスによって適切に考慮され、そのメモリーを 1 回だけカウントします。
Pod のオーバーヘッド では、ノード上の Pod が使用するシステムリソースの量を記述します。以下のように、oc describe runtimeclass kata を使用して、Kata ランタイムクラスの現在の Pod オーバーヘッドを取得できます。
例
$ oc describe runtimeclass kata
出力例
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
RuntimeClass の spec.overhead フィールドを変更して、Pod のオーバーヘッドを変更できます。たとえば、コンテナーに対する設定が QEMU プロセスおよびゲストカーネルデータでメモリー 350Mi 以上を消費する場合に、RuntimeClass のオーバーヘッドをニーズに合わせて変更できます。
Red Hat では、指定のデフォルトオーバーヘッド値がサポートされます。デフォルトのオーバーヘッド値の変更はサポートされておらず、値を変更すると技術的な問題が発生する可能性があります。
ゲストで種類にかかわらず、ファイルシステム I/O を実行すると、ファイルバッファーがゲストカーネルに割り当てられます。ファイルバッファーは、virtiofsd プロセスだけでなく、ホスト上の QEMU プロセスでもマッピングされます。
たとえば、ゲストでファイルバッファーキャッシュ 300Mi を使用すると、QEMU と virtiofsd の両方が、追加で 300Mi を使用するように見えます。ただし、3 つのケースすべてで同じメモリーが使用されています。つまり、メモリーの合計使用量は 300Mi のみで、このメモリー量が 3 つの異なる場所にマッピングされています。これは、メモリー使用量メトリクスの報告時に適切に考慮されます。
3.2. Web コンソールを使用した OpenShift サンドボックスコンテナーワークロードのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから OpenShift サンドボックスコンテナーのワークロードをデプロイできます。まず、OpenShift サンドボックスコンテナー Operator をインストールしてから、KataConfig カスタムリソース (CR) を作成する必要があります。サンドボックスコンテナーにワークロードをデプロイする準備ができたら、ワークロード YAML ファイルに kata を runtimeClassName として手動で追加する必要があります。
3.2.1. Web コンソールを使用した OpenShift サンドボックスコンテナー Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールから OpenShift サンドボックスコンテナー Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.9 がインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
- Web コンソールの Administrator パースペクティブで、Operators → OperatorHub に移動します。
-
Filter by keyword フィールドに
OpenShift sandboxed containersと入力します。 - OpenShift sandboxed containers タイルを選択します。
- Operator についての情報を確認してから、Install をクリックします。
Install Operator ページで以下を行います。
- 利用可能な Update Channel オプションから preview-1.1 を選択します。
Installed Namespace で Operator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の
openshift-sandboxed-containers-operatornamespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。注記OpenShift サンドボックスコンテナー Operator を
openshift-sandboxed-containers-operator以外の namespace にインストールしようとすると、インストールが失敗します。- Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift サンドボックスコンテナーへの自動更新が有効になります。
- Install をクリックします。
これで、OpenShift サンドボックスコンテナー Operator がクラスターにインストールされました。
検証
- Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- OpenShift サンドボックスコンテナー Operator が in オペレーターリストにリストされていることを確認します。
3.2.2. Web コンソールで KataConfig カスタムリソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードに kata を RuntimeClass としてインストールできるようにするには、1 つの KataConfig カスタムリソース (CR) を作成する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.9 をインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift サンドボックスコンテナー Operator をインストールしました。
Kata は、デフォルトですべてのワーカーノードにインストールされます。特定のノードにのみ kata を RuntimeClass としてインストールする場合は、それらのノードにラベルを追加し、作成時に KataConfig CR でラベルを定義できます。
手順
- Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- オペレーターのリストから OpenShift サンドボックスコンテナーオペレーターを選択します。
- KataConfig タブで、Create KataConfig をクリックします。
-
Create KataConfig ページで、YAML view 経由で
KataConfigCR を設定することを選択します。 次のマニフェストをコピーして YAML view に貼り付けます。
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig選択したノードにのみ
kataをRuntimeClassとしてインストールする場合は、マニフェストにラベルを含めます。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>'1 - 1
kataConfigPoolSelectorのラベルは単一値のみをサポートします。nodeSelector構文はサポートされていません。
- Create をクリックします。
新しい KataConfig CR が作成され、ワーカーノードに kata を RuntimeClass としてインストールし始めます。
OpenShift サンドボックスコンテナーは、Kata を主なランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてのみインストールします。
検証
-
KataConfig タブで、新しい
KataConfigCR を選択します。 - KataConfig ページで、YAML タブを選択します。
ステータスの installationStatus フィールドをモニターします。
更新があるたびにメッセージが表示されます。リロード をクリックして、更新された
KataConfigCR を表示します。Completed nodes の値がワーカーまたはラベル付けされたノードの数と等しくなると、インストールは完了です。ステータスには、インストールが完了したノードの一覧も含まれます。
3.2.3. Web コンソールを使用してサンドボックスコンテナーにワークロードをデプロイする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーは、Kata を主なランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてインストールします。
Pod テンプレート化されたワークロードをサンドボックスコンテナーにデプロイするには、kata を runtimeClassName としてワークロード YAML ファイルに手動で追加する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.9 をインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift サンドボックスコンテナー Operator をインストールしました。
-
KataConfigカスタムリソース (CR) を作成しました。
手順
- Web コンソールの Administrator パースペクティブから、Workloads をデプロイメントし、作成するワークロードのタイプを選択します。
- ワークロードページで、をクリックしてワークロードを作成します。
ワークロードの YAML ファイルで、コンテナーがリストされている spec フィールドに、
runtimeClassName: kataを追加します。Pod の例
apiVersion: v1 kind: Pod metadata: name: example labels: app: httpd namespace: openshift-sandboxed-containers-operator spec: runtimeClassName: kata containers: - name: httpd image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest' ports: - containerPort: 8080デプロイメントの例
apiVersion: apps/v1 kind: Deployment metadata: name: example namespace: openshift-sandboxed-containers-operator spec: selector: matchLabels: app: httpd replicas: 3 template: metadata: labels: app: httpd spec: runtimeClassName: kata containers: - name: httpd image: >- image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest ports: - containerPort: 8080- Save をクリックします。
OpenShift Container Platform はワークロードを作成し、スケジューリングを開始します。
3.3. CLI を使用した OpenShift サンドボックスコンテナーワークロードのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して、OpenShift サンドボックスコンテナーのワークロードをデプロイできます。まず、OpenShift サンドボックスコンテナー Operator をインストールしてから、KataConfig カスタムリソースを作成する必要があります。サンドボックスコンテナーにワークロードをデプロイする準備ができたら、ワークロード YAML ファイルに runtimeClassName として kata を追加する必要があります。
3.3.1. CLI を使用したサンドボックスコンテナー Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform CLI から OpenShift サンドボックスコンテナー Operator をインストールできます。
前提条件
- クラスターに OpenShift Container Platform 4.9 がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 OpenShift サンドボックスコンテナーカタログにサブスクライブしている。
注記OpenShift サンドボックスコンテナーカタログにサブスクライブすると、
openshift-sandboxed-containers-operatornamespace の OpenShift サンドボックスコンテナー Operator にアクセスできるようになります。
手順
OpenShift サンドボックスコンテナー Operator の
Namespaceオブジェクトを作成します。次のマニフェストを含む
Namespaceオブジェクト YAML ファイルを作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operatorNamespaceオブジェクトを作成します。$ oc create -f Namespace.yaml
OpenShift サンドボックスコンテナー Operator の
OperatorGroupオブジェクトを作成します。次のマニフェストを含む
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-operatorOperatorGroupオブジェクトを作成します。$ oc create -f OperatorGroup.yaml
Subscriptionオブジェクトを作成して、Namespaceを OpenShift サンドボックスコンテナー Operator にサブスクライブします。次のマニフェストを含む
Subscriptionオブジェクト YAML ファイルを作成します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: channel: "preview-1.1" installPlanApproval: Automatic name: sandboxed-containers-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: sandboxed-containers-operator.v1.1.0Subscriptionオブジェクトを作成します。$ oc create -f Subscription.yaml
これで、OpenShift サンドボックスコンテナー Operator がクラスターにインストールされました。
上記のオブジェクトファイル名はすべて提案です。他の名前を使用してオブジェクト YAML ファイルを作成できます。
検証
Operator が正常にインストールされていることを確認します。
$ oc get csv -n openshift-sandboxed-containers-operator出力例
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.1.0 1.0.2 Succeeded
3.3.2. CLI を使用して KataConfig カスタムリソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
kata を RuntimeClass としてノードにインストールするには、1 つの KataConfig カスタムリソース (CR) を作成する必要があります。KataConfig CR を作成すると、OpenShift サンドボックス化されたコンテナー Operator がトリガーされ、以下が実行されます。
-
QEMU および
kata-containersなど、必要な RHCOS 拡張を RHCOS ノードにインストールします。 -
ランタイム CRI-O が正しい
kataランタイムハンドラーで設定されていることを確認します。 -
デフォルト設定で
kataという名前のRuntimeClassCR を作成します。これにより、ユーザーは、RuntimeClassNameフィールドで CR を参照することにより、kataをランタイムとして使用するようにワークロードを設定できます。この CR は、ランタイムのリソースオーバーヘッドも指定します。
Kata は、デフォルトですべてのワーカーノードにインストールされます。特定のノードにのみ kata を RuntimeClass としてインストールする場合は、それらのノードにラベルを追加し、作成時に KataConfig CR でラベルを定義できます。
前提条件
- クラスターに OpenShift Container Platform 4.9 をインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift サンドボックスコンテナー Operator をインストールしました。
手順
次のマニフェストで YAML ファイルを作成します。
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig(オプション) 選択したノードにのみ
kataをRuntimeClassとしてインストールする場合は、マニフェストにラベルを含む YAML ファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>'1 - 1
kataConfigPoolSelectorのラベルは単一値のみをサポートします。nodeSelector構文はサポートされていません。
KataConfigリソースを作成します。$ oc create -f <file name>.yaml
新しい KataConfig CR が作成され、ワーカーノードに kata を RuntimeClass としてインストールし始めます。
OpenShift サンドボックスコンテナーは、Kata を主なランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてのみインストールします。
検証
インストールの進捗を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"Is In Progress の値が
falseと表示されたら、インストールは完了です。
3.3.3. CLI を使用してサンドボックスコンテナーにワークロードをデプロイする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーは、Kata を主なランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてインストールします。
Pod テンプレート化されたワークロードをサンドボックスコンテナーにデプロイするには、ワークロード YAML ファイルに runtimeClassName として kata を追加する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.9 をインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift サンドボックスコンテナー Operator をインストールしました。
-
KataConfigカスタムリソース (CR) を作成しました。
手順
任意の Pod テンプレートオブジェクトに
runtimeClassName: kataを追加します。-
Podオブジェクト -
ReplicaSetオブジェクト -
ReplicationControllerオブジェクト -
StatefulSetオブジェクト -
Deploymentオブジェクト -
DeploymentConfigオブジェクト
-
Pod オブジェクトの例
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: kata
Deployment オブジェクトの例
apiVersion: apps/v1
kind: Deployment
metadata:
name: mypod
labels:
app: mypod
spec:
replicas: 3
selector:
matchLabels:
app: mypod
template:
metadata:
labels:
app: mypod
spec:
runtimeClassName: kata
containers:
- name: mypod
image: myImage
OpenShift Container Platform はワークロードを作成し、スケジューリングを開始します。
検証
-
Pod テンプレートオブジェクトの
runtimeClassNameフィールドを調べます。runtimeClassNameがkataの場合、ワークロードは OpenShift サンドボックスコンテナーで実行されています。
第4章 OpenShift サンドボックスコンテナーのアンインストール リンクのコピーリンクがクリップボードにコピーされました!
4.1. Web コンソールを使用した OpenShift サンドボックスコンテナーのアンインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して OpenShift サンドボックスコンテナーをアンインストールできます。
4.1.1. OpenShift サンドボックスコンテナーリソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーをアンインストールするには、まず OpenShift サンドボックスコンテナーカスタムリソース KataConfig を削除する必要があります。これにより、kata ランタイムと関連リソースがクラスターから削除され、アンインストールされます。
前提条件
- クラスターに OpenShift Container Platform 4.9 がインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 kataをruntimeClassNameとして使用する実行中の Pod がない。-
OpenShift CLI (
oc) がインストールされている。 -
コマンドライン JSON プロセッサー (
jq) がインストールされている。 以下のコマンドを実行して、
kataをruntimeClassNameとして使用する Pod が実行されていないことを確認します。$ oc get pods -A -o json | jq -r '.items[] | select(.spec.runtimeClassName | test("kata")).metadata.name'
-
OpenShift CLI (
手順
-
kataの値でruntimeClassNameを使用するすべての Pod を削除します。 -
OpenShift Container Platform Web コンソールから、Projects 一覧より
openshift-sandboxed-containersを選択します。 - Operators → Installed Operators ページに移動します。
- OpenShift sandboxed containers をクリックします。
- OpenShift sandboxed containers Operator タブをクリックします。
-
Operator Details のスクロールダウン一覧をクリックし、Delete
KataConfigをクリックします。 - 確認ウィンドウで Delete をクリックします。
4.1.1.1. Web コンソールを使用した namespace の削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して namespace を削除できます。
前提条件
- クラスターに OpenShift Container Platform 4.9 がインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
- Administration → Namespaces に移動します。
-
namespace の一覧で削除する
openshift-sandboxed-containers-operatornamespace を見つけます。 - namespace の一覧の右端で、Options メニュー から Delete Namespace を選択します。
Delete Namespace ペインが表示されたら、フィールドに
openshift-sandboxed-containers-operatorを入力します。注記Delete Namespace オプションが選択できない場合には、namespace を削除するパーミッションがありません。
- Delete をクリックします。
4.1.2. OpenShift サンドボックスコンテナー Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
カタログサブスクリプションを削除し、Operator への namespace アクセスを取り消すことで、OpenShift でサンドボックス化したコンテナー Operator を削除できます。
前提条件
- クラスターに OpenShift Container Platform 4.9 がインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
- Operators → OperatorHub ページに移動します。
-
OpenShift sandboxed containers検索して、Operator を選択します。 - Uninstall をクリックします。
-
openshift-sandboxed-containers-operatornamespace を削除します。
4.2. CLI からの Kata ランタイムのアンインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform コマンドラインインターフェイス (CLI) を使用して、OpenShift サンドボックスコンテナーをアンインストールできます。
4.2.1. OpenShift サンドボックスコンテナーリソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
kata ランタイムとその関連リソースすべて (CRI-O 設定や RuntimeClass など) をクラスターから削除およびアンインストールできます。
前提条件
- クラスターに OpenShift Container Platform 4.9 がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを実行して
KataConfigカスタムリソースを削除します。$ oc delete kataconfig <KataConfig_CR_Name>以下のコマンドを実行して
KataConfigカスタムリソース定義を削除します。$ oc delete crd kataconfigs.kataconfiguration.openshift.io
OpenShift サンドボックスコンテナー Operator は、クラスターでランタイムを有効化するために初期に作成されていたリソースをすべて削除します。上記のコマンドを実行すると、インストールプロセス前の状態にクラスターが復元されます。openshift-sandboxed-containers-operator namespace が削除できるようになりました。
検証
KataConfigカスタムリソースが削除されたことを確認するには、以下のコマンドを実行します。$ oc get kataconfig <KataConfig_CR_Name>出力例
No KataConfig instances existKataConfigカスタムリソース定義が削除されていることを確認するには、以下のコマンドを実行します。$ oc get crd kataconfigs.kataconfiguration.openshift.io出力例
Unknown CR KataConfig
4.2.2. OpenShift サンドボックスコンテナー Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナー Operator をクラスターから削除できます。
前提条件
- クラスターに OpenShift Container Platform 4.9 がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを実行して、OpenShift サンドボックスコンテナー Operator サブスクリプションを Operator Lifecyle Manager (OLM) から削除します。
$ oc delete subscription openshift-sandboxed-containers-subscription -n openshift-sandboxed-containers-operator以下のコマンドを実行して、OpenShift サンドボックスコンテナーのクラスターサービスバージョン (CSV) 名を環境変数として設定します。
CSV_NAME=$(oc get csv -n openshift-sandboxed-containers-operator -o=custom-columns=:metadata.name)以下のコマンドを実行して、OpenShift サンドボックスコンテナーの CSV 名を削除します。
$ oc delete csv ${CSV_NAME} -n openshift-sandboxed-containers-operator
第5章 OpenShift サンドボックスコンテナーのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナー Operator および OpenShift サンドボックスコンテナーのアーティファクトをアップグレードして、OpenShift サンドボックスコンテナーのコンポーネントをアップグレードできます。
5.1. OpenShift サンドボックスコンテナー Operator のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) を使用して、OpenShift サンドボックスコンテナー Operator を手動で設定するか、または自動的にアップグレードできます。最初のデプロイメント時に手動または自動アップグレードを選択できます。手動アップグレードのコンテキストでは、Web コンソールに、クラスター管理者がインストールでき、利用可能な更新を表示します。
5.2. OpenShift サンドボックスコンテナーアーティファクトをアップグレードします。 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift サンドボックスコンテナーアーティファクトは、Red Hat Enterprise Linux CoreOS (RHCOS) 拡張機能を使用してクラスターにデプロイされます。
RHCOS 拡張 サンドボックスコンテナー には、Kata コンテナーランタイム、ハイパーバイザーの QEMU およびその他の依存関係などの Kata コンテナーの実行に必要なコンポーネントが含まれます。この拡張機能は、クラスターを OpenShift Container Platform の新規リリースにアップグレードする時に、アップグレードされます。
第6章 Red Hat サポート用の OpenShift サンドボックスコンテナーデータの収集 リンクのコピーリンクがクリップボードにコピーされました!
サポートケースを作成する際、ご使用のクラスターについてのデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。
must-gather ツールを使用すると、仮想マシンおよび OpenShift Virtualization に関連する他のデータを含む、 OpenShift Container Platform クラスターについての診断情報を収集できます。
迅速なサポートのために、OpenShift Container Platform と OpenShift サンドボックスコンテナーの両方の診断情報を提供してください。
6.1. must-gather ツールについて リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。
- リソース定義
- サービスログ
デフォルトで、oc adm must-gather コマンドはデフォルトのプラグインイメージを使用し、./must-gather.local に書き込みを行います。
または、以下のセクションで説明されているように、適切な引数を指定してコマンドを実行すると、特定の情報を収集できます。
1 つ以上の特定の機能に関連するデータを収集するには、以下のセクションに示すように、イメージと共に
--image引数を使用します。以下に例を示します。
$ oc adm must-gather --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.9.0監査ログを収集するには、以下のセクションで説明されているように
-- /usr/bin/gather_audit_logs引数を使用します。以下に例を示します。
$ oc adm must-gather -- /usr/bin/gather_audit_logs注記ファイルのサイズを小さくするために、監査ログはデフォルトの情報セットの一部として収集されません。
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
...
6.2. OpenShift サンドボックスコンテナーデータの収集について リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather CLI コマンドを使用して、クラスターに関する情報を収集できます。次の機能とオブジェクトは、OpenShift サンドボックスコンテナーに関連付けられています。
- OpenShift サンドボックスコンテナーリソースに属するすべての名前空間とその子オブジェクト
- すべての OpenShift サンドボックスコンテナーのカスタムリソース定義 (CRD)
oc adm must-gather CLI コマンドは、次のコンポーネントログを収集します。
- QEMU ログ
- 監査ログ
- OpenShift サンドボックスコンテナーのログ
- CRI-O ログ
これらのコンポーネントログは、kata ランタイムで実行されている Pod が最低でも 1 つあれば、収集されます。
must-gather を使用して OpenShift サンドボックスコンテナーデータを収集するには、OpenShift サンドボックスコンテナーイメージを指定する必要があります。
--image=registry.redhat.io/openshift-sandboxed-containers-tech-preview/osc-must-gather-rhel8:1.1.0
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 the OpenJS Foundation.
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.