2.2. Web コンソールを使用した OpenShift Sandboxed Containers のデプロイ
OpenShift Container Platform Web コンソールを使用して次のタスクを実行することで、ベアメタルに OpenShift sandboxed containers をデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
- オプション: ノード適格性チェックを設定するには、Node Feature Discovery (NFD) Operator をインストールします。詳細は、ノードの適格性チェック および NFD Operator ドキュメント を参照してください。
- オプション: Kata エージェントポリシーをカスタマイズします。
-
KataConfig
カスタムリソースを作成します。 - OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。
2.2.1. OpenShift Sandboxed Containers Operator のインストール
OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
-
Web コンソールで、Operators
OperatorHub に移動します。 -
Filter by keyword フィールドに
OpenShift sandboxed containers
と入力します。 - OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
- Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
Installed Namespace で Operator recommended 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 をクリックします。
-
Operator
Installed Operator に移動して、Operator がインストールされていることを確認します。
2.2.2. Kata エージェントポリシーのカスタマイズ
Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。
セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーで上書きできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。
- ポリシーを Pod VM イメージに組み込む。
- ピア Pod の config map にパッチを適用する。
- ワークロード Pod YAML にアノテーションを追加する。
実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy
アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。
カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。
手順
カスタムポリシーを含む
policy.rego
ファイルを作成します。次の例では、デモ用にexec
とlog
を有効にした、設定可能なすべての API を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow package agent_policy import future.keywords.in import input default CopyFileRequest := false default CreateContainerRequest := false default CreateSandboxRequest := true default DestroySandboxRequest := true default ExecProcessRequest := true # Enabled to allow exec API default GetOOMEventRequest := true default GuestDetailsRequest := true default OnlineCPUMemRequest := true default PullImageRequest := true default ReadStreamRequest := true # Enabled to allow log API default RemoveContainerRequest := true default RemoveStaleVirtiofsShareMountsRequest := true default SignalProcessRequest := true default StartContainerRequest := true default StatsContainerRequest := true default TtyWinResizeRequest := true default UpdateEphemeralMountsRequest := true default UpdateInterfaceRequest := true default UpdateRoutesRequest := true default WaitProcessRequest := true default WriteStreamRequest := false
package agent_policy import future.keywords.in import input default CopyFileRequest := false default CreateContainerRequest := false default CreateSandboxRequest := true default DestroySandboxRequest := true default ExecProcessRequest := true # Enabled to allow exec API default GetOOMEventRequest := true default GuestDetailsRequest := true default OnlineCPUMemRequest := true default PullImageRequest := true default ReadStreamRequest := true # Enabled to allow log API default RemoveContainerRequest := true default RemoveStaleVirtiofsShareMountsRequest := true default SignalProcessRequest := true default StartContainerRequest := true default StatsContainerRequest := true default TtyWinResizeRequest := true default UpdateEphemeralMountsRequest := true default UpdateInterfaceRequest := true default UpdateRoutesRequest := true default WaitProcessRequest := true default WriteStreamRequest := false
このポリシーは、
exec
(ExecProcessRequest
) およびlog
(ReadStreamRequest
) API を有効にします。必要に応じて、true
またはfalse
の値を調整してポリシーをさらにカスタマイズします。次のコマンドを実行して、
policy.rego
ファイルを Base64 でエンコードされた文字列に変換します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow base64 -w0 policy.rego
$ base64 -w0 policy.rego
yaml ファイルで使用するために出力を保存します。
2.2.3. KataConfig カスタムリソースの作成
ワーカーノードに kata
を RuntimeClass
としてインストールするには、KataConfig
カスタムリソース (CR) を作成する必要があります。
kata
ランタイムクラスは、デフォルトですべてのワーカーノードにインストールされます。特定のノードにのみ kata
をインストールする場合は、それらのノードにラベルを追加し、KataConfig
CR でラベルを定義できます。
OpenShift sandboxed containers は、プライマリーランタイムとしてではなく クラスター上のセカンダリーのオプション ランタイムとして kata
をインストールします。
KataConfig
CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーが有効である。
- SSD ではなくハードディスクドライブにデプロイしている。
- 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
- CPU とネットワークが遅い。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - オプション: ノードの適格性チェックを有効にする場合は、Node Feature Discovery Operator をインストールしておきます。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - OpenShift sandboxed containers Operator を選択します。
- KataConfig タブで、Create KataConfig をクリックします。
以下の詳細を入力します。
-
Name: オプション: デフォルト名は
example-kataconfig
です。 -
Labels: オプション: 関連する識別属性を
KataConfig
リソースに入力します。各ラベルはキーと値のペアを表します。 - checkNodeEligibility : オプション: Node Feature Discovery Operator (NFD) を使用してノードの適格性を検出する場合に選択します。
kataConfigPoolSelector。オプション: 選択したノードに
kata
をインストールするには、選択したノードのラベルに一致する式を追加します。- kataConfigPoolSelector エリアを展開します。
- kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
- Add matchExpressions をクリックします。
- Key フィールドに、セレクターの適用先のラベルキーを入力します。
-
Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、
In
、NotIn
、Exists
、DoesNotExist
です。 - Values エリアを展開し、Add value をクリックします。
-
Value フィールドで、
true
またはfalse
を key ラベル値として入力します。
-
logLevel: ランタイムクラスが
kata
のノードに対して取得されるログデータのレベルを定義します。
-
Name: オプション: デフォルト名は
Create をクリックします。
KataConfig
CR が作成され、ワーカーノードにkata
ランタイムクラスをインストールします。kata
のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。
検証
-
KataConfig タブで、
KataConfig
CR をクリックして詳細を表示します。 YAML タブをクリックして
status
スタンザを表示します。status
スタンザには、conditions
およびkataNodes
キーが含まれています。status.kataNodes
の値はノード配列であり、各ノードにはkata
インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。Reload をクリックして、YAML を更新します。
status.kataNodes
配列内のすべてのワーカーに、installed
の値と、理由が指定されていないconditions.InProgress: False
が表示される場合、kata
がクラスターにインストールされています。
関連情報
2.2.4. ワークロードオブジェクトの設定
次の Pod テンプレートオブジェクトのランタイムクラスとして kata
を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。
-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。
前提条件
-
KataConfig
カスタムリソース (CR) を作成している。
手順
-
OpenShift Container Platform Web コンソールで、Workloads
workload type (例: Pods) に移動します。 - ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
- YAML タブをクリックします。
次の例のように、
spec.runtimeClassName: kata
を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。
検証
-
Pod テンプレートオブジェクトの
spec.runtimeClassName
フィールドを検査します。値がkata
の場合、ワークロードはピア Pod を使用して OpenShift sandboxed containers 上で実行されています。