Red Hat Summit第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 つの異なる場所にマッピングされています。これは、メモリー使用量メトリクスの報告時に適切に考慮されます。
