2.2. Kafka クラスターの設定

手順

1. Kafka リソースの spec プロパティーを編集します。

   設定可能なプロパティーは以下の例のとおりです。

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   metadata:
     name: my-cluster
   spec:
     kafka:
       replicas: 3 1
       version: 3.4.0 2
       logging: 3
         type: inline
         loggers:
           kafka.root.logger.level: "INFO"
       resources: 4
         requests:
           memory: 64Gi
           cpu: "8"
         limits:
           memory: 64Gi
           cpu: "12"
       readinessProbe: 5
         initialDelaySeconds: 15
         timeoutSeconds: 5
       livenessProbe:
         initialDelaySeconds: 15
         timeoutSeconds: 5
       jvmOptions: 6
         -Xms: 8192m
         -Xmx: 8192m
       image: my-org/my-image:latest 7
       listeners: 8
         - name: plain 9
           port: 9092 10
           type: internal 11
           tls: false 12
           configuration:
             useServiceDnsDomain: true 13
         - name: tls
           port: 9093
           type: internal
           tls: true
           authentication: 14
             type: tls
         - name: external 15
           port: 9094
           type: route
           tls: true
           configuration:
             brokerCertChainAndKey: 16
               secretName: my-secret
               certificate: my-certificate.crt
               key: my-key.key
       authorization: 17
         type: simple
       config: 18
         auto.create.topics.enable: "false"
         offsets.topic.replication.factor: 3
         transaction.state.log.replication.factor: 3
         transaction.state.log.min.isr: 2
         default.replication.factor: 3
         min.insync.replicas: 2
         inter.broker.protocol.version: "3.4"
         ssl.cipher.suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 19
         ssl.enabled.protocols: TLSv1.2
         ssl.protocol: TLSv1.2
       storage: 20
         type: persistent-claim 21
         size: 10000Gi 22
       rack: 23
         topologyKey: topology.kubernetes.io/zone
       metricsConfig: 24
         type: jmxPrometheusExporter
         valueFrom:
           configMapKeyRef: 25
             name: my-config-map
             key: my-key
       # ...
     zookeeper: 26
       replicas: 3 27
       logging: 28
         type: inline
         loggers:
           zookeeper.root.logger: "INFO"
       resources:
         requests:
           memory: 8Gi
           cpu: "2"
         limits:
           memory: 8Gi
           cpu: "2"
       jvmOptions:
         -Xms: 4096m
         -Xmx: 4096m
       storage:
         type: persistent-claim
         size: 1000Gi
       metricsConfig:
         # ...
     entityOperator: 29
       tlsSidecar: 30
         resources:
           requests:
             cpu: 200m
             memory: 64Mi
           limits:
             cpu: 500m
             memory: 128Mi
       topicOperator:
         watchedNamespace: my-topic-namespace
         reconciliationIntervalSeconds: 60
         logging: 31
           type: inline
           loggers:
             rootLogger.level: "INFO"
         resources:
           requests:
             memory: 512Mi
             cpu: "1"
           limits:
             memory: 512Mi
             cpu: "1"
       userOperator:
         watchedNamespace: my-topic-namespace
         reconciliationIntervalSeconds: 60
         logging: 32
           type: inline
           loggers:
             rootLogger.level: INFO
         resources:
           requests:
             memory: 512Mi
             cpu: "1"
           limits:
             memory: 512Mi
             cpu: "1"
     kafkaExporter: 33
       # ...
     cruiseControl: 34
       # ...

   1

   レプリカノードの数。

   2

   Kafka バージョン。アップグレード手順 に従うと、サポート対象のバージョンに変更できます。

   3

   ConfigMap を介して直接 (inline) または間接 (external) に追加された Kafka ロガーとログレベル。カスタム ConfigMap は、log4j.properties キー下に配置する必要があります。Kafka kafka.root.logger.level ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。

   4

   サポートされているリソース (現在は cpu と memory) の予約と、消費可能な最大リソースを指定するための制限を要求します。

   5

   コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するための ヘルスチェック。

   6

   Kafka を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。

   7

   高度な任意設定: 特別な場合のみ推奨される コンテナーイメージの設定。

   8

   リスナーは、ブートストラップアドレスでクライアントが Kafka クラスターに接続する方法を設定します。リスナーは、OpenShift クラスター内部または外部からの接続の 内部 または 外部 リスナーとして設定 されます。

   9

   リスナーを識別するための名前。Kafka クラスター内で一意である必要があります。

   10

   Kafka 内でリスナーによって使用されるポート番号。ポート番号は指定の Kafka クラスター内で一意である必要があります。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。リスナーのタイプによっては、ポート番号は Kafka クライアントに接続するポート番号と同じではない場合があります。

   11

   リスナーのタイプは、internal または cluster-ip (ブローカーごとの ClusterIP サービスを使用して Kafka を公開するため) として指定されるか、外部リスナーの場合は、route (OpenShift のみ)、loadbalancer、nodeport または ingress (Kubernetes のみ) として指定されます。

   12

   各リスナーの TLS 暗号化を有効にします。デフォルトは false です。route リスナーに TLS 暗号化は必要ありません。

   13

   クラスターサービス接尾辞 (通常は cluster.local) を含む完全修飾 DNS 名が割り当てられているかどうかを定義します。

   14

   mTLS、SCRAM-SHA-512、またはトークンベースの OAuth 2.0 として指定 されるリスナー認証メカニズム。

   15

   外部リスナー設定は 、route、loadbalancer、または nodeportからなど、Kafka クラスターが外部の OpenShift に公開される方法を指定 します。

   16

   外部 CA (認証局) によって管理される Kafka リスナー証明書 のオプションの設定。brokerCertChainAndKey は、サーバー証明書および秘密鍵が含まれる Secret を指定します。TLS による暗号化が有効な任意のリスナーで Kafka リスナー証明書を設定できます。

   17

   承認は Kafka ブローカーで簡易、OAUTH2.0、または OPA 承認を有効化 します。簡易承認では、AclAuthorizer Kafka プラグインが使用されます。

   18

   ブローカー設定。AMQ Streams によって直接管理されないプロパティーに限り、標準 Apache Kafka 設定の提供が可能 です。

   19

   特定の 暗号スイート または TLS バージョンを有効化するために TLS 暗号化が有効になっている SSL プロパティー。

   20

   Storage は ephemeral、persistent-claim、jbod のいずれかに設定されています。

   21

   永続ボリュームのストレージサイズは拡張可能 で、さらに JBOD ストレージへのボリューム追加が可能 です。

   22

   永続ストレージには、動的ボリュームプロビジョニングのためのストレージ id や class など、追加の設定オプション があります。

   23

   異なるラック、データセンター、または可用性ゾーンにレプリカを分散させるための Rack awareness 設定。topologyKey は、ラック ID を含むノードラベルと一致する必要があります。この設定で使用される例では、標準の topology.kubernetes.io/zone ラベルを使用するゾーンを指定します。

   24

   Prometheus メトリクス は有効になっています。この例では、メトリクスは Prometheus JMX Exporter (デフォルトのメトリクスエクスポーター) に対して設定されます。

   25

   Prometheus JMX Exporter 経由でメトリクスを Grafana ダッシュボードにエクスポートする Prometheus ルール。Prometheus JMX Exporter の設定が含まれる ConfigMap を参照することで有効になります。metricsConfig.valueFrom.configMapKeyRef.key 配下に空のファイルが含まれる ConfigMap の参照を使用して、追加設定なしでメトリクスを有効にできます。

   26

   Kafka 設定と似たプロパティーが含まれる、ZooKeeper 固有の設定。

   27

   ZooKeeper ノードの数。通常、ZooKeeper クラスターまたはアンサンブルは、一般的に 3、5、7 個の奇数個のノードで実行されます。効果的なクォーラムを維持するには、過半数のノードが利用可能である必要があります。ZooKeeper クラスターでクォーラムを失うと、クライアントへの応答が停止し、Kafka ブローカーが機能しなくなります。AMQ Streams では、ZooKeeper クラスターの安定性および高可用性が重要になります。

   28

   指定された ZooKeeper ロガーおよびログレベル。

   29

   Topic Operator および User Operator の設定を指定 する Entity Operator 設定。

   30

   Entity Operator の TLS サイドカー設定。Entity Operator は、ZooKeeper とのセキュアな通信に TLS サイドカーを使用します。

   31

   指定された Topic Operator ロガーおよびログレベル。この例では、inline ロギングを使用します。

   32

   指定された User Operator ロガーおよびログレベル。

   33

   Kafka Exporter の設定。Kafka Exporter は、Kafka ブローカーからメトリックデータ、特にコンシューマーラグデータを抽出するためのオプションのコンポーネントです。Kafka Exporter が適切に機能できるようにするには、コンシューマーグループを使用する必要があります。

   34

   Kafka クラスターの再バランスに使用される Cruise Control のオプションの設定。

2. リソースを作成または更新します。

   oc apply -f <kafka_configuration_file>

手順

1. OpenShift コンソールを使用してターミナルを開くか、CLI から exec コマンドを実行します。

   以下に例を示します。

   oc exec -ti my-cluster-zookeeper-0 -- bin/kafka-topics.sh --list --zookeeper localhost:12181

   必ず localhost:12181 を使用してください。

   ZooKeeper に対して Kafka コマンドを実行できるようになりました。

手順

1. 削除する Pod の名前を見つけます。

   Kafka ブローカー Pod の名前は <cluster-name>-kafka-<index> です。ここで、<index> はゼロで始まり、レプリカの合計数から 1 を引いた数で終了します。例: my-cluster-kafka-0

2. OpenShift で Pod リソースにアノテーションを付けます。

   oc annotate を使用します。

   oc annotate pod cluster-name-kafka-index strimzi.io/delete-pod-and-pvc=true

3. 基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。

手順

1. 削除する Pod の名前を見つけます。

   ZooKeeper Pod の名前は <cluster-name>-zookeeper-<index> です。ここで、<index> はゼロで始まり、レプリカの合計数から 1 を引いた数で終了します。例: my-cluster-zookeeper-0

2. OpenShift で Pod リソースにアノテーションを付けます。

   oc annotate を使用します。

   oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true

3. 基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。