10.2. 高可用性
高可用性 (HA) は Kubernetes API の標準的な機能で、中断が生じる場合に API が稼働を継続するのに役立ちます。HA デプロイメントでは、アクティブなコントローラーがクラッシュまたは削除されると、別のコントローラーをすぐに使用できます。このコントローラーは、現在使用できないコントローラーによって処理されていた API の処理を引き継ぎます。
OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。リーダー選択の HA パターンを使用する場合は、必要時に備えてコントローラーのインスタンスがスケジュールされ、クラスター内で実行されます。このコントローラーインスタンスは、リーダー選出ロックと呼ばれる共有リソースを使用するために競合します。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。
OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。リーダー選択の HA パターンを使用する場合は、必要時に備えてコントローラーのインスタンスがスケジュールされ、クラスター内で実行されます。このコントローラーインスタンスは、リーダー選出ロックと呼ばれる共有リソースを使用するために競合します。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。
10.2.1. Knative Eventing の高可用性レプリカの設定
Knative Eventing の eventing-controller、eventing-webhook、imc-controller、imc-dispatcher、mt-broker-controller コンポーネントは、デフォルトでそれぞれ 2 つのレプリカを持つように設定されており、高可用性 (HA) を利用することができます。KnativeEventing カスタムリソース (CR) の spec.high-availability.replicas 値を変更して、これらのコンポーネントのレプリカ数を変更できます。
Knative Eventing の場合、HA では mt-broker-filter および mt-broker-ingress デプロイメントはスケーリングされません。複数のデプロイメントが必要な場合は、これらのコンポーネントを手動でスケーリングします。
前提条件
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
手順
-
OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub
Installed Operators に移動します。 -
knative-eventingnamespace を選択します。 - OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。
knative-eventing をクリックしてから、knative-eventing ページの YAML タブに移動します。
KnativeEventingCR のレプリカ数を変更します。サンプル YAML
apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: high-availability: replicas: 3特定のワークロードのレプリカの数を指定することもできます。
注記ワークロード固有の設定は、Knative Eventing のグローバル設定をオーバーライドします。
サンプル YAML
apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: high-availability: replicas: 3 workloads: - name: mt-broker-filter replicas: 3高可用性の制限が反映されていることを確認します。
コマンドの例
$ oc get hpa -n knative-eventing
出力例
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE broker-filter-hpa Deployment/mt-broker-filter 1%/70% 3 12 3 112s broker-ingress-hpa Deployment/mt-broker-ingress 1%/70% 3 12 3 112s eventing-webhook Deployment/eventing-webhook 4%/100% 3 7 3 115s
10.2.2. Apache Kafka の Knative ブローカー実装の高可用性レプリカの設定
高可用性 (HA) は、Apache Kafka コンポーネント kafka-controller および kafka-webhook-eventing の Knative ブローカー実装にはデフォルトで提供されており、これらはデフォルトでそれぞれ 2 つのレプリカを持つように設定されています。KnativeKafka カスタムリソース (CR) の spec.high-availability.replicas 値を変更して、これらのコンポーネントのレプリカ数を変更できます。
前提条件
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- OpenShift Serverless Operator と Apache Kafka 用の Knative ブローカーがクラスターにインストールされている。
手順
-
OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub
Installed Operators に移動します。 -
knative-eventingnamespace を選択します。 - OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka をクリックし、Knative Kafka タブに移動します。
knative-kafka をクリックしてから、knative-kafka ページの YAML タブに移動します。
KnativeKafkaCR のレプリカ数を変更します。サンプル YAML
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: name: knative-kafka namespace: knative-eventing spec: high-availability: replicas: 3
10.2.3. 停止状態の予算のオーバーライド
Pod Disruption Budget (PDB) は、Kubernetes API の標準機能であり、メンテナンス上の理由で Pod の再スケジュールが必要になったときにアプリケーションの中断を制限するのに役立ちます。
手順
-
KnativeEventingカスタムリソース (CR) のminAvailable設定値を変更して、特定のリソースのデフォルトの PDB をオーバーライドします。
minAvailable 設定が 70% の PDB の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: podDisruptionBudgets: - name: eventing-webhook minAvailable: 70%
たとえば、high-availability.replicas の値を 1 に変更して高可用性を無効にする場合は、対応する PDB minAvailable の値も 0 に更新してください。そうしないと、Pod 停止状態の予算によってクラスターまたは Operator の自動更新が妨げられます。
