6.3. Kafka のデプロイ

Cluster Operator で Kafka クラスターを管理できるようにするには、これを Kafka リソースとしてデプロイする必要があります。Streams for Apache Kafka では、これを行うためにデプロイメントファイルのサンプルが提供されます。これらのファイルを使用して、Topic Operator および User Operator を同時にデプロイできます。

Cluster Operator をデプロイしたら、Kafka リソースを使用して次のコンポーネントをデプロイします。

KRaft または ZooKeeper を使用する Kafka クラスター:
- ノードプールを備えた KRaft ベースまたは ZooKeeper ベースの Kafka クラスター
- ノードプールを使用しない ZooKeeper ベースの Kafka クラスター
Topic Operator
User Operator

ノードプールは、Kafka ノードのセットの設定を提供します。ノードプールを使用すると、同じ Kafka クラスター内でノードに異なる設定を持たせることができます。

Kafka クラスターを Kafka リソースとしてデプロイしていない場合は、Cluster Operator を使用してこのクラスターを管理できません。これには、OpenShift 外で実行されている Kafka クラスターなどが該当します。ただし、Topic Operator と User Operator をスタンドアロンコンポーネントとしてデプロイすることで、それらを Streams for Apache Kafka によって 管理されていない Kafka クラスターで使用できます。また、Streams for Apache Kafka によって管理されていない Kafka クラスターで、その他の Kafka コンポーネントをデプロイして使用することもできます。

6.3.1. ノードプールを使用した Kafka クラスターのデプロイ

この手順では、Cluster Operator を使用して、ノードプールを持つ Kafka を OpenShift クラスターにデプロイする方法を示します。ノードプールは、同じ設定を共有する Kafka クラスター内の Kafka ノードの個別のグループを表します。ノードプール内の各 Kafka ノードについて、ノードプールで定義されていない設定は、kafka リソースのクラスター設定から継承されます。

デプロイメントでは、YAML ファイルの仕様を使用して KafkaNodePool リソースが作成されます。クラスター管理に KRaft (Kafka Raft メタデータ) モードまたは ZooKeeper を使用する Kafka クラスターでノードプールを使用できます。Kafka クラスターを KRaft モードでデプロイするには、KafkaNodePool リソースを使用する必要があります。

Streams for Apache Kafka には、ノードプールを使用する Kafka クラスターの作成に使用できる次のサンプルファイルが用意されています。

kafka-with-dual-role-kraft-nodes.yaml: ブローカーとコントローラーのロールを共有する KRaft ノードの 1 つのプールを備えた Kafka クラスターをデプロイします。
kafka-with-kraft.yaml: コントローラーノードの 1 つのプールとブローカーノードの 1 つのプールを備えた永続的な Kafka クラスターをデプロイします。
kafka-with-kraft-ephemeral.yaml: コントローラーノードの 1 つのプールとブローカーノードの 1 つのプールを備えた一時的な Kafka クラスターをデプロイします。
kafka.yaml: 3 つのノードと 2 つの異なる Kafka ブローカープールを備えた ZooKeeper をデプロイします。各プールには 3 つのブローカーがあります。この例のプールは、異なるストレージ設定を使用しています。

注記

ここで説明する手順を実行して、KafkaNodePool リソースを使用して新しい Kafka クラスターをデプロイしたり、既存の Kafka クラスターを移行したりできます。

前提条件

Cluster Operator がデプロイされている。

手順

KRaft ベースの Kafka クラスターをデプロイします。
- デュアルロールノードを使用する単一ノードプールを備えた Kafka クラスターを KRaft モードでデプロイするには、次の手順を実行します。
```
oc apply -f examples/kafka/kraft/kafka-with-dual-role-nodes.yaml
```
- ブローカーノードとコントローラーノードに個別のノードプールを使用して永続的な Kafka クラスターを KRaft モードでデプロイするには、次の手順を実行します。
```
oc apply -f examples/kafka/kraft/kafka.yaml
```
- ブローカーノードとコントローラーノードに個別のノードプールを使用して KRaft モードでエフェメラル Kafka クラスターをデプロイするには、以下を実行します。
```
oc apply -f examples/kafka/kraft/kafka-ephemeral.yaml
```
- 3 つのブローカーの 2 つのノードプールを備えた Kafka クラスターと ZooKeeper クラスターをデプロイするには、次の手順を実行します。
```
oc apply -f examples/kafka/kafka-with-node-pools.yaml
```
デプロイメントのステータスを確認します。
```
oc get pods -n <my_cluster_operator_namespace>
```
出力にはノードプール名と準備状況が表示されます
```
NAME                        READY  STATUS   RESTARTS
my-cluster-entity-operator  3/3    Running  0
my-cluster-pool-a-0         1/1    Running  0
my-cluster-pool-a-1         1/1    Running  0
my-cluster-pool-a-4         1/1    Running  0
```
- my-cluster は Kafka クラスターの名前です。
- pool-a はノードプールの名前です。
  0 で始まる連続したインデックス番号は、作成された各 Kafka Pod を識別します。ZooKeeper を使用している場合は、ZooKeeper Pod も表示されます。
  READY は、Ready/expected 状態のレプリカ数を表示します。STATUS が Running と表示されれば、デプロイメントは成功です。
  デプロイに関する情報は、プール内のノードの ID のリストなど、KafkaNodePool リソースのステータスにも表示されます。
  注記
  ノード ID は、クラスター内のすべてのノードプールにわたって 0 (ゼロ) から順番に割り当てられます。これは、ノード ID が特定のノードプール内で連続して実行されない可能性があることを意味します。クラスター全体のノード ID のシーケンスにギャップがある場合、追加される次のノードにはギャップを埋める ID が割り当てられます。スケールダウンすると、プール内で最も大きな数のノード ID を持つノードが削除されます。

関連情報

ノードプールの設定

6.3.2. ノードプールを使用しない ZooKeeper ベースの Kafka クラスターのデプロイ

この手順では、Cluster Operator を使用して ZooKeeper ベースの Kafka クラスターを OpenShift クラスターにデプロイする方法を示します。

デプロイメントでは、YAML ファイルの仕様を使用して Kafka リソースが作成されます。

Streams for Apache Kafka には、クラスター管理に ZooKeeper を使用する Kafka クラスターを作成するための次のサンプルファイルが用意されています。

kafka-persistent.yaml: 3 つの Zookeeper ノードと 3 つの Kafka ノードを使用して永続クラスターをデプロイします。
kafka-jbod.yaml: それぞれが複数の永続ボリューを使用する、3 つの ZooKeeper ノードと 3 つの Kafka ノードを使用して、永続クラスターをデプロイします。
kafka-persistent-single.yaml: 1 つの ZooKeeper ノードと 1 つの Kafka ノードを使用して、永続クラスターをデプロイします。
kafka-ephemeral.yaml: 3 つの ZooKeeper ノードと 3 つの Kafka ノードを使用して、一時クラスターをデプロイします。
kafka-ephemeral-single.yaml: 3 つの ZooKeeper ノードと 1 つの Kafka ノードを使用して、一時クラスターをデプロイします。

この手順では、一時および永続 Kafka クラスターデプロイメントの例を使用します。

一時クラスター

通常、Kafka の一時クラスターは開発およびテスト環境での使用に適していますが、本番環境での使用には適していません。このデプロイメントでは、ブローカー情報 (ZooKeeper) と、トピックまたはパーティション (Kafka) を格納するための emptyDir ボリュームが使用されます。emptyDir ボリュームを使用すると、その内容は Pod のライフサイクルと厳密な関係を持つため、Pod がダウンすると削除されます。

永続クラスター

Kafka の永続クラスターでは、永続ボリュームを使用して ZooKeeper および Kafka データを格納します。PersistentVolumeClaim を使用して PersistentVolume が取得され、PersistentVolume の実際のタイプには依存しません。PersistentVolumeClaim で StorageClass を使用し、自動ボリュームプロビジョニングをトリガーすることができます。StorageClass が指定されていない場合、OpenShift はデフォルトの StorageClass を使用しようとします。

次の例では、一般的なタイプの永続ボリュームを一部紹介しています。

OpenShift クラスターが Amazon AWS で実行されている場合、OpenShift は Amazon EBS ボリュームをプロビジョニングできます。
OpenShift クラスターが Microsoft Azure で実行されている場合、OpenShift は Azure Disk Storage ボリュームをプロビジョニングできます。
OpenShift クラスターが Google Cloud で実行されている場合、OpenShift は永続ディスクボリュームをプロビジョニングできます
OpenShift クラスターがベアメタルで実行されている場合、OpenShift はローカル永続ボリュームをプロビジョニングできます

このサンプル YAML ファイルは、最新のサポート対象 Kafka バージョン、サポート対象のログメッセージ形式バージョンとブローカー間のプロトコルバージョンの設定を指定します。Kafka config の inter.broker.protocol.version プロパティーは、指定された Kafka バージョン (spec.kafka.version) によってサポートされるバージョンである必要があります。このプロパティーは、Kafka クラスターで使用される Kafka プロトコルのバージョンを表します。

Kafka 3.0.0 以降、inter.broker.protocol.version が 3.0 以上に設定されていると、log.message.format.version オプションは無視されるため、設定する必要はありません。

サンプルクラスターの名前はデフォルトで my-cluster になります。クラスター名はリソースの名前によって定義され、クラスターがデプロイされた後に変更できません。クラスターをデプロイする前にクラスター名を変更するには、関連する YAML ファイルにある Kafka リソースの Kafka.metadata.name プロパティーを編集します。

デフォルトのクラスター名および指定された Kafka バージョン

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    version: 3.7.0
    #...
    config:
      #...
      log.message.format.version: "3.7"
      inter.broker.protocol.version: "3.7"
  # ...

前提条件

Cluster Operator がデプロイされている。

手順

ZooKeeper ベースの Kafka クラスターをデプロイします。
- 一時クラスターをデプロイするには、以下を実行します。
```
oc apply -f examples/kafka/kafka-ephemeral.yaml
```
- 永続クラスターをデプロイするには、以下を実行します。
```
oc apply -f examples/kafka/kafka-persistent.yaml
```
デプロイメントのステータスを確認します。
```
oc get pods -n <my_cluster_operator_namespace>
```
Pod 名および readiness が表示される出力
```
NAME                        READY   STATUS    RESTARTS
my-cluster-entity-operator  3/3     Running   0
my-cluster-kafka-0          1/1     Running   0
my-cluster-kafka-1          1/1     Running   0
my-cluster-kafka-2          1/1     Running   0
my-cluster-zookeeper-0      1/1     Running   0
my-cluster-zookeeper-1      1/1     Running   0
my-cluster-zookeeper-2      1/1     Running   0
```
my-cluster は Kafka クラスターの名前です。
0 で始まる連続インデックス番号は、作成された各 Kafka および ZooKeeper Pod を識別します。
デフォルトのデプロイメントでは、Entity Operator クラスター、3 つの Kafka Pod、および 3 つの ZooKeeper Pod を作成します。
READY は、Ready/expected 状態のレプリカ数を表示します。STATUS が Running と表示されれば、デプロイメントは成功です。

関連情報

Kafka クラスターの設定

6.3.3. Cluster Operator を使用した Topic Operator のデプロイ

この手順では、Cluster Operator を使用して Topic Operator をデプロイする方法を説明します。Topic Operator は、双方向モードまたは一方向モードのいずれかで使用するためにデプロイメントできます。双方向および一方向のトピック管理の詳細は、「トピック管理モード」を参照してください。

Kafka リソースの entityOperator プロパティーを設定し、topicOperator が含まれるようにします。デフォルトでは、Topic Operator は Cluster Operator によってデプロイされた Kafka クラスターの namespace で KafkaTopic リソースを監視します。Topic Operator spec で watchedNamespace を使用して namespace を指定することもできます。1 つの Topic Operator が監視できるのは、namespace 1 つです。1 つの namespace を監視するのは、Top Operator 1 つのみとします。

Streams for Apache Kafka を使用して複数の Kafka クラスターを同じ namespace にデプロイする場合は、1 つの Kafka クラスターに対してのみ Topic Operator を有効にするか、watchedNamespace プロパティーを使用して Topic Operator が他の namespace を監視するように設定します。

Streams for Apache Kafka によって管理されない Kafka クラスターを Topic Operator と使用する場合は、Topic Operator をスタンドアロンコンポーネントとしてデプロイする必要があります。

entityOperator および topicOperator プロパティーの設定に関する詳細は、Configuring the Entity Operator を参照してください。

前提条件

Cluster Operator がデプロイされている。

手順

Kafka リソースの entityOperator プロパティーを編集し、topicOperator が含まれるようにします。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  #...
  entityOperator:
    topicOperator: {}
    userOperator: {}

EntityTopicOperatorSpec スキーマリファレンスで説明されているプロパティーを使用して、Topic Operator の spec を設定します。
すべてのプロパティーにデフォルト値を使用する場合は、空のオブジェクト ({}) を使用します。
リソースを作成または更新します。
```
oc apply -f <kafka_configuration_file>
```
デプロイメントのステータスを確認します。
```
oc get pods -n <my_cluster_operator_namespace>
```
Pod 名と準備状況が表示される出力
```
NAME                        READY   STATUS    RESTARTS
my-cluster-entity-operator  3/3     Running   0
# ...
```
my-cluster は Kafka クラスターの名前です。
READY は、Ready/expected 状態のレプリカ数を表示します。STATUS が Running と表示されれば、デプロイメントは成功です。

6.3.4. Cluster Operator を使用した User Operator のデプロイ

この手順では、Cluster Operator を使用して User Operator をデプロイする方法を説明します。

Kafka リソースの entityOperator プロパティーを設定し、userOperator が含まれるようにします。デフォルトでは、User Operator は Kafka クラスターデプロイメントの namespace で KafkaUser リソースを監視します。User Operator spec で watchedNamespace を使用して namespace を指定することもできます。1 つの User Operator が監視できるのは、namespace 1 つです。1 つの namespace を監視するのは、User Operator 1 つのみとします。

Streams for Apache Kafka によって管理されていない Kafka クラスターを User Operator と使用する場合は、User Operator をスタンドアロンコンポーネントとしてデプロイする必要があります。

entityOperator および userOperator プロパティーの設定に関する詳細は、Configuring the Entity Operator を参照してください。

前提条件

Cluster Operator がデプロイされている。

手順

Kafka リソースの entityOperator プロパティーを編集し、userOperator が含まれるようにします。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  #...
  entityOperator:
    topicOperator: {}
    userOperator: {}

EntityUserOperatorSpec スキーマリファレンスに記載されているプロパティーを使用して、User Operator の spec を設定します。
すべてのプロパティーにデフォルト値を使用する場合は、空のオブジェクト ({}) を使用します。
リソースを作成または更新します。
```
oc apply -f <kafka_configuration_file>
```
デプロイメントのステータスを確認します。
```
oc get pods -n <my_cluster_operator_namespace>
```
Pod 名と準備状況が表示される出力
```
NAME                        READY   STATUS    RESTARTS
my-cluster-entity-operator  3/3     Running   0
# ...
```
my-cluster は Kafka クラスターの名前です。
READY は、Ready/expected 状態のレプリカ数を表示します。STATUS が Running と表示されれば、デプロイメントは成功です。

6.3.5. ターミナルからの ZooKeeper への接続

ZooKeeper サービスは暗号化と認証によって保護されており、Streams for Apache Kafka の一部でない外部アプリケーションでの使用は想定されていません。

ただし、ZooKeeper への接続が必要な CLI ツールを使用する場合は、ZooKeeper Pod 内の端末を使用して、ZooKeeper アドレスとして localhost:12181 に接続できます。

前提条件

利用可能な OpenShift クラスター
稼働中の Kafka クラスター
Cluster Operator が稼働中である。

手順

OpenShift コンソールを使用してターミナルを開くか、CLI から exec コマンドを実行します。
以下に例を示します。
```
oc exec -ti my-cluster-zookeeper-0 -- bin/zookeeper-shell.sh localhost:12181 ls /
```
必ず localhost:12181 を使用してください。

6.3.6. Kafka クラスターリソースのリスト

以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。

共有リソース

<kafka_cluster_name>-cluster-ca: クラスター通信の暗号化に使用されるクラスター CA プライベートキーのあるシークレット。
<kafka_cluster_name>-cluster-ca-cert: クラスター CA 公開鍵のあるシークレット。このキーは、Kafka ブローカーのアイデンティティーの検証に使用できます。
<kafka_cluster_name>-clients-ca: ユーザー証明書に署名するために使用されるクライアント CA 秘密鍵のあるシークレット。
<kafka_cluster_name>-clients-ca-cert: クライアント CA 公開鍵のあるシークレット。このキーは、Kafka ユーザーのアイデンティティーの検証に使用できます。
<kafka_cluster_name>-cluster-operator-certs: Kafka および ZooKeeper と通信するための Cluster Operator キーのあるシークレット。

ZooKeeper ノード

<kafka_cluster_name>-zookeeper

以下の ZooKeeper リソースに指定された名前。

ZooKeeper ノード Pod を管理するための StrimziPodSet。
ZooKeeper ノードで使用されるサービスアカウント。
ZooKeeper ノードに設定された PodDisruptionBudget。

<kafka_cluster_name>-zookeeper-<pod_id>

StrimziPodSet によって作成された Pod。

<kafka_cluster_name>-zookeeper-nodes

DNS が ZooKeeper Pod の IP アドレスを直接解決するのに必要なヘッドレスサービス。

<kafka_cluster_name>-zookeeper-client

Kafka ブローカーがクライアントとして ZooKeeper ノードに接続するために使用するサービス。

<kafka_cluster_name>-zookeeper-config

ZooKeeper 補助設定が含まれ、ZooKeeper ノード Pod によってボリュームとしてマウントされる ConfigMap。

<kafka_cluster_name>-zookeeper-nodes

ZooKeeper ノードキーがあるシークレット。

<kafka_cluster_name>-network-policy-zookeeper

ZooKeeper サービスへのアクセスを管理するネットワークポリシー。

data-<kafka_cluster_name>-zookeeper-<pod_id>

特定の ZooKeeper ノードのデータを保存するために使用されるボリュームの永続ボリューム要求。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。

Kafka ブローカー

<kafka_cluster_name>-kafka

以下の Kafka リソースに指定された名前。

Kafka ブローカー Pod を管理するための StrimziPodSet。
Kafka Pod によって使用されるサービスアカウント。
Kafka ブローカーに設定された PodDisruptionBudget。

<kafka_cluster_name>-kafka-<pod_id>

以下の Kafka リソースに指定された名前。

StrimziPodSet によって作成された Pod。
Kafka ブローカー設定を使用した ConfigMap。

<kafka_cluster_name>-kafka-brokers

DNS が Kafka ブローカー Pod の IP アドレスを直接解決するのに必要なサービス。

<kafka_cluster_name>-kafka-bootstrap

サービスは、OpenShift クラスター内から接続する Kafka クライアントのブートストラップサーバーとして使用できます。

<kafka_cluster_name>-kafka-external-bootstrap

OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いサービス名が使用されます。

<kafka_cluster_name>-kafka-<pod_id>

トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いサービス名が使用されます。

<kafka_cluster_name>-kafka-external-bootstrap

OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いルート名が使用されます。

<kafka_cluster_name>-kafka-<pod_id>

OpenShift クラスターの外部から個別の Pod へのトラフィックに対するルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。リスナー名が external でポートが 9094 の場合、後方互換性のために古いルート名が使用されます。

<kafka_cluster_name>-kafka-<listener_name>-bootstrap

OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。新しいサービス名はその他すべての外部リスナーに使用されます。

<kafka_cluster_name>-kafka-<listener_name>-<pod_id>

トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。新しいサービス名はその他すべての外部リスナーに使用されます。

<kafka_cluster_name>-kafka-<listener_name>-bootstrap

OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。新しいルート名はその他すべての外部リスナーに使用されます。

<kafka_cluster_name>-kafka-<listener_name>-<pod_id>

OpenShift クラスターの外部から個別の Pod へのトラフィックに対するルート。このリソースは、外部リスナーが有効でタイプが route に設定されている場合にのみ作成されます。新しいルート名はその他すべての外部リスナーに使用されます。

<kafka_cluster_name>-kafka-config

Kafka の補助設定を含む ConfigMap。UseStrimziPodSets フィーチャーゲートが無効な場合、ブローカー Pod によってボリュームとしてマウントされます。

<kafka_cluster_name>-kafka-brokers

Kafka ブローカーキーのあるシークレット。

<kafka_cluster_name>-network-policy-kafka

Kafka サービスへのアクセスを管理するネットワークポリシー。

strimzi-namespace-name-<kafka_cluster_name>-kafka-init

Kafka ブローカーによって使用されるクラスターロールバインディング。

<kafka_cluster_name>-jmx

Kafka ブローカーポートのセキュア化に使用される JMX ユーザー名およびパスワードのあるシークレット。このリソースは、Kafka で JMX が有効になっている場合にのみ作成されます。

data-<kafka_cluster_name>-kafka-<pod_id>

特定の Kafka ブローカーのデータを保存するために使用されるボリュームの永続ボリューム要求。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。

data-<id>-<kafka_cluster_name>-kafka-<pod_id>

特定の Kafka ブローカーのデータを保存するために使用されるボリューム id の永続ボリューム要求。このリソースは、永続ボリュームをプロビジョニングしてデータを保存するときに、JBOD ボリュームに永続ストレージが選択された場合のみ作成されます。

Kafka ノードプール

Kafka ノードプールを使用している場合、作成されたリソースは、ノードがブローカー、コントローラー、またはその両方として動作しているかどうかに関係なく、ノードプールで管理されているノードに適用されます。命名規則には、Kafka クラスターとノードプールの名前が含まれます (<kafka_cluster_name>-<pool_name>)。

<kafka_cluster_name>-<pool_name>

Kafka ノードプールを管理するために StrimziPodSet に指定された名前。

<kafka_cluster_name>-<pool_name>-<pod_id>

次の Kafka ノードプールリソースに与えられた名前。

StrimziPodSet によって作成された Pod。
Kafka ノード設定を使用した ConfigMap。

data-<kafka_cluster_name>-<pool_name>-<pod_id>

特定のノードのデータを保存するために使用されるボリュームに対する永続ボリューム要求。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。

data-<id>-<kafka_cluster_name>-<pool_name>-<pod_id>

特定のノードのデータを保存するために使用されるボリューム id に対する永続ボリューム要求。このリソースは、永続ボリュームをプロビジョニングしてデータを保存するときに、JBOD ボリュームに永続ストレージが選択された場合のみ作成されます。

Entitiy Operator

これらのリソースは、Cluster Operator を使用して Entity Operator がデプロイされる場合にのみ作成されます。

<kafka_cluster_name>-entity-operator

以下の Entity Operator リソースに指定された名前:

Topic および User Operator とのデプロイメント。
Entity Operator によって使用されるサービスアカウント。
Entity Operator メトリックへのアクセスを管理するネットワークポリシー。

<kafka_cluster_name>-entity-operator-<random_string>

Entity Operator デプロイメントによって作成された Pod。

<kafka_cluster_name>-entity-topic-operator-config

Topic Operator の補助設定のある ConfigMap。

<kafka_cluster_name>-entity-user-operator-config

User Operator の補助設定のある ConfigMap。

<kafka_cluster_name>-entity-topic-operator-certs

Kafka および ZooKeeper と通信するための Topic Operator キーのあるシークレット。

<kafka_cluster_name>-entity-user-operator-certs

Kafka および ZooKeeper と通信するための User Operator キーのあるシークレット。

strimzi-<kafka_cluster_name>-entity-topic-operator

Entity Topic Operator によって使用されるロールバインディング。

strimzi-<kafka_cluster_name>-entity-user-operator

Entity User Operator によって使用されるロールバインディング。

Kafka Exporter

これらのリソースは、Cluster Operator を使用して Kafka Exporter がデプロイされる場合にのみ作成されます。

<kafka_cluster_name>-kafka-exporter

以下の Kafka Exporter リソースに指定された名前。

Kafka Exporter でのデプロイメント。
コンシューマーラグメトリックの収集に使用されるサービス。
Kafka Exporter によって使用されるサービスアカウント。
Kafka Exporter メトリックへのアクセスを管理するネットワークポリシー。

<kafka_cluster_name>-kafka-exporter-<random_string>

Kafka Exporter デプロイメントによって作成された Pod。

Cruise Control

これらのリソースは、Cluster Operator を使用して Cruise Control がデプロイされた場合のみ作成されます。

<kafka_cluster_name>-cruise-control

以下の Cruise Control リソースに指定された名前。

Cruise Control でのデプロイメント。
Cruise Control との通信に使用されるサービス。
Cruise Control によって使用されるサービスアカウント。

<kafka_cluster_name>-cruise-control-<random_string>

Cruise Control デプロイメントによって作成された Pod。

<kafka_cluster_name>-cruise-control-config

Cruise Control の補助設定が含まれ、Cruise Control Pod によってボリュームとしてマウントされる ConfigMap。

<kafka_cluster_name>-cruise-control-certs

Kafka および ZooKeeper と通信するための Cruise Control キーのあるシークレット。

<kafka_cluster_name>-network-policy-cruise-control

Cruise Control サービスへのアクセスを管理するネットワークポリシー。

6.3. Kafka のデプロイ

6.3.1. ノードプールを使用した Kafka クラスターのデプロイ

6.3.2. ノードプールを使用しない ZooKeeper ベースの Kafka クラスターのデプロイ

6.3.3. Cluster Operator を使用した Topic Operator のデプロイ

6.3.4. Cluster Operator を使用した User Operator のデプロイ

6.3.5. ターミナルからの ZooKeeper への接続

6.3.6. Kafka クラスターリソースのリスト

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links