3.2. Web コンソールでピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ
Web コンソールから OpenShift Sandboxed Containers のワークロードをデプロイできます。まず、OpenShift Sandboxed Containers Operator をインストールし、次にシークレットオブジェクト、VM イメージ、およびピア Pod ConfigMap を作成する必要があります。シークレットオブジェクトと ConfigMap は一意です。クラウドプロバイダーに応じて指定します。最後に、KataConfig
カスタムリソース (CR) を作成する必要があります。Sandboxed Containers にワークロードをデプロイする準備ができたら、kata-remote
を runtimeClassName
としてワークロード YAML ファイルに手動で追加する必要があります。
3.2.1. Web コンソールを使用した OpenShift Sandboxed Containers Operator のインストール
OpenShift Container Platform Web コンソールから OpenShift サンドボックスコンテナー Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.15 がインストールされている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
-
Web コンソールの Administrator パースペクティブで、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 がクラスターにインストールされました。
検証
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - OpenShift Sandboxed Containers Operator がインストール済みの Operator リストに表示されていることを確認します。
3.2.2. Web コンソールを使用した AWS のピア Pod パラメーターの設定
AWS 上のピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、シークレットオブジェクトと ConfigMap
を作成する必要があります。
シークレットオブジェクトを作成した後も、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするために KataConfig
カスタムリソース (CR) を作成する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
3.2.2.1. Web コンソールを使用した AWS のシークレットオブジェクトの作成
AWS アクセスキーを指定してシークレットオブジェクトでネットワークを設定します。シークレットオブジェクトは、Pod 仮想マシンイメージの作成に使用され、ピア Pod によって使用されます。
AWS のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。シークレットオブジェクトを作成する前に、これらの値の一部を取得できます。CLI を使用してこれらの値を取得する必要があります。詳細は、CLI を使用した AWS のシークレットオブジェクトの作成 を参照してください。
さらに、AWS Web コンソールで次の値を生成し、保存する必要があります。
-
AWS_ACCESS_KEY_ID
-
AWS_SECRET_ACCESS_KEY
手順
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AWS_ACCESS_KEY_ID: "<enter value>" 1 AWS_SECRET_ACCESS_KEY: "<enter value>" 2 AWS_REGION: "<enter value>" 3 AWS_SUBNET_ID: "<enter value>" 4 AWS_VPC_ID: "<enter value>" 5 AWS_SG_IDS: "<enter value>" 6
- Create をクリックします。
シークレットオブジェクトが作成されます。Workloads
ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
シークレットを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
3.2.2.2. Web コンソールを使用した AWS 用のピア Pod ConfigMap の作成
Web コンソールを使用して、AWS のピア Pod ConfigMap
を作成できます。
手順
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "aws" VXLAN_PORT: "9000" PODVM_INSTANCE_TYPE: "t3.medium" 1 PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 2 PROXY_TIMEOUT: "5m"
- Create をクリックします。
ConfigMap
オブジェクトが作成されます。Workloads
ピア Pod 設定マップを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
設定マップを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
KataConfig
CR を作成すると、AWS 上のピア Pod を使用して OpenShift Sandboxed Containers を実行できます。
3.2.3. Web コンソールを使用した Azure のピア Pod パラメーターの設定
Microsoft Azure 上のピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、シークレットオブジェクトと ConfigMap
を作成する必要があります。
シークレットオブジェクトを作成した後も、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするために KataConfig
カスタムリソース (CR) を作成する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
3.2.3.1. Web コンソールを使用した Azure のシークレットオブジェクトの作成
Azure アクセスキーを設定し、シークレットオブジェクトでネットワークを設定します。シークレットオブジェクトは、Pod 仮想マシンイメージの作成に使用され、ピア Pod によって使用されます。
Azure のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。これらの値は、シークレットオブジェクトを作成する前に取得できます。CLI を使用してこれらの値を取得する必要があります。詳細は、CLI を使用した Azure のシークレットオブジェクトの作成 を参照してください。
手順
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<enter value>" 1 AZURE_CLIENT_SECRET: "<enter value>" 2 AZURE_TENANT_ID: "<enter value>" 3 AZURE_SUBSCRIPTION_ID: "<enter value>" 4 AZURE_REGION: "<enter value>" 5 AZURE_RESOURCE_GROUP: "<enter value>" 6
- Create をクリックします。
シークレットオブジェクトが作成されます。Workloads
ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
シークレットを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
3.2.3.2. Web コンソールを使用した Azure のピア Pod ConfigMap の作成
Web コンソールを使用して Azure のピア Pod ConfigMap
を作成できます。
手順
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 1 AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 2 AZURE_SUBNET_ID: "<enter value>" 3 AZURE_NSG_ID: "<enter value>" 4 PROXY_TIMEOUT: "5m" DISABLECVM: "true"
- Create をクリックします。
ConfigMap`
オブジェクトが作成されます。Workloads
ピア Pod 設定マップを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
設定マップを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
3.2.3.3. Web コンソールを使用した Azure の SSH キーシークレットオブジェクトの作成
Azure でピア Pod を使用するには、SSH キーシークレットオブジェクトを作成する必要があります。オブジェクトの作成用の SSH 鍵がない場合は、CLI を使用して SSH 鍵を生成する必要があります。詳細は、以下を参照してください。
手順
-
Web コンソールの Administrator パースペクティブから、Workloads
Secrets に移動します。 - Secrets ウィンドウの左上隅で、openshift-sandboxed-containers-operator プロジェクトにいることを確認します。
- Create をクリックし、リストから Key/value secret を選択します。
-
Secret name フィールドに
ssh-key-secret
と入力します。 -
Key フィールドに
id_rsa.pub
と入力します。 - Value フィールドに、公開 SSH 鍵を貼り付けます。
- Create をクリックします。
SSH 鍵のシークレットオブジェクトが作成されます。Workloads
KataConfig
CR を作成すると、Azure 上のピア Pod を使用して OpenShift Sandboxed Containers を実行できます。
3.2.4. Web コンソールでの KataConfig カスタムリソースの作成
kata-remote
をクラスターノードに RuntimeClass
としてインストールできるようにするには、KataConfig
カスタムリソース (CR) を 1 つ作成する必要があります。
KataConfig
CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーが有効である。
- SSD ではなくハードディスクドライブにデプロイしている。
- 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
- CPU とネットワークが遅い。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
ピア Pod の Kata は、デフォルトですべてのワーカーノードにインストールされます。kata-remote
を 特定のノードにのみ RuntimeClass
としてインストールする場合は、それらのノードにラベルを追加し、作成時に KataConfig
CR でラベルを定義できます。
手順
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- KataConfig タブで、Create KataConfig をクリックします。
Create KataConfig ページで、次の詳細を入力します。
-
Name:
KataConfig
リソースの名前を入力します。デフォルトでは、名前はexample-kataconfig
として定義されています。 -
Labels (オプション): 関連する識別属性を
KataConfig
リソースに入力します。各ラベルはキーと値のペアを表します。 -
checkNodeEligibility
(オプション、ピア Pod には該当しない):kata
をRuntimeClass
として実行するノードの適格性を、Node Feature Discovery Operator (NFD) を使用して検出するには、このチェックボックスを選択します。詳細は、「クラスターノードが OpenShift Sandboxed Containers を実行する資格があるかどうかを確認する」を参照してください。 -
EnablePeerPods
(ピア Pod の場合): ピア Pod を有効にし、パブリッククラウド環境で OpenShift Sandboxed Containers を使用するには、このチェックボックスをオンにします。 kataConfigPoolSelector
: デフォルトでは、kata-remote
はすべてのノードにRuntimeClass
としてインストールされます。選択したノードにのみkata-remote
をRuntimeClass
としてインストールする場合は、matchExpression を追加する必要があります。-
kataConfigPoolSelector
エリアを展開します。 -
kataConfigPoolSelector
で、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。 - Add matchExpressions をクリックします。
- key フィールドに、セレクターの適用先のラベルキーを追加します。
-
operator フィールドに、ラベル値に対するキーの関係を追加します。有効な演算子は、
In
、NotIn
、Exists
、DoesNotExist
です。 - values エリアを展開し、Add value をクリックします。
-
Value フィールドで、
true
またはfalse
を key ラベル値として入力します。
-
-
logLevel
:kata-remote
をRuntimeClass
として実行しているノードに対して取得するログデータのレベルを定義します。詳細は、「OpenShift Sandboxed Containers データの収集」を参照してください。
-
Name:
- Create をクリックします。
新しい KataConfig
CR が作成され、ワーカーノードに RuntimeClass
として kata-remote
をインストールし始めます。インストールが完了してワーカーノードが再起動するまで待ってから、次の手順に進みます。
CR を実行すると、VM イメージが作成されます。イメージの作成はクラウドプロバイダーにより行われ、追加のリソースを使用する場合があります。
OpenShift Sandboxed Containers は、kata-remote
をプライマリーランタイムとしてではなく、クラスター上のセカンダリーオプションのランタイムとしてのみインストールします。
検証
-
KataConfig タブで、新しい
KataConfig
CR を選択します。 - KataConfig ページで、YAML タブを選択します。
status フィールドを監視します。
更新があるたびにメッセージが表示されます。リロード をクリックして、更新された
KataConfig
CR を表示します。status フィールドには conditions および kataNodes サブフィールドがあります。kataNodes サブフィールドはノード一覧のコレクションです。各ノードは、
kata
インストールの特定状態のノードを一覧表示します。kataNodes の下のすべてのワーカーが
installs
としてリストされ、理由を指定せずにInProgress
の条件がFalse
の場合は、kata
がクラスターにインストールされていることを示します。詳細は、「移行のインストールとアンインストール」を参照してください。
3.2.5. Web コンソールを使用したピア Pod を含むワークロードの Sandboxed Containers へのデプロイ
OpenShift Sandboxed Containers は、Kata をプライマリーランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてインストールします。
Sandboxed Containers 内のピア Pod を使用して Pod テンプレート化されたワークロードをデプロイするには、kata-remote
を runtimeClassName
としてワークロード YAML ファイルに手動で追加する必要があります。
また、YAML ファイルにアノテーションを追加して、ConfigMap
で以前に定義したデフォルトのインスタンスサイズまたはタイプを使用してワークロードをデプロイするかどうかも定義する必要があります。インスタンスサイズまたはインスタンスタイプの使用は、クラウドプロバイダーによって異なります。インスタンスのサイズまたはタイプを手動で定義しない場合は、アノテーションを追加して、使用可能なメモリーに基づいて自動インスタンスのサイズまたはタイプの使用を定義する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
-
クラウドプロバイダーに固有のシークレットオブジェクトとピア Pod の
ConfigMap
を作成している。 -
KataConfig
カスタムリソース (CR) を作成している。
手順
- Web コンソールの Administrator パースペクティブから、Workloads をデプロイメントし、作成するワークロードのタイプを選択します。
- ワークロードページで、をクリックしてワークロードを作成します。
-
ワークロードの YAML ファイルで、コンテナーがリストされている spec フィールドに
runtimeClassName: kata-remote
を追加します。 ワークロードの YAML ファイルにアノテーションを追加して、デフォルトのインスタンスサイズまたはタイプを使用するか、自動インスタンスサイズまたはタイプを使用するかを定義します。インスタンスサイズは特定のクラウドプロバイダーに使用され、インスタンスタイプは他のクラウドプロバイダーに使用されます。
特定のインスタンスサイズタイプについては、次のアノテーションを追加します。
io.katacontainers.config.hypervisor.machine_type: <instance type/instance size>
ワークロードが使用するインスタンスのサイズまたはタイプを定義します。これらのデフォルトのサイズまたはタイプは、ピア Pod の
ConfigMap
を作成するときに事前に定義してあります。そのうちの 1 つを選択してください。自動インスタンスのサイズまたはタイプについては、次のアノテーションを追加します。
io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory>
ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて、自動インスタンスサイズまたはタイプで実行されます。
Pod
オブジェクトの例apiVersion: v1 kind: Pod metadata: name: hello-openshift labels: app: hello-openshift annotations: io.katacontainers.config.hypervisor.machine_type: Standard_DC4as_v5 1 spec: runtimeClassName: kata-remote containers: - name: hello-openshift image: quay.io/openshift/origin-hello-openshift ports: - containerPort: 8888 securityContext: privileged: false allowPrivilegeEscalation: false runAsNonRoot: true runAsUser: 1001 capabilities: drop: - ALL seccompProfile: type: RuntimeDefault
- 1
- この例では、Azure を使用してピア Pod に事前に定義されたインスタンスサイズを使用します。AWS を使用するピア Pod はインスタンスタイプを使用します。
- Save をクリックします。
OpenShift Container Platform はワークロードを作成し、スケジューリングを開始します。