Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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
Copy to Clipboard Toggle word wrap

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 がクラスターにインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub Installed Operators に移動します。
  2. knative-eventing namespace を選択します。
  3. OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。

  4. knative-serving をクリックしてから、knative-eventing ページの YAML タブに移動します。

    Knative Eventing YAML
    View larger image
    Knative Eventing YAML

  5. KnativeEvening CR のレプリカ数を変更します。

    サンプル YAML

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  high-availability:
    replicas: 3
    Copy to Clipboard Toggle word wrap

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 がクラスターにインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub Installed Operators に移動します。
  2. knative-eventing namespace を選択します。
  3. OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka をクリックし、 Knative Kafka タブに移動します。

  4. knative-kafka をクリックしてから、knative-kafka ページの YAML タブに移動します。

    Knative Kafka YAML
    View larger image
    Knative Kafka YAML

  5. KnativeKafka CR のレプリカ数を変更します。

    サンプル YAML

    apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
  name: knative-kafka
  namespace: knative-eventing
spec:
  high-availability:
    replicas: 3
    Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat