Confluent Platform のマルチリージョンデプロイ

Confluent for Kubernetes (CFK)は、1 つのマルチリージョンクラスターとして異なるリージョンで実行されている複数の Kubernetes クラスターにおいて、Confluent Platform の構成、デプロイ、運用をサポートします。

Kafka, ZooKeeper, and Schema Registry can be deployed in multiple regions to form a logical cluster stretched across Kubernetes regions.

For information about Confluent Platform MRC, see Multi-Region Clusters.

The MRC configured Confluent deployment needs to be deployed across three or more Kubernetes clusters.

CFK supports various deployment scenarios for Confluent Platform.

  • The following diagram describes an example MRC deployment across three Kubernetes regions, where each cluster hosts CFK, Kafka brokers, and ZooKeeper servers.

    _images/co-mrc-3clusters.ja.png
  • The diagram describes an example MRC deployment across three Kubernetes regions, where each cluster hosts CFK, ZooKeeper servers, and two clusters host Kafka brokers.

    _images/co-mrc-2.5clusters.ja.png

基本的および包括的なユースケースシナリオについては、GitHub の Confluent for Kubernetes サンプルレポジトリ を参照してください。

The supported security features work in MRC deployments. For specific configurations, see Confluent for Kubernetes でのセキュリティの構成.

Kubernetes クラスターのセットアップ要件

名前空間の命名
各 Kubernetes リージョンクラスターで、名前空間に固有の名前を付けます。
Kubernetes リージョンクラスター間でフラットなポッドネットワーキング
Pod CIDRs across the Kubernetes clusters must not overlap.
Kubernetes リージョンクラスター間の DNS 解決と TCP 通信

Kubernetes クラスターは、他のクラスターの内部 DNS を解決し、他のクラスターの内部ポッドへとルーティングできなければなりません。

リージョンクラスターの DNS を公開するには、kube-dns または CoreDNS を使用します。

ファイアウォールルール

すべてのリージョンクラスターのポッドのサブネットワークで、標準的な ZooKeeper、Kafka、Schema Registry のポートでの TCP トラフィックを許可します。

For specific configuration and validation steps on various platforms, specifically, GKE, EKS, and AKS, see MRC Networking in the CFK example repo.

Kubernetes コンテキスト

複数の Kubernetes クラスターを使用する場合、Kubernetes クラスター、ユーザー、名前空間を指定する特定のコンテキストで、kubectl コマンドがクラスターに対して実行されます。

--context <cluster-context>kubectl コマンドに追加すると、確実に適切なクラスターに対してコマンドを実行できます。

マルチリージョンクラスターでの Confluent Platform の構成

CFK は、複数の Kubernetes リージョンクラスターで個別の Kafka ブローカー id とコンポーネントサーバー id(ZooKeeper および Schema Registry)を使用して、各 Confluent コンポーネントの論理マルチリージョンクラスターを作成し、管理します。

  1. Confluent for Kubernetes のデプロイ」の説明に従って、CFK を各リージョンにデプロイします。

  2. ZooKeeper を構成します。

    1. ZooKeeper の CR の annotations を使用して、ZooKeeper サーバー id オフセットを、各 Kubernetes リージョンクラスターで異なる数字に設定します。

      例を次に示します。

      metadata:
        annotations:
          platform.confluent.io/zookeeper-myid-offset: 100
      

      デフォルトは 0 です。

      このオフセットは、各リージョンでの将来的なクラスターの増加に備えて、100200300 のように柔軟に拡張できます。

      このオフセットは、一度設定すると変更できません。このため、クラスターをデプロイする前に、これらのオフセットをどの程度まで拡張するかを慎重に検討する必要があります。

    2. ピア ZooKeeper サーバーを spec.configOverrides.peers プロパティに指定します。例を次に示します。

      spec:
        configOverrides:
          peers:
            - server.0=zookeeper-0.zookeeper.central.svc.cluster.local:2888:3888
            - server.10=zookeeper-0.zookeeper.east.svc.cluster.local:2888:3888
            - server.20=zookeeper-0.zookeeper.west.svc.cluster.local:2888:3888
      
  3. Kafka を構成します。

    1. ブローカー id オフセットを、各リージョンの Kafka の CR で異なる数字に設定します。

      例を次に示します。

      metadata:
        annotations:
          platform.confluent.io/broker-id-offset: 100
      

      デフォルトは 0 です。

      このオフセットは、各リージョンでの将来的なクラスターの増加に備えて、100200300 のように柔軟に拡張できます。

      このオフセットは、一度設定すると変更できません。このため、クラスターをデプロイする前に、これらのオフセットをどの程度まで拡張するかを慎重に検討する必要があります。

    2. Kafka の CR で、ZooKeeper エンドポイントのコンマ区切りのリストを spec.dependencies.zookeeper.endpoint に指定します。この値は、Kubernetes クラスター全体のすべての Kafka の CR で同じである必要があります。

      例を次に示します。

      spec:
        dependencies:
          zookeeper:
            endpoint: zookeeper.central.svc.cluster.local:2182/mrc,zookeeper.east.svc.cluster.local:2182/mrc,zookeeper.west.svc.cluster.local:2182/mrc
      

      The ZooKeeper node id (mrc in the above example) can be any string, but it needs to be the same for all the Kafka deployments in a MRC.

      If you are deploying multiple MRCs utilizing the same ZooKeeper, use different node ids, for example, mrc1, mrc2, etc., in each MRC.

      この値は、クラスターの作成後に変更できません。変更すると、データが失われます。

    3. ロードバランサー、ノードポート、または静的なホストベースの Ingress コントローラールーティングを介した Kafka ブローカーへの外部アクセスを構成します。詳細については、「Confluent Platform のネットワークの概要」を参照してください。

  4. 各 Kubernetes リージョンクラスターにデプロイする Schema Registry を構成します。

    Kubernetes リージョンクラスター全体に Schema Registry の論理クラスターを形成するには、Schema Registry の CR で以下のプロパティを指定します。

    • spec.dependencies.kafka.bootstrapEndpoint: すべての Kubernetes リージョンクラスターの Kafka エンドポイントのコンマ区切りのリスト
    • spec.configOverrides.server.schema.registry.group.id: すべての Kubernetes リージョンクラスターですべての Schema Registry サービスに同じグループ id を使用します
    • spec.configOverrides.server.kafkastore.topic: このログのトピック名に _ で始まる文字列を指定します。すべての Kubernetes リージョンクラスターですべての Schema Registry サービスに同じ値を使用します。

    例を次に示します。

    spec:
      dependencies:
        kafka:
          bootstrapEndpoint: kafka.central.svc.cluster.local:9071,kafka.east.svc.cluster.local:9071,kafka.west.svc.cluster.local:9071
      configOverrides:
        server:
          - schema.registry.group.id=schema-registry-mrc
          - kafkastore.topic=_schemas_mrc
    

    マルチリージョン Schema Registry のデプロイの詳細については、「マルチデータセンター構成」を参照してください。

  5. Configure the remaining Confluent Platform components, including Control Center, Connect, and ksqlDB, to deploy in one Kubernetes region cluster and utilize the stretched Kafka.

    コンポーネントの CR で、Kafka エンドポイントのコンマ区切りのリストを指定します。

    例を次に示します。

    spec:
      dependencies:
        kafka:
          bootstrapEndpoint: kafka.central.svc.cluster.local:9071,kafka.east.svc.cluster.local:9071,kafka.west.svc.cluster.local:9071
    
  6. Apply the CRs with the kubectl apply -f <component CRs>.