第5章 OpenShift Serverless のインストール
5.1. OpenShift Serverless のインストール
以下では、クラスター管理者を対象に、OpenShift Serverless Operator の OpenShift Container Platform クラスターへのインストールについて説明します。
OpenShift Serverless は、ネットワークが制限された環境でのインストールに対してサポートされません。詳細は、「ネットワークが制限された環境での Operator Lifecycle Manager の使用」を参照してください。
5.1.1. クラスターサイジングの要件
OpenShift Serverless を実行するには、OpenShift Container Platform クラスターのサイズを適切に設定する必要があります。OpenShift Serverless を使用する最小要件は、10 CPU および 40GB メモリーを持つクラスターです。
OpenShift Serverless を実行するための合計サイズ要件は、デプロイされたアプリケーションによって異なります。デフォルトで、各 Pod は CPU ~400m を要求し、推奨値のベースはこの値になります。
指定されるサイズ要件において、アプリケーションはレプリカを最大 10 つにスケールアップできます。アプリケーションの実際の CPU 要求を減らすと、レプリカ数が増える可能性があります。
MachineSet API を使用して、クラスターを必要なサイズにスケールアップすることができます。最小要件は、通常 2 つのマシンを追加することによってデフォルト MachineSet のいずれかをスケールアップする必要があることを意味します。
MachineSet API の使用についての詳細は、「MachineSet の作成」を参照してください。
MachineSet の手動によるスケーリングについての詳細は、MachineSet の手動によるスケーリングについてのドキュメントを参照してください。
指定される要件は、OpenShift Container Platform クラスターのワーカーマシンのプールにのみ関連します。マスターノードは一般的なスケジューリングには使用されず、要件から省略されます。
以下の制限は、すべての OpenShift Serverless デプロイメントに適用されます。
- Knative サービスの最大数: 1000
- Knative リビジョンの最大数: 1000
5.1.1.1. 高度なユースケースの追加要件
OpenShift Container Platform でのロギングまたはメータリングなどの高度なユースケースの場合は、追加のリソースをデプロイする必要があります。このようなユースケースで推奨される要件は 24 vCPU および 96GB メモリーです。
クラスターで高可用性 (HA) を有効にしている場合、これには Knative Serving コントロールプレーンの各レプリカについて 0.5 - 1.5 コアおよび 200MB - 2GB のメモリーが必要です。HA は、デフォルトで一部の Knative Serving コンポーネントについて有効にされます。OpenShift Serverless での高可用性レプリカの設定についてのドキュメントに従って HA を無効にできます。
最新の Serverless リリースにアップグレードする前に、事前にインストールしている場合はコミュニティー Knative Eventing Operator を削除する必要があります。Knative Eventing Operator をインストールすると、OpenShift Serverless Operator を使用して Knative Eventing の最新のテクノロジープレビューバージョンをインストールできなくなります。
5.1.2. OpenShift Serverless Operator のインストール
この手順では、OpenShift Container Platform Web コンソールを使用して、OperatorHub から OpenShift Serverless Operator をインストールし、これにサブスクライブする方法を説明します。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 スクロールするか、またはこれらのキーワード Serverless を Filter by keyword ボックス に入力して OpenShift Serverless Operator を検索します。
Operator についての情報を確認してから、Install をクリックします。
Create Operator Subscription ページで以下を実行します。
-
Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの
openshift-operators
namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。 -
Installed Namespace は
openshift-operators
になります。 - Update Channel として 4.3 を選択します。
- Automatic または Manual 承認ストラテジーを選択します。
-
Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの
- Subscribe をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。
Catalog
Operator Management ページから、OpenShift Serverless Operator サブスクリプションのインストールおよびアップグレードの進捗をモニターできます。 - 手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、その Install Plan を確認し、承認するまで Upgrading のままになります。Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。
- 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。
検証手順
サブスクリプションのアップグレードステータスが Up to date に移行したら、Catalog
上記通りにならない場合:
-
Catalog
Operator Management ページに切り替え、Operator Subscriptions および Install Plans タブで Status の下の失敗またはエラーの有無を確認します。 -
さらにトラブルシューティングの必要な問題を報告している Pod のログについては、Workloads
Pods ページの openshift-operators
プロジェクトの Pod のログで確認できます。
追加リソース
- 詳細は、OpenShift Container Platform ドキュメントの Operator のクラスターへの追加 について参照してください。
5.1.3. 次のステップ
- OpenShift Serverless Operator がインストールされた後に、Knative Serving コンポーネントをインストールできます。Knative Serving のインストールについてのドキュメントを参照してください。
- OpenShift Serverless Operator がインストールされた後に、Knative Eventing コンポーネントをインストールできます。Knative Eventing のインストールについてのドキュメントを参照してください。