Red Hat Summit第3章 OpenShift サンドボックスコンテナーワークロードのデプロイ
Web コンソールまたは OpenShift CLI (oc) のいずれかを使用して OpenShift サンドボックスコンテナー Operator をインストールできます。OpenShift サンドボックスコンテナー Operator をインストールする前に、OpenShift Container Platform クラスターを準備する必要があります。
3.1. OpenShift サンドボックスコンテナー向けのクラスターの準備
OpenShift サンドボックスコンテナーをインストールする前に、OpenShift Container Platform クラスターが以下の要件を満たしていることを確認してください。
クラスターは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーを使用してベアメタルインフラストラクチャーにインストールする必要があります。お使いのクラスターではインストーラーでプロビジョニングを使用する必要があります。
重要- OpenShift サンドボックスコンテナーは RHCOS ワーカーノードのみをサポートします。RHEL 7 ノードまたは RHEL 8 ノードはサポートされません。
- ネストされた仮想化はサポートされていません。
3.1.1. OpenShift サンドボックスコンテナーの追加のリソース要件
OpenShift サンドボックスコンテナーは、Kata Containers などのサンドボックス化されたランタイム内でワークロードを OpenShift Container Platform クラスターで実行できる製品です。各 Pod は仮想マシン (VM) で表されます。各仮想マシンは qemu プロセスで実行され、コンテナーワークロードおよびこれらのコンテナーで実行されているプロセスを管理するためのスーパーバイザーとして機能する kata-agent プロセスをホストします。オーバーヘッドが増えるプロセスは他に 2 つあります。
-
containerd-shim-kata-v2。これは Pod との通信に使用されます。 -
virtiofsd。これはゲストの代わりにホストファイルシステムのアクセスを処理します。
各仮想マシンには、デフォルトのメモリー容量が設定されます。コンテナーでメモリーが明示的に要求された場合に、メモリーが追加で仮想マシンにホットプラグされます。
- コンテナーが指定のメモリーリソースなしで実行される場合は、空きメモリーを使用できます。これは、仮想マシンで使用される合計メモリーがデフォルトの割り当てに到達するまで行われます。ゲストやその I/O バッファーもメモリーを消費します。
- コンテナーに特定のメモリー量が指定されている場合には、コンテナーが起動する前に、メモリーが仮想マシンにホットプラグされます。
- メモリー制限が指定されている場合には、上限より多くメモリーが消費された場合に、ワークロードが終了します。メモリー制限を指定しないと、仮想マシンで実行しているカーネルのメモリーが不足する可能性があります。カーネルでのメモリーが不足すると、仮想マシン上の他のプロセスが終了される可能性があります。
デフォルトのメモリーサイズ
以下の表は、リソース割り当てのデフォルト値を示しています。
| リソース | 値 |
|---|---|
| デフォルトで仮想マシンに割り当てられるメモリー | 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
出力例
Name: kata
[...]
Metadata:
[...]
Overhead:
Pod Fixed:
Cpu: 250m
Memory: 350Mi
[...]
RuntimeClass の spec.overhead フィールドを変更して、Pod のオーバーヘッドを変更できます。たとえば、コンテナーに対する設定が QEMU プロセスおよびゲストカーネルデータでメモリー 350Mi 以上を消費する場合に、RuntimeClass のオーバーヘッドをニーズに合わせて変更できます。
Red Hat では、指定のデフォルトオーバーヘッド値がサポートされます。デフォルトのオーバーヘッド値の変更はサポートされておらず、値を変更すると技術的な問題が発生する可能性があります。
例
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
- 仮想マシンのデフォルト割り当ては 2Gi です。
- Linux カーネルは、システムの起動時に約 100Mi のメモリーを使用します。
- QEMU プロセスでは約 30Mi のメモリーを使用します。
-
virtiofsdプロセスでは約 10Mi のメモリーを使用します。 -
shim-v2プロセスでは約 20Mi のメモリーを使用します。
ゲストで種類にかかわらず、ファイルシステム I/O を実行すると、ファイルバッファーがゲストカーネルに割り当てられます。ファイルバッファーは、virtiofsd プロセスだけでなく、ホスト上の QEMU プロセスでもマッピングされます。たとえば、ゲストでファイルバッファーキャッシュ 300Mi を使用すると、QEMU と virtiofsd の両方が、追加で 300Mi を使用するように見えます。ただし、3 つのケースすべてで同じメモリーが使用されています。つまり、メモリーの合計使用量は 300Mi のみで、このメモリー量が 3 つの異なる場所にマッピングされています。これは、メモリー使用量メトリクスの報告時に適切に考慮されます。
