5.9. イベント設定のチューニング
5.9.1. Knative Eventing システムのデプロイメント設定のオーバーライド
KnativeEventing カスタムリソース (CR) の deployments 仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、デフォルトの構成設定のオーバーライドは、eventing-controller、eventing-webhook、および imc-controller フィールド、およびプローブの readiness フィールドと liveness フィールドでサポートされています。
replicas の仕様は、Horizontal Pod Autoscaler (HPA) を使用するデプロイのレプリカの数をオーバーライドできず、eventing-webhook デプロイでは機能しません。
デプロイメントでデフォルトで定義されているプローブのみをオーバーライドできます。
すべての Knative Serving デプロイメントは、デフォルトで readiness および liveness プローブを定義しますが、次の例外があります。
-
net-kourier-controllerと3scale-kourier-gateway はreadiness プローブのみを定義します。 -
net-istio-controllerとnet-istio-webhook はプローブを定義しません。
5.9.1.1. デプロイメント設定のオーバーライド
現在、デフォルトの構成設定のオーバーライドは、eventing-controller、eventing-webhook、および imc-controller フィールド、およびプローブの readiness フィールドと liveness フィールドでサポートされています。
replicas の仕様は、Horizontal Pod Autoscaler (HPA) を使用するデプロイのレプリカの数をオーバーライドできず、eventing-webhook デプロイでは機能しません。
次の例では、KnativeEventing CR が eventing-controller デプロイメントをオーバーライドして、次のようにします。
-
readinessプローブのタイムアウトeventing-controllerは 10 秒に設定されています。 - デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
- デプロイメントには 3 つのレプリカがあります。
-
example-label:labellabelが追加されました。 -
example-annotation: annotationが追加されます。 -
nodeSelectorフィールドは、disktype: hddラベルを持つノードを選択するように設定されます。
KnativeEventing CR の例
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
deployments:
- name: eventing-controller
readinessProbes: 1
- container: controller
timeoutSeconds: 10
resources:
- container: eventing-controller
requests:
cpu: 300m
memory: 100Mi
limits:
cpu: 1000m
memory: 250Mi
replicas: 3
labels:
example-label: label
annotations:
example-annotation: annotation
nodeSelector:
disktype: hdd
- 1
readinessおよびlivenessプローブオーバーライドを使用して、プローブハンドラーに関連するフィールド (exec、grpc、httpGet、およびtcpSocket) を除き、Kubernetes API で指定されているデプロイメントのコンテナー内のプローブのすべてのフィールドをオーバーライドできます。
KnativeEventing CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。
5.9.2. 高可用性
高可用性 (HA) は Kubernetes API の標準的な機能で、中断が生じる場合に API が稼働を継続するのに役立ちます。HA デプロイメントでは、アクティブなコントローラーがクラッシュまたは削除された場合、別のコントローラーをすぐに使用できます。このコントローラーは、現在使用できないコントローラーによって処理されていた API の処理を引き継ぎます。
OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。リーダー選択の HA パターンを使用する場合、必要時に備えてコントローラーのインスタンスはスケジュールされ、クラスター内で実行されます。これらのコントローラーインスタンスは、共有リソースの使用に向けて競います。これは、リーダー選択ロックとして知られています。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。
OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。リーダー選択の HA パターンを使用する場合、必要時に備えてコントローラーのインスタンスはスケジュールされ、クラスター内で実行されます。これらのコントローラーインスタンスは、共有リソースの使用に向けて競います。これは、リーダー選択ロックとして知られています。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。
5.9.2.1. Knative Eventing の高可用性レプリカの設定
Knative Eventing の eventing-controller、eventing-webhook、imc-controller、imc-dispatcher、mt-broker-controller コンポーネントは、デフォルトでそれぞれ 2 つのレプリカを持つように設定されており、高可用性 (HA) を利用することができます。KnativeServing カスタムリソース (CR) の spec.high-availability.replicas 値を変更して、これらのコンポーネントのレプリカ数を変更できます。
Knative Eventing の場合には、HA では mt-broker-filter および mt-broker-ingress デプロイメントはスケーリングされません。複数のデプロイメントが必要な場合は、これらのコンポーネントを手動でスケーリングします。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- 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-serving をクリックしてから、knative-eventing ページの YAML タブに移動します。
KnativeEveningCR のレプリカ数を変更します。サンプル YAML
apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: high-availability: replicas: 3
5.9.2.2. Knative Kafka の高可用性レプリカの設定
高可用性 (HA) は、デフォルトで Knative Kafka Kafka-controller および kafka-webhook-eventing コンポーネントで使用できます。これらのコンポーネントは、デフォルトで各レプリカが 2 つあるように設定されています。KnativeKafka カスタムリソース (CR) の spec.high-availability.replicas 値を変更して、これらのコンポーネントのレプリカ数を変更できます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Serverless Operator および Knative Kafka がクラスターにインストールされている。
手順
-
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
