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

手順

  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-eventing をクリックしてから、knative-eventing ページの YAML タブに移動します。

    Knative Eventing YAML
  5. KnativeEventing CR のレプリカ数を変更します。

    サンプル YAML

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3

  6. 特定のワークロードのレプリカの数を指定することもできます。

    注記

    ワークロード固有の設定は、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

  7. 高可用性の制限が反映されていることを確認します。

    コマンドの例

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

手順

  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
  5. KnativeKafka CR のレプリカ数を変更します。

    サンプル 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 の自動更新が妨げられます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.