第4章 OpenShift Serverless のインストール
4.1. OpenShift Serverless のインストール
以下では、クラスター管理者を対象に、OpenShift Serverless Operator の OpenShift Container Platform クラスターへのインストールについて説明します。
OpenShift Serverless は、ネットワークが制限された環境でのインストールに対してサポートされません。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
最新の Serverless リリースにアップグレードする前に、事前にインストールしている場合には、コミュニティー Knative Eventing Operator を削除する必要があります。Knative Eventing Operator をインストールすると、OpenShift Serverless Operator を使用して Knative Eventing の最新のバージョンをインストールできなくなります。
4.1.1. OpenShift Serverless インストールのクラスターサイズ要件の定義
OpenShift Serverless をインストールし、使用するには、OpenShift Container Platform クラスターのサイズを適切に設定する必要があります。OpenShift Serverless の最小要件は、10 CPU および 40GB メモリーを持つクラスターです。OpenShift Serverless を実行するための合計サイズ要件は、デプロイされたアプリケーションによって異なります。デフォルトで、各 Pod は約 400m の CPU を要求し、推奨値のベースはこの値になります。指定されるサイズ要件において、アプリケーションはレプリカを最大 10 つにスケールアップできます。アプリケーションの実際の CPU 要求を減らすと、レプリカ数が増える可能性があります。
指定される要件は、OpenShift Container Platform クラスターのワーカーマシンのプールにのみ関連します。マスターノードは一般的なスケジューリングには使用されず、要件から省略されます。
以下の制限は、すべての OpenShift Serverless デプロイメントに適用されます。
- Knative サービスの最大数: 1000
- Knative リビジョンの最大数: 1000
4.1.2. 高度なユースケースの追加要件
OpenShift Container Platform でのロギングまたはメータリングなどの高度なユースケースの場合は、追加のリソースをデプロイする必要があります。このようなユースケースで推奨される要件は 24 vCPU および 96GB メモリーです。
クラスターで高可用性 (HA) を有効にしている場合、これには Knative Serving コントロールプレーンの各レプリカについて 0.5 - 1.5 コアおよび 200MB - 2GB のメモリーが必要です。HA は、デフォルトで一部の Knative Serving コンポーネントについて有効にされます。OpenShift Serverless での高可用性レプリカの設定 についてのドキュメントに従って HA を無効にできます。
4.1.3. マシンセットを使用したクラスターのスケーリング
OpenShift Container Platform MachineSet
API を使用して、クラスターを必要なサイズに手動でスケールアップすることができます。最小要件は、通常 2 つのマシンを追加することによってデフォルトのマシンセットのいずれかをスケールアップする必要があることを意味します。マシンセットの手動によるスケーリング を参照してください。
4.1.4. 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 をクリックします。
Install Operator ページで以下を行います。
-
Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの
openshift-operators
namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。 -
Installed Namespace は
openshift-operators
になります。 - Update Channel として 4.5 チャネルを選択します。4.5 チャネルは、OpenShift Serverless Operator の最新の安定したリリースのインストールを可能にします。
- Automatic または Manual 承認ストラテジーを選択します。
-
Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの
- Install をクリックし、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 のクラスターへの追加 について参照してください。
4.1.5. 次のステップ
- OpenShift Serverless Operator がインストールされた後に、Knative Serving コンポーネントをインストールできます。Knative Serving のインストール についてのドキュメントを参照してください。
- OpenShift Serverless Operator がインストールされた後に、Knative Eventing コンポーネントをインストールできます。Knative Eventing のインストール についてのドキュメントを参照してください。