1. Home
2. Confluent for Kubernetes
3. Confluent Platform の構成
4. Confluent Platform ネットワークの構成

a.. _co-loadbalancers:

Confluent コンポーネントにアクセスするためのロードバランサーの構成

ロードバランサーを使用した Kafka への外部アクセス

クライアントによる Kafka クラスターへのアクセスでは、まずブートストラップサーバーへの接続が行われ、クラスターに属するすべてのブローカーのメタデータリストが取得されます。次に、クライアントにより、関心の対象であるブローカーのアドレスが検出され、データを生成または消費するためにブローカーへの直接接続が行われます。ロードバランサーを使用するように構成すると、CFK により、ブートストラップサーバー用のロードバランサーに加えて、各ブローカー用のロードバランサーが作成されます。Kafka ブローカーが N 個であれば、CFK によってロードバランサーサービスが N+1 個作成されます。

• 1 個は、初期接続と Kafka クラスターに関するメタデータの受信に使用するブートストラップサービスとして作成されます。
• 残りの N 個のサービスは、各ブローカーにつき 1 個で、ブローカーに直接対応します。

ロードバランサーを使用して Kafka への外部アクセスを実現するには

1. Kafka カスタムリソース（CR）で次のように設定し、構成を適用します。

   spec:
     listeners:
       external:
         externalAccess:
           type: loadBalancer
           loadBalancer:
             domain:           --- [1]
             bootstrapPrefix:  --- [2]
             brokerPrefix:     --- [3]
             advertisedPort:   --- [4]
   

   • [1]（必須）Kubernetes クラスターが実行されているドメインに設定します。

     実行中のクラスターでこの値を変更する場合、クラスターをローリングする必要があります。

   • [2]（省略可）``bootstrapPrefix`` を使用して、デフォルトの Kafka ブートストラッププレフィックスを変更します。デフォルトのブートストラッププレフィックスは Kafka コンポーネント名（kafka）です。

     この値は DNS エントリに使用されます。ブートストラップ DNS 名は <bootstrapPrefix>.<domain> となります。

     設定されていない場合、デフォルトのブートストラップ DNS 名は kafka.<domain> です。

     複数の Kafka クラスターを実行しているときは、DNS の競合を避けるために、コンポーネントごとにデフォルトプレフィックスの変更が必要となる場合があります。

   • [3]（省略可）``brokerPrefix:`` を使用して、デフォルトの Kafka ブローカープレフィックスを変更します。デフォルトの Kafka ブローカープレフィックスは b です。

     これらは DNS エントリに使用されます。ブローカー DNS 名は <brokerPrefix>0.<domain>、<brokerPrefix>1.<domain>、などとなります。

     設定されていない場合、デフォルトのブローカー DNS 名は b0.<domain>、b1.<domain>、などとなります。

     複数の Kafka クラスターを実行しているときは、DNS の競合を避けるためにデフォルトプレフィックスの変更が必要となる場合があります。

     実行中のクラスターでこの値を変更する場合、クラスターをローリングする必要があります。

   • [4]（省略可）``advertisedPort`` を使用して Kafka の外部アクセス用のデフォルトポート（9092）をオーバーライドします。

2. Kafka のブートストラップサーバーとブローカー用に DNS エントリを追加します。

   外部ロードバランサーが作成されたら、Kafka ブローカーと Kafka ブートストラップサービスの DNS エントリを DNS テーブル（または、プロバイダー環境によって認識された DNS エントリの取得に使用する手段）に追加します。

   Kafka ブローカーの DNS エントリを取得するには以下が必要です。

   • Kubernetes クラスターのドメイン名（ステップ 1 の domain）

   • Kafka ロードバランサーの外部 IP。

     外部 IP を取得するには、以下のコマンドを使用します。

     kubectl get services -n <namespace> | grep LoadBalancer
     

   • Kafka のブートストラッププレフィックスとブローカープレフィックス

   以下に示したのは、DNS テーブルのエントリの例です。各項目が次のように指定されています。

   • ドメイン: example.com
   • デフォルトのプレフィックスを使用するブローカーレプリカ 3 個: b
   • Kafka ブートストラッププレフィックス: kafka

   DNS name               External IP
   b0.example.com         192.50.14.35
   b1.example.com         192.50.28.28
   b2.example.com         192.50.64.18
   kafka.example.com      192.50.34.20
   

ロードバランサーを使用した MDS への外部アクセス

ロールベースアクセス制御（RBAC）を有効にして MDS への外部アクセスをセットアップする場合、追加でネットワーク構成の手順が必要になります。

ロードバランサータイプの外部アクセスを指定すると、Kubernetes に MDS 用のロードバランサーサービスが追加で作成されます。

Kafka Metadata Service (MDS) への外部アクセスをサポートするには、Kafka のカスタムリソース（CR）で以下のように構成します。

ロードバランサーを使用して MDS への外部アクセスを実現するには

Kafka の CR で次のように設定し、構成を適用します。

spec
  services
    mds:
      externalAccess:
        type: loadBalancer
        loadBalancer:
          domain:                --- [1]
          port:                  --- [2]
          prefix:                --- [3]
          advertisedURL:         --- [4]

• [1]（必須）MDS のドメイン名。

• [2] MDS に外部アクセスするためのポート。設定されていない場合、MDS に外部アクセスするためのエンドポイントは、以下のようにデフォルトのポートを使用します。

  • ロードバランサーを使用して、外部から HTTPS で MDS にアクセスするためのエンドポイントは、https://<prefix>.<domain>:443 です。
  • ロードバランサーを使用して、外部から HTTP で MDS にアクセスするためのエンドポイントは、http://<prefix>.<domain>:80 です。

• [3] 設定されている場合、MDS エンドポイントは https://<prefix>.<domain>:<port> です。省略されている場合、MDS エンドポイントはデフォルトの `` https://<domain>:<port>`` です。

• [4] 設定されている場合、内部のエンドポイントを使用するのではなく、各ブローカーの MDS にアドバタイズされるリスナーが <httpSchema>://<advertisedUrl.prefix><podId>.<domain> に設定されます。<podId> の範囲は 0 から replicaCount -1 です。

  このプロパティは、内部 SAN を MDS の TLS 証明書に追加できない場合にのみ使用します。また、外部 DNS は Kubernetes クラスター内で解決する必要があります。

ロードバランサーを使用した他の Confluent Platform コンポーネントへの外部アクセス

外部クライアントは、ロードバランサーを使用して他の Confluent Platform コンポーネントに接続することができます。

注釈

Kafka ブローカーと ZooKeeper との間には常時接続が維持されますが、ロードバランサーが ZooKeeper 用に使用されると切断のおそれが生じます。ロードバランサーを ZooKeeper 用には構成しないでください。

各 Confluent Platform コンポーネントのアクセスエンドポイントは <component CR name>.<Kubernetes domain> となります。

たとえば、TLS が有効な example.com ドメインでは、Confluent Platform コンポーネントへのアクセスに以下のエンドポイントを使用します。

• https://connect.example.com
• https://replicator.example.com
• https://schemaregistry.example.com
• https://ksql.example.com
• https://controlcenter.example.com
• https://kafkarestproxy.example.com

ロードバランサーを使用して Kafka への外部アクセスを実現するには

1. コンポーネントの CR で次のように設定し、構成を適用します。

   spec:
     externalAccess:
       type: loadBalancer
       loadBalancer:
         domain:                 --- [1]
         prefix:                 --- [2]
   
         sessionAffinity:        --- [3]
         sessionAffinityConfig:  --- [4]
           clientIP:
             timeoutSeconds:     --- [5]
   

   • [1]（必須）``domain`` を、Kubernetes クラスターのドメイン名に設定します。

     実行中のクラスターでこの値を変更する場合、クラスターをローリングする必要があります。

   • [2]（省略可）``prefix`` を設定して、デフォルトのロードバランサープレフィックスを変更します。デフォルトでは、コンポーネント名です（例: controlcenter、connect、replicator、schemaregistry、ksql）。

     この値は DNS エントリに使用されます。コンポーネントの DNS 名は <prefix>.<domain> となります。

     設定されていない場合のデフォルトの DNS 名は <component name>.<domain> になります（例: controlcenter.example.com）。

     複数の Kafka クラスターを実行しているときは、DNS の競合を避けるために、コンポーネントごとにデフォルトプレフィックスの変更が必要となる場合があります。

     実行中のクラスターでこの値を変更する場合、クラスターをローリングする必要があります。

   • [3] コンシューマー REST Proxy でクライアント IP ベースのセッションアフィニティを有効にする場合に必須です。

     REST Proxy を Kafka コンシューマーで使用する場合は、 ClientIP に設定します。セッションアフィニティの詳細については、「Kubernetes Service」を参照してください。

   • [4] [3] で sessionAffinity: ClientIP を設定した場合に、セッションアフィニティの構成を格納します。

   • [5] ClientIP タイプのセッションのスティッキー時間（秒数）を指定します。この値は、0 より大きく、86400 （1 日）以下でなければなりません。

     デフォルト値は 10800 （3 時間）です。

2. ロードバランサーを追加した各 Confluent Platform コンポーネントの DNS エントリを追加します。

   外部ロードバランサーが作成されたら、コンポーネントロードバランサーに関連付けられた DNS エントリを DNS テーブル（または、プロバイダー環境によって認識された DNS エントリの取得に使用する手段）に追加します。

   Confluent Platform コンポーネントの DNS エントリを取得するには以下が必要です。

   • ステップ 1 で設定した Kubernetes クラスターのドメイン名

   • コンポーネントのロードバランサーの外部 IP

     外部 IP を取得するには、以下のコマンドを使用します。

     kubectl get services -n <namespace> -ojson
     

   • コンポーネントの prefix （前述のステップ 1 で設定した場合）。それ以外の場合は、デフォルトのコンポーネント名。

   DNS 名は prefix と domain 名から成ります（例: controlcenter.example.com）。

ロードバランサーを使用した外部アクセスの構成に関するチュートリアルのシナリオについては、ロードバランサーの使用に関するクイックスタートチュートリアル を参照してください。

ロードバランサーを使用した Confluent コンポーネントへの内部アクセス

Kubernetes がプライベートサブネット内または VPC ピアリングされたクラスターの範囲内で実行されている場合は、Kafka や他の Confluent Platform コンポーネントの間で VPC 対 VPC のピアリング接続に使用される内部ロードバランサーを構成できます。

内部ロードバランサーを設定するには、内部アノテーションにより外部リスナーを使用します。

Kafka の CR は以下のようになります。

spec:
    listeners:
      external:
        externalAccess:
          loadBalancer:
            annotations:         --- [*]

その他の Confluent コンポーネントの CR は以下のようになります。

spec:
  externalAccess:
    type: loadBalancer
    loadBalancer:
      annotations:               --- [*]

[*] 以下のプロバイダー固有アノテーションを追加して、該当プロバイダー用の内部ロードバランサーを作成します。

Azure

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

AWS

service.beta.kubernetes.io/aws-load-balancer-internal: "0.0.0.0/0"

インターネットからのすべてのトラフィックを許可するセキュリティグループの作成が望ましくない場合は、より厳格な CIDR を指定できます。

GCP

cloud.google.com/load-balancer-type: "Internal"

その他のロードバランサー設定については、Kafka にアクセスする場合は「ロードバランサーを使用した Kafka への外部アクセス」を、他の Confluent Platform コンポーネントにアクセスする場合は「ロードバランサーを使用した他の Confluent Platform コンポーネントへの外部アクセス」をそれぞれ参照してください。