第2章 ベアメタルへのワークロードのデプロイ
ワーカーノードに Red Hat Enterprise Linux CoreOS (RHCOS) がインストールされたオンプレミスのベアメタルサーバーに、OpenShift sandboxed containers ワークロードをデプロイできます。
- RHEL ノードはサポートされていません。
- ネストされた仮想化はサポートされていません。
ユーザーによってプロビジョニングされる、インストーラーでプロビジョニングされる、または Assisted Installer によるインストールなどのインストール方法を使用してクラスターをデプロイできます。
Amazon Web Services (AWS) ベアメタルインスタンスに OpenShift Sandboxed Containers のインストールもできます。他のクラウドプロバイダーが提供するベアメタルインスタンスはサポートされません。
デプロイメントワークフロー
次の手順を実行して、OpenShift Sandboxed Containers のワークロードをデプロイします。
- 環境を準備します。
-
KataConfig
カスタムリソースを作成します。 -
kata
ランタイムクラスを使用するようにワークロードオブジェクトを設定します。
2.1. 環境の準備
環境を準備するには、以下の手順を実行します。
- クラスターに十分なリソースがあることを確認します。
- OpenShift Sandboxed Containers Operator を再インストールします。
オプション: ワーカーノードが OpenShift sandboxed containers をサポートするように ノード適格性チェック を設定します。
- Node Feature Discovery (NFD) Operator をインストールします。詳細は、NFD Operator のドキュメント を参照してください。
-
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 バッファーもメモリーを消費します。
コンテナーに特定のメモリー量が指定されている場合には、コンテナーが起動する前に、メモリーが仮想マシンにホットプラグされます。
メモリー制限が指定されている場合には、上限より多くメモリーが消費された場合に、ワークロードが終了します。メモリー制限が指定されていない場合、仮想マシンで実行されているカーネルがメモリー不足になる可能性があります。カーネルがメモリー不足になると、仮想マシン上の他のプロセスが終了する可能性があります。
デフォルトのメモリーサイズ
以下の表は、リソース割り当てのデフォルト値を示しています。
リソース | 値 |
---|---|
デフォルトで仮想マシンに割り当てられるメモリー | 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 のみです。これは、メモリー使用量メトリックの報告時に適切に考慮されます。
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
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 -
Filter by keyword フィールドに
OpenShift sandboxed containers
と入力します。 - OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
- Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
Installed Namespace で Operator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の
openshift-sandboxed-containers-operator
namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。注記OpenShift Sandboxed Containers Operator を
openshift-sandboxed-containers-operator
以外の namespace にインストールしようとすると、インストールに失敗します。- Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
- Install をクリックします。
これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。
検証
-
Operators
Installed Operators に移動します。 - OpenShift Sandboxed Containers Operator が表示されることを確認します。
2.1.2.2. CLI を使用した Operator のインストール
CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
Namespace.yaml
マニフェストファイルを作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
以下のコマンドを実行して namespace を作成します。
$ oc create -f Namespace.yaml
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
以下のコマンドを実行して Operator グループを作成します。
$ oc create -f OperatorGroup.yaml
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
次のコマンドを実行して、サブスクリプションを作成します。
$ oc create -f Subscription.yaml
これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。
検証
次のコマンドを実行して、Operator が正常にインストールされていることを確認します。
$ oc get csv -n openshift-sandboxed-containers-operator
出力例
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.6.0 1.5.3 Succeeded
2.1.2.3. 関連情報
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 がインストールされている。
手順
以下の例に従って、
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"] # ...
NodeFeatureDiscovery
CR を作成します。$ oc create -f nfd.yaml
NodeFeatureDiscovery
CR は、feature.node.kubernetes.io/runtime.kata=true
ラベルをすべての認定ワーカーノードに適用します。
次の例に従って、
kata-config.yaml
マニフェストファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
KataConfig
CR を作成します。$ oc create -f kata-config.yaml
検証
クラスター内の適格なノードに正しいラベルが適用されていることを確認します。
$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
出力例
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