第2章 ベアメタルへのデプロイ
ワーカーノードに Red Hat Enterprise Linux CoreOS (RHCOS) がインストールされたオンプレミスのベアメタルクラスターに OpenShift sandboxed containers をデプロイできます。
- RHEL ノードはサポートされていません。
- ネストされた仮想化はサポートされていません。
ユーザーによってプロビジョニングされる、インストーラーでプロビジョニングされる、または Assisted Installer によるインストールなどのインストール方法を使用してクラスターをデプロイできます。
Amazon Web Services (AWS) ベアメタルインスタンスに OpenShift Sandboxed Containers のインストールもできます。他のクラウドプロバイダーが提供するベアメタルインスタンスはサポートされません。
クラスターの要件
- OpenShift sandboxed containers Operator をインストールするクラスターに Red Hat OpenShift Container Platform 4.14 以降をインストールしている。
- クラスターには少なくとも 1 つのワーカーノードがある。
2.1. OpenShift Sandboxed Containers のリソース要件
クラスターに十分なリソースがあることを確認する。
OpenShift sandboxed containers を使用すると、ユーザーはサンドボックスランタイム (Kata) 内の 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
出力例
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 つのケースすべてで同じメモリーが使用されます。したがって、合計メモリー使用量は 3 つの異なる場所にマップされた 300Mi のみです。これは、メモリー使用量メトリックの報告時に適切に考慮されます。
