AMQ Streams on OpenShift の使用
OpenShift Container Platform 上で AMQ Streams 1.7 を使用
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。これは大規模な取り組みであるため、これらの変更は今後の複数のリリースで段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージをご覧ください。
第1章 AMQ Streams の概要
AMQ Streams は、OpenShift クラスターで Apache Kafka を実行するプロセスを簡素化します。
本ガイドでは、Kafka コンポーネントの設定方法と、AMQ Streams Operator の使用方法を説明します。手順は、デプロイメントの変更方法や、Cruise Control や分散トレーシングなどの追加機能を導入する方法に関連しています。
AMQ Streams カスタムリソース を使用して、デプロイメントを設定できます。カスタムリソース API リファレンス は、設定で使用できるプロパティーを説明します。
AMQ Streams を使用する方法ステップごとのデプロイメント手順は、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
1.1. Kafka の機能
Kafka の基盤のデータストリーム処理機能とコンポーネントアーキテクチャーによって以下が提供されます。
- スループットが非常に高く、レイテンシーが低い状態でデータを共有するマイクロサービスおよびその他のアプリケーション。
- メッセージの順序の保証。
- アプリケーションの状態を再構築するためにデータストレージからメッセージを巻き戻し/再生。
- キーバリューログの使用時に古いレコードを削除するメッセージ圧縮。
- クラスター設定での水平スケーラビリティー。
- 耐障害性を制御するデータのレプリケーション。
- 即座にアクセスするために大容量のデータを保持。
1.2. Kafka のユースケース
Kafka の機能は、以下に適しています。
- イベント駆動型のアーキテクチャー。
- アプリケーションの状態変更をイベントのログとしてキャプチャーするイベントソーシング。
- メッセージのブローカー。
- Web サイトアクティビティーの追跡。
- メトリクスによるオペレーションの監視。
- ログの収集および集計。
- 分散システムのログのコミット。
- アプリケーションがリアルタイムでデータに対応できるようにするストリーム処理。
1.3. AMQ Streams による Kafka のサポート
AMQ Streams は、Kafka を OpenShift で実行するためのコンテナーイメージおよび Operator を提供します。AMQ Streams Operator は、AMQ Streams の実行に必要です。AMQ Streams で提供される Operator は、Kafka を効果的に管理するために、専門的なオペレーション情報で目的に合うよう構築されています。
Operator は以下のプロセスを単純化します。
- Kafka クラスターのデプロイおよび実行。
- Kafka コンポーネントのデプロイおよび実行。
- Kafka へアクセスするための設定。
- Kafka へのアクセスをセキュア化。
- Kafka のアップグレード。
- ブローカーの管理。
- トピックの作成および管理。
- ユーザーの作成および管理。
1.4. AMQ Streams の Operator
AMQ Streams では Operator を使用して Kafka をサポートし、Kafka のコンポーネントおよび依存関係を OpenShift にデプロイして管理します。
Operator は、OpenShift アプリケーションのパッケージ化、デプロイメント、および管理を行う方法です。AMQ Streams Operator は OpenShift の機能を拡張し、Kafka デプロイメントに関連する共通タスクや複雑なタスクを自動化します。Kafka 操作の情報をコードに実装することで、Kafka の管理タスクは簡素化され、必要な手動の作業が少なくなります。
Operator
AMQ Streams は、OpenShift クラスター内で実行中の Kafka クラスターを管理するための Operator を提供します。
- Cluster Operator
- Apache Kafka クラスター、Kafka Connect、Kafka MirrorMaker、Kafka Bridge、Kafka Exporter、および Entity Operator をデプロイおよび管理します。
- Entitiy Operator
- Topic Operator および User Operator を構成します。
- Topic Operator
- Kafka トピックを管理します。
- User Operator
- Kafka ユーザーを管理します。
Cluster Operator は、Kafka クラスターと同時に、Topic Operator および User Operator を Entity Operator 設定の一部としてデプロイできます。
AMQ Streams アーキテクチャー内の Operator
1.4.1. Cluster Operator
AMQ Streams では、Cluster Operator を使用して以下のクラスターをデプロイおよび管理します。
- Kafka (ZooKeeper、Entity Operator、Kafka Exporter、Cruise Control を含む)
- Kafka Connect
- Kafka MirrorMaker
- Kafka Bridge
クラスターのデプロイメントにはカスタムリソースが使用されます。
たとえば、以下のように Kafka クラスターをデプロイします。
-
クラスター設定のある
Kafka
リソースが OpenShift クラスター内で作成されます。 -
Kafka
リソースに宣言された内容を基にして、該当する Kafka クラスターが Cluster Operator によってデプロイされます。
Cluster Operator で以下もデプロイできます (Kafka
リソースの設定より)。
-
KafkaTopic
カスタムリソースより Operator スタイルのトピック管理を提供する Topic Operator -
KafkaUser
カスタムリソースより Operator スタイルのユーザー管理を提供する User Operator
デプロイメントの Entity Operator 内の Topic Operator および User Operator 関数。
Cluster Operator のアーキテクチャー例
1.4.2. Topic Operator
Topic Operator は、OpenShift リソースより Kafka クラスターのトピックを管理する方法を提供します。
Topic Operator のアーキテクチャー例
Topic Operator の役割は、対応する Kafka トピックと同期して Kafka トピックを記述する KafkaTopic
OpenShift リソースのセットを保持することです。
KafkaTopic
とトピックの関係は次のとおりです。
-
KafkaTopic
が作成されると、Topic Operator によってトピックが作成されます。 -
KafkaTopic
が削除されると、Topic Operator によってトピックが削除されます。 -
KafkaTopic
が変更されると、Topick Operator によってトピックが更新されます。
上記と逆になるトピックと KafkaTopic
の関係は次のとおりです。
-
トピックが Kafka クラスター内で作成されると、Operator によって
KafkaTopic
が作成されます。 -
トピックが Kafka クラスターから削除されると、Operator によって
KafkaTopic
が削除されます。 -
トピックが Kafka クラスターで変更されると、Operator によって
KafkaTopic
が更新されます。
このため、KafkaTopic
をアプリケーションのデプロイメントの一部として宣言でき、トピックの作成は Topic Operator によって行われます。アプリケーションは、必要なトピックからの作成または消費のみに対処する必要があります。
Topic Operator は、各トピックの情報を トピックストア で維持します。トピックストアは、Kafka トピックまたは OpenShift KafkaTopic
カスタムリソースからの更新と継続的に同期されます。ローカルのインメモリートピックストアに適用される操作からの更新は、ディスク上のバックアップトピックストアに永続化されます。トピックが再設定されたり、別のブローカーに再割り当てされた場合、KafkaTopic
は常に最新の状態になります。
1.4.3. User Operator
User Operator は、Kafka ユーザーが記述される KafkaUser
リソースを監視して Kafka クラスターの Kafka ユーザーを管理し、Kafka ユーザーが Kafka クラスターで適切に設定されるようにします。
たとえば、KafkaUser
とユーザーの関係は次のようになります。
-
KafkaUser
が作成されると、User Operator によって記述されるユーザーが作成されます。 -
KafkaUser
が削除されると、User Operator によって記述されるユーザーが削除されます。 -
KafkaUser
が変更されると、User Operator によって記述されるユーザーが更新されます。
User Operator は Topic Operator とは異なり、Kafka クラスターからの変更は OpenShift リソースと同期されません。アプリケーションで直接 Kafka トピックを Kafka で作成することは可能ですが、ユーザーが User Operator と同時に直接 Kafka クラスターで管理されることは想定されません。
User Operator では、アプリケーションのデプロイメントの一部として KafkaUser
リソースを宣言できます。ユーザーの認証および承認メカニズムを指定できます。たとえば、ユーザーがブローカーへのアクセスを独占しないようにするため、Kafka リソースの使用を制御する ユーザークォータ を設定することもできます。
ユーザーが作成されると、ユーザークレデンシャルが Secret
に作成されます。アプリケーションはユーザーとそのクレデンシャルを使用して、認証やメッセージの生成または消費を行う必要があります。
User Operator は 認証のクレデンシャルを管理する他に、KafkaUser
宣言にユーザーのアクセス権限の記述を含めることで承認も管理します。
1.5. AMQ Streams のカスタムリソース
AMQ Streams を使用した Kafka コンポーネントの OpenShift クラスターへのデプロイメントは、カスタムリソースの適用により高度な設定が可能です。カスタムリソースは、OpenShift リソースを拡張するために CRD (カスタムリソース定義、Custom Resource Definition) によって追加される API のインスタンスとして作成されます。
CRD は、OpenShift クラスターでカスタムリソースを記述するための設定手順として機能し、デプロイメントで使用する Kafka コンポーネントごとに AMQ Streams で提供されます。CRD およびカスタムリソースは YAML ファイルとして定義されます。YAML ファイルのサンプルは AMQ Streams ディストリビューションに同梱されています。
また、CRD を使用すると、CLI へのアクセスや設定検証などのネイティブ OpenShift 機能を AMQ Streams リソースで活用することもできます。
1.5.1. AMQ Streams カスタムリソースの例
AMQ Streams 固有リソースのインスタンス化および管理に使用されるスキーマを定義するため、CRD をクラスターに 1 度インストールする必要があります。
CRD をインストールして新規カスタムリソースタイプをクラスターに追加した後に、その仕様に基づいてリソースのインスタンスを作成できます。
クラスターの設定によりますが、インストールには通常、クラスター管理者権限が必要です。
カスタムリソースの管理は、AMQ Streams 管理者のみが行えます。詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「AMQ Streams の管理者の指名」を参照してください。
kind:Kafka
などの新しい kind
リソースは、OpenShift クラスター内で CRD によって定義されます。
Kubernetes API サーバーを使用すると、kind
を基にしたカスタムリソースの作成が可能になり、カスタムリソースが OpenShift クラスターに追加されたときにカスタムリソースの検証および格納方法を CRD から判断します。
CRD が削除されると、そのタイプのカスタムタイプも削除されます。さらに、Pod や Statefulset などのカスタムリソースによって作成されたリソースも削除されます。
AMQ Streams 固有の各カスタムリソースは、リソースの kind
の CRD によって定義されるスキーマに準拠します。AMQ Streams コンポーネントのカスタムリソースには、spec
で定義される共通の設定プロパティーがあります。
CRD とカスタムリソースの関係を理解するため、Kafka トピックの CRD の例を見てみましょう。
Kafka トピックの CRD
apiVersion: kafka.strimzi.io/v1beta2 kind: CustomResourceDefinition metadata: 1 name: kafkatopics.kafka.strimzi.io labels: app: strimzi spec: 2 group: kafka.strimzi.io versions: v1beta2 scope: Namespaced names: # ... singular: kafkatopic plural: kafkatopics shortNames: - kt 3 additionalPrinterColumns: 4 # ... subresources: status: {} 5 validation: 6 openAPIV3Schema: properties: spec: type: object properties: partitions: type: integer minimum: 1 replicas: type: integer minimum: 1 maximum: 32767 # ...
- 1
- CRD を識別するためのトピック CRD、その名前および名前のメタデータ。
- 2
- この CRD に指定された項目には、トピックの API にアクセスするため URL に使用されるグルShortNameープ (ドメイン) 名、複数名、およびサポートされるスキーマバージョンが含まれます。他の名前は、CLI のインスタンスリソースを識別するために使用されます。例:
oc get kafkatopic my-topic
またはoc get kafkatopics
- 3
- ShortName は CLI コマンドで使用できます。たとえば、
oc get kafkatopic
の代わりにoc get kt
を略名として使用できます。 - 4
- カスタムリソースで
get
コマンドを使用する場合に示される情報。 - 5
- リソースの スキーマ参照 に記載されている CRD の現在のステータス。
- 6
- openAPIV3Schema 検証によって、トピックカスタムリソースの作成が検証されます。たとえば、トピックには 1 つ以上のパーティションと 1 つのレプリカが必要です。
ファイル名に、インデックス番号とそれに続く「Crd」が含まれるため、AMQ Streams インストールファイルと提供される CRD YAML ファイルを識別できます。
KafkaTopic
カスタムリソースに該当する例は次のとおりです。
Kafka トピックカスタムリソース
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic 1 metadata: name: my-topic labels: strimzi.io/cluster: my-cluster 2 spec: 3 partitions: 1 replicas: 1 config: retention.ms: 7200000 segment.bytes: 1073741824 status: conditions: 4 lastTransitionTime: "2019-08-20T11:37:00.706Z" status: "True" type: Ready observedGeneration: 1 / ...
- 1
kind
およびapiVersion
によって、インスタンスであるカスタムリソースの CRD が特定されます。- 2
- トピックまたはユーザーが属する Kafka クラスターの名前 (
Kafka
リソースの名前と同じ) を定義する、KafkaTopic
およびKafkaUser
リソースのみに適用可能なラベル。 - 3
- 指定内容には、トピックのパーティション数およびレプリカ数や、トピック自体の設定パラメーターが示されています。この例では、メッセージがトピックに保持される期間や、ログのセグメントファイルサイズが指定されています。
- 4
KafkaTopic
リソースのステータス条件。lastTransitionTime
でtype
条件がReady
に変更されています。
プラットフォーム CLI からカスタムリソースをクラスターに適用できます。カスタムリソースが作成されると、Kubernetes API の組み込みリソースと同じ検証が使用されます。
KafkaTopic
の作成後、Topic Operator は通知を受け取り、該当する Kafka トピックが AMQ Streams で作成されます。
1.6. リスナーの設定
リスナーは、Kafka ブローカーへの接続に使用されます。
AMQ Streams は、Kafka
リソース経由でリスナーを設定するプロパティーと汎用 GenericKafkaListener
スキーマを提供します。
GenericKafkaListener
は、柔軟なリスナー設定を実現します。
プロパティーを指定して、OpenShift クラスター内で接続する 内部 リスナーを設定したり、OpenShift クラスター外部で接続する外部 リスナーを設定したりできます。
汎用リスナーの設定
各リスナーは、Kafka
リソースの配列として定義されます。
リスナーの設定に関する詳細は、「GenericKafkaListener
スキーマ参照」を参照してください。
汎用リスナー設定は、非推奨 である KafkaListeners
スキーマ参照 を使用した従来のリスナー設定の代わりに使用します。ただし、後方互換性によって、以前の形式を新しい形式に変換 することができます。
KafkaListeners
スキーマは plain
、tls
、および external
リスナーのサブプロパティーを使用し、それぞれに固定ポートを使用します。スキーマのアーキテクチャー固有の制限により、3 つのリスナーのみを設定でき、設定オプションはリスナーのタイプに制限されます。
GenericKafkaListener
スキーマでは、名前とポートが一意であれば、必要なリスナーをいくつでも設定できます。
たとえば、異なる認証メカニズムを必要とするネットワークからのアクセスを処理する場合などに、複数の外部リスナーを設定することがあります。また、OpenShift ネットワークを外部ネットワークに参加させる必要があることがあります。この場合、OpenShift サービスの DNS ドメイン (通常は .cluster.local
) が使用されないように、useServiceDnsDomain
プロパティーを使用して内部リスナーを設定できます。
Kafka ブローカーへのアクセスをセキュアにするためのリスナー設定
リスナーを設定して、認証を使用したセキュアな接続を確立できます。Kafka ブローカーへのアクセスをセキュアにするための詳細は、「Kafka へのアクセス管理」を参照してください。
OpenShift 外部のクライアントアクセスに対する外部リスナーの設定
ロードバランサーなどの指定された接続メカニズムを使用して、OpenShift 環境外部のクライアントアクセスに対して外部リスナーを設定できます。外部クライアントを接続するための設定オプションの詳細は、「外部リスナーの設定」を参照してください。
リスナー証明書
TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーの、Kafka リスナー証明書 と呼ばれる独自のサーバー証明書を提供できます。詳細は「Kafka リスナー証明書」を参照してください。
1.7. 本書の表記慣例
置き換え可能なテキスト
本書では、置き換え可能なテキストは、monospace
フォントのイタリック体、大文字、およびハイフンで記載されています。
たとえば、以下のコードでは MY-NAMESPACE
を namespace の名前に置き換えます。
sed -i 's/namespace: .*/namespace: MY-NAMESPACE/' install/cluster-operator/*RoleBinding*.yaml
第2章 デプロイメント設定
本章では、カスタムリソースを使用してサポートされるデプロイメントのさまざまな側面を設定する方法について説明します。
- Kafka クラスター
- Kafka Connect クラスター
- Source2Image がサポートされる Kafka Connect クラスター
- Kafka MirrorMaker
- Kafka Bridge
- Cruise Control
カスタムリソースに適用されるラベルは、Kafka MirrorMaker を構成する OpenShift リソースにも適用されます。そのため、必要に応じてリソースにラベルが適用されるため便利です。
2.1. Kafka クラスターの設定
ここでは、AMQ Streams クラスターで Kafka デプロイメントを設定する方法を説明します。Kafka クラスターは ZooKeeper クラスターとデプロイされます。デプロイメントには、Kafka トピックおよびユーザーを管理する Topic Operator および User Operator も含まれます。
Kafka
リソースを使用して Kafka を設定します。設定オプションは、Kafka
リソース内の ZooKeeper および Entity Operator でも利用できます。Entity Operator は Topic Operator と User Operator で構成されます。
Kafka
リソースの完全なスキーマは 「Kafka
スキーマ参照」 に記載されています。
リスナーの設定
クライアントを Kafka ブローカーに接続するためのリスナーを設定します。ブローカーに接続するためのリスナーの設定に関する詳細は、「リスナーの設定」を参照してください。
Kafka へのアクセスの承認
ユーザーが実行するアクションを許可または拒否するように Kafka クラスターを設定できます。Kafka ブローカーへのアクセスをセキュアにするための詳細は、「Kafka へのアクセス管理」を参照してください。
TLS 証明書の管理
Kafka をデプロイする場合、Cluster Operator は自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。必要な場合は、更新期間の終了前にクラスターおよびクライアント CA 証明書を手動で更新できます。クラスターおよびクライアント CA 証明書によって使用される鍵を置き換えることもできます。詳細は、「CA 証明書の手動更新」および「秘密鍵の置換」を参照してください。
その他のリソース
- Apache Kafka の詳細は、Apache Kafka の Web サイト を参照してください。
2.1.1. Kafka の設定
Kafka
リソースのプロパティーを使用して、Kafka デプロイメントを設定します。
Kafka の設定に加え、ZooKeeper および AMQ Streams Operator の設定を追加することもできます。ロギングやヘルスチェックなどの一般的な設定プロパティーは、コンポーネントごとに独立して設定されます。
この手順では、可能な設定オプションの一部のみを取り上げますが、特に重要なオプションは次のとおりです。
- リソース要求 (CPU/メモリー)
- 最大および最小メモリー割り当ての JVM オプション
- リスナー (およびクライアントの認証)
- 認証
- ストレージ
- ラックアウェアネス (Rack Awareness)
- メトリクス
- Cruise Control によるクラスターのリバランス
Kafka バージョン
Kafka config
の log.message.format.version
および inter.broker.protocol.version
プロパティーは、指定された Kafka バージョン (spec.kafka.version
) によってサポートされるバージョンです。プロパティーは、メッセージに追加されるログ形式のバージョンと、Kafka クラスターで使用される Kafka プロトコルのバージョンを表します。Kafka バージョンのアップグレード時に、これらのプロパティーの更新が必要になります。詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Kafka のアップグレード」を参照してください。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
以下をデプロイする手順については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
手順
Kafka
リソースのspec
プロパティーを編集します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: replicas: 3 1 version: 2.7.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 log.message.format.version: 2.7 inter.broker.protocol.version: 2.7 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 # ... tlsSidecar: 35 # ...
- 1
- レプリカノードの数。クラスターにトピックがすでに定義されている場合は、クラスターをスケーリング できます。
- 2
- Kafka バージョン。アップグレード手順にしたがうと、サポート対象のバージョンに変更できます。
- 3
- ConfigMap にて直接的 (
inline
) または間接的 (external
) に追加される Kafka のロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties
キー下に配置する必要があります。Kafkakafka.root.logger.level
ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。 - 4
- 5
- コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
- 6
- Kafka を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
- 7
- 高度な任意設定: 特別な場合のみ推奨されるコンテナーイメージの設定。
- 8
- リスナーは、ブートストラップアドレスでクライアントが Kafka クラスターに接続する方法を設定します。リスナーは、OpenShift クラスター内部または外部からの接続の 内部 または 外部 リスナーとして設定されます。
- 9
- リスナーを識別するための名前。Kafka クラスター内で一意である必要があります。
- 10
- Kafka 内でリスナーによって使用されるポート番号。ポート番号は指定の Kafka クラスター内で一意である必要があります。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。リスナーのタイプによっては、ポート番号は Kafka クライアントに接続するポート番号と同じではない場合があります。
- 11
internal
として指定されたリスナータイプ。外部リスナーの場合はroute
、loadbalancer
、nodeport
、またはingress
として指定。- 12
- 各リスナーの TLS 暗号化を有効にします。デフォルトは
false
です。route
リスナーには TLS 暗号化は必要ありません。 - 13
- クラスターサービスサフィックス (通常は
.cluster.local
) を含む完全修飾 DNS 名が割り当てられているかどうかを定義します。 - 14
- 相互 TLS、SCRAM-SHA-512、またはトークンベース OAuth 2.0 として指定される リスナー認証メカニズム。
- 15
- 外部リスナー設定は、
route
、loadbalancer
、またはnodeport
からなど、Kafka クラスターが OpenShift 外部で公開される方法 を指定します。 - 16
- 外部の認証局によって管理される Kafka リスナー証明書 の任意設定。
brokerCertChainAndKey
プロパティーは、サーバー証明書および秘密鍵が含まれるSecret
を指定します。TLS による暗号化が有効な任意のリスナーで Kafka リスナー証明書を設定できます。 - 17
- 承認は Kafka ブローカーで簡易、OAUTH2.0、または OPA 承認を有効にします。簡易承認では
AclAuthorizer
Kafka プラグインが使用されます。 - 18
config
によってブローカー設定が指定されます。標準の Apache Kafka 設定が提供されることがあり、AMQ Streams によって直接管理されないプロパティーに限定されます。- 19
- 20
- 21
- 22
- 23
- ラックアウェアネス (Rack awareness) は、異なるラック全体でレプリカを分散するために設定されます。
topologykey
はクラスターノードのラベルと一致する必要があります。 - 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 ブローカーから抽出する任意のコンポーネントです。
- 34
- Kafka クラスターのリバランス に使用される Cruise Control の任意設定。
- 35
- Cruise Conrol の TLS サイドカーの設定。Cruise Control は、ZooKeeper とのセキュアな通信に TLS サイドカーを使用します。
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
2.1.2. Entity Operator の設定
Entity Operator は、実行中の Kafka クラスターで Kafka 関連のエンティティーを管理します。
Entity Operator は以下と構成されます。
- Kafka トピックを管理する Topic Operator
- Kafka ユーザーを管理する User Operator
Cluster Operator は Kafka
リソース設定を介して、Kafka クラスターのデプロイ時に、上記の Operator の 1 つまたは両方を含む Entity Operator をデプロイできます。
デプロイされると、デプロイメント設定に応じて、Entity Operator にオペレーターが含まれます。
これらのオペレーターは、Kafka クラスターのトピックおよびユーザーを管理するために自動的に設定されます。
2.1.2.1. Entity Operator の設定プロパティー
Kafka.spec
の entityOperator
プロパティーを使用して Entity Operator を設定します。
entityOperator
プロパティーでは複数のサブプロパティーがサポートされます。
-
tlsSidecar
-
topicOperator
-
userOperator
-
template
tlsSidecar
プロパティーには、ZooKeeper との通信に使用される TLS サイドカーコンテナーの設定が含まれます。
template
プロパティーには、ラベル、アノテーション、アフィニティー、および容認 (Toleration) などの Entity Operator Pod の設定が含まれます。テンプレートの設定に関する詳細は、「OpenShift リソースのカスタマイズ」 を参照してください。
topicOperator
プロパティーには、Topic Operator の設定が含まれます。このオプションがないと、Entity Operator は Topic Operator なしでデプロイされます。
userOperator
プロパティーには、User Operator の設定が含まれます。このオプションがないと、Entity Operator は User Operator なしでデプロイされます。
Entity Operator の設定に使用されるプロパティーに関する詳細は「EntityUserOperatorSpec
スキーマ参照」を参照してください。
両方の Operator を有効にする基本設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: topicOperator: {} userOperator: {}
topicOperator
および userOperator
に空のオブジェクト ({}
) が使用された場合、すべてのプロパティーでデフォルト値が使用されます。
topicOperator
および userOperator
プロパティーの両方がない場合、Entity Operator はデプロイされません。
2.1.2.2. Topic Operator 設定プロパティー
Topic Operator デプロイメントは、topicOperator
オブジェクト内で追加オプションを使用すると設定できます。以下のプロパティーがサポートされます。
watchedNamespace
-
User Operator によって
KafkaTopics
が監視される OpenShift namespace。デフォルトは、Kafka クラスターがデプロイされた namespace です。 reconciliationIntervalSeconds
-
定期的な調整 (reconciliation) の間隔 (秒単位)。デフォルトは
90
です。 zookeeperSessionTimeoutSeconds
-
ZooKeeper セッションのタイムアウト (秒単位)。デフォルトは
20
です。 topicMetadataMaxAttempts
-
Kafka からトピックメタデータの取得を試行する回数。各試行の間隔は、指数バックオフとして定義されます。パーティションまたはレプリカの数によって、トピックの作成に時間がかかる可能性がある場合は、この値を大きくすることを検討してください。デフォルトは
6
です。 image
-
image
プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、「image
」 を参照してください。 resources
-
resources
プロパティーを使用すると、Topic Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、「resources
」 を参照してください。 logging
-
logging
プロパティーは、Topic Operator のロギングを設定します。詳細は 「logging
」 を参照してください。
Topic Operator の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: # ... topicOperator: watchedNamespace: my-topic-namespace reconciliationIntervalSeconds: 60 # ...
2.1.2.3. User Operator 設定プロパティー
User Operator デプロイメントは、userOperator
オブジェクト内で追加オプションを使用すると設定できます。以下のプロパティーがサポートされます。
watchedNamespace
-
User Operator によって
KafkaUsers
が監視される OpenShift namespace。デフォルトは、Kafka クラスターがデプロイされた namespace です。 reconciliationIntervalSeconds
-
定期的な調整 (reconciliation) の間隔 (秒単位)。デフォルトは
120
です。 zookeeperSessionTimeoutSeconds
-
ZooKeeper セッションのタイムアウト (秒単位)。デフォルトは
6
です。 image
-
image
プロパティーを使用すると、使用されるコンテナーイメージを設定できます。カスタムコンテナーイメージの設定に関する詳細は、「image
」 を参照してください。 resources
-
resources
プロパティーを使用すると、User Operator に割り当てられるリソースの量を設定できます。リソースの要求と制限の設定に関する詳細は、「resources
」 を参照してください。 logging
-
logging
プロパティーは、User Operator のロギングを設定します。詳細は 「logging
」 を参照してください。 secretPrefix
-
secretPrefix
プロパティーは、KafkaUser リソースから作成されたすべての Secret の名前にプレフィックスを追加します。たとえば、STRIMZI_SECRET_PREFIX=kafka-
は、すべての Secret 名の前にkafka-
を付けます。そのため、my-user
という名前の KafkaUser は、kafka-my-user
という名前の Secret を作成します。
User Operator の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: # ... userOperator: watchedNamespace: my-user-namespace reconciliationIntervalSeconds: 60 # ...
2.1.3. Kafka および ZooKeeper のストレージタイプ
Kafka および ZooKeeper はステートフルなアプリケーションであるため、データをディスクに格納する必要があります。AMQ Streams では、3 つのタイプのストレージがサポートされます。
- 一時ストレージ
- 永続ストレージ
- JBOD ストレージ
JBOD ストレージは Kafka でサポートされ、ZooKeeper ではサポートされていません。
Kafka
リソースを設定する場合、Kafka ブローカーおよび対応する ZooKeeper ノードによって使用されるストレージのタイプを指定できます。以下のリソースの storage
プロパティーを使用して、ストレージタイプを設定します。
-
Kafka.spec.kafka
-
Kafka.spec.zookeeper
ストレージタイプは type
フィールドで設定されます。
Kafka クラスターをデプロイした後に、ストレージタイプを変更することはできません。
その他のリソース
- 一時ストレージの詳細は、「一時ストレージのスキーマ参照」を参照してください。
- 永続ストレージの詳細は、「永続ストレージのスキーマ参照」を参照してください。
- JBOD ストレージの詳細は、「JBOD スキーマ参照」を参照してください。
-
Kafka
のスキーマに関する詳細は、「Kafka
スキーマ参照」を参照してください。
2.1.3.1. データストレージに関する留意事項
効率的なデータストレージインフラストラクチャーは、AMQ Streams のパフォーマンスを最適化するために不可欠です。
ブロックストレージが必要です。NFS などのファイルストレージは、Kafka では機能しません。
ブロックストレージには、以下などを選択できます。
- Amazon Elastic Block Store (EBS)などのクラウドベースのブロックストレージソリューション。
- ローカルの永続ボリューム。
- ファイバーチャネル や iSCSI などのプロトコルがアクセスする SAN (ストレージネットワークエリア) ボリューム。
AMQ Streams には OpenShift の raw ブロックボリュームは必要ありません。
2.1.3.1.1. ファイルシステム
XFS ファイルシステムを使用するようにストレージシステムを設定することが推奨されます。AMQ Streams は ext4 ファイルシステムとも互換性がありますが、最適化するには追加の設定が必要になることがあります。
2.1.3.1.2. Apache Kafka および ZooKeeper ストレージ
Apache Kafka と ZooKeeper には別々のディスクを使用します。
3 つのタイプのデータストレージがサポートされます。
- 一時データストレージ (開発用のみで推奨されます)
- 永続データストレージ
- JBOD (Just a Bunch of Disks、Kafka のみに適しています)
詳細は「Kafka および ZooKeeper ストレージ」を参照してください。
ソリッドステートドライブ (SSD) は必須ではありませんが、複数のトピックに対してデータが非同期的に送受信される大規模なクラスターで Kafka のパフォーマンスを向上させることができます。SSD は、高速で低レイテンシーのデータアクセスが必要な ZooKeeper で特に有効です。
Kafka と ZooKeeper の両方にデータレプリケーションが組み込まれているため、複製されたストレージのプロビジョニングは必要ありません。
2.1.3.2. 一時ストレージ
一時ストレージは emptyDir
ボリュームを使用してデータを保存します。一時ストレージを使用するには、type
フィールドを ephemeral
に設定します。
emptyDir
ボリュームは永続的ではなく、保存されたデータは Pod の再起動時に失われます。新規 Pod の起動後に、クラスターの他のノードからすべてのデータを復元する必要があります。一時ストレージは、単一ノードの ZooKeeper クラスターやレプリケーション係数が 1 の Kafka トピックでの使用には適していません。この設定により、データが失われます。
一時ストレージの例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... storage: type: ephemeral # ... zookeeper: # ... storage: type: ephemeral # ...
2.1.3.2.1. ログディレクトリー
一時ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。
/var/lib/kafka/data/kafka-logIDX
IDX
は、Kafka ブローカー Pod インデックスです。例: /var/lib/kafka/data/kafka-log0
2.1.3.3. 永続ストレージ
永続ストレージは Persistent Volume Claim (永続ボリューム要求、PVC) を使用して、データを保存するための永続ボリュームをプロビジョニングします。永続ボリューム要求を使用すると、ボリュームのプロビジョニングを行う ストレージクラス に応じて、さまざまなタイプのボリュームをプロビジョニングできます。永続ボリューム要求と使用できるデータタイプには、多くのタイプの SAN ストレージやローカル永続ボリューム などがあります。
永続ストレージを使用するには、type
を persistent-claim
に設定する必要があります。永続ストレージでは、追加の設定オプションがサポートされます。
id
(任意)-
ストレージ ID 番号。このオプションは、JBOD ストレージ宣言で定義されるストレージボリュームには必須です。デフォルトは
0
です。 size
(必須)- 永続ボリューム要求のサイズを定義します (例: 1000Gi)。
class
(任意)- 動的ボリュームプロビジョニングに使用する OpenShift の ストレージクラス。
selector
(任意)- 使用する特定の永続ボリュームを選択できます。このようなボリュームを選択するラベルを表す key:value ペアが含まれます。
deleteClaim
(任意)-
クラスターのアンデプロイ時に永続ボリューム要求を削除する必要があるかどうかを指定するブール値。デフォルトは
false
です。
既存の AMQ Streams クラスターで永続ボリュームのサイズを増やすことは、永続ボリュームのサイズ変更をサポートする OpenShift バージョンでのみサポートされます。サイズを変更する永続ボリュームには、ボリューム拡張をサポートするストレージクラスを使用する必要があります。ボリューム拡張をサポートしないその他のバージョンの OpenShift およびストレージクラスでは、クラスターをデプロイする前に必要なストレージサイズを決定する必要があります。既存の永続ボリュームのサイズを縮小することはできません。
size
が 1000Gi の永続ストレージ設定の例 (抜粋)
# ... storage: type: persistent-claim size: 1000Gi # ...
以下の例は、ストレージクラスの使用例を示しています。
特定のストレージクラスを指定する永続ストレージ設定の例 (抜粋)
# ... storage: type: persistent-claim size: 1Gi class: my-storage-class # ...
最後に、selector
を使用して特定のラベルが付いた永続ボリュームを選択し、SSD などの必要な機能を提供できます。
セレクターを指定する永続ストレージ設定の例 (抜粋)
# ... storage: type: persistent-claim size: 1Gi selector: hdd-type: ssd deleteClaim: true # ...
2.1.3.3.1. ストレージクラスのオーバーライド
デフォルトのストレージクラスを使用する代わりに、1 つ以上の Kafka ブローカー または ZooKeeper ノードに異なるストレージクラスを指定できます。これは、ストレージクラスが、異なるアベイラビリティーゾーンやデータセンターに制限されている場合などに便利です。この場合、overrides
フィールドを使用できます。
以下の例では、デフォルトのストレージクラスの名前は my-storage-class
になります。
ストレージクラスのオーバーライドを使用した AMQ Streams クラスターの例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: labels: app: my-cluster name: my-cluster namespace: myproject spec: # ... kafka: replicas: 3 storage: deleteClaim: true size: 100Gi type: persistent-claim class: my-storage-class overrides: - broker: 0 class: my-storage-class-zone-1a - broker: 1 class: my-storage-class-zone-1b - broker: 2 class: my-storage-class-zone-1c # ... zookeeper: replicas: 3 storage: deleteClaim: true size: 100Gi type: persistent-claim class: my-storage-class overrides: - broker: 0 class: my-storage-class-zone-1a - broker: 1 class: my-storage-class-zone-1b - broker: 2 class: my-storage-class-zone-1c # ...
overrides
プロパティーが設定され、ボリュームによって以下のストレージクラスが使用されます。
-
ZooKeeper ノード 0 の永続ボリュームでは
my-storage-class-zone-1a
が使用されます。 -
ZooKeeper ノード 1 の永続ボリュームでは
my-storage-class-zone-1b
が使用されます。 -
ZooKeeper ノード 2 の永続ボリュームでは
my-storage-class-zone-1c
が使用されます。 -
Kafka ブローカー 0 の永続ボリュームでは
my-storage-class-zone-1a
が使用されます。 -
Kafka ブローカー 1 の永続ボリュームでは
my-storage-class-zone-1b
が使用されます。 -
Kafka ブローカー 2 の永続ボリュームでは
my-storage-class-zone-1c
が使用されます。
現在、overrides
プロパティーは、ストレージクラスの設定をオーバーライドするためのみに使用されます。他のストレージ設定フィールドのオーバーライドは現在サポートされていません。ストレージ設定の他のフィールドは現在サポートされていません。
2.1.3.3.2. Persistent Volume Claim (永続ボリューム要求、PVC) の命名
永続ストレージが使用されると、以下の名前で Persistent Volume Claim (永続ボリューム要求、PVC) が作成されます。
data-cluster-name-kafka-idx
-
Kafka ブローカー Pod
idx
のデータを保存するために使用されるボリュームの永続ボリューム要求です。 data-cluster-name-zookeeper-idx
-
ZooKeeper ノード Pod
idx
のデータを保存するために使用されるボリュームの永続ボリューム要求です。
2.1.3.3.3. ログディレクトリー
永続ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。
/var/lib/kafka/data/kafka-logIDX
IDX
は、Kafka ブローカー Pod インデックスです。例: /var/lib/kafka/data/kafka-log0
2.1.3.4. 永続ボリュームのサイズ変更
既存の AMQ Streams クラスターによって使用される永続ボリュームのサイズを増やすことで、ストレージ容量を増やすことができます。永続ボリュームのサイズ変更は、JBOD ストレージ設定で 1 つまたは複数の永続ボリュームが使用されるクラスターでサポートされます。
永続ボリュームのサイズを拡張することはできますが、縮小することはできません。永続ボリュームのサイズ縮小は、現在 OpenShift ではサポートされていません。
前提条件
- ボリュームのサイズ変更をサポートする OpenShift クラスター。
- Cluster Operator が稼働している必要があります。
- ボリューム拡張をサポートするストレージクラスを使用して作成された永続ボリュームを使用する Kafka クラスター。
手順
Kafka
リソースで、Kafka クラスター、ZooKeeper クラスター、またはその両方に割り当てられた永続ボリュームのサイズを増やします。-
Kafka クラスターに割り当てられたボリュームサイズを増やすには、
spec.kafka.storage
プロパティーを編集します。 ZooKeeper クラスターに割り当てたボリュームサイズを増やすには、
spec.zookeeper.storage
プロパティーを編集します。たとえば、ボリュームサイズを
1000Gi
から2000Gi
に増やすには、以下のように編集します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... storage: type: persistent-claim size: 2000Gi class: my-storage-class # ... zookeeper: # ...
-
Kafka クラスターに割り当てられたボリュームサイズを増やすには、
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
OpenShift では、Cluster Operator からの要求に応じて、選択された永続ボリュームの容量が増やされます。サイズ変更が完了すると、サイズ変更された永続ボリュームを使用するすべての Pod が Cluster Operator によって再起動されます。これは自動的に行われます。
その他のリソース
OpenShift での永続ボリュームのサイズ変更に関する詳細は、「Resizing Persistent Volumes using Kubernetes」を参照してください。
2.1.3.5. JBOD ストレージの概要
AMQ Streams で、複数のディスクやボリュームのデータストレージ設定である JBOD を使用するように設定できます。JBOD は、Kafka ブローカーのデータストレージを増やす方法の 1 つです。また、パフォーマンスを向上することもできます。
JBOD 設定は 1 つ以上のボリュームによって記述され、各ボリュームは 一時 または 永続 ボリュームのいずれかになります。JBOD ボリューム宣言のルールおよび制約は、一時および永続ストレージのルールおよび制約と同じです。たとえば、永続ストレージのボリュームをプロビジョニング後に縮小することはできません。また、type=ephemeral の場合は sizeLimit
の値を変更することはできません。
2.1.3.5.1. JBOD の設定
AMQ Streams で JBOD を使用するには、ストレージ type
を jbod
に設定する必要があります。volumes
プロパティーを使用すると、JBOD ストレージアレイまたは設定を構成するディスクを記述できます。以下は、JBOD 設定例の抜粋になります。
# ... storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false - id: 1 type: persistent-claim size: 100Gi deleteClaim: false # ...
id は、JBOD ボリュームの作成後に変更することはできません。
ユーザーは JBOD 設定に対してボリュームを追加または削除できます。
2.1.3.5.2. JBOD および 永続ボリューム要求 (PVC)
永続ストレージを使用して JBOD ボリュームを宣言する場合、永続ボリューム要求 (Persistent Volume Claim、PVC) の命名スキームは以下のようになります。
data-id-cluster-name-kafka-idx
-
id
は、Kafka ブローカー Podidx
のデータを保存するために使用されるボリュームの ID に置き換えます。
2.1.3.5.3. ログディレクトリー
JBOD ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。
/var/lib/kafka/data-id/kafka-log_idx_
-
id
は、Kafka ブローカー Podidx
のデータを保存するために使用されるボリュームの ID に置き換えます。例:/var/lib/kafka/data-0/kafka-log0
2.1.3.6. JBOD ストレージへのボリュームの追加
この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターにボリュームを追加する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。
以前使用され、削除された id
の下に新規ボリュームを追加する場合、以前使用された PersistentVolumeClaims
が必ず削除されているよう確認する必要があります。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
- JBOD ストレージのある Kafka クラスター。
手順
Kafka
リソースのspec.kafka.storage.volumes
プロパティーを編集します。新しいボリュームをvolumes
アレイに追加します。たとえば、id が2
の新しいボリュームを追加します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false - id: 1 type: persistent-claim size: 100Gi deleteClaim: false - id: 2 type: persistent-claim size: 100Gi deleteClaim: false # ... zookeeper: # ...
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
- 新しいトピックを作成するか、既存のパーティションを新しいディスクに再度割り当てします。
その他のリソース
トピックの再割り当てに関する詳細は 「パーティションの再割り当て」 を参照してください。
2.1.3.7. JBOD ストレージからのボリュームの削除
この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターからボリュームを削除する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。JBOD ストレージには、常に 1 つのボリュームが含まれている必要があります。
データの損失を避けるには、ボリュームを削除する前にすべてのパーティションを移動する必要があります。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
- 複数のボリュームがある JBOD ストレージのある Kafka クラスター。
手順
- 削除するディスクからすべてのパーティションを再度割り当てます。削除するディスクに割り当てられたままになっているパーティションのデータは削除される可能性があります。
Kafka
リソースのspec.kafka.storage.volumes
プロパティーを編集します。volumes
アレイから 1 つまたは複数のボリュームを削除します。たとえば、ID が1
と2
のボリュームを削除します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false # ... zookeeper: # ...
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
その他のリソース
トピックの再割り当てに関する詳細は 「パーティションの再割り当て」 を参照してください。
2.1.4. クラスターのスケーリング
2.1.4.1. Kafka クラスターのスケーリング
2.1.4.1.1. ブローカーのクラスターへの追加
トピックのスループットを向上させる主な方法は、そのトピックのパーティション数を増やすことです。これにより、追加のパーティションによってクラスター内の異なるブローカー間でトピックの負荷が共有されます。ただし、各ブローカーが特定のリソース (通常は I/O) によって制約される場合、パーティションを増やしてもスループットは向上しません。代わりに、ブローカーをクラスターに追加する必要があります。
追加のブローカーをクラスターに追加する場合、Kafka ではパーティションは自動的に割り当てられません。既存のブローカーから新規のブローカーに移動するパーティションを決定する必要があります。
すべてのブローカー間でパーティションが再分散されたら、各ブローカーのリソース使用率が低下するはずです。
2.1.4.1.2. クラスターからのブローカーの削除
AMQ Streams では StatefulSets
を使用してブローカー Pod を管理されるため、あらゆる Pod を削除できるわけではありません。クラスターから削除できるのは、番号が最も大きい 1 つまたは複数の Pod のみです。たとえば、12 個のブローカーがあるクラスターでは、Pod の名前は cluster-name-kafka-0
から cluster-name-kafka-11
になります。1 つのブローカー分をスケールダウンする場合、cluster-name-kafka-11
が削除されます。
クラスターからブローカーを削除する前に、そのブローカーにパーティションが割り当てられていないことを確認します。また、使用が停止されたブローカーの各パーティションを引き継ぐ、残りのブローカーを決める必要もあります。ブローカーに割り当てられたパーティションがなければ、クラスターを安全にスケールダウンできます。
2.1.4.2. パーティションの再割り当て
現在、Topic Operator はレプリカを別のブローカーに再割当てすることをサポートしないため、ブローカー Pod に直接接続してレプリカをブローカーに再割り当てする必要があります。
ブローカー Pod 内では、kafka-reassign-partitions.sh
ユーティリティーを使用してパーティションを別のブローカーに再割り当てできます。
これには、以下の 3 つのモードがあります。
--generate
- トピックとブローカーのセットを取り、再割り当て JSON ファイル を生成します。これにより、トピックのパーティションがブローカーに割り当てられます。これはトピック全体で動作するため、一部のトピックのパーティションを再度割り当てする場合は使用できません。
--execute
- 再割り当て JSON ファイル を取り、クラスターのパーティションおよびブローカーに適用します。その結果、パーティションを取得したブローカーは、パーティションリーダーのフォロワーになります。新規ブローカーが ISR (In-Sync Replica、同期レプリカ) に参加できたら、古いブローカーはフォロワーではなくなり、そのレプリカが削除されます。
--verify
-
--verify
は、--execute
ステップと同じ 再割り当て JSON ファイル を使用して、ファイル内のすべてのパーティションが目的のブローカーに移動されたかどうかを確認します。再割り当てが完了すると、--verify は有効な スロットル も削除します。スロットルを削除しないと、再割り当てが完了した後もクラスターは影響を受け続けます。
クラスターでは、1 度に 1 つの再割当てのみを実行でき、実行中の再割当てをキャンセルすることはできません。再割り当てをキャンセルする必要がある場合は、割り当てが完了するのを待ってから別の再割り当てを実行し、最初の再割り当ての結果を元に戻します。kafka-reassign-partitions.sh
によって、元に戻すための再割り当て JSON が出力の一部として生成されます。大規模な再割り当ては、進行中の再割り当てを停止する必要がある場合に備えて、複数の小さな再割り当てに分割するようにしてください。
2.1.4.2.1. 再割り当て JSON ファイル
再割り当て JSON ファイル には特定の構造があります。
{
"version": 1,
"partitions": [
<PartitionObjects>
]
}
ここで <PartitionObjects> は、以下のようなコンマ区切りのオブジェクトリストになります。
{ "topic": <TopicName>, "partition": <Partition>, "replicas": [ <AssignedBrokerIds> ] }
Kafka は "log_dirs"
プロパティーもサポートしますが、AMQ Streams では使用しないでください。
以下は、トピック topic-a
のパーティション 4
をブローカー 2
、4
、および 7
に割り当て、トピック topic-b
のパーティション 2
をブローカー 1
、5
、および 7
に割り当てる、再割り当て JSON ファイルの例になります。
{ "version": 1, "partitions": [ { "topic": "topic-a", "partition": 4, "replicas": [2,4,7] }, { "topic": "topic-b", "partition": 2, "replicas": [1,5,7] } ] }
JSON に含まれていないパーティションは変更されません。
2.1.4.2.2. JBOD ボリューム間でのパーティションの再割り当て
Kafka クラスターで JBOD ストレージを使用する場合は、特定のボリュームとログディレクトリー (各ボリュームに単一のログディレクトリーがある) との間でパーティションを再割り当てを選択することができます。パーティションを特定のボリュームに再割り当てするには、再割り当て JSON ファイルで log_dirs
オプションを <PartitionObjects> に追加します。
{ "topic": <TopicName>, "partition": <Partition>, "replicas": [ <AssignedBrokerIds> ], "log_dirs": [ <AssignedLogDirs> ] }
log_dirs
オブジェクトに含まれるログディレクトリーの数は、replicas
オブジェクトで指定されるレプリカ数と同じである必要があります。値は、ログディレクトリーへの絶対パスか、any
キーワードである必要があります。
以下に例を示します。
{ "topic": "topic-a", "partition": 4, "replicas": [2,4,7]. "log_dirs": [ "/var/lib/kafka/data-0/kafka-log2", "/var/lib/kafka/data-0/kafka-log4", "/var/lib/kafka/data-0/kafka-log7" ] }
2.1.4.3. 再割り当て JSON ファイルの生成
この手順では、kafka-reassign-partitions.sh
ツールを使用して、指定のトピックセットすべてのパーティションを再割り当てする再割り当て JSON ファイルを生成する方法を説明します。
前提条件
- 稼働中の Cluster Operator。
-
Kafka
リソース - パーティションを再割り当てするトピックセット。
手順
移動するトピックを一覧表示する
topics.json
という名前の JSON ファイルを準備します。これには、以下の構造が必要です。{ "version": 1, "topics": [ <TopicObjects> ] }
ここで <TopicObjects> は、以下のようなコンマ区切りのオブジェクトリストになります。
{ "topic": <TopicName> }
たとえば、
topic-a
とtopic-b
のすべてのパーティションを再割り当てするには、以下のようなtopics.json
ファイルを準備する必要があります。{ "version": 1, "topics": [ { "topic": "topic-a"}, { "topic": "topic-b"} ] }
topics.json
ファイルをブローカー Pod の 1 つにコピーします。cat topics.json | oc exec -c kafka <BrokerPod> -i -- \ /bin/bash -c \ 'cat > /tmp/topics.json'
kafka-reassign-partitions.sh
コマンドを使用して、再割り当て JSON を生成します。oc exec <BrokerPod> -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --topics-to-move-json-file /tmp/topics.json \ --broker-list <BrokerList> \ --generate
たとえば、
topic-a
およびtopic-b
のすべてのパーティションをブローカー4
および7
に移動する場合は、以下を実行します。oc exec <BrokerPod> -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --topics-to-move-json-file /tmp/topics.json \ --broker-list 4,7 \ --generate
2.1.4.4. 手動による再割り当て JSON ファイルの作成
特定のパーティションを移動したい場合は、再割り当て JSON ファイルを手動で作成できます。
2.1.4.5. 再割り当てスロットル
パーティションの再割り当てには、ブローカーの間で大量のデータを転送する必要があるため、処理が遅くなる可能性があります。クライアントへの悪影響を防ぐため、再割り当て処理をスロットルで調整することができます。これにより、再割り当ての完了に時間がかかる可能性があります。
- スロットルが低すぎると、新たに割り当てられたブローカーは公開されるレコードに遅れずに対応することはできず、再割り当ては永久に完了しません。
- スロットルが高すぎると、クライアントに影響します。
たとえば、プロデューサーの場合は、承認待ちが通常のレイテンシーよりも大きくなる可能性があります。コンシューマーの場合は、ポーリング間のレイテンシーが大きいことが原因でスループットが低下する可能性があります。
2.1.4.6. Kafka クラスターのスケールアップ
この手順では、Kafka クラスターでブローカーの数を増やす方法を説明します。
前提条件
- 既存の Kafka クラスター。
-
拡大されたクラスターでパーティションをブローカーに再割り当てする方法が記述される
reassignment.json
というファイル名の 再割り当て JSON ファイル。
手順
-
Kafka.spec.kafka.replicas
設定オプションを増やして、新しいブローカーを必要なだけ追加します。 - 新しいブローカー Pod が起動したことを確認します。
後でコマンドを実行するブローカー Pod に
reassignment.json
ファイルをコピーします。cat reassignment.json | \ oc exec broker-pod -c kafka -i -- /bin/bash -c \ 'cat > /tmp/reassignment.json'
以下に例を示します。
cat reassignment.json | \ oc exec my-cluster-kafka-0 -c kafka -i -- /bin/bash -c \ 'cat > /tmp/reassignment.json'
同じブローカー Pod から
kafka-reassign-partitions.sh
コマンドラインツールを使用して、パーティションの再割り当てを実行します。oc exec broker-pod -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --execute
レプリケーションをスロットルで調整する場合、
--throttle
とブローカー間のスロットル率 (バイト/秒単位) を渡すこともできます。以下に例を示します。oc exec my-cluster-kafka-0 -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --throttle 5000000 \ --execute
このコマンドは、2 つの再割り当て JSON オブジェクトを出力します。最初の JSON オブジェクトには、移動されたパーティションの現在の割り当てが記録されます。後で再割り当てを元に戻す必要がある場合に備え、この値をローカルファイル (Pod のファイル以外) に保存します。2 つ目の JSON オブジェクトは、再割り当て JSON ファイルに渡した目的の再割り当てです。
再割り当ての最中にスロットルを変更する必要がある場合は、同じコマンドラインに別のスロットル率を指定して実行します。以下に例を示します。
oc exec my-cluster-kafka-0 -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --throttle 10000000 \ --execute
ブローカー Pod のいずれかから
kafka-reassign-partitions.sh
コマンドラインツールを使用して、再割り当てが完了したかどうかを定期的に確認します。これは先ほどの手順と同じコマンドですが、--execute
オプションの代わりに--verify
オプションを使用します。oc exec broker-pod -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --verify
例:
oc exec my-cluster-kafka-0 -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --verify
-
--verify
コマンドによって、移動した各パーティションが正常に完了したことが報告されると、再割り当ては終了します。この最終的な--verify
によって、結果的に再割り当てスロットルも削除されます。割り当てを元のブローカーに戻すために JSON ファイルを保存した場合は、ここでそのファイルを削除できます。
2.1.4.7. Kafka クラスターのスケールダウン
この手順では、Kafka クラスターでブローカーの数を減らす方法を説明します。
前提条件
- 既存の Kafka クラスター。
-
最も番号の大きい
Pod(s)
のブローカーが削除された後にクラスターのブローカーにパーティションを再割り当てする方法が記述されている、reassignment.json
という名前の 再割り当て JSON ファイル。
手順
後でコマンドを実行するブローカー Pod に
reassignment.json
ファイルをコピーします。cat reassignment.json | \ oc exec broker-pod -c kafka -i -- /bin/bash -c \ 'cat > /tmp/reassignment.json'
以下に例を示します。
cat reassignment.json | \ oc exec my-cluster-kafka-0 -c kafka -i -- /bin/bash -c \ 'cat > /tmp/reassignment.json'
同じブローカー Pod から
kafka-reassign-partitions.sh
コマンドラインツールを使用して、パーティションの再割り当てを実行します。oc exec broker-pod -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --execute
レプリケーションをスロットルで調整する場合、
--throttle
とブローカー間のスロットル率 (バイト/秒単位) を渡すこともできます。以下に例を示します。oc exec my-cluster-kafka-0 -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --throttle 5000000 \ --execute
このコマンドは、2 つの再割り当て JSON オブジェクトを出力します。最初の JSON オブジェクトには、移動されたパーティションの現在の割り当てが記録されます。後で再割り当てを元に戻す必要がある場合に備え、この値をローカルファイル (Pod のファイル以外) に保存します。2 つ目の JSON オブジェクトは、再割り当て JSON ファイルに渡した目的の再割り当てです。
再割り当ての最中にスロットルを変更する必要がある場合は、同じコマンドラインに別のスロットル率を指定して実行します。以下に例を示します。
oc exec my-cluster-kafka-0 -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --throttle 10000000 \ --execute
ブローカー Pod のいずれかから
kafka-reassign-partitions.sh
コマンドラインツールを使用して、再割り当てが完了したかどうかを定期的に確認します。これは先ほどの手順と同じコマンドですが、--execute
オプションの代わりに--verify
オプションを使用します。oc exec broker-pod -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --verify
例:
oc exec my-cluster-kafka-0 -c kafka -it -- \ bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \ --reassignment-json-file /tmp/reassignment.json \ --verify
-
--verify
コマンドによって、移動した各パーティションが正常に完了したことが報告されると、再割り当ては終了します。この最終的な--verify
によって、結果的に再割り当てスロットルも削除されます。割り当てを元のブローカーに戻すために JSON ファイルを保存した場合は、ここでそのファイルを削除できます。 すべてのパーティションの再割り当てが終了すると、削除されるブローカーはクラスター内のいずれのパーティションにも対応しないはずです。これは、ブローカーのデータログディレクトリーにライブパーティションのログが含まれていないことを確認すると検証できます。ブローカーのログディレクトリーに、拡張正規表現
\.[a-z0-9]-delete$
と一致しないディレクトリーが含まれる場合、ブローカーにライブパーティションがあるため、停止してはなりません。これを確認するには、以下のコマンドを実行します。
oc exec my-cluster-kafka-0 -c kafka -it -- \ /bin/bash -c \ "ls -l /var/lib/kafka/kafka-log_<N>_ | grep -E '^d' | grep -vE '[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$'"
N は削除された
Pod(s)
の数に置き換えます。上記のコマンドによって出力が生成される場合、ブローカーにはライブパーティションがあります。この場合、再割り当てが終了していないか、再割り当て JSON ファイルが適切ではありません。
-
ブローカーにライブパーティションがないことが確認できたら、
Kafka
リソースのKafka.spec.kafka.replicas
を編集できます。これにより、StatefulSet
がスケールダウンされ、番号が最も大きいブローカーPod(s)
が削除されます。
2.1.5. ローリングアップデートのメンテナンス時間枠
メンテナンス時間枠によって、Kafka および ZooKeeper クラスターの特定のローリングアップデートが便利な時間に開始されるようにスケジュールできます。
2.1.5.1. メンテナンス時間枠の概要
ほとんどの場合、Cluster Operator は対応する Kafka
リソースの変更に対応するために Kafka または ZooKeeper クラスターのみを更新します。これにより、Kafka
リソースの変更を適用するタイミングを計画し、Kafka クライアントアプリケーションへの影響を最小限に抑えることができます。
ただし、Kafka
リソースの変更がなくても Kafka および ZooKeeper クラスターの更新が発生することがあります。たとえば、Cluster Operator によって管理される CA (認証局) 証明書が期限切れ直前である場合にローリング再起動の実行が必要になります。
サービスの 可用性 は Pod のローリング再起動による影響を受けないはずですが (ブローカーおよびトピックの設定が適切である場合)、Kafka クライアントアプリケーションの パフォーマンス は影響を受ける可能性があります。メンテナンス時間枠によって、Kafka および ZooKeeper クラスターのこのような自発的なアップデートが便利な時間に開始されるようにスケジュールできます。メンテナンス時間枠がクラスターに設定されていない場合は、予測できない高負荷が発生する期間など、不便な時間にこのような自発的なローリングアップデートが行われる可能性があります。
2.1.5.2. メンテナンス時間枠の定義
Kafka.spec.maintenanceTimeWindows
プロパティーに文字列の配列を入力して、メンテナンス時間枠を設定します。各文字列は、UTC (協定世界時、Coordinated Universal Time) であると解釈される cron 式 です。UTC は実用的にはグリニッジ標準時と同じです。
以下の例では、日、月、火、水、および木曜日の午前 0 時に開始し、午前 1 時 59 分 (UTC) に終わる、単一のメンテナンス時間枠が設定されます。
# ... maintenanceTimeWindows: - "* * 0-1 ? * SUN,MON,TUE,WED,THU *" # ...
実際には、必要な CA 証明書の更新が設定されたメンテナンス時間枠内で完了できるように、Kafka
リソースの Kafka.spec.clusterCa.renewalDays
および Kafka.spec.clientsCa.renewalDays
プロパティーとともにメンテナンス期間を設定する必要があります。
AMQ Streams では、指定の期間にしたがってメンテナンス操作を正確にスケジュールしません。その代わりに、調整ごとにメンテナンス期間が現在「オープン」であるかどうかを確認します。これは、特定の時間枠内でのメンテナンス操作の開始が、最大で Cluster Operator の調整が行われる間隔の長さ分、遅れる可能性があることを意味します。したがって、メンテナンス時間枠は最低でもその間隔の長さにする必要があります。
その他のリソース
- Cluster Operator 設定についての詳細は、「Cluster Operator の設定」 を参照してください。
2.1.5.3. メンテナンス時間枠の設定
サポートされるプロセスによってトリガーされるローリングアップデートのメンテナンス時間枠を設定できます。
前提条件
- OpenShift クラスターが必要です。
- Cluster Operator が稼働している必要があります。
手順
Kafka
リソースでmaintenanceTimeWindows
プロパティーを追加または編集します。たとえば、0800 から 1059 までと、1400 から 1559 までのメンテナンスを可能にするには、以下のようにmaintenanceTimeWindows
を設定します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... maintenanceTimeWindows: - "* * 8-10 * * ?" - "* * 14-15 * * ?"
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
その他のリソース
ローリングアップデートの実行:
2.1.6. ターミナルからの ZooKeeper への接続
ほとんどの Kafka CLI ツールは Kafka に直接接続できます。したがって、通常の状況では ZooKeeper に接続する必要はありません。ZooKeeper サービスは暗号化および認証でセキュア化され、AMQ Streams の一部でない外部アプリケーションでの使用は想定されていません。
しかし、ZooKeeper への接続を必要とする Kafka CLI ツールを使用する場合は、ZooKeeper コンテナー内でターミナルを使用し、ZooKeeper アドレスとして localhost:12181
に接続できます。
前提条件
- OpenShift クラスターが利用できる必要があります。
- Kafka クラスターが稼働している必要があります。
- Cluster Operator が稼働している必要があります。
手順
OpenShift コンソールを使用してターミナルを開くか、CLI から
exec
コマンドを実行します。以下に例を示します。
oc exec -ti my-cluster-zookeeper-0 -- bin/kafka-topics.sh --list --zookeeper localhost:12181
必ず
localhost:12181
を使用してください。ZooKeeper に対して Kafka コマンドを実行できるようになりました。
2.1.7. Kafka ノードの手動による削除
この手順では、OpenShift アノテーションを使用して既存の Kafka ノードを削除する方法を説明します。Kafka ノードの削除するには、Kafka ブローカーが稼働している Pod
と、関連する PersistentVolumeClaim
の両方を削除します (クラスターが永続ストレージでデプロイされた場合)。削除後、Pod
と関連する PersistentVolumeClaim
は自動的に再作成されます。
PersistentVolumeClaim
を削除すると、データが永久に失われる可能性があります。以下の手順は、ストレージで問題が発生した場合にのみ実行してください。
前提条件
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
手順
削除する
Pod
の名前を見つけます。たとえば、クラスターの名前が cluster-name の場合、Pod の名前は cluster-name-kafka-index になります。index はゼロで始まり、レプリカーの合計数で終わる値です。
OpenShift で
Pod
リソースにアノテーションを付けます。oc annotate
を使用します。oc annotate pod cluster-name-kafka-index strimzi.io/delete-pod-and-pvc=true
- 基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。
2.1.8. ZooKeeper ノードの手動による削除
この手順では、OpenShift アノテーションを使用して既存の ZooKeeper ノードを削除する方法を説明します。ZooKeeper ノードの削除するには、ZooKeeper が稼働している Pod
と、関連する PersistentVolumeClaim
の両方を削除します (クラスターが永続ストレージでデプロイされた場合)。削除後、Pod
と関連する PersistentVolumeClaim
は自動的に再作成されます。
PersistentVolumeClaim
を削除すると、データが永久に失われる可能性があります。以下の手順は、ストレージで問題が発生した場合にのみ実行してください。
前提条件
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
手順
削除する
Pod
の名前を見つけます。たとえば、クラスターの名前が cluster-name の場合、Pod の名前は cluster-name-zookeeper-index になります。index はゼロで始まり、レプリカーの合計数で終わる値です。
OpenShift で
Pod
リソースにアノテーションを付けます。oc annotate
を使用します。oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true
- 基盤となる永続ボリューム要求 (Persistent Volume Claim) でアノテーションが付けられた Pod が削除され、再作成されるときに、次の調整の実行を待ちます。
2.1.9. Kafka クラスターリソースのリスト
以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。
共有リソース
cluster-name-cluster-ca
- クラスター通信の暗号化に使用されるクラスター CA プライベートキーのあるシークレット。
cluster-name-cluster-ca-cert
- クラスター CA 公開鍵のあるシークレット。このキーは、Kafka ブローカーのアイデンティティーの検証に使用できます。
cluster-name-clients-ca
- ユーザー証明書に署名するために使用されるクライアント CA 秘密鍵のあるシークレット。
cluster-name-clients-ca-cert
- クライアント CA 公開鍵のあるシークレット。このキーは、Kafka ユーザーのアイデンティティーの検証に使用できます。
cluster-name-cluster-operator-certs
- Kafka および ZooKeeper と通信するための Cluster Operator キーのあるシークレット。
ZooKeeper ノード
cluster-name-zookeeper
- ZooKeeper ノード Pod の管理を担当する StatefulSet。
cluster-name-zookeeper-idx
- Zookeeper StatefulSet によって作成された Pod。
cluster-name-zookeeper-nodes
- DNS が ZooKeeper Pod の IP アドレスを直接解決するのに必要なヘッドレスサービス。
cluster-name-zookeeper-client
- Kafka ブローカーがクライアントとして ZooKeeper ノードに接続するために使用するサービス。
cluster-name-zookeeper-config
- ZooKeeper 補助設定が含まれ、ZooKeeper ノード Pod によってボリュームとしてマウントされる ConfigMap。
cluster-name-zookeeper-nodes
- ZooKeeper ノードキーがあるシークレット。
cluster-name-zookeeper
- Zookeeper ノードで使用されるサービスアカウント。
cluster-name-zookeeper
- ZooKeeper ノードに設定された Pod の Disruption Budget。
cluster-name-network-policy-zookeeper
- ZooKeeper サービスへのアクセスを管理するネットワークポリシー。
data-cluster-name-zookeeper-idx
-
ZooKeeper ノード Pod
idx
のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。
Kafka ブローカー
cluster-name-kafka
- Kafka ブローカー Pod の管理を担当する StatefulSet。
cluster-name-kafka-idx
- Kafka StatefulSet によって作成された Pod。
cluster-name-kafka-brokers
- DNS が Kafka ブローカー Pod の IP アドレスを直接解決するのに必要なサービス。
cluster-name-kafka-bootstrap
- サービスは、OpenShift クラスター内から接続する Kafka クライアントのブートストラップサーバーとして使用できます。
cluster-name-kafka-external-bootstrap
-
OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。リスナー名が
external
で、ポートが9094
である場合に、古いサービス名は後方互換性を維持するために使用されます。 cluster-name-kafka-pod-id
-
トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。リスナー名が
external
で、ポートが9094
である場合に、古いサービス名は後方互換性を維持するために使用されます。 cluster-name-kafka-external-bootstrap
-
OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効になっていて、タイプ
route
に設定されている場合にのみ作成されます。リスナー名がexternal
で、ポートが9094
である場合に、古いルート名は後方互換性を維持するために使用されます。 cluster-name-kafka-pod-id
-
OpenShift クラスターの外部から個別の Pod へのトラフィックに対するルート。このリソースは、外部リスナーが有効になっていて、タイプ
route
に設定されている場合にのみ作成されます。リスナー名がexternal
で、ポートが9094
である場合に、古いルート名は後方互換性を維持するために使用されます。 cluster-name-kafka-listener-name-bootstrap
- OpenShift クラスター外部から接続するクライアントのブートストラップサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。新しいサービス名はその他すべての外部リスナーに使用されます。
cluster-name-kafka-listener-name-pod-id
- トラフィックを OpenShift クラスターの外部から個別の Pod にルーティングするために使用されるサービス。このリソースは、外部リスナーが有効な場合にのみ作成されます。新しいサービス名はその他すべての外部リスナーに使用されます。
cluster-name-kafka-listener-name-bootstrap
-
OpenShift クラスターの外部から接続するクライアントのブートストラップルート。このリソースは、外部リスナーが有効になっていて、タイプ
route
に設定されている場合にのみ作成されます。新しいルート名はその他すべての外部リスナーに使用されます。 cluster-name-kafka-listener-name-pod-id
-
OpenShift クラスターの外部から個別の Pod へのトラフィックに対するルート。このリソースは、外部リスナーが有効になっていて、タイプ
route
に設定されている場合にのみ作成されます。新しいルート名はその他すべての外部リスナーに使用されます。 cluster-name-kafka-config
- Kafka 補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
cluster-name-kafka-brokers
- Kafka ブローカーキーのあるシークレット。
cluster-name-kafka
- Kafka ブローカーによって使用されるサービスアカウント。
cluster-name-kafka
- Kafka ブローカーに設定された Pod の Disruption Budget。
cluster-name-network-policy-kafka
- Kafka サービスへのアクセスを管理するネットワークポリシー。
strimzi-namespace-name-cluster-name-kafka-init
- Kafka ブローカーによって使用されるクラスターロールバインディング。
cluster-name-jmx
- Kafka ブローカーポートのセキュア化に使用される JMX ユーザー名およびパスワードのあるシークレット。このリソースは、Kafka で JMX が有効になっている場合にのみ作成されます。
data-cluster-name-kafka-idx
-
Kafka ブローカー Pod
idx
のデータを保存するために使用されるボリュームの永続ボリューム要求です。このリソースは、データを保存するために永続ボリュームのプロビジョニングに永続ストレージが選択された場合のみ作成されます。 data-id-cluster-name-kafka-idx
-
Kafka ブローカー Pod
idx
のデータを保存するために使用されるボリュームid
の永続ボリューム要求です。このリソースは、永続ボリュームをプロビジョニングしてデータを保存するときに、JBOD ボリュームに永続ストレージが選択された場合のみ作成されます。
Entitiy Operator
これらのリソースは、Cluster Operator を使用して Entity Operator がデプロイされる場合にのみ作成されます。
cluster-name-entity-operator
- Topic および User Operator とのデプロイメント。
cluster-name-entity-operator-random-string
- Entity Operator デプロイメントによって作成された Pod。
cluster-name-entity-topic-operator-config
- Topic Operator の補助設定のある ConfigMap。
cluster-name-entity-user-operator-config
- User Operator の補助設定のある ConfigMap。
cluster-name-entity-operator-certs
- Kafka および ZooKeeper と通信するための Entity Operator キーのあるシークレット。
cluster-name-entity-operator
- Entity Operator によって使用されるサービスアカウント。
strimzi-cluster-name-entity-topic-operator
- Entity Topic Operator によって使用されるロールバインディング。
strimzi-cluster-name-entity-user-operator
- Entity User Operator によって使用されるロールバインディング。
Kafka Exporter
これらのリソースは、Cluster Operator を使用して Kafka Exporter がデプロイされる場合にのみ作成されます。
cluster-name-kafka-exporter
- Kafka Exporter でのデプロイメント。
cluster-name-kafka-exporter-random-string
- Kafka Exporter デプロイメントによって作成された Pod。
cluster-name-kafka-exporter
- コンシューマーラグメトリクスの収集に使用されるサービス。
cluster-name-kafka-exporter
- Kafka Exporter によって使用されるサービスアカウント。
Cruise Control
これらのリソースは、Cluster Operator を使用して Cruise Control がデプロイされた場合のみ作成されます。
cluster-name-cruise-control
- Cruise Control でのデプロイメント。
cluster-name-cruise-control-random-string
- Cruise Control デプロイメントによって作成された Pod。
cluster-name-cruise-control-config
- Cruise Control の補助設定が含まれ、Cruise Control Pod によってボリュームとしてマウントされる ConfigMap。
cluster-name-cruise-control-certs
- Kafka および ZooKeeper と通信するための Cruise Control キーのあるシークレット。
cluster-name-cruise-control
- Cruise Control との通信に使用されるサービス。
cluster-name-cruise-control
- Cruise Control によって使用されるサービスアカウント。
cluster-name-network-policy-cruise-control
- Cruise Control サービスへのアクセスを管理するネットワークポリシー。
2.2. Kafka Connect/S2I クラスターの設定
ここでは、AMQ Streams クラスターにて Kafka Connect や S2I (Source-to-Image) のある Kafka Connect デプロイメントを設定する方法を説明します。
Kafka Connect は、コネクタープラグインを使用して Kafka ブローカーと他のシステムの間でデータをストリーミングする統合ツールです。Kafka Connect は、Kafka と、データベースなどの外部データソースまたはターゲットと統合するためのフレームワークを提供し、コネクターを使用してデータをインポートまたはエクスポートします。コネクターは、必要な接続設定を提供するプラグインです。
Kafka Connect を使用している場合は、KafkaConnect
または KafkaConnectS2I
リソースを設定します。S2I (Source-to-Image) フレームワークを使用して Kafka Connect をデプロイする場合は、KafkaConnectS2I
リソースを使用します。
-
KafkaConnect
リソースの完全なスキーマは 「KafkaConnect
スキーマ参照」 に記載されています。 -
KafkaConnectS2I
リソースの完全なスキーマは 「KafkaConnectS2I
スキーマ参照」 に記載されています。
build
設定が KafkaConnect
リソースに導入されたため、AMQ Streams はデータコネクションに必要なコネクタープラグインでコンテナーイメージを自動的にビルドできるようになりました。そのため、S2I (Source-to-Image) 対応の Kafka Connect のサポートが非推奨になりました。この変更に備えるため、Kafka Connect S2I インスタンスを Kafka Connect インスタンスに移行できます。
その他のリソース
2.2.1. Kafka Connect の設定
Kafka Connect を使用して、Kafka クラスターへの外部データ接続を設定します。
KafkaConnect
または KafkaConnectS2I
リソースのプロパティーを使用して、Kafka Connect デプロイメントを設定します。この手順の例は、KafkaConnect
リソースの場合ですが、プロパティーは KafkaConnectS2I
リソースと同じです。
Kafka Connector の設定
KafkaConnect リソースを使用すると、Kafka Connect のコネクターインスタンスを OpenShift ネイティブに作成および管理できます。
Kafka Connect 設定では、strimzi.io/use-connector-resources
アノテーションを追加して、Kafka Connect クラスターの KafkaConnectors を有効にします。AMQ Streams がデータコネクションに必要なコネクタープラグインでコンテナーイメージを自動的にビルドするために、build
設定を追加することもできます。Kafka Connect コネクターの外部設定は、externalConfiguration
プロパティーを使用して指定されます。
コネクターを管理するには、Kafka Connect REST API を使用するか、KafkaConnector カスタムリソースを使用します。KafkaConnector リソースは、リンク先の Kafka Connect クラスターと同じ namespace にデプロイする必要があります。これらの方法を使用して、コネクターを作成、再割り当て、または削除するための詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「コネクターの作成および管理」を参照してください。
コネクター設定は、HTTP リクエストの一部として Kafka Connect に渡され、Kafka 自体に保存されます。ConfigMap およびシークレットは、設定やデータの保存に使用される標準的な OpenShift リソースです。ConfigMap およびシークレットを使用してコネクターの特定の要素を設定できます。その後、HTTP REST コマンドで設定値を参照できます。これにより、必要な場合は設定が分離され、よりセキュアになります。この方法は、ユーザー名、パスワード、証明書などの機密性の高いデータに適用されます。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
手順
KafkaConnect
またはKafkaConnectS2I
リソースのspec
プロパティーを編集します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect 1 metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 2 spec: replicas: 3 3 authentication: 4 type: tls certificateAndKey: certificate: source.crt key: source.key secretName: my-user-source bootstrapServers: my-cluster-kafka-bootstrap:9092 5 tls: 6 trustedCertificates: - secretName: my-cluster-cluster-cert certificate: ca.crt - secretName: my-cluster-cluster-cert certificate: ca2.crt config: 7 group.id: my-connect-cluster offset.storage.topic: my-connect-cluster-offsets config.storage.topic: my-connect-cluster-configs status.storage.topic: my-connect-cluster-status key.converter: org.apache.kafka.connect.json.JsonConverter value.converter: org.apache.kafka.connect.json.JsonConverter key.converter.schemas.enable: true value.converter.schemas.enable: true config.storage.replication.factor: 3 offset.storage.replication.factor: 3 status.storage.replication.factor: 3 build: 8 output: 9 type: docker image: my-registry.io/my-org/my-connect-cluster:latest pushSecret: my-registry-credentials plugins: 10 - name: debezium-postgres-connector artifacts: - type: tgz url: https://repo1.maven.org/maven2/io/debezium/debezium-connector-postgres/1.3.1.Final/debezium-connector-postgres-1.3.1.Final-plugin.tar.gz sha512sum: 962a12151bdf9a5a30627eebac739955a4fd95a08d373b86bdcea2b4d0c27dd6e1edd5cb548045e115e33a9e69b1b2a352bee24df035a0447cb820077af00c03 - name: camel-telegram artifacts: - type: tgz url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.7.0/camel-telegram-kafka-connector-0.7.0-package.tar.gz sha512sum: a9b1ac63e3284bea7836d7d24d84208c49cdf5600070e6bd1535de654f6920b74ad950d51733e8020bf4187870699819f54ef5859c7846ee4081507f48873479 externalConfiguration: 11 env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: aws-creds key: awsAccessKey - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: aws-creds key: awsSecretAccessKey resources: 12 requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 2Gi logging: 13 type: inline loggers: log4j.rootLogger: "INFO" readinessProbe: 14 initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 metricsConfig: 15 type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: my-config-map key: my-key jvmOptions: 16 "-Xmx": "1g" "-Xms": "1g" image: my-org/my-image:latest 17 rack: topologyKey: topology.kubernetes.io/zone 18 template: 19 pod: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: application operator: In values: - postgresql - mongodb topologyKey: "kubernetes.io/hostname" connectContainer: 20 env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831"
- 1
- 必要に応じて、
KafkaConnect
またはKafkaConnectS2I
を使用します。 - 2
- Kafka Connect クラスターの KafkaConnectors を有効にします。
- 3
- 4
- OAuth ベアラートークン、SASL ベースの SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズム を使用する、Kafka Connect クラスターの認証。デフォルトでは、Kafka Connect はプレーンテキスト接続を使用して Kafka ブローカーに接続します。
- 5
- Kafka Connect クラスターに接続するためのブートストラップサーバー。
- 6
- クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
- 7
- ワーカー の Kafka Connect 設定 (コネクターではない)。標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
- 8
- コネクタープラグインで自動的にコンテナーイメージをビルドするためのビルド設定プロパティー。
- 9
- (必須) 新しいイメージがプッシュされるコンテナーレジストリーの設定。
- 10
- (必須) 新しいコンテナーイメージに追加するコネクタープラグインとそれらのアーティファクトの一覧。各プラグインは、1 つ以上の
artifact
で設定する必要があります。 - 11
- ここで示す環境変数や、ボリュームを使用した Kafka コネクターの外部設定
- 12
- 13
- ConfigMap にて直接的 (
inline
) または間接的 (external
) に追加される Kafka Connect のロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties
またはlog4j2.properties
キー下に配置する必要があります。Kafka Connectlog4j.rootLogger
ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。 - 14
- コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
- 15
- Prometheus メトリクス。この例では、Prometheus JMX エクスポーターの設定が含まれる ConfigMap を参照して有効になります。
metricsConfig.valueFrom.configMapKeyRef.key
下の空のファイルが含まれる ConfigMap への参照を使用すると、追加設定なしでメトリクスを有効にできます。 - 16
- Kafka Connect を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
- 17
- 高度な任意設定: 特別な場合のみ推奨されるコンテナーイメージの設定。
- 18
- ラックアウェアネス (Rack awareness) は、異なるラック全体でレプリカを分散するために設定されます。
topologykey
はクラスターノードのラベルと一致する必要があります。 - 19
- テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
- 20
- 環境変数は、Jaeger を使用した分散トレーシングにも設定 されます。
リソースを作成または更新します。
oc apply -f KAFKA-CONNECT-CONFIG-FILE
- Kafka Connect の承認が有効である場合、Kafka Connect ユーザーを設定し、Kafka Connect のコンシューマーグループおよびトピックへのアクセスを有効にします。
2.2.2. 複数インスタンスの Kafka Connect 設定
Kafka Connect のインスタンスを複数実行している場合は、以下の config
プロパティーのデフォルト設定を変更する必要があります。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... config: group.id: connect-cluster 1 offset.storage.topic: connect-cluster-offsets 2 config.storage.topic: connect-cluster-configs 3 status.storage.topic: connect-cluster-status 4 # ... # ...
これら 3 つのトピックの値は、同じ group.id
を持つすべての Kafka Connect インスタンスで同じする必要があります。
デフォルト設定を変更しないと、同じ Kafka クラスターに接続する各 Kafka Connect インスタンスは同じ値でデプロイされます。その結果、事実上はすべてのインスタンスが結合されてクラスターで実行され、同じトピックが使用されます。
複数の Kafka Connect クラスターが同じトピックの使用を試みると、Kafka Connect は想定どおりに動作せず、エラーが生成されます。
複数の Kafka Connect インスタンスを実行する場合は、インスタンスごとにこれらのプロパティーの値を変更してください。
2.2.3. Kafka Connect のユーザー承認の設定
この手順では、Kafka Connect のユーザーアクセスを承認する方法を説明します。
Kafka でいかなるタイプの承認が使用される場合、Kafka Connect ユーザーは Kafka Connect のコンシューマーグループおよび内部トピックへの読み書きアクセス権限が必要になります。
コンシューマーグループおよび内部トピックのプロパティーは AMQ Streams によって自動設定されますが、 KafkaConnect
または KafkaConnectS2I
リソースの spec
で明示的に指定することもできます。
KafkaConnect
リソースの設定プロパティーの例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... config: group.id: my-connect-cluster 1 offset.storage.topic: my-connect-cluster-offsets 2 config.storage.topic: my-connect-cluster-configs 3 status.storage.topic: my-connect-cluster-status 4 # ... # ...
この手順では、simple
承認の使用時にアクセス権限が付与される方法を説明します。
簡易 (simple) 承認は、Kafka AclAuthorizer
プラグインによって処理される ACL ルールを使用し、適切なレベルのアクセス権限が提供されます。簡易 (simple) 承認を使用するように KafkaUser
リソースを設定するための詳細は、「AclRule
スキーマ参照」を参照してください。
複数のインスタンスを実行している場合、コンシューマーグループとトピックのデフォルト値は異なります。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
KafkaUser
リソースのauthorization
プロパティーを編集し、アクセス権限をユーザーに付与します。以下の例では、
literal
の名前の値を使用して Kafka Connect トピックおよびコンシューマーグループにアクセス権限が設定されます。プロパティー 名前 offset.storage.topic
connect-cluster-offsets
status.storage.topic
connect-cluster-status
config.storage.topic
connect-cluster-configs
group
connect-cluster
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: # ... authorization: type: simple acls: # access to offset.storage.topic - resource: type: topic name: connect-cluster-offsets patternType: literal operation: Write host: "*" - resource: type: topic name: connect-cluster-offsets patternType: literal operation: Create host: "*" - resource: type: topic name: connect-cluster-offsets patternType: literal operation: Describe host: "*" - resource: type: topic name: connect-cluster-offsets patternType: literal operation: Read host: "*" # access to status.storage.topic - resource: type: topic name: connect-cluster-status patternType: literal operation: Write host: "*" - resource: type: topic name: connect-cluster-status patternType: literal operation: Create host: "*" - resource: type: topic name: connect-cluster-status patternType: literal operation: Describe host: "*" - resource: type: topic name: connect-cluster-status patternType: literal operation: Read host: "*" # access to config.storage.topic - resource: type: topic name: connect-cluster-configs patternType: literal operation: Write host: "*" - resource: type: topic name: connect-cluster-configs patternType: literal operation: Create host: "*" - resource: type: topic name: connect-cluster-configs patternType: literal operation: Describe host: "*" - resource: type: topic name: connect-cluster-configs patternType: literal operation: Read host: "*" # consumer group - resource: type: group name: connect-cluster patternType: literal operation: Read host: "*"
リソースを作成または更新します。
oc apply -f KAFKA-USER-CONFIG-FILE
2.2.4. Kafka コネクターの再起動の実行
この手順では、OpenShift アノテーションを使用して Kafka コネクターの再起動を手動でトリガーする方法を説明します。
前提条件
- Cluster Operator が稼働している必要があります。
手順
再起動する Kafka コネクターを制御する
KafkaConnector
カスタムリソースの名前を見つけます。oc get KafkaConnector
コネクターを再起動するには、OpenShift で
KafkaConnector
リソースにアノテーションを付けます。以下はoc annotate
を使用した例になります。oc annotate KafkaConnector KAFKACONNECTOR-NAME strimzi.io/restart=true
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka コネクターは再起動されます。Kafka Connect が再起動リクエストを受け入れると、アノテーションは
KafkaConnector
カスタムリソースから削除されます。
その他のリソース
- 『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「コネクターの作成および管理」。
2.2.5. Kafka コネクタータスクの再起動の実行
この手順では、OpenShift アノテーションを使用して Kafka コネクタータスクの再起動を手動でトリガーする方法を説明します。
前提条件
- Cluster Operator が稼働している必要があります。
手順
再起動する Kafka コネクタータスクを制御する
KafkaConnector
カスタムリソースの名前を見つけます。oc get KafkaConnector
KafkaConnector
カスタムリソースから再起動するタスクの ID を検索します。タスク ID は 0 から始まる負の値ではない整数です。oc describe KafkaConnector KAFKACONNECTOR-NAME
コネクタータスクを再起動するには、OpenShift で
KafkaConnector
リソースにアノテーションを付けます。たとえば、oc annotate
を使用してタスク 0 を再起動します。oc annotate KafkaConnector KAFKACONNECTOR-NAME strimzi.io/restart-task=0
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka コネクタータスクは再起動されます。Kafka Connect が再起動リクエストを受け入れると、アノテーションは
KafkaConnector
カスタムリソースから削除されます。
その他のリソース
- 『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「コネクターの作成および管理」。
2.2.6. S2I を使用する Kafka Connect から Kafka Connect への移行
S2I を使用する Kafka Connect と KafkaConnectS2I
リソースのサポートは非推奨になりました。これは、データ接続に必要なコネクタープラグインでコンテナーイメージを自動的にビルドするために使用される KafkaConnect
リソースに build
設定プロパティーが導入されたためです。
この手順では、S2I インスタンスのある Kafka Connect を標準の Kafka Connect インスタンスに移行する方法を説明します。これには、KafkaConnectS2I
リソースに代わる、新しい KafkaConnect
カスタムリソースを設定します。設定後、KafkaConnectS2I
リソースは削除されます。
移行プロセスでは、KafkaConnectS2I
インスタンスが削除された時点から、新しい KafkaConnect
インスタンスが正常にデプロイされるまで、ダウンタイムが発生します。この間、コネクターは実行されず、データは処理されません。ただし、変更後に停止した時点からコネクターが続行されるはずです。
前提条件
-
S2I を使用する Kafka Connect が
KafkaConnectS2I
設定を使用してデプロイされている。 - S2I を使用する Kafka Connect が、S2I ビルドを使用して追加されたコネクターでイメージを使用している。
-
シンクおよびソースコネクターインスタンスは
KafkaConnector
リソースまたは Kafka Connect REST API を使用して作成された。
手順
-
KafkaconnectS2I
リソースに使用される名前と同じ名前を使用して、新しいKafkaConnect
カスタムリソースを作成します。 -
KafkaConnectS2I
リソースプロパティーをKafkaConnect
リソースにコピーします。 指定した場合は、同じ
spec.config
プロパティーを使用するようにしてください。-
group.id
-
offset.storage.topic
-
config.storage.topic
status.storage.topic
これらのプロパティーが指定されていない場合は、デフォルトが使用されます。この場合は、
KafkaConnect
リソース設定にも指定しません。
次に、
KafkaConnect
リソース固有の設定を新しいリソースに追加します。-
build
設定を追加して、Kafka Connect デプロイメントに追加するすべてのコネクターおよびその他のライブラリーを設定します。注記この代わりに、コネクターで新しいイメージを手動でビルドし、
.spec.image
プロパティーを使用して指定することもできます。古い
KafkaConnectS2I
リソースを削除します。oc delete -f MY-KAFKA-CONNECT-S2I-CONFIG-FILE
MY-KAFKA-CONNECT-S2I-CONFIG-FILE を、
KafkaConnectS2I
リソース設定が含まれるファイルの名前に置き換えます。代わりに、リソースの名前を指定できます。
oc delete kafkaconnects2i MY-KAFKA-CONNECT-S2I
MY-KAFKA-CONNECT-S2I を
KafkaConnectS2I
リソースの名前に置き換えます。S2I を使用する Kafka Connect のデプロイメントと Pod が削除されるまで待ちます。
警告他のリソースを削除する必要はありません。
新しい
KafkaConnect
リソースをデプロイします。oc apply -f MY-KAFKA-CONNECT-CONFIG-FILE
MY-KAFKA-CONNECT-CONFIG-FILE を、新しい
KafkaConnect
リソース設定が含まれるファイルの名前に置き換えます。新しいイメージのビルド、デプロイメントの作成、および Pod の起動が行われるまで待ちます。
Kafka Connect コネクターの管理に
KafkaConnector
リソースを使用している場合は、予想されるコネクターがすべて存在し、稼働していることを確認します。oc get kctr --selector strimzi.io/cluster=MY-KAFKA-CONNECT-CLUSTER -o name
MY-KAFKA-CONNECT-CLUSTER は、Kafka Connect クラスターの名前に置き換えます。
コネクターは Kafka Connect ストレージより自動的に復元されます。Kafka Connect REST API を使用してコネクターを管理している場合でも、手作業で再作成する必要はありません。
2.2.7. Kafka Connect クラスターリソースの一覧
以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。
- connect-cluster-name-connect
- Kafka Connect ワーカーノード Pod の作成を担当するデプロイメント。
- connect-cluster-name-connect-api
- Kafka Connect クラスターを管理するために REST インターフェースを公開するサービス。
- connect-cluster-name-config
- Kafka Connect 補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
- connect-cluster-name-connect
- Kafka Connect ワーカーノードに設定された Pod の Disruption Budget。
2.2.8. Kafka Connect (S2I) クラスターリソースの一覧
以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。
- connect-cluster-name-connect-source
- 新たにビルドされた Docker イメージのベースイメージとして使用される ImageStream。
- connect-cluster-name-connect
- あたらしい Kafka Connect Docker イメージのビルドを担当する BuildConfig。
- connect-cluster-name-connect
- 新たにビルドされた Docker イメージがプッシュされる ImageStream。
- connect-cluster-name-connect
- Kafka Connect ワーカーノード Pod の作成を担当する DeploymentConfig。
- connect-cluster-name-connect-api
- Kafka Connect クラスターを管理するために REST インターフェースを公開するサービス。
- connect-cluster-name-config
- Kafka Connect 補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
- connect-cluster-name-connect
- Kafka Connect ワーカーノードに設定された Pod の Disruption Budget。
2.2.9. 変更データキャプチャーのための Debezium との統合
Red Hat Debezium は分散型の変更データキャプチャー (change data capture) プラットフォームです。データベースの行レベルの変更をキャプチャーして、変更イベントレコードを作成し、Kafka トピックへレコードをストリーミングします。Debezium は Apache Kafka に構築されます。AMQ Streams で Debezium をデプロイおよび統合できます。AMQ Streams のデプロイ後に、Kafka Connect で Debezium をコネクター設定としてデプロイします。Debezium は変更イベントレコードを OpenShift 上の AMQ Streams に渡します。アプリケーションは 変更イベントストリーム を読み取りでき、変更イベントが発生した順にアクセスできます。
Debezium には、以下を含む複数の用途があります。
- データレプリケーション。
- キャッシュの更新およびインデックスの検索。
- モノリシックアプリケーションの簡素化。
- データ統合。
- ストリーミングクエリーの有効化。
データベースの変更をキャプチャーするには、Debezium データベースコネクターで Kafka Connect をデプロイします。KafkaConnector
リソースを設定し、コネクターインスタンスを定義します。
AMQ Streams で Debezium をデプロイするための詳細は、「製品ドキュメント」を参照してください。Debezium のドキュメントの 1 つ が『Getting Started with Debezium』で、このガイドはデータベース更新の変更イベントレコードの表示に必要なサービスおよびコネクターの設定方法を説明します。
2.3. Kafka MirrorMaker クラスターの設定
本章では、Kafka クラスター間でデータを複製するために AMQ Streams クラスターで Kafka MirrorMaker デプロイメントを設定する方法を説明します。
AMQ Streams では、MirrorMaker または MirrorMaker 2.0 を使用できます。MirrorMaker 2.0 は最新バージョンで、Kafka クラスター間でより効率的にデータをミラーリングする方法を提供します。
MirrorMaker を使用している場合は、KafkaMirrorMaker
リソースを設定します。
以下の手順は、リソースの設定方法を示しています。
KafkaMirrorMaker
リソースの完全なスキーマは、「KafkaMirrorMaker スキーマ参照」に記載されています。
2.3.1. Kafka MirrorMaker の設定
KafkaMirrorMaker
リソースのプロパティーを使用して、Kafka MirrorMaker デプロイメントを設定します。
TLS または SASL 認証を使用して、プロデューサーおよびコンシューマーのアクセス制御を設定できます。この手順では、コンシューマーおよびプロデューサー側で TLS による暗号化および認証を使用する設定を説明します。
前提条件
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
- ソースおよびターゲットの Kafka クラスターが使用できる必要があります。
手順
KafkaMirrorMaker
リソースのspec
プロパティーを編集します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker metadata: name: my-mirror-maker spec: replicas: 3 1 consumer: bootstrapServers: my-source-cluster-kafka-bootstrap:9092 2 groupId: "my-group" 3 numStreams: 2 4 offsetCommitInterval: 120000 5 tls: 6 trustedCertificates: - secretName: my-source-cluster-ca-cert certificate: ca.crt authentication: 7 type: tls certificateAndKey: secretName: my-source-secret certificate: public.crt key: private.key config: 8 max.poll.records: 100 receive.buffer.bytes: 32768 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 9 ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" ssl.endpoint.identification.algorithm: HTTPS 10 producer: bootstrapServers: my-target-cluster-kafka-bootstrap:9092 abortOnSendFailure: false 11 tls: trustedCertificates: - secretName: my-target-cluster-ca-cert certificate: ca.crt authentication: type: tls certificateAndKey: secretName: my-target-secret certificate: public.crt key: private.key config: compression.type: gzip batch.size: 8192 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 12 ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" ssl.endpoint.identification.algorithm: HTTPS 13 whitelist: "my-topic|other-topic" 14 resources: 15 requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 2Gi logging: 16 type: inline loggers: mirrormaker.root.logger: "INFO" readinessProbe: 17 initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 metricsConfig: 18 type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: my-config-map key: my-key jvmOptions: 19 "-Xmx": "1g" "-Xms": "1g" image: my-org/my-image:latest 20 template: 21 pod: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: application operator: In values: - postgresql - mongodb topologyKey: "kubernetes.io/hostname" connectContainer: 22 env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831" tracing: 23 type: jaeger
- 1
- 2
- コンシューマーおよびプロデューサーのブートストラップサーバー。
- 3
- 4
- 5
- 6
- コンシューマーまたはプロデューサーの TLS 証明書が X.509 形式で保存される、キー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
- 7
- OAuth ベアラートークン、SASL ベースの SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズム を使用する、コンシューマーおよびプロデューサーの認証。
- 8
- 9
- TLS バージョンの特定の 暗号スイート と実行される外部リスナーの SSL プロパティー。
- 10
HTTPS
に設定して ホスト名の検証を有効にします。空の文字列を指定すると検証が無効になります。- 11
abortOnSendFailure
プロパティー がtrue
に設定された場合、Kafka MirrorMaker が終了し、メッセージの送信失敗後にコンテナーが再起動します。- 12
- TLS バージョンの特定の 暗号スイート と実行される外部リスナーの SSL プロパティー。
- 13
HTTPS
に設定して ホスト名の検証を有効にします。空の文字列を指定すると検証が無効になります。- 14
- ソースからターゲット Kafka クラスターにミラーリングされたトピックの 許可リスト。
- 15
- 16
- ConfigMap より直接的 (
inline
) または間接的 (external
) に追加されたロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties
またはlog4j2.properties
キー下に配置する必要があります。MirrorMaker にはmirrormaker.root.logger
と呼ばれる単一のロガーがあります。ログレベルは INFO、ERROR、WARN、TRACE、DEBUG、FATAL、または OFF に設定できます。 - 17
- コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
- 18
- Prometheus メトリクス。この例では、Prometheus JMX エクスポーターの設定が含まれる ConfigMap を参照して有効になります。
metricsConfig.valueFrom.configMapKeyRef.key
下の空のファイルが含まれる ConfigMap への参照を使用すると、追加設定なしでメトリクスを有効にできます。 - 19
- Kafka MirrorMaker を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
- 20
- 高度な任意設定: 特別な場合のみ推奨されるコンテナーイメージの設定。
- 21
- テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
- 22
- 環境変数は、Jaeger を使用した分散トレーシングにも設定 されます。
- 23
警告abortOnSendFailure
プロパティーがfalse
に設定されると、プロデューサーはトピックの次のメッセージを送信しようとします。失敗したメッセージは再送されないため、元のメッセージが失われる可能性があります。リソースを作成または更新します。
oc apply -f <your-file>
2.3.2. Kafka MirrorMaker クラスターリソースの一覧
以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。
- <mirror-maker-name>-mirror-maker
- Kafka MirrorMaker Pod の作成を担当するデプロイメント。
- <mirror-maker-name>-config
- Kafka MirrorMaker の補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
- <mirror-maker-name>-mirror-maker
- Kafka MirrorMaker ワーカーノードに設定された Pod の Disruption Budget。
2.4. Kafka MirrorMaker 2.0 クラスターの設定
ここでは、AMQ Streams クラスターで Kafka MirrorMaker 2.0 デプロイメントを設定する方法を説明します。
MirrorMaker 2.0 は、データセンター内またはデータセンター全体の 2 台以上の Kafka クラスター間でデータを複製するために使用されます。
クラスター全体のデータレプリケーションでは、以下が必要な状況がサポートされます。
- システム障害時のデータの復旧
- 分析用のデータの集計
- 特定のクラスターへのデータアクセスの制限
- レイテンシーを改善するための特定場所でのデータのプロビジョニング
MirrorMaker 2.0 を使用している場合は、KafkaMirrorMaker2
リソースを設定します。
MirrorMaker 2.0 では、クラスターの間でデータを複製する全く新しい方法が導入されました。
その結果、リソースの設定は MirrorMaker の以前のバージョンとは異なります。MirrorMaker 2.0 の使用を選択した場合、現在、レガシーサポートがないため、リソースを手作業で新しい形式に変換する必要があります。
MirrorMaker 2.0 によってデータが複製される方法は、以下に説明されています。
以下の手順では、MirrorMaker 2.0 に対してリソースが設定される方法について取り上げます。
KafkaMirrorMaker2
リソースの完全なスキーマは、「KafkaMirrorMaker2 スキーマ参照」に記載されています。
2.4.1. MirrorMaker 2.0 のデータレプリケーション
MirrorMaker 2.0 はソースの Kafka クラスターからメッセージを消費して、ターゲットの Kafka クラスターに書き込みます。
MirrorMaker 2.0 は以下を使用します。
- ソースクラスターからデータを消費するソースクラスターの設定。
- データをターゲットクラスターに出力するターゲットクラスターの設定。
MirrorMaker 2.0 は Kafka Connect フレームワークをベースとし、コネクターによってクラスター間のデータ転送が管理されます。MirrorMaker 2.0 の MirrorSourceConnector
は、ソースクラスターからターゲットクラスターにトピックを複製します。
あるクラスターから別のクラスターにデータを ミラーリング するプロセスは非同期です。推奨されるパターンは、ソース Kafka クラスターとともにローカルでメッセージが作成され、ターゲットの Kafka クラスターの近くでリモートで消費されることです。
MirrorMaker 2.0 は、複数のソースクラスターで使用できます。
図2.1 2 つのクラスターにおけるレプリケーション

デフォルトでは、ソースクラスターの新規トピックのチェックは 10 分ごとに行われます。refresh.topics.interval.seconds
を KafkaMirrorMaker2
リソースのソースコネクター設定に追加することで、頻度を変更できます。ただし、操作の頻度が増えると、全体的なパフォーマンスに影響する可能性があります。
2.4.2. クラスターの設定
active/passive または active/active クラスター設定で MirrorMaker 2.0 を使用できます。
- active/active 設定では、両方のクラスターがアクティブで、同じデータを同時に提供します。これは、地理的に異なる場所で同じデータをローカルで利用可能にする場合に便利です。
- active/passive 設定では、アクティブなクラスターからのデータはパッシブなクラスターで複製され、たとえば、システム障害時のデータ復旧などでスタンバイ状態を維持します。
プロデューサーとコンシューマーがアクティブなクラスターのみに接続することを前提とします。
MirrorMaker 2.0 クラスターは、ターゲットの宛先ごとに必要です。
2.4.2.1. 双方向レプリケーション (active/active)
MirrorMaker 2.0 アーキテクチャーでは、active/active クラスター設定で双方向レプリケーションがサポートされます。
各クラスターは、 source および remote トピックの概念を使用して、別のクラスターのデータを複製します。同じトピックが各クラスターに保存されるため、リモートトピックの名前がソースクラスターを表すように自動的に MirrorMaker 2.0 によって変更されます。元のクラスターの名前の先頭には、トピックの名前が追加されます。
図2.2 トピックの名前変更

ソースクラスターにフラグを付けると、トピックはそのクラスターに複製されません。
remote トピックを介したレプリケーションの概念は、データの集約が必要なアーキテクチャーの設定に役立ちます。コンシューマーは、同じクラスター内でソースおよびリモートトピックにサブスクライブできます。これに個別の集約クラスターは必要ありません。
2.4.2.2. 一方向レプリケーション (active/passive)
MirrorMaker 2.0 アーキテクチャーでは、active/passive クラスター設定でー方向レプリケーションがサポートされます。
active/passiveのクラスター設定を使用してバックアップを作成したり、データを別のクラスターに移行したりできます。この場合、リモートトピックの名前を自動的に変更したくないことがあります。
IdentityReplicationPolicy
を KafkaMirrorMaker2
リソースのソースコネクター設定に追加することで、名前の自動変更をオーバーライドできます。この設定が適用されると、トピックには元の名前が保持されます。
2.4.2.3. トピック設定の同期
トピック設定は、ソースクラスターとターゲットクラスター間で自動的に同期化されます。設定プロパティーを同期化することで、リバランスの必要性が軽減されます。
2.4.2.4. データの整合性
MirrorMaker 2.0 は、ソーストピックを監視し、設定変更をリモートトピックに伝播して、不足しているパーティションを確認および作成します。MirrorMaker 2.0 のみがリモートトピックに書き込みできます。
2.4.2.5. オフセットの追跡
MirrorMaker 2.0 では、内部トピックを使用してコンシューマーグループのオフセットを追跡します。
- オフセット同期 トピックは、複製されたトピックパーティションのソースおよびターゲットオフセットをレコードメタデータからマッピングします。
- チェックポイント トピックは、各コンシューマーグループの複製されたトピックパーティションのソースおよびターゲットクラスターで最後にコミットされたオフセットをマッピングします。
チェックポイント トピックのオフセットは、設定によって事前定義された間隔で追跡されます。両方のトピックは、フェイルオーバー時に正しいオフセットの位置からレプリケーションの完全復元を可能にします。
MirrorMaker 2.0 は、MirrorCheckpointConnector
を使用して、オフセット追跡の チェックポイントを生成します。
2.4.2.6. コンシューマーグループオフセットの同期
__consumer_offsets
トピックには、各コンシューマーグループのコミットされたオフセットに関する情報が保存されます。オフセットの同期は、ソースクラスターのコンシューマーグループのコンシューマーオフセットをターゲットクラスターのコンシューマーオフセットに定期的に転送します。
オフセットの同期は、特に active/passive 設定で便利です。アクティブなクラスターがダウンした場合、コンシューマーアプリケーションはパッシブ (スタンバイ) クラスターに切り替え、最後に転送されたオフセットの位置からピックアップできます。
トピックオフセットの同期を使用するには、以下を行います。
-
sync.group.offsets.enabled
をKafkaMirrorMaker2
リソースのチェックポイントコネクター設定に追加し、プロパティーをtrue
に設定して同期を有効にします。同期はデフォルトで無効になっています。 -
IdentityReplicationPolicy
をソースおよびチェックポイントコネクター設定に追加し、ターゲットクラスターのトピックが元の名前を保持するようにします。
トピックオフセットの同期を機能させるため、ターゲットクラスターのコンシューマーグループは、ソースクラスターのグループと同じ ID を使用できません。
同期を有効にすると、ソースクラスターからオフセットの同期が定期的に行われます。sync.group.offsets.interval.seconds
および emit.checkpoints.interval.seconds
をチェックポイントコネクター設定に追加すると、頻度を変更できます。これらのプロパティーは、コンシューマーグループのオフセットが同期される頻度 (秒単位) と、オフセットを追跡するためにチェックポイントが生成される頻度を指定します。両方のプロパティーのデフォルトは 60 秒です。refresh.groups.interval.seconds
プロパティーを使用して、新規コンシューマーグループをチェックする頻度を変更することもできます。デフォルトでは 10 分ごとに実行されます。
同期は時間ベースであるため、コンシューマーによってパッシブクラスターへ切り替えられると、一部のメッセージが重複する可能性があります。
2.4.2.7. 接続性チェック
ハートビート 内部トピックによって、クラスター間の接続性が確認されます。
ハートビート トピックは、ソースクラスターから複製されます。
ターゲットクラスターは、トピックを使用して以下を確認します。
- クラスター間の接続を管理するコネクターが稼働している。
- ソースクラスターが利用可能である。
MirrorMaker 2.0 は MirrorHeartbeatConnector
を使用して、これらのチェックを実行する ハートビート を生成します。
2.4.3. ACL ルールの同期
User Operator を使用して いない 場合は、ACL でリモートトピックにアクセスできます。
User Operator なしで AclAuthorizer
が使用されている場合、ブローカーへのアクセスを管理する ACL ルールはリモートトピックにも適用されます。ソーストピックを読み取りできるユーザーは、そのリモートトピックを読み取りできます。
OAuth 2.0 での承認は、このようなリモートトピックへのアクセスをサポートしません。
2.4.4. MirrorMaker 2.0 を使用した Kafka クラスター間でのデータの同期
MirrorMaker 2.0 を使用して、設定を介して Kafka クラスター間のデータを同期します。
設定では以下を指定する必要があります。
- 各 Kafka クラスター
- TLS 認証を含む各クラスターの接続情報
レプリケーションのフローおよび方向
- クラスター対クラスター
- トピック対トピック
KafkaMirrorMaker2
リソースのプロパティーを使用して、Kafka MirrorMaker 2.0 デプロイメントを設定します。
従来のバージョンの MirrorMaker は継続してサポートされます。従来のバージョンに設定したリソースを使用する場合は、MirrorMaker 2.0 でサポートされる形式に更新する必要があります。
MirrorMaker 2.0 によって、レプリケーション係数などのプロパティーのデフォルト設定値が提供されます。デフォルトに変更がない最小設定の例は以下のようになります。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mirror-maker2 spec: version: 2.7.0 connectCluster: "my-cluster-target" clusters: - alias: "my-cluster-source" bootstrapServers: my-cluster-source-kafka-bootstrap:9092 - alias: "my-cluster-target" bootstrapServers: my-cluster-target-kafka-bootstrap:9092 mirrors: - sourceCluster: "my-cluster-source" targetCluster: "my-cluster-target" sourceConnector: {}
TLS または SASL 認証を使用して、ソースおよびターゲットクラスターのアクセス制御を設定できます。この手順では、ソースおよびターゲットクラスターに対して TLS による暗号化および認証を使用する設定を説明します。
前提条件
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
- ソースおよびターゲットの Kafka クラスターが使用できる必要があります。
手順
KafkaMirrorMaker2
リソースのspec
プロパティーを編集します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mirror-maker2 spec: version: 2.7.0 1 replicas: 3 2 connectCluster: "my-cluster-target" 3 clusters: 4 - alias: "my-cluster-source" 5 authentication: 6 certificateAndKey: certificate: source.crt key: source.key secretName: my-user-source type: tls bootstrapServers: my-cluster-source-kafka-bootstrap:9092 7 tls: 8 trustedCertificates: - certificate: ca.crt secretName: my-cluster-source-cluster-ca-cert - alias: "my-cluster-target" 9 authentication: 10 certificateAndKey: certificate: target.crt key: target.key secretName: my-user-target type: tls bootstrapServers: my-cluster-target-kafka-bootstrap:9092 11 config: 12 config.storage.replication.factor: 1 offset.storage.replication.factor: 1 status.storage.replication.factor: 1 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 13 ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" ssl.endpoint.identification.algorithm: HTTPS 14 tls: 15 trustedCertificates: - certificate: ca.crt secretName: my-cluster-target-cluster-ca-cert mirrors: 16 - sourceCluster: "my-cluster-source" 17 targetCluster: "my-cluster-target" 18 sourceConnector: 19 config: replication.factor: 1 20 offset-syncs.topic.replication.factor: 1 21 sync.topic.acls.enabled: "false" 22 refresh.topics.interval.seconds: 60 23 replication.policy.separator: "" 24 replication.policy.class: "io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy" 25 heartbeatConnector: 26 config: heartbeats.topic.replication.factor: 1 27 checkpointConnector: 28 config: checkpoints.topic.replication.factor: 1 29 refresh.groups.interval.seconds: 600 30 sync.group.offsets.enabled: true 31 sync.group.offsets.interval.seconds: 60 32 emit.checkpoints.interval.seconds: 60 33 replication.policy.class: "io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy" topicsPattern: ".*" 34 groupsPattern: "group1|group2|group3" 35 resources: 36 requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 2Gi logging: 37 type: inline loggers: connect.root.logger.level: "INFO" readinessProbe: 38 initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 jvmOptions: 39 "-Xmx": "1g" "-Xms": "1g" image: my-org/my-image:latest 40 template: 41 pod: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: application operator: In values: - postgresql - mongodb topologyKey: "kubernetes.io/hostname" connectContainer: 42 env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831" tracing: type: jaeger 43 externalConfiguration: 44 env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: aws-creds key: awsAccessKey - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: aws-creds key: awsSecretAccessKey
- 1
- 常に同じになる Kafka Connect と Mirror Maker 2.0 の バージョン。
- 2
- 3
- Kafka Connect の Kafka クラスターエイリアス。ターゲット Kafka クラスターを指定する必要があります。Kafka クラスターは、その内部トピックのために Kafka Connect によって使用されます。
- 4
- 同期される Kafka クラスターの 指定。
- 5
- ソースの Kafka クラスターの クラスターエイリアス。
- 6
- 7
- ソース Kafka クラスターに接続するための ブートストラップサーバー。
- 8
- ソース Kafka クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
- 9
- ターゲット Kafka クラスターの クラスターエイリアス。
- 10
- ターゲット Kafka クラスターの認証は、ソース Kafka クラスターと同様に設定されます。
- 11
- ターゲット Kafka クラスターに接続するための ブートストラップサーバー。
- 12
- Kafka Connect の設定。標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
- 13
- TLS バージョンの特定の 暗号スイート と実行される外部リスナーの SSL プロパティー。
- 14
HTTPS
に設定して ホスト名の検証を有効にします。空の文字列を指定すると検証が無効になります。- 15
- ターゲット Kafka クラスターの TLS による暗号化は、ソース Kafka クラスターと同様に設定されます。
- 16
- 17
- MirrorMaker 2.0 コネクターによって使用されるソースクラスターの クラスターエイリアス。
- 18
- MirrorMaker 2.0 コネクターによって使用されるターゲットクラスターの クラスターエイリアス。
- 19
- リモートトピックを作成する
MirrorSourceConnector
の設定。デフォルトの設定オプションはconfig
によって上書きされます。 - 20
- ターゲットクラスターで作成されるミラーリングされたトピックのレプリケーション係数。
- 21
- ソースおよびターゲットクラスターのオフセットをマップする
MirrorSourceConnector
offset-syncs
内部トピックのレプリケーション係数。 - 22
- ACL ルールの同期 が有効になっていると、同期されたトピックに ACL が適用されます。デフォルトは
true
です。 - 23
- 新規トピックのチェック頻度を変更する任意設定。デフォルトでは 10 分毎にチェックされます。
- 24
- リモートトピック名の変更に使用する区切り文字を定義します。
- 25
- リモートトピック名の自動変更をオーバーライドするポリシーを追加します。その名前の前にソースクラスターの名前を追加する代わりに、トピックが元の名前を保持します。このオプションの設定は、active/passive バックアップおよびデータ移行に役立ちます。トピックオフセットの同期を設定するには、このプロパティーも
checkpointConnector.config
に設定する必要があります。 - 26
- 接続性チェックを実行する
MirrorHeartbeatConnector
の設定。デフォルトの設定オプションはconfig
によって上書きされます。 - 27
- ターゲットクラスターで作成されたハートビートトピックのレプリケーション係数。
- 28
- オフセットを追跡する
MirrorCheckpointConnector
の設定。デフォルトの設定オプションはconfig
によって上書きされます。 - 29
- ターゲットクラスターで作成されたチェックポイントトピックのレプリケーション係数。
- 30
- 新規コンシューマーグループのチェック頻度を変更する任意設定。デフォルトでは 10 分毎にチェックされます。
- 31
- コンシューマーグループのオフセットを同期する任意設定。これは、active/passive 設定でのリカバリーに便利です。同期はデフォルトでは有効になっていません。
- 32
- コンシューマーグループオフセットの同期が有効な場合は、同期の頻度を調整できます。
- 33
- オフセット追跡のチェック頻度を調整します。オフセット同期の頻度を変更する場合、これらのチェックの頻度も調整する必要がある場合があります。
- 34
- 正規表現パターンとして定義されたソースクラスターからのトピックレプリケーション。ここで、すべてのトピックを要求します。
- 35
- 正規表現パターンとして定義されたソースクラスターからのコンシューマーグループレプリケーション。ここで、3 つのコンシューマーグループを名前で要求します。コンマ区切りリストを使用できます。
- 36
- 37
- ConfigMap にて直接的 (
inline
) または間接的 (external
) に追加される Kafka Connect のロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties
またはlog4j2.properties
キー下に配置する必要があります。Kafka Connectlog4j.rootLogger
ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。 - 38
- コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
- 39
- Kafka MirrorMaker を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
- 40
- 高度な任意設定: 特別な場合のみ推奨されるコンテナーイメージの設定。
- 41
- テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
- 42
- 環境変数は、Jaeger を使用した分散トレーシングにも設定 されます。
- 43
- 44
- 環境変数として Kafka MirrorMaker にマウントされた OpenShift Secret の外部設定。
リソースを作成または更新します。
oc apply -f MIRRORMAKER-CONFIGURATION-FILE
2.4.5. Kafka MirrorMaker 2.0 コネクターの再起動の実行
この手順では、OpenShift アノテーションを使用して Kafka MirrorMaker 2.0 コネクターの再起動を手動でトリガーする方法を説明します。
前提条件
- Cluster Operator が稼働している必要があります。
手順
再起動する Kafka MirrorMaker 2.0 コネクターを制御する
KafkaMirrorMaker2
カスタムリソースの名前を見つけます。oc get KafkaMirrorMaker2
KafkaMirrorMaker2
カスタムリソースから再起動される Kafka MirrorMaker 2.0 コネクターの名前を見つけます。oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
コネクターを再起動するには、OpenShift で
KafkaMirrorMaker2
リソースにアノテーションを付けます。以下の例では、my-source->my-target.MirrorSourceConnector
という名前のコネクターがoc annotate
によって再起動されます。oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector=my-source->my-target.MirrorSourceConnector"
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka MirrorMaker 2.0 コネクターは再起動されます。再起動リクエストが許可されると、アノテーションは
KafkaMirrorMaker2
カスタムリソースから削除されます。
その他のリソース
2.4.6. Kafka MirrorMaker 2.0 コネクタータスクの再起動の実行
この手順では、OpenShift アノテーションを使用して Kafka MirrorMaker 2.0 コネクタータスクの再起動を手動でトリガーする方法を説明します。
前提条件
- Cluster Operator が稼働している必要があります。
手順
再起動する Kafka MirrorMaker 2.0 コネクターを制御する
KafkaMirrorMaker2
カスタムリソースの名前を見つけます。oc get KafkaMirrorMaker2
KafkaMirrorMaker2
カスタムリソースから再起動される Kafka MirrorMaker 2.0 コネクターの名前と、タスクの ID を見つけます。タスク ID は 0 から始まる負の値ではない整数です。oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
コネクタータスクを再起動するには、OpenShift で
KafkaMirrorMaker2
リソースにアノテーションを付けます。以下の例では、my-source->my-target.MirrorSourceConnector
という名前のコネクターのタスク 0 がoc annotate
によって再起動されます。oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector-task=my-source->my-target.MirrorSourceConnector:0"
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。
アノテーションが調整プロセスで検出されれば、Kafka MirrorMaker 2.0 コネクタータスクは再起動されます。再起動タスクリクエストが許可されると、アノテーションは
KafkaMirrorMaker2
カスタムリソースから削除されます。
その他のリソース
2.5. Kafka Bridge クラスターの設定
ここでは、AMQ Streams クラスターで Kafka Bridge デプロイメントを設定する方法を説明します。
Kafka Bridge では、HTTP ベースのクライアントと Kafka クラスターを統合するための API が提供されます。
Kafka Bridge を使用している場合は、KafkaBridge
リソースを設定します。
KafkaBridge
リソースの完全なスキーマは 「KafkaBridge
スキーマ参照」 に記載されています。
2.5.1. Kafka Bridge の設定
Kafka Bridge を使用した Kafka クラスターへの HTTP ベースのリクエスト
KafkaBridge
リソースのプロパティーを使用して、Kafka Bridge デプロイメントを設定します。
クライアントのコンシューマーリクエストが異なる Kafka Bridge インスタンスによって処理された場合に発生する問題を防ぐには、アドレスベースのルーティングを利用して、要求が適切な Kafka Bridge インスタンスにルーティングされるようにする必要があります。また、独立した各 Kafka Bridge インスタンスにレプリカが必要です。Kafka Bridge インスタンスには、別のインスタンスと共有されない独自の状態があります。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
手順
KafkaBridge
リソースのspec
プロパティーを編集します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: replicas: 3 1 bootstrapServers: my-cluster-kafka-bootstrap:9092 2 tls: 3 trustedCertificates: - secretName: my-cluster-cluster-cert certificate: ca.crt - secretName: my-cluster-cluster-cert certificate: ca2.crt authentication: 4 type: tls certificateAndKey: secretName: my-secret certificate: public.crt key: private.key http: 5 port: 8080 cors: 6 allowedOrigins: "https://strimzi.io" allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH" consumer: 7 config: auto.offset.reset: earliest producer: 8 config: delivery.timeout.ms: 300000 resources: 9 requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 2Gi logging: 10 type: inline loggers: logger.bridge.level: "INFO" # enabling DEBUG just for send operation logger.send.name: "http.openapi.operation.send" logger.send.level: "DEBUG" jvmOptions: 11 "-Xmx": "1g" "-Xms": "1g" readinessProbe: 12 initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 image: my-org/my-image:latest 13 template: 14 pod: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: application operator: In values: - postgresql - mongodb topologyKey: "kubernetes.io/hostname" bridgeContainer: 15 env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831"
- 1
- 2
- ターゲット Kafka クラスターに接続するための ブートストラップサーバー。
- 3
- ソース Kafka クラスターの TLS 証明書が X.509 形式で保存されるキー名のある TLS による暗号化。複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
- 4
- OAuth ベアラートークン、SASL ベースの SCRAM-SHA-512 または PLAIN メカニズムを使用し、ここで示された TLS メカニズム を使用する、Kafka Bridge クラスターの認証。デフォルトでは、Kafka Bridge は認証なしで Kafka ブローカーに接続します。
- 5
- Kafka ブローカーへの HTTP アクセス。
- 6
- 選択されたリソースおよびアクセスメソッドを指定する CORS アクセス。リクエストの追加の HTTP ヘッダーには Kafka クラスターへのアクセスが許可されるオリジンが記述されています。
- 7
- コンシューマー設定 オプション。
- 8
- プロデューサー設定 オプション。
- 9
- 10
- ConfigMap にて直接的 (
inline
) または間接的 (external
) に追加される Kafka Bridge のロガーおよびログレベルを指定します。カスタム ConfigMap は、log4j.properties
またはlog4j2.properties
キー下に配置する必要があります。Kafka Bridge ロガーでは、ログレベルを INFO、ERROR、WARN、TRACE、DEBUG、FATAL または OFF に設定できます。 - 11
- Kafka Bridge を実行している仮想マシン (VM) のパフォーマンスを最適化するための JVM 設定オプション。
- 12
- コンテナーを再起動するタイミング (liveness) およびコンテナーがトラフィックを許可できるタイミング (readiness) を把握するためのヘルスチェック。
- 13
- 高度な任意設定: 特別な場合のみ推奨されるコンテナーイメージの設定。
- 14
- テンプレートのカスタマイズ。ここでは、Pod は非アフィニティーでスケジュールされるため、Pod は同じホスト名のノードではスケジュールされません。
- 15
- 環境変数は、Jaeger を使用した分散トレーシングにも設定 されます。
リソースを作成または更新します。
oc apply -f KAFKA-BRIDGE-CONFIG-FILE
2.5.2. Kafka Bridge クラスターリソースのリスト
以下のリソースは、OpenShift クラスターの Cluster Operator によって作成されます。
- bridge-cluster-name-bridge
- Kafka Bridge ワーカーノード Pod の作成を担当するデプロイメント。
- bridge-cluster-name-bridge-service
- Kafka Bridge クラスターの REST インターフェースを公開するサービス。
- bridge-cluster-name-bridge-config
- Kafka Bridge の補助設定が含まれ、Kafka ブローカー Pod によってボリュームとしてマウントされる ConfigMap。
- bridge-cluster-name-bridge
- Kafka Bridge ワーカーノードに設定された Pod の Disruption Budget。
2.6. OpenShift リソースのカスタマイズ
AMQ Streams では、AMQ Streams の operator によって管理される Deployments
、StatefulSets
、Pods
、および Services
などの複数の OpenShift リソースが作成されます。特定の OpenShift リソースの管理を担当する operator のみがそのリソースを変更できます。operator によって管理される OpenShift リソースを手動で変更しようとすると、operator はその変更を元に戻します。
しかし、operator が管理する OpenShift リソースの変更は、以下のような特定のタスクを実行する場合に役立ちます。
-
Pods
が Istio またはその他のサービスによって処理される方法を制御するカスタムラベルまたはアノテーションを追加する場合。 -
Loadbalancer
タイプのサービスがクラスターによって作成される方法を管理する場合。
このような変更は、AMQ Streams カスタムリソースの template
プロパティーを使用して追加します。template
プロパティーは以下のリソースでサポートされます。API リファレンスは、カスタマイズ可能フィールドに関する詳細を提供します。
Kafka.spec.kafka
-
「
KafkaClusterTemplate
スキーマ参照」 を参照 Kafka.spec.zookeeper
-
「
ZookeeperClusterTemplate
スキーマ参照」 を参照 Kafka.spec.entityOperator
-
「
EntityOperatorTemplate
スキーマ参照」 を参照 Kafka.spec.kafkaExporter
-
「
KafkaExporterTemplate
スキーマ参照」 を参照 Kafka.spec.cruiseControl
-
「
CruiseControlTemplate
スキーマ参照」 を参照 KafkaConnect.spec
-
「
KafkaConnectTemplate
スキーマ参照」 を参照 KafkaConnectS2I.spec
-
「
KafkaConnectTemplate
スキーマ参照」 を参照 KafkaMirrorMaker.spec
-
「
KafkaMirrorMakerTemplate
スキーマ参照」 を参照 KafkaMirrorMaker2.spec
-
「
KafkaConnectTemplate
スキーマ参照」 を参照 KafkaBridge.spec
-
「
KafkaBridgeTemplate
スキーマ参照」 を参照 KafkaUser.spec
-
「
KafkaUserTemplate
スキーマ参照」 を参照
以下の例では、template
プロパティーを使用して Kafka ブローカーの StatefulSet
のラベルを変更します。
テンプレートのカスタマイズ例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster labels: app: my-cluster spec: kafka: # ... template: statefulset: metadata: labels: mylabel: myvalue # ...
2.6.1. イメージプルポリシーのカスタマイズ
AMQ Streams では、Cluster Operator によってデプロイされたすべての Pod のコンテナーのイメージプルポリシーをカスタマイズできます。イメージプルポリシーは、Cluster Operator デプロイメントの環境変数 STRIMZI_IMAGE_PULL_POLICY
を使用して設定されます。STRIMZI_IMAGE_PULL_POLICY
環境変数に設定できる値は 3 つあります。
Always
- Pod が起動または再起動されるたびにコンテナーイメージがレジストリーからプルされます。
IfNotPresent
- 以前プルされたことのないコンテナーイメージのみがレジストリーからプルされます。
Never
- コンテナーイメージはレジストリーからプルされることはありません。
現在、イメージプルポリシーはすべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターに対してのみ 1 度にカスタマイズできます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。
その他のリソース
- Cluster Operator の設定に関する詳細は、「Cluster Operator の使用」 を参照してください。
- イメージプルポリシーに関する詳細は、「Disruptions」を参照してください。
2.7. Pod スケジューリングの設定
2 つのアプリケーションが同じ OpenShift ノードにスケジュールされた場合、両方のアプリケーションがディスク I/O のように同じリソースを使用し、パフォーマンスに影響する可能性があります。これにより、パフォーマンスが低下する可能性があります。ノードを他の重要なワークロードと共有しないように Kafka Pod をスケジュールする場合、適切なノードを使用したり、Kafka 専用のノードのセットを使用すると、このような問題を適切に回避できます。
2.7.1. アフィニティー、容認 (Toleration)、およびトポロジー分散制約の指定
アフィニティー、容認 (Toleration)、およびトポロジー分散制約を使用して、kafka リソースの Pod をノードにスケジュールします。アフィニティー、容認 (Toleration)、およびトポロジー分散制約は、以下のリソースの affinity
、tolerations
、および topologySpreadConstraint
プロパティーを使用して設定されます。
-
Kafka.spec.kafka.template.pod
-
Kafka.spec.zookeeper.template.pod
-
Kafka.spec.entityOperator.template.pod
-
KafkaConnect.spec.template.pod
-
KafkaConnectS2I.spec.template.pod
-
KafkaBridge.spec.template.pod
-
KafkaMirrorMaker.spec.template.pod
-
KafkaMirrorMaker2.spec.template.pod
affinity
、tolerations
、および topologySpreadConstraint
プロパティーの形式は、OpenShift の仕様に準拠します。アフィニティー設定には、さまざまなタイプのアフィニティーを含めることができます。
- Pod のアフィニティーおよび非アフィニティー
- ノードのアフィニティー
OpenShift 1.16 および 1.17 では、topologySpreadConstraint
のサポートはデフォルトで無効になっています。topologySpreadConstraint
を使用するには、Kubernetes API サーバーおよびスケジューラーで EvenPodsSpread
フィーチャーゲートを有効にする必要があります。
その他のリソース
2.7.1.1. Pod の非アフィニティーを使用して重要なアプリケーションがノードを共有しないようにする
Pod の非アフィニティーを使用して、重要なアプリケーションが同じディスクにスケジュールされないようにします。Kafka クラスターの実行時に、Pod の非アフィニティーを使用して、Kafka ブローカーがデータベースなどの他のワークロードとノードを共有しないようにすることが推奨されます。
2.7.1.2. ノードのアフィニティーを使用したワークロードの特定ノードへのスケジュール
OpenShift クラスターは、通常多くの異なるタイプのワーカーノードで構成されます。ワークロードが非常に大きい環境の CPU に対して最適化されたものもあれば、メモリー、ストレージ (高速のローカル SSD)、または ネットワークに対して最適化されたものもあります。異なるノードを使用すると、コストとパフォーマンスの両面で最適化しやすくなります。最適なパフォーマンスを実現するには、AMQ Streams コンポーネントのスケジューリングで適切なノードを使用できるようにすることが重要です。
OpenShift はノードのアフィニティーを使用してワークロードを特定のノードにスケジュールします。ノードのアフィニティーにより、Pod がスケジュールされるノードにスケジューリングの制約を作成できます。制約はラベルセレクターとして指定されます。beta.kubernetes.io/instance-type
などの組み込みノードラベルまたはカスタムラベルのいずれかを使用してラベルを指定すると、適切なノードを選択できます。
2.7.1.3. 専用ノードへのノードのアフィニティーと容認 (Toleration) の使用
テイントを使用して専用ノードを作成し、ノードのアフィニティーおよび容認 (Toleration) を設定して専用ノードに Kafka Pod をスケジュールします。
クラスター管理者は、選択した OpenShift ノードをテイントとしてマーク付けできます。テイントのあるノードは、通常のスケジューリングから除外され、通常の Pod はそれらのノードでの実行はスケジュールされません。ノードに設定されたテイントを許容できるサービスのみをスケジュールできます。このようなノードで実行されるその他のサービスは、ログコレクターやソフトウェア定義のネットワークなどのシステムサービスのみです。
専用のノードで Kafka とそのコンポーネントを実行する利点は多くあります。障害の原因になったり、Kafka に必要なリソースを消費するその他のアプリケーションが同じノードで実行されません。これにより、パフォーマンスと安定性が向上します。
2.7.2. Kafka コンポーネントでの Pod の非アフィニティーの設定
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
クラスターデプロイメントを指定するリソースの
affinity
プロパティーを編集します。ラベルを使用して、同じノードでスケジュールすべきでない Pod を指定します。topologyKey
をkubernetes.io/hostname
に設定し、選択した Pod が同じホスト名のノードでスケジュールされてはならないことを指定する必要があります。以下に例を示します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... template: pod: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: application operator: In values: - postgresql - mongodb topologyKey: "kubernetes.io/hostname" # ... zookeeper: # ...
リソースを作成または更新します。
oc apply
を使用してこれを行うことができます。oc apply -f KAFKA-CONFIG-FILE
2.7.3. Kafka コンポーネントでのノードのアフィニティーの設定
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
AMQ Streams コンポーネントをスケジュールする必要のあるノードにラベルを付けます。
oc label
を使用してこれを行うことができます。oc label node NAME-OF-NODE node-type=fast-network
または、既存のラベルによっては再利用が可能です。
クラスターデプロイメントを指定するリソースの
affinity
プロパティーを編集します。以下に例を示します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... template: pod: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-type operator: In values: - fast-network # ... zookeeper: # ...
リソースを作成または更新します。
oc apply
を使用してこれを行うことができます。oc apply -f KAFKA-CONFIG-FILE
2.7.4. 専用ノードの設定と Pod のスケジューリング
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
- 専用ノードとして使用するノードを選択します。
- これらのノードにスケジュールされているワークロードがないことを確認します。
選択したノードにテイントを設定します。
oc adm taint
を使用してこれを行うことができます。oc adm taint node NAME-OF-NODE dedicated=Kafka:NoSchedule
さらに、選択したノードにラベルも追加します。
oc label
を使用してこれを行うことができます。oc label node NAME-OF-NODE dedicated=Kafka
クラスターデプロイメントを指定するリソースの
affinity
およびtolerations
プロパティーを編集します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... template: pod: tolerations: - key: "dedicated" operator: "Equal" value: "Kafka" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: dedicated operator: In values: - Kafka # ... zookeeper: # ...
リソースを作成または更新します。
oc apply
を使用してこれを行うことができます。oc apply -f KAFKA-CONFIG-FILE
2.8. 外部ロギング
リソースのロギングレベルを設定する場合、リソース YAML の spec.logging
プロパティーで直接 インライン で指定できます。
spec: # ... logging: type: inline loggers: kafka.root.logger.level: "INFO"
または external ロギングを指定することもできます。
spec: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: keyInConfigMap
外部ロギングでは、ロギングプロパティーは ConfigMap に定義されます。ConfigMap の名前は spec.logging.valueFrom.configMapKeyRef.name
プロパティーで参照されます。spec.logging.valueFrom.configMapKeyRef.name
および spec.logging.valueFrom.configMapKeyRef.key
プロパティーは必須です。name
または key
が設定されていない場合、デフォルトのロギングが使用されます。
ConfigMap を使用する利点は、ロギングプロパティーが 1 カ所で維持され、複数のリソースにアクセスできることです。
2.8.1. ロギングの ConfigMap の作成
ConfigMap を使用してロギングプロパティーを定義するには、ConfigMap を作成してから、リソースの spec
にあるロギング定義の一部としてそれを参照します。
ConfigMap には適切なロギング設定が含まれる必要があります。
-
Kafka コンポーネント、ZooKeeper、および Kafka Bridge の
log4j.properties
。 -
Topic Operator および User Operator の
log4j2.properties
。
設定はこれらのプロパティーの配下に配置する必要があります。
ここでは、ConfigMap によって Kafka リソースのルートロガーが定義される方法を実証します。
手順
ConfigMap を作成します。
ConfigMap を YAML ファイルとして作成するか、コマンドラインで
oc
を使用してプロパティーファイルから Config Map を作成します。Kafka のルートロガー定義が含まれる ConfigMap の例:
kind: ConfigMap apiVersion: kafka.strimzi.io/v1beta2 metadata: name: logging-configmap data: log4j.properties: kafka.root.logger.level="INFO"
プロパティーファイルを使用してコマンドラインから作成します。
oc create configmap logging-configmap --from-file=log4j.properties
プロパティーファイルではロギング設定が定義されます。
# Define the logger kafka.root.logger.level="INFO" # ...
logging.valueFrom.configMapKeyRef.name
を ConfigMap の名前に設定し、logging.valueFrom.configMapKeyRef.key
をこの ConfigMap のキーに設定し、リソースのspec
で 外部 ロギングを定義します。spec: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: keyInConfigMap
リソースを作成または更新します。
oc apply -f kafka.yaml
第3章 外部リスナーの設定
外部リスナーを使用して AMQ Streams の Kafka クラスターを OpenShift 環境外のクライアントに公開します。
コネクション type
を指定して、外部リスナー設定で Kafka を公開します。
-
nodeport
はNodePort
タイプのServices
を使用します。 -
loadbalancer
はLoadbalancer
タイプのServices
を使用します。 -
ingress
は、KubernetesIngress
および NGINX Ingress Controller for Kubernetes を使用します。 -
route
は OpenShiftRoutes
および HAProxy ルーターを使用します。
リスナーの設定に関する詳細は、「GenericKafkaListener
スキーマ参照」を参照してください。
route
は OpenShift でのみサポートされます。
その他のリソース
3.1. ノードポートを使用した Kafka へのアクセス
この手順では、ノードポートを使用して外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法について説明します。
ブローカーに接続するには、Kafka bootstrap アドレスのホスト名とポート番号、および認証に使用される証明書が必要です。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
外部リスナーを
nodeport
タイプに設定してKafka
リソースを設定します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: external port: 9094 type: nodeport tls: true authentication: type: tls # ... # ... zookeeper: # ...
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
NodePort
タイプサービスは、各 Kafka ブローカーと、外部 ブートストラップサービス に対して作成されます。ブートストラップサービスは外部トラフィックを Kafka ブローカーにルーティングします。接続に使用されるノードアドレスは、Kafka カスタムリソースのstatus
に伝播されます。kafka ブローカーの ID を検証するためのクラスター CA 証明書も、
Kafka
リソースと同じ名前で作成されます。Kafka
リソースのステータスから Kafka クラスターにアクセスするために使用するブートストラップアドレスを取得します。oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
TLS による暗号化が有効な場合は、ブローカーの認証局の公開証明書を取得します。
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。
3.2. ロードバランサーを使用した Kafka へのアクセス
この手順では、ロードバランサーを使用して外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法について説明します。
ブローカーに接続するには、ブートストラップロードバランサーのアドレスと、TLS による暗号化に使用される証明書が必要です。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
外部リスナーを
loadbalancer
タイプに設定してKafka
リソースを設定します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: external port: 9094 type: loadbalancer tls: true # ... # ... zookeeper: # ...
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
loadbalancer
タイプサービスおよびロードバランサーは、各 Kafka ブローカーと、外部 ブートストラップサービス に対して作成されます。ブートストラップサービスは外部トラフィックをすべての Kafka ブローカーにルーティングします。接続に使用される DNS 名と IP アドレスは、各サービスのstatus
に伝播されます。kafka ブローカーの ID を検証するためのクラスター CA 証明書も、
Kafka
リソースと同じ名前で作成されます。Kafka
リソースのステータスから Kafka クラスターにアクセスするために使用するブートストラップサービスのアドレスを取得します。oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
TLS による暗号化が有効な場合は、ブローカーの認証局の公開証明書を取得します。
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。
3.3. ingress を使用した Kafka へのアクセス
このの手順では、Nginx Ingress を使用して OpenShift 外部の外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法を説明します。
ブローカーに接続するには、Ingress ブートストラップアドレス のホスト名 (アドバタイズされたアドレス) と、認証に使用される証明書が必要です。
Ingress を使用したアクセスでは、ポートは常に 443 になります。
TLS パススルー
Kafka は TCP 上でバイナリープロトコルを使用しますが、NGINX Ingress Controller for Kubernetes は HTTP プロトコルで動作するように設計されています。Ingress から Kafka コネクションを渡せるようにするため、AMQ Streams では NGINX Ingress Controller for Kubernetes の TLS パススルー機能が使用されます。TLS パススルーが NGINX Ingress Controller for Kubernetes デプロイメントで有効になっているようにしてください。
Ingress
を使用して Kafka を公開する場合、TLS パススルー機能を使用するため、TLS による暗号化を無効にできません。
TLS パススルーの有効化に関する詳細は、TLS パススルーのドキュメント を参照してください。
前提条件
- OpenShift クラスターが必要です。
- TLS パススルーが有効になっている、デプロイ済みの NGINX Ingress Controller for Kubernetes。
- 稼働中の Cluster Operator。
手順
外部リスナーを
ingress
タイプに設定してKafka
リソースを設定します。ブートストラップサービスおよび Kafka ブローカーの Ingress ホストを指定します。
以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: external port: 9094 type: ingress tls: true authentication: type: tls configuration: 1 bootstrap: host: bootstrap.myingress.com brokers: - broker: 0 host: broker-0.myingress.com - broker: 1 host: broker-1.myingress.com - broker: 2 host: broker-2.myingress.com # ... zookeeper: # ...
- 1
- ブートストラップサービスおよび Kafka ブローカーの Ingress ホスト。
リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
ClusterIP
タイプサービスは、各 Kafka ブローカーと、追加の ブートストラップサービス に対して作成されます。これらのサービスは、トラフィックを Kafka ブローカーにルーティングするために Ingress コントローラーによって使用されます。また、各サービスにIngress
リソースが作成され、Ingress コントローラーを使用してそれらのリソースが公開されます。Ingress ホストは各サービスのstatus
に伝播されます。kafka ブローカーの ID を検証するためのクラスター CA 証明書も、
Kafka
リソースと同じ名前で作成されます。configuration
で指定したブートストラップホストのアドレスと、Kafka クライアントのポート 443 (BOOTSTRAP-HOST:443) を、Kafka クラスターに接続する ブートストラップアドレス として使用します。ブローカーの認証局の公開証明書を取得します。
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。
3.4. OpenShift ルートを使用した Kafka へのアクセス
この手順では、ルートを使用して OpenShift 外部の外部クライアントから AMQ Streams Kafka クラスターにアクセスする方法について説明します。
ブローカーに接続するには、ルートブートストラップアドレス のホスト名と、TLS による暗号化に使用される証明書が必要です。
ルートを使用したアクセスでは、ポートは常に 443 になります。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
外部リスナーを
route
タイプに設定してKafka
リソースを設定します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: labels: app: my-cluster name: my-cluster namespace: myproject spec: kafka: # ... listeners: - name: listener1 port: 9094 type: route tls: true # ... # ... zookeeper: # ...
警告OpenShift Route アドレスは、Kafka クラスターの名前、リスナーの名前、および作成される namespace の名前で構成されます。たとえば、
my-cluster-kafka-listener1-bootstrap-myproject
(CLUSTER-NAME-kafka-LISTENER-NAME-bootstrap-NAMESPACE) となります。アドレスの全体の長さが上限の 63 文字を超えないように注意してください。リソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
ClusterIP
タイプサービスは、各 Kafka ブローカーと、外部 ブートストラップサービス に対して作成されます。サービスは、トラフィックを OpenShift ルートから Kafka ブローカーにルーティングします。また、各サービスに OpenShiftRoute
リソースも作成され、HAProxy ロードバランサーを使用してそれらのリソースが公開されます。接続に使用される DNS アドレスは、各サービスのstatus
に伝播されます。kafka ブローカーの ID を検証するためのクラスター CA 証明書も、
Kafka
リソースと同じ名前で作成されます。Kafka
リソースのステータスから Kafka クラスターにアクセスするために使用するブートストラップサービスのアドレスを取得します。oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
ブローカーの認証局の公開証明書を取得します。
oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
Kafka クライアントで取得した証明書を使用して TLS 接続を設定します。認証が有効になっている場合は、SASL または TLS 認証を設定する必要もあります。
第4章 Kafka へのセキュアなアクセスの管理
各クライアントの Kafka ブローカーへのアクセスを管理することで、Kafka クラスターを保護できます。
Kafka ブローカーとクライアント間のセキュアな接続には、以下が含まれます。
- データ交換の暗号化
- アイデンティティー証明に使用する認証
- ユーザーが実行するアクションを許可または拒否する承認
本章では、以下を取り上げ、Kafka ブローカーとクライアント間でセキュアな接続を設定する方法を説明します。
- Kafka クラスターおよびクライアントのセキュリティーオプション
- Kafka ブローカーをセキュアにする方法
- OAuth 2.0 トークンベースの認証および承認に承認サーバーを使用する方法
4.1. Kafka のセキュリティーオプション
Kafka
リソースを使用して、Kafka の認証および承認に使用されるメカニズムを設定します。
4.1.1. リスナー認証
OpenShift クラスター内のクライアントの場合は、plain
(暗号化なし) または tls
内部 リスナーを作成できます。
OpenShift クラスター外のクライアントの場合は、外部 リスナーを作成して接続メカニズムを指定します。接続メカニズムは nodeport
、loadbalancer
、ingress
、または route
(OpenShift の場合) のいずれかです。
外部クライアントを接続するための設定オプションの詳細は、「外部リスナーの設定」を参照してください。
サポートされる認証オプションは次のとおりです。
- 相互 TLS 認証 (TLS による暗号化が有効なリスナーのみ)
- SCRAM-SHA-512 認証
- OAuth 2.0 のトークンベースの認証
選択する認証オプションは、Kafka ブローカーへのクライアントアクセスを認証する方法によって異なります。
図4.1 Kafka リスナーの認証オプション

リスナーの authentication
プロパティーは、そのリスナーに固有の認証メカニズムを指定するために使用されます。
authentication
プロパティーが指定されていない場合、リスナーはそのリスナー経由で接続するクライアントを認証しません。認証がないと、リスナーではすべての接続が許可されます。
認証は、User Operator を使用して KafkaUsers
を管理する場合に設定する必要があります。
以下の例で指定されるものは次のとおりです。
-
SCRAM-SHA-512 認証に設定された
plain
リスナー -
相互 TLS 認証を使用する
tls
リスナー -
相互 TLS 認証を使用する
external
リスナー
各リスナーは、Kafka クラスター内で一意の名前およびポートで設定されます。
ブローカー間通信 (9091) およびメトリクス (9404) 用に確保されたポートを使用するようにリスナーを設定することはできません。
リスナー認証設定の例
# ... listeners: - name: plain port: 9092 type: internal tls: true authentication: type: scram-sha-512 - name: tls port: 9093 type: internal tls: true authentication: type: tls - name: external port: 9094 type: loadbalancer tls: true authentication: type: tls # ...
4.1.1.1. 相互 TLS 認証
相互 TLS 認証は、Kafka ブローカーと ZooKeeper Pod 間の通信で常に使用されます。
AMQ Streams では、Kafka が TLS (Transport Layer Security) を使用して、相互認証の有無を問わず、Kafka ブローカーとクライアントとの間で暗号化された通信が行われるよう設定できます。相互 (双方向) 認証の場合、サーバーとクライアントの両方が証明書を提示します。相互認証を設定すると、ブローカーはクライアントを認証し (クライアント認証)、クライアントはブローカーを認証します (サーバー認証)。
TLS 認証は一般的には一方向で、一方が他方のアイデンティティーを認証します。たとえば、Web ブラウザーと Web サーバーの間で HTTPS が使用される場合、ブラウザーは Web サーバーのアイデンティティーの証明を取得します。
4.1.1.2. SCRAM-SHA-512 認証
SCRAM (Salted Challenge Response Authentication Mechanism) は、パスワードを使用して相互認証を確立できる認証プロトコルです。AMQ Streams では、Kafka が SASL (Simple Authentication and Security Layer) SCRAM-SHA-512 を使用するよう設定し、暗号化されていないクライアントの接続と暗号化されたクライアントの接続の両方で認証を提供できます。
TLS クライアント接続で SCRAM-SHA-512 認証が使用される場合、TLS プロトコルは暗号化を提供しますが、認証には使用されません。
SCRAM の以下のプロパティーは、暗号化されていない接続でも SCRAM-SHA-512 を安全に使用できるようにします。
- 通信チャネル上では、パスワードはクリアテキストで送信されません。代わりに、クライアントとサーバーはお互いにチャレンジを生成し、認証するユーザーのパスワードを認識していることを証明します。
- サーバーとクライアントは、認証を交換するたびに新しいチャレンジを生成します。よって、この交換はリレー攻撃に対する回復性を備えています。
KafkaUser.spec.authentication.type
を scram-sha-512
に設定すると、User Operator によって、大文字と小文字の ASCII 文字と数字で構成された無作為の 12 文字のパスワードが生成されます。
4.1.1.3. ネットワークポリシー
AMQ Streams では、Kafka ブローカーで有効になっているリスナーごとに NetworkPolicy
リソースが自動的に作成されます。デフォルトでは、すべてのアプリケーションと namespace にアクセスする権限が NetworkPolicy
によってリスナーに付与されます。
ネットワークレベルでのリスナーへのアクセスを指定のアプリケーションまたは namespace のみに制限するには、networkPolicyPeers
プロパティーを使用します。
リスナーの認証設定の一部としてネットワークポリシーを使用します。リスナーごとに、異なる networkPolicyPeers
設定を指定できます。
詳細は、「リスナーネットワークポリシー」のセクションおよび 「NetworkPolicyPeer API reference」を参照してください。
AMQ Streams でネットワークポリシーを使用するには、ingress NetworkPolicies
が OpenShift の設定でサポートされる必要があります。
4.1.1.4. 追加のリスナー設定オプション
GenericKafkaListenerConfiguration スキーマのプロパティーを使用して、設定をリスナーに追加できます。
4.1.2. Kafka の承認
Kafka.spec.kafka
リソースの authorization
プロパティーを使用して Kafka ブローカーの承認を設定できます。authorization
プロパティーがないと、承認が有効にならず、クライアントの制限はありません。承認を有効にすると、承認は有効なすべてのリスナーに適用されます。承認方法は type
フィールドで定義されます。
サポートされる承認オプションは次のとおりです。
- 簡易承認
- OAuth 2.0 での承認 (OAuth 2.0 トークンベースの認証を使用している場合)
- Open Policy Agent (OPA) での承認
図4.2 Kafka クラスター承認オプション

4.1.2.1. スーパーユーザー
スーパーユーザーは、アクセスの制限に関係なく Kafka クラスターのすべてのリソースにアクセスでき、すべての承認メカニズムでサポートされます。
Kafka クラスターのスーパーユーザーを指定するには、superUsers
プロパティーにユーザープリンシパルのリストを追加します。ユーザーが TLS クライアント認証を使用する場合、ユーザー名は CN=
で始まる証明書のサブジェクトの共通名になります。
スーパーユーザーを使用した設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... authorization: type: simple superUsers: - CN=client_1 - user_2 - CN=client_3 # ...
4.2. Kafka クライアントのセキュリティーオプション
KafkaUser
リソースを使用して、Kafka クライアントの認証メカニズム、承認メカニズム、およびアクセス権限を設定します。セキュリティーの設定では、クライアントはユーザーとして表されます。
Kafka ブローカーへのユーザーアクセスを認証および承認できます。認証によってアクセスが許可され、承認によって許容されるアクションへのアクセスが制限されます。
Kafka ブローカーへのアクセスが制限されない スーパーユーザー を作成することもできます。
認証および承認メカニズムは、Kafka ブローカーへのアクセスに使用されるリスナーの仕様 と一致する必要があります。
4.2.1. ユーザー処理用の Kafka クラスターの特定
KafkaUser
リソースには、このリソースが属する Kafka クラスターに適した名前 (Kafka
リソースの名前から派生) を定義するラベルが含まれています。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster
このラベルは、KafkaUser
リソースを特定し、新しいユーザーを作成するために、User Operator によって使用されます。また、以降のユーザーの処理でも使用されます。
ラベルが Kafka クラスターと一致しない場合、User Operator は KafkaUser
を識別できず、ユーザーは作成されません。
KafkaUser
リソースのステータスが空のままであれば、ラベルを確認してください。
4.2.2. ユーザー認証
ユーザー認証は、KafkaUser.spec
の authentication
プロパティーを使用して設定されます。ユーザーに有効な認証メカニズムは、type
フィールドを使用して指定されます。
サポートされる認証メカニズム
- TLS クライアント認証
- SCRAM-SHA-512 認証
認証メカニズムを指定しないと、User Operator によってユーザーまたはそのクレデンシャルが作成されません。
4.2.2.1. TLS クライアント認証
TLS クライアント認証を使用するには、type
フィールドを tls
に設定します。
TLS クライアント認証が有効になっている KafkaUser
の例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: tls # ...
ユーザーが User Operator によって作成されると、KafkaUser
リソースと同じ名前で新しいシークレットが作成されます。Secret には、TLS クライアント認証の秘密鍵と公開鍵が含まれます。公開鍵は、クライアント認証局 (CA) によって署名されたユーザー証明書に含まれます。
すべての鍵は X.509 形式です。
Secret には、PEM 形式および PKCS #12 形式の秘密鍵と証明書が含まれます。
Kafka と Secret との通信をセキュアにする方法については、11章TLS 証明書の管理 を参照してください。
ユーザークレデンシャルのある Secret
の例
apiVersion: v1 kind: Secret metadata: name: my-user labels: strimzi.io/kind: KafkaUser strimzi.io/cluster: my-cluster type: Opaque data: ca.crt: # Public key of the client CA user.crt: # User certificate that contains the public key of the user user.key: # Private key of the user user.p12: # PKCS #12 archive file for storing certificates and keys user.password: # Password for protecting the PKCS #12 archive file
4.2.2.2. SCRAM-SHA-512 認証
SCRAM-SHA-512 認証メカニズムを使用するには、type
フィールドを scram-sha-512
に設定します。
SCRAM-SHA-512 認証が有効になっている KafkaUser
の例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: scram-sha-512 # ...
ユーザーが User Operator によって作成されると、KafkaUser
リソースと同じ名前で新しいシークレットが作成されます。シークレットの password
キーには、生成されたパスワードが含まれ、base64 でエンコードされます。パスワードを使用するにはデコードする必要があります。
ユーザークレデンシャルのある Secret
の例
apiVersion: v1 kind: Secret metadata: name: my-user labels: strimzi.io/kind: KafkaUser strimzi.io/cluster: my-cluster type: Opaque data: password: Z2VuZXJhdGVkcGFzc3dvcmQ= 1 sasl.jaas.config: b3JnLmFwYWNoZS5rYWZrYS5jb21tb24uc2VjdXJpdHkuc2NyYW0uU2NyYW1Mb2dpbk1vZHVsZSByZXF1aXJlZCB1c2VybmFtZT0ibXktdXNlciIgcGFzc3dvcmQ9ImdlbmVyYXRlZHBhc3N3b3JkIjsK 2
生成されたパスワードをデコードします。
echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
4.2.3. ユーザーの承認
ユーザーの承認は、KafkaUser.spec
の authorization
プロパティーを使用して設定されます。ユーザーに有効な承認タイプは、type
フィールドを使用して指定します。
簡易承認を使用するには、KafkaUser.spec.authorization
で type
プロパティーを simple
に設定します。簡易承認では、デフォルトの Kafka 承認プラグインである AclAuthorizer
が使用されます。
代わりに、OPA 承認 を使用することもできます。OAuth 2.0 トークンベースの認証をすでに使用している場合は、OAuth 2.0 承認 を使用することもできます。
承認が指定されていない場合は、User Operator によるユーザーのアクセス権限のプロビジョニングは行われません。KafkaUser
がリソースにアクセスできるかどうかは、使用されているオーソライザーによって異なります。たとえば、AclAuthorizer
の場合は、allow.everyone.if.no.acl.found
設定によって決定されます。
4.2.3.1. ACL ルール
AclAuthorizer
は、ACL ルールを使用して Kafka ブローカーへのアクセスを管理します。
ACL ルールによって、acls
プロパティーで指定したユーザーにアクセス権限が付与されます。
AclRule
オブジェクトの詳細は、「AclRule
スキーマ参照」を参照してください。
4.2.3.2. Kafka ブローカーへのスーパーユーザーアクセス
ユーザーを Kafka ブローカー設定のスーパーユーザーのリストに追加すると、KafkaUser
の ACL で定義された承認制約に関係なく、そのユーザーにはクラスターへのアクセスが無制限に許可されます。
ブローカーへのスーパーユーザーアクセスの設定に関する詳細は「Kafka の承認」を参照してください。
4.2.3.3. ユーザークォータ
KafkaUser
リソースの spec
を設定してクォータを強制し、バイトしきい値または CPU 使用の時間制限に基づいてユーザーが Kafka ブローカーへのアクセスを超過しないようにすることができます。
ユーザークォータをともなう KafkaUser
の例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: # ... quotas: producerByteRate: 1048576 1 consumerByteRate: 2097152 2 requestPercentage: 55 3
これらのプロパティーの詳細は、「KafkaUserQuotas
スキーマ参照」を参照してください。
4.3. Kafka ブローカーへのアクセスのセキュア化
Kafka ブローカーへのセキュアなアクセスを確立するには、以下を設定し、適用します。
Kafka
リソースが以下を行うようにします。- 指定された認証タイプでリスナーを作成します。
- Kafka クラスター全体の承認を設定します。
-
リスナーを使用して Kafka ブローカーにセキュアにアクセスするための
KafkaUser
リソース。
Kafka
リソースで以下を設定します。
- リスナー認証
- Kafka リスナーへのアクセスを制限するネットワークポリシー
- Kafka の承認
- ブローカーへのアクセスが制限されないスーパーユーザー
認証は、リスナーごとに独立して設定されます。承認は、常に Kafka クラスター全体に対して設定されます。
Cluster Operator はリスナーを作成し、クラスターおよびクライアント認証局 (CA) 証明書を設定して Kafka クラスター内で認証を有効にします。
独自の証明書をインストールして、Cluster Operator によって生成された証明書を置き換えることができます。外部認証局によって管理される Kafka リスナー証明書を使用するようにリスナーを設定することもできます。PKCS #12 形式 (.p12) および PEM 形式 (.crt) の証明書を利用できます。
KafkaUser
を使用して、Kafka にアクセスするために特定のクライアントが使用する認証および承認メカニズムを有効にします。
KafkaUser
リソースで以下を設定します。
- 有効なリスナー認証と一致する認証
- 有効な Kafka 承認と一致する承認
- クライアントによるリソースの使用を制御するクォータ
User Operator はクライアントに対応するユーザーを作成すると共に、選択した認証タイプに基づいて、クライアント認証に使用されるセキュリティークレデンシャルを作成します。
その他のリソース
スキーマの詳細は、以下を参照してください。
-
Kafka
の場合は「Kafka
スキーマ参照」 -
KafkaUser
の場合は「KafkaUser
スキーマ参照」
4.3.1. Kafka ブローカーのセキュア化
この手順では、AMQ Streams の実行時に Kafka ブローカーをセキュアにするためのステップを説明します。
Kafka ブローカーに実装されたセキュリティーは、アクセスを必要とするクライアントに実装されたセキュリティーとの互換性を維持する必要があります。
-
Kafka.spec.kafka.listeners[*].authentication
はKafkaUser.spec.authentication
と一致します。 -
Kafka.spec.kafka.authorization
はKafkaUser.spec.authorization
と一致します。
この手順では、TLS 認証を使用した簡易承認とリスナーの設定を説明します。リスナーの設定に関する詳細は、「GenericKafkaListener
スキーマ参照」を参照してください。
代わりに、リスナー認証 には SCRAM-SHA または OAuth 2.0、Kafka 承認 には OAuth 2.0 または OPA を使用することができます。
手順
Kafka
リソースを設定します。-
承認には
authorization
プロパティーを設定します。 listeners
プロパティーを設定し、認証のあるリスナーを作成します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... authorization: 1 type: simple superUsers: 2 - CN=client_1 - user_2 - CN=client_3 listeners: - name: tls port: 9093 type: internal tls: true authentication: type: tls 3 # ... zookeeper: # ...
- 1
- 2
- Kafka へのアクセスを制限されないユーザープリンシパルのリスト。CN は、TLS による認証が使用される場合のクライアント証明書の共通名です。
- 3
- リスナーの認証メカニズムは各リスナーに対して設定でき、相互 TLS、SCRAM-SHA-512、またはトークンベース OAuth 2.0 として指定 できます。
外部リスナーを設定している場合、設定は選択した接続のメカニズムによって異なります。
-
承認には
Kafka
リソースを作成または更新します。oc apply -f KAFKA-CONFIG-FILE
Kafka クラスターは、TLS 認証を使用する Kafka ブローカーリスナーと共に設定されます。
Kafka ブローカー Pod ごとにサービスが作成されます。
サービスが作成され、Kafka クラスターに接続するための ブートストラップアドレス として機能します。
kafka ブローカーの ID を検証するためのクラスター CA 証明書も、
Kafka
リソースと同じ名前で作成されます。
4.3.2. Kafka へのユーザーアクセスのセキュア化
KafkaUser
リソースのプロパティーを使用して Kafka ユーザーを設定します。
oc apply
を使用すると、ユーザーを作成または編集できます。oc delete
を使用すると、既存のユーザーを削除できます。
以下に例を示します。
-
oc apply -f USER-CONFIG-FILE
-
oc delete KafkaUser USER-NAME
KafkaUser
認証および承認メカニズムを設定する場合、必ず同等の Kafka
設定と一致するようにしてください。
-
KafkaUser.spec.authentication
はKafka.spec.kafka.listeners[*].authentication
と一致 -
KafkaUser.spec.authorization
はKafka.spec.kafka.authorization
と一致
この手順では、TLS 認証でユーザーを作成する方法を説明します。SCRAM-SHA 認証でユーザーを作成することも可能です。
必要な認証は、Kafka ブローカーリスナーに設定された認証のタイプ によって異なります。
Kafka ユーザーと Kafka ブローカー間の認証は、それぞれの認証設定によって異なります。たとえば、TLS が Kafka 設定で有効になっていない場合は、TLS でユーザーを認証できません。
前提条件
- TLS による認証および暗号化を使用して Kafka ブローカーリスナーで設定された 稼働中の Kafka クラスターが必要です。
- 稼働中の User Operator (通常は Entity Operator でデプロイされる) が必要です。
KafkaUser
の認証タイプは、Kafka
ブローカーで設定された認証と一致する必要があります。
手順
KafkaUser
リソースを設定します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: 1 type: tls authorization: type: simple 2 acls: - resource: type: topic name: my-topic patternType: literal operation: Read - resource: type: topic name: my-topic patternType: literal operation: Describe - resource: type: group name: my-group patternType: literal operation: Read
KafkaUser
リソースを作成または更新します。oc apply -f USER-CONFIG-FILE
KafkaUser
リソースと同じ名前の Secret と共に、ユーザーが作成されます。Secret には、TLS クライアント認証の秘密鍵と公開鍵が含まれます。
Kafka ブローカーへの接続をセキュアにするために Kafka クライアントをプロパティーで設定する詳細は『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「OpenShift 外クライアントのアクセスの設定」を参照してください。
4.3.3. ネットワークポリシーを使用した Kafka リスナーへのアクセス制限
networkPolicyPeers
プロパティーを使用すると、リスナーへのアクセスを指定のアプリケーションのみに制限できます。
前提条件
- Ingress NetworkPolicies をサポートする OpenShift クラスター。
- Cluster Operator が稼働している必要があります。
手順
-
Kafka
リソースを開きます。 networkPolicyPeers
プロパティーで、Kafka クラスターへのアクセスが許可されるアプリケーション Pod または namespace を定義します。以下は、ラベル
app
がkafka-client
に設定されているアプリケーションからの接続のみを許可するようtls
リスナーを設定する例になります。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: tls port: 9093 type: internal tls: true authentication: type: tls networkPolicyPeers: - podSelector: matchLabels: app: kafka-client # ... zookeeper: # ...
リソースを作成または更新します。
oc apply
を使用します。oc apply -f your-file
その他のリソース
-
スキーマの詳細は、「NetworkPolicyPeer API reference」および「
GenericKafkaListener
スキーマ参照」を参照してください。
4.4. OAuth 2.0 トークンベース認証の使用
AMQ Streams は、OAUTHBEARER および PLAIN メカニズムを使用して OAuth 2.0 認証の使用をサポートします。
OAuth 2.0 は、アプリケーション間で標準的なトークンベースの認証および承認を有効にし、中央の承認サーバーを使用してリソースに制限されたアクセス権限を付与するトークンを発行します。
Kafka ブローカーおよびクライアントの両方が OAuth 2.0 を使用するように設定する必要があります。OAuth 2.0 認証を設定した後に OAuth 2.0 承認 を設定できます。
OAuth 2.0 認証は、Kafka 承認 と併用できます。
OAuth 2.0 認証を使用すると、アプリケーションクライアントはアカウントのクレデンシャルを公開せずにアプリケーションサーバー (リソースサーバー と呼ばれる) のリソースにアクセスできます。
アプリケーションクライアントは、アクセストークンを認証の手段として渡します。アプリケーションサーバーはこれを使用して、付与するアクセス権限のレベルを決定することもできます。承認サーバーは、アクセスの付与とアクセスに関する問い合わせを処理します。
AMQ Streams のコンテキストでは以下が行われます。
- Kafka ブローカーは OAuth 2.0 リソースサーバーとして動作します。
- Kafka クライアントは OAuth 2.0 アプリケーションクライアントとして動作します。
Kafka クライアントは Kafka ブローカーに対して認証を行います。ブローカーおよびクライアントは、必要に応じて OAuth 2.0 承認サーバーと通信し、アクセストークンを取得または検証します。
AMQ Streams のデプロイメントでは、OAuth 2.0 インテグレーションは以下を提供します。
- Kafka ブローカーのサーバー側 OAuth 2.0 サポート。
- Kafka MirrorMaker、Kafka Connect、および Kafka Bridge のクライアント側 OAuth 2.0 サポート。
その他のリソース
4.4.1. OAuth 2.0 認証メカニズム
AMQ Streams は、OAuth 2.0 認証で OAUTHBEARER および PLAIN メカニズムをサポートします。どちらのメカニズムも、Kafka クライアントが Kafka ブローカーで認証されたセッションを確立できるようにします。クライアント、承認サーバー、および Kafka ブローカー間の認証フローは、メカニズムごとに異なります。
可能な限り、OAUTHBEARER を使用するようにクライアントを設定することが推奨されます。OAUTHBEARER では、クライアントクレデンシャルは Kafka ブローカーと共有されることがないため、PLAIN よりも高レベルのセキュリティーが提供されます。OAUTHBEARER をサポートしない Kafka クライアントの場合のみ、PLAIN の使用を検討してください。
必要であれば、同じ oauth
リスナーで OAUTHBEARER と PLAIN を両方有効にすることができます。
OAUTHBEARER の概要
Kafka は OAUTHBEARER 認証メカニズムをサポートしますが、明示的に設定する必要があります。また、多くの Kafka クライアントツールでは、プロトコルレベルで OAUTHBEARER の基本サポートを提供するライブラリーを使用します。
AMQ Streams では、アプリケーションの開発を容易にするため、アップストリームの Kafka Client Java ライブラリー用の OAuth コールバックハンドラーが提供されます (ただし、他のライブラリーには提供されません)。そのため、このようなクライアントには独自のコールバックハンドラーを作成する必要はありません。アプリケーションクライアントはコールバックハンドラーを使用してアクセストークンを提供できます。Go などの他言語で書かれたクライアントは、カスタムコードを使用して承認サーバーに接続し、アクセストークンを取得する必要があります。
OAUTHBEARER を使用する場合、クライアントはクレデンシャルを交換するために Kafka ブローカーでセッションを開始します。ここで、クレデンシャルはコールバックハンドラーによって提供されるベアラートークンの形式を取ります。コールバックを使用して、以下の 3 つの方法のいずれかでトークンの提供を設定できます。
- クライアント ID および Secret (OAuth 2.0 クライアントクレデンシャルメカニズムを使用)
- 設定時に手動で取得された有効期限の長いアクセストークン
- 設定時に手動で取得された有効期限の長い更新トークン
OAUTHBEARER は、Kafka ブローカーの oauth
リスナー設定で自動的に有効になります。enableOauthBearer
プロパティーを true
に設定できますが、これは必須ではありません。
# ... authentication: type: oauth # ... enableOauthBearer: true
OAUTHBEARER 認証は、プロトコルレベルで OAUTHBEARER メカニズムをサポートする Kafka クライアントでのみ使用できます。
PLAIN の概要
PLAIN は、すべての Kafka クライアントツール (kafkacat などの開発者ツールを含む) によって使用される簡易認証メカニズムです。PLAIN を OAuth 2.0 認証とともに使用できるようにするため、AMQ Streams にはサーバー側のコールバックが含まれ、この OAuth 2.0 over PLAIN を呼び出します。
PLAIN の AMQ Streams 実装では、クライアントのクレデンシャルは ZooKeeper に保存されません。代わりに、OAUTHBEARER 認証が使用される場合と同様に、クライアントのクレデンシャルは準拠した承認サーバーの背後で一元的に処理されます。
OAuth 2.0 over PLAIN コールバックを併用する場合、以下のいずれかの方法を使用して Kafka クライアントは Kafka ブローカーで認証されます。
- クライアント ID およびシークレット (OAuth 2.0 クライアントクレデンシャルメカニズムを使用)
- 設定時に手動で取得された有効期限の長いアクセストークン
PLAIN 認証を使用し、username
および password
を提供するように、クライアントを有効にする必要があります。パスワードの最初に $accessToken:
が付けられ、その後にアクセストークンの値が続く場合は、Kafka ブローカーはパスワードをアクセストークンとして解釈します。それ以外の場合は、Kafka ブローカーは username
をクライアント ID として解釈し、password
をクライアントシークレットとして解釈します。
password
がアクセストークンとして設定されている場合、username
は Kafka ブローカーによってアクセストークンから取得されるプリンシパル名と同じになるように設定される必要があります。このプロセスは、userNameClaim
、fallbackUserNameClaim
、fallbackUsernamePrefix
、または userInfoEndpointUri
を使用してユーザー名の抽出を設定する方法によって異なります。また、承認サーバーによっても異なり、特にクライアント ID をアカウント名にマッピングする方法によります。
PLAIN を使用するには、Kafka ブローカーの oauth
リスナー設定で有効にする必要があります。
以下の例では、デフォルトで有効になっている OAUTHBEARER に加え、PLAIN も有効になっています。PLAIN のみを使用する場合は、enableOauthBearer
を false
に設定して OAUTHBEARER を無効にすることができます。
# ...
authentication:
type: oauth
# ...
enablePlain: true
tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token
その他のリソース
4.4.2. OAuth 2.0 Kafka ブローカーの設定
OAuth 2.0 の Kafka ブローカー設定には、以下が関係します。
- 承認サーバーでの OAuth 2.0 クライアントの作成
- Kafka カスタムリソースでの OAuth 2.0 認証の設定
承認サーバーに関連する Kafka ブローカーおよび Kafka クライアントはどちらも OAuth 2.0 クライアントと見なされます。
4.4.2.1. 承認サーバーの OAuth 2.0 クライアント設定
セッションの開始中に受信されたトークンを検証するように Kafka ブローカーを設定するには、承認サーバーで OAuth 2.0 の クライアント 定義を作成し、以下のクライアントクレデンシャルが有効な状態で 機密情報 として設定することが推奨されます。
-
kafka
のクライアント ID (例) - 認証メカニズムとしてのクライアント ID およびシークレット
承認サーバーのパブリックでないイントロスペクションエンドポイントを使用する場合のみ、クライアント ID およびシークレットを使用する必要があります。高速のローカル JWT トークンの検証と同様に、パブリック承認サーバーのエンドポイントを使用する場合は、通常クレデンシャルは必要ありません。
4.4.2.2. Kafka クラスターでの OAuth 2.0 認証設定
Kafka クラスターで OAuth 2.0 認証を使用するには、たとえば、認証方法が oauth
の Kafka クラスターカスタムリソースの TLS リスナー設定を指定します。
OAuth 2.0 の認証方法タイプの割り当て
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
kafka:
# ...
listeners:
- name: tls
port: 9093
type: internal
tls: true
authentication:
type: oauth
#...
plain
、tls
、および external
リスナーを設定できますが、OAuth 2.0 では TLS による暗号化が無効になっている plain
リスナーまたは external
リスナーを使用しないことが推奨されます。これは、ネットワークでのデータ漏えいの脆弱性や、トークンの盗難による不正アクセスへの脆弱性が発生するためです。
external
リスナーを type: oauth
で設定し、セキュアなトランスポート層がクライアントと通信するようにします。
OAuth 2.0 の外部リスナーとの使用
# ...
listeners:
- name: external
port: 9094
type: loadbalancer
tls: true
authentication:
type: oauth
#...
tls
プロパティーはデフォルトで false に設定されているため、有効にする必要があります。
認証のタイプを OAuth 2.0 として定義した場合、検証のタイプに基づいて、 高速のローカル JWT 検証 または イントロスペクションエンドポイントを使用したトークンの検証 のいずれかとして、設定を追加します。
説明や例を用いてリスナー向けに OAuth 2.0 を設定する手順は、「Kafka ブローカーの OAuth 2.0 サポートの設定」を参照してください。
4.4.2.3. 高速なローカル JWT トークン検証の設定
高速なローカル JWT トークンの検証では、JWTトークンの署名がローカルでチェックされます。
ローカルチェックでは、トークンに対して以下が確認されます。
-
アクセストークンに
Bearer
の (typ) 要求値が含まれ、トークンがタイプに準拠することを確認します。 - 有効であるか (期限切れでない) を確認します。
-
トークンに
validIssuerURI
と一致する発行元があることを確認します。
承認サーバーによって発行されなかったすべてのトークンが拒否されるよう、リスナーの設定時に validIssuerURI
属性を指定します。
高速のローカル JWT トークン検証の実行中に、承認サーバーの通信は必要はありません。OAuth 2.0 の承認サーバーによって公開されるエンドポイントの jwksEndpointUri
属性を指定して、高速のローカル JWT トークン検証をアクティベートします。エンドポイントには、署名済み JWT トークンの検証に使用される公開鍵が含まれます。これらは、Kafka クライアントによってクレデンシャルとして送信されます。
承認サーバーとの通信はすべて TLS による暗号化を使用して実行する必要があります。
証明書トラストストアを AMQ Streams プロジェクト namespace の OpenShift シークレットとして設定し、tlsTrustedCertificates
属性を使用してトラストストアファイルが含まれる OpenShift シークレットを示すことができます。
JWT トークンからユーザー名を適切に取得するため、userNameClaim
の設定を検討してください。Kafka ACL 承認を使用する場合は、認証中にユーザー名でユーザーを特定する必要があります。JWT トークンの sub
要求は、通常は一意な ID でユーザー名ではありません。
高速なローカル JWT トークン検証の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: #... listeners: - name: tls port: 9093 type: internal tls: true authentication: type: oauth validIssuerUri: <https://<auth-server-address>/auth/realms/tls> jwksEndpointUri: <https://<auth-server-address>/auth/realms/tls/protocol/openid-connect/certs> userNameClaim: preferred_username maxSecondsWithoutReauthentication: 3600 tlsTrustedCertificates: - secretName: oauth-server-cert certificate: ca.crt #...
4.4.2.4. OAuth 2.0 イントロスペクションエンドポイントの設定
OAuth 2.0 のイントロスペクションエンドポイントを使用したトークンの検証では、受信したアクセストークンは不透明として対処されます。Kafka ブローカーは、アクセストークンをイントロスペクションエンドポイントに送信します。このエンドポイントは、検証に必要なトークン情報を応答として返します。ここで重要なのは、特定のアクセストークンが有効である場合は最新情報を返すことで、トークンの有効期限に関する情報も返します。
OAuth 2.0 のイントロスペクションベースの検証を設定するには、高速のローカル JWT トークン検証に指定された jwksEndpointUri
属性ではなく、introspectionEndpointUri
属性を指定します。通常、イントロスペクションエンドポイントは保護されているため、承認サーバーに応じて clientId
および clientSecret
を指定する必要があります。
イントロスペクションエンドポイントの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: listeners: - name: tls port: 9093 type: internal tls: true authentication: type: oauth clientId: kafka-broker clientSecret: secretName: my-cluster-oauth key: clientSecret validIssuerUri: <https://<auth-server-address>/auth/realms/tls> introspectionEndpointUri: <https://<auth-server-address>/auth/realms/tls/protocol/openid-connect/token/introspect> userNameClaim: preferred_username maxSecondsWithoutReauthentication: 3600 tlsTrustedCertificates: - secretName: oauth-server-cert certificate: ca.crt
4.4.3. Kafka ブローカーの再認証の設定
Kafka クライアントと Kafka ブローカー間の OAuth 2.0 セッションに Kafka セッション再認証 を使用するように、oauth
リスナーを設定できます。このメカニズムは、定義された期間後に、クライアントとブローカー間の認証されたセッションを期限切れにします。セッションの有効期限が切れると、クライアントは既存のコネクションを破棄せずに再使用して、新しいセッションを即座に開始します。
セッションの再認証はデフォルトで無効になっています。これを有効にするには、oauth
リスナー設定で maxSecondsWithoutReauthentication
に時間の値を設定します。OAUTHBEARER および PLAIN 認証では、同じプロパティーを使用してセッションの再認証が設定されます。設定例については、「Kafka ブローカーの OAuth 2.0 サポートの設定」 を参照してください。
セッションの再認証は、クライアントによって使用される Kafka クライアントライブラリーによってサポートされる必要があります。
セッションの再認証は、高速ローカル JWT またはイントロスペクションエンドポイントのトークン検証と使用できます。
クライアントの再認証
ブローカーの認証されたセッションが期限切れになると、クライアントは接続を切断せずに新しい有効なアクセストークンをブローカーに送信し、既存のセッションを再認証する必要があります。
トークンの検証に成功すると、既存の接続を使用して新しいクライアントセッションが開始されます。クライアントが再認証に失敗した場合、さらにメッセージを送受信しようとすると、ブローカーは接続を閉じます。ブローカーで再認証メカニズムが有効になっていると、Kafka クライアントライブラリー 2.2 以降を使用する Java クライアントが自動的に再認証されます。
更新トークンが使用される場合、セッションの再認証は更新トークンにも適用されます。セッションが期限切れになると、クライアントは更新トークンを使用してアクセストークンを更新します。その後、クライアントは新しいアクセストークンを使用して既存のセッションに再認証されます。
OAUTHBEARER および PLAIN のセッションの有効期限
セッションの再認証が設定されている場合、OAUTHBEARER と PLAIN 認証ではセッションの有効期限は異なります。
クライアント ID とシークレットによる方法を使用する OAUTHBEARER および PLAIN の場合:
-
ブローカーの認証されたセッションは、設定された
maxSecondsWithoutReauthentication
で期限切れになります。 - アクセストークンが設定期間前に期限切れになると、セッションは設定期間前に期限切れになります。
有効期間の長いアクセストークンによる方法を使用する PLAIN の場合:
-
ブローカーの認証されたセッションは、設定された
maxSecondsWithoutReauthentication
で期限切れになります。 - アクセストークンが設定期間前に期限切れになると、再認証に失敗します。セッションの再認証は試行されますが、PLAIN にはトークンを更新するメカニズムがありません。
maxSecondsWithoutReauthentication
が設定されていない場合は、再認証しなくても、OAUTHBEARER および PLAIN クライアントはブローカーへの接続を無期限に維持します。認証されたセッションは、アクセストークンの期限が切れても終了しません。ただし、これは keycloak
承認を使用したり、カスタムオーソライザーをインストールしたりして、承認を設定する場合に考慮されます。
4.4.4. OAuth 2.0 Kafka クライアントの設定
Kafka クライアントは以下のいずれかで設定されます。
- 承認サーバーから有効なアクセストークンを取得するために必要なクレデンシャル (クライアント ID およびシークレット)。
- 承認サーバーから提供されたツールを使用して取得された、有効期限の長い有効なアクセストークンまたは更新トークン。
アクセストークンは、Kafka ブローカーに送信される唯一の情報です。アクセストークンを取得するために承認サーバーでの認証に使用されるクレデンシャルは、ブローカーに送信されません。
クライアントによるアクセストークンの取得後、承認サーバーと通信する必要はありません。
クライアント ID とシークレットを使用した認証が最も簡単です。有効期間の長いアクセストークンまたは更新トークンを使用すると、承認サーバーツールに追加の依存関係があるため、より複雑になります。
有効期間が長いアクセストークンを使用している場合は、承認サーバーでクライアントを設定し、トークンの最大有効期間を長くする必要があります。
Kafka クライアントが直接アクセストークンで設定されていない場合、クライアントは承認サーバーと通信して Kafka セッションの開始中にアクセストークンのクレデンシャルを交換します。Kafka クライアントは以下のいずれかを交換します。
- クライアント ID およびシークレット
- クライアント ID、更新トークン、および (任意の) シークレット
4.4.5. OAuth 2.0 のクライアント認証フロー
ここでは、Kafka セッションの開始時における Kafka クライアント、Kafka ブローカー、および承認ブローカー間の通信フローを説明および可視化します。フローは、クライアントとサーバーの設定によって異なります。
Kafka クライアントがアクセストークンをクレデンシャルとして Kafka ブローカーに送信する場合、トークンを検証する必要があります。
使用する承認サーバーや利用可能な設定オプションによっては、以下の使用が適している場合があります。
- 承認サーバーと通信しない、JWT の署名確認およびローカルトークンのイントロスペクションをベースとした高速なローカルトークン検証。
- 承認サーバーによって提供される OAuth 2.0 のイントロスペクションエンドポイント。
高速のローカルトークン検証を使用するには、トークンでの署名検証に使用される公開証明書のある JWKS エンドポイントを提供する承認サーバーが必要になります。
この他に、承認サーバーで OAuth 2.0 のイントロスペクションエンドポイントを使用することもできます。新しい Kafka ブローカー接続が確立されるたびに、ブローカーはクライアントから受け取ったアクセストークンを承認サーバーに渡し、応答を確認してトークンが有効であるかどうかを確認します。
Kafka クライアントのクレデンシャルは以下に対して設定することもできます。
- 以前に生成された有効期間の長いアクセストークンを使用した直接ローカルアクセス。
- 新しいアクセストークンの発行についての承認サーバーとの通信。
承認サーバーは不透明なアクセストークンの使用のみを許可する可能性があり、この場合はローカルトークンの検証は不可能です。
4.4.5.1. クライアント認証フローの例
Kafka クライアントおよびブローカーが以下に設定されている場合の、Kafka セッション認証中のコミュニケーションフローを確認できます。
クライアントではクライアント ID とシークレットが使用され、ブローカーによって検証が承認サーバーに委譲される場合
- Kafka クライアントは承認サーバーからアクセストークンを要求します。これにはクライアント ID とシークレットを使用し、任意で更新トークンも使用します。
- 承認サーバーによって新しいアクセストークンが生成されます。
- Kafka クライアントは SASL OAUTHBEARER メカニズムを使用してアクセストークンを渡し、Kafka ブローカーの認証を行います。
- Kafka ブローカーは、独自のクライアント ID およびシークレットを使用して、承認サーバーでトークンイントロスペクションエンドポイントを呼び出し、アクセストークンを検証します。
- トークンが有効な場合は、Kafka クライアントセッションが確立されます。
クライアントではクライアント ID およびシークレットが使用され、ブローカーによって高速のローカルトークン検証が実行される場合
- Kafka クライアントは、トークンエンドポイントから承認サーバーの認証を行います。これにはクライアント ID とシークレットが使用され、任意で更新トークンも使用されます。
- 承認サーバーによって新しいアクセストークンが生成されます。
- Kafka クライアントは SASL OAUTHBEARER メカニズムを使用してアクセストークンを渡し、Kafka ブローカーの認証を行います。
- Kafka ブローカーは、JWT トークン署名チェックおよびローカルトークンイントロスペクションを使用して、ローカルでアクセストークンを検証します。
クライアントでは有効期限の長いアクセストークンが使用され、ブローカーによって検証が承認サーバーに委譲される場合
- Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して有効期限の長いアクセストークンを渡し、Kafka ブローカーの認証を行います。
- Kafka ブローカーは、独自のクライアント ID およびシークレットを使用して、承認サーバーでトークンイントロスペクションエンドポイントを呼び出し、アクセストークンを検証します。
- トークンが有効な場合は、Kafka クライアントセッションが確立されます。
クライアントでは有効期限の長いアクセストークンが使用され、ブローカーによって高速のローカル検証が実行される場合
- Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して有効期限の長いアクセストークンを渡し、Kafka ブローカーの認証を行います。
- Kafka ブローカーは、JWT トークン署名チェックおよびローカルトークンイントロスペクションを使用して、ローカルでアクセストークンを検証します。
トークンが取り消された場合に承認サーバーとのチェックが行われないため、高速のローカル JWT トークン署名の検証は有効期限の短いトークンにのみ適しています。トークンの有効期限はトークンに書き込まれますが、失効はいつでも発生する可能性があるため、承認サーバーと通信せずに対応することはできません。発行されたトークンはすべて期限切れになるまで有効とみなされます。
4.4.6. OAuth 2.0 認証の設定
OAuth 2.0 は、Kafka クライアントと AMQ Streams コンポーネントとの対話に使用されます。
AMQ Streams に OAuth 2.0 を使用するには、以下を行う必要があります。
4.4.6.1. OAuth 2.0 承認サーバーとしての Red Hat Single Sign-On の設定
この手順では、Red Hat Single Sign-On を承認サーバーとしてデプロイし、AMQ Streams と統合するための設定方法を説明します。
承認サーバーは、一元的な認証および承認の他、ユーザー、クライアント、およびパーミッションの一元管理を実現します。Red Hat Single Sign-On にはレルムの概念があります。レルム はユーザー、クライアント、パーミッション、およびその他の設定の個別のセットを表します。デフォルトの マスターレルム を使用できますが、新しいレルムを作成することもできます。各レルムは独自の OAuth 2.0 エンドポイントを公開します。そのため、アプリケーションクライアントとアプリケーションサーバーはすべて同じレルムを使用する必要があります。
AMQ Streams で OAuth 2.0 を使用するには、Red Hat Single Sign-On のデプロイメントを使用して認証レルムを作成および管理します。
Red Hat Single Sign-On がすでにデプロイされている場合は、デプロイメントの手順を省略して、現在のデプロイメントを使用できます。
作業を開始する前の注意事項
Red Hat Single Sign-On を使用するための知識が必要です。
デプロイメントおよび管理の手順は、以下を参照してください。
前提条件
- AMQ Streams および Kafka が稼働している必要があります。
Red Hat Single Sign-On デプロイメントに関する条件:
- 「Red Hat Single Sign-On でサポートされる構成」を確認しておく必要があります。
- インストールには、system:admin などの cluster-admin ロールを持つユーザーが必要です。
手順
Red Hat Single Sign-On を OpenShift クラスターにデプロイします。
OpenShift Web コンソールでデプロイメントの進捗を確認します。
Red Hat Single Sign-On の Admin Console にログインし、AMQ Streams の OAuth 2.0 ポリシーを作成します。
ログインの詳細は、Red Hat Single Sign-On のデプロイ時に提供されます。
レルムを作成し、有効にします。
既存のマスターレルムを使用できます。
- 必要に応じて、レルムのセッションおよびトークンのタイムアウトを調整します。
-
kafka-broker
というクライアントを作成します。 -
Access Type を
Confidential
に設定します。 -
Standard Flow Enabled を
OFF
に設定し、このクライアントからの Web ログインを無効にします。 -
Service Accounts Enabled を
ON
に設定し、このクライアントが独自の名前で認証できるようにします。
-
Access Type を
- 続行する前に Save クリックします。
- タブにある、AMQ Streams の Kafka クラスター設定で使用するシークレットを書き留めておきます。
Kafka ブローカーに接続するすべてのアプリケーションクライアントに対して、このクライアント作成手順を繰り返し行います。
新しいクライアントごとに定義を作成します。
設定では、名前をクライアント ID として使用します。
次のステップ
承認サーバーのデプロイおよび設定後に、Kafka ブローカーが OAuth 2.0 を使用するように設定 します。
4.4.6.2. Kafka ブローカーの OAuth 2.0 サポートの設定
この手順では、ブローカーリスナーが承認サーバーを使用して OAuth 2.0 認証を使用するように、Kafka ブローカーを設定する方法について説明します。
TLS リスナーを設定して、暗号化されたインターフェースで OAuth 2.0 を使用することが推奨されます。プレーンリスナーは推奨されません。
承認サーバーが信頼できる CA によって署名された証明書を使用し、OAuth 2.0 サーバーのホスト名と一致する場合、TLS 接続はデフォルト設定を使用して動作します。それ以外の場合は、プローバー証明書でトラストストアを設定するか、証明書のホスト名の検証を無効にする必要があります。
Kafka ブローカーの設定する場合、新たに接続された Kafka クライアントの OAuth 2.0 認証中にアクセストークンを検証するために使用されるメカニズムには、以下の 2 つのオプションがあります。
作業を開始する前の注意事項
Kafka ブローカーリスナーの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。
前提条件
- AMQ Streams および Kafka が稼働している必要があります。
- OAuth 2.0 の承認サーバーがデプロイされている必要があります。
手順
エディターで、
Kafka
リソースの Kafka ブローカー設定 (Kafka.spec.kafka
) を更新します。oc edit kafka my-cluster
Kafka ブローカーの
listeners
設定を行います。各タイプのリスナーは独立しているため、同じ設定にする必要はありません。
以下は、外部リスナーに設定された設定オプションの例になります。
例 1: 高速なローカル JWT トークン検証の設定
#... - name: external port: 9094 type: loadbalancer tls: true authentication: type: oauth 1 validIssuerUri: <https://<auth-server-address>/auth/realms/external> 2 jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs> 3 userNameClaim: preferred_username 4 maxSecondsWithoutReauthentication: 3600 5 tlsTrustedCertificates: 6 - secretName: oauth-server-cert certificate: ca.crt disableTlsHostnameVerification: true 7 jwksExpirySeconds: 360 8 jwksRefreshSeconds: 300 9 jwksMinRefreshPauseSeconds: 1 10 enableECDSA: "true" 11
- 1
oauth
に設定されたリスナータイプ。- 2
- 認証に使用されるトークン発行者の URI。
- 3
- ローカルの JWT 検証に使用される JWKS 証明書エンドポイントの URI。
- 4
- トークンの実際のユーザー名が含まれるトークン要求 (またはキー)。ユーザー名は、ユーザーの識別に使用される principal です。
userNameClaim
の値は、使用される認証フローと承認サーバーによって異なります。 - 5
- (任意設定): セッションの有効期限がアクセストークンと同じ期間になるよう強制する Kafka の再認証メカニズムを有効にします。指定された値がアクセストークンの有効期限が切れるまでの残り時間未満の場合、クライアントは実際にトークンの有効期限が切れる前に再認証する必要があります。デフォルトでは、アクセストークンの期限が切れてもセッションは期限切れにならず、クライアントは再認証を試行しません。
- 6
- (任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。
- 7
- (任意設定): TLS ホスト名の検証を無効にします。デフォルトは
false
です。 - 8
- JWKS 証明書が期限切れになる前に有効であるとみなされる期間。デフォルトは
360
秒 です。デフォルトよりも長い時間を指定する場合は、無効になった証明書へのアクセスが許可されるリスクを考慮してください。 - 9
- JWKS 証明書を更新する間隔。この間隔は、有効期間よりも 60 秒以上短くする必要があります。デフォルトは
300
秒 です。 - 10
- JWKS 公開鍵の更新が連続して試行される間隔の最小一時停止時間 (秒単位)。不明な署名キーが検出されると、JWKS キーの更新は、最後に更新を試みてから少なくとも指定された期間は一時停止し、通常の定期スケジュール以外でスケジュールされます。キーの更新はエクスポネンシャルバックオフ (exponential backoff) のルールに従い、
jwksRefreshSeconds
に到達するまで、一時停止を増やして失敗した更新の再試行を行います。デフォルト値は 1 です。 - 11
- (任意設定): ECDSA を使用して承認サーバーで JWT トークンを署名する場合は、これを有効にする必要があります。BouncyCastle 暗号ライブラリーを使用して追加の暗号プロバイダーがインストールされます。デフォルトは
false
です。
例 2: イントロスペクションエンドポイントを使用したトークンの検証の設定
- name: external port: 9094 type: loadbalancer tls: true authentication: type: oauth validIssuerUri: <https://<auth-server-address>/auth/realms/external> introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect> 1 clientId: kafka-broker 2 clientSecret: 3 secretName: my-cluster-oauth key: clientSecret userNameClaim: preferred_username 4 maxSecondsWithoutReauthentication: 3600 5
- 1
- トークンイントロスペクションエンドポイントの URI。
- 2
- クライアントを識別するためのクライアント ID。
- 3
- 認証にはクライアントシークレットとクライアント ID が使用されます。
- 4
- トークンの実際のユーザー名が含まれるトークン要求 (またはキー)。ユーザー名は、ユーザーの識別に使用される principal です。
userNameClaim
の値は、使用される承認サーバーによって異なります。 - 5
- (任意設定): セッションの有効期限がアクセストークンと同じ期間になるよう強制する Kafka の再認証メカニズムを有効にします。指定された値がアクセストークンの有効期限が切れるまでの残り時間未満の場合、クライアントは実際にトークンの有効期限が切れる前に再認証する必要があります。デフォルトでは、アクセストークンの期限が切れてもセッションは期限切れにならず、クライアントは再認証を試行しません。
OAuth 2.0 認証の適用方法や、承認サーバーのタイプによっては、追加 (任意) の設定を使用できます。
# ... authentication: type: oauth # ... checkIssuer: false 1 checkAudience: true 2 fallbackUserNameClaim: client_id 3 fallbackUserNamePrefix: client-account- 4 validTokenType: bearer 5 userInfoEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/userinfo 6 enableOauthBearer: false 7 enablePlain: true 8 tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token 9 customClaimCheck: "@.custom == 'custom-value'" 10
- 1
- 承認サーバーが
iss
クレームを提供しない場合は、発行者チェックを行うことができません。このような場合、checkIssuer
をfalse
に設定し、validIssuerUri
を指定しないようにします。デフォルトはtrue
です。 - 2
- 承認サーバーによって
aud
(オーディエンス) クレームが提供され、オーディエンスチェックを強制する場合は、checkAudience
をtrue
に設定します。オーディエンスチェックによって、トークンの目的の受信者が特定されます。そのため、Kafka ブローカーによって、aud
クレームにclientId
のないトークンは拒否されます。デフォルトはfalse
です。 - 3
- 承認サーバーは、通常ユーザーとクライアントの両方を識別する単一の属性を提供しない場合があります。クライアントが独自の名前で認証される場合、サーバーによって クライアント ID が提供されることがあります。更新トークンまたはアクセストークンを取得するために、ユーザー名およびパスワードを使用してユーザーが認証される場合、サーバーによってクライアント ID の他に ユーザー名 が提供されることがあります。プライマリーユーザー ID 属性が使用できない場合は、このフォールバックオプションで、使用するユーザー名クレーム (属性) を指定します。
- 4
fallbackUserNameClaim
が適用される場合、ユーザー名クレームの値とフォールバックユーザー名クレームの値が競合しないようにする必要もあることがあります。producer
というクライアントが存在し、producer
という通常ユーザーも存在する場合について考えてみましょう。この 2 つを区別するには、このプロパティーを使用してクライアントのユーザー ID に接頭辞を追加します。- 5
- (
introspectionEndpointUri
を使用する場合のみ該当): 使用している認証サーバーによっては、イントロスペクションエンドポイントによってトークンタイプ属性が返されるかどうかは分からず、異なる値が含まれることがあります。イントロスペクションエンドポイントからの応答に含まれなければならない有効なトークンタイプ値を指定できます。 - 6
- (
introspectionEndpointUri
を使用する場合のみ該当): イントロスペクションエンドポイントの応答に識別可能な情報が含まれないように、承認サーバーが設定または実装されることがあります。ユーザー ID を取得するには、userinfo
エンドポイントの URI をフォールバックとして設定します。userNameClaim
、fallbackUserNameClaim
、およびfallbackUserNamePrefix
設定がuserinfo
エンドポイントの応答に適用されます。 - 7
- これを
false`to disable the OAUTHBEARER mechanism on the listener. At least one of PLAIN or OAUTHBEARER has to be enabled. Default is `true
に設定します。 - 8
- リスナーで PLAIN メカニズムを有効にするには、これを
true
に設定します。これは、すべてのプラットフォームのすべてのクライアントでサポートされます。Kafka クライアントで PLAIN メカニズムを有効にし、username
およびpassword
を設定する必要があります。このメカニズムは、OAuth アクセストークンを使用するか、OAuth クライアント ID およびシークレット (クライアントクレデンシャル) を使用して、認証するために使用できます。クライアントによって、文字列$accessToken:
で始まるpassword
が設定された場合、パスワードはサーバー上のアクセストークンとして解釈され、username
はアカウントのユーザー名として解釈されます。それ以外の場合は、ユーザーはクライアント ID として解釈され、パスワードはクライアントシークレットとして解釈されます。デフォルトはfalse
です。 - 9
- これは、前のポイントで説明されているように、
enablePlain
が true に設定されている場合にクライアントクレデンシャル認証をサポートするように設定する必要があります。 - 10
- これを JsonPath フィルタークエリーに設定すると、検証中に追加のカスタムルールを JWT アクセストークンに適用できます。アクセストークンに必要なデータが含まれていないと拒否されます。
introspectionEndpointUri
を使用する場合、カスタムチェックはイントロスペクションエンドポイントの応答 JSON に適用されます。
- エディターを保存して終了し、ローリングアップデートの完了を待ちます。
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -w
ローリングアップデートによって、ブローカーが OAuth 2.0 認証を使用するように設定されます。
次のステップ
4.4.6.3. OAuth 2.0 を使用するよう Kafka Java クライアントを設定
この手順では、Kafka ブローカーとの対話に OAuth 2.0 を使用するように Kafka プロデューサーおよびコンシューマー API を設定する方法を説明します。
クライアントコールバックプラグインを pom.xml ファイルに追加し、システムプロパティーを設定します。
前提条件
- AMQ Streams および Kafka が稼働している必要があります。
- OAuth 2.0 承認サーバーがデプロイされ、Kafka ブローカーへの OAuth のアクセスが設定されている必要があります。
- Kafka ブローカーが OAuth 2.0 に対して設定されている必要があります。
手順
OAuth 2.0 サポートのあるクライアントライブラリーを Kafka クライアントの
pom.xml
ファイルに追加します。<dependency> <groupId>io.strimzi</groupId> <artifactId>kafka-oauth-client</artifactId> <version>0.7.1.redhat-00003</version> </dependency>
コールバックのシステムプロパティーを設定します。
以下に例を示します。
System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”); 1 System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client-name>"); 2 System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client-secret>"); 3
Kafka クライアント設定の TLS で暗号化された接続で SASL OAUTHBEARER メカニズムを有効にします。
以下に例を示します。
props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;"); props.put("security.protocol", "SASL_SSL"); 1 props.put("sasl.mechanism", "OAUTHBEARER"); props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");
- 1
- この例では、TLS 接続で
SASL_SSL
を使用します。暗号化されていない接続ではSASL_PLAINTEXT
を使用します。
- Kafka クライアントが Kafka ブローカーにアクセスできることを確認します。
次のステップ
4.4.6.4. Kafka コンポーネントの OAuth 2.0 の設定
この手順では、承認サーバーを使用して OAuth 2.0 認証を使用するように Kafka コンポーネントを設定する方法を説明します。
以下の認証を設定できます。
- Kafka Connect
- Kafka MirrorMaker
- Kafka Bridge
この手順では、Kafka コンポーネントと承認サーバーは同じサーバーで稼働しています。
作業を開始する前の注意事項
Kafka コンポーネントの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。
前提条件
- AMQ Streams および Kafka が稼働している必要があります。
- OAuth 2.0 承認サーバーがデプロイされ、Kafka ブローカーへの OAuth のアクセスが設定されている必要があります。
- Kafka ブローカーが OAuth 2.0 に対して設定されている必要があります。
手順
クライアントシークレットを作成し、これを環境変数としてコンポーネントにマウントします。
以下は、Kafka Bridge の
Secret
を作成する例になります。apiVersion: kafka.strimzi.io/v1beta2 kind: Secret metadata: name: my-bridge-oauth type: Opaque data: clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 1
- 1
clientSecret
キーは base64 形式である必要があります。
Kafka コンポーネントのリソースを作成または編集し、OAuth 2.0 認証が認証プロパティーに設定されるようにします。
OAuth 2.0 認証では、以下を使用できます。
- クライアント ID およびシークレット
- クライアント ID および更新トークン
- アクセストークン
- TLS
KafkaClientAuthenticationOAuth スキーマ参照は、それぞれの例を提供します。
以下は、クライアント ID、シークレット、および TLS を使用して OAuth 2.0 が Kafka Bridge クライアントに割り当てられる例になります。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... authentication: type: oauth 1 tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 2 clientId: kafka-bridge clientSecret: secretName: my-bridge-oauth key: clientSecret tlsTrustedCertificates: 3 - secretName: oauth-server-cert certificate: tls.crt
OAuth 2.0 認証の適用方法や、承認サーバーのタイプによって、使用できる追加の設定オプションがあります。
# ... spec: # ... authentication: # ... disableTlsHostnameVerification: true 1 checkAccessTokenType: false 2 accessTokenIsJwt: false 3 scope: any 4
- 1
- (任意設定): TLS ホスト名の検証を無効にします。デフォルトは
false
です。 - 2
- 承認サーバーによって、JWT トークン内部で
typ
(タイプ) 要求が返されない場合は、checkAccessTokenType: false
を適用するとトークンタイプがチェックされず次に進むことができます。デフォルトはtrue
です。 - 3
- 不透明なトークンを使用している場合、アクセストークンが JWT トークンとして処理されないように
accessTokenIsJwt: false
を適用することができます。 - 4
- (任意設定): トークンエンドポイントからトークンを要求するための
scope
。認証サーバーでは、クライアントによるスコープの指定が必要になることがあります。この場合ではany
になります。
Kafka リソースのデプロイメントに変更を適用します。
oc apply -f your-file
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -w
ローリングアップデートでは、OAuth 2.0 認証を使用して Kafka ブローカーと対話するコンポーネントが設定されます。
4.5. OAuth 2.0 トークンベース承認の使用
AMQ Streams は、Red Hat Single Sign-On の 承認サービス による OAuth 2.0 トークンベースの承認をサポートします。これにより、セキュリティーポリシーとパーミッションの一元的な管理が可能になります。
Red Hat Single Sign-On で定義されたセキュリティーポリシーおよびパーミッションは、Kafka ブローカーのリソースへのアクセスを付与するために使用されます。ユーザーとクライアントは、Kafka ブローカーで特定のアクションを実行するためのアクセスを許可するポリシーに対して照合されます。
Kafka では、デフォルトですべてのユーザーがブローカーに完全アクセスできます。また、アクセス制御リスト (ACL) を基にして承認を設定するために AclAuthorizer
プラグインが提供されます。
ZooKeeper には、 ユーザー名 を基にしてリソースへのアクセスを付与または拒否する ACL ルールが保存されます。ただし、Red Hat Single Sign-On を使用した OAuth 2.0 トークンベースの承認では、より柔軟にアクセス制御を Kafka ブローカーに実装できます。さらに、Kafka ブローカーで OAuth 2.0 の承認および ACL が使用されるように設定することができます。
4.5.1. OAuth 2.0 の承認メカニズム
AMQ Streams の OAuth 2.0 での承認では、Red Hat Single Sign-On サーバーの Authorization Services REST エンドポイントを使用して、Red Hat Single Sign-On を使用するトークンベースの認証が拡張されます。これは、定義されたセキュリティーポリシーを特定のユーザーに適用し、そのユーザーの異なるリソースに付与されたパーミッションの一覧を提供します。ポリシーはロールとグループを使用して、パーミッションをユーザーと照合します。OAuth 2.0 の承認では、Red Hat Single Sign-On の Authorization Services から受信した、ユーザーに付与された権限のリストを基にして、権限がローカルで強制されます。
4.5.1.1. Kafka ブローカーのカスタムオーソライザー
AMQ Streams では、Red Hat Single Sign-On の オーソライザー (KeycloakRBACAuthorizer
) が提供されます。Red Hat Single Sign-On によって提供される Authorization Services で Red Hat Single Sign-On REST エンドポイントを使用できるようにするには、Kafka ブローカーでカスタムオーソライザーを設定します。
オーソライザーは必要に応じて付与された権限のリストを承認サーバーから取得し、ローカルで Kafka ブローカーに承認を強制するため、クライアントの要求ごとに迅速な承認決定が行われます。
4.5.2. OAuth 2.0 承認サポートの設定
この手順では、Red Hat Single Sign-On の Authorization Services を使用して、OAuth 2.0 承認を使用するように Kafka ブローカーを設定する方法を説明します。
作業を始める前に
特定のユーザーに必要なアクセス、または制限するアクセスについて検討してください。Red Hat Single Sign-On では、Red Hat Single Sign-On の グループ、ロール、クライアント、および ユーザー の組み合わせを使用して、アクセスを設定できます。
通常、グループは組織の部門または地理的な場所を基にしてユーザーを照合するために使用されます。また、ロールは職務を基にしてユーザーを照合するために使用されます。
Red Hat Single Sign-On を使用すると、ユーザーおよびグループを LDAP で保存できますが、クライアントおよびロールは LDAP で保存できません。ユーザーデータへのアクセスとストレージを考慮して、承認ポリシーの設定方法を選択する必要がある場合があります。
スーパーユーザー は、Kafka ブローカーに実装された承認にかかわらず、常に制限なく Kafka ブローカーにアクセスできます。
前提条件
- AMQ Streams は、トークンベースの認証 に Red Hat Single Sign-On と OAuth 2.0 を使用するように設定されている必要があります。承認を設定するときに、同じ Red Hat Single Sign-On サーバーエンドポイントを使用する必要があります。
-
OAuth 2.0 認証は、再認証を有効にするために
maxSecondsWithoutReauthentication
オプションで設定する必要があります。
手順
- Red Hat Single Sign-On の Admin Console にアクセスするか、Red Hat Single Sign-On の Admin CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka ブローカークライアントの Authorization Services を有効にします。
- 承認サービスを使用して、クライアントのリソース、承認スコープ、ポリシー、およびパーミッションを定義します。
- ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
エディターで
Kafka
リソースの Kafka ブローカー設定 (Kafka.spec.kafka
) を更新して、Kafka ブローカーで Red Hat Single Sign-On による承認が使用されるように設定します。oc edit kafka my-cluster
Kafka ブローカーの
kafka
設定を指定して、keycloak
による承認を使用し、承認サーバーと Red Hat Single Sign-On の Authorization Services にアクセスできるようにします。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... authorization: type: keycloak 1 tokenEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token> 2 clientId: kafka 3 delegateToKafkaAcls: false 4 disableTlsHostnameVerification: false 5 superUsers: 6 - CN=fred - sam - CN=edward tlsTrustedCertificates: 7 - secretName: oauth-server-cert certificate: ca.crt grantsRefreshPeriodSeconds: 60 8 grantsRefreshPoolSize: 5 9 #...
- 1
- タイプ
keycloak
によって Red Hat Single Sign-On の承認が有効になります。 - 2
- Red Hat Single Sign-On トークンエンドポイントの URI。本番環境では常に HTTP を使用してください。
- 3
- 承認サービスが有効になっている Red Hat Single Sign-On の OAuth 2.0 クライアント定義のクライアント ID。通常、
kafka
が ID として使用されます。 - 4
- (任意設定): Red Hat Single Sign-On の Authorization Services のポリシーによってアクセスが拒否される場合は、Kafka
AclAuthorizer
に承認を委譲します。デフォルトはfalse
です。 - 5
- (任意設定): TLS ホスト名の検証を無効にします。デフォルトは
false
です。 - 6
- (任意設定): 指定の スーパーユーザー。
- 7
- (任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。
- 8
- (任意設定): 連続する付与 (Grants) 更新実行の間隔。これは、アクティブなセッションが Red Hat Single Sign-On でユーザーのパーミッション変更を検出する最大時間です。デフォルト値は 60 です。
- 9
- (任意設定): アクティブなセッションの付与 (Grants) の更新 (並行して) に使用するスレッドの数。デフォルト値は 5 です。
- エディターを保存して終了し、ローリングアップデートの完了を待ちます。
ログで更新を確認するか、Pod の状態遷移を監視して確認します。
oc logs -f ${POD_NAME} -c kafka oc get pod -w
ローリングアップデートによって、ブローカーが OAuth 2.0 承認を使用するように設定されます。
- クライアントまたは特定のロールを持つユーザーとして Kafka ブローカーにアクセスして、設定したパーミッションを検証し、必要なアクセス権限があり、付与されるべきでないアクセス権限がないことを確認します。
第5章 AMQ Streams operator の使用
AMQ Streams の operator を使用して Kafka クラスターと Kafka トピックおよびユーザーを管理します。
5.1. Cluster Operator の使用
Cluster Operator は Kafka クラスターや他の Kafka コンポーネントをデプロイするために使用されます。
Cluster Operator は YAML インストールファイルを使用してデプロイされます。
OpenShift では、Kafka Connect デプロイメントに Source2Image 機能を組み込み、追加のコネクターを加えるための便利な方法として利用できます。
その他のリソース
- 『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Cluster Operator のデプロイ」
- 「Kafka クラスターの設定」
5.1.1. Cluster Operator の設定
Cluster Operator は、サポートされる環境変数を使用してロギング設定から設定できます。
環境変数は、Cluster Operator イメージのデプロイメンのコンテナー設定に関連します。image
設定の詳細は、「image
」 を参照してください。
STRIMZI_NAMESPACE
Operator が操作する namespace のカンマ区切りのリスト。設定されていない場合や、空の文字列や
*
に設定された場合は、Cluster Operator はすべての namespace で操作します。Cluster Operator デプロイメントでは OpenShift Downward API を使用して、これを Cluster Operator がデプロイされる namespace に自動設定することがあります。Cluster Operator namespace の設定例
env: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
-
STRIMZI_FULL_RECONCILIATION_INTERVAL_MS
- 任意設定、デフォルトは 120000 ミリ秒です。定期的な調整の間隔 (秒単位)。
STRIMZI_OPERATION_TIMEOUT_MS
- 任意設定、デフォルトは 300000 ミリ秒です。内部操作のタイムアウト (ミリ秒単位)。この値は、標準の OpenShift 操作の時間が通常よりも長いクラスターで (Docker イメージのダウンロードが遅い場合など) AMQ Streams を使用する場合に増やす必要があります。
STRIMZI_OPERATOR_NAMESPACE
AMQ Streams Cluster Operator が稼働している namespace の名前。この変数は手動で設定しないでください。OpenShift Downward API を使用します。
env: - name: STRIMZI_OPERATOR_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
STRIMZI_OPERATOR_NAMESPACE_LABELS
任意設定。AMQ Streams Cluster Operator が稼働している namespace のラベル。namespace ラベルは、ネットワークポリシーで namespace セレクターを設定するために使用されます。これにより、AMQ Streams Cluster Operator はこれらのラベルを持つ namespace からのオペランドのみにアクセスできます。設定されていない場合、ネットワークポリシーの namespace セレクターは、OpenShift クラスターのすべての namespace から AMQ Streams Cluster Operator にアクセスできるように設定されます。
env: - name: STRIMZI_OPERATOR_NAMESPACE_LABELS value: label1=value1,label2=value2
STRIMZI_CUSTOM_RESOURCE_SELECTOR
任意設定。Operator によって処理されるカスタムリソースのフィルタリングに使用されるラベルセレクターを指定します。Operator は、指定されたラベルが設定されているカスタムリソースでのみ動作します。これらのラベルのないリソースは Operator によって認識されません。ラベルセレクターは、
Kafka
、KafkaConnect
、KafkaConnectS2I
、KafkaBridge
、KafkaMirrorMaker
、およびKafkaMirrorMaker2
リソースに適用されます。KafkaRebalance
およびKafkaConnector
リソースは、対応する Kafka および Kafka Connect クラスターに一致するラベルがある場合にのみ操作されます。env: - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR value: label1=value1,label2=value2
STRIMZI_KAFKA_IMAGES
-
必須。Kafka バージョンから、そのバージョンの Kafka ブローカーが含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>
ペアです。例:2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
これは、Kafka.spec.kafka.version
プロパティーが指定され、Kafka
リソースのKafka.spec.kafka.image
は指定されていない場合に使用されます。 STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
です。Kafka
リソースでkafka-init-image
として指定されたイメージがない場合に、初期設定作業 (ラックサポート) のブローカーの前に開始される init コンテナーのデフォルトとして使用するイメージ名。 STRIMZI_KAFKA_CONNECT_IMAGES
-
必須。Kafka バージョンから、そのバージョンの Kafka Connect が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>
ペアです。例:2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
これは、KafkaConnect.spec.version
プロパティーが指定され、KafkaConnect.spec.image
は指定されていない場合に使用されます。 STRIMZI_KAFKA_CONNECT_S2I_IMAGES
-
必須。Kafka バージョンから、そのバージョンの Kafka Connect が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>
ペアです。例:2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
これは、KafkaConnectS2I.spec.version
プロパティーが指定され、KafkaConnectS2I.spec.image
は指定されていない場合に使用されます。 STRIMZI_KAFKA_MIRROR_MAKER_IMAGES
-
必須。Kafka バージョンから、そのバージョンの Kafka Mirror Maker が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>
ペアです。例:2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.7.0, 2.7.0=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
これは、KafkaMirrorMaker.spec.version
プロパティーが指定され、KafkaMirrorMaker.spec.image
は指定されていない場合に使用されます。 STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE
-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
です。Kafka
リソースにKafka.spec.entityOperator.topicOperator.image
として指定されたイメージがない場合に、Topic Operator のデプロイ時にデフォルトとして使用するイメージ名。 STRIMZI_DEFAULT_USER_OPERATOR_IMAGE
-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
です。Kafka
リソースにKafka.spec.entityOperator.userOperator.image
として指定されたイメージがない場合に、User Operator のデプロイ時にデフォルトとして使用するイメージ名。 STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE
-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
です。Kafka
リソースでKafka.spec.entityOperator.tlsSidecar.image
として指定されたイメージがない場合に、Entity Operator の TLS サポートを提供するサイドカーコンテナーをデプロイする際にデフォルトとして使用するイメージ名。 STRIMZI_IMAGE_PULL_POLICY
-
任意設定。AMQ Streams の Cluster Operator によって管理されるすべての Pod のコンテナーに適用される
ImagePullPolicy
。有効な値は、Always
、IfNotPresent
、およびNever
です。指定のない場合、OpenShift のデフォルトが使用されます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。 STRIMZI_IMAGE_PULL_SECRETS
-
任意設定。
Secret
名のカンマ区切りのリスト。ここで参照されるシークレットには、コンテナーイメージがプルされるコンテナーレジストリーへのクレデンシャルが含まれます。シークレットは、Cluster Operator によって作成されるすべてのPods
のimagePullSecrets
フィールドで使用されます。このリストを変更すると、Kafka、Kafka Connect、および Kafka MirrorMaker のすべてのクラスターのローリングアップデートが実行されます。 STRIMZI_KUBERNETES_VERSION
任意設定。API サーバーから検出された Kubernetes バージョン情報をオーバーライドします。
Kubernetes バージョンオーバーライドの設定例
env: - name: STRIMZI_KUBERNETES_VERSION value: | major=1 minor=16 gitVersion=v1.16.2 gitCommit=c97fe5036ef3df2967d086711e6c0c405941e14b gitTreeState=clean buildDate=2019-10-15T19:09:08Z goVersion=go1.12.10 compiler=gc platform=linux/amd64
KUBERNETES_SERVICE_DNS_DOMAIN
任意設定。デフォルトの OpenShift DNS サフィックスを上書きします。
デフォルトでは、OpenShfit クラスターで割り当てられるサービスに、デフォルトのサフィックス
cluster.local
を使用する DNS ドメイン名があります。ブローカーが kafka-0 の場合の例は次のとおりです。
<cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc.cluster.local
DNS ドメイン名は、ホスト名の検証に使用される Kafka ブローカー証明書に追加されます。
クラスターで異なる DNS サフィックスを使用している場合、Kafka ブローカーとの接続を確立するために、
KUBERNETES_SERVICE_DNS_DOMAIN
環境変数をデフォルトから現在使用中の DNS サフィックスに変更します。STRIMZI_CONNECT_BUILD_TIMEOUT_MS
- 任意設定、デフォルトは 300000 ミリ秒です。追加のコネクターで新しい Kafka Connect イメージをビルドする場合のタイムアウト (ミリ秒単位)。AMQ Streams を使用して多くのコネクターが含まれるコンテナーイメージをビルドしたり、低速なコンテナーレジストリーを使用する場合は、この値を大きくする必要があります。
5.1.1.1. ConfigMap による設定のロギング
Cluster Operator のロギングは strimzi-cluster-operator
ConfigMap
によって設定されます。
ロギング設定を含む ConfigMap
は、Cluster Operator のインストール時に作成されます。この ConfigMap
は、ファイル install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml
に記述されています。Cluster Operator のロギングを設定するには、この ConfigMap
のデータフィールド log4j2.properties
を変更します。
ロギング設定を更新するには、050-ConfigMap-strimzi-cluster-operator.yaml
ファイルを編集して以下のコマンドを実行します。
oc create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml
ConfigMap
を直接編集することもできます。
oc edit cm strimzi-cluster-operator
リロード間隔の頻度を変更するには、作成された ConfigMap
の monitorInterval
オプションで、秒単位の時間を設定します。
Cluster Operator のデプロイ時に ConfigMap
がない場合、デフォルトのロギング値が使用されます。
Cluster Operator のデプロイ後に ConfigMap
が誤って削除された場合、最後にロードされたロギング設定が使用されます。ConfigMap
を新たに作成し、新しいロギング設定を読み込みます。
ConfigMap から monitorInterval
オプションを削除しないでください。
5.1.1.2. ネットワークポリシーによる Cluster Operator アクセスの制限
Cluster Operator は、管理するリソースと同じ namespace または別の namespace で実行できます。デフォルトでは、STRIMZI_OPERATOR_NAMESPACE
環境変数は、OpenShift Downward API を使用して Cluster Operator が稼働している namespace を検索するように設定されます。Cluster Operator がリソースと同じ namespace で実行されている場合は、ローカルアクセスのみが必要で、AMQ Sreams によって許可されます。
Cluster Operator が管理するリソースとは別の namespace で実行されている場合、ネットワークポリシーが設定されている場合を除き、OpenShift クラスターのすべての namespace は Cluster Operator へのアクセスが許可されます。任意の STRIMZI_OPERATOR_NAMESPACE_LABELS
環境変数を使用し、namespace ラベルを使用して Cluster Operator のネットワークポリシーを確立します。namespace ラベルを追加すると、Cluster Operator へのアクセスは指定された namespace に限定されます。
Cluster Operator デプロイメントに設定されたネットワークポリシー
#... env: # ... - name: STRIMZI_OPERATOR_NAMESPACE_LABELS value: label1=value1,label2=value2 #...
5.1.1.3. 定期的な調整
Cluster Operator は OpenShift クラスターから受信する必要なクラスターリソースに関するすべての通知に対応しますが、Operator が実行されていない場合や、何らかの理由で通知が受信されない場合、必要なリソースは実行中の OpenShift クラスターの状態と同期しなくなります。
フェイルオーバーを適切に処理するために、Cluster Operator によって定期的な調整プロセスが実行され、必要なリソースすべてで一貫した状態になるように、必要なリソースの状態を現在のクラスターデプロイメントと比較できます。[STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 変数を使用して、定期的な調整の時間間隔を設定できます。
5.1.2. ロールベースアクセス制御 (RBAC) のプロビジョニング
Cluster Operator が機能するには、Kafka
、KafkaConnect
などのリソースや ConfigMaps
、Pods
、Deployments
、StatefulSets
、および Services
の管理リソースと対話するために OpenShift クラスター内でパーミッションが必要になり ます。このようなパーミッションは、OpenShift のロールベースアクセス制御 (RBAC) リソースに記述されます。
-
ServiceAccount
-
Role
およびClusterRole
-
RoleBinding
およびClusterRoleBinding
Cluster Operator は、ClusterRoleBinding
を使用して独自の ServiceAccount
で実行される他に、OpenShift リソースへのアクセスを必要とするコンポーネントの RBAC リソースを管理します。
また OpenShift には、ServiceAccount
で動作するコンポーネントが、その ServiceAccount
にはない他の ServiceAccounts
の権限を付与しないようにするための特権昇格の保護機能も含まれています。Cluster Operator は、ClusterRoleBindings
と、それが管理するリソースで必要な RoleBindings
を作成できる必要があるため、Cluster Operator にも同じ権限が必要です。
5.1.2.1. 委譲された権限
Cluster Operator が必要な Kafka
リソースのリソースをデプロイする場合、以下のように ServiceAccounts
、RoleBindings
、および ClusterRoleBindings
も作成します。
Kafka ブローカー Pod は
cluster-name-kafka
というServiceAccount
を使用します。-
ラック機能が使用されると、
strimzi-cluster-name-kafka-init
ClusterRoleBinding
は、strimzi-kafka-broker
と呼ばれるClusterRole
経由で、クラスター内のノードへのServiceAccount
アクセスを付与するために使用されます。 - ラック機能が使用されていない場合は、バインディングは作成されません。
-
ラック機能が使用されると、
-
ZooKeeper Pod は
cluster-name-zookeeper
というServiceAccount
を使用します。 Entity Operator は、
cluster-name-entity-operator
というServiceAccount
を使用します。-
Topic Operator はステータス情報のある OpenShift イベントを生成し、
ServiceAccount
がstrimzi-entity-operator
というClusterRole
にバインドされるようにします。strimzi-entity-operator
はこのアクセス権限をstrimzi-entity-operator
RoleBinding
経由で付与します。
-
Topic Operator はステータス情報のある OpenShift イベントを生成し、
-
KafkaConnect
およびKafkaConnectS2I
リソースの Pod はcluster-name-cluster-connect
というServiceAccount
を使用します。 -
KafkaMirrorMaker
の Pod はcluster-name-mirror-maker
というServiceAccount
を使用します。 -
KafkaMirrorMaker2
の Pod はcluster-name-mirrormaker2
というServiceAccount
を使用します。 -
KafkaBridge
の Pod はcluster-name-bridge
というServiceAccount
を使用します。
5.1.2.2. ServiceAccount
Cluster Operator は ServiceAccount
を使用して最適に実行されます。
Cluster Operator の ServiceAccount
の例
apiVersion: v1 kind: ServiceAccount metadata: name: strimzi-cluster-operator labels: app: strimzi
その後、Cluster Operator の Deployment
で、これを spec.template.spec.serviceAccountName
に指定する必要があります。
Cluster Operator の Deployment
の部分的な例
apiVersion: apps/v1 kind: Deployment metadata: name: strimzi-cluster-operator labels: app: strimzi spec: replicas: 1 selector: matchLabels: name: strimzi-cluster-operator strimzi.io/kind: cluster-operator template: # ...
strimzi-cluster-operator
ServiceAccount
が serviceAccountName
として指定されている 12 行目に注目してください。
5.1.2.3. ClusterRoles
Cluster Operator は、必要なリソースへのアクセス権限を付与する ClusterRoles
を使用して操作する必要があります。OpenShift クラスターの設定によっては、クラスター管理者が ClusterRoles
を作成する必要があることがあります。
クラスター管理者の権限は ClusterRoles
の作成にのみ必要です。Cluster Operator はクラスター管理者アカウントで実行されません。
ClusterRoles
は、 最小権限の原則に従い、Kafka、Kafka Connect、および ZooKeeper クラスターを操作するために Cluster Operator が必要とする権限のみが含まれます。最初に割り当てられた一連の権限により、Cluster Operator で StatefulSets
、Deployments
、Pods
、および ConfigMaps
などの OpenShift リソースを管理できます。
Cluster Operator は ClusterRoles を使用して、namespace スコープリソースのレベルおよびクラスタースコープリソースのレベルで権限を付与します。
Cluster Operator の namespaced リソースのある ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-namespaced labels: app: strimzi rules: - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to access and manage rolebindings to grant Strimzi components cluster permissions - rolebindings verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to access and manage roles to grant the entity operator permissions - roles verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: # The cluster operator needs to access and delete pods, this is to allow it to monitor pod health and coordinate rolling updates - pods # The cluster operator needs to access and manage service accounts to grant Strimzi components cluster permissions - serviceaccounts # The cluster operator needs to access and manage config maps for Strimzi components configuration - configmaps # The cluster operator needs to access and manage services and endpoints to expose Strimzi components to network traffic - services - endpoints # The cluster operator needs to access and manage secrets to handle credentials - secrets # The cluster operator needs to access and manage persistent volume claims to bind them to Strimzi components for persistent data - persistentvolumeclaims verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "kafka.strimzi.io" resources: # The cluster operator runs the KafkaAssemblyOperator, which needs to access and manage Kafka resources - kafkas - kafkas/status # The cluster operator runs the KafkaConnectAssemblyOperator, which needs to access and manage KafkaConnect resources - kafkaconnects - kafkaconnects/status # The cluster operator runs the KafkaConnectS2IAssemblyOperator, which needs to access and manage KafkaConnectS2I resources - kafkaconnects2is - kafkaconnects2is/status # The cluster operator runs the KafkaConnectorAssemblyOperator, which needs to access and manage KafkaConnector resources - kafkaconnectors - kafkaconnectors/status # The cluster operator runs the KafkaMirrorMakerAssemblyOperator, which needs to access and manage KafkaMirrorMaker resources - kafkamirrormakers - kafkamirrormakers/status # The cluster operator runs the KafkaBridgeAssemblyOperator, which needs to access and manage BridgeMaker resources - kafkabridges - kafkabridges/status # The cluster operator runs the KafkaMirrorMaker2AssemblyOperator, which needs to access and manage KafkaMirrorMaker2 resources - kafkamirrormaker2s - kafkamirrormaker2s/status # The cluster operator runs the KafkaRebalanceAssemblyOperator, which needs to access and manage KafkaRebalance resources - kafkarebalances - kafkarebalances/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: # The cluster operator needs the extensions api as the operator supports Kubernetes version 1.11+ # apps/v1 was introduced in Kubernetes 1.14 - "extensions" resources: # The cluster operator needs to access and manage deployments to run deployment based Strimzi components - deployments - deployments/scale # The cluster operator needs to access replica sets to manage Strimzi components and to determine error states - replicasets # The cluster operator needs to access and manage replication controllers to manage replicasets - replicationcontrollers # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components - networkpolicies # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "apps" resources: # The cluster operator needs to access and manage deployments to run deployment based Strimzi components - deployments - deployments/scale - deployments/status # The cluster operator needs to access and manage stateful sets to run stateful sets based Strimzi components - statefulsets # The cluster operator needs to access replica-sets to manage Strimzi components and to determine error states - replicasets verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: # The cluster operator needs to be able to create events and delegate permissions to do so - events verbs: - create - apiGroups: # OpenShift S2I requirements - apps.openshift.io resources: - deploymentconfigs - deploymentconfigs/scale - deploymentconfigs/status - deploymentconfigs/finalizers verbs: - get - list - watch - create - delete - patch - update - apiGroups: # OpenShift S2I requirements - build.openshift.io resources: - buildconfigs - buildconfigs/instantiate - builds verbs: - get - list - watch - create - delete - patch - update - apiGroups: # OpenShift S2I requirements - image.openshift.io resources: - imagestreams - imagestreams/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: - networking.k8s.io resources: # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components - networkpolicies # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - route.openshift.io resources: # The cluster operator needs to access and manage routes to expose Strimzi components for external access - routes - routes/custom-host verbs: - get - list - watch - create - delete - patch - update - apiGroups: - policy resources: # The cluster operator needs to access and manage pod disruption budgets this limits the number of concurrent disruptions # that a Strimzi component experiences, allowing for higher availability - poddisruptionbudgets verbs: - get - list - watch - create - delete - patch - update
2 番目の一連の権限には、クラスタースコープリソースに必要な権限が含まれます。
Cluster Operator のクラスタースコープリソースのある ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-global labels: app: strimzi rules: - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to create and manage cluster role bindings in the case of an install where a user # has specified they want their cluster role bindings generated - clusterrolebindings verbs: - get - list - watch - create - delete - patch - update - apiGroups: - storage.k8s.io resources: # The cluster operator requires "get" permissions to view storage class details # This is because only a persistent volume of a supported storage class type can be resized - storageclasses verbs: - get - apiGroups: - "" resources: # The cluster operator requires "list" permissions to view all nodes in a cluster # The listing is used to determine the node addresses when NodePort access is configured # These addresses are then exposed in the custom resource states - nodes verbs: - list
strimzi-kafka-broker
ClusterRole
は、ラック機能に使用される Kafka Pod の init コンテナーが必要とするアクセス権限を表します。「委譲された権限」 で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole
により、OpenShift ノードへのアクセスを Kafka ブローカー Pod に委譲できます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-broker labels: app: strimzi rules: - apiGroups: - "" resources: # The Kafka Brokers require "get" permissions to view the node they are on # This information is used to generate a Rack ID that is used for High Availability configurations - nodes verbs: - get
strimzi-topic-operator
の ClusterRole
は、Topic Operator が必要とするアクセスを表します。「委譲された権限」 で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole
により、イベントへのアクセスを Topic Operator に委譲できます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-entity-operator labels: app: strimzi rules: - apiGroups: - "kafka.strimzi.io" resources: # The entity operator runs the KafkaTopic assembly operator, which needs to access and manage KafkaTopic resources - kafkatopics - kafkatopics/status # The entity operator runs the KafkaUser assembly operator, which needs to access and manage KafkaUser resources - kafkausers - kafkausers/status verbs: - get - list - watch - create - patch - update - delete - apiGroups: - "" resources: - events verbs: # The entity operator needs to be able to create events - create - apiGroups: - "" resources: # The entity operator user-operator needs to access and manage secrets to store generated credentials - secrets verbs: - get - list - watch - create - delete - patch - update
strimzi-kafka-client
ClusterRole
は、クライアントのラックアウェアネスを使用する Kafka クライアントをベースとするコンポーネントが必要なアクセスを表します。「委譲された権限」 で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole
により、OpenShift ノードへのアクセスを Kafka クライアントベースの Pod に委譲できます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-client labels: app: strimzi rules: - apiGroups: - "" resources: # The Kafka clients (Connect, Mirror Maker, etc.) require "get" permissions to view the node they are on # This information is used to generate a Rack ID (client.rack option) that is used for consuming from the closest # replicas when enabled - nodes verbs: - get
5.1.2.4. ClusterRoleBindings
Operator には ClusterRoleBindings
と、ClusterRole
をServiceAccount
に関連付ける RoleBindings
が必要です。ClusterRoleBindings
は、クラスタースコープリロースが含まれる ClusterRoles
に必要です。
Cluster Operator の ClusterRoleBinding
の例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-global apiGroup: rbac.authorization.k8s.io
ClusterRoleBindings
は、委譲に必要な ClusterRoles
にも必要です。
Kafka ブローカーラックアウェアネスの Cluster Operator の ClusterRoleBinding
例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-broker-delegation labels: app: strimzi # The Kafka broker cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Kafka brokers. # This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-broker apiGroup: rbac.authorization.k8s.io
以下も必要です。
Kafka クライアントラックアウェアネスの Cluster Operator の ClusterRoleBinding
例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-client-delegation labels: app: strimzi # The Kafka clients cluster role must be bound to the cluster operator service account so that it can delegate the # cluster role to the Kafka clients using it for consuming from closest replica. # This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-client apiGroup: rbac.authorization.k8s.io
namespaced リソースのみが含まれる ClusterRoles
は、RoleBindings
のみを使用してバインドされます。
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-namespaced apiGroup: rbac.authorization.k8s.io
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator-entity-operator-delegation labels: app: strimzi # The Entity Operator cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Entity Operator. # This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-entity-operator apiGroup: rbac.authorization.k8s.io
5.2. Topic Operator の使用
KafkaTopic
リソースを使用してトピックを作成、編集、または削除する場合、Topic Operator によって変更が確実に Kafka クラスターで反映されます。
『OpenShift での AMQ Streams のデプロイおよびアップグレード』には、Topic Operator をデプロイする手順が記載されています。
5.2.1. Kafka トピックリソース
KafkaTopic
リソースは、パーティションやレプリカの数を含む、トピックの設定に使用されます。
KafkaTopic
の完全なスキーマは、「KafkaTopic
スキーマ参照」で確認できます。
5.2.1.1. トピック処理用の Kafka クラスターの特定
KafkaTopic
リソースには、このリソースが属する Kafka クラスターに適した名前 (Kafka
リソースの名前から派生) を定義するラベルが含まれています。
以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 labels: strimzi.io/cluster: my-cluster
ラベルは、KafkaTopic
リソースを特定し、新しいトピックを作成するために、Topic Operator によって使用されます。また、以降のトピックの処理でも使用されます。
ラベルが Kafka クラスターと一致しない場合、Topic Operator は KafkaTopic
を識別できず、トピックは作成されません。
5.2.1.2. Kafka トピックの使用に関する推奨事項
トピックを使用する場合は、整合性を保ちます。常に KafkaTopic
リソースで作業を行うか、直接 OpenShift でトピックを扱います。特定のトピックで、両方の方法を頻繁に切り替えないでください。
トピックの性質を反映するトピック名を使用し、後で名前を変更できないことに注意してください。
Kafka でトピックを作成する場合は、有効な OpenShift リソース名である名前を使用します。それ以外の場合は、Topic Operator は対応する KafkaTopic
を OpenShift ルールに準じた名前で作成する必要があります。
OpenShift の識別子および名前の推奨事項については、OpenShift コミュニティーの記事「Identifiers and Names」を参照してください。
5.2.1.3. Kafka トピックの命名規則
Kafka と OpenShift では、Kafka と KafkaTopic.metadata.name
でのトピックの命名にそれぞれ独自の検証ルールを適用します。トピックごとに有効な名前があり、他のトピックには無効です。
spec.topicName
プロパティーを使用すると、OpenShift の Kafka トピックでは無効な名前を使用して、Kafka で有効なトピックを作成できます。
spec.topicName
プロパティーは Kafka の命名検証ルールを継承します。
- 249 文字を超える名前は使用できません。
-
Kafka トピックの有効な文字は ASCII 英数字、
.
、_
、および-
です。 -
名前を
.
または..
にすることはできませんが、.
はexampleTopic.
や.exampleTopic
のように名前で使用できます。
spec.topicName
は変更しないでください。
以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
name: topic-name-1
spec:
topicName: topicName-1 1
# ...
- 1
- OpenShift では大文字は無効です。
上記は下記のように変更できません。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 spec: topicName: name-2 # ...
Kafka Streams など一部の Kafka クライアントアプリケーションは、プログラムを使用して Kafka でトピックを作成できます。これらのトピックに、OpenShift リソース名としては無効な名前が付いている場合、Topic Operator はそれらのトピックに Kafka 名に基づく有効な metadata.name
を付けます。無効な文字が置き換えられ、ハッシュが名前に追加されます。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: mytopic---c55e57fe2546a33f9e603caf57165db4072e827e spec: topicName: myTopic # ...
5.2.2. Topic Operator のトピックストア
Topic Operator は Kafka を使用して、トピック設定をキーと値のペアとして記述するトピックメタデータを保存します。トピックストアは、Kafka トピックを使用して状態を永続化する Kafka Streams のキーバリューメカニズムを基にしています。
トピックメタデータはインメモリーでキャッシュされ、Topic Operator 内にてローカルでアクセスされます。ローカルのインメモリーキャッシュに適用される操作からの更新は、ディスク上のバックアップトピックストアに永続化されます。トピックストアは、Kafka トピックまたは OpenShift KafkaTopic
カスタムリソースからの更新と継続的に同期されます。操作は、このような方法で設定されたトピックストアで迅速に処理されますが、インメモリーキャッシュがクラッシュした場合は、永続ストレージから自動的にデータが再入力されます。
5.2.2.1. 内部トピックストアトピック
内部トピックは、トピックストアでのトピックメタデータの処理をサポートします。
__strimzi_store_topic
- トピックメタデータを保存するための入力トピック
__strimzi-topic-operator-kstreams-topic-store-changelog
- 圧縮されたトピックストア値のログの維持
これらのトピックは、Topic Operator の実行に不可欠であるため、削除しないでください。
5.2.2.2. ZooKeeper からのトピックメタデータの移行
これまでのリリースの AMQ Streams では、トピックメタデータは ZooKeeper に保存されていました。新しいプロセスによってこの要件は除外されたため、メタデータは Kafka クラスターに取り込まれ、Topic Operator の制御下となります。
AMQ Streams 1.7 にアップグレードする場合、Topic Operator によってトピックストアが制御されるようにシームレスに移行されます。メタデータは ZooKeeper から検出および移行され、古いストアは削除されます。
5.2.2.3. ZooKeeper を使用してトピックメタデータを保存する AMQ Streams バージョンへのダウングレード
トピックメタデータの保存に ZooKeeper を使用する 0.22 より前のバージョンの AMQ Streams に戻す場合でも、Cluster Operator を前のバージョンにダウングレードしてから、Kafka ブローカーおよびクライアントアプリケーションを前の Kafka バージョンにダウングレードします。
ただし、kafka-admin
コマンドを使用して Kafka クラスターのブートストラップアドレスを指定し、トピックストア用に作成されたトピックを削除する必要もあります。以下に例を示します。
oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete
このコマンドは、Kafka クラスターへのアクセスに使用されるリスナーおよび認証のタイプに対応している必要があります。
Topic Operator は、Kafka のトピックの状態から ZooKeeper トピックメタデータを再構築します。
5.2.2.4. Topic Operator トピックのレプリケーションおよびスケーリング
Topic Operator によって管理されるトピックには、トピックレプリケーション係数を 3 に設定し、最低でも 2 つの In-Sync レプリカを設定することが推奨されます。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: my-topic labels: strimzi.io/cluster: my-cluster spec: partitions: 1 1 replicas: 3 2 config: min.insync.replicas=2 3 #...
In-Sync レプリカは、プロデューサーアプリケーションの acks
設定とともに使用されます。acks
設定は、メッセージの正常受信が確認される前に、メッセージがレプリケートされなければならないフォロワーパーティションの数を決定します。Topic Operator は acks=all
で実行されます。すべての In-Sync レプリカによってメッセージが確認される必要があります。
ブローカーを追加または削除して Kafka クラスターをスケーリングする場合、レプリケーション係数設定は変更されず、レプリカは自動的に再割り当てされません。ただし、kafka-reassign-partitions.sh
ツールを使用してレプリケーション係数を変更し、レプリカをブローカーに手動で再割り当てすることができます。
また、AMQ Streams の Cruise Control の統合ではトピックのレプリケーション係数を変更することはできませんが、Kafka をリバランスするために生成された最適化プロポーザルには、パーティションレプリカを転送し、パーティションリーダーを変更するコマンドが含まれます。
5.2.2.5. トピック変更の処理
Topic Operator にとって解決しなければならない基本的な問題として、信頼できる唯一の情報源 (SSOT: single source of truth) がないことがあります。KafkaTopic
リソースと Kafka トピックの両方とも、Topic Operator に関係なく変更される可能性があります面倒なことに、Topic Operator は KafkaTopic リソースと Kafka トピックで変更を常にリアルタイムで監視できるとは限りません。たとえば、Topic Operator が停止した場合などがこれに該当します。
これを解決するために、Topic Operator はトピックストアの各トピックに関する情報を維持します。Kafka クラスターまたは OpenShift で変更が生じると、他のシステムの状態とトピックストアの両方を確認し、すべての同期が保たれるように何を変更する必要があるかを判断します。同じことが Topic Operator の起動時に必ず実行され、また Topic Operator の稼働中にも定期的に行われます。
たとえば、Topic Operator が実行されていないときに my-topic という KafkaTopic
が作成された場合を考えてみましょう。Topic Operator の起動時、トピックストアには my-topic に関する情報が含まれないため、最後に実行された後に KafkaTopic
が作成されたと推測できます。Topic Operator によって my-topic に対応するトピックが作成され、さらにトピックストアに my-topic のメタデータも格納されます。
Kafka トピック設定を更新するか、KafkaTopic
カスタムリソースで変更を適用する場合、Kafka クラスターの調整後にトピックストアが更新されます。
また、トピックストアは Kafka トピックでトピック設定が変更され、かつ OpenShift KafkaTopic
カスタムリソースで更新される場合に、変更が矛盾しない限り、Topic Operator による管理を可能にします。たとえば、同じトピック設定キーに変更を加えることはできますが、別の値への変更のみが可能です。変更に矛盾がある場合、Kafka の設定が優先され、KafkaTopic
はそれに応じて更新されます。
KafkaTopic
リソースを使用すると、oc delete -f KAFKA-TOPIC-CONFIG-FILE
コマンドを使用してトピックを削除することもできます。これを可能にするには、Kafka リソースの spec.kafka.config
で delete.topic.enable
を true
(デフォルト) に設定する必要があります。
5.2.3. Kafka トピックの設定
KafkaTopic
リソースのプロパティーを使用して Kafka トピックを設定します。
oc apply
を使用すると、トピックを作成または編集できます。oc delete
を使用すると、既存のトピックを削除できます。
以下に例を示します。
-
oc apply -f <topic-config-file>
-
oc delete KafkaTopic <topic-name>
この手順では、10 個のパーティションと 2 つのレプリカがあるトピックを作成する方法を説明します。
作業を開始する前の注意事項
以下を考慮してから変更を行うことが重要になります。
Kafka は
KafkaTopic
リソースによる以下の変更をサポートしません。-
spec.topicName
を使用したトピック名の変更 -
spec.partitions
を使用したパーティションサイズの減少
-
-
spec.replicas
を使用して最初に指定したレプリカの数を変更することはできません。 -
キーのあるトピックの
spec.partitions
を増やすと、レコードをパーティション化する方法が変更されます。これは、トピックがセマンティックパーティションを使用するとき、特に問題になる場合があります。
前提条件
- TLS 認証および暗号化を使用してリスナーで設定された 稼働中の Kafka クラスターが必要です。
- 稼働中の Topic Operator が必要です (通常は Entity Operator でデプロイされます)。
-
トピックを削除する場合は、
Kafka
リソースのspec.kafka.config
がdelete.topic.enable=true
(デフォルト) である必要があります。
手順
作成する
KafkaTopic
が含まれるファイルを準備します。KafkaTopic
の例apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: orders labels: strimzi.io/cluster: my-cluster spec: partitions: 10 replicas: 2
ヒントトピックを変更する場合、現行バージョンのリソースは、
oc get kafkatopic orders -o yaml
を使用して取得できます。OpenShift で
KafkaTopic
リソースを作成します。oc apply -f TOPIC-CONFIG-FILE
5.2.4. リソース要求および制限のある Topic Operator の設定
CPU やメモリーなどのリソースを Topic Operator に割り当て、Topic Operator が消費できるリソースの量に制限を設定できます。
前提条件
- Cluster Operator が稼働している必要があります。
手順
必要に応じてエディターで Kafka クラスター設定を更新します。
oc edit kafka MY-CLUSTER
Kafka
リソースのspec.entityOperator.topicOperator.resources
プロパティーで、Topic Operator のリソース要求および制限を設定します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # Kafka and ZooKeeper sections... entityOperator: topicOperator: resources: requests: cpu: "1" memory: 500Mi limits: cpu: "1" memory: 500Mi
新しい設定を適用してリソースを作成または更新します。
oc apply -f KAFKA-CONFIG-FILE
5.3. User Operator の使用
KafkaUser
リソースを使用してユーザーを作成、編集、または削除する場合、User Operator によって変更が確実に Kafka クラスターで反映されます。
『OpenShift での AMQ Streams のデプロイおよびアップグレード』には、User Operator をデプロイする手順が記載されています。
スキーマの詳細は、「KafkaUser
スキーマ参照」を参照してください。
Kafka へのアクセスの認証および承認
KafkaUser
を使用して、Kafka にアクセスするために特定のクライアントが使用する認証および承認メカニズムを有効にします。
KafkUser
を使用してユーザーを管理し、Kafka ブローカーへのアクセスをセキュアにする方法の詳細は、「Kafka ブローカーへのアクセスのセキュア化」を参照してください。
5.3.1. リソース要求および制限のある User Operator の設定
CPU やメモリーなどのリソースを User Operator に割り当て、User Operator が消費できるリソースの量に制限を設定できます。
前提条件
- Cluster Operator が稼働している必要があります。
手順
必要に応じてエディターで Kafka クラスター設定を更新します。
oc edit kafka MY-CLUSTER
Kafka
リソースのspec.entityOperator.userOperator.resources
プロパティーで、User Operator のリソース要求および制限を設定します。apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # Kafka and ZooKeeper sections... entityOperator: userOperator: resources: requests: cpu: "1" memory: 500Mi limits: cpu: "1" memory: 500Mi
ファイルを保存し、エディターを終了します。Cluster Operator によって変更が自動的に適用されます。
5.4. Prometheus メトリクスを使用した Operator の監視
AMQ Streams の operator は Prometheus メトリクスを公開します。メトリクスは自動で有効になり、以下の情報が含まれます。
- 調整の数
- operator が処理しているカスタムリソースの数
- 調整の期間
- operator からの JVM メトリクス
この他に、Grafana ダッシュボードのサンプルが提供されます。
詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「AMQ Streams のメトリクスおよびダッシュボードの設定」を参照してください。
第6章 Kafka Bridge
本章では、AMQ Streams Kafka Bridge について概説し、その REST API を使用して AMQ Streams と対話するために役立つ情報を提供します。
- ローカル環境で Kafka Bridge を試すには、本章で後述する 「Kafka Bridge クイックスタート」 を参照してください。
- 詳細な設定手順は、「Kafka Bridge クラスターの設定」 を参照してください。
- API ドキュメントは、「Kafka Bridge API reference」を参照してください。
6.1. Kafka Bridge の概要
AMQ Streams Kafka Bridge をインターフェースとして使用し、Kafka クラスターに対して特定タイプの HTTP リクエストを行うことができます。
6.1.1. Kafka Bridge インターフェース
Kafka Bridge では、HTTP ベースのクライアントと Kafka クラスターとの対話を可能にする RESTful インターフェースが提供されます。 また、クライアントアプリケーションによる Kafka プロトコルの変換は必要なく、Web API コネクションの利点が AMQ Streams に提供されます。
API には consumers
と topics
の 2 つの主なリソースがあります。これらのリソースは、Kafka クラスターでコンシューマーおよびプロデューサーと対話するためにエンドポイント経由で公開され、アクセスが可能になります。リソースと関係があるのは Kafka ブリッジのみで、Kafka に直接接続されたコンシューマーやプロデューサーとは関係はありません。
6.1.1.1. HTTP リクエスト
Kafka Bridge は、以下の方法で Kafka クラスターへの HTTP リクエストをサポートします。
- トピックにメッセージを送信する。
- トピックからメッセージを取得する。
- トピックのパーティションリストを取得する。
- コンシューマーを作成および削除する。
- コンシューマーをトピックにサブスクライブし、このようなトピックからメッセージを受信できるようにする。
- コンシューマーがサブスクライブしているトピックの一覧を取得する。
- トピックからコンシューマーのサブスクライブを解除する。
- パーティションをコンシューマーに割り当てる。
- コンシューマーオフセットの一覧をコミットする。
- パーティションで検索して、コンシューマーが最初または最後のオフセットの位置、または指定のオフセットの位置からメッセージを受信できるようにする。
上記の方法で、JSON 応答と HTTP 応答コードのエラー処理を行います。メッセージは JSON またはバイナリー形式で送信できます。
クライアントは、ネイティブの Kafka プロトコルを使用する必要なくメッセージを生成して使用できます。
その他のリソース
- リクエストおよび応答の例など、API ドキュメントを確認するには、『Strimzi Kafka Bridge Documentation 』を参照してください。
6.1.2. Kafka Bridge でサポートされるクライアント
Kafka Bridge を使用して、内部および外部の HTTP クライアントアプリケーションの両方を Kafka クラスターに統合できます。
- 内部クライアント
-
内部クライアントとは、Kafka Bridge 自体と同じ OpenShift クラスターで実行されるコンテナーベースの HTTP クライアントのことです。内部クライアントは、ホストの Kafka Bridge および
KafkaBridge
のカスタムリソースで定義されたポートにアクセスできます。 - 外部クライアント
- 外部クライアントとは、Kafka Bridge がデプロイおよび実行される OpenShift クラスター外部で実行される HTTP クライアントのことです。外部クライアントは、OpenShift Route、ロードバランサーサービス、または Ingress を使用して Kafka Bridge にアクセスできます。
HTTP 内部および外部クライアントの統合
6.1.3. Kafka Bridge のセキュリティー保護
AMQ Streams には、現在 Kafka Bridge の暗号化、認証、または承認は含まれていません。そのため、外部クライアントから Kafka Bridge に送信されるリクエストは以下のようになります。
- 暗号化されず、HTTPS ではなく HTTP を使用する必要がある。
- 認証なしで送信される。
ただし、以下のような他の方法で Kafka Bridge をセキュアにできます。
- Kafka Bridge にアクセスできる Pod を定義する OpenShift ネットワークポリシー。
- 認証または承認によるリバースプロキシー (例: OAuth2 プロキシー)。
- API ゲートウェイ。
- TLS 終端をともなう Ingress または OpenShift ルート。
Kafka Bridge では、Kafka Broker への接続時に TLS 暗号化と、TLS および SASL 認証がサポートされます。OpenShift クラスター内で以下を設定できます。
- Kafka Bridge と Kafka クラスター間の TLS または SASL ベースの認証。
- Kafka Bridge と Kafka クラスター間の TLS 暗号化接続。
詳細は、「Kafka Bridge の設定」 を参照してください。
Kafka ブローカーで ACL を使用することで、Kafka Bridge を使用して消費および生成できるトピックを制限することができます。
6.1.4. OpenShift 外部の Kafka Bridge へのアクセス
デプロイメント後、AMQ Streams Kafka Bridge には同じ OpenShift クラスターで実行しているアプリケーションのみがアクセスできます。これらのアプリケーションは、kafka-bridge-name-bridge-service
サービスを使用して API にアクセスします。
OpenShift クラスター外部で実行しているアプリケーションに Kafka Bridge がアクセスできるようにする場合は、以下の機能のいずれかを使用して Kafka Bridge を手動で公開できます。
- LoadBalancer または NodePort タイプのサービス
- Ingress リソース
- OpenShift ルート
サービスを作成する場合には、selector
で以下のラベルを使用して、サービスがトラフィックをルーティングする Pod を設定します。
# ...
selector:
strimzi.io/cluster: kafka-bridge-name 1
strimzi.io/kind: KafkaBridge
#...
- 1
- OpenShift クラスターでの Kafka Bridge カスタムリソースの名前。
6.1.5. Kafka Bridge へのリクエスト
データ形式と HTTP ヘッダーを指定し、有効なリクエストが Kafka Bridge に送信されるようにします。
6.1.5.1. コンテンツタイプヘッダー
API リクエストおよびレスポンス本文は、常に JSON としてエンコードされます。
コンシューマー操作の実行時に、
POST
リクエストの本文が空でない場合は、以下のContent-Type
ヘッダーが含まれている必要があります。Content-Type: application/vnd.kafka.v2+json
プロデューサー操作の実行時に、
POST
リクエストは、生成されたメッセージの 埋め込みデータ形式 を指定するContent-Type
ヘッダーを提供する必要があります。これは、json
またはbinary
のいずれかになります。埋め込みデータ形式 Content-Type ヘッダー JSON
Content-Type: application/vnd.kafka.json.v2+json
バイナリー
Content-Type: application/vnd.kafka.binary.v2+json
次のセクションで説明どおり、埋め込みデータ形式はコンシューマーごとに設定されます。
POST
リクエストに空のボディーがある場合は、Content-Type
を設定しないでください。空のボディーを使用して、デフォルト値のコンシューマーを作成できます。
6.1.5.2. 埋め込みデータ形式
埋め込みデータ形式は、Kafka メッセージが Kafka Bridge によりプロデューサーからコンシューマーに HTTP で送信される際の形式です。サポートされる埋め込みデータ形式には、JSON とバイナリーの 2 種類があります。
/consumers/groupid
エンドポイントを使用してコンシューマーを作成する場合、POST
リクエスト本文で JSON またはバイナリーいずれかの埋め込みデータ形式を指定する必要があります。これは、以下の例のように format
フィールドで指定します。
{
"name": "my-consumer",
"format": "binary", 1
...
}
- 1
- バイナリー埋め込みデータ形式。
コンシューマーの作成時に指定する埋め込みデータ形式は、コンシューマーが消費する Kafka メッセージのデータ形式と一致する必要があります。
バイナリー埋め込みデータ形式を指定する場合は、以降のプロデューサーリクエストで、リクエスト本文にバイナリーデータが Base64 でエンコードされた文字列として含まれる必要があります。たとえば、/topics/topicname
エンドポイントを使用してメッセージを送信する場合は、records.value
を Base64 でエンコードする必要があります。
{ "records": [ { "key": "my-key", "value": "ZWR3YXJkdGhldGhyZWVsZWdnZWRjYXQ=" }, ] }
プロデューサーリクエストは、埋め込みデータ形式に対応する Content-Type
ヘッダーも提供する必要があります (例: Content-Type: application/vnd.kafka.binary.v2+json
)。
6.1.5.3. メッセージの形式
/topics
エンドポイントを使用してメッセージを送信する場合は、records
パラメーターでリクエストボディーにメッセージペイロードを入力します。
records
パラメーターには、以下のオプションフィールドを含めることができます。
-
メッセージの
headers
-
メッセージの
key
-
メッセージの
value
-
宛先の
partition
トピックへの POST
リクエストの例
curl -X POST \
http://localhost:8080/topics/my-topic \
-H 'content-type: application/vnd.kafka.json.v2+json' \
-d '{
"records": [
{
"key": "my-key",
"value": "sales-lead-0001"
"partition": 2
"headers": [
{
"key": "key1",
"value": "QXBhY2hlIEthZmthIGlzIHRoZSBib21iIQ==" 1
}
]
},
]
}'
- 1
- バイナリー形式のヘッダー値。Base64 としてエンコードされます。
6.1.5.4. Accept ヘッダー
コンシューマーを作成したら、以降のすべての GET リクエストには Accept
ヘッダーが以下のような形式で含まれる必要があります。
Accept: application/vnd.kafka.EMBEDDED-DATA-FORMAT.v2+json
EMBEDDED-DATA-FORMAT
は、json
または binary
のどちらかです。
たとえば、サブスクライブされたコンシューマーのレコードを JSON 埋め込みデータ形式で取得する場合、この Accept ヘッダーが含まれるようにします。
Accept: application/vnd.kafka.json.v2+json
6.1.6. CORS
CORS (Cross-Origin Resource Sharing) を使用すると、Kafka Bridge HTTP の設定 で Kafka クラスターにアクセスするために許可されるメソッドおよび元の URL を指定できます。
Kafka Bridge の CORS 設定例
# ... cors: allowedOrigins: "https://strimzi.io" allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH" # ...
CORS では、異なるドメイン上のオリジンソース間での シンプルな リクエストおよび プリフライト リクエストが可能です。
シンプルなリクエストは、GET
、HEAD
、および POST
メソッドを使用する標準のリクエストに適しています。
プリフライトリクエストは、実際のリクエストが安全に送信できることを確認する最初のチェックとして HTTP OPTIONS リクエストを送信します。確認時に、実際のリクエストが送信されます。プリフライトリクエストは、PUT
および DELETE
などのより安全な手段が必要な方法や標準でないヘッダーを使用する方法に適しています。
すべての要求には、HTTP リクエストのソースであるヘッダーの Origin
値が必要です。
6.1.6.1. シンプルなリクエスト
たとえば、このシンプルなリクエストヘッダーは、オリジンを https://strimzi.io
と指定します。
Origin: https://strimzi.io
ヘッダー情報がリクエストに追加されます。
curl -v -X GET HTTP-ADDRESS/bridge-consumer/records \
-H 'Origin: https://strimzi.io'\
-H 'content-type: application/vnd.kafka.v2+json'
Kafka Bridge からの応答として、Access-Control-Allow-Origin
ヘッダーが返されます。
HTTP/1.1 200 OK
Access-Control-Allow-Origin: * 1
- 1
- 返されたアスタリスク (
*
) は、どのドメインでもリソースにアクセスできることを意味します。
6.1.6.2. プリフライトリクエスト
最初のプリフライトリクエストは、OPTIONS
メソッドを使用して Kafka Bridge に送信されます。HTTP OPTIONS リクエストはヘッダー情報を送信し、Kafka Bridge が実際のリクエストを許可することを確認します。
ここでは、プリフライトリクエストは https://strimzi.io
からの POST
リクエストが有効であることを確認します。
OPTIONS /my-group/instances/my-user/subscription HTTP/1.1 Origin: https://strimzi.io Access-Control-Request-Method: POST 1 Access-Control-Request-Headers: Content-Type 2
プリフライトリクエストのヘッダー情報に OPTIONS
が追加されます。
curl -v -X OPTIONS -H 'Origin: https://strimzi.io' \ -H 'Access-Control-Request-Method: POST' \ -H 'content-type: application/vnd.kafka.v2+json'
Kafka Bridge は最初のリクエストに応答し、リクエストが受け入れられることを確認します。応答ヘッダーは、許可されるオリジン、メソッド、およびヘッダーを返します。
HTTP/1.1 200 OK Access-Control-Allow-Origin: https://strimzi.io Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS,PATCH Access-Control-Allow-Headers: content-type
オリジンまたはメソッドが拒否されると、エラーメッセージが返されます。
プリフライトリクエストで確認されたため、実際のリクエストには Access-Control-Request-Method
ヘッダーは必要ありませんが、オリジンのヘッダーが必要です。
curl -v -X POST HTTP-ADDRESS/topics/bridge-topic \
-H 'Origin: https://strimzi.io' \
-H 'content-type: application/vnd.kafka.v2+json'
応答は、送信元 URL が許可されることを示します。
HTTP/1.1 200 OK Access-Control-Allow-Origin: https://strimzi.io
その他のリソース
Fetch CORS 仕様
6.1.7. Kafka Bridge API リソース
リクエストやレスポンスの例などを含む REST API エンドポイントおよび説明の完全リストは、「Kafka Bridge API reference」を参照してください。
6.1.8. Kafka Bridge デプロイメント
Cluster Operator を使用して、Kafka Bridge を OpenShift クラスターにデプロイします。
Kafka Bridge をデプロイすると、Cluster Operator により OpenShift クラスターに Kafka Bridge オブジェクトが作成されます。オブジェクトには、デプロイメント、サービス、および Pod が含まれ、それぞれ Kafka Bridge のカスタムリソースに付与された名前が付けられます。
その他のリソース
- デプロイメントの手順は『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Kafka Bridge を OpenShift クラスターへデプロイ」を参照してください。
- Kafka Bridge の設定に関する詳細は、「Kafka Bridge クラスターの設定」 を参照してください。
-
KafkaBridge
リソースのホストおよびポートの設定に関する詳細は、「Kafka Bridge の設定」 を参照してください。 - 外部クライアントの統合に関する詳細は、「OpenShift 外部の Kafka Bridge へのアクセス」 を参照してください。
6.2. Kafka Bridge クイックスタート
このクイックスタートを使用して、ローカルの開発環境で AMQ Streams の Kafka Bridge を試すことができます。以下の方法について説明します。
- OpenShift クラスターに Kafka Bridge をデプロイする。
- ポート転送を使用して Kafka Bridge サービスをローカルマシンに公開する。
- Kafka クラスターのトピックおよびパーティションへのメッセージを生成する。
- Kafka Bridge コンシューマーを作成する。
- 基本的なコンシューマー操作を実行する (たとえば、コンシューマーをトピックにサブスクライブする、生成したメッセージを取得するなど)。
このクイックスタートでは、HTTP リクエストはターミナルにコピーおよび貼り付けできる curl コマンドを使用します。OpenShift クラスターへのアクセスが必要になります。ローカルの OpenShift クラスターを実行および管理するには、Minikube、CodeReady Containers、または MiniShift などのツールを使用します。
前提条件を確認し、本章に指定されている順序でタスクを行うようにしてください。
データ形式について
このクイックスタートでは、バイナリーではなく JSON 形式でメッセージを生成および消費します。リクエスト例で使用されるデータ形式および HTTP ヘッダーの詳細は、「Kafka Bridge へのリクエスト」 を参照してください。
クイックスタートの前提条件
- ローカルまたはリモート OpenShift クラスターにアクセスできるクラスター管理者権限が必要です。
- AMQ Streams がインストールされている必要があります。
- Cluster Operator によってデプロイされた稼働中の Kafka クラスターが OpenShift namespace に必要です。
- Entity Operator がデプロイされ、Kafka クラスターの一部として稼働している必要があります。
6.2.1. OpenShift クラスターへの Kafka Bridge のデプロイメント
AMQ Streams には、AMQ Streams Kafka Bridge の設定を指定する YAML サンプルが含まれています。このファイルに最小限の変更を加え、Kafka Bridge のインスタンスを OpenShift クラスターにデプロイします。
手順
examples/bridge/kafka-bridge.yaml
ファイルを編集します。apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: quickstart 1 spec: replicas: 1 bootstrapServers: <cluster-name>-kafka-bootstrap:9092 2 http: port: 8080
Kafka Bridge を OpenShift クラスターにデプロイします。
oc apply -f examples/bridge/kafka-bridge.yaml
quickstart-bridge
デプロイメント、サービス、および他の関連リソースが OpenShift クラスターに作成されます。Kafka Bridge が正常にデプロイされたことを確認します。
oc get deployments
NAME READY UP-TO-DATE AVAILABLE AGE quickstart-bridge 1/1 1 1 34m my-cluster-connect 1/1 1 1 24h my-cluster-entity-operator 1/1 1 1 24h #...
次のステップ
Kafka Bridge を OpenShift クラスターにデプロイしたら、Kafka Bridge サービスをローカルマシンに公開します。
その他のリソース
- Kafka Bridge の設定に関する詳細は、「Kafka Bridge クラスターの設定」 を参照してください。
6.2.2. Kafka Bridge サービスのローカルマシンへの公開
次に、ポート転送を使用して AMQ Streams の Kafka Bridge サービスを http://localhost:8080 上でローカルマシンに公開します。
ポート転送は、開発およびテストの目的でのみ適切です。
手順
OpenShift クラスターの Pod の名前をリストします。
oc get pods -o name pod/kafka-consumer # ... pod/quickstart-bridge-589d78784d-9jcnr pod/strimzi-cluster-operator-76bcf9bc76-8dnfm
ポート
8080
でquickstart-bridge
Pod に接続します。oc port-forward pod/quickstart-bridge-589d78784d-9jcnr 8080:8080 &
注記ローカルマシンのポート 8080 がすでに使用中の場合は、代わりの HTTP ポート (
8008
など) を使用します。
これで、API リクエストがローカルマシンのポート 8080 から Kafka Bridge Pod のポート 8080 に転送されるようになります。
6.2.3. トピックおよびパーティションへのメッセージの作成
次に、topics エンドポイントを使用して、トピックへのメッセージを JSON 形式で生成します。以下に示すように、メッセージの宛先パーティションをリクエスト本文に指定できます。partitions エンドポイントは、全メッセージの単一の宛先パーティションをパスパラメーターとして指定する代替方法を提供します。
手順
テキストエディターを使用して、3 つのパーティションがある Kafka トピックの YAML 定義を作成します。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: bridge-quickstart-topic labels: strimzi.io/cluster: <kafka-cluster-name> 1 spec: partitions: 3 2 replicas: 1 config: retention.ms: 7200000 segment.bytes: 1073741824
-
ファイルを
bridge-quickstart-topic.yaml
としてexamples/topic
ディレクトリーに保存します。 OpenShift クラスターにトピックを作成します。
oc apply -f examples/topic/bridge-quickstart-topic.yaml
Kafka Bridge を使用して、作成したトピックに 3 つのメッセージを生成します。
curl -X POST \ http://localhost:8080/topics/bridge-quickstart-topic \ -H 'content-type: application/vnd.kafka.json.v2+json' \ -d '{ "records": [ { "key": "my-key", "value": "sales-lead-0001" }, { "value": "sales-lead-0002", "partition": 2 }, { "value": "sales-lead-0003" } ] }'
-
sales-lead-0001
は、キーのハッシュに基づいてパーティションに送信されます。 -
sales-lead-0002
は、パーティション 2 に直接送信されます。 -
sales-lead-0003
は、ラウンドロビン方式を使用してbridge-quickstart-topic
トピックのパーティションに送信されます。
-
リクエストが正常に行われると、Kafka Bridge は
offsets
アレイを200
コードとapplication/vnd.kafka.v2+json
のcontent-type
ヘッダーとともに返します。各メッセージで、offsets
アレイは以下を記述します。- メッセージが送信されたパーティション。
パーティションの現在のメッセージオフセット。
応答の例
#... { "offsets":[ { "partition":0, "offset":0 }, { "partition":2, "offset":0 }, { "partition":0, "offset":1 } ] }
次のステップ
トピックおよびパーティションへのメッセージを作成したら、Kafka Bridge コンシューマーを作成します。
その他のリソース
- API リファレンスドキュメントの「POST /topics/{topicname}」
- API リファレンスドキュメントの「POST /topics/{topicname}/partitions/{partitionid}」
6.2.4. Kafka Bridge コンシューマーの作成
Kafka クラスターで何らかのコンシューマー操作を実行するには、まず consumers エンドポイントを使用してコンシューマーを作成する必要があります。コンシューマーは Kafka Bridge コンシューマー と呼ばれます。
手順
bridge-quickstart-consumer-group
という名前の新しいコンシューマーグループに Kafka Bridge コンシューマーを作成します。curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group \ -H 'content-type: application/vnd.kafka.v2+json' \ -d '{ "name": "bridge-quickstart-consumer", "auto.offset.reset": "earliest", "format": "json", "enable.auto.commit": false, "fetch.min.bytes": 512, "consumer.request.timeout.ms": 30000 }'
-
コンシューマーには
bridge-quickstart-consumer
という名前を付け、埋め込みデータ形式はjson
として設定します。 - 一部の基本的な設定が定義されます。
コンシューマーはログへのオフセットに自動でコミットしません。これは、
enable.auto.commit
がfalse
に設定されているからです。このクイックスタートでは、オフセットを跡で手作業でコミットします。リクエストが正常に行われると、Kafka Bridge はレスポンス本文でコンシューマー ID (
instance_id
) とベース URL (base_uri
) を200
コードとともに返します。応答の例
#... { "instance_id": "bridge-quickstart-consumer", "base_uri":"http://<bridge-name>-bridge-service:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer" }
-
コンシューマーには
-
ベース URL (
base_uri
) をコピーし、このクイックスタートの他のコンシューマー操作で使用します。
次のステップ
上記で作成した Kafka Bridge コンシューマーをトピックにサブスクライブできます。
その他のリソース
- API リファレンスドキュメントの「POST /consumers/{groupid}」
6.2.5. Kafka Bridge コンシューマーのトピックへのサブスクライブ
Kafka Bridge コンシューマーを作成したら、subscription エンドポイントを使用して、1 つ以上のトピックにサブスクライブします。サブスクライブすると、コンシューマーはトピックに生成されたすべてのメッセージの受信を開始します。
手順
前述の「トピックおよびパーティションへのメッセージの作成」の手順ですでに作成した
bridge-quickstart-topic
トピックに、コンシューマーをサブスクライブします。curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/subscription \ -H 'content-type: application/vnd.kafka.v2+json' \ -d '{ "topics": [ "bridge-quickstart-topic" ] }'
topics
アレイには、例のような単一のトピック、または複数のトピックを含めることができます。正規表現に一致する複数のトピックにコンシューマーをサブスクライブする場合は、topics
アレイの代わりにtopic_pattern
文字列を使用できます。リクエストが正常に行われると、Kafka Bridge によって
204
(No Content) コードのみが返されます。
次のステップ
Kafka Bridge コンシューマーをトピックにサブスクライブしたら、コンシューマーからメッセージを取得できます。
その他のリソース
- API リファレンスドキュメントの「POST /consumers/{groupid}/instances/{name}/subscription」
6.2.6. Kafka Bridge コンシューマーからの最新メッセージの取得
次に、records エンドポイントからデータをリクエストすることで、Kafka Bridge コンシューマーから最新メッセージを取得します。実稼働環境では、HTTP クライアントはこのエンドポイントを繰り返し (ループで) 呼び出すことができます。
手順
- 「トピックおよびパーティションへのメッセージの生成」の説明に従い、Kafka Bridge コンシューマーに新たなメッセージを生成します。
GET
リクエストをrecords
エンドポイントに送信します。curl -X GET http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/records \ -H 'accept: application/vnd.kafka.json.v2+json'
Kafka Bridge コンシューマーを作成し、サブスクライブすると、最初の GET リクエストによって空のレスポンスが返されます。これは、ポーリング操作がリバランスプロセスを開始してパーティションを割り当てるからです。
手順 2 を繰り返し、Kafka Bridge コンシューマーからメッセージを取得します。
Kafka Bridge は、レスポンス本文でメッセージのアレイ (トピック名、キー、値、パーティション、オフセットの記述) を
200
コードとともに返します。メッセージはデフォルトで最新のオフセットから取得されます。HTTP/1.1 200 OK content-type: application/vnd.kafka.json.v2+json #... [ { "topic":"bridge-quickstart-topic", "key":"my-key", "value":"sales-lead-0001", "partition":0, "offset":0 }, { "topic":"bridge-quickstart-topic", "key":null, "value":"sales-lead-0003", "partition":0, "offset":1 }, #...
注記空のレスポンスが返される場合は、「トピックおよびパーティションへのメッセージの生成」の説明に従い、コンシューマーに対して追加のレコードを生成し、メッセージの取得を再試行します。
次のステップ
Kafka Bridge コンシューマーからメッセージを取得したら、ログへのオフセットをコミットします。
その他のリソース
- API リファレンスドキュメントの「GET /consumers/{groupid}/instances/{name}/records」
6.2.7. ログへのオフセットのコミット
次に、offsets エンドポイントを使用して、Kafka Bridge コンシューマーによって受信されるすべてのメッセージに対して、手動でオフセットをログにコミットします。この操作が必要なのは、前述の「Kafka Bridge コンシューマーの作成」で作成した Kafka Bridge コンシューマー が enable.auto.commit
の設定で false
に指定されているからです。
手順
bridge-quickstart-consumer
のオフセットをログにコミットします。curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/offsets
リクエスト本文は送信されないので、オフセットはコンシューマーによって受信されたすべてのレコードに対してコミットされます。この代わりに、リクエスト本文に、オフセットをコミットするトピックおよびパーティションを指定するアレイ (OffsetCommitSeekList) を含めることができます。
リクエストが正常に行われると、Kafka Bridge は
204
コードのみを返します。
次のステップ
オフセットをログにコミットしたら、オフセットをシークのエンドポイントを試行します。
その他のリソース
- API リファレンスドキュメントの「POST /consumers/{groupid}/instances/{name}/offsets」
6.2.8. パーティションのオフセットのシーク
次に、positions エンドポイントを使用して、Kafka Bridge コンシューマーを設定することで、パーティションのメッセージを特定のオフセットから取得し、さらに最新のオフセットから取得します。これは Apache Kafka では、シーク操作と呼ばれます。
手順
quickstart-bridge-topic
トピックで、パーティション 0 の特定のオフセットをシークします。curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/positions \ -H 'content-type: application/vnd.kafka.v2+json' \ -d '{ "offsets": [ { "topic": "bridge-quickstart-topic", "partition": 0, "offset": 2 } ] }'
リクエストが正常に行われると、Kafka Bridge は
204
コードのみを返します。GET
リクエストをrecords
エンドポイントに送信します。curl -X GET http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/records \ -H 'accept: application/vnd.kafka.json.v2+json'
Kafka Bridge は、シークしたオフセットからのメッセージを返します。
同じパーティションの最後のオフセットをシークし、デフォルトのメッセージ取得動作を復元します。この時点で、positions/end エンドポイントを使用します。
curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/positions/end \ -H 'content-type: application/vnd.kafka.v2+json' \ -d '{ "partitions": [ { "topic": "bridge-quickstart-topic", "partition": 0 } ] }'
リクエストが正常に行われると、Kafka Bridge は別の
204
コードを返します。
また、positions/beginning エンドポイントを使用して、1 つ以上のパーティションの最初のオフセットをシークすることもできます。
次のステップ
このクイックスタートでは、AMQ Streams Kafka Bridge を使用して Kafka クラスターの一般的な操作をいくつか実行しました。これで、すでに作成した Kafka Bridge コンシューマーを削除 できます。
その他のリソース
- API リファレンスドキュメントの「POST /consumers/{groupid}/instances/{name}/positions」
- API リファレンスドキュメントの「POST /consumers/{groupid}/instances/{name}/positions/beginning」
- API リファレンスドキュメントの「POST /consumers/{groupid}/instances/{name}/positions/end」
6.2.9. Kafka Bridge コンシューマーの削除
最後に、このクイックスタートを通して使用した Kafa Bridge コンシューマーを削除します。
手順
DELETE
リクエストを instances エンドポイントに送信し、Kafka Bridge コンシューマーを削除します。curl -X DELETE http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer
リクエストが正常に行われると、Kafka Bridge は
204
コードのみを返します。
その他のリソース
- API リファレンスドキュメントの「DELETE /consumers/{groupid}/instances/{name}」
第7章 3scale での Kafka Bridge の使用
Red Hat 3scale API Management をデプロイし、AMQ Streams の Kafka Bridge と統合できます。
7.1. 3scale での Kafka Bridge の使用
Kafka Bridge のプレーンデプロイメントでは、認証または承認のプロビジョニングがなく、TLS 暗号化による外部クライアントへの接続はサポートされません。
3scale を使用すると、TLS によって Kafka Bridge のセキュリティーが保護され、認証および承認も提供されます。また、3scale との統合により、メトリクス、流量制御、請求などの追加機能も利用できるようになります。
3scale では、AMQ Streams へのアクセスを希望する外部クライアントからのリクエストに対して、各種タイプの認証を使用できます。3scale では、以下のタイプの認証がサポートされます。
- 標準 API キー
- 識別子およびシークレットトークンとして機能する、ランダムな単一文字列またはハッシュ。
- アプリケーション ID とキーのペア
- イミュータブルな識別子およびミュータブルなシークレットキー文字列。
- OpenID Connect
- 委譲された認証のプロトコル。
既存の 3scale デプロイメントを使用する場合
3scale がすでに OpenShift にデプロイされており、Kafka Bridge と併用する場合は、正しく設定されていることを確認してください。
設定については、「Kafka Bridge を使用するための 3scale のデプロイメント」 を参照してください。
7.1.1. Kafka Bridge のサービス検出
3scale は、サービス検出を使用して統合されますが、これには 3scale が AMQ Streams および Kafka Bridge と同じ OpenShift クラスターにデプロイされている必要があります。
AMQ Streams Cluster Operator デプロイメントには、以下の環境変数が設定されている必要があります。
- STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_LABELS
- STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_ANNOTATIONS
Kafka Bridge をデプロイすると、Kafka Bridge の REST インターフェースを公開するサービスは、3scale による検出にアノテーションとラベルを使用します。
-
3scale によって
discovery.3scale.net=true
ラベルが使用され、サービスが検出されます。 - アノテーションによってサービスに関する情報が提供されます。
OpenShift コンソールで設定を確認するには、Kafka Bridge インスタンスの Services に移動します。Annotations に、Kafka Bridge の OpenAPI 仕様へのエンドポイントが表示されます。
7.1.2. 3scale APIcast ゲートウェイポリシー
3scale は 3scale APIcast と併用されます。3scale APIcast は、Kafka Bridge の単一エントリーポイントを提供する 3scale とデプロイされる API ゲートウェイです。
APIcast ポリシーは、ゲートウェイの動作をカスタマイズするメカニズムを提供します。3scale には、ゲートウェイ設定のための標準ポリシーのセットが含まれています。また、独自のポリシーを作成することもできます。
APIcast ポリシーの詳細は、3scale ドキュメントの「API ゲートウェイの管理」を参照してください。
Kafka Bridge の APIcast ポリシー
3scale と Kafka Bridge との統合のポリシー設定例は policies_config.json
ファイルに含まれており、このファイルでは以下を定義します。
- Anonymous Access (匿名アクセス)
- Header Modification (ヘッダー変更)
- Routing (ルーティング)
- URL Rewriting (URL の書き換え)
ゲートウェイポリシーは、このファイルを使用して有効または無効に設定します。
この例をひな形として使用し、独自のポリシーを定義できます。
- Anonymous Access (匿名アクセス)
- Anonymous Access ポリシーでは、認証をせずにサービスが公開され、HTTP クライアントがデフォルトのクレデンシャル (匿名アクセス用) を提供しない場合に、このポリシーによって提供されます。このポリシーは必須ではなく、認証が常に必要であれば無効または削除できます。
- Header Modification (ヘッダー変更)
Header Modification ポリシーを使用すると、既存の HTTP ヘッダーを変更したり、ゲートウェイを通過するリクエストまたはレスポンスへ新規ヘッダーを追加したりすることができます。3scale の統合では、このポリシーによって、HTTP クライアントから Kafka Bridge までゲートウェイを通過するすべてのリクエストにヘッダーが追加されます。
Kafka Bridge は、新規コンシューマー作成のリクエストを受信すると、URI のある
base_uri
フィールドが含まれる JSON ペイロードを返します。コンシューマーは後続のすべてのリクエストにこの URI を使用する必要があります。以下に例を示します。{ "instance_id": "consumer-1", "base_uri":"http://my-bridge:8080/consumers/my-group/instances/consumer1" }
APIcast を使用する場合、クライアントは以降のリクエストをすべてゲートウェイに送信し、Kafka Bridge には直接送信しません。そのため URI には、ゲートウェイの背後にある Kafka Bridge のアドレスではなく、ゲートウェイのホスト名が必要です。
Header Modification ポリシーを使用すると、ヘッダーが HTTP クライアントからリクエストに追加されるので、Kafka Bridge はゲートウェイホスト名を使用します。
たとえば、
Forwarded: host=my-gateway:80;proto=http
ヘッダーを適用すると、Kafka Bridge は以下をコンシューマーに提供します。{ "instance_id": "consumer-1", "base_uri":"http://my-gateway:80/consumers/my-group/instances/consumer1" }
X-Forwarded-Path
ヘッダーには、クライアントからゲートウェイへのリクエストに含まれる元のパスが含まれています。このヘッダーは、ゲートウェイが複数の Kafka Bridge インスタンスをサポートする場合に適用される Routing ポリシーに密接に関連します。- Routing (ルーティング)
Routing ポリシーは、複数の Kafka Bridge インスタンスがある場合に適用されます。コンシューマーが最初に作成された Kafka Bridge インスタンスにリクエストを送信する必要があるため、適切な Kafka Bridge インスタンスにリクエストを転送するようゲートウェイのルートをリクエストに指定する必要があります。
Routing ポリシーは各ブリッジインスタンスに名前を付け、ルーティングはその名前を使用して実行されます。Kafka Bridge のデプロイ時に、
KafkaBridge
カスタムリソースで名前を指定します。たとえば、コンシューマーから以下への各リクエスト (
X-Forwarded-Path
を使用) について考えてみましょう。http://my-gateway:80/my-bridge-1/consumers/my-group/instances/consumer1
この場合、各リクエストは以下に転送されます。
http://my-bridge-1-bridge-service:8080/consumers/my-group/instances/consumer1
URL Rewriting ポリシーはブリッジ名を削除しますが、これは、リクエストをゲートウェイから Kafka Bridge に転送するときにこのポリシーが使用されないからです。
- URL Rewriting (URL の書き換え)
URL Rewiring ポリシーは、ゲートウェイから Kafka Bridge にリクエストが転送されるとき、クライアントから特定の Kafka Bridge インスタンスへのリクエストにブリッジ名が含まれないようにします。
ブリッジ名は、ブリッジが公開するエンドポイントで使用されません。
7.1.3. TLS の検証
TLS の検証用に APIcast を設定できます。これにはテンプレートを使用した APIcast の自己管理によるデプロイメントが必要になります。apicast
サービスがルートとして公開されます。
TLS ポリシーを Kafka Bridge API に適用することもできます。
TLS 設定の詳細は、3scale ドキュメントの「API ゲートウェイの管理」を参照してください。
7.1.4. 3scale ドキュメント
3scale を Kafka Bridge と使用するためにデプロイする手順は、3scale をある程度理解していることを前提としています。
詳細は、3scale の製品ドキュメントを参照してください。
7.2. Kafka Bridge を使用するための 3scale のデプロイメント
3scale を Kafka Bridge で使用するには、まず 3scale をデプロイし、次に Kafka Bridge API の検出を設定します。
また、3scale APIcast および 3scale toolbox も使用します。
- APIcast は、HTTP クライアントが Kafka Bridge API サービスに接続するための NGINX ベースの API ゲートウェイとして、3scale により提供されます。
- 3scale toolbox は設定ツールで、Kafka Bridge サービスの OpenAPI 仕様を 3scale にインポートするために使用されます。
このシナリオでは、AMQ Streams、Kafka、Kafka Bridge、および 3scale/APIcast を、同じ OpenShift クラスターで実行します。
3scale がすでに Kafka Bridge と同じクラスターにデプロイされている場合は、デプロイメントの手順を省略して、現在のデプロイメントを使用できます。
3scale デプロイメントの場合:
- 「Red Hat 3scale API Management Supported Configurations」を確認します。
-
インストールには、
cluster-admin
ロール (system:admin
など) を持つユーザーが必要です。 以下が記述されている JSON ファイルにアクセスできる必要があります。
-
Kafka Bridge OpenAPI 仕様 (
openapiv2.json
) Kafka Bridge のヘッダー変更および Routing ポリシー (
policies_config.json
)GitHub で JSON ファイルを探します。
-
Kafka Bridge OpenAPI 仕様 (
手順
3scale API Management を OpenShift クラスターにデプロイします。
新規プロジェクトを作成するか、または既存プロジェクトを使用します。
oc new-project my-project \ --description="description" --display-name="display_name"
3scale をデプロイします。
「3scale のインストール」 ガイドに記載の情報に従い、テンプレートまたは Operator を使用して OpenShift に 3scale をデプロイします。
どの方法を使用する場合も、WILDCARD_DOMAIN パラメーターが OpenShift クラスターのドメインに設定されていることを確認してください。
3scale 管理ポータルにアクセスするために表示される URL およびクレデンシャルを書き留めておきます。
3scale が Kafka Bridge サービスを検出するように承認を付与します。
oc adm policy add-cluster-role-to-user view system:serviceaccount:my-project:amp
3scale が OpenShift コンソールまたは CLI から Openshift クラスターに正常にデプロイされたことを確認します。
以下に例を示します。
oc get deployment 3scale-operator
3scale toolbox を設定します。
- 『Operating 3scale』 に記載の情報を使用して、3scale toolbox をインストールします。
3scale と対話できるように環境変数を設定します。
export REMOTE_NAME=strimzi-kafka-bridge 1 export SYSTEM_NAME=strimzi_http_bridge_for_apache_kafka 2 export TENANT=strimzi-kafka-bridge-admin 3 export PORTAL_ENDPOINT=$TENANT.3scale.net 4 export TOKEN=3scale access token 5
- 1
REMOTE_NAME
は、3scale 管理ポータルのリモートアドレスに割り当てられた名前です。- 2
SYSTEM_NAME
は、3scale toolbox で OpenAPI 仕様をインポートして作成される 3scale サービス/API の名前です。- 3
TENANT
は、3scale 管理ポータルのテナント名です (https://$TENANT.3scale.net
)。- 4
PORTAL_ENDPOINT
は、3scale 管理ポータルを実行するエンドポイントです。- 5
TOKEN
は、3scale toolbox または HTTP リクエストを介して対話するために 3scale 管理ポータルによって提供されるアクセストークンです。
3scale toolbox のリモート Web アドレスを設定します。
3scale remote add $REMOTE_NAME https://$TOKEN@$PORTAL_ENDPOINT/
これで、toolbox を実行するたびに、3scale 管理ポータルのエンドポイントアドレスを指定する必要がなくなりました。
Cluster Operator デプロイメントに、3scale が Kafka Bridge サービスを検出するために必要なラベルプロパティーおよびアノテーションプロパティーがあることを確認します。
#... env: - name: STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_LABELS value: | discovery.3scale.net=true - name: STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_ANNOTATIONS value: | discovery.3scale.net/scheme=http discovery.3scale.net/port=8080 discovery.3scale.net/path=/ discovery.3scale.net/description-path=/openapi #...
これらのプロパティーがない場合は、OpenShift コンソールからプロパティーを追加するか、Cluster Operator および Kafka Bridge を再デプロイします。
3scale で Kafka Bridge API サービスを検出します。
- 3scale をデプロイしたときに提供されたクレデンシャルを使用して、3scale 管理ポータルにログインします。
- 3scale 管理ポータルから、 → に移動します。ここで、Kafka Bridge サービスが表示されます。
ページを更新して Kafka Bridge サービスを表示することが必要な場合もあります。
ここで、サービスの設定をインポートする必要があります。エディターからインポートしますが、ポータルを開いたまま正常にインポートされたことを確認します。
OpenAPI 仕様 (JSON ファイル) の Host フィールドを編集して、Kafka Bridge サービスのベース URL を使用します。
以下に例を示します。
"host": "my-bridge-bridge-service.my-project.svc.cluster.local:8080"
host
URL に以下が正しく含まれることを確認します。- Kafka Bridge 名 (my-bridge)
- プロジェクト名 (my-project)
- Kafka Bridge のポート (8080)
3scale toolbox を使用して、更新された OpenAPI 仕様をインポートします。
3scale import openapi -k -d $REMOTE_NAME openapiv2.json -t myproject-my-bridge-bridge-service
サービスの Header Modification および Routing ポリシー (JSON ファイル) をインポートします。
3scale で作成したサービスの ID を特定します。
ここでは、`jq` ユーティリティー を使用します。
export SERVICE_ID=$(curl -k -s -X GET "https://$PORTAL_ENDPOINT/admin/api/services.json?access_token=$TOKEN" | jq ".services[] | select(.service.system_name | contains(\"$SYSTEM_NAME\")) | .service.id")
ポリシーをインポートするときにこの ID が必要です。
ポリシーをインポートします。
curl -k -X PUT "https://$PORTAL_ENDPOINT/admin/api/services/$SERVICE_ID/proxy/policies.json" --data "access_token=$TOKEN" --data-urlencode policies_config@policies_config.json
- 3scale 管理ポータルから、 → に移動し、Kafka Bridge サービスのエンドポイントとポリシーが読み込まれていることを確認します。
- アプリケーションプランを作成するために、 → に移動します。
アプリケーションを作成するために、
→ → → に移動します。認証のユーザーキーを取得するためにアプリケーションが必要になります。
実稼働環境用の手順: 実稼働環境のゲートウェイで API を利用可能にするには、設定をプロモートします。
3scale proxy-config promote $REMOTE_NAME $SERVICE_ID
API テストツールを使用して、コンシューマーの作成に呼び出しを使用する APIcast ゲートウェイと、アプリケーションに作成されたユーザーキーで、Kafka Bridge にアクセスできることを検証します。
以下に例を示します。
https//my-project-my-bridge-bridge-service-3scale-apicast-staging.example.com:443/consumers/my-group?user_key=3dfc188650101010ecd7fdc56098ce95
Kafka Bridge からペイロードが返されれば、コンシューマーが正常に作成されています。
{ "instance_id": "consumer1", "base uri": "https//my-project-my-bridge-bridge-service-3scale-apicast-staging.example.com:443/consumers/my-group/instances/consumer1" }
ベース URI は、クライアントが以降のリクエストで使用するアドレスです。
第8章 Cruise Control によるクラスターのリバランス
Cruise Control を AMQ Streams クラスターにデプロイし、Kafka クラスターのリバランスに使用できます。
Cruise Control は、クラスターワークロードの監視、事前定義の制約を基にしたクラスターのリバランス、異常の検出および修正などの Kafka の操作を自動化するオープンソースのシステムです。Cruise Control は Load Monitor、Analyzer、Anomaly Detector、および Executor の主な 4 つのコンポーネントと、クライアントの対話に使用される REST API で構成されます。AMQ Streams は REST API を使用して、以下の Cruise Control 機能をサポートします。
- 複数の最適化ゴールから、最適化プロポーザルを生成します。
- 最適化プロポーザルを基にして Kafka クラスターのリバランスを行います。
異常検出、通知、独自ゴールの作成、トピックレプリケーション係数の変更などの、その他の Cruise Control の機能は現在サポートされていません。
Cruise Control の サンプル YAML ファイルは、examples/cruise-control/
にあります。
8.1. Cruise Control とは
Cruise Control は、分散された Kafka クラスターを効率的に実行するための時間および労力を削減します。
通常、クラスターの負荷は時間とともに不均等になります。大量のメッセージトラフィックを処理するパーティションは、使用可能なブローカー全体で不均等に分散される可能性があります。クラスターを再分散するには、管理者はブローカーの負荷を監視し、トラフィックの多いパーティションを容量に余裕のあるブローカーに手作業で再割り当てします。
Cruise Control はクラスターのリバランス処理を自動化します。CPU、ディスク、およびネットワーク負荷を基にして、クラスターにおけるリソース使用のワークロードモデルを構築し、パーティションの割り当てをより均等にする、最適化プロポーザル (承認または拒否可能) を生成します。これらのプロポーザルの算出には、設定可能な最適化ゴールが複数使用されます。
最適化プロポーザルを承認すると、Cruise Control はそのプロポーザルを Kafka クラスターに適用します。クラスターのリバランス操作が完了すると、ブローカー Pod はより効率的に使用され、Kafka クラスターはより均等に分散されます。
その他のリソース
8.2. 最適化ゴールの概要
Cruise Control は Kafka クラスターをリバランスするために、最適化ゴールを使用して、承認または拒否可能な最適化プロポーザルを生成します。
最適化ゴールは、Kafka クラスター全体のワークロード再分散およびリソース使用の制約です。AMQ Streams は、Cruise Control プロジェクトで開発された最適化ゴールのほとんどをサポートします。以下に、サポートされるゴールをデフォルトの優先度順に示します。
- ラックアウェアネス (Rack Awareness)
- トピックのセットに対するブローカーごとのリーダーレプリカの最小数
- レプリカの容量
- 容量: ディスク容量、ネットワークインバウンド容量、ネットワークアウトバウンド容量、CPU 容量
- レプリカの分散
- 潜在的なネットワーク出力
リソース分散: ディスク使用率の分散、ネットワークインバウンド使用率の分散、ネットワークアウトバウンド使用率の分散、CPU 使用率の分散。
注記リソース分散ゴールは、ブローカーリソースで 容量制限 を使用して制御されます。
- リーダーへの単位時間あたりバイト流入量の分散
- トピックレプリカの分散
- リーダーレプリカの分散
- 優先リーダーの選択
各最適化ゴールの詳細は、Cruise Control Wiki の「Goals」を参照してください。
ブローカー内ディスクゴール、独自のゴール、および Kafka アサイナーゴールはサポートされていません。
AMQ Streams カスタムリソースでのゴールの設定
Kafka
および KafkaRebalance
カスタムリソースで最適化ゴールを設定します。Cruise Control には、必ず満たさなければならない ハード 最適化ゴールの設定と、マスター、デフォルト、およびユーザー提供最適化ゴールの設定があります。リソースディストリビューションの最適化ゴール (ディスク、ネットワークインバウンド、ネットワークアウトバウンド、および CPU) は、ブローカーリソースの 容量制限 の対象となります。
以下のセクションでは、各ゴール設定の詳細を説明します。
ハードゴールおよびソフトゴール
ハードゴールは最適化プロポーザルで必ず満たさなければならないゴールです。ハードゴールとして設定されていないゴールはソフトゴールと呼ばれます。ソフトゴールは ベストエフォート 型のゴールと解釈できます。最適化プロポーザルで満たす必要はありませんが、最適化の計算に含まれます。すべてのハードゴールを満たし、1 つ以上のソフトゴールに違反する最適化プロポーザルは有効です。
Cruise Control は、すべてのハードゴールを満たし、優先度順にできるだけ多くのソフトゴールを満たす最適化プロポーザルを算出します。すべてのハードゴールを満たさない最適化プロポーザルは Cruise Control によって拒否され、ユーザーには送信されません。
たとえば、クラスター全体でトピックのレプリカを均等に分散するソフトゴールがあるとします (トピックレプリカ分散のゴール)。このソフトゴールを無視すると、設定されたハードゴールがすべて有効になる場合、Cruise Control はこのソフトゴールを無視します。
Cruise Control では、以下のマスター最適化ゴールがハードゴールとして事前設定されています。
RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal
Kafka.spec.cruiseControl.config
の hard.goals
プロパティーを編集し、Cruise Control のデプロイメント設定でハードゴールを設定します。
-
Cruise Control から事前設定されたハードゴールを継承する場合は、
Kafka.spec.cruiseControl.config
にhard.goals
プロパティーを指定しないでください。 -
事前設定されたハードゴールを変更するには、完全修飾ドメイン名を使用して、希望のゴールを
hard.goals
プロパティーに指定します。
ハード最適化ゴールの Kafka
設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: topicOperator: {} userOperator: {} cruiseControl: brokerCapacity: inboundNetwork: 10000KB/s outboundNetwork: 10000KB/s config: hard.goals: > com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal, com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal # ...
ハードゴールの数を増やすと、Cruise Control が有効な最適化プロポーザルを生成する可能性が低くなります。
skipHardGoalCheck: true
が KafkaRebalance
カスタムリソースに指定された場合、Cruise Control はユーザー提供の最適化ゴールのリスト (KafkaRebalance.spec.goals
内) に設定済みのハードゴール (hard.goals
) がすべて含まれていることをチェックしません。そのため、すべてではなく一部のユーザー提供の最適化ゴールが hard.goals
リストにある場合、skipHardGoalCheck: true
が指定されていてもハードゴールとして処理されます。
マスター最適化ゴール
マスター最適化ゴールはすべてのユーザーが使用できます。マスター最適化ゴールにリストされていないゴールは、Cruise Control 操作で使用できません。
Cruise Control の デプロイメント設定を変更しない限り、AMQ Streams は以下のマスター最適化ゴールを優先度順 (降順) に Cruise Control から継承します。
RackAwareGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal; PreferredLeaderElectionGoal
これらのゴールの 6 個が ハードゴール として事前設定されます。
複雑さを軽減するため、1 つ以上のゴールを KafkaRebalance
リソースでの使用から完全に除外する必要がある場合を除き、継承されるマスター最適化ゴールを使用することが推奨されます。必要な場合、マスター最適化ゴールの優先順位は デフォルトの最適化ゴール の設定で変更できます。
マスター最適化ゴールは、必要であれば Cruise Control のデプロイメント設定である Kafka.spec.cruiseControl.config.goals
で設定できます。
-
継承されたマスター最適化ゴールを許可する場合は、
goals
プロパティーをKafka.spec.cruiseControl.config
に指定しないでください。 -
継承されたマスター最適化ゴールを変更する必要がある場合は、
goals
設定オプションにゴールのリストを優先度が高いものから順に指定します。
継承されたマスター最適化ゴールを変更する場合、Kafka.spec.cruiseControl.config
の hard.goals
プロパティーに設定されたハードゴールがあれば、必ず設定したマスター継承ゴールのサブセットになるように確認してください。そうでないと、最適化プロポーザルの生成時にエラーが発生します。
デフォルトの最適化ゴール
Cruise Conrol はデフォルトの最適化ゴール を使用して キャッシュされた最適化プロポーザル を生成します。キャッシュされた最適化プロポーザルの詳細は、「最適化プロポーザルの概要」 を参照してください。
ユーザー提供の最適化ゴール を KafkaRebalance
カスタムリソースに設定すると、デフォルトの最適化ゴールを上書きできます。
Cruise Control のデプロイメント設定に default.goals
を指定しない限り、マスター最適化ゴールがデフォルトの最適化ゴールとして使用されます。この場合、マスター最適化ゴールを使用して、キャッシュされた最適化プロポーザルが生成されます。
-
マスター最適化ゴールをデフォルトのゴールとして使用する場合は、
default.goals
プロパティーをKafka.spec.cruiseControl.config
に指定しないでください。 -
デフォルトの最適化ゴールを編集するには、
Kafka.spec.cruiseControl.config
のdefault.goals
プロパティーを編集します。マスター最適化ゴールのサブセットを使用する必要があります。
デフォルト最適化ゴールの Kafka
設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: topicOperator: {} userOperator: {} cruiseControl: brokerCapacity: inboundNetwork: 10000KB/s outboundNetwork: 10000KB/s config: default.goals: > com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal, com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal, com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal # ...
デフォルトの最適化ゴールの指定がない場合、マスター最適化ゴールを使用して、キャッシュされたプロポーザルが生成されます。
ユーザー提供の最適化ゴール
ユーザー提供の最適化ゴールは、特定の最適化プロポーザルの設定済みのデフォルトゴールを絞り込みます。必要に応じて、KafkaRebalance
カスタムリソースの spec.goals
で設定できます。
KafkaRebalance.spec.goals
ユーザー提供の最適化ゴールは、さまざまな状況の最適化プロポーザルを生成できます。たとえば、ディスクの容量やディスクの使用率を考慮せずに、Kafka クラスター全体でリーダーレプリカの分散を最適化したい場合があります。この場合、リーダーレプリカ分散の単一のユーザー提供ゴールが含まれる KafkaRebalance
カスタムリソースを作成します。
ユーザー提供の最適化ゴールには以下が必要になります。
- 設定済みのハードゴールがすべて含まれるようにする必要があります。そうでないと、エラーが発生します。
- マスター最適化ゴールのサブセットである必要があります。
最適化プロポーザルの生成時に設定済みのハードゴールを無視するには、skipHardGoalCheck: true
プロパティーを KafkaRebalance
カスタムリソースに追加します。「最適化プロポーザルの生成」 を参照してください。
その他のリソース
- 「Cruise Control の設定」
- Cruise Control Wiki の「Configurations」
8.3. 最適化プロポーザルの概要
最適化プロポーザルは、パーティションのワークロードをブローカー間でより均等に分散することで、Kafka クラスターの負荷をより均等にするために提案された変更の概要です各最適化プロポーザルは、そのプロポーザルの生成に使用された 最適化ゴール のセットが基になっており、ブローカーリソースの設定済みの容量制限 の対象になります。
最適化プロポーザルは KafkaRebalance
カスタムリソースの Status.Optimization Result
プロパティーに含まれます。提供される情報は完全な最適化プロポーザルの概要になります。概要を使用して以下を決定します。
- 最適化プロポーザルの承認。プロポーザルを Kafka クラスターに適用し、クラスターリバランス操作を開始するよう Cruise Control が指示されます。
- 最適化プロポーザルの拒否。最適化ゴールを変更し、別のプロポーザルを生成できます。
最適化プロポーザルはすべてドライランです。最適化プロポーザルを最初に生成しないと、クラスターのリバランスを承認できません。生成できる最適化プロポーザルの数に制限はありません。
キャッシュされた最適化プロポーザル
Cruise Control は、設定済みのデフォルト最適化ゴールを基にして キャッシュされた最適化プロポーザル を維持します。キャッシュされた最適化プロポーザルはワークロードモデルから生成され、Kafka クラスターの現在の状況を反映するために 15 分ごとに更新されます。デフォルトの最適化ゴールを使用して最適化プロポーザルを生成する場合、Cruise Control は最新のキャッシュされたプロポーザルを返します。
キャッシュされた最適化プロポーザルの更新間隔を変更するには、Cruise Control デプロイメント設定の proposal.expiration.ms
設定を編集します。更新間隔を短くすると、Cruise Control サーバーの負荷が増えますが、変更が頻繁に行われるクラスターでは、更新間隔を短くするよう考慮してください。
最適化プロポーザルの内容
以下の表は、最適化プロポーザルに含まれるプロパティーを表しています。
JSON プロパティー | 説明 |
---|---|
| ディスクとクラスターのブローカーとの間で転送されるパーティションレプリカの合計数。
リバランス操作中のパフォーマンスへの影響度: 比較的高いが、 |
| サポートされていません。空のリストが返されます。 |
| 個別のブローカー間で移動されるパーティションレプリカの数。 リバランス操作中のパフォーマンスへの影響度: 比較的高い。 |
| 最適化プロポーザルの生成前および生成後における、Kafka クラスターの全体的な 分散度 (balancedness) の値。
スコアは、違反した各ソフトゴールの
|
|
同じブローカーのディスク間で移動される各パーティションレプリカのサイズの合計 (
リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。大量のデータを移動する場合、同じブローカーのディスク間で移動する方が個別のブローカー間で移動するよりも影響度が低くなります ( |
| 最適化プロポーザルの基になるメトリクスウインドウの数。 |
|
個別のブローカーに移動される各パーティションレプリカのサイズの合計 ( リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。 |
|
最適化プロポーザルの対象となる Kafka クラスターのパーティションの割合 (パーセント)。 |
|
|
| リーダーが別のレプリカに切り替えられるパーティションの数。ZooKeeper 設定の変更を伴います。 リバランス操作中のパフォーマンスへの影響度: 比較的低い。 |
| サポートされていません。空のリストが返されます。 |
その他のリソース
8.4. リバランスパフォーマンスチューニングの概要
クラスターリバランスのパフォーマンスチューニングオプションを調整できます。これらのオプションは、リバランスのパーティションレプリカおよびリーダーシップの移動が実行される方法を制御し、また、リバランス操作に割り当てられた帯域幅も制御します。
パーティション再割り当てコマンド
最適化プロポーザル は、個別のパーティション再割り当てコマンドで構成されています。プロポーザルを 承認 すると、Cruise Control サーバーはこれらのコマンドを Kafka クラスターに適用します。
パーティション再割り当てコマンドは、以下のいずれかの操作で構成されます。
パーティションの移動: パーティションレプリカとそのデータを新しい場所に転送します。パーティションの移動は、以下の 2 つの形式のいずれかになります。
- ブローカー間の移動: パーティションレプリカを、別のブローカーのログディレクトリーに移動します。
- ブローカー内の移動: パーティションレプリカを、同じブローカーの異なるログディレクトリーに移動します。
- リーダーシップの移動: パーティションのレプリカのリーダーを切り替えます。
Cruise Control によって、パーティション再割り当てコマンドがバッチで Kafka クラスターに発行されます。リバランス中のクラスターのパフォーマンスは、各バッチに含まれる各タイプの移動数に影響されます。
レプリカの移動ストラテジー
クラスターリバランスのパフォーマンスは、パーティション再割り当てコマンドのバッチに適用される レプリカ移動ストラテジー の影響も受けます。デフォルトでは、Cruise Control は BaseReplicaMovementStrategy
を使用します。これは、生成された順序でコマンドを適用します。ただし、プロポーザルの初期に非常に大きなパーティションの再割り当てがある場合、このストラテジーによって他の再割り当ての適用が遅くなる可能性があります。
Cruise Control は、最適化プロポーザルに適用できる代替のレプリカ移動ストラテジーを 3 つ提供します。
-
PrioritizeSmallReplicaMovementStrategy
: サイズの昇順で再割り当てを並べ替えます。 -
PrioritizeLargeReplicaMovementStrategy
: サイズの降順で再割り当てを並べ替えます。 -
PostponeUrpReplicaMovementStrategy
: 非同期のレプリカがないパーティションのレプリカの再割り当てを優先します。
これらのストラテジーをシーケンスとして設定できます。最初のストラテジーは、内部ロジックを使用して 2 つのパーティション再割り当ての比較を試みます。再割り当てが同等である場合は、順番を決定するために再割り当てをシーケンスの次のストラテジーに渡します。
リバランスチューニングオプション
Cruise Control には、上記のリバランスパラメーターを調整する設定オプションが複数あります。これらのチューニングオプションは、Cruise Control サーバー または 最適化プロポーザル レベルのいずれかに設定できます。
-
Cruise Control のサーバー設定は、
Kafka.spec.cruiseControl.config
の Kafka カスタムリソースで設定できます。 -
個別のリバランスパフォーマンス設定は、
KafkaRebalance.spec
で設定できます。
関連する設定の概要を以下に示します。
サーバーおよび KafkaRebalance の設定 | 説明 | デフォルト値 |
---|---|---|
| 各パーティション再割り当てバッチでのブローカー間パーティション移動の最大数。 | 5 |
| ||
| 各パーティション再割り当てバッチでのブローカー内パーティション移動の最大数。 | 2 |
| ||
| 各パーティション再割り当てバッチにおけるパーティションリーダー変更の最大数。 | 1000 |
| ||
| パーティションの再割り当てに割り当てられる帯域幅 (バイト/秒単位)。 | 制限なし |
| ||
| パーティション再割り当てコマンドが、生成されたプロポーザルに対して実行される順番を決定するために使用されるストラテジー (優先順位順) の一覧。
サーバー設定で、ストラテジークラスの完全修飾名にコンマ区切りの文字列を使用します (各クラス名の先頭に |
|
|
デフォルト設定を変更すると、リバランスの完了までにかかる時間と、リバランス中の Kafka クラスターの負荷に影響します。値を小さくすると負荷は減りますが、かかる時間は長くなり、その逆も同様です。
8.5. Cruise Control の設定
Kafka.spec.cruiseControl
の config
プロパティーには設定オプションがキーとして含まれ、それらの値は以下の JSON タイプの 1 つになります。
- 文字列
- 数値
- ブール値
AMQ Streams によって直接管理されるオプション以外は、Cruise Control ドキュメント の「Configurations」セクションにリストされているすべてのオプションを指定および設定できます。ここに示されているキーの 1 つと同等の設定オプションまたはキーの 1 つで始まる設定オプションは、編集できません。
制限されたオプションが指定された場合、そのオプションは無視され、警告メッセージが Cluster Operator のログファイルに出力されます。すべてのサポートされるオプションは Cruise Control に渡されます。
Cruise Control の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... cruiseControl: # ... config: default.goals: > com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal, com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal cpu.balance.threshold: 1.1 metadata.max.age.ms: 300000 send.buffer.bytes: 131072 # ...
CORS (Corss-Origin Resource Sharing) の設定
CORS (Cross-Origin Resource Sharing) を使用すると、REST API へのアクセスに許可されるメソッドおよびアクセス元 URL を指定できます。
デフォルトでは、Cruise Control REST API の CORS は無効になっています。有効にすると、Kafka クラスターの状態の読み取り専用アクセスを要求する GET
リクエストのみが許可されます。そのため、AMQ Streams コンポーネントとは異なるオリジンで実行されている外部アプリケーションは、Cruise Control API に POST
リクエストを送信できません。ただし、これらのアプリケーションは、現在のクラスターの負荷や最新の最適化プロポーザルなどの、Kafka クラスターに関する読み取り専用の情報へアクセスするための GET
リクエストを送信できます。
Cruise Control の CORS の有効化
Kafka.spec.cruiseControl.config
で CORS を有効化および設定します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... cruiseControl: # ... config: webserver.http.cors.enabled: true webserver.http.cors.origin: "*" webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type" # ...
詳細は、Cruise Control Wiki の「REST APIs」を参照してください。
容量の設定
Cruise Control は 容量制限 を使用して、リソース分散の最適化ゴールが破損しているかどうかを判断します。このタイプには 4 つのゴールがあります。
-
DiskUsageDistributionGoal
: ディスク使用率の分散 -
CpuUsageDistributionGoal
: CPU 使用率の分散 -
NetworkInboundUsageDistributionGoal
: ネットワークインバウンド使用率の分散 -
NetworkOutboundUsageDistributionGoal
: ネットワークアウトバウンド使用率の分散
Kafka ブローカーリソースの容量制限は、Kafka.spec.cruiseControl
の brokerCapacity
プロパティーに指定します。これらはデフォルトで有効になっており、デフォルト値を変更できます。容量制限は、標準の OpenShift バイト単位 (K、M、G、および T) または同等 (2 のべき乗) の bibyte (Ki、Mi、Gi、および Ti) を使用して、以下のブローカーリソースに設定できます。
-
disk
- ブローカーごとのディスクストレージ (デフォルトは 100000Mi) -
cpuUtilization
- パーセントで表した CPU 使用率 (デフォルトは 100) -
inboundNetwork
- バイト毎秒単位のインバウンドネットワークスループット (デフォルトは 10000KiB/s) -
outboundNetwork
- バイト毎秒単位のアウトバウンドネットワークスループット (デフォルトは 10000KiB/s)
AMQ Streams の Kafka ブーカーは同種であるため、Cruise Control は監視している各ブローカーに同じ容量制限を適用します。
bibyte 単位での Cruise Control brokerCapacity の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... cruiseControl: # ... brokerCapacity: disk: 100Gi cpuUtilization: 100 inboundNetwork: 10000KiB/s outboundNetwork: 10000KiB/s # ...
その他のリソース
詳細は 「BrokerCapacity
スキーマ参照」 を参照してください。
ロギングの設定
Cruise Control には独自の設定可能なロガーがあります。
-
rootLogger.level
Cruise Control では Apache log4j 2
ロガー実装が使用されます。
logging
プロパティーを使用してロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka # ... spec: cruiseControl: # ... logging: type: inline loggers: rootLogger.level: "INFO" # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka # ... spec: cruiseControl: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: cruise-control-log4j.properties # ...
8.6. Cruise Control のデプロイ
Cruise Control を AMQ Streams クラスターにデプロイするいは、Kafka
リソースの cruiseControl
プロパティーを使用して設定を定義した後、リソースを作成または更新します。
Kafka クラスターごとに Cruise Control のインスタンスを 1 つデプロイします。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
Kafka
リソースを編集し、cruiseControl
プロパティーを追加します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... cruiseControl: brokerCapacity: 1 inboundNetwork: 10000KB/s outboundNetwork: 10000KB/s # ... config: 2 default.goals: > com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal, com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal # ... cpu.balance.threshold: 1.1 metadata.max.age.ms: 300000 send.buffer.bytes: 131072 # ... resources: 3 requests: cpu: 1 memory: 512Mi limits: cpu: 2 memory: 2Gi logging: 4 type: inline loggers: rootLogger.level: "INFO" template: 5 pod: metadata: labels: label1: value1 securityContext: runAsUser: 1000001 fsGroup: 0 terminationGracePeriodSeconds: 120 readinessProbe: 6 initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: 7 initialDelaySeconds: 15 timeoutSeconds: 5 # ...
- 1
- ブローカーリソースの容量制限を指定します。詳細は、容量の設定 を参照してください。
- 2
- Cruise Control 設定を定義します。これには、デフォルトの最適化ゴール (
default.goals
で設定) が含まれ、マスター最適化ゴール (goals
で設定) またはハードゴール (hard.goals
で設定) へのカスタマイズも含まれまもす。AMQ Streams によって直接管理されるものを除き、標準の Cruise Cntrol 設定オプション をすべて提供できます。最適化ゴールの設定に関する詳細は、「最適化ゴールの概要」 を参照してください。 - 3
- Cruise Control によって予約された CPU およびメモリーリソース。詳細は、「
resources
」 を参照してください。 - 4
- ConfigMap より直接的 (inline) または間接的 (external) に追加されたロガーおよびログレベルを定義します。カスタム ConfigMap は、log4j.properties キー下に配置する必要があります。Cruise Control には
rootLogger.level
という名前の単一のロガーがあります。ログレベルは INFO、ERROR、WARN、TRACE、DEBUG、FATAL、または OFF に設定できます。詳細は、「ロギングの設定」を参照してください。 - 5
- 6
- 7
リソースを作成または更新します。
oc apply -f kafka.yaml
Cruise Control が正常にデプロイされたことを確認します。
oc get deployments -l app.kubernetes.io/name=cruise-control
自動作成されたトピック
以下の表は、Cruise Control のデプロイ時に自動作成される 3 つのトピックを表しています。これらのトピックは、Cruise Control が適切に動作するために必要であるため、削除または変更しないでください。
自動作成されたトピック | 作成元 | 機能 |
---|---|---|
| AMQ Streams の Metrics Reporter | Metrics Reporter からの raw メトリクスを各 Kafka ブローカーに格納します。 |
| Cruise Control | 各パーティションの派生されたメトリクスを格納します。これらは Metric Sample Aggregator によって作成されます。 |
| Cruise Control | クラスターワークロードモデル の作成に使用されるメトリクスサンプルを格納します。 |
Cruise Control に必要なレコードを削除しないようにするため、自動作成されたトピックではログの圧縮は無効になっています。
次のステップ
Cruise Control を設定およびデプロイした後、最適化プロポーザルを生成できます。
その他のリソース
8.7. 最適化プロポーザルの生成
KafkaRebalance
リソースを作成または更新すると、Cruise Control は 設定済みの最適化ゴールを基にして、Kafka クラスターの 最適化プロポーザル を生成します。
最適化プロポーザルの情報を分析して、プロポーザルを承認するかどうかを決定します。
前提条件
- AMQ Streams クラスターに Cruise Control がデプロイされている 必要があります。
- 最適化ゴール が設定され、任意で ブローカーリソースに容量制限 が設定されている必要があります。
手順
KafkaRebalance
リソースを作成します。Kafka
リソースに定義された デフォルトの最適化ゴール を使用するには、spec
プロパティーを空のままにします。apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: name: my-rebalance labels: strimzi.io/cluster: my-cluster spec: {}
デフォルトのゴールを使用する代わりに ユーザー定義の最適化ゴール を設定するには、
goals
プロパティーを追加し、1 つ以上のゴールを入力します。以下の例では、ラックアウェアネス (Rack Awareness) およびレプリカの容量はユーザー定義の最適化ゴールとして設定されています。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: name: my-rebalance labels: strimzi.io/cluster: my-cluster spec: goals: - RackAwareGoal - ReplicaCapacityGoal
設定済みのハードゴールを無視するには、
skipHardGoalCheck: true
プロパティーを追加します。apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: name: my-rebalance labels: strimzi.io/cluster: my-cluster spec: goals: - RackAwareGoal - ReplicaCapacityGoal skipHardGoalCheck: true
リソースを作成または更新します。
oc apply -f your-file
Cluster Operator は Cruise Control から最適化プロポーザルを要求します。Kafka クラスターのサイズによっては処理に数分かかることがあります。
KafkaRebalance
リソースのステータスを確認します。oc describe kafkarebalance rebalance-cr-name
Cruise Control は以下の 2 つの状態の 1 つを返します。
-
PendingProposal
: 最適化プロポーザルが準備できているかどうかを確認するために、リバランス operator が Cruise Control API をポーリングしています。 -
ProposalReady
: 最適化プロポーザルを確認し、希望する場合は承認することができます。最適化プロポーザルはKafkaRebalance
リソースのStatus.Optimization Result
プロパティーに含まれます。
-
最適化プロポーザルを確認します。
oc describe kafkarebalance rebalance-cr-name
以下はプロポーザルの例になります。
Status: Conditions: Last Transition Time: 2020-05-19T13:50:12.533Z Status: ProposalReady Type: State Observed Generation: 1 Optimization Result: Data To Move MB: 0 Excluded Brokers For Leadership: Excluded Brokers For Replica Move: Excluded Topics: Intra Broker Data To Move MB: 0 Monitored Partitions Percentage: 100 Num Intra Broker Replica Movements: 0 Num Leader Movements: 0 Num Replica Movements: 26 On Demand Balancedness Score After: 81.8666802863978 On Demand Balancedness Score Before: 78.01176356230222 Recent Windows: 1 Session Id: 05539377-ca7b-45ef-b359-e13564f1458c
Optimization Result
セクションのプロパティーには、保留クラスターリバランス操作の詳細が表示されます。各プロパティーの説明は、「最適化プロポーザルの内容」を参照してください。
次のステップ
その他のリソース
8.8. 最適化プロポーザルの承認
状態が ProposalReady
の場合、Cruise Control によって生成された最適化プロポーザルを承認できます。その後、Cruise Control は最適化プロポーザルを Kafka クラスターに適用して、パーティションをブローカーに再割り当てし、パーティションのリーダーを変更します。
これはドライランではありません。最適化プロポーザルを承認する前に、以下を行う必要があります。
- 最新でない可能性があるため、プロポーザルを更新します。
- プロポーザルの内容を注意して確認します。
前提条件
- Cruise Control から 最適化プロポーザルを生成済み である必要があります。
-
KafkaRebalance
カスタムリソースの状態がProposalReady
である必要があります。
手順
承認する最適化プロポーザルに対して、以下の手順を実行します。
最適化プロポーザルが新規生成された場合を除き、プロポーザルが Kafka クラスターの状態に関する現在の情報を基にしていることを確認します。これには、最適化プロポーザルを更新し、必ず最新のクラスターメトリクスを使用するようにします。
OpenShift で
KafkaRebalance
リソースにrefresh
アノテーションを付けます。oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=refresh
KafkaRebalance
リソースのステータスを確認します。oc describe kafkarebalance rebalance-cr-name
-
状態が
ProposalReady
に変わるまで待ちます。
Cruise Control が適用する最適化プロポーザルを承認します。
OpenShift で
KafkaRebalance
リソースにアノテーションを付けます。oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=approve
- Cluster Operator は アノテーションが付けられたリソースを検出し、Cruise Control に Kafka クラスターのリバランスを指示します。
KafkaRebalance
リソースのステータスを確認します。oc describe kafkarebalance rebalance-cr-name
Cruise Control は以下の 3 つの状態の 1 つを返します。
- Rebalaning: クラスターリバランス操作の実行中です。
-
Ready: クラスターリバランス操作が正常に完了しました。
KafkaRebalance
カスタムリソースは再利用できません。 -
NotReady: エラーが発生しました。「
KafkaRebalance
リソースの問題の修正」 を参照してください。
その他のリソース
8.9. クラスターリバランスの停止
クラスターリバランス操作を開始すると、完了まで時間がかかることがあり、Kafka クラスターの全体的なパフォーマンスに影響します。
実行中のクラスターリバランス操作を停止するには、stop
アノテーションを KafkaRebalance
カスタムリソースに適用します。これにより、現在のパーティション再割り当てのバッチ処理を完了し、リバランスを停止するよう Cruise Control が指示されます。リバランスの停止時、完了したパーティションの再割り当てはすで適用されています。そのため、Kafka クラスターの状態は、リバランス操作の開始前とは異なります。さらなるリバランスが必要な場合は、新しい最適化プロポーザルを生成してください。
中間 (停止) 状態の Kafka クラスターのパフォーマンスは、初期状態の場合よりも悪くなる可能性があります。
前提条件
-
KafkaRebalance
カスタムリソースにapprove
アノテーションを付けて 最適化プロポーザルが承認済みである必要があります。 -
KafkaRebalance
カスタムリソースの状態がRebalancing
である必要があります。
手順
OpenShift で
KafkaRebalance
リソースにアノテーションを付けます。oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=stop
KafkaRebalance
リソースのステータスを確認します。oc describe kafkarebalance rebalance-cr-name
-
状態が
Stopped
に変わるまで待ちます。
その他のリソース
8.10. KafkaRebalance
リソースの問題の修正
KafkaRebalance
リソースの作成時や、Cruise Control との対話中に問題が発生した場合、エラーとその修正方法の詳細がリソースの状態で報告されます。また、リソースも NotReady
の状態に変わります。
クラスターリバランス操作を続行するには、KafkaRebalance
リソース自体の問題または Cruise Control デプロイメント全体の問題を修正する必要があります。問題には以下が含まれる可能性があります。
-
KafkaRebalance
リソースのパラメーターの設定に誤りがある。 -
KafkaRebalance
リソースの Kafka クラスターを指定するためのstrimzi.io/cluster
ラベルがない。 -
Kafka
リソースにcruiseControl
プロパティーがないため、Cruise Control サーバーがデプロイされていない。 - Cruise Control サーバーに接続できない。
問題の修正後、refresh
アノテーションを KafkaRebalance
リソースに付ける必要があります。「refresh」(更新) 中、Cruise Control サーバーから新しい最適化プロポーザルが要求されます。
前提条件
- 最適化プロポーザルが承認済みである必要があります。
-
リバランス操作の
KafkaRebalance
カスタムリソースの状態がNotReady
である必要があります。
手順
KafkaRebalance
の状態からエラーに関する情報を取得します。oc describe kafkarebalance rebalance-cr-name
-
KafkaRebalance
リソースで問題の解決を試みます。 OpenShift で
KafkaRebalance
リソースにアノテーションを付けます。oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=refresh
KafkaRebalance
リソースのステータスを確認します。oc describe kafkarebalance rebalance-cr-name
-
状態が
PendingProposal
からProposalReady
に変わるまで待ちます。
その他のリソース
第9章 Service Registry を使用したスキーマの検証
AMQ Streams では、Red Hat Service Registry を使用できます。
Service Registry は、API およびイベント駆動型アーキテクチャー全体で標準的なイベントスキーマおよび API 設計を共有するためのデータストアです。Service Registry を使用して、クライアントアプリケーションからデータの構造を切り離し、REST インターフェースを使用して実行時にデータ型と API の記述を共有および管理できます。
Service Registry では、メッセージをシリアライズおよびデシリアライズするために使用されるスキーマが保存されます。その後、クライアントアプリケーションからスキーマを参照して、送受信されるメッセージとこれらのスキーマの互換性を維持するようにします。Service Registry によって、Kafka プロデューサーおよびコンシューマーアプリケーションの Kafka クライアントシリアライザーおよびデシリアライザーが提供されます。Kafka プロデューサーアプリケーションは、シリアライザーを使用して、特定のイベントスキーマに準拠するメッセージをエンコードします。Kafka コンシューマーアプリケーションはデシリアライザーを使用して、特定のスキーマ ID に基づいてメッセージが適切なスキーマを使用してシリアライズされたことを検証します。
アプリケーションがレジストリーからスキーマを使用できるようにすることができます。これにより、スキーマが一貫して使用されるようにし、実行時にデータエラーが発生しないようにします。
その他のリソース
- Service Registry のドキュメント
- Service Registry は、GitHub の Apicurio/Apicurio-registry で利用可能な Apicurio Registry オープンソースコミュニティープロジェクトで構築されます。
第10章 分散トレーシング
分散トレーシングを使用すると、分散システムのアプリケーション間で実行されるトランザクションの進捗を追跡できます。マイクロサービスのアーキテクチャーでは、トレーシングはサービス間のトランザクションの進捗を追跡します。トレースデータは、アプリケーションのパフォーマンスを監視し、ターゲットシステムおよびエンドユーザーアプリケーションの問題を調べるのに役立ちます。
AMQ Streams では、トレーシングによってメッセージのエンドツーエンドの追跡が容易になります。これは、ソースシステムから Kafka、さらに Kafka からターゲットシステムおよびアプリケーションへのメッセージの追跡です。これは、Grafana ダッシュボード で表示できるメトリクスやコンポーネントロガーを補います。
AMQ Streams によるトレーシングのサポート方法
トレーシングのサポートは、以下のコンポーネントに組み込まれています。
- Kafka Connect (Source2Image がサポートされる Kafka Connect を含む)
- MirrorMaker
- MirrorMaker 2.0
- AMQ Streams Kafka Bridge
カスタムリソースのテンプレート設定プロパティーを使用して、これらのコンポーネントのトレーシングを有効化および設定します。
Kafka プロデューサー、コンシューマー、および Kafka Streams API アプリケーションでトレーシングを有効にするには、AMQ Streams に含まれる OpenTracing Apache Kafka Client Instrumentation ライブラリーを使用してアプリケーションコードを インストルメント化 します。インストルメント化されると、クライアントはメッセージのトレースデータを生成します (メッセージの作成時やログへのオフセットの書き込み時など)。
トレースは、サンプリングストラテジーに従いサンプル化され、Jaeger ユーザーインターフェースで可視化されます。
トレーシングは Kafka ブローカーではサポートされません。
AMQ Streams 以外のアプリケーションおよびシステムにトレーシングを設定する方法については、本章の対象外となります。この件についての詳細は、OpenTracing ドキュメント を参照し、「inject and extrac」を検索してください。
手順の概要
AMQ Streams のトレーシングを設定するには、以下の手順を順番に行います。
クライアントのトレーシングを設定します。
トレーサーでクライアントをインストルメント化します。
- MirrorMaker、Kafka Connect、Kafka Bridge のトレーシングを設定します。
前提条件
- Jaeger バックエンドコンポーネントが OpenShift クラスターにデプロイされている必要があります。デプロイメント手順の詳細は、Jaeger デプロイメントのドキュメントを参照してください。
10.1. OpenTracing および Jaeger の概要
AMQ Streams では OpenTracing および Jaeger プロジェクトが使用されます。
OpenTracing は、トレーシングまたは監視システムに依存しない API 仕様です。
- OpenTracing API は、アプリケーションコードを インストルメント化 するために使用されます。
- インストルメント化されたアプリケーションは、分散システム全体で個別のトランザクションの トレース を生成します。
- トレースは、特定の作業単位を定義する スパン で構成されます。
Jaeger はマイクロサービスベースの分散システムのトレーシングシステムです。
- Jaeger は OpenTracing API を実装し、インストルメント化のクライアントライブラリーを提供します。
- Jaeger ユーザーインターフェースを使用すると、トレースデータをクエリー、フィルター、および分析できます。
その他のリソース
10.2. Kafka クライアントのトレーシング設定
Jaeger トレーサーを初期化し、分散トレーシング用にクライアントアプリケーションをインストルメント化します。
10.2.1. Kafka クライアント用の Jaeger トレーサーの初期化
一連のトレーシング環境変数を使用して、Jaeger トレーサーを設定および初期化します。
手順
各クライアントアプリケーションで以下を行います。
Jaeger の Maven 依存関係をクライアントアプリケーションの
pom.xml
ファイルに追加します。<dependency> <groupId>io.jaegertracing</groupId> <artifactId>jaeger-client</artifactId> <version>1.1.0.redhat-00002</version> </dependency>
- トレーシング環境変数を使用して Jaeger トレーサーの設定を定義します。
2. で定義した環境変数から、Jaeger トレーサーを作成します。
Tracer tracer = Configuration.fromEnv().getTracer();
注記別の Jaeger トレーサーの初期化方法については、Java OpenTracing ライブラリーのドキュメントを参照してください。
Jaeger トレーサーをグローバルトレーサーとして登録します。
GlobalTracer.register(tracer);
これで、Jaeger トレーサーはクライアントアプリケーションが使用できるように初期化されました。
10.2.2. トレーシングの環境変数
ここに示す環境変数は、Kafka クライアントに Jaeger トレーサーを設定するときに使用します。
トレーシング環境変数は Jaeger プロジェクトの一部で、変更される場合があります。最新の環境変数については、Jaeger ドキュメントを参照してください。
プロパティー | 必要性 | 説明 |
---|---|---|
| 必要 | Jaeger トレーサーサービスの名前。 |
| 不要 |
UDP (User Datagram Protocol) を介した |
| 不要 |
UDP を介した |
| 不要 |
|
| 不要 | エンドポイントに bearer トークンとして送信する認証トークン。 |
| 不要 | Basic 認証を使用する場合にエンドポイントに送信するユーザー名。 |
| 不要 | Basic 認証を使用する場合にエンドポイントに送信するパスワード。 |
| 不要 |
トレースコンテキストの伝播に使用するカンマ区切りの形式リスト。デフォルトは標準の Jaeger 形式です。有効な値は |
| 不要 | レポーターがスパンも記録する必要があるかどうかを示します。 |
| 不要 | レポーターの最大キューサイズ。 |
| 不要 | レポーターのフラッシュ間隔 (ミリ秒単位)。Jaeger レポーターがスパンバッチをフラッシュする頻度を定義します。 |
| 不要 | クライアントトレースに使用するサンプリングストラテジー。
すべてのトレースをサンプリングするには、Constant サンプリングストラテジーを使用し、パラメーターを 1 にします。 詳細は、Jaeger ドキュメントを参照してください。 |
| 不要 | サンプラーのパラメーター (数値)。 |
| 不要 | リモートサンプリングストラテジーを選択する場合に使用するホスト名およびポート。 |
| 不要 | 報告されたすべてのスパンに追加されるトレーサーレベルのタグのカンマ区切りリスト。
この値に |
その他のリソース
10.3. トレーサーでの Kafka クライアントのインストルメント化
Kafka プロデューサーとコンシューマークライアント、および Kafka Streams API アプリケーションを分散トレーシング用にインストルメント化します。
10.3.1. トレーシングのための Kafka プロデューサーおよびコンシューマーのインストルメント化
Decorator パターンまたは Interceptor を使用して、Java プロデューサーおよびコンシューマーアプリケーションコードをトレーシング用にインストルメント化します。
手順
各プロデューサーおよびコンシューマーアプリケーションのアプリケーションコードで以下を行います。
OpenTracing の Maven 依存関係を、プロデューサーまたはコンシューマーの
pom.xml
ファイルに追加します。<dependency> <groupId>io.opentracing.contrib</groupId> <artifactId>opentracing-kafka-client</artifactId> <version>0.1.15.redhat-00001</version> </dependency>
Decorator パターンまたは Interceptor のいずれかを使用して、クライアントアプリケーションコードをインストルメント化します。
Decorator パターンを使用する場合は以下を行います。
// Create an instance of the KafkaProducer: KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps); // Create an instance of the TracingKafkaProducer: TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer, tracer); // Send: tracingProducer.send(...); // Create an instance of the KafkaConsumer: KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps); // Create an instance of the TracingKafkaConsumer: TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer, tracer); // Subscribe: tracingConsumer.subscribe(Collections.singletonList("messages")); // Get messages: ConsumerRecords<Integer, String> records = tracingConsumer.poll(1000); // Retrieve SpanContext from polled record (consumer side): ConsumerRecord<Integer, String> record = ... SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
インターセプターを使用する場合は以下を使用します。
// Register the tracer with GlobalTracer: GlobalTracer.register(tracer); // Add the TracingProducerInterceptor to the sender properties: senderProps.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG, TracingProducerInterceptor.class.getName()); // Create an instance of the KafkaProducer: KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps); // Send: producer.send(...); // Add the TracingConsumerInterceptor to the consumer properties: consumerProps.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG, TracingConsumerInterceptor.class.getName()); // Create an instance of the KafkaConsumer: KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps); // Subscribe: consumer.subscribe(Collections.singletonList("messages")); // Get messages: ConsumerRecords<Integer, String> records = consumer.poll(1000); // Retrieve the SpanContext from a polled message (consumer side): ConsumerRecord<Integer, String> record = ... SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
10.3.1.1. Decorator パターンのカスタムスパン名
スパン は Jaeger の論理作業単位で、操作名、開始時間、および期間が含まれます。
Decorator パターンを使用してプロデューサーおよびコンシューマーの各アプリケーションをインストルメント化する場合、TracingKafkaProducer
および TracingKafkaConsumer
オブジェクトの作成時に BiFunction
オブジェクトを追加の引数として渡すと、カスタムスパン名を定義できます。OpenTracing の Apache Kafka Client Instrumentation ライブラリーには、複数の組み込みスパン名が含まれています。
例: カスタムスパン名を使用した Decorator パターンでのクライアントアプリケーションコードのインストルメント化
// Create a BiFunction for the KafkaProducer that operates on (String operationName, ProducerRecord consumerRecord) and returns a String to be used as the name: BiFunction<String, ProducerRecord, String> producerSpanNameProvider = (operationName, producerRecord) -> "CUSTOM_PRODUCER_NAME"; // Create an instance of the KafkaProducer: KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps); // Create an instance of the TracingKafkaProducer TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer, tracer, producerSpanNameProvider); // Spans created by the tracingProducer will now have "CUSTOM_PRODUCER_NAME" as the span name. // Create a BiFunction for the KafkaConsumer that operates on (String operationName, ConsumerRecord consumerRecord) and returns a String to be used as the name: BiFunction<String, ConsumerRecord, String> consumerSpanNameProvider = (operationName, consumerRecord) -> operationName.toUpperCase(); // Create an instance of the KafkaConsumer: KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps); // Create an instance of the TracingKafkaConsumer, passing in the consumerSpanNameProvider BiFunction: TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer, tracer, consumerSpanNameProvider); // Spans created by the tracingConsumer will have the operation name as the span name, in upper-case. // "receive" -> "RECEIVE"
10.3.1.2. ビルトインスパン名
カスタムスパン名を定義するとき、ClientSpanNameProvider
クラスで以下の BiFunctions
を使用できます。spanNameProvider
の指定がない場合は、CONSUMER_OPERATION_NAME
および PRODUCER_OPERATION_NAME
が使用されます。
BiFunction | 説明 |
---|---|
|
|
|
|
|
メッセージの送信先または送信元となったトピックの名前を |
|
|
|
操作名およびトピック名を |
|
|
10.3.2. Kafka Streams アプリケーションのトレーシングのインストルメント化
本セクションでは、分散トレーシングのために Kafka Streams API アプリケーションをインストルメント化する方法を説明します。
手順
各 Kafka Streams API アプリケーションで以下を行います。
opentracing-kafka-streams
依存関係を、Kafka Streams API アプリケーションの pom.xml ファイルに追加します。<dependency> <groupId>io.opentracing.contrib</groupId> <artifactId>opentracing-kafka-streams</artifactId> <version>0.1.15.redhat-00001</version> </dependency>
TracingKafkaClientSupplier
サプライヤーインターフェースのインスタンスを作成します。KafkaClientSupplier supplier = new TracingKafkaClientSupplier(tracer);
サプライヤーインターフェースを
KafkaStreams
に提供します。KafkaStreams streams = new KafkaStreams(builder.build(), new StreamsConfig(config), supplier); streams.start();
10.4. MirrorMaker、Kafka Connect、および Kafka Bridge のトレーシング設定
分散トレーシングは、MirrorMaker、MirrorMaker 2.0、Kafka Connect (Source2Image がサポートされる Kafka Connect を含む)、および AMQ Streams Kafka Bridge でサポートされます。
MirrorMaker および MirrorMaker 2.0 でのトレーシング
MirrorMaker および MirrorMaker 2.0 では、メッセージはソースクラスターからターゲットクラスターにトレーシングされます。トレースデータは、MirrorMaker または MirrorMaker 2.0 コンポーネントを出入りするメッセージを記録します。
Kafka Connect でのトレーシング
Kafka Connect により生成および消費されるメッセージのみがトレーシングされます。Kafka Connect と外部システム間で送信されるメッセージをトレーシングするには、これらのシステムのコネクターでトレーシングを設定する必要があります。詳細は、「Kafka Connect の設定」 を参照してください。
Kafka Bridge でのトレーシング
Kafka Bridge によって生成および消費されるメッセージがトレーシングされます。Kafka Bridge を介してメッセージを送受信するクライアントアプリケーションから受信する HTTP リクエストもトレーシングされます。エンドツーエンドのトレーシングを設定するために、HTTP クライアントでトレーシングを設定する必要があります。
10.4.1. MirrorMaker、Kafka Connect、および Kafka Bridge リソースでのトレーシングの有効化
KafkaMirrorMaker
、KafkaMirrorMaker2
、KafkaConnect
、KafkaConnectS2I
、および KafkaBridge
カスタムリソースの設定を更新して、リソースごとに Jaeger トレーサーサービスを指定および設定します。OpenShift クラスターでトレーシングが有効になっているリソースを更新すると、2 つのイベントがトリガーされます。
- インターセプタークラスは、MirrorMaker、MirrorMaker 2.0、Kafka Connect、または AMQ Streams Kafka Bridge の統合されたコンシューマーおよびプロデューサーで更新されます。
- MirrorMaker、MirrorMaker 2.0 および Kafka Connect では、リソースに定義されたトレーシング設定に基づいて、Jaeger トレーサーがトレーシングエージェントによって初期化されます。
- Kafka Bridge では、リソースに定義されたトレーシング設定に基づいて、Jaeger トレーサーが Kafka Bridge によって初期化されます。
手順
各 KafkaMirrorMaker
、KafkaMirrorMaker2
、KafkaConnect
、KafkaConnectS2I
、および KafkaBridge
リソースにこれらのステップを実行します。
spec.template
プロパティーで、Jaeger トレーサーサービスを設定します。以下に例を示します。Kafka Connect の Jaeger トレーサー設定
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster spec: #... template: connectContainer: 1 env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831" tracing: 2 type: jaeger #...
MirrorMaker の Jaeger トレーサー設定
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker metadata: name: my-mirror-maker spec: #... template: mirrorMakerContainer: env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831" tracing: type: jaeger #...
MirrorMaker 2.0 の Jaeger トレーサー設定
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: #... template: connectContainer: env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831" tracing: type: jaeger #...
Kafka Bridge の Jaeger トレーサー設定
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: #... template: bridgeContainer: env: - name: JAEGER_SERVICE_NAME value: my-jaeger-service - name: JAEGER_AGENT_HOST value: jaeger-agent-name - name: JAEGER_AGENT_PORT value: "6831" tracing: type: jaeger #...
- 1
- トレーシング環境変数をテンプレートの設定プロパティーとして使用します。
- 2
spec.tracing.type
プロパティーをjaeger
に設定します。
リソースを作成または更新します。
oc apply -f your-file
第11章 TLS 証明書の管理
AMQ Streams は、Kafka と AMQ Streams コンポーネントとの間で TLS プロトコルを使用して暗号化された通信をサポートします。Kafka ブローカー間の通信 (Interbroker 通信)、ZooKeeper ノード間の通信 (Internodal 通信)、およびこれらと AMQ Streams Operator 間の通信は、常に暗号化されます。Kafka クライアントと Kafka ブローカーとの間の通信は、クラスターが設定された方法に応じて暗号化されます。Kafka および AMQ Streams コンポーネントでは、TLS 証明書も認証に使用されます。
Cluster Operator は、自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。また、Kafka ブローカーとクライアントとの間の暗号化または TLS 認証を有効にする場合、他の TLS 証明書も設定されます。ユーザーが用意した証明書は更新されません。
TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーの、Kafka リスナー証明書 と呼ばれる独自のサーバー証明書を提供できます。詳細は、「Kafka リスナー証明書」 を参照してください。
図11.1 TLS によってセキュリティーが保護された通信のアークテクチャー例

11.1. 認証局
暗号化のサポートには、AMQ Streams コンポーネントごとに固有の秘密鍵と公開鍵証明書が必要です。すべてのコンポーネント証明書は、クラスター CA と呼ばれる内部認証局 (CA) により署名されます。
同様に、TLS クライアント認証を使用して AMQ Streams に接続する各 Kafka クライアントアプリケーションは、秘密鍵と証明書を提供する必要があります。クライアント CA という第 2 の内部 CA を使用して、Kafka クライアントの証明書に署名します。
11.1.1. CA 証明書
クラスター CA とクライアント CA の両方には、自己署名の公開鍵証明書があります。
Kafka ブローカーは、クラスター CA またはクライアント CA のいずれかが署名した証明書を信頼するように設定されます。クライアントによる接続が不要なコンポーネント (ZooKeeper など) のみが、クラスター CA によって署名された証明書を信頼します。外部リスナーの TLS 暗号化が無効でない限り、クライアントアプリケーションはクラスター CA により署名された証明書を必ず信頼する必要があります。これは、相互 TLS 認証 を実行するクライアントアプリケーションにも当てはまります。
デフォルトで、AMQ Streams はクラスター CA またはクライアント CA によって発行された CA 証明書を自動で生成および更新します。これらの CA 証明書の管理は、Kafka.spec.clusterCa
および Kafka.spec.clientsCa
オブジェクトで設定できます。ユーザーが用意した証明書は更新されません。
クラスター CA またはクライアント CA に、独自の CA 証明書を提供できます。詳細は、「独自の CA 証明書のインストール」 を参照してください。独自の証明書を提供する場合は、証明書の更新が必要なときに手作業で更新する必要があります。
11.1.2. 独自の CA 証明書のインストール
この手順では、Cluster Operator で生成される CA 証明書と鍵を使用する代わりに、独自の CA 証明書と秘密鍵をインストールする方法について説明します。
以下の手順を使用して、独自のクラスターまたはクライアント CA 証明書をインストールできます。
この手順では、PEM 形式の CA 証明書の更新を説明します。PKCS #12 形式の証明書を使用することもできます。
前提条件
- Cluster Operator が稼働している必要があります。
- Kafka クラスターがデプロイされていない必要があります。
クラスター CA またはクライアントの、PEM 形式による独自の X.509 証明書および鍵が必要です。
ルート CA ではないクラスターまたはクライアント CA を使用する場合、証明書ファイルにチェーン全体を含める必要があります。チェーンの順序は以下のとおりです。
- クラスターまたはクライアント CA
- 1 つ以上の中間 CA
- ルート CA
- チェーン内のすべての CA は、X509v3 の基本制約 (Basic Constraint) で CA として設定する必要があります。
手順
CA 証明書を対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-CERTIFICATE-SECRET
CA-CERTIFICATE-SECRET は
Secret
の名前です。これは、クラスター CA 証明書の場合はCLUSTER-NAME-cluster-ca-cert
、クライアント CA 証明書の場合はCLUSTER-NAME-clients-ca-cert
になります。「Not Exists」エラーを無視します。
新規シークレットを作成およびラベル付けします。
oc create secret generic CA-CERTIFICATE-SECRET --from-file=ca.crt=CA-CERTIFICATE-FILENAME
CA キーを対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-KEY-SECRET
CA-KEY-SECRET は CA 鍵の名前です。これは、クラスター CA 鍵の場合は
CLUSTER-NAME-cluster-ca
、クライアント CA 鍵の場合はCLUSTER-NAME-clients-ca
になります。新規シークレットを作成します。
oc create secret generic CA-KEY-SECRET --from-file=ca.key=CA-KEY-SECRET-FILENAME
strimzi.io/kind=Kafka
およびstrimzi.io/cluster=CLUSTER-NAME
というラベルをシークレットに付けます。oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
クラスターの
Kafka
リソースを作成し、生成された CA を使用 しない ようにKafka.spec.clusterCa
およびKafka.spec.clientsCa
オブジェクトを設定します。独自指定の証明書を使用するようにクラスター CA を設定する
Kafka
リソースの例 (抜粋)kind: Kafka version: kafka.strimzi.io/v1beta2 spec: # ... clusterCa: generateCertificateAuthority: false
その他のリソース
- 以前インストールした CA 証明書を更新する場合は 「独自の CA 証明書の更新」 を参照してください。
- 「独自の Kafka リスナー証明書の指定」
11.2. Secret
AMQ Streams は Secret を使用して、Kafka クラスターコンポーネントおよびクライアントの秘密鍵および証明書を格納します。Secrets は、Kafka ブローカー間およびブローカーとクライアント間で TLS で暗号化された接続を確立するために使用されます。Secret は相互 TLS 認証にも使用されます。
- Cluster Secret には、Kafka ブローカー証明書に署名するためのクラスター CA 証明書が含まれます。また、接続クライアントによって、Kafka クラスターとの TLS 暗号化接続を確立してブローカー ID を検証するために使用されます。
- Client Secret にはクライアント CA 証明書が含まれ、これによりユーザーは独自のクライアント証明書に署名し、Kafka クラスターに対する相互認証が可能になります。ブローカーはクライアント CA 証明書を使用してクライアント ID を検証します。
- User Secret には、新規ユーザーの作成時にクライアント CA 証明書によって生成および署名される秘密鍵と証明書が含まれています。この鍵と証明書は、クラスターへのアクセス時の認証および承認に使用されます。
Secret には、PEM 形式および PKCS #12 形式の秘密鍵と証明書が含まれます。PEM 形式の秘密鍵と証明書を使用する場合、ユーザーは Secret からそれらの秘密鍵と証明書を取得し、Java アプリケーションで使用するために対応するトラストストア (またはキーストア) を生成します。PKCS #12 ストレージは、直接使用できるトラストストア (またはキーストア) を提供します。
すべての鍵のサイズは 2048 ビットです。
11.2.1. PKCS #12 ストレージ
PKCS #12 は、暗号化オブジェクトをパスワードで保護された単一のファイルに格納するためのアーカイブファイル形式 (.p12
) を定義します。PKCS #12 を使用して、証明書および鍵を一元的に管理できます。
各 Secret には、PKCS #12 特有のフィールドが含まれています。
-
.p12
フィールドには、証明書と鍵が含まれます。 -
.password
フィールドは、アーカイブを保護するパスワードです。
11.2.2. クラスター CA Secret
以下の表は、Kafka クラスターの Cluster Operator によって管理される Cluster Secret を表しています。
<cluster>-cluster-ca-cert
Secret のみがクライアントによって使用される必要があります。表に記載されているそれ以外の Secrets
はすべて AMQ Streams コンポーネントによるアクセスのみが必要です。これは、必要な場合に OpenShift のロールベースアクセス制御を使用して強制できます。
フィールド | 説明 |
---|---|
| クラスター CA の現在の秘密鍵。 |
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
| クラスター CA の現在の証明書。 |
TLS を介した Kafka ブローカーへの接続時に Kafka ブローカー証明書を検証するため、<cluster>-cluster-ca-cert
の CA 証明書は Kafka クライアントアプリケーションによって信頼される必要があります。
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
|
Kafka ブローカー Pod <num> の証明書。 |
|
Kafka ブローカー Pod |
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
|
ZooKeeper ノード <num> の証明書。 |
|
ZooKeeper Pod |
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
|
Entity Operator と Kafka または ZooKeeper との間の TLS 通信の証明書。 |
| Entity Operator と、Kafka または ZooKeeper との間の TLS 通信の秘密鍵。 |
11.2.3. クライアント CA Secret
Secret 名 | Secret 内のフィールド | 説明 |
---|---|---|
|
| クライアント CA の現在の秘密鍵。 |
|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 | |
| クライアント CA の現在の証明書。 |
<cluster>-clients-ca-cert
の証明書は、Kafka ブローカーが信頼する証明書です。
<cluster>-clients-ca
は、クライアントアプリケーションの証明書への署名に使用されます。また AMQ Streams コンポーネントにアクセスできる必要があり、User Operator を使わずにアプリケーション証明書を発行する予定であれば管理者のアクセス権限が必要です。これは、必要な場合に OpenShift のロールベースのアクセス制御を使用して強制できます。
11.2.4. ラベルおよびアノテーションの Secret への追加
Kafka
カスタムリソースの clusterCaCert
テンプレートプロパティーを設定すると、カスタムラベルとアノテーションを Cluster Operator によって作成された Cluster CA Secret に追加できます。ラベルとアノテーションは、オブジェクトを特定し、コンテキスト情報を追加するのに便利です。AMQ Streams カスタムリソースでテンプレートプロパティーを設定します。
ラベルおよびアノテーションを Secret に追加するテンプレートのカスタマイズ例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... template: clusterCaCert: metadata: labels: label1: value1 label2: value2 annotations: annotation1: value1 annotation2: value2 # ...
テンプレートプロパティーの設定に関する詳細は、「OpenShift リソースのカスタマイズ」 を参照してください。
11.2.5. CA Secret での ownerReference
の無効化
デフォルトでは、クラスターおよびクライアント CA Secret は、Kafka
カスタムリソースに設定される ownerReference
プロパティーで作成されます。つまり、Kafka
カスタムリソースが削除されると、OpenShift によって CA Secret も削除 (ガベッジコレクション) されます。
新しいクラスターに CA を再利用する場合は、Kafka
設定で Cluster および Client CA Secret の generateSecretOwnerReference
プロパティーを false
に設定して、ownerReference
を無効にすることができます。ownerReference
を無効にすると、対応する Kafka
カスタムリソースが削除されても、CA Secret は OpenShift によって削除されません。
クラスターおよびクライアント CA の ownerReference
が無効になっている Kafka 設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka # ... spec: # ... clusterCa: generateSecretOwnerReference: false clientsCa: generateSecretOwnerReference: false # ...
その他のリソース
11.2.6. User Secret
Secret 名 | Secret 内のフィールド | 説明 |
---|---|---|
|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 | |
| ユーザーの証明書、クライアント CA により署名されます。 | |
| ユーザーの秘密鍵。 |
11.3. 証明書の更新および有効期間
クラスター CA およびクライアント CA の証明書は、限定された期間、すなわち有効期間に限り有効です。通常、この期間は証明書の生成からの日数として定義されます。
Cluster Operator によって自動作成される CA 証明書の場合、以下の有効期間を設定できます。
-
クラスター CA 証明書の場合:
Kafka.spec.clusterCa.validityDays
-
クライアント CA 証明書の場合:
Kafka.spec.clientsCa.validityDays
デフォルトの有効期間は、両方の証明書で 365 日です。手動でインストールした CA 証明書には、独自の有効期間が定義されている必要があります。
CA 証明書の期限が切れると、その証明書を信頼しているコンポーネントおよびクライアントは、その CA 秘密鍵で署名された証明書を持つ相手からの TLS 接続を受け入れません。代わりに、コンポーネントおよびクライアントは 新しい CA 証明書を信頼する必要があります。
サービスを中断せずに CA 証明書を更新できるようにするため、Cluster Operator は古い CA 証明書が期限切れになる前に証明書の更新を開始します。
Cluster Operator によって作成される証明書の更新期間を設定できます。
-
クラスター CA 証明書の場合:
Kafka.spec.clusterCa.renewalDays
-
クライアント CA 証明書の場合:
Kafka.spec.clientsCa.renewalDays
デフォルトの更新期間は、両方の証明書とも 30 日です。
更新期間は、現在の証明書の有効期日から逆算されます。
更新期間に対する有効期間
Not Before Not After | | |<--------------- validityDays --------------->| <--- renewalDays --->|
Kafka クラスターの作成後に有効期間および更新期間を変更するには、Kafka
カスタムリソースを設定および適用し、CA 証明書を手動で更新 します。証明書を手動で更新しないと、証明書が次回自動更新される際に新しい期間が使用されます。
証明書の有効および更新期間の Kafka 設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka # ... spec: # ... clusterCa: renewalDays: 30 validityDays: 365 generateCertificateAuthority: true clientsCa: renewalDays: 30 validityDays: 365 generateCertificateAuthority: true # ...
更新期間中の Cluster Operator の動作は、証明書生成プロパティー generateCertificateAuthority
および generateCertificateAuthority
の設定によって異なります。
true
-
プロパティーが
true
に設定されている場合、CA 証明書は Cluster Operator によって自動的に生成され、更新期間内に自動的に更新されます。 false
-
プロパティーが
false
に設定されている場合、CA 証明書は Cluster Operator によって生成されません。独自の証明書をインストールする場合は、このオプションを使用します。
11.3.1. 自動生成された CA 証明書での更新プロセス
Cluster Operator は以下のプロセスを実行して CA 証明書を更新します。
-
新しい CA 証明書を生成しますが、既存の鍵は保持します。該当する
Secret
内のca.crt
という名前の古い証明書が新しい証明書に置き換えられます。 - 新しいクライアント証明書を生成します (ZooKeeper ノード、Kafka ブローカー、および Entity Operator 用)。署名鍵は変わっておらず、CA 証明書と同期してクライアント証明書の有効期間を維持するため、これは必須ではありません。
- ZooKeeper ノードを再起動して、ZooKeeper ノードが新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。
- Kafka ブローカーを再起動して、Kafka ブローカーが新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。
- Topic Operator および User Operator を再起動して、それらの Operator が新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。
11.3.2. クライアント証明書の更新
Cluster Operator は、Kafka クラスターを使用するクライアントアプリケーションを認識しません。
クラスターに接続し、クライアントアプリケーションが正しく機能するように確認するには、クライアントアプリケーションは以下を行う必要があります。
- <cluster>-cluster-ca-cert Secret でパブリッシュされるクラスター CA 証明書を信頼する必要があります。
<user-name> Secret でパブリッシュされたクレデンシャルを使用してクラスターに接続します。
User Secret は PEM および PKCS #12 形式のクレデンシャルを提供し、SCRAM-SHA 認証を使用する場合はパスワードを提供できます。ユーザーの作成時に User Operator によってユーザークレデンシャルが生成されます。
証明書の更新後もクライアントが動作するようにする必要があります。更新プロセスは、クライアントの設定によって異なります。
クライアント証明書と鍵のプロビジョニングを手動で行う場合、新しいクライアント証明書を生成し、更新期間内に新しい証明書がクライアントによって使用されるようにする必要があります。更新期間の終了までにこれが行われないと、クライアントアプリケーションがクラスターに接続できなくなる可能性があります。
同じ OpenShift クラスターおよび namespace 内で実行中のワークロードの場合、Secrets はボリュームとしてマウントできるので、クライアント Pod はそれらのキーストアとトラストストアを現在の状態の Secrets から構築できます。この手順の詳細は、「クラスター CA を信頼する内部クライアントの設定」を参照してください。
11.3.3. Cluster Operator によって生成される CA 証明書の手動更新
Cluster Operator によって生成されるクラスターおよびクライアント CA 証明書は、各証明書の更新期間の開始時に自動更新されます。ただし、strimzi.io/force-renew
アノテーションを使用すると、証明書の更新期間が始まる前に、これらの証明書のいずれかまたは両方を手動で更新できます。セキュリティー上の理由や、証明書の更新または有効期間を変更した 場合などに、自動更新を行うことがあります。
更新された証明書は、更新前の証明書と同じ秘密鍵を使用します。
独自の CA 証明書を使用している場合は、force-renew
アノテーションを使用できません。代わりに、独自の CA 証明書を更新する手順に従ってください。
前提条件
- Cluster Operator が稼働している必要があります。
- CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。
手順
strimzi.io/force-renew
アノテーションを、更新対象の CA 証明書が含まれるSecret
に適用します。表11.8 証明書の更新を強制する Secret のアノテーション。 証明書 Secret annotate コマンド クラスター CA
KAFKA-CLUSTER-NAME-cluster-ca-cert
oc annotate secret KAFKA-CLUSTER-NAME-cluster-ca-cert strimzi.io/force-renew=true
クライアント CA
KAFKA-CLUSTER-NAME-clients-ca-cert
oc annotate secret KAFKA-CLUSTER-NAME-clients-ca-cert strimzi.io/force-renew=true
次回の調整で、アノテーションを付けた
Secret
の新規 CA 証明書が Cluster Operator によって生成されます。メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新規 CA 証明書が生成されます。Cluster Operator によって更新されたクラスターおよびクライアント CA 証明書をクライアントアプリケーションがリロードする必要があります。
CA 証明書が有効である期間を確認します。
たとえば、以下のように
openssl
コマンドを使用します。oc get secret CA-CERTIFICATE-SECRET -o 'jsonpath={.data.CA-CERTIFICATE}' | base64 -d | openssl x509 -subject -issuer -startdate -enddate -noout
CA-CERTIFICATE-SECRET は
Secret
の名前です。これは、クラスター CA 証明書の場合はKAFKA-CLUSTER-NAME-cluster-ca-cert
、クライアント CA 証明書の場合はKAFKA-CLUSTER-NAME-clients-ca-cert
になります。CA-CERTIFICATE は CA 証明書の名前です (例:
jsonpath={.data.ca\.crt}
)。このコマンドは、CA 証明書の有効期間である
notBefore
およびnotAfter
の日付を返します。たとえば、クラスター CA 証明書の場合は以下のようになります。
subject=O = io.strimzi, CN = cluster-ca v0 issuer=O = io.strimzi, CN = cluster-ca v0 notBefore=Jun 30 09:43:54 2020 GMT notAfter=Jun 30 09:43:54 2021 GMT
Secret から古い証明書を削除します。
コンポーネントで新しい証明書が使用される場合でも、古い証明書がアクティブであることがあります。古い証明書を削除して、潜在的なセキュリティーリスクを取り除きます。
11.3.4. Cluster Operator によって生成された CA 証明書によって使用される秘密鍵の置き換え
Cluster Operator によって生成されるクラスター CA およびクライアント CA 証明書によって使用される秘密鍵を置換できます。秘密鍵が交換されると、Cluster Operator によって新しい秘密鍵の新しい CA 証明書が生成されます。
独自の CA 証明書を使用している場合は、force-replace
アノテーションは使用できません。代わりに、独自の CA 証明書を更新する手順に従ってください。
前提条件
- Cluster Operator が稼働している必要があります。
- CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。
手順
strimzi.io/force-replace
アノテーションを、更新対象の秘密鍵が含まれるSecret
に適用します。表11.9 秘密鍵を置き換えるコマンド 秘密鍵 Secret annotate コマンド クラスター CA
CLUSTER-NAME-cluster-ca
oc annotate secret CLUSTER-NAME-cluster-ca strimzi.io/force-replace=true
クライアント CA
CLUSTER-NAME-clients-ca
oc annotate secret CLUSTER-NAME-clients-ca strimzi.io/force-replace=true
次回の調整時に、Cluster Operator は以下を生成します。
-
アノテーションを付けた
Secret
の新しい秘密鍵 - 新規 CA 証明書
メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新しい秘密鍵と CA 証明書が生成されます。
Cluster Operator によって更新されたクラスターおよびクライアント CA 証明書をクライアントアプリケーションがリロードする必要があります。
その他のリソース
11.3.5. 独自の CA 証明書の更新
この手順では、Cluster Operator によって生成される証明書を使用せずに、独自にインストールした CA 証明書および鍵を更新する方法を説明します。
独自の証明書を使用している場合、Cluster Operator は自動的に更新されません。したがって、期限切れ間近の CA 証明書を交換するために、証明書の更新期間中にこの手順を実行することが重要になります。
この手順では、PEM 形式の CA 証明書の更新を説明します。PKCS #12 形式の証明書を使用することもできます。
前提条件
- Cluster Operator が稼働している必要があります。
- 独自の CA 証明書と秘密鍵がインストールされている必要があります。
- クラスターおよびクライアントの PEM 形式による新しい X.509 証明書と鍵が必要です。
これらは、openssl
コマンドを使用して以下のように生成できます。
openssl req -x509 -new -days NUMBER-OF-DAYS-VALID --nodes -out ca.crt -keyout ca.key
手順
Secret
で、現在の CA 証明書の詳細を確認します。oc describe secret CA-CERTIFICATE-SECRET
CA-CERTIFICATE-SECRET は
Secret
の名前です。これは、クラスター CA 証明書の場合はKAFKA-CLUSTER-NAME-cluster-ca-cert
、クライアント CA 証明書の場合はKAFKA-CLUSTER-NAME-clients-ca-cert
になります。シークレットに既存の CA 証明書が含まれるディレクトリーを作成します。
mkdir new-ca-cert-secret cd new-ca-cert-secret
更新する各 CA 証明書のシークレットを取得します。
oc get secret CA-CERTIFICATE-SECRET -o 'jsonpath={.data.CA-CERTIFICATE}' | base64 -d > CA-CERTIFICATE
CA-CERTIFICATE を各 CA 証明書の名前に置き換えます。
古い
ca.crt
ファイルの名前をca-DATE.crt
に変更します。ここで DATE は、YEAR-MONTH-DAYTHOUR-MINUTE-SECONDZ 形式で表した証明書の有効期限日に置き換えます。たとえば、
ca-2018-09-27T17-32-00Z.crt
のようになります。mv ca.crt ca-$(date -u -d$(openssl x509 -enddate -noout -in ca.crt | sed 's/.*=//') +'%Y-%m-%dT%H-%M-%SZ').crt
新しい CA 証明書をディレクトリーにコピーし、
ca.crt
という名前を付けます。cp PATH-TO-NEW-CERTIFICATE ca.crt
CA 証明書を対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-CERTIFICATE-SECRET
CA-CERTIFICATE-SECRET は、最初のステップで返された、
Secret
の名前です。「Not Exists」エラーを無視します。
シークレットを再作成します。
oc create secret generic CA-CERTIFICATE-SECRET --from-file=.
作成したディレクトリーを削除します。
cd .. rm -r new-ca-cert-secret
CA キーを対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-KEY-SECRET
CA-KEY-SECRET は CA 鍵の名前です。これは、クラスター CA 鍵の場合は
KAFKA-CLUSTER-NAME-cluster-ca
、クライアント CA 鍵の場合はKAFKA-CLUSTER-NAME-clients-ca
になります。新しい CA 鍵でシークレットを再作成します。
oc create secret generic CA-KEY-SECRET --from-file=ca.key=CA-KEY-SECRET-FILENAME
strimzi.io/kind=Kafka
およびstrimzi.io/cluster=KAFKA-CLUSTER-NAME
というラベルをシークレットに付けます。oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=KAFKA-CLUSTER-NAME oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=KAFKA-CLUSTER-NAME
11.4. TLS 接続
11.4.1. ZooKeeper の通信
すべてのポート上の ZooKeeper ノード間の通信と、クライアントと ZooKeeper 間の通信は暗号化されます。
11.4.2. Kafka のブローカー間の通信
Kafka ブローカー間の通信は、ポート 9091 の内部リスナーを介して行われます。この通信はデフォルトで暗号化され、Kafka クライアントへはアクセスできません。
Kafka ブローカーと ZooKeeper ノード間の通信も暗号化されます。
11.4.3. Topic Operator および User Operator
すべての Operator は、Kafka と ZooKeeper 両方との通信に暗号化を使用します。Topic Operator および User Operator では、ZooKeeper との通信時に TLS サイドカーが使用されます。
11.4.4. Cruise Control
Cruise Control は、Kafka と ZooKeeper 両方との通信に暗号化を使用します。TLS サイドカーは、ZooKeeper との通信時に使用されます。
11.4.5. Kafka クライアント接続
Kafka ブローカーとクライアント間の暗号化または非暗号化通信は、spec.kafka.listeners
の tls
プロパティーを使用して設定されます。
11.5. クラスター CA を信頼する内部クライアントの設定
この手順では、TLS リスナーに接続する OpenShift クラスター内部に存在する Kafka クライアントがクラスター CA 証明書を信頼するように設定する方法を説明します。
これを内部クライアントで実現するには、ボリュームマウントを使用して、必要な証明書と鍵が含まれる Secrets
にアクセスするのが最も簡単な方法です。
以下の手順に従い、クラスター CA によって署名された信頼できる証明書を Java ベースの Kafka Producer、Consumer、および Streams API に設定します。
クラスター CA の証明書の形式が PKCS #12 (.p12
) または PEM (.crt
) であるかに応じて、手順を選択します。
この手順では、Kafka クラスターの ID を検証する Cluster Secret をクライアント Pod にマウントする方法を説明します。
前提条件
- Cluster Operator が稼働している必要があります。
-
OpenShift クラスター内に
Kafka
リソースが必要です。 - TLS を使用して接続し、クラスター CA 証明書を必ず信頼する Kafka クライアントアプリケーションが、OpenShift クラスター内部に必要です。
-
クライアントアプリケーションが
Kafka
リソースと同じ namespace で実行している必要があります。
PKCS #12 形式 (.p12) の使用
クライアント Pod の定義時に、Cluster Secret をボリュームとしてマウントします。
以下に例を示します。
kind: Pod apiVersion: v1 metadata: name: client-pod spec: containers: - name: client-name image: client-name volumeMounts: - name: secret-volume mountPath: /data/p12 env: - name: SECRET_PASSWORD valueFrom: secretKeyRef: name: my-secret key: my-password volumes: - name: secret-volume secret: secretName: my-cluster-cluster-ca-cert
ここでは、以下をマウントしています。
- PKCS #12 ファイルを設定可能な正確なパスにマウント。
- パスワードを Java 設定に使用できる環境変数にマウント。
Kafka クライアントを以下のプロパティーで設定します。
セキュリティープロトコルのオプション:
-
security.protocol: SSL
(TLS 認証ありまたはなしで、暗号化に TLS を使用する場合)。 -
security.protocol: SASL_SSL
(TLS 経由で SCRAM-SHA 認証を使用する場合)。
-
-
ssl.truststore.location
(証明書がインポートされたトラストストアを指定)。 -
ssl.truststore.password
(トラストストアにアクセスするためのパスワードを指定)。 -
ssl.truststore.type=PKCS12
(トラストストアのタイプを識別)。
PEM 形式の使用 (.crt)
クライアント Pod の定義時に、Cluster Secret をボリュームとしてマウントします。
以下に例を示します。
kind: Pod apiVersion: v1 metadata: name: client-pod spec: containers: - name: client-name image: client-name volumeMounts: - name: secret-volume mountPath: /data/crt volumes: - name: secret-volume secret: secretName: my-cluster-cluster-ca-cert
- X.509 形式の証明書を使用するクライアントでこの証明書を使用します。
11.6. クラスター CA を信頼する外部クライアントの設定
この手順では、external
リスナーに接続する OpenShift クラスター外部に存在する Kafka クライアントがクラスター CA 証明書を信頼するように設定する方法を説明します。クライアントのセットアップ時および更新期間中に、古いクライアント CA 証明書を交換する場合は、以下の手順に従います。
以下の手順に従い、クラスター CA によって署名された信頼できる証明書を Java ベースの Kafka Producer、Consumer、および Streams API に設定します。
クラスター CA の証明書の形式が PKCS #12 (.p12
) または PEM (.crt
) であるかに応じて、手順を選択します。
この手順では、Kafka クラスターの ID を検証する Cluster Secret から証明書を取得する方法を説明します。
CA 証明書の更新期間中に、<cluster-name>-cluster-ca-cert
Secret
に複数の CA 証明書が含まれます。クライアントは、それらを すべて をクライアントのトラストストアに追加する必要があります。
前提条件
- Cluster Operator が稼働している必要があります。
-
OpenShift クラスター内に
Kafka
リソースが必要です。 - TLS を使用して接続し、クラスター CA 証明書を必ず信頼する Kafka クライアントアプリケーションが、OpenShift クラスター外部に必要です。
PKCS #12 形式 (.p12) の使用
生成された
<cluster-name>-cluster-ca-cert
Secret から、クラスター CA 証明書およびパスワードを抽出します。oc get secret <cluster-name>-cluster-ca-cert -o jsonpath='{.data.ca\.p12}' | base64 -d > ca.p12
oc get secret <cluster-name>-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 -d > ca.password
Kafka クライアントを以下のプロパティーで設定します。
セキュリティープロトコルのオプション:
-
security.protocol: SSL
(TLS 認証ありまたはなしで、暗号化に TLS を使用する場合)。 -
security.protocol: SASL_SSL
(TLS 経由で SCRAM-SHA 認証を使用する場合)。
-
-
ssl.truststore.location
(証明書がインポートされたトラストストアを指定)。 -
ssl.truststore.password
(トラストストアにアクセスするためのパスワードを指定)。このプロパティーは、トラストストアで必要なければ省略できます。 -
ssl.truststore.type=PKCS12
(トラストストアのタイプを識別)。
PEM 形式の使用 (.crt)
生成された
<cluster-name>-cluster-ca-cert
Secret から、クラスター CA 証明書を抽出します。oc get secret <cluster-name>-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
- X.509 形式の証明書を使用するクライアントでこの証明書を使用します。
11.7. Kafka リスナー証明書
以下のタイプのリスナーに、独自のサーバー証明書と秘密鍵を指定できます。
- OpenShift クラスター内で通信するための内部 TLS リスナー
-
Kafka クライアントと Kafka ブローカー間の通信に TLS 暗号化が有効になっている外部リスナー (
route
、loadbalancer
、ingress
、およびnodeport
タイプ)
これらのユーザー提供による証明書は、Kafka リスナー証明書 と呼ばれます。
外部リスナーに Kafka リスナー証明書を提供すると、既存のセキュリティーインフラストラクチャー (所属組織のプライベート CA やパブリック CA など) を利用できます。Kafka クライアントは Kafka ブローカーに接続する際に、クラスター CA またはクライアント CA によって署名された証明書ではなく、Kafka リスナー証明書を使用します。
Kafka リスナー証明書の更新が必要な場合は、手作業で更新する必要があります。
11.7.1. 独自の Kafka リスナー証明書の指定
この手順では、独自の秘密鍵と Kafka リスナー証明書と呼ばれるサーバー証明書を使用するようにリスナーを設定する方法について説明します。
Kafka ブローカーの ID を検証するため、クライアントアプリケーションは CA 公開鍵を信頼できる証明書として使用する必要があります。
前提条件
- OpenShift クラスターが必要です。
- Cluster Operator が稼働している必要があります。
リスナーごとに、外部 CA によって署名された互換性のあるサーバー証明書が必要です。
- X.509 証明書を PEM 形式で提供します。
- リスナーごとに正しい SAN (サブジェクト代替名) を指定します。詳細は、「Kafka リスナーのサーバー証明書の SAN」 を参照してください。
- 証明書ファイルに CA チェーン全体が含まれる証明書を提供できます。
手順
秘密鍵およびサーバー証明書が含まれる
Secret
を作成します。oc create secret generic my-secret --from-file=my-listener-key.key --from-file=my-listener-certificate.crt
クラスターの
Kafka
リソースを編集します。Secret
、証明書ファイル、および秘密鍵ファイルを使用するように、リスナーをconfiguration.brokerCertChainAndKey
プロパティーで設定します。TLS 暗号化が有効な
loadbalancer
外部リスナーの設定例# ... listeners: - name: plain port: 9092 type: internal tls: false - name: external port: 9094 type: loadbalancer tls: true authentication: type: tls configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
TLS リスナーの設定例
# ... listeners: - name: plain port: 9092 type: internal tls: false - name: tls port: 9093 type: internal tls: true authentication: type: tls configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
新しい設定を適用してリソースを作成または更新します。
oc apply -f kafka.yaml
Cluster Operator は、Kafka クラスターのローリングアップデートを開始し、これによりリスナーの設定が更新されます。
注記TLS または外部リスナーによってすでに使用されている
Secret
の Kafka リスナー証明書を更新した場合でも、ローリングアップデートが開始されます。
11.7.2. Kafka リスナーのサーバー証明書の SAN
独自の Kafka リスナー証明書で TLS ホスト名検証を使用するには、リスナーごとに SAN (サブジェクト代替名) を使用する必要があります。証明書の SAN は、以下のホスト名を指定する必要があります。
- クラスターのすべての Kafka ブローカー
- Kafka クラスターブートストラップサービス
ワイルドカード証明書は、CA でサポートされれば使用できます。
11.7.2.1. TLS リスナー SAN の例
以下の例を利用して、TLS リスナーの証明書で SAN のホスト名を指定できます。
ワイルドカードの例
//Kafka brokers *.<cluster-name>-kafka-brokers *.<cluster-name>-kafka-brokers.<namespace>.svc // Bootstrap service <cluster-name>-kafka-bootstrap <cluster-name>-kafka-bootstrap.<namespace>.svc
ワイルドカードのない例
// Kafka brokers <cluster-name>-kafka-0.<cluster-name>-kafka-brokers <cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc <cluster-name>-kafka-1.<cluster-name>-kafka-brokers <cluster-name>-kafka-1.<cluster-name>-kafka-brokers.<namespace>.svc # ... // Bootstrap service <cluster-name>-kafka-bootstrap <cluster-name>-kafka-bootstrap.<namespace>.svc
11.7.2.2. 外部リスナー SAN の例
TLS 暗号化が有効になっている外部リスナーの場合、証明書に指定する必要があるホスト名は、外部リスナーの type
によって異なります。
外部リスナータイプ | SAN で指定する内容 |
---|---|
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
| Kafka ブローカー Pod がスケジュールされるすべての OpenShift ワーカーノードのアドレス。 一致するワイルドカード名を使用できます。 |
その他のリソース
第12章 AMQ Streams の管理
本章では、AMQ Streams のデプロイメントを維持するタスクについて説明します。
12.1. カスタムリソースの使用
oc
コマンドを使用して、AMQ Streams カスタムリソースで情報を取得し、他の操作を実行できます。
カスタムリソースの status
サブリソースと oc
を使用すると、リソースに関する情報を取得できます。
12.1.1. カスタムリソースでの oc
操作の実行
get
、describe
、edit
、または delete
などの oc
コマンドを使用して、リソースタイプで操作を実行します。たとえば、oc get kafkatopics
はすべての Kafka トピックのリストを取得し、oc get kafkas
はデプロイされたすべての Kafka クラスターを取得します。
リソースタイプを参照する場合は、単数名および複数名の両方を使用できます。oc get kafkas
は、oc get kafka
と同じ結果を得られます。
リソースの 短縮名 を使用することもできます。短縮名を理解すると、AMQ Streams を管理する時間を節約できます。Kafka
の短縮名は k
であるため、oc get k
を実行してすべての Kafka クラスターを一覧表示することもできます。
oc get k NAME DESIRED KAFKA REPLICAS DESIRED ZK REPLICAS my-cluster 3 3
AMQ Streams リソース | 正式名 | 短縮名 |
---|---|---|
Kafka | kafka | k |
Kafka Topic | kafkatopic | kt |
Kafka User | kafkauser | ku |
Kafka Connect | kafkaconnect | kc |
Kafka Connect S2I | kafkaconnects2i | kcs2i |
Kafka Connector | kafkaconnector | kctr |
Kafka Mirror Maker | kafkamirrormaker | kmm |
Kafka Mirror Maker 2 | kafkamirrormaker2 | kmm2 |
Kafka Bridge | kafkabridge | kb |
Kafka Rebalance | kafkarebalance | kr |
12.1.1.1. リソースカテゴリー
カスタムリソースのカテゴリーは oc
コマンドでも使用することができます。
すべての AMQ Streams カスタムリソースはカテゴリー strimzi
に属するため、strimzi
を使用すると 1 つのコマンドですべての AMQ Streams リソースを取得できます。
たとえば、oc get strimzi
を実行すると、指定の namespace のすべての AMQ Streams カスタムリソースが一覧表示されます。
oc get strimzi NAME DESIRED KAFKA REPLICAS DESIRED ZK REPLICAS kafka.kafka.strimzi.io/my-cluster 3 3 NAME PARTITIONS REPLICATION FACTOR kafkatopic.kafka.strimzi.io/kafka-apps 3 3 NAME AUTHENTICATION AUTHORIZATION kafkauser.kafka.strimzi.io/my-user tls simple
oc get strimzi -o name
コマンドは、すべてのリソースタイプおよびリソース名を返します。-o name
オプションは type/name 形式で出力を取得します。
oc get strimzi -o name kafka.kafka.strimzi.io/my-cluster kafkatopic.kafka.strimzi.io/kafka-apps kafkauser.kafka.strimzi.io/my-user
この strimzi
コマンドを他のコマンドと組み合わせることができます。たとえば、これを oc delete
コマンドに渡して、1 つのコマンドですべてのリソースを削除できます。
oc delete $(oc get strimzi -o name) kafka.kafka.strimzi.io "my-cluster" deleted kafkatopic.kafka.strimzi.io "kafka-apps" deleted kafkauser.kafka.strimzi.io "my-user" deleted
1 つの操作ですべてのリソースを削除することは、AMQ Streams の新機能をテストする場合などに役立ちます。
12.1.1.2. サブリソースのステータスのクエリー
他の値を -o
オプションに渡すことができます。たとえば、-o yaml
を使用すると、YAML 形式で出力されます。-o json
を使用すると JSON で返されます。
すべてのオプションは oc get --help
で確認できます。
最も便利なオプションの 1 つは JSONPath サポート で、JSONPath 式を渡して Kubernetes API にクエリーを実行できます。JSONPath 式は、リソースの特定部分を抽出または操作できます。
たとえば、JSONPath 式 {.status.listeners[?(@.type=="tls")].bootstrapServers}
を使用して、Kafka カスタムリソースのステータスからブートストラップアドレスを取得し、Kafka クライアントで使用できます。
このコマンドは、tls
リスナーの bootstrapServers
の値を見つけます。
oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.type=="tls")].bootstrapServers}{"\n"}' my-cluster-kafka-bootstrap.myproject.svc:9093
type 条件を @.type=="external"
または @.type=="plain"
に変更すると、他の Kafka リスナーのアドレスを取得することもできます。
oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}' 192.168.1.247:9094
jsonpath
を使用すると、カスタムリソースからその他のプロパティーやプロパティーのグループを抽出することができます。
12.1.2. AMQ Streams カスタムリソースのステータス情報
下記の表のとおり、複数のリソースに status
プロパティーがあります。
AMQ Streams リソース | スキーマ参照 | ステータス情報がパブリッシュされる場所 |
---|---|---|
| Kafka クラスター。 | |
| デプロイされている場合は Kafka Connect クラスター。 | |
| デプロイされている場合は Source-to-Image (S2I) サポートのある Kafka Connect クラスター。 | |
| デプロイされている場合は KafkaConnector リソース。 | |
| デプロイされている場合は Kafka MirrorMakerツール。 | |
| Kafka クラスターの Kafka トピック | |
| Kafka クラスターの Kafka ユーザー。 | |
| デプロイされている場合は AMQ Streams の Kafka Bridge。 |
リソースの status
プロパティーによって、リソースの下記項目の情報が提供されます。
-
status.conditions
プロパティーの Current state (現在の状態)。 -
status.observedGeneration
プロパティーの Last observed generation (最後に確認された生成)。
status
プロパティーによって、リソース固有の情報も提供されます。以下に例を示します。
-
KafkaStatus
によって、リスナーアドレスの情報と Kafka クラスターの ID が提供されます。 -
KafkaConnectStatus
によって、Kafka Connect コネクターの REST API エンドポイントが提供されます。 -
KafkaUserStatus
によって、Kafka ユーザーの名前と、ユーザーのクレデンシャルが保存されるSecret
が提供されます。 -
KafkaBridgeStatus
によって、外部クライアントアプリケーションが Bridge サービスにアクセスできる HTTP アドレスが提供されます。
リソースの Current state (現在の状態) は、spec
プロパティーによって定義される Desired state (望ましい状態) を実現するリソースに関する進捗を追跡するのに便利です。ステータス条件によって、リソースの状態が変更された時間および理由が提供され、Operator によるリソースの望ましい状態の実現を妨げたり遅らせたりしたイベントの詳細が提供されます。
Last observed generation (最後に確認された生成) は、Cluster Operator によって最後に照合されたリソースの生成です。observedGeneration
の値が metadata.generation
の値と異なる場合、リソースの最新の更新が Operator によって処理されていません。これらの値が同じである場合、リソースの最新の変更がステータス情報に反映されます。
AMQ Streams によってカスタムリソースのステータスが作成および維持されます。定期的にカスタムリソースの現在の状態が評価され、その結果に応じてステータスが更新されます。くださいーたとえば、oc edit
を使用してカスタムリソースで更新を行う場合、その status
は編集不可能です。さらに、status
の変更は Kafka クラスターステータスの設定に影響しません。
以下では、Kafka カスタムリソースに status
プロパティーが指定されています。
Kafka カスタムリソースとステータス
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: spec: # ... status: conditions: 1 - lastTransitionTime: 2021-07-23T23:46:57+0000 status: "True" type: Ready 2 observedGeneration: 4 3 listeners: 4 - addresses: - host: my-cluster-kafka-bootstrap.myproject.svc port: 9092 type: plain - addresses: - host: my-cluster-kafka-bootstrap.myproject.svc port: 9093 certificates: - | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- type: tls - addresses: - host: 172.29.49.180 port: 9094 certificates: - | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- type: external clusterId: CLUSTER-ID 5 # ...
- 1
- status の
conditions
は、既存のリソース情報から推測できないステータスに関連する基準や、リソースのインスタンスに固有する基準を記述します。 - 2
Ready
条件は、Cluster Operator が現在 Kafka クラスターでトラフィックの処理が可能であると判断するかどうかを示しています。- 3
observedGeneration
は、最後に Cluster Operator によって照合されたKafka
カスタムリソースの生成を示しています。- 4
listeners
は、現在の Kafka ブートストラップアドレスをタイプ別に示しています。- 5
- Kafka クラスター ID。重要
タイプが
nodeport
の外部リスナーのカスタムリソースステータスにおけるアドレスは、現在サポートされていません。
Kafka ブートストラップアドレスがステータスに一覧表示されても、それらのエンドポイントまたは Kafka クラスターが準備状態であるとは限りません。
ステータス情報のアクセス
リソースのステータス情報はコマンドラインから取得できます。詳細は、「カスタムリソースのステータスの検出」 を参照してください。
12.1.3. カスタムリソースのステータスの検出
この手順では、カスタムリソースのステータスを検出する方法を説明します。
前提条件
- OpenShift クラスターが必要です。
- Cluster Operator が稼働している必要があります。
手順
カスタムリソースを指定し、
-o jsonpath
オプションを使用して標準の JSONPath 式を適用してstatus
プロパティーを選択します。oc get kafka <kafka_resource_name> -o jsonpath='{.status}'
この式は、指定されたカスタムリソースのすべてのステータス情報を返します。
status.listeners
またはstatus.observedGeneration
などのドット表記を使用すると、表示するステータス情報を微調整できます。
その他のリソース
- 「AMQ Streams カスタムリソースのステータス情報」
- JSONPath の使用に関する詳細は、「JSONPath support」を参照してください。
12.2. カスタムリソースの調整の一時停止
修正や更新を実行するために、AMQ Streams Operator によって管理されるカスタムリソースの調整を一時停止すると便利な場合があります。調整が一時停止されると、カスタムリソースに加えられた変更は一時停止が終了するまで Operator によって無視されます。
カスタムリソースの調整を停止する場合は、設定で strimzi.io/pause-reconciliation
アノテーションを true
に設定します。これにより、適切な Operator がカスタムリソースの調整を一時停止するよう指示されます。たとえば、Cluster Operator による調整が一時停止されるように、アノテーションを KafkaConnect
リソースに適用できます。
pause アノテーションを有効にしてカスタムリソースを作成することもできます。カスタムリソースは作成されますが、無視されます。
現在、KafkaTopic
リソースの調整を一時停止することはできません。
前提条件
- カスタムリソースを管理する AMQ Streams Operator が稼働している必要があります。
手順
OpenShift のカスタムリソースにアノテーションを付け、
pause-reconciliation
をtrue
に設定します。oc annotate KIND-OF-CUSTOM-RESOURCE NAME-OF-CUSTOM-RESOURCE strimzi.io/pause-reconciliation="true"
たとえば、
KafkaConnect
カスタムリソースの場合は次のようになります。oc annotate KafkaConnect my-connect strimzi.io/pause-reconciliation="true"
カスタムリソースの status 条件で、
ReconciliationPaused
への変更が表示されていることを確認します。oc describe KIND-OF-CUSTOM-RESOURCE NAME-OF-CUSTOM-RESOURCE
lastTransitionTime
でtype
条件がReconciliationPaused
に変更されています。一時停止された調整条件タイプを持つカスタムリソースの例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: annotations: strimzi.io/pause-reconciliation: "true" strimzi.io/use-connector-resources: "true" creationTimestamp: 2021-03-12T10:47:11Z #... spec: # ... status: conditions: - lastTransitionTime: 2021-03-12T10:47:41.689249Z status: "True" type: ReconciliationPaused
一時停止からの再開
-
調整を再開するには、アノテーションを
false
に設定するか、アノテーションを削除します。
その他のリソース
12.3. Kafka および ZooKeeper クラスターの手動によるローリングアップデートの開始
AMQ Streams は、Cluster Operator 経由で Kafka および ZooKeeper クラスターのローリングアップデートを手動でトリガーするために、StatefulSet
および Pod
リソースのアノテーションの使用をサポートします。ローリングアップデートにより、新しい Pod でリソースの Pod が再起動されます。
通常、例外的な状況でのみ、特定の Pod や同じ StatefulSet
からの Pod のセットを手動で実行する必要があります。ただし、Pod を直接削除せずに、Cluster Operator 経由でローリングアップデートを実行すると、以下を確実に行うことができます。
- Pod を手動で削除しても、他の Pod を並行して削除するなどの、同時に行われる Cluster Operator の操作とは競合しません。
- Cluster Operator ロジックによって、In-Sync レプリカの数などの Kafka 設定で指定された内容が処理されます。
12.3.1. 前提条件
手動でローリングアップデートを実行するには、稼働中の Cluster Operator および Kafka クラスターが必要です。
以下を実行する方法については、『 OpenShift での AMQ Streams のデプロイおよびアップグレード』を参照してください。
12.3.2. StatefulSet アノテーションを使用したローリングアップデートの実行
この手順では、OpenShift StatefulSet
アノテーションを使用して、既存の Kafka クラスターまたは ZooKeeper クラスターのローリングアップデートを手動でトリガーする方法を説明します。
手順
手動で更新する Kafka または ZooKeeper Pod を制御する
StatefulSet
の名前を見つけます。たとえば、Kafka クラスターの名前が my-cluster の場合、対応する
StatefulSet
の名前は my-cluster-kafka と my-cluster-zookeeper になります。OpenShift で
StatefulSet
リソースにアノテーションを付けます。oc annotate
を使用します。oc annotate statefulset cluster-name-kafka strimzi.io/manual-rolling-update=true oc annotate statefulset cluster-name-zookeeper strimzi.io/manual-rolling-update=true
-
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。アノテーションが調整プロセスで検出されれば、アノテーションが付いた
StatefulSet
内のすべての Pod でローリングアップデートがトリガーされます。すべての Pod のローリングアップデートが完了すると、アノテーションはStatefulSet
から削除されます。
12.3.3. Pod アノテーションを使用したローリングアップデートの実行
この手順では、OpenShift Pod
アノテーションを使用して、既存の Kafka クラスターまたは ZooKeeper クラスターのローリングアップデートを手動でトリガーする方法を説明します。同じ StatefulSet
の複数の Pod にアノテーションが付けられると、連続したローリングアップデートは同じ調整実行内で実行されます。
手順
手動で更新する Kafka または ZooKeeper
Pod
の名前を見つけます。たとえば、Kafka クラスターの名前が my-cluster の場合、対応する
Pod
の名前は my-cluster-kafka-index と my-cluster-zookeeper-index になります。インデックス はゼロで始まり、レプリカの総数で終わります。OpenShift で
Pod
リソースにアノテーションを付けます。oc annotate
を使用します。oc annotate pod cluster-name-kafka-index strimzi.io/manual-rolling-update=true oc annotate pod cluster-name-zookeeper-index strimzi.io/manual-rolling-update=true
-
次の調整が発生するまで待ちます (デフォルトでは 2 分ごとです)。アノテーションが調整プロセスで検出されれば、アノテーションが付いた
Pod
のローリングアップデートがトリガーされます。Pod のローリングアップデートが完了すると、アノテーションはPod
から削除されます。
12.4. ラベルおよびアノテーションを使用したサービスの検出
サービスディスカバリーは、AMQ Streams と同じ OpenShift クラスターで稼働しているクライアントアプリケーションの Kafka クラスターとの対話を容易にします。
サービスディスカバリー ラベルおよびアノテーションは、Kafka クラスターにアクセスするために使用されるサービスに対して生成されます。
- 内部 Kafka ブートストラップサービス
- HTTP Bridge サービス
ラベルは、サービスの検出を可能にします。アノテーションは、クライアントアプリケーションが接続を確立するために使用できる接続詳細を提供します。
サービスディスカバリーラベル strimzi.io/discovery
は、Service
リソースに対して true
に設定されています。サービスディスカバリーアノテーションには同じキーがあり、各サービスの接続詳細を JSON 形式で提供します。
内部 Kafka ブートストラップサービスの例
apiVersion: v1 kind: Service metadata: annotations: strimzi.io/discovery: |- [ { "port" : 9092, "tls" : false, "protocol" : "kafka", "auth" : "scram-sha-512" }, { "port" : 9093, "tls" : true, "protocol" : "kafka", "auth" : "tls" } ] labels: strimzi.io/cluster: my-cluster strimzi.io/discovery: "true" strimzi.io/kind: Kafka strimzi.io/name: my-cluster-kafka-bootstrap name: my-cluster-kafka-bootstrap spec: #...
HTTP Bridge サービスの例
apiVersion: v1 kind: Service metadata: annotations: strimzi.io/discovery: |- [ { "port" : 8080, "tls" : false, "auth" : "none", "protocol" : "http" } ] labels: strimzi.io/cluster: my-bridge strimzi.io/discovery: "true" strimzi.io/kind: KafkaBridge strimzi.io/name: my-bridge-bridge-service
12.4.1. サービスの接続詳細の返信
サービスを検出するには、コマンドラインまたは対応する API 呼び出しでサービスを取得するときに、ディスカバリーラベルを指定します。
oc get service -l strimzi.io/discovery=true
サービスディスカバリーラベルの取得時に接続詳細が返されます。
12.5. 永続ボリュームからのクラスターの復元
Kafka クラスターは、永続ボリューム (PV) が存在していれば、そこから復元できます。
たとえば、以下の場合に行います。
- namespace が意図せずに削除された後。
- OpenShift クラスター全体が失われた後でも PV がインフラストラクチャーに残っている場合。
12.5.1. namespace が削除された場合の復元
永続ボリュームと namespace の関係により、namespace の削除から復元することが可能です。PersistentVolume
(PV) は、namespace の外部に存在するストレージリソースです。PV は、namespace 内部に存在する PersistentVolumeClaim
(PVC) を使用して Kafka Pod にマウントされます。
PV の回収 (reclaim) ポリシーは、namespace が削除されるときにクラスターに動作方法を指示します。以下に、回収 (reclaim) ポリシーの設定とその結果を示します。
- Delete (デフォルト) に設定すると、PVC が namespace 内で削除されるときに PV が削除されます。
- Retain に設定すると、namespace の削除時に PV は削除されません。
namespace が意図せず削除された場合に PV から復旧できるようにするには、PV 仕様で persistentVolumeReclaimPolicy
プロパティーを使用してポリシーを Delete から Retain にリセットする必要があります。
apiVersion: v1
kind: PersistentVolume
# ...
spec:
# ...
persistentVolumeReclaimPolicy: Retain
または、PV は、関連付けられたストレージクラスの回収 (reclaim) ポリシーを継承できます。ストレージクラスは、動的ボリュームの割り当てに使用されます。
ストレージクラスの reclaimPolicy
プロパティーを設定することで、ストレージクラスを使用する PV が適切な回収 (reclaim) ポリシー で作成されます。ストレージクラスは、storageClassName
プロパティーを使用して PV に対して設定されます。
apiVersion: v1 kind: StorageClass metadata: name: gp2-retain parameters: # ... # ... reclaimPolicy: Retain
apiVersion: v1
kind: PersistentVolume
# ...
spec:
# ...
storageClassName: gp2-retain
Retain を回収 (reclaim) ポリシーとして使用しながら、クラスター全体を削除する場合は、PV を手動で削除する必要があります。そうしないと、PV は削除されず、リソースに不要な経費がかかる原因になります。
12.5.2. OpenShift クラスター喪失からの復旧
クラスターが失われた場合、ディスク/ボリュームのデータがインフラストラクチャー内に保持されていれば、それらのデータを使用してクラスターを復旧できます。PV が復旧可能でそれらが手動で作成されていれば、復旧の手順は namespace の削除と同じです。
12.5.3. 削除したクラスターの永続ボリュームからの復元
この手順では、削除されたクラスターを永続ボリューム (PV) から復元する方法を説明します。
この状況では、Topic Operator はトピックが Kafka に存在することを認識しますが、KafkaTopic
リソースは存在しません。
クラスター再作成の手順を行うには、2 つの方法があります。
すべての
KafkaTopic
リソースを復旧できる場合は、オプション 1 を使用します。これにより、クラスターが起動する前に
KafkaTopic
リソースを復旧することで、該当するトピックが Topic Operator によって削除されないようにする必要があります。すべての
KafkaTopic
リソースを復旧できない場合は、オプション 2 を使用します。この場合、Topic Operator なしでクラスターをデプロイし、Topic Operator のトピックストアメタデータを削除してから、Topic Operator で Kafka クラスターを再デプロイすることで、該当するトピックから
KafkaTopic
リソースを再作成できるようにします。
Topic Operator がデプロイされていない場合は、PersistentVolumeClaim
(PVC) リソースのみを復旧する必要があります。
作業を始める前に
この手順では、データの破損を防ぐために PV を正しい PVC にマウントする必要があります。volumeName
が PVC に指定されており、それが PV の名前に一致する必要があります。
詳細は以下を参照してください。
この手順には、手動での再作成が必要な KafkaUser
リソースの復旧は含まれません。パスワードと証明書を保持する必要がある場合は、KafkaUser
リソースの作成前にシークレットを再作成する必要があります。
手順
クラスターの PV についての情報を確認します。
oc get pv
PV の情報がデータとともに表示されます。
この手順で重要な列を示す出力例:
NAME RECLAIMPOLICY CLAIM pvc-5e9c5c7f-3317-11ea-a650-06e1eadd9a4c ... Retain ... myproject/data-my-cluster-zookeeper-1 pvc-5e9cc72d-3317-11ea-97b0-0aef8816c7ea ... Retain ... myproject/data-my-cluster-zookeeper-0 pvc-5ead43d1-3317-11ea-97b0-0aef8816c7ea ... Retain ... myproject/data-my-cluster-zookeeper-2 pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c ... Retain ... myproject/data-0-my-cluster-kafka-0 pvc-7e21042e-3317-11ea-9786-02deaf9aa87e ... Retain ... myproject/data-0-my-cluster-kafka-1 pvc-7e226978-3317-11ea-97b0-0aef8816c7ea ... Retain ... myproject/data-0-my-cluster-kafka-2
- NAME は各 PV の名前を示します。
- RECLAIM POLICY は PV が 保持される ことを示します。
- CLAIM は元の PVC へのリンクを示します。
元の namespace を再作成します。
oc create namespace myproject
元の PVC リソース仕様を再作成し、PVC を該当する PV にリンクします。
以下に例を示します。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data-0-my-cluster-kafka-0 spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi storageClassName: gp2-retain volumeMode: Filesystem volumeName: pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c
PV 仕様を編集して、元の PVC にバインドされた
claimRef
プロパティーを削除します。以下に例を示します。
apiVersion: v1 kind: PersistentVolume metadata: annotations: kubernetes.io/createdby: aws-ebs-dynamic-provisioner pv.kubernetes.io/bound-by-controller: "yes" pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs creationTimestamp: "<date>" finalizers: - kubernetes.io/pv-protection labels: failure-domain.beta.kubernetes.io/region: eu-west-1 failure-domain.beta.kubernetes.io/zone: eu-west-1c name: pvc-7e226978-3317-11ea-97b0-0aef8816c7ea resourceVersion: "39431" selfLink: /api/v1/persistentvolumes/pvc-7e226978-3317-11ea-97b0-0aef8816c7ea uid: 7efe6b0d-3317-11ea-a650-06e1eadd9a4c spec: accessModes: - ReadWriteOnce awsElasticBlockStore: fsType: xfs volumeID: aws://eu-west-1c/vol-09db3141656d1c258 capacity: storage: 100Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: data-0-my-cluster-kafka-2 namespace: myproject resourceVersion: "39113" uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: failure-domain.beta.kubernetes.io/zone operator: In values: - eu-west-1c - key: failure-domain.beta.kubernetes.io/region operator: In values: - eu-west-1 persistentVolumeReclaimPolicy: Retain storageClassName: gp2-retain volumeMode: Filesystem
この例では、以下のプロパティーが削除されます。
claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: data-0-my-cluster-kafka-2 namespace: myproject resourceVersion: "39113" uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
Cluster Operator をデプロイします。
oc create -f install/cluster-operator -n my-project
クラスターを再作成します。
クラスターの再作成に必要なすべての
KafkaTopic
リソースがあるかどうかに応じて、以下の手順を実行します。オプション 1: クラスターを失う前に存在した
KafkaTopic
リソースが すべて ある場合 (__consumer_offsets
からコミットされたオフセットなどの内部トピックを含む)。すべての
KafkaTopic
リソースを再作成します。クラスターをデプロイする前にリソースを再作成する必要があります。そうでないと、Topic Operator によってトピックが削除されます。
Kafka クラスターをデプロイします。
以下に例を示します。
oc apply -f kafka.yaml
オプション 2: クラスターを失う前に存在したすべての
KafkaTopic
リソースがない場合。オプション 1 と同様に Kafka クラスターをデプロイしますが、デプロイ前に Kafka リソースから
topicOperator
プロパティーを削除して、Topic Operator がない状態でデプロイします。デプロイメントに Topic Operator が含まれると、Topic Operator によってすべてのトピックが削除されます。
Kafka クラスターから内部トピックストアのトピックを削除します。
oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete
このコマンドは、Kafka クラスターへのアクセスに使用されるリスナーおよび認証のタイプに対応している必要があります。
Kafka クラスターを
topicOperator
プロパティーで再デプロイして TopicOperator を有効にし、KafkaTopic
リソースを再作成します。以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: #... entityOperator: topicOperator: {} 1 #...
- 1
- ここで示すデフォルト設定には、追加のプロパティーはありません。「
EntityTopicOperatorSpec
スキーマ参照」に説明されているプロパティーを使用して、必要な設定を指定します。
KafkaTopic
リソースのリストを表示して、復旧を確認します。oc get KafkaTopic
12.6. クライアント設定のチューニング
設定プロパティーを使用して、Kafka プロデューサーおよびコンシューマーのパフォーマンスを最適化します。
最小セットの設定プロパティーが必要ですが、プロパティーを追加または調整して、プロデューサーとコンシューマーが Kafka と対話する方法を変更できます。たとえば、プロデューサーの場合は、クライアントがリアルタイムでデータに応答できるように、メッセージのレイテンシーおよびスループットをチューニングできます。また、設定を変更して、より強力にメッセージの持続性を保証することもできます。
クライアントメトリックを分析して初期設定を行う場所を判断することから始め、必要な設定になるまで段階的に変更を加え、さらに比較を行うことができます。
12.6.1. Kafka プロデューサー設定のチューニング
特定のユースケースに合わせて調整されたオプションのプロパティーとともに、基本的なプロデューサー設定を使用します。
設定を調整してスループットを最大化すると、レイテンシーが増加する可能性があり、その逆も同様です。必要なバランスを取得するために、プロデューサー設定を実験して調整する必要があります。
12.6.1.1. 基本のプロデューサー設定
接続およびシリアライザープロパティーはすべてのプロデューサーに必要です。通常、追跡用のクライアント ID を追加し、プロデューサーで圧縮してリクエストのバッチサイズを減らすことが推奨されます。
基本的なプロデューサー設定には以下が含まれます。
- パーティション内のメッセージの順序は保証されません。
- ブローカーに到達するメッセージの完了通知は持続性を保証しません。
# ... bootstrap.servers=localhost:9092 1 key.serializer=org.apache.kafka.common.serialization.StringSerializer 2 value.serializer=org.apache.kafka.common.serialization.StringSerializer 3 client.id=my-client 4 compression.type=gzip 5 # ...
- 1
- (必須) Kafka ブローカーの host:port ブートストラップサーバーアドレスを使用して Kafka クラスターに接続するようプロデューサーを指示します。プロデューサーはアドレスを使用して、クラスター内のすべてのブローカーを検出し、接続します。サーバーがダウンした場合に備えて、コンマ区切りリストを使用して 2 つまたは 3 つのアドレスを指定しますが、クラスター内のすべてのブローカーのリストを提供する必要はありません。
- 2
- (必須) メッセージがブローカーに送信される前に、各メッセージの鍵をバイトに変換するシリアライザー。
- 3
- (必須) メッセージがブローカーに送信される前に、各メッセージの値をバイトに変換するシリアライザー。
- 4
- (任意) クライアントの論理名。リクエストのソースを特定するためにログおよびメトリクスで使用されます。
- 5
- (任意) メッセージを圧縮するコーデック。これは、送信され、圧縮された形式で格納された後、コンシューマーへの到達時に圧縮解除される可能性があります。圧縮はスループットを改善し、ストレージの負荷を減らすのに役立ちますが、圧縮や圧縮解除のコストが異常に高い低レイテンシーのアプリケーションには不適切である場合があります。
12.6.1.2. データの持続性
メッセージ配信の完了通知を使用して、データの持続性を適用し、メッセージが失われる可能性を最小限に抑えることができます。
# ...
acks=all 1
# ...
- 1
acks=all
と指定すると、パーティションリーダーは、メッセージリクエストが正常に受信されたことを確認する前に、特定数のフォロワーに対してメッセージをレプリケートすることを強制されます。acks=all
の追加のチェックにより、プルデューサーがメッセージを送信してから完了通知を受信するまでのレイテンシーが増加します。
完了通知がプロデューサーに送信される前にメッセージをログに追加する必要のあるブローカーの数は、トピックの min.insync.replicas
設定によって決定されます。最初に、トピックレプリケーション係数を 3 にし、他のブローカーの In-Sync レプリカを 2 にするのが一般的です。この設定では、単一のブローカーが利用できない場合でもプロデューサーは影響を受けません。2 番目のブローカーが利用できなくなると、プロデューサーは完了通知を受信せず、それ以上のメッセージを生成できなくなります。
acks=all
をサポートするトピック設定
# ...
min.insync.replicas=2 1
# ...
- 1
2
In-Sync レプリカを使用します。デフォルトは1
です。
システムに障害が発生すると、バッファーの未送信データが失われる可能性があります。
12.6.1.3. 順序付き配信
メッセージは 1 度だけ配信されるため、べき等プロデューサーは重複を回避します。障害発生時でも配信の順序が維持されるように、ID とシーケンス番号がメッセージに割り当てられます。データの一貫性を維持するために acks=all
を使用している場合は、順序付き配信にべき等を有効にするのは妥当です。
べき等を使った順序付き配信
# ... enable.idempotence=true 1 max.in.flight.requests.per.connection=5 2 acks=all 3 retries=2147483647 4 # ...
パフォーマンスコストが原因で acks=all
およびべき等を使用しない場合は、インフライト (完了確認されない) リクエストの数を 1 に設定して、順序を保持します。そうしないと、Message-A が失敗し、Message-B がブローカーに書き込まれた後にのみ成功する可能性があります。
べき等を使用しない順序付け配信
# ... enable.idempotence=false 1 max.in.flight.requests.per.connection=1 2 retries=2147483647 # ...
12.6.1.4. 信頼性の保証
べき等は、1 つのパーティションへの書き込みを 1 回だけ行う場合に便利です。トランザクションをべき等と使用すると、複数のパーティション全体で 1 度だけ書き込みを行うことができます。
トランザクションは、同じトランザクション ID を使用するメッセージが 1 度作成され、すべてがそれぞれのログに書き込まれるか、何も書き込まれないかのどちらかになることを保証します。
# ... enable.idempotence=true max.in.flight.requests.per.connection=5 acks=all retries=2147483647 transactional.id=UNIQUE-ID 1 transaction.timeout.ms=900000 2 # ...
トランザクションの保証を維持するには、transactional.id
の選択が重要になります。トランザクション ID は、一意なトピックパーティションセットに使用する必要があります。たとえば、トピックパーティション名からトランザクション ID への外部マッピングを使用したり、競合を回避する関数を使用してトピックパーティション名からトランザクション IDを算出したりすると、これを実現できます。
12.6.1.5. スループットおよびレイテンシーの最適化
通常、システムの要件は、指定のレイテンシー内であるメッセージの割合に対して、特定のスループットのターゲットを達成することです。たとえば、95 % のメッセージが 2 秒以内に完了確認される、1 秒あたり 500,000 個のメッセージをターゲットとします。
プロデューサーのメッセージングセマンティック (メッセージの順序付けと持続性) は、アプリケーションの要件によって定義される可能性があります。たとえば、アプリケーションによって提供される重要なプロパティーや保証に反することなく、acks=0
または acks=1
を使用するオプションがない可能性があります。
ブローカーの再起動は、パーセンタイルの高いの統計に大きく影響します。たとえば、長期間では、99% のレイテンシーはブローカーの再起動に関する動作によるものです。これは、ベンチマークを設計したり、本番環境のパフォーマンスで得られた数字を使ってベンチマークを行い、そのパフォーマンスの数字を比較したりする場合に検討する価値があります。
目的に応じて、Kafka はスループットとレイテンシーのプロデューサーパフォーマンスを調整するために多くの設定パラメーターと設定方法を提供します。
- メッセージのバッチ処理 (
linger.ms
およびbatch.size
) -
メッセージのバッチ処理では、同じブローカー宛のメッセージをより多く送信するために、メッセージの送信を遅らせ、単一の生成リクエストでバッチ処理できるようにします。バッチ処理では、スループットを増やすためにレイテンシーを長くして妥協します。時間ベースのバッチ処理は
linger.ms
を使用して設定され、サイズベースのバッチ処理はbatch.size
を使用して設定されます。 - 圧縮処理 (
compression.type
) -
メッセージ圧縮処理により、プロデューサー (メッセージの圧縮に費やされた CPU 時間) のレイテンシーが追加されますが、リクエスト (および場合によってはディスクの書き込み) を小さくするため、スループットが増加します。圧縮に価値があるかどうか、および使用に最適な圧縮は、送信されるメッセージによって異なります。圧縮処理は
KafkaProducer.send()
を呼び出すスレッドで発生するため、アプリケーションでこの方法のレイテンシーが問題になる場合は、より多くのスレッドを使用するよう検討してください。 - パイプライン処理 (
max.in.flight.requests.per.connection
) - パイプライン処理は、以前のリクエストへの応答を受け取る前により多くのリクエストを送信します。通常、パイプライン処理を増やすと、バッチ処理の悪化などの別の問題がスループットに悪影響を与え始めるしきい値まではスループットが増加します。
レイテンシーの短縮
アプリケーションが KafkaProducer.send()
を呼び出す場合、メッセージには以下が行われます。
- インターセプターによる処理。
- シリアライズ。
- パーティションへの割り当て。
- 圧縮処理。
- パーティションごとのキューでメッセージのバッチに追加。
ここで、send()
メソッドが返されます。そのため、send()
がブロックされる時間は、以下によって決定されます。
- インターセプター、シリアライザー、およびパーティションヤーで費やされた時間。
- 使用される圧縮アルゴリズム。
- 圧縮に使用するバッファーの待機に費やされた時間。
バッチは、以下のいずれかが行われるまでキューに残ります。
-
バッチが満杯になる (
batch.size
による)。 -
linger.ms
によって導入された遅延が経過。 - 送信者は他のパーティションのメッセージバッチを同じブローカーに送信しようとし、このバッチの追加も可能。
- プロデューサーがフラッシュまたは閉じられる。
バッチ処理とバッファーの設定を参照して、レイテンシーをブロックする send()
の影響を軽減します。
# ... linger.ms=100 1 batch.size=16384 2 buffer.memory=33554432 3 # ...
スループットの増加
メッセージの配信および送信リクエストの完了までの最大待機時間を調整して、メッセージリクエストのスループットを向上します。
また、カスタムパーティションを作成してデフォルトを置き換えることで、メッセージを指定のパーティションに転送することもできます。
# ... delivery.timeout.ms=120000 1 partitioner.class=my-custom-partitioner 2 # ...
12.6.2. Kafka コンシューマー設定の調整
特定のユースケースに合わせて調整されたオプションのプロパティーとともに、基本的なコンシューマー設定を使用します。
コンシューマーを調整する場合、最も重要なことは、取得するデータ量に効率的に対処できるようにすることです。プロデューサーのチューニングと同様に、コンシューマーが想定どおりに動作するまで、段階的に変更を加える必要があります。
12.6.2.1. 基本的なコンシューマー設定
接続およびデシリアライザープロパティーはすべてのコンシューマーに必要です。通常、追跡用にクライアント ID を追加することが推奨されます。
コンシューマー設定では、後続の設定に関係なく、以下を行います。
- メッセージをスキップまたは再読み取りするようオフセットを変更しない限り、コンシューマーはメッセージを指定のオフセットから取得し、順番に消費します。
- オフセットはクラスターの別のブローカーに送信される可能性があるため、オフセットを Kafka にコミットした場合でも、ブローカーはコンシューマーが応答を処理したかどうかを認識しません。
# ... bootstrap.servers=localhost:9092 1 key.deserializer=org.apache.kafka.common.serialization.StringDeserializer 2 value.deserializer=org.apache.kafka.common.serialization.StringDeserializer 3 client.id=my-client 4 group.id=my-group-id 5 # ...
- 1
- (必須) Kafka ブローカーの host:port ブートストラップサーバーアドレスを使用して、コンシューマーが Kafka クラスターに接続するよう指示しますコンシューマーはアドレスを使用して、クラスター内のすべてのブローカーを検出し、接続します。サーバーがダウンした場合に備えて、コンマ区切りリストを使用して 2 つまたは 3 つのアドレスを指定しますが、クラスター内のすべてのブローカーのリストを提供する必要はありません。ロードバランサーサービスを使用して Kafka クラスターを公開する場合、可用性はロードバランサーによって処理されるため、サービスのアドレスのみが必要になります。
- 2
- (必須) Kafka ブローカーから取得されたバイトをメッセージキーに変換するデシリアライザー。
- 3
- (必須) Kafka ブローカーから取得されたバイトをメッセージ値に変換するデシリアライザー。
- 4
- (任意) クライアントの論理名。リクエストのソースを特定するためにログおよびメトリクスで使用されます。ID は、時間クォータの処理に基づいてコンシューマーにスロットリングを適用するために使用することもできます。
- 5
- (条件) コンシューマーがコンシューマーグループに参加するには、グループ ID が 必要 です。
コンシューマーグループは、特定のトピックから複数のプロデューサーによって生成される、典型的に大量のデータストリームを共有するのに使用します。コンシューマーは group.id
でグループ化され、メッセージをメンバー全体に分散できます。
12.6.2.2. コンシューマーグループを使用したデータ消費のスケーリング
コンシューマーグループは、特定のトピックから 1 つまたは複数のプロデューサーによって生成される、典型的な大量のデータストリームを共有します。group.id
プロパティーが同じコンシューマーは同じグループになります。グループ内のコンシューマーの 1 つがリーダーを選択し、パーティションをグループのコンシューマーにどのように割り当てるかを決定します。各パーティションは 1 つのコンシューマーにのみ割り当てることができます。
コンシューマーの数がパーティションよりも少ない場合、同じ group.id
を持つコンシューマーインスタンスを追加して、データの消費をスケーリングできます。コンシューマーをグループに追加して、パーティションの数より多くしても、スループットは改善されませんが、コンシューマーが機能しなくなったときに予備のコンシューマーを使用できます。より少ないコンシューマーでスループットの目標を達成できれば、リソースを節約できます。
同じコンシューマーグループのコンシューマーは、オフセットコミットとハートビートを同じブローカーに送信します。グループのコンシューマーの数が多いほど、ブローカーのリクエスト負荷が高くなります。
# ...
group.id=my-group-id 1
# ...
- 1
- グループ ID を使用してコンシューマーグループにコンシューマーを追加します。
12.6.2.3. メッセージの順序の保証
Kafka ブローカーは、トピック、パーティション、およびオフセット位置のリストからメッセージを送信するようブローカーに要求するコンシューマーからフェッチリクエストを受け取ります。
コンシューマーは、ブローカーにコミットされたのと同じ順序でメッセージを単一のパーティションで監視します。つまり、Kafka は単一パーティションのメッセージ のみ 順序付けを保証します。逆に、コンシューマーが複数のパーティションからメッセージを消費している場合、コンシューマーによって監視される異なるパーティションのメッセージの順序は、必ずしも送信順序を反映しません。
1 つのトピックからメッセージを厳格に順序付ける場合は、コンシューマーごとに 1 つのパーティションを使用します。
12.6.2.4. スループットおよびレイテンシーの最適化
クライアントアプリケーションが KafkaConsumer.poll()
を呼び出すときに返されるメッセージの数を制御します。
fetch.max.wait.ms
および fetch.min.bytes
プロパティーを使用して、Kafka ブローカーからコンシューマーによって取得されるデータの最小量を増やします。時間ベースのバッチ処理は fetch.max.wait.ms
を使用して設定され、サイズベースのバッチ処理は fetch.min.bytes
を使用して設定されます。
コンシューマーまたはブローカーの CPU 使用率が高い場合、コンシューマーからのリクエストが多すぎる可能性があります。リクエストの数を減らし、メッセージがより大きなバッチで配信されるように、fetch.max.wait.ms
および fetch.min.bytes
プロパティーを調整します。より高い値に調整することでスループットが改善されますが、レイテンシーのコストが発生します。生成されるデータ量が少ない場合、より高い値に調整することもできます。
たとえば、fetch.max.wait.ms
を 500ms に設定し、fetch.min.bytes
を 16384 バイトに設定した場合、Kafka がコンシューマーからフェッチリクエストを受信すると、いずれかのしきい値に最初に到達した時点で応答されます。
逆に、fetch.max.wait.ms
および fetch.min.bytes
プロパティーを低く設定すると、エンドツーエンドのレイテンシーを改善できます。
# ... fetch.max.wait.ms=500 1 fetch.min.bytes=16384 2 # ...
フェッチリクエストサイズの増加によるレイテンシーの短縮
fetch.max.bytes
および max.partition.fetch.bytes
プロパティーを使用して、Kafka ブローカーからコンシューマーによって取得されるデータの最大量を増やします。
fetch.max.bytes
プロパティーは、一度にブローカーから取得されるデータ量の上限をバイト単位で設定します。
max.partition.fetch.bytes
は、各パーティションに返されるデータ量の上限をバイト単位で設定します。これは、常に max.message.bytes
のブローカーまたはトピック設定に設定されたバイト数よりも大きくする必要があります。
クライアントが消費できるメモリーの最大量は、以下のように概算されます。
NUMBER-OF-BROKERS * fetch.max.bytes and NUMBER-OF-PARTITIONS * max.partition.fetch.bytes
メモリー使用量がこれに対応できる場合は、これら 2 つのプロパティーの値を増やすことができます。各リクエストでより多くのデータを許可すると、フェッチリクエストが少なくなるため、レイテンシーが向上されます。
# ... fetch.max.bytes=52428800 1 max.partition.fetch.bytes=1048576 2 # ...
12.6.2.5. オフセットをコミットする際のデータ損失または重複の回避
Kafka の 自動コミットメカニズム により、コンシューマーはメッセージのオフセットを自動的にコミットできます。有効にすると、コンシューマーはブローカーをポーリングして受信したオフセットを 5000ms 間隔でコミットします。
自動コミットのメカニズムは便利ですが、データ損失と重複のリスクが発生します。コンシューマーが多くのメッセージを取得および変換し、自動コミットの実行時にコンシューマーバッファーに処理されたメッセージがある状態でシステムがクラッシュすると、そのデータは失われます。メッセージの処理後、自動コミットの実行前にシステムがクラッシュした場合、リバランス後に別のコンシューマーインスタンスでデータが複製されます。
ブローカーへの次のポーリングの前またはコンシューマーが閉じられる前に、すべてのメッセージが処理された場合は、自動コミットによるデータの損失を回避できます。
データ損失や重複の可能性を最小限にするには、enable.auto.commit
を false
に設定し、クライアントアプリケーションを開発して、オフセットのコミットをさらに制御します。または、auto.commit.interval.ms
を使用して、コミットの間隔を減らすことができます。
# ...
enable.auto.commit=false 1
# ...
- 1
- 自動コミットを false に設定すると、オフセットのコミットの制御が強化されます。
enable.auto.commit
を false
に設定すると、すべて の処理が実行され、メッセージが消費された後にオフセットをコミットできます。たとえば、Kafka commitSync
および commitAsync
コミット API を呼び出すようにアプリケーションを設定できます。
commitSync
API は、ポーリングから返されるメッセージバッチのオフセットをコミットします。バッチのメッセージすべての処理が完了したら API を呼び出します。commitSync
API を使用する場合、アプリケーションはバッチの最後のオフセットがコミットされるまで新しいメッセージをポーリングしません。これがスループットに悪影響する場合は、コミットする頻度を減らすか、commitAsync
API を使用できます。commitAsync
API はブローカーがコミットリクエストに応答するまで待機しませんが、リバランス時にさらに重複が発生するリスクがあります。一般的なアプローチとして、両方のコミット API をアプリケーションで組み合わせ、コンシューマーをシャットダウンまたはリバランスの直前に commitSync
API を使用し、最終コミットが正常に実行されるようにします。
12.6.2.5.1. トランザクションメッセージの制御
プロデューサー側でトランザクション ID を使用し、べき等 (enable.idempotence=true
) を有効にして、1 回のみの配信の保証を検討してください。コンシューマー側で、isolation.level
プロパティーを使用して、コンシューマーによってトランザクションメッセージが読み取られる方法を制御できます。
isolation.level
プロパティーに有効な値は 2 つあります。
-
read_committed
-
read_uncommitted
(デフォルト)
コミットされたトランザクションメッセージのみがコンシューマーによって読み取られるようにするには、read_committed
を使用します。ただし、これによりトランザクションの結果を記録するトランザクションマーカー (committed または aborted) がブローカーによって書き込まれるまで、コンシューマーはメッセージを返すことができないため、エンドツーエンドのレイテンシーが長くなります。
# ...
enable.auto.commit=false
isolation.level=read_committed 1
# ...
- 1
- コミットされたメッセージのみがコンシューマーによって読み取られるように、
read_committed
に設定します。
12.6.2.6. データ損失を回避するための障害からの復旧
session.timeout.ms
および heartbeat.interval.ms
プロパティーを使用して、コンシューマーグループ内のコンシューマー障害をチェックし、復旧するのにかかる時間を設定します。
session.timeout.ms
プロパティーは、コンシューマーグループのコンシュマーが非アクティブであるとみなされ、そのグループのアクティブなコンシューマー間でリバランスがトリガーされる前に、ブローカーと通信できない最大時間をミリ秒単位で指定します。グループのリバランス時に、パーティションはグループのメンバーに再割り当てされます。
heartbeat.interval.ms
プロパティーは、コンシューマーがアクティブで接続されていることを示す、コンシューマーグループコーディネーターへのハートビートチェックの間隔をミリ秒単位で指定します。通常、ハートビートの間隔はセッションタイムアウトの間隔の 3 分の 2 にする必要があります。
session.timeout.ms
プロパティーの値を低く設定すると、失敗するコンシューマーが早期に発見され、リバランスがより迅速に実行されます。ただし、タイムアウトの値を低くしすぎて、ブローカーがハートビートを時間内に受信できず、不必要なリバランスがトリガーされることがないように気を付けてください。
ハートビートの間隔が短くなると、誤ってリバランスを行う可能性が低くなりますが、ハートビートを頻繁に行うとブローカーリソースのオーバーヘッドが増えます。
12.6.2.7. オフセットポリシーの管理
auto.offset.reset
プロパティーを使用して、オフセットをすべてコミットしなかった場合やコミットされたオフセットが有効でないまたは削除された場合の、コンシューマーの動作を制御します。
コンシューマーアプリケーションを初めてデプロイし、既存のトピックからメッセージを読み取る場合について考えてみましょう。group.id
が初めて使用されるため、__consumer_offsets
トピックには、このアプリケーションのオフセット情報は含まれません。新しいアプリケーションは、ログの始めからすべての既存メッセージの処理を開始するか、新しいメッセージのみ処理を開始できます。デフォルトのリセット値は、パーティションの最後から開始する latest
で、一部のメッセージは見逃されることを意味します。データの損失を回避し、処理量を増やすには、auto.offset.reset
を earliest
に設定し、パーティションの最初から開始します。
また、ブローカーに設定されたオフセットの保持期間 (offsets.retention.minutes
) が終了したときにメッセージが失われないようにするため、earliest
オプションを使用することも検討してください。コンシューマーグループまたはスタンドアロンコンシューマーが非アクティブで、保持期間中にオフセットをコミットしない場合、以前にコミットされたオフセットは __consumer_offsets
から削除されます。
# ... heartbeat.interval.ms=3000 1 session.timeout.ms=10000 2 auto.offset.reset=earliest 3 # ...
- 1
- 予想されるリバランスに応じて、ハートビートの間隔を短くして調整します。
- 2
- タイムアウトの期限が切れる前に Kafka ブローカーによってハートビートが受信されなかった場合、コンシューマーはコンシューマーグループから削除され、リバランスが開始されます。ブローカー設定に
group.min.session.timeout.ms
およびgroup.max.session.timeout.ms
がある場合は、セッションタイムアウト値はこの範囲内である必要があります。 - 3
- パーティションの最初に戻り、オフセットがコミットされなかった場合にデータの損失が発生しないようにするには、
earliest
に設定します。
1 つのフェッチリクエストで返されるデータ量が大きい場合、コンシューマーが処理する前にタイムアウトが発生することがあります。この場合は、max.partition.fetch.bytes
の値を低くするか、session.timeout.ms
の値を高くします。
12.6.2.8. リバランスの影響を最小限にする
グループのアクティブなコンシューマー間で行うパーティションのリバランスは、以下にかかる時間です。
- コンシューマーによるオフセットのコミット
- 作成される新しいコンシューマーグループ
- グループリーダーによるグループメンバーへのパーティションの割り当て。
- 割り当てを受け取り、取得を開始するグループのコンシューマー
明らかに、このプロセスは特にコンシューマーグループクラスターのローリング再起動時に繰り返し発生するサービスのダウンタイムを増やします。
このような場合、静的メンバーシップ の概念を使用してリバランスの数を減らすことができます。リバランスによって、コンシューマーグループメンバー全体でトピックパーティションが割り当てられます。静的メンバーシップは永続性を使用し、セッションタイムアウト後の再起動時にコンシューマーインスタンスが認識されるようにします。
コンシューマーグループコーディネーターは、group.instance.id
プロパティーを使用して指定される一意の ID を使用して新しいコンシューマーインスタンスを特定できます。再起動時には、コンシューマーには新しいメンバー ID が割り当てられますが、静的メンバーとして、同じインスタンス ID を使用し、同じトピックパーティションの割り当てが行われます。
コンシューマーアプリケーションが最低でも max.poll.interval.ms
ミリ秒毎にポーリングへの呼び出しを行わない場合、コンシューマーは失敗したと見なされ、リバランスが発生します。アプリケーションがポーリングから返されたすべてレコードを時間内に処理できない場合は、max.poll.interval.ms
プロパティーを使用して、コンシューマーからの新規メッセージのポーリングの間隔をミリ秒単位で指定して、リバランスの発生を防ぎます。または、max.poll.records
プロパティーを使用して、コンシューマーバッファーから返されるレコードの数の上限を設定し、アプリケーションが max.poll.interval.ms
内でより少ないレコードを処理できるようにします。
# ... group.instance.id=UNIQUE-ID 1 max.poll.interval.ms=300000 2 max.poll.records=500 3 # ...
12.7. AMQ Streams のアンインストール
この手順では、AMQ Streams をアンインストールし、デプロイメントに関連するリソースを削除する方法を説明します。
前提条件
この手順を実行するには、デプロイメント用に特別に作成され、AMQ Streams リソースから参照されるリソースを特定します。
このようなリソースには以下があります。
- シークレット (カスタム CA および証明書、Kafka Connect Secrets、その他の Kafka シークレット)
-
ロギング
ConfigMaps
(タイプはexternal
)
これらのリソースは、Kafka
、KafkaConnect
、KafkaConnectS2I
、KafkaMirrorMaker
、または KafkaBridge
設定によって参照されます。
手順
Cluster Operator の
Deployment
、関連するCustomResourceDefinitions
およびRBAC
リソースを削除します。oc delete -f install/cluster-operator
警告CustomResourceDefinitions
を削除すると、対応するカスタムリソース (Kafka
、KafkaConnect
、KafkaConnectS2I
、KafkaMirrorMaker
、またはKafkaBridge
) 、およびそれらに依存するリソース (Deployments、StatefulSets、その他の依存リソース) のガベージコレクションが実行されます。- 前提条件で特定したリソースを削除します。
12.8. よくある質問
第13章 カスタムリソース API のリファレンス
13.1. 共通の設定プロパティー
共通設定プロパティーは複数のリソースに適用されます。
13.1.1. replicas
replicas
プロパティーを使用してレプリカを設定します。
レプリケーションのタイプはリソースによって異なります。
-
KafkaTopic
はレプリケーション係数を使用して、Kafka クラスター内のパーティションごとのレプリカ数を設定します。 - Kafka コンポーネントはレプリカを使用してデプロイメントの Pod 数を設定し、可用性とスケーラビリティーを向上します。
OpenShift で Kafka コンポーネントを実行している場合、高可用性のために複数のレプリカを実行する必要がない場合があります。コンポーネントがデプロイされたノードがクラッシュすると、OpenShift によって自動的に Kafka コンポーネント Pod が別のノードに再スケジュールされます。ただし、複数のレプリカで Kafka コンポーネントを実行すると、他のノードが稼働しているため、フェイルオーバー時間が短縮されます。
13.1.2. bootstrapServers
bootstrapServers
プロパティーを使用してブートストラップサーバーのリストを設定します。
ブートストラップサーバーリストは、同じ OpenShift クラスターにデプロイされていない Kafka クラスターを参照できます。AMQ Streams によってデプロイされた Kafka クラスターを参照することもできます。
同じ OpenShift クラスターである場合、各リストに CLUSTER-NAME-kafka-bootstrap
という名前の Kafka クラスターブートストラップサービスとポート番号が含まれる必要がありますAMQ Streams によって異なる OpenShift クラスターにデプロイされた場合、リストの内容はクラスターを公開するために使用された方法によって異なります (route、ingress、nodeport、または loadbalancer)。
AMQ Streams によって管理されない Kafka クラスターで Kafka を使用する場合は、指定のクラスターの設定に応じてブートストラップサーバーのリストを指定できます。
13.1.3. ssl
TLS バージョンの特定の 暗号スイート を使用して、クライアント接続に許可される 3 つの ssl
設定オプションを使用します。暗号スイートは、セキュアな接続とデータ転送のためのアルゴリズムを組み合わせます。
また、ssl.endpoint.identification.algorithm
プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。
SSL の設定例
# ... spec: config: ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 1 ssl.enabled.protocols: "TLSv1.2" 2 ssl.protocol: "TLSv1.2" 3 ssl.endpoint.identification.algorithm: HTTPS 4 # ...
13.1.4. trustedCertificates
tls
を設定して TLS による暗号化を設定したら、trustedCertificates
プロパティーを使用して、証明書が X.509 形式で保存される鍵の名前でシークレットの一覧を提供します。
Kafka クラスターの Cluster Operator によって作成されるシークレットを使用するか、独自の TLS 証明書ファイルを作成してから、ファイルから Secret
を作成できます。
oc create secret generic MY-SECRET \ --from-file=MY-TLS-CERTIFICATE-FILE.crt
TLS による暗号化の設定例
tls: trustedCertificates: - secretName: my-cluster-cluster-cert certificate: ca.crt - secretName: my-cluster-cluster-cert certificate: ca2.crt
複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。
TLS を有効にし、Java に同梱されるデフォルトの公開認証局のセットを使用する場合は、trustedCertificates
を空の配列として指定します。
デフォルトの Java 証明書で TLS を有効にする例
tls: trustedCertificates: []
TLS クライアント認証の設定に関する詳細は、「KafkaClientAuthenticationTls
スキーマ参照」を参照してください。
13.1.5. resources
コンポーネントの CPU およびメモリーリソースを要求します。制限によって、指定のコンテナーが消費可能な最大リソースが指定されます。
Topic Operator および User Operator のリソース要求および制限は Kafka
リソースに設定されます。
reources.requests
および resources.limits
プロパティーを使用して、リソース要求および制限を設定します。
AMQ Streams では、デプロイされたコンテナーごとに特定のリソースを要求し、これらのリソースの最大消費を定義できます。
AMQ Streams では、以下のリソースタイプの要求および制限がサポートされます。
-
cpu
-
memory
AMQ Streams では、このようなリソースの指定に OpenShift の構文が使用されます。
OpenShift におけるコンピュートリソースの管理に関する詳細は、「Managing Compute Resources for Containers」を参照してください。
リソース要求
要求によって、指定のコンテナーに対して予約するリソースが指定されます。リソースを予約すると、リソースが常に利用できるようになります。
リソース要求が OpenShift クラスターで利用可能な空きリソースを超える場合、Pod はスケジュールされません。
1 つまたは複数のサポートされるリソースに対してリクエストを設定できます。
リソース要求の設定例
# ... resources: requests: cpu: 12 memory: 64Gi # ...
リソース制限
制限によって、指定のコンテナーが消費可能な最大リソースが指定されます。制限は予約されず、常に利用できるとは限りません。コンテナーは、リソースが利用できる場合のみ、制限以下のリソースを使用できます。リソース制限は、常にリソース要求よりも高くする必要があります。
1 つまたは複数のサポートされる制限に対してリソースを設定できます。
リソース制限の設定例
# ... resources: limits: cpu: 12 memory: 64Gi # ...
サポートされる CPU 形式
CPU の要求および制限は以下の形式でサポートされます。
-
整数値 (
5
CPU コア) または少数 (2.5
CPU コア) の CPU コアの数。 -
数値または ミリ CPU / ミリコア (
100m
)。1000 ミリコア は1
CPU コアと同じです。
CPU ユニットの例
# ... resources: requests: cpu: 500m limits: cpu: 2.5 # ...
1 つの CPU コアのコンピューティング能力は、OpenShift がデプロイされたプラットフォームによって異なることがあります。
CPU 仕様の詳細は、「Meaning of CPU」を参照してください。
サポートされるメモリー形式
メモリー要求および制限は、メガバイト、ギガバイト、メビバイト、およびギビバイトで指定されます。
-
メモリーをメガバイトで指定するには、
M
接尾辞を使用します。例:1000M
-
メモリーをギガバイトで指定するには、
G
接尾辞を使用します。例:1G
-
メモリーをメビバイトで指定するには、
Mi
接尾辞を使用します。例:1000Mi
-
メモリーをギビバイトで指定するには、
Gi
接尾辞を使用します。例:1Gi
異なるメモリー単位を使用するリソースの例
# ... resources: requests: memory: 512Mi limits: memory: 2Gi # ...
メモリーの指定およびサポートされるその他の単位に関する詳細は、「Meaning of memory」を参照してください。
13.1.6. image
image
プロパティーを使用して、コンポーネントによって使用されるコンテナーイメージを設定します。
コンテナーイメージのオーバーライドは、別のコンテナーレジストリーやカスタマイズされたイメージを使用する必要がある特別な状況でのみ推奨されます。
たとえば、ネットワークで AMQ Streams によって使用されるコンテナーリポジトリーへのアクセスが許可されない場合、AMQ Streams イメージのコピーまたはソースからのビルドを行うことができます。しかし、設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。
コンテナーイメージのコピーはカスタマイズでき、デバッグに使用されることもあります。
以下のリソースの image
プロパティーを使用すると、コンポーネントに使用するコンテナーイメージを指定できます。
-
Kafka.spec.kafka
-
Kafka.spec.zookeeper
-
Kafka.spec.entityOperator.topicOperator
-
Kafka.spec.entityOperator.userOperator
-
Kafka.spec.entityOperator.tlsSidecar
-
KafkaConnect.spec
-
KafkaConnectS2I.spec
-
KafkaMirrorMaker.spec
-
KafkaMirrorMaker2.spec
-
KafkaBridge.spec
Kafka、Kafka Connect、および Kafka MirrorMaker の image
プロパティーの設定
Kafka、Kafka Connect (S2I サポートのある Kafka Connect を含む)、および Kafka MirrorMaker では、複数のバージョンの Kafka がサポートされます。各コンポーネントには独自のイメージが必要です。異なる Kafka バージョンのデフォルトイメージは、以下の環境変数で設定されます。
-
STRIMZI_KAFKA_IMAGES
-
STRIMZI_KAFKA_CONNECT_IMAGES
-
STRIMZI_KAFKA_CONNECT_S2I_IMAGES
-
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES
これらの環境変数には、Kafka バージョンと対応するイメージ間のマッピングが含まれます。マッピングは、image
および version
プロパティーとともに使用されます。
-
image
とversion
のどちらもカスタムリソースに指定されていない場合、version
は Cluster Operator のデフォルトの Kafka バージョンに設定され、環境変数のこのバージョンに対応するイメージが指定されます。 -
image
が指定されていてもversion
が指定されていない場合、指定されたイメージが使用され、Cluster Operator のデフォルトの Kafka バージョンがversion
であると想定されます。 -
version
が指定されていてもimage
が指定されていない場合、環境変数の指定されたバージョンに対応するイメージが使用されます。 -
version
とimage
の両方を指定すると、指定されたイメージが使用されます。このイメージには、指定のバージョンの Kafka イメージが含まれると想定されます。
異なるコンポーネントの image
および version
は、以下のプロパティーで設定できます。
-
Kafka の場合は
spec.kafka.image
およびspec.kafka.version
。 -
Kafka Connect、Kafka Connect S2I、および Kafka MirrorMaker の場合は
spec.image
およびspec.version
。
version
のみを提供し、image
プロパティーを未指定のままにしておくことが推奨されます。これにより、カスタムリソースの設定時に間違いが発生する可能性が低減されます。異なるバージョンの Kafka に使用されるイメージを変更する必要がある場合は、Cluster Operator の環境変数を設定することが推奨されます。
他のリソースでの image
プロパティーの設定
他のカスタムリソースの image
プロパティーでは、デプロイメント中に指定の値が使用されます。image
プロパティーがない場合、Cluster Operator 設定に指定された image
が使用されます。image
名が Cluster Operator 設定に定義されていない場合、デフォルト値が使用されます。
Topic Operator の場合:
-
Cluster Operator 設定から
STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
コンテナーイメージ。
-
Cluster Operator 設定から
User Operator の場合:
-
Cluster Operator 設定から
STRIMZI_DEFAULT_USER_OPERATOR_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
コンテナーイメージ。
-
Cluster Operator 設定から
Entity Operator TLS サイドカーの場合:
-
Cluster Operator 設定から
STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
コンテナーイメージ。
-
Cluster Operator 設定から
Kafka Exporter の場合:
-
Cluster Operator 設定から
STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-kafka-27-rhel7:1.7.0
コンテナーイメージ。
-
Cluster Operator 設定から
Kafka Bridge の場合:
-
Cluster Operator 設定から
STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-bridge-rhel7:1.7.0
コンテナーイメージ。
-
Cluster Operator 設定から
Kafka ブローカーイニシャライザーの場合:
-
Cluster Operator 設定から
STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
コンテナーイメージ。
-
Cluster Operator 設定から
コンテナーイメージ設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... image: my-org/my-image:latest # ... zookeeper: # ...
13.1.7. livenessProbe
および readinessProbe
ヘルスチェック
livenessProbe
および readinessProbe
プロパティーを使用して、AMQ Streams でサポートされるヘルスチェックプローブを設定します。
ヘルスチェックは、アプリケーションの健全性を検証する定期的なテストです。ヘルスチェックプローブが失敗すると、OpenShift によってアプリケーションが正常でないと見なされ、その修正が試行されます。
プローブの詳細は、「Configure Liveness and Readiness Probes」を参照してください。
livenessProbe
および readinessProbe
の両方によって以下のオプションがサポートされます。
-
initialDelaySeconds
-
timeoutSeconds
-
periodSeconds
-
successThreshold
-
failureThreshold
Liveness および Readiness プローブの設定例
# ... readinessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 # ...
livenessProbe
および readinessProbe
オプションの詳細については、「Probe スキーマ参照」を参照してください。
13.1.8. metricsConfig
metricsConfig
プロパティーを使用して、Prometheus メトリクスを有効化および設定します。
metricsConfig
プロパティーには、Prometheus JMX エスクポーター の追加設定が含まれる ConfigMap への参照が含まれます。AMQ Streams では、Apache Kafka および ZooKeeper によってサポートされる JMX メトリクスを Prometheus メトリクスに変換するために、Prometheus JMX エクスポーターを使用した Prometheus メトリクスがサポートされます。
追加設定なしで Prometheus メトリクスのエクスポートを有効にするには、metricsConfig.valueFrom.configMapKeyRef.key
下で空のファイルが含まれる ConfigMap を参照します。空のファイルを参照する場合、名前が変更されていない限り、すべてのメトリクスが公開されます。
Kafka のメトリクス設定が含まれる ConfigMap の例
kind: ConfigMap apiVersion: v1 metadata: name: my-configmap data: my-key: | lowercaseOutputName: true rules: # Special cases and very specific rules - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value name: kafka_server_$1_$2 type: GAUGE labels: clientId: "$3" topic: "$4" partition: "$5" # further configuration
Kafka のメトリクス設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... metricsConfig: type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: my-config-map key: my-key # ... zookeeper: # ...
有効になったメトリクスは、9404 番ポートで公開されます。
metricsConfig
(または非推奨となった metrics
) プロパティーがリソースに定義されていない場合、Prometheus メトリクスは無効になります。
Prometheus および Grafana の設定およびデプロイに関する詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Kafka へのメトリクスの導入」を参照してください。
13.1.9. jvmOptions
以下の AMQ Streams コンポーネントは、Java 仮想マシン (JVM) 内で実行されます。
- Apache Kafka
- Apache ZooKeeper
- Apache Kafka Connect
- Apache Kafka MirrorMaker
- AMQ Streams Kafka Bridge
異なるプラットフォームやアーキテクチャーでパフォーマンスを最適化するには、以下のリソースで jvmOptions
プロパティーを設定します。
-
Kafka.spec.kafka
-
Kafka.spec.zookeeper
-
KafkaConnect.spec
-
KafkaConnectS2I.spec
-
KafkaMirrorMaker.spec
-
KafkaMirrorMaker2.spec
-
KafkaBridge.spec
設定では、以下のオプションを指定できます。
-Xms
- JVM の起動時に最初に割り当てられる最小ヒープサイズ。
-Xmx
- 最大ヒープサイズ。
-XX
- JVM の高度なランタイムオプション。
javaSystemProperties
- 追加のシステムプロパティー。
gcLoggingEnabled
- ガベッジコレクターのロギングを有効にします。
jvmOptions
の完全なスキーマは、「JvmOptions
スキーマ参照」に記載されています。
-Xmx
や -Xms
などの JVM 設定で使用できる単位は、対応するイメージの JDK java
バイナリーで使用できる単位と同じです。そのため、1g
または 1G
は 1,073,741,824 バイトを意味し、Gi
はサフィックスとして有効な単位ではありません。これは、1G
は 1,000,000,000 バイトを意味し、1Gi
は 1,073,741,824 バイトを意味する OpenShift の慣例に準拠している メモリー要求および制限 に使用される単位とは異なります。
-Xms
および -Xmx
オプション
-Xms
および -Xmx
に使用されるデフォルト値は、コンテナーに メモリー要求 の制限が設定されているかどうかによって異なります。
- メモリーの制限がある場合は、JVM の最小および最大メモリーは制限に対応する値に設定されます。
-
メモリーの制限がない場合、JVM の最小メモリーは
128M
に設定されます。JVM の最大メモリーは、必要に応じてメモリーを拡張するようには定義されていません。これは、テストおよび開発での単一ノード環境に適しています。
-Xmx
を明示的に設定する前に、以下を考慮してください。
-
JVM のメモリー使用量の合計は、
-Xmx
によって設定された最大ヒープの約 4 倍になります。 -
適切な OpenShift メモリー制限を設定せずに
-Xmx
が設定された場合、OpenShift ノードで、実行されている他の Pod からメモリー不足が発生するとコンテナーが強制終了される可能性があります。 -
適切な OpenShift メモリー要求を設定せずに
-Xmx
が設定された場合、コンテナーはメモリー不足のノードにスケジュールされる可能性があります。この場合、-Xms
が-Xmx
に設定されていると、コンテナーは起動せずに即座にクラッシュし、設定されていないと後でクラッシュします。
以下を行うことが推奨されます。
- メモリー要求とメモリー制限を同じ値に設定します。
-
-Xmx
の 4.5 倍以上のメモリー要求を使用します。 -
-Xms
を-Xmx
と同じ値に設定することを検討してください。
この例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。メモリー使用量の合計は約 8GiB です。
-Xmx
および -Xms
の設定例
# ... jvmOptions: "-Xmx": "2g" "-Xms": "2g" # ...
最初のヒープサイズ (-Xms
) および最大ヒープサイズ (-Xmx
) に同じ値を設定すると、JVM が必要以上のヒープを割り当てて起動後にメモリーを割り当てないようにすることができます。
Kafka ブローカーコンテナーなど、多数のディスク I/O を実行するコンテナーには、オペレーティングシステムのページキャッシュとして使用できるメモリーが必要です。このようなコンテナーでは、要求されるメモリーは JVM によって使用されるメモリーよりもはるかに多くなります。
-XX オプション
-XX
オプションは、Apache Kafka の KAFKA_JVM_PERFORMANCE_OPTS
オプションの設定に使用されます。
-XX
の設定例
jvmOptions: "-XX": "UseG1GC": true "MaxGCPauseMillis": 20 "InitiatingHeapOccupancyPercent": 35 "ExplicitGCInvokesConcurrent": true
-XX
設定からの JVM オプション
-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -XX:-UseParNewGC
-XX
オプションを指定しないと、Apache Kafka のデフォルト設定 KAFKA_JVM_PERFORMANCE_OPTS
が使用されます。
javaSystemProperties
javaSystemProperties
は、デバッグユーティリティーなどの追加の Java システムプロパティーの設定に使用されます。
javaSystemProperties
の設定例
jvmOptions: javaSystemProperties: - name: javax.net.debug value: ssl
13.1.10. ガベッジコレクターのロギング
jvmOptions
プロパティーでは、ガベージコレクター (GC) のロギングを有効または無効にすることもできます。GC ロギングはデフォルトで無効になっています。これを有効にするには、以下のように gcLoggingEnabled
プロパティーを設定します。
GC ロギングの設定例
# ... jvmOptions: gcLoggingEnabled: true # ...
13.2. スキーマプロパティー
13.2.1. Kafka
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka および ZooKeeper クラスター、Topic Operator の仕様。 |
status | Kafka および ZooKeeper クラスター、Topic Operator のステータス。 |
13.2.2. KafkaSpec
スキーマ参照
Kafka
で使用
プロパティー | 説明 |
---|---|
kafka | Kafka クラスターの設定。 |
zookeeper | ZooKeeper クラスターの設定。 |
topicOperator |
|
entityOperator | Entity Operator の設定。 |
clusterCa | クラスター認証局の設定。 |
clientsCa | クライアント認証局の設定。 |
cruiseControl | Cruise Control デプロイメントの設定。指定時に Cruise Control インスタンスをデプロイします。 |
kafkaExporter | Kafka Exporter の設定。Kafka Exporter は追加のメトリクスを提供できます (例: トピック/パーティションでのコンシューマーグループのラグなど)。 |
maintenanceTimeWindows | メンテナンスタスク (証明書の更新) 用の時間枠の一覧。それぞれの時間枠は、cron 式で定義されます。 |
string array |
13.2.3. KafkaClusterSpec
スキーマ参照
KafkaSpec
で使用
KafkaClusterSpec
スキーマプロパティーの完全リスト
Kafka クラスターを設定します。
13.2.3.1. listeners
listeners
プロパティーを使用して、Kafka ブローカーへのアクセスを提供するようにリスナーを設定します。
認証のないプレーン (暗号化されていない) リスナーの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: plain port: 9092 type: internal tls: false # ... zookeeper: # ...
13.2.3.2. config
config
プロパティーを使用して、Kafka ブローカーオプションをキーとして設定します。
標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
以下に関連する設定オプションは設定できません。
- セキュリティー (暗号化、認証、および承認)
- リスナーの設定
- Broker ID の設定
- ログデータディレクトリーの設定
- ブローカー間の通信
- ZooKeeper の接続
値は以下の JSON タイプのいずれかになります。
- 文字列
- 数値
- ブール値
AMQ Streams で直接管理されるオプションを除き、Apache Kafka ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。
-
listeners
-
advertised.
-
broker.
-
listener.
-
host.name
-
port
-
inter.broker.listener.name
-
sasl.
-
ssl.
-
security.
-
password.
-
principal.builder.class
-
log.dir
-
zookeeper.connect
-
zookeeper.set.acl
-
authorizer.
-
super.user
禁止されているオプションが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。サポートされるその他すべてのオプションは Kafka に渡されます。
禁止されているオプションには例外があります。TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。zookeeper.connection.timeout.ms
プロパティーを設定して、ZooKeeper 接続の確立に許可される最大時間も設定できます。
Kafka ブローカーの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... config: num.partitions: 1 num.recovery.threads.per.data.dir: 1 default.replication.factor: 3 offsets.topic.replication.factor: 3 transaction.state.log.replication.factor: 3 transaction.state.log.min.isr: 1 log.retention.hours: 168 log.segment.bytes: 1073741824 log.retention.check.interval.ms: 300000 num.network.threads: 3 num.io.threads: 8 socket.send.buffer.bytes: 102400 socket.receive.buffer.bytes: 102400 socket.request.max.bytes: 104857600 group.initial.rebalance.delay.ms: 0 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" zookeeper.connection.timeout.ms: 6000 # ...
13.2.3.3. brokerRackInitImage
ラックアウェアネス (Rack Awareness) が有効である場合、Kafka ブローカー Pod は init コンテナーを使用して OpenShift クラスターノードからラベルを収集します。このコンテナーに使用されるコンテナーイメージは、brokerRackInitImage
プロパティーを使用して設定できます。brokerRackInitImage
フィールドがない場合、優先順位順に以下のイメージが使用されます。
-
Cluster Operator 設定の
STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
環境変数に指定されたコンテナーイメージ。 -
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.7.0
コンテナーイメージ。
brokerRackInitImage
の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... rack: topologyKey: topology.kubernetes.io/zone brokerRackInitImage: my-org/my-image:latest # ...
コンテナーイメージのオーバーライドは、別のコンテナーレジストリーを使用する必要がある特別な状況でのみ推奨されます。たとえば、AMQ Streams によって使用されるコンテナーレジストリーにネットワークがアクセスできない場合などがこれに該当します。この場合は、AMQ Streams イメージをコピーするか、ソースからビルドする必要があります。設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。
13.2.3.4. logging
Kafka には独自の設定可能なロガーがあります。
-
log4j.logger.org.I0Itec.zkclient.ZkClient
-
log4j.logger.org.apache.zookeeper
-
log4j.logger.kafka
-
log4j.logger.org.apache.kafka
-
log4j.logger.kafka.request.logger
-
log4j.logger.kafka.network.Processor
-
log4j.logger.kafka.server.KafkaApis
-
log4j.logger.kafka.network.RequestChannel$
-
log4j.logger.kafka.controller
-
log4j.logger.kafka.log.LogCleaner
-
log4j.logger.state.change.logger
-
log4j.logger.kafka.authorizer.logger
Kafka では Apache log4j
ロガー実装が使用されます。
logging
プロパティーを使用してロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # ... kafka: # ... logging: type: inline loggers: kafka.root.logger.level: "INFO" # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: kafka-log4j.properties # ...
設定されていない利用可能なロガーのレベルは OFF
に設定されています。
Cluster Operator を使用して Kafka がデプロイされた場合、Kafka のロギングレベルの変更は動的に適用されます。
外部ロギングを使用する場合は、ロギングアペンダーが変更されるとローリングアップデートがトリガーされます。
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.3.5. KafkaClusterSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
version | Kafka ブローカーのバージョン。デフォルトは 2.7.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。 |
string | |
replicas | クラスター内の Pod 数。 |
integer | |
image |
Pod の Docker イメージ。デフォルト値は、設定した |
string | |
listeners | Kafka ブローカーのリスナーを設定します。 |
config | 次の接頭辞のある Kafka ブローカーの config プロパティーは設定できません: listeners、advertised.、broker.、listener.、 host.name、port、inter.broker.listener.name、sasl.、ssl.、 security.、password.、principal.builder.class、log.dir、 zookeeper.connect、zookeeper.set.acl、zookeeper.ssl、zookeeper.clientCnxnSocket、authorizer.、super.user、cruise.control.metrics.topic、cruise.control.metrics.reporter.bootstrap.servers (次の例外を除く: zookeeper.connection.timeout.ms、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols,cruise.control.metrics.topic.num.partitions、cruise.control.metrics.topic.replication.factor、cruise.control.metrics.topic.retention.ms、cruise.control.metrics.topic.auto.create.retries、cruise.control.metrics.topic.auto.create.timeout.ms、cruise.control.metrics.topic.min.insync.replicas) |
map | |
storage |
ストレージの設定 (ディスク)。更新はできません。タイプは、指定のオブジェクト内の |
authorization |
Kafka ブローカーの承認設定。タイプは、指定のオブジェクト内の |
| |
rack |
|
brokerRackInitImage |
|
string | |
affinity |
|
tolerations |
|
Toleration array | |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
jvmOptions | Pod の JVM オプション。 |
jmxOptions | Kafka ブローカーの JMX オプション。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
metrics |
|
map | |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
logging |
Kafka のロギング設定。タイプは、指定のオブジェクト内の |
tlsSidecar |
|
template |
Kafka クラスターリソースのテンプレート。テンプレートを使用すると、ユーザーは |
13.2.4. GenericKafkaListener
スキーマ参照
KafkaClusterSpec
で使用
GenericKafkaListener
スキーマプロパティーの完全リスト
OpenShift 内外の Kafka ブローカーに接続するようにリスナーを設定します。
Kafka
リソースでリスナーを設定します。
リスナー設定を示す Kafka
リソースの例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: #... listeners: - name: plain port: 9092 type: internal tls: false - name: tls port: 9093 type: internal tls: true authentication: type: tls - name: external1 port: 9094 type: route tls: true - name: external2 port: 9095 type: ingress tls: true authentication: type: tls configuration: bootstrap: host: bootstrap.myingress.com brokers: - broker: 0 host: broker-0.myingress.com - broker: 1 host: broker-1.myingress.com - broker: 2 host: broker-2.myingress.com #...
13.2.4.1. listeners
Kafka
リソースの listeners
プロパティーを使用して Kafka ブローカーリスナーを設定します。リスナーは配列として定義されます。
リスナーの設定例
listeners: - name: plain port: 9092 type: internal tls: false
名前およびポートは Kafka クラスター内で一意である必要があります。名前は最大 25 文字で、小文字と数字で構成されます。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。
各リスナーに一意の名前とポートを指定することで、複数のリスナーを設定できます。
13.2.4.2. type
タイプは internal
と設定するか、外部リスナーの場合は route
、loadbalancer
、nodeport
、または ingress
と設定します。
- internal
tls
プロパティーを使用すると、暗号化の有無に関わらず内部リスナーを設定できます。internal
リスナーの設定例#... spec: kafka: #... listeners: #... - name: plain port: 9092 type: internal tls: false - name: tls port: 9093 type: internal tls: true authentication: type: tls #...
- route
OpenShift の
Routes
および HAProxy ルーターを使用して、Kafka を公開するように外部リスナーを設定します。専用の
Route
がすべての Kafka ブローカー Pod に作成されます。追加のRoute
が作成され、Kafka ブートストラップアドレスとして提供されます。これらのRoutes
を使用すると、Kafka クライアントを 443 番ポートで Kafka に接続することができます。クライアントはデフォルトのルーターポートであるポート 443 に接続しますが、トラフィックは設定するポート (この例では9094
) にルーティングされます。route
リスナーの設定例#... spec: kafka: #... listeners: #... - name: external1 port: 9094 type: route tls: true #...
- ingress
Kubernetes
Ingress
および NGINX Ingress Controller for Kubernetes を使用して Kafka を公開するように外部リスナーを設定します。各 Kafka ブローカー Pod に専用の
Ingress
リソースが作成されます。追加のIngress
リソースが作成され、Kafka ブートストラップアドレスとして提供されます。これらのIngress
リソースを使用すると、Kafka クライアントを 443 番ポートで Kafka に接続することができます。クライアントはデフォルトのコントローラーポートであるポート 443 に接続しますが、トラフィックは設定するポート (以下の例では9095
) にルーティングされます。GenericKafkaListenerConfigurationBootstrap
およびGenericKafkaListenerConfigurationBroker
プロパティーを使用して、ブートストラップおよびブローカーごとのサービスによって使用されるホスト名を指定する必要があります。ingress
リスナーの設定例#... spec: kafka: #... listeners: #... - name: external2 port: 9095 type: ingress tls: true authentication: type: tls configuration: bootstrap: host: bootstrap.myingress.com brokers: - broker: 0 host: broker-0.myingress.com - broker: 1 host: broker-1.myingress.com - broker: 2 host: broker-2.myingress.com #...
注記Ingress
を使用する外部リスナーは、現在 NGINX Ingress Controller for Kubernetes でのみテストされます。- loadbalancer
Kafka
Loadbalancer
タイプのServices
を公開するように外部リスナーを設定します。Kafka ブローカー Pod ごとに新しいロードバランサーサービスが作成されます。追加のロードバランサーが作成され、Kafka の ブートストラップ アドレスとして提供されます。Loadbalancer は指定のポート番号をリッスンします。これは以下の例ではポート
9094
になります。loadBalancerSourceRanges
プロパティーを使用して ソース範囲 を設定し、指定した IP アドレスへのアクセスを制限できます。loadbalancer
リスナーの設定例#... spec: kafka: #... listeners: - name: external3 port: 9094 type: loadbalancer tls: true configuration: loadBalancerSourceRanges: - 10.0.0.0/8 - 88.208.76.87/32 #...
- nodeport
NodePort
タイプのServices
を使用して、Kafka を公開するように外部リスナーを設定します。Kafka クライアントは OpenShift のノードに直接接続します。追加の
NodePort
タイプのサービスが作成され、Kafka ブートストラップアドレスとして提供されます。Kafka ブローカー Pod にアドバタイズされたアドレスを設定する場合、AMQ Stremas では該当の Pod が稼働しているノードのアドレスが使用されます。
preferredNodePortAddressType
プロパティーを使用して、ノードアドレスとしてチェックされた最初のアドレスタイプを設定できます。nodeport
リスナーの設定例#... spec: kafka: #... listeners: #... - name: external4 port: 9095 type: nodeport tls: false configuration: preferredNodePortAddressType: InternalDNS #...
注記ノードポートを使用して Kafka クラスターを公開する場合、現在 TLS ホスト名の検証はサポートされません。
13.2.4.3. port
ポート番号は Kafka クラスターで使用されるポートで、クライアントによるアクセスに使用されるポートとは異なる場合があります。
-
loadbalancer
リスナーは、internal
リスナーのように、指定されたポート番号を使用します。 -
ingress
およびroute
リスナーはアクセスにポート 443 を使用します。 -
nodeport
リスナーは OpenShift によって割り当てられたポート番号を使用します。
クライアント接続の場合は、リスナーのブートストラップサービスのアドレスおよびポートを使用します。これは、Kafka
リソースのステータスから取得できます。
クライアント接続のアドレスおよびポートを取得するコマンドの例
oc get kafka KAFKA-CLUSTER-NAME -o=jsonpath='{.status.listeners[?(@.type=="external")].bootstrapServers}{"\n"}'
ブローカー間通信 (9091) およびメトリクス (9404) 用に確保されたポートを使用するようにリスナーを設定することはできません。
13.2.4.4. tls
TLS プロパティーが必要です。
デフォルトでは、TLS による暗号化は有効になっていません。これを有効にするには、tls
プロパティーを true
に設定します。
TLS による暗号化は、常に route
リスナーと使用されます。
13.2.4.5. authentication
リスナーの認証は以下のように指定できます。
-
相互 TLS (
tls
) -
SCRAM-SHA-512 (
scram-sha-512
) -
トークンベース OAuth 2.0 (
oauth
)
13.2.4.6. networkPolicyPeers
ネットワークレベルでリスナーへのアクセスを制限するネットワークポリシーを設定するには、networkPolicyPeers
を使用します。以下に、plain
および tls
リスナーの networkPolicyPeers
設定の例を示します。
listeners: #... - name: plain port: 9092 type: internal tls: true authentication: type: scram-sha-512 networkPolicyPeers: - podSelector: matchLabels: app: kafka-sasl-consumer - podSelector: matchLabels: app: kafka-sasl-producer - name: tls port: 9093 type: internal tls: true authentication: type: tls networkPolicyPeers: - namespaceSelector: matchLabels: project: myproject - namespaceSelector: matchLabels: project: myproject2 # ...
この例では以下が設定されています。
-
ラベル
app: kafka-sasl-consumer
およびapp: kafka-sasl-producer
と一致するアプリケーション Pod のみがplain
リスナーに接続できます。アプリケーション Pod は Kafka ブローカーと同じ namespace で実行されている必要があります。 -
ラベル
project: myproject
およびproject: myproject2
と一致する namespace で稼働するアプリケーション Pod のみがtls
リスナーに接続できます。
networkPolicyPeers
フィールドの構文は、NetworkPolicy
リソースの from
フィールドと同じです。
KafkaListeners
との後方互換性
GenericKafkaListener
は、非推奨となった KafkaListeners
スキーマを置き換えます。
KafkaListeners
スキーマを使用して設定されたリスナーを、後方互換性を持つ GenericKafkaListener
スキーマの形式に変換するには、以下の名前、ポート、およびタイプを使用します。
listeners: #... - name: plain port: 9092 type: internal tls: false - name: tls port: 9093 type: internal tls: true - name: external port: 9094 type: EXTERNAL-LISTENER-TYPE 1 tls: true # ...
- 1
- オプション:
ingress
、loadbalancer
、nodeport
、route
13.2.4.7. GenericKafkaListener
スキーマプロパティー
プロパティー | 説明 |
---|---|
name | リスナーの名前。名前は、リスナーおよび関連する OpenShift オブジェクトの識別に使用されます。指定の Kafka クラスター内で一意となる必要があります。この名前には、小文字と数字を使用でき、最大 11 文字まで使用できます。 |
string | |
port | Kafka 内でリスナーによって使用されるポート番号。ポート番号は指定の Kafka クラスター内で一意である必要があります。許可されるポート番号は 9092 以上ですが、すでに Prometheus および JMX によって使用されているポート 9404 および 9999 以外になります。リスナーのタイプによっては、ポート番号は Kafka クライアントに接続するポート番号と同じではない場合があります。 |
integer | |
type |
リスナーのタイプ。現在サポートされるタイプは、
* |
string ([ingress、internal、route、loadbalancer、nodeport] のいずれか) | |
tls | リスナーで TLS による暗号化を有効にします。これは必須プロパティーです。 |
boolean | |
authentication |
このリスナーの認証設定。タイプは、指定のオブジェクト内の |
| |
configuration | 追加のリスナー設定。 |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array |
13.2.5. KafkaListenerAuthenticationTls
スキーマ参照
GenericKafkaListener
、KafkaListenerExternalIngress
、KafkaListenerExternalLoadBalancer
、KafkaListenerExternalNodePort
、KafkaListenerExternalRoute
、KafkaListenerPlain
、KafkaListenerTls
で使用
type
プロパティーは、KafkaListenerAuthenticationTls
タイプの使用を KafkaListenerAuthenticationScramSha512
、KafkaListenerAuthenticationOAuth
と区別する識別子です。KafkaListenerAuthenticationTls
タイプには tls
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.6. KafkaListenerAuthenticationScramSha512
スキーマ参照
GenericKafkaListener
、KafkaListenerExternalIngress
、KafkaListenerExternalLoadBalancer
、KafkaListenerExternalNodePort
、KafkaListenerExternalRoute
、KafkaListenerPlain
、KafkaListenerTls
で使用
type
プロパティーは、KafkaListenerAuthenticationScramSha512
タイプの使用を KafkaListenerAuthenticationTls
、KafkaListenerAuthenticationOAuth
と区別する識別子です。KafkaListenerAuthenticationScramSha512
タイプには scram-sha-512
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.7. KafkaListenerAuthenticationOAuth
スキーマ参照
GenericKafkaListener
、KafkaListenerExternalIngress
、KafkaListenerExternalLoadBalancer
、KafkaListenerExternalNodePort
、KafkaListenerExternalRoute
、KafkaListenerPlain
、KafkaListenerTls
で使用
type
プロパティーは、KafkaListenerAuthenticationOAuth
タイプの使用を KafkaListenerAuthenticationTls
、KafkaListenerAuthenticationScramSha512
と区別する識別子です。KafkaListenerAuthenticationOAuth
タイプには oauth
の値が必要です。
プロパティー | 説明 |
---|---|
accessTokenIsJwt |
アクセストークンを JWT として処理するかどうかを設定します。承認サーバーが不透明なトークンを返す場合は、 |
boolean | |
checkAccessTokenType |
アクセストークンタイプのチェックを行うかどうかを設定します。承認サーバーの JWT トークンに 'typ' 要求が含まれない場合は、 |
boolean | |
checkAudience |
オーディエンスのチェックを有効または無効にします。オーディエンスのチェックによって、トークンの受信者が特定されます。オーディエンスのチェックが有効な場合は、 |
boolean | |
checkIssuer |
発行元のチェックを有効または無効にします。デフォルトでは、 |
boolean | |
clientId | Kafka ブローカーは、OAuth クライアント ID を使用して承認サーバーに対して認証し、イントロスペクションエンドポイント URI を使用することができます。 |
string | |
clientSecret | OAuth クライアントシークレットが含まれる OpenShift シークレットへのリンク。Kafka ブローカーは、OAuth クライアントシークレットを使用して承認サーバーに対して認証し、イントロスペクションエンドポイント URI を使用することができます。 |
customClaimCheck | JWT トークンに適用される JSONPath フィルタークエリー、または追加のトークン検証のイントロスペクションエンドポイントの応答に適用される JSONPath フィルタークエリー。デフォルトでは設定されません。 |
string | |
disableTlsHostnameVerification |
TLS ホスト名の検証を有効または無効にします。デフォルト値は |
boolean | |
enableECDSA |
BouncyCastle 暗号プロバイダーをインストールして、ECDSA サポートを有効または無効にします。デフォルト値は |
boolean | |
enableOauthBearer |
SASL_OAUTHBEARER での OAuth 認証を有効または無効にします。デフォルト値は |
boolean | |
enablePlain |
SASL_PLAIN で OAuth 認証を有効または無効にします。このメカニズムが使用される場合、再認証はサポートされません。デフォルト値は |
boolean | |
fallbackUserNameClaim |
|
string | |
fallbackUserNamePrefix |
ユーザー ID を構成するために |
string | |
introspectionEndpointUri | 不透明な JWT 以外のトークンの検証に使用できるトークンイントロスペクションエンドポイントの URI。 |
string | |
jwksEndpointUri | ローカルの JWT 検証に使用できる JWKS 証明書エンドポイントの URI。 |
string | |
jwksExpirySeconds |
JWKS 証明書が有効とみなされる頻度を設定します。期限切れの間隔は、 |
integer | |
jwksMinRefreshPauseSeconds | 連続する 2 回の更新の間に適用される最小の一時停止期間。不明な署名鍵が検出されると、更新は即座にスケジュールされますが、この最小一時停止の期間は待機します。デフォルトは 1 秒です。 |
integer | |
jwksRefreshSeconds |
JWKS 証明書が更新される頻度を設定します。更新間隔は、 |
integer | |
maxSecondsWithoutReauthentication |
再認証せずに認証されたセッションが有効な状態でいられる最大期間 (秒単位)。これにより、Apache Kafka の再認証機能が有効になり、アクセストークンの有効期限が切れるとセッションが期限切れになります。最大期間の前または最大期間の到達時にアクセストークンが期限切れになると、クライアントは再認証する必要があります。そうでないと、サーバーは接続を切断します。デフォルトでは設定されません。アクセストークンが期限切れになっても認証されたセッションは期限切れになりません。このオプションは SASL_OAUTHBEARER 認証メカニズム ( |
integer | |
tlsTrustedCertificates | OAuth サーバーへの TLS 接続の信頼済み証明書。 |
| |
tokenEndpointUri | クライアントが clientId およびシークレットで認証されるときに SASL_PLAIN メカニズムで使用するトークンエンドポイントの URI。 |
string | |
type |
|
string | |
userInfoEndpointUri | Introspection Endpoint がユーザー ID に使用できる情報を返さない場合に、ユーザー ID 取得のフォールバックとして使用する User Info Endpoint の URL。 |
string | |
userNameClaim |
ユーザー ID の取得に使用される JWT 認証トークン、Introspection Endpoint の応答、または User Info Endpoint の応答からの要求の名前。デフォルトは |
string | |
validIssuerUri | 認証に使用されるトークン発行者の URI。 |
string | |
validTokenType |
Introspection Endpoint によって返される |
string |
13.2.8. GenericSecretSource
スキーマ参照
KafkaClientAuthenticationOAuth
、KafkaListenerAuthenticationOAuth
で使用
プロパティー | 説明 |
---|---|
key | OpenShift シークレットでシークレット値が保存されるキー。 |
string | |
secretName | シークレット値が含まれる OpenShift シークレットの名前。 |
string |
13.2.9. CertSecretSource
スキーマ参照
KafkaAuthorizationKeycloak
、KafkaBridgeTls
、KafkaClientAuthenticationOAuth
、KafkaConnectTls
、KafkaListenerAuthenticationOAuth
、KafkaMirrorMaker2Tls
、KafkaMirrorMakerTls
で使用
プロパティー | 説明 |
---|---|
certificate | Secret のファイル証明書の名前。 |
string | |
secretName | 証明書が含まれる Secret の名前。 |
string |
13.2.10. GenericKafkaListenerConfiguration
スキーマ参照
GenericKafkaListenerConfiguration
スキーマプロパティーの完全リスト
Kafka リスナーの設定。
13.2.10.1. brokerCertChainAndKey
brokerCertChainAndKey
プロパティーは、TLS による暗号化が有効になっているリスナーとのみ使用されます。独自の Kafka リスナー証明書を提供してこのプロパティーを使用できます。
TLS による暗号化が有効な loadbalancer
外部リスナーの設定例
listeners: #... - name: external port: 9094 type: loadbalancer tls: true authentication: type: tls configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
13.2.10.2. externalTrafficPolicy
externalTrafficPolicy
プロパティーは、loadbalancer
および nodeport
リスナーと使用されます。OpenShift 外部で Kafka を公開する場合、Local
または Cluster
を選択できます。Local
は他のノードへのホップを回避し、クライアント IP を保持しますが、Cluster
はホップを回避せず、クライアント IP も保持しません。デフォルトは Cluster
です。
13.2.10.3. loadBalancerSourceRanges
loadBalancerSourceRanges
プロパティーは、loadbalancer
リスナーとのみ使用されます。OpenShift 外部で Kafka を公開する場合、ラベルやアノテーションの他にソースの範囲を使用して、サービスの作成方法をカスタマイズします。
ロードバランサーリスナー向けに設定されたソース範囲の例
listeners: #... - name: external port: 9094 type: loadbalancer tls: false configuration: externalTrafficPolicy: Local loadBalancerSourceRanges: - 10.0.0.0/8 - 88.208.76.87/32 # ... # ...
13.2.10.4. class
class
プロパティーは、ingress
リスナーとのみ使用されます。class
プロパティーを使用して Ingress
クラスを設定できます。
Ingress
クラスの nginx-internal
を使用するタイプ ingress
の外部リスナーの例
listeners: #... - name: external port: 9094 type: ingress tls: true configuration: class: nginx-internal # ... # ...
13.2.10.5. preferredNodePortAddressType
preferredNodePortAddressType
プロパティーは、nodeport
リスナーとのみ使用されます。
リスナー設定の preferredNodePortAddressType
プロパティーを使用して、ノードアドレスとしてチェックされた最初のアドレスタイプを指定できます。たとえば、デプロイメントに DNS サポートがない場合や、内部 DNS または IP アドレスを介してブローカーを内部でのみ公開する場合、このプロパティーは便利です。該当タイプのアドレスが見つかった場合はそのアドレスが使用されます。アドレスタイプが見つからなかった場合、AMQ Streams は標準の優先順位でタイプの検索を続行します。
- ExternalDNS
- ExternalIP
- Hostname
- InternalDNS
- InternalIP
優先ノードポートアドレスタイプで設定された外部リスナーの例
listeners: #... - name: external port: 9094 type: nodeport tls: false configuration: preferredNodePortAddressType: InternalDNS # ... # ...
13.2.10.6. useServiceDnsDomain
useServiceDnsDomain
プロパティーは、internal
リスナーとのみ使用されます。クラスターサービスサフィックス (通常は .cluster.local
) を含む完全修飾 DNS 名が使用されるかどうかを定義します。useServiceDnsDomain
を false
に設定すると、サービスサフィックスのないアドバタイズされたアドレスが生成されます (例my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc
)。useServiceDnsDomain
を true
に設定すると、サービスサフィックスのあるアドバタイズされたアドレスが生成されます (例my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc.cluster.local
)。デフォルトは false
です。
サービス DNS ドメインを使用するよう設定された内部リスナーの例
listeners: #... - name: plain port: 9092 type: internal tls: false configuration: useServiceDnsDomain: true # ... # ...
OpenShift クラスターが .cluster.local
以外のサービスサフィックスを使用する場合、Cluster Operator 設定で KUBERNETES_SERVICE_DNS_DOMAIN
環境変数を使用してサフィックスを設定できます。詳細は 「Cluster Operator の設定」 を参照してください。
13.2.10.7. GenericKafkaListenerConfiguration
スキーマプロパティー
プロパティー | 説明 |
---|---|
brokerCertChainAndKey |
このリスナーに使用される証明書と秘密鍵のペアを保持する |
externalTrafficPolicy |
サービスによって外部トラフィックがローカルノードのエンドポイントまたはクラスター全体のエンドポイントにルーティングされるかどうかを指定します。 |
string ([Local、Cluster] のいずれか) | |
loadBalancerSourceRanges |
クライアントがロードバランサータイプのリスナーに接続できる CIDR 形式による範囲 (例: |
string array | |
bootstrap | ブートストラップの設定。 |
brokers | ブローカーごとの設定。 |
class |
使用される |
string | |
preferredNodePortAddressType |
ノードアドレスとして使用するアドレスタイプを定義します。利用可能なタイプは、
このフィールドは、優先タイプとして使用され、最初にチェックされるアドレスタイプの選択に使用できます。このアドレスタイプのアドレスが見つからない場合は、デフォルトの順序で他のタイプが使用されます。このフィールドは、 |
string ([ExternalDNS、ExternalIP、Hostname、InternalIP、InternalDNS] のいずれか) | |
useServiceDnsDomain |
OpenShift サービス DNS ドメインを使用するべきかどうかを設定します。 |
boolean |
13.2.11. CertAndKeySecretSource
スキーマ参照
GenericKafkaListenerConfiguration
、IngressListenerConfiguration
、KafkaClientAuthenticationTls
、KafkaListenerExternalConfiguration
、NodePortListenerConfiguration
、TlsListenerConfiguration
で使用
プロパティー | 説明 |
---|---|
certificate | Secret のファイル証明書の名前。 |
string | |
key | Secret の秘密鍵の名前。 |
string | |
secretName | 証明書が含まれる Secret の名前。 |
string |
13.2.12. GenericKafkaListenerConfigurationBootstrap
スキーマ参照
GenericKafkaListenerConfiguration
で使用
GenericKafkaListenerConfigurationBootstrap
スキーマプロパティーの完全リスト
nodePort
、host
、loadBalancerIP
、および annotations
プロパティーに相当するブローカーサービスは、GenericKafkaListenerConfigurationBroker
スキーマ で設定されます。
13.2.12.1. alternativeNames
ブートストラップサービスの代替名を指定できます。名前はブローカー証明書に追加され、TLS ホスト名の検証に使用できます。alternativeNames
プロパティーは、すべてのタイプのリスナーに適用できます。
追加のブートストラップアドレスが設定された外部 route
リスナーの例
listeners: #... - name: external port: 9094 type: route tls: true authentication: type: tls configuration: bootstrap: alternativeNames: - example.hostname1 - example.hostname2 # ...
13.2.12.2. host
host
プロパティーは、ブートストラップおよびブローカーごとのサービスによって使用されるホスト名を指定するために route
および ingress
リスナーと使用されます。
Ingress コントローラーはホスト名を自動的に割り当てないため、ingress
リスナー設定に host
プロパティーの値は必須となります。確実にホスト名が Ingress エンドポイントに解決されるようにしてください。AMQ Streams では、要求されたホストが利用可能で、適切に Ingress エンドポイントにルーティングされることを検証しません。
Ingress リスナーのホスト設定例
listeners: #... - name: external port: 9094 type: ingress tls: true authentication: type: tls configuration: bootstrap: host: bootstrap.myingress.com brokers: - broker: 0 host: broker-0.myingress.com - broker: 1 host: broker-1.myingress.com - broker: 2 host: broker-2.myingress.com # ...
デフォルトでは、route
リスナーホストは OpenShift によって自動的に割り当てられます。ただし、ホストを指定して、割り当てられたルートをオーバーライドすることができます。
AMQ Streams では、要求されたホストが利用可能であることを検証しません。ホストが使用可能であることを確認する必要があります。
route リスナーのホスト設定例
# ... listeners: #... - name: external port: 9094 type: route tls: true authentication: type: tls configuration: bootstrap: host: bootstrap.myrouter.com brokers: - broker: 0 host: broker-0.myrouter.com - broker: 1 host: broker-1.myrouter.com - broker: 2 host: broker-2.myrouter.com # ...
13.2.12.3. nodePort
デフォルトでは、ブートストラップおよびブローカーサービスに使用されるポート番号は OpenShift によって自動的に割り当てられます。要求されたポート番号を指定すると、nodeport
リスナーに割り当てられたノードポートをオーバーライドできます。
AMQ Streams は要求されたポートの検証を行いません。ポートが使用できることを確認する必要があります。
ノードポートのオーバーライドが設定された外部リスナーの例
# ... listeners: #... - name: external port: 9094 type: nodeport tls: true authentication: type: tls configuration: bootstrap: nodePort: 32100 brokers: - broker: 0 nodePort: 32000 - broker: 1 nodePort: 32001 - broker: 2 nodePort: 32002 # ...
13.2.12.4. loadBalancerIP
loadBalancerIP
プロパティーを使用してロードバランサーの作成時に特定の IP アドレスをリクエストします。特定の IP アドレスでロードバランサーを使用する必要がある場合は、このプロパティーを使用します。クラウドプロバイダーがこの機能に対応していない場合、loadBalancerIP
フィールドは無視されます。
特定のロードバランサー IP アドレスリクエストのある loadbalancer
タイプの外部リスナーの例
# ... listeners: #... - name: external port: 9094 type: loadbalancer tls: true authentication: type: tls configuration: bootstrap: loadBalancerIP: 172.29.3.10 brokers: - broker: 0 loadBalancerIP: 172.29.3.1 - broker: 1 loadBalancerIP: 172.29.3.2 - broker: 2 loadBalancerIP: 172.29.3.3 # ...
13.2.12.5. annotations
annotations
プロパティーを使用して、リスナーに関連する OpenShift リソースにアノテーションを追加します。これらのアノテーションを使用すると、自動的に DNS 名をロードバランサーサービスに割り当てる 外部 DNS などの DNS ツールをインストルメント化できます。
annotations
を使用するタイプ loadbalancer
の外部リスナーの例
# ... listeners: #... - name: external port: 9094 type: loadbalancer tls: true authentication: type: tls configuration: bootstrap: annotations: external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com. external-dns.alpha.kubernetes.io/ttl: "60" brokers: - broker: 0 annotations: external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com. external-dns.alpha.kubernetes.io/ttl: "60" - broker: 1 annotations: external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com. external-dns.alpha.kubernetes.io/ttl: "60" - broker: 2 annotations: external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com. external-dns.alpha.kubernetes.io/ttl: "60" # ...
13.2.12.6. GenericKafkaListenerConfigurationBootstrap
スキーマプロパティー
プロパティー | 説明 |
---|---|
alternativeNames | ブートストラップサービスの追加の代替名。代替名は、TLS 証明書のサブジェクト代替名のリストに追加されます。 |
string array | |
host |
ブートストラップホスト。このフィールドは、ホスト名を指定するために Ingress リソースまたは Route リソースで使用されます。このフィールドは、 |
string | |
nodePort |
ブートストラップサービスのノードポート。このフィールドは、 |
integer | |
loadBalancerIP |
ロードバランサーは、このフィールドに指定された IP アドレスで要求されます。この機能は、ロードバランサーの作成時に、基礎となるクラウドプロバイダーが |
string | |
annotations |
|
map | |
labels |
|
map |
13.2.13. GenericKafkaListenerConfigurationBroker
スキーマ参照
GenericKafkaListenerConfiguration
で使用
GenericKafkaListenerConfigurationBroker
スキーマプロパティーの完全リスト
ブートストラップサービスのオーバーライドを設定する GenericKafkaListenerConfigurationBootstrap
スキーマ で、nodePort
、host
、loadBalancerIP
、および annotations
プロパティーの設定例を参照できます。
ブローカーのアドバタイズされたアドレス
デフォルトでは、AMQ Streams は Kafka クラスターがそのクライアントにアドバタイズするホスト名とポートを自動的に決定しようとします。AMQ Streams が稼働しているインフラストラクチャーでは Kafka にアクセスできる正しいホスト名やポートを提供しない可能性があるため、デフォルトの動作はすべての状況に適しているわけではありません。
ブローカー ID を指定し、リスナーの configuration
プロパティーでアドバタイズされたホスト名およびポートをカスタマイズできます。その後、AMQ Streams では Kafka ブローカーでアドバタイズされたアドレスが自動設定され、ブローカー証明書に追加されるため、TLS ホスト名の検証が使用できるようになります。アドバタイズされたホストおよびポートのオーバーライドは、すべてのタイプのリスナーで利用できます。
アドバタイズされたアドレスのオーバーライドが設定された外部 route
リスナーの例
listeners: #... - name: external port: 9094 type: route tls: true authentication: type: tls configuration: brokers: - broker: 0 advertisedHost: example.hostname.0 advertisedPort: 12340 - broker: 1 advertisedHost: example.hostname.1 advertisedPort: 12341 - broker: 2 advertisedHost: example.hostname.2 advertisedPort: 12342 # ...
13.2.13.1. GenericKafkaListenerConfigurationBroker
スキーマプロパティー
プロパティー | 説明 |
---|---|
broker | Kafka ブローカーの ID (ブローカー識別子)。ブローカー ID は 0 から始まり、ブローカーレプリカの数に対応します。 |
integer | |
advertisedHost |
ブローカーの |
string | |
advertisedPort |
ブローカーの |
integer | |
host |
ブローカーホスト。このフィールドは、ホスト名を指定するために Ingress リソースまたは Route リソースで使用されます。このフィールドは、 |
string | |
nodePort |
ブローカーごとのサービスのノードポート。このフィールドは、 |
integer | |
loadBalancerIP |
ロードバランサーは、このフィールドに指定された IP アドレスで要求されます。この機能は、ロードバランサーの作成時に、基礎となるクラウドプロバイダーが |
string | |
annotations |
|
map | |
labels |
|
map |
13.2.14. KafkaListeners
スキーマ参照
KafkaListeners
タイプは非推奨となり、API バージョン v1beta2
で削除されます。代わりに GenericKafkaListener
を使用してください。
KafkaClusterSpec
で使用
設定例は 以前のドキュメント を参照してください。
プロパティー | 説明 |
---|---|
plain | ポート 9092 でプレーンリスナーを設定します。 |
tls | ポート 9093 で TLS リスナーを設定します。 |
external |
ポート 9094 で外部リスナーを設定します。タイプは、指定のオブジェクト内の |
|
13.2.15. KafkaListenerPlain
スキーマ参照
KafkaListeners
で使用
プロパティー | 説明 |
---|---|
authentication |
このリスナーの認証設定。このリスナーは TLS トランスポートを使用しないため、 |
| |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array |
13.2.16. KafkaListenerTls
スキーマ参照
KafkaListeners
で使用
プロパティー | 説明 |
---|---|
authentication |
このリスナーの認証設定。タイプは、指定のオブジェクト内の |
| |
configuration | TLS リスナーの設定。 |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array |
13.2.17. TlsListenerConfiguration
スキーマ参照
KafkaListenerTls
で使用
プロパティー | 説明 |
---|---|
brokerCertChainAndKey |
証明書と秘密鍵のペアを保持する |
13.2.18. KafkaListenerExternalRoute
スキーマ参照
KafkaListeners
で使用
type
プロパティーは、KafkaListenerExternalRoute
タイプの使用を KafkaListenerExternalLoadBalancer
、KafkaListenerExternalNodePort
、および KafkaListenerExternalIngress
タイプと区別する識別子です。KafkaListenerExternalRoute
タイプには route
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
authentication |
Kafka ブローカーの認証の設定タイプは、指定のオブジェクト内の |
| |
overrides | 外部ブートストラップサービスおよびブローカーサービス、ならびに外部にアドバタイズされたアドレスの上書き。 |
configuration | 外部リスナーの設定。 |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array |
13.2.19. RouteListenerOverride
スキーマ参照
KafkaListenerExternalRoute
で使用
プロパティー | 説明 |
---|---|
bootstrap | 外部ブートストラップサービスの設定。 |
brokers | 外部ブローカーサービスの設定。 |
13.2.20. RouteListenerBootstrapOverride
スキーマ参照
プロパティー | 説明 |
---|---|
address | ブートストラップサービスの追加のアドレス名。このアドレスは、TLS 証明書のサブジェクトの別名の一覧に追加されます。 |
string | |
host |
ブートストラップルートのホスト。このフィールドは OpenShift Route の |
string |
13.2.21. RouteListenerBrokerOverride
スキーマ参照
プロパティー | 説明 |
---|---|
broker | Kafka ブローカーの ID (ブローカー ID)。 |
integer | |
advertisedHost |
ブローカーの |
string | |
advertisedPort |
ブローカーの |
integer | |
host |
ブローカールートのホスト。このフィールドは OpenShift Route の |
string |
13.2.22. KafkaListenerExternalConfiguration
スキーマ参照
KafkaListenerExternalLoadBalancer
、KafkaListenerExternalRoute
で使用
プロパティー | 説明 |
---|---|
brokerCertChainAndKey |
証明書と秘密鍵のペアを保持する |
13.2.23. KafkaListenerExternalLoadBalancer
スキーマ参照
KafkaListeners
で使用
type
プロパティーは、KafkaListenerExternalLoadBalancer
タイプの使用を KafkaListenerExternalRoute
、KafkaListenerExternalNodePort
、および KafkaListenerExternalIngress
タイプと区別する識別子です。KafkaListenerExternalLoadBalancer
タイプには loadbalancer
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
authentication |
Kafka ブローカーの認証の設定タイプは、指定のオブジェクト内の |
| |
overrides | 外部ブートストラップサービスおよびブローカーサービス、ならびに外部にアドバタイズされたアドレスの上書き。 |
configuration | 外部リスナーの設定。 |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array | |
tls |
リスナーで TLS による暗号化を有効にします。有効な TLS 暗号化の場合、デフォルトで |
boolean |
13.2.24. LoadBalancerListenerOverride
スキーマ参照
KafkaListenerExternalLoadBalancer
で使用
プロパティー | 説明 |
---|---|
bootstrap | 外部ブートストラップサービスの設定。 |
brokers | 外部ブローカーサービスの設定。 |
13.2.25. LoadBalancerListenerBootstrapOverride
スキーマ参照
LoadBalancerListenerOverride
で使用
プロパティー | 説明 |
---|---|
address | ブートストラップサービスの追加のアドレス名。このアドレスは、TLS 証明書のサブジェクトの別名の一覧に追加されます。 |
string | |
dnsAnnotations |
|
map | |
loadBalancerIP |
ロードバランサーは、このフィールドに指定された IP アドレスで要求されます。この機能は、ロードバランサーの作成時に、基礎となるクラウドプロバイダーが |
string |
13.2.26. LoadBalancerListenerBrokerOverride
スキーマ参照
LoadBalancerListenerOverride
で使用
プロパティー | 説明 |
---|---|
broker | Kafka ブローカーの ID (ブローカー ID)。 |
integer | |
advertisedHost |
ブローカーの |
string | |
advertisedPort |
ブローカーの |
integer | |
dnsAnnotations |
個別のブローカーの |
map | |
loadBalancerIP |
ロードバランサーは、このフィールドに指定された IP アドレスで要求されます。この機能は、ロードバランサーの作成時に、基礎となるクラウドプロバイダーが |
string |
13.2.27. KafkaListenerExternalNodePort
スキーマ参照
KafkaListeners
で使用
type
プロパティーは、KafkaListenerExternalNodePort
タイプの使用を KafkaListenerExternalRoute
、KafkaListenerExternalLoadBalancer
、および KafkaListenerExternalIngress
タイプと区別する識別子です。KafkaListenerExternalNodePort
タイプには nodeport
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
authentication |
Kafka ブローカーの認証の設定タイプは、指定のオブジェクト内の |
| |
overrides | 外部ブートストラップサービスおよびブローカーサービス、ならびに外部にアドバタイズされたアドレスの上書き。 |
configuration | 外部リスナーの設定。 |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array | |
tls |
リスナーで TLS による暗号化を有効にします。有効な TLS 暗号化の場合、デフォルトで |
boolean |
13.2.28. NodePortListenerOverride
スキーマ参照
KafkaListenerExternalNodePort
で使用
プロパティー | 説明 |
---|---|
bootstrap | 外部ブートストラップサービスの設定。 |
brokers | 外部ブローカーサービスの設定。 |
13.2.29. NodePortListenerBootstrapOverride
スキーマ参照
プロパティー | 説明 |
---|---|
address | ブートストラップサービスの追加のアドレス名。このアドレスは、TLS 証明書のサブジェクトの別名の一覧に追加されます。 |
string | |
dnsAnnotations |
|
map | |
nodePort | ブートストラップサービスのノードポート。 |
integer |
13.2.30. NodePortListenerBrokerOverride
スキーマ参照
プロパティー | 説明 |
---|---|
broker | Kafka ブローカーの ID (ブローカー ID)。 |
integer | |
advertisedHost |
ブローカーの |
string | |
advertisedPort |
ブローカーの |
integer | |
nodePort | ブローカーサービスのノードポート。 |
integer | |
dnsAnnotations |
個別のブローカーの |
map |
13.2.31. NodePortListenerConfiguration
スキーマ参照
KafkaListenerExternalNodePort
で使用
プロパティー | 説明 |
---|---|
brokerCertChainAndKey |
証明書と秘密鍵のペアを保持する |
preferredAddressType |
ノードアドレスとして使用するアドレスタイプを定義します。利用可能なタイプは、 このフィールドは、優先タイプとして使用され、最初にチェックされるアドレスタイプの選択に使用できます。このアドレスタイプのアドレスが見つからない場合は、デフォルトの順序で他のタイプが使用されます。 |
string ([ExternalDNS、ExternalIP、Hostname、InternalIP、InternalDNS] のいずれか) |
13.2.32. KafkaListenerExternalIngress
スキーマ参照
KafkaListeners
で使用
type
プロパティーは、KafkaListenerExternalIngress
タイプの使用を KafkaListenerExternalRoute
、KafkaListenerExternalLoadBalancer
、および KafkaListenerExternalNodePort
タイプと区別する識別子です。KafkaListenerExternalIngress
タイプには ingress
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
authentication |
Kafka ブローカーの認証の設定タイプは、指定のオブジェクト内の |
| |
class |
使用される |
string | |
configuration | 外部リスナーの設定。 |
networkPolicyPeers | このリスナーに接続できるピアの一覧。この一覧のピアは、論理演算子 OR を使用して組み合わせます。このフィールドが空であるか、または存在しない場合、このリスナーのすべてのコネクションが許可されます。このフィールドが存在し、1 つ以上の項目が含まれる場合、リスナーはこの一覧の少なくとも 1 つの項目と一致するトラフィックのみを許可します。詳細は、networking.k8s.io/v1 networkpolicypeer の外部ドキュメントを参照してください。 |
NetworkPolicyPeer array |
13.2.33. IngressListenerConfiguration
スキーマ参照
KafkaListenerExternalIngress
で使用
プロパティー | 説明 |
---|---|
bootstrap | 外部ブートストラップ Ingress の設定。 |
brokers | 外部ブローカー Ingress の設定。 |
brokerCertChainAndKey |
証明書と秘密鍵のペアを保持する |
13.2.34. IngressListenerBootstrapConfiguration
スキーマ参照
IngressListenerConfiguration
で使用
プロパティー | 説明 |
---|---|
address | ブートストラップサービスの追加のアドレス名。このアドレスは、TLS 証明書のサブジェクトの別名の一覧に追加されます。 |
string | |
dnsAnnotations |
|
map | |
host | ブートストラップルートのホスト。このフィールドは Ingress リソースで使用されます。 |
string |
13.2.35. IngressListenerBrokerConfiguration
スキーマ参照
IngressListenerConfiguration
で使用
プロパティー | 説明 |
---|---|
broker | Kafka ブローカーの ID (ブローカー ID)。 |
integer | |
advertisedHost |
ブローカーの |
string | |
advertisedPort |
ブローカーの |
integer | |
host | ブローカー Ingress のホスト。このフィールドは Ingress リソースで使用されます。 |
string | |
dnsAnnotations |
個別のブローカーの |
map |
13.2.36. EphemeralStorage
スキーマ参照
JbodStorage
、KafkaClusterSpec
、ZookeeperClusterSpec
で使用
type
プロパティーは、EphemeralStorage
タイプの使用を PersistentClaimStorage
と区別する識別子です。EphemeralStorage
タイプには ephemeral
の値が必要です。
プロパティー | 説明 |
---|---|
id | ストレージ ID 番号。これは、'jbod' タイプのストレージで定義されるストレージボリュームのみで必須です。 |
integer | |
sizeLimit | type=ephemeral の場合、この EmptyDir ボリュームに必要なローカルストレージの合計容量を定義します (例: 1Gi)。 |
string | |
type |
|
string |
13.2.37. PersistentClaimStorage
スキーマ参照
JbodStorage
、KafkaClusterSpec
、ZookeeperClusterSpec
で使用
type
プロパティーは、PersistentClaimStorage
タイプの使用を EphemeralStorage
と区別する識別子です。PersistentClaimStorage
タイプには persistent-claim
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
size | type=persistent-claim の場合、永続ボリューム要求のサイズを定義します (例: 1Gi).。type=persistent-claim の場合には必須です。 |
string | |
selector | 使用する特定の永続ボリュームを指定します。このようなボリュームを選択するラベルを表す key:value ペアが含まれます。 |
map | |
deleteClaim | クラスターのアンデプロイ時に永続ボリューム要求を削除する必要があるかどうかを指定します。 |
boolean | |
class | 動的ボリュームの割り当てに使用するストレージクラス。 |
string | |
id | ストレージ ID 番号。これは、'jbod' タイプのストレージで定義されるストレージボリュームのみで必須です。 |
integer | |
overrides |
個々のブローカーを上書きします。 |
13.2.38. PersistentClaimStorageOverride
スキーマ参照
プロパティー | 説明 |
---|---|
class | このブローカーの動的ボリュームの割り当てに使用するストレージクラス。 |
string | |
broker | Kafka ブローカーの ID (ブローカー ID)。 |
integer |
13.2.39. JbodStorage
スキーマ参照
KafkaClusterSpec
で使用
type
プロパティーは、JbodStorage
タイプの使用を EphemeralStorage
、PersistentClaimStorage
と区別する識別子です。JbodStorage
タイプには jbod
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
volumes | JBOD ディスクアレイを表すストレージオブジェクトとしてのボリュームの一覧。 |
13.2.40. KafkaAuthorizationSimple
スキーマ参照
KafkaClusterSpec
で使用
KafkaAuthorizationSimple
スキーマプロパティーの完全リスト
AMQ Streams の簡易承認では、AclAuthorizer
プラグインが使用されます。これは、Apache Kafka で提供されるデフォルトのアクセス制御リスト (ACL) 承認プラグインです。ACL を使用すると、ユーザーがアクセスできるリソースを細かく定義できます。
Kafka
カスタムリソースが簡易承認を使用するように設定します。authorization
セクションの type
プロパティーの値を simple
に設定し、スーパーユーザーの一覧を設定します。
「ACLRule スキーマ参照」の説明にあるように、アクセスルールは KafkaUser
に対して設定されます。
13.2.40.1. superUsers
スーパーユーザーとして扱われるユーザープリンシパルのリスト。このリストのユーザープリンシパルは、ACL ルールをクエリーしなくても常に許可されます。詳細は「Kafka の承認」を参照してください。
簡易承認の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... authorization: type: simple superUsers: - CN=client_1 - user_2 - CN=client_3 # ...
Kafka.spec.kafka
の config
プロパティーにある super.user
設定オプションは無視されます。この代わりに、authorization
プロパティーでスーパーユーザーを指定します。詳細は「Kafka ブローカーの設定」を参照してください。
13.2.40.2. KafkaAuthorizationSimple
スキーマプロパティー
type
プロパティーは、KafkaAuthorizationSimple
タイプの使用を KafkaAuthorizationOpa
、KafkaAuthorizationKeycloak
と区別する識別子です。KafkaAuthorizationSimple
タイプには simple
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
superUsers | スーパーユーザーの一覧。無制限のアクセス権を取得する必要のあるユーザープリンシパルの一覧が含まれなければなりません。 |
string array |
13.2.41. KafkaAuthorizationOpa
スキーマ参照
KafkaClusterSpec
で使用
KafkaAuthorizationOpa
スキーマプロパティーの完全リスト
Open Policy Agent 承認を使用するには、authorization
セクションの type
プロパティーを値 opa
に設定し、必要に応じて OPA プロパティーを設定します。
13.2.41.1. url
Open Policy Agent サーバーへの接続に使用される URL。URL には、オーソライザーによってクエリーされるポリシーが含まれる必要があります。必須。
13.2.41.2. allowOnError
一時的に利用できない場合など、オーソライザーによる Open Policy Agent へのクエリーが失敗した場合に、デフォルトで Kafka クライアントを許可または拒否するかどうかを定義します。デフォルトは false
で、すべてのアクションが拒否されます。
13.2.41.3. initialCacheCapacity
すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの初期容量。デフォルトは 5000
です。
13.2.41.4. maximumCacheSize
すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの最大容量。デフォルトは 50000
です。
13.2.41.5. expireAfterMs
すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、ローカルキャッシュに保持されるレコードの有効期限。キャッシュされた承認決定が Open Policy Agent サーバーからリロードされる頻度を定義します。ミリ秒単位です。デフォルトは 3600000
ミリ秒 (1 時間) です。
13.2.41.6. superUsers
スーパーユーザーとして扱われるユーザープリンシパルのリスト。このリストのユーザープリンシパルは、Open Policy Agent ポリシーをクエリーしなくても常に許可されます。詳細は「Kafka の承認」を参照してください。
Open Policy Agent オーソライザーの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... authorization: type: opa url: http://opa:8181/v1/data/kafka/allow allowOnError: false initialCacheCapacity: 1000 maximumCacheSize: 10000 expireAfterMs: 60000 superUsers: - CN=fred - sam - CN=edward # ...
13.2.41.7. KafkaAuthorizationOpa
スキーマプロパティー
type
プロパティーは、KafkaAuthorizationOpa
タイプの使用を KafkaAuthorizationSimple
、KafkaAuthorizationKeycloak
と区別する識別子です。KafkaAuthorizationOpa
タイプには opa
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
url | Open Policy Agent サーバーへの接続に使用される URL。URL には、オーソライザーによってクエリーされるポリシーが含まれる必要があります。このオプションは必須です。 |
string | |
allowOnError |
一時的に利用できない場合など、オーソライザーによる Open Policy Agent へのクエリーが失敗した場合に、デフォルトで Kafka クライアントを許可または拒否するかどうかを定義します。デフォルトは |
boolean | |
initialCacheCapacity |
すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの初期容量。デフォルトは |
integer | |
maximumCacheSize |
すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、オーソライザーによって使用されるローカルキャッシュの最大容量。デフォルトは |
integer | |
expireAfterMs |
すべてのリクエストに対して Open Policy Agent をクエリーしないようにするために、ローカルキャッシュに保持されるレコードの有効期限。キャッシュされた承認決定が Open Policy Agent サーバーからリロードされる頻度を定義します。ミリ秒単位です。デフォルトは |
integer | |
superUsers | スーパーユーザーのリスト。これは、無制限のアクセス権限を持つユーザープリンシパルのリストです。 |
string array |
13.2.42. KafkaAuthorizationKeycloak
スキーマ参照
KafkaClusterSpec
で使用
type
プロパティーは、KafkaAuthorizationKeycloak
タイプの使用を KafkaAuthorizationSimple
、KafkaAuthorizationOpa
と区別する識別子です。KafkaAuthorizationKeycloak
タイプには keycloak
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
clientId | Kafka クライアントが OAuth サーバーに対する認証に使用し、トークンエンドポイント URI を使用することができる OAuth クライアント ID。 |
string | |
tokenEndpointUri | 承認サーバートークンエンドポイント URI。 |
string | |
tlsTrustedCertificates | OAuth サーバーへの TLS 接続の信頼済み証明書。 |
| |
disableTlsHostnameVerification |
TLS ホスト名の検証を有効または無効にします。デフォルト値は |
boolean | |
delegateToKafkaAcls |
Red Hat Single Sign-On の Authorization Services ポリシーにより DENIED となった場合に、承認の決定を 'Simple' オーソライザーに委譲すべきかどうか。デフォルト値は |
boolean | |
grantsRefreshPeriodSeconds | 連続する付与 (Grants) 更新実行の間隔 (秒単位)。デフォルト値は 60 です。 |
integer | |
grantsRefreshPoolSize | アクティブなセッションの付与(Grants) の更新に使用するスレッドの数。スレッドが多いほど並列処理多くなるため、ジョブがより早く完了します。ただし、使用するスレッドが多いほど、承認サーバーの負荷が大きくなります。デフォルト値は 5 です。 |
integer | |
superUsers | スーパーユーザーの一覧。無制限のアクセス権を取得する必要のあるユーザープリンシパルの一覧が含まれなければなりません。 |
string array |
13.2.43. Rack
スキーマ参照
KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
で使用
異なるラック全体でパーティションレプリカを分散するためにラックアウェアネスを設定します。
ラックは、アベイラビリティーゾーン、データセンター、またはデータセンターの実際のラックを表すことができます。Kafka クラスターの rack
を設定すると、コンシューマーは最も近いレプリカからデータを取得できます。これは、Kafka クラスターが複数のデータセンターにまたがる場合に、ネットワークの負荷を軽減するのに役立ちます。
ラックアウェアネス (Rack Awareness) に Kafka ブローカーを設定するには、Kafka ブローカー Pod をノードに対してスケジュールする際に OpenShift によって使用されるクラスターノードのラベルと一致する topologyKey
の値を指定します。
OpenShift クラスターがクラウドプロバイダープラットフォームで稼働している場合、ラベルはノードが稼働している可用性ゾーンを表す必要があります。通常、ノードには topologyKey
の値として使用できる topology.kubernetes.io/zone
ラベル (または古い OpenShift バージョンでは failure-domain.beta.kubernetes.io/zone
) が付けられます。
ラックアウェアネスの設定によってブローカー Pod およびパーティションレプリカがゾーン全体に分散され、耐障害性が向上されます。また、各 Kafka ブローカーに broker.rack
設定も設定されます。broker.rack
設定によって、ラック ID が各ブローカーに割り当てられます。
ノードがデプロイされたゾーンやラックを表すノードラベルについては、OpenShift 管理者に相談します。
Kafka の rack
の 設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... rack: topologyKey: topology.kubernetes.io/zone config: # ... replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector # ...
クライアントが最も近いレプリカから消費するようにするには、Kafka ReplicaSelector
プラグインに RackAwareReplicaSelector
実装を使用します。ReplicaSelector
プラグインは、クライアントが最も近いレプリカから消費できるようにするロジックを提供します。replica.selector.class
に RackAwareReplicaSelector
を指定して、デフォルト実装から切り替えます。デフォルトの実装では、LeaderSelector
を使用してクライアントのリーダーレプリカを常に選択します。リーダーレプリカからレプリカフォロワーに切り替えると、遅延のコストが発生します。必要に応じて、独自の実装をカスタマイズすることもできます。
Kafka Connect を含むクライアントでは、クライアントがメッセージを消費するために使用するブローカーと同じトポロジーキーを指定します。
Kafka Connect の rack
設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect # ... spec: kafka: # ... rack: topologyKey: topology.kubernetes.io/zone # ...
クライアントには client.rack
ID が割り当てられます。
RackAwareReplicaSelector
は、クライアントが最も近いレプリカから消費できるようにするため、broker.rack
と client.rack
ID の一致を関連付けます。
図13.1 同じアベイラビリティーゾーンのレプリカから消費するクライアントの例

同じラックに複数のレプリカがある場合は、RackAwareReplicaSelector
は常に最新のレプリカを選択します。ラック ID が指定されていない場合や、同じラック ID を持つレプリカが見つからない場合は、リーダーレプリカにフォールバックします。
OpenShift ノードラベルの詳細は、「Well-Known Labels, Annotations and Taints」を参照してください。
13.2.43.1. Rack
スキーマプロパティー
プロパティー | 説明 |
---|---|
topologyKey |
OpenShift クラスターノードに割り当てられたラベルに一致するキー。ラベルの値は、Kafka Connect でブローカーの |
string |
13.2.44. Probe
スキーマ参照
CruiseControlSpec
、EntityTopicOperatorSpec
、EntityUserOperatorSpec
、KafkaBridgeSpec
、KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaExporterSpec
、KafkaMirrorMaker2Spec
、KafkaMirrorMakerSpec
、TlsSidecar
、TopicOperatorSpec
、ZookeeperClusterSpec
で使用
プロパティー | 説明 |
---|---|
failureThreshold | 正常に実行された後に失敗とみなされるプローブの連続失敗回数の最小値。デフォルトは 3 です。最小値は 1 です。 |
integer | |
initialDelaySeconds | 最初に健全性をチェックするまでの初期の遅延。デフォルトは 15 秒です。最小値は 0 です。 |
integer | |
periodSeconds | プローブを実行する頻度 (秒単位)。デフォルトは 10 秒です。最小値は 1 です。 |
integer | |
successThreshold | 失敗後に、プローブが正常とみなされるための最小の連続成功回数。デフォルトは 1 です。liveness は 1 でなければなりません。最小値は 1 です。 |
integer | |
timeoutSeconds | ヘルスチェック試行のタイムアウト。デフォルトは 5 秒です。最小値は 1 です。 |
integer |
13.2.45. JvmOptions
スキーマ参照
CruiseControlSpec
、EntityTopicOperatorSpec
、EntityUserOperatorSpec
、KafkaBridgeSpec
、KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
、KafkaMirrorMakerSpec
、TopicOperatorSpec
、ZookeeperClusterSpec
で使用
プロパティー | 説明 |
---|---|
-XX | JVM への -XX オプションのマップ。 |
map | |
-Xms | JVM への -Xms オプション。 |
string | |
-Xmx | JVM への -Xmx オプション。 |
string | |
gcLoggingEnabled | ガベージコレクションのロギングが有効かどうかを指定します。デフォルトは false です。 |
boolean | |
javaSystemProperties |
|
|
13.2.46. SystemProperty
スキーマ参照
JvmOptions
で使用
プロパティー | 説明 |
---|---|
name | システムプロパティー名。 |
string | |
value | システムプロパティーの値。 |
string |
13.2.47. KafkaJmxOptions
スキーマ参照
KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
で使用
KafkaJmxOptions
スキーマプロパティーの完全リスト
JMX 接続オプションを設定します。
JMX メトリクスは、9999 で JMX ポートを開いて、Kafka ブローカー、Kafka Connect、および MirrorMaker 2.0 から取得されます。jmxOptions
プロパティーを使用して、パスワードで保護される JMX ポートまたは保護されない JMX ポートを設定します。パスワードで保護すると、未許可の Pod によるポートへの不正アクセスを防ぐことができます。
その後、コンポーネントに関するメトリクスを取得できます。
たとえば、Kafka ブローカーごとに、クライアントからのバイト/秒の使用度データや、ブローカーのネットワークの要求レートを取得することができます。
JMX ポートのセキュリティーを有効にするには、authentication
フィールドの type
パラメーターを password
に設定します。
パスワードで保護された JMX の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... jmxOptions: authentication: type: "password" # ... zookeeper: # ...
次に、対応するブローカーを指定して、Pod をクラスターにデプロイし、ヘッドレスサービスを使用して JMX メトリクスを取得できます。
たとえば、ブローカー 0 から JMX メトリクスを取得するには、以下を指定します。
"CLUSTER-NAME-kafka-0.CLUSTER-NAME-kafka-brokers"
CLUSTER-NAME-kafka-0
ブローカー Pod の名前で、CLUSTER-NAME-kafka-brokers
はブローカー Pod の IP を返すヘッドレスサービスの名前になります。
JMX ポートがセキュアである場合、Pod のデプロイメントで JMX Secret からユーザー名とパスワードを参照すると、そのユーザー名とパスワードを取得できます。
保護されていない JMX ポートの場合は、空のオブジェクト {}
を使用してヘッドレスサービスで JMX ポートを開きます。保護されたポートと同じ方法で Pod をデプロイし、メトリクスを取得できますが、この場合はどの Pod も JMX ポートから読み取ることができます。
オープンポート JMX 設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... jmxOptions: {} # ... zookeeper: # ...
その他のリソース
- JMX を使用して公開される Kafka コンポーネントメトリクスの詳細は、Apache Kafka のドキュメントを参照してください。
13.2.47.1. KafkaJmxOptions
スキーマプロパティー
プロパティー | 説明 |
---|---|
authentication |
JMX ポートに接続するための認証設定。タイプは、指定のオブジェクト内の |
13.2.48. KafkaJmxAuthenticationPassword
スキーマ参照
KafkaJmxOptions
で使用
type
プロパティーは、KafkaJmxAuthenticationPassword
タイプを使用する際に、今後追加される可能性のある他のサブタイプと区別する識別子です。KafkaJmxAuthenticationPassword
タイプには password
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.49. JmxPrometheusExporterMetrics
スキーマ参照
CruiseControlSpec
、KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
、KafkaMirrorMakerSpec
、ZookeeperClusterSpec
で使用
type
プロパティーは、JmxPrometheusExporterMetrics
タイプを使用する際に、今後追加される可能性のある他のサブタイプと区別する識別子です。JmxPrometheusExporterMetrics
タイプには jmxPrometheusExporter
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
valueFrom | Prometheus JMX Exporter 設定が保存される ConfigMap エントリー。この設定の構造に関する詳細は、JMX Exporter のドキュメント を参照してください。 |
13.2.50. ExternalConfigurationReference
スキーマ参照
ExternalLogging
、JmxPrometheusExporterMetrics
で使用
プロパティー | 説明 |
---|---|
configMapKeyRef | 設定が含まれる ConfigMap のキーへの参照。詳細は、core/v1 configmapkeyselector の外部ドキュメントを参照してください。 |
13.2.51. InlineLogging
スキーマ参照
CruiseControlSpec
、EntityTopicOperatorSpec
、EntityUserOperatorSpec
、KafkaBridgeSpec
、KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
、KafkaMirrorMakerSpec
、TopicOperatorSpec
、ZookeeperClusterSpec
で使用
type
プロパティーは、InlineLogging
タイプの使用を ExternalLogging
と区別する識別子です。InlineLogging
タイプには inline
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
loggers | ロガー名からロガーレベルへのマップ。 |
map |
13.2.52. ExternalLogging
スキーマ参照
CruiseControlSpec
、EntityTopicOperatorSpec
、EntityUserOperatorSpec
、KafkaBridgeSpec
、KafkaClusterSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
、KafkaMirrorMakerSpec
、TopicOperatorSpec
、ZookeeperClusterSpec
で使用
type
プロパティーは、ExternalLogging
タイプの使用を InlineLogging
と区別する識別子です。ExternalLogging
タイプには external
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
name |
|
string | |
valueFrom |
ロギング設定が保存される |
13.2.53. TlsSidecar
スキーマ参照
CruiseControlSpec
、EntityOperatorSpec
、KafkaClusterSpec
、TopicOperatorSpec
、ZookeeperClusterSpec
で使用
Pod で実行されるコンテナーである TLS サイドカーを設定しますが、サポートの目的で提供されます。。AMQ Streams では、TLS サイドカーは TLS を使用して、コンポーネントと ZooKeeper との間の通信を暗号化および復号化します。
TLS サイドカーは以下で使用されます。
- Entitiy Operator
- Cruise Control
TLS サイドカーは、以下で tlsSidecar
プロパティーを使用して設定されます。
-
Kafka.spec.entityOperator
-
Kafka.spec.cruiseControl
TLS サイドカーは、以下の追加オプションをサポートします。
-
image
-
resources
-
logLevel
-
readinessProbe
-
livenessProbe
resources
プロパティーは、TLS サイドカーに割り当てられる メモリーおよび CPU リソース を指定します。
image
プロパティーは、使用される コンテナーイメージ を設定します。
readinessProbe
および livenessProbe
プロパティーは、TLS サイドカーの healthcheck プローブ を設定します。
logLevel
プロパティーはログレベルを指定します。以下のログレベルがサポートされます。
- emerg
- alert
- crit
- err
- warning
- notice
- info
- debug
デフォルト値は notice です。
TLS サイドカーの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... entityOperator: # ... tlsSidecar: resources: requests: cpu: 200m memory: 64Mi limits: cpu: 500m memory: 128Mi # ... cruiseControl: # ... tlsSidecar: image: my-org/my-image:latest resources: requests: cpu: 200m memory: 64Mi limits: cpu: 500m memory: 128Mi logLevel: debug readinessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 # ...
13.2.53.1. TlsSidecar
スキーマプロパティー
プロパティー | 説明 |
---|---|
image | コンテナーの Docker イメージ。 |
string | |
livenessProbe | Pod の liveness チェック。 |
logLevel |
TLS サイドカーのログレベル。デフォルト値は |
string ([emerg、debug、crit、err、alert、warning、notice、info] のいずれか) | |
readinessProbe | Pod の readiness チェック。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
13.2.54. KafkaClusterTemplate
スキーマ参照
KafkaClusterSpec
で使用
プロパティー | 説明 |
---|---|
statefulset |
Kafka |
pod |
Kafka |
bootstrapService |
Kafka ブートストラップ |
brokersService |
Kafka ブローカー |
externalBootstrapService |
Kafka 外部ブートストラップ |
perPodService |
OpenShift の外部からアクセスするために使用される Kafka の Pod ごとの |
externalBootstrapRoute |
Kafka 外部ブートストラップ |
perPodRoute |
OpenShift の外部からアクセスするために使用される Kafka の Pod ごとの |
externalBootstrapIngress |
Kafka 外部ブートストラップ |
perPodIngress |
OpenShift の外部からアクセスするために使用される Kafka の Pod ごとの |
persistentVolumeClaim |
すべての Kafka |
podDisruptionBudget |
Kafka |
kafkaContainer | Kafka ブローカーコンテナーのテンプレート。 |
tlsSidecarContainer |
|
initContainer | Kafka init コンテナーのテンプレート。 |
clusterCaCert | Kafka Cluster 証明書の公開鍵が含まれる Secret のテンプレート。 |
clusterRoleBinding | Kafka ClusterRoleBinding のテンプレート。 |
13.2.55. StatefulSetTemplate
スキーマ参照
KafkaClusterTemplate
、ZookeeperClusterTemplate
で使用
プロパティー | 説明 |
---|---|
metadata | リソースに適用済みのメタデータ。 |
podManagementPolicy |
この StatefulSet に使用される PodManagementPolicy。有効な値は |
string ([OrderedReady、Parallel] のいずれか) |
13.2.56. MetadataTemplate
スキーマ参照
DeploymentTemplate
、ExternalServiceTemplate
、PodDisruptionBudgetTemplate
、PodTemplate
、ResourceTemplate
、StatefulSetTemplate
で使用
MetadataTemplate
スキーマプロパティーの完全リスト
Labels
および Annotations
は、リソースの識別および整理に使用され、metadata
プロパティーで設定されます。
以下に例を示します。
# ... template: statefulset: metadata: labels: label1: value1 label2: value2 annotations: annotation1: value1 annotation2: value2 # ...
labels
および annotations
フィールドには、予約された文字列 strimzi.io
が含まれないすべてのラベルやアノテーションを含めることができます。strimzi.io
が含まれるラベルやアノテーションは、内部で AMQ Streams によって使用され、設定することはできません。
13.2.56.1. MetadataTemplate
スキーマプロパティー
プロパティー | 説明 |
---|---|
labels |
リソーステンプレートに追加されたラベル。 |
map | |
annotations |
リソーステンプレートに追加されたアノテーション。 |
map |
13.2.57. PodTemplate
スキーマ参照
CruiseControlTemplate
、EntityOperatorTemplate
、KafkaBridgeTemplate
、KafkaClusterTemplate
、KafkaConnectTemplate
、KafkaExporterTemplate
、KafkaMirrorMakerTemplate
、ZookeeperClusterTemplate
で使用
Kafka Pod のテンプレートを設定します。
PodTemplate
の設定例
# ... template: pod: metadata: labels: label1: value1 annotations: anno1: value1 imagePullSecrets: - name: my-docker-credentials securityContext: runAsUser: 1000001 fsGroup: 0 terminationGracePeriodSeconds: 120 # ...
13.2.57.1. hostAliases
hostAliases
プロパティーを使用して、Pod の /etc/hosts
ファイルに注入されるホストおよび IP アドレスの一覧を指定します。
この設定は特に、クラスター外部の接続がユーザーによっても要求される場合に Kafka Connect または MirrorMaker で役立ちます。
hostAliases
の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect #... spec: # ... template: pod: hostAliases: - ip: "192.168.1.86" hostnames: - "my-host-1" - "my-host-2" #...
13.2.57.2. PodTemplate
スキーマプロパティー
プロパティー | 説明 |
---|---|
metadata | リソースに適用済みのメタデータ。 |
imagePullSecrets |
この Pod で使用されるイメージのプルに使用する同じ namespace のシークレットへの参照の一覧です。Cluster Operator の |
LocalObjectReference array | |
securityContext | Pod レベルのセキュリティー属性と共通のコンテナー設定を設定します。詳細は、core/v1 podsecuritycontext の外部ドキュメント を参照してください。 |
terminationGracePeriodSeconds | 猶予期間とは、Pod で実行されているプロセスに終了シグナルが送信されてから、kill シグナルでプロセスを強制的に終了するまでの期間 (秒単位) です。この値は、プロセスの予想されるクリーンアップ時間よりも長く設定します。値は負の値ではない整数にする必要があります。値をゼロにすると、即座に削除されます。非常に大型な Kafka クラスターの場合は、正常終了期間を延長し、Kafka ブローカーの終了前に作業を別のブローカーに転送する時間を十分確保する必要があることがあります。デフォルトは 30 秒です。 |
integer | |
affinity | Pod のアフィニティールール。詳細は、core/v1 affinity の外部ドキュメント を参照してください。 |
tolerations | Pod の許容 (Toleration)。詳細は、core/v1 toleration の外部ドキュメント を参照してください。 |
Toleration array | |
priorityClassName | 優先順位を Pod に割り当てるために使用される優先順位クラス (Priority Class) の名前。Priority Class (優先順位クラス) の詳細は、「Pod Priority and Preemption」を参照してください。 |
string | |
schedulerName |
この |
string | |
hostAliases | Pod の HostAliases。HostAliases は、指定された場合に Pod の hosts ファイルに注入されるホストおよび IP のオプションのリストです。詳細は、core/v1 HostAlias の外部ドキュメント を参照してください。 |
HostAlias array | |
topologySpreadConstraints | Pod のトポロジー分散制約。詳細は、core/v1 topologyspreadconstraint の外部ドキュメント を参照してください。 |
TopologySpreadConstraint array |
13.2.58. ResourceTemplate
スキーマ参照
CruiseControlTemplate
、EntityOperatorTemplate
、KafkaBridgeTemplate
、KafkaClusterTemplate
、KafkaConnectTemplate
、KafkaExporterTemplate
、KafkaUserTemplate
、ZookeeperClusterTemplate
で使用
プロパティー | 説明 |
---|---|
metadata | リソースに適用済みのメタデータ。 |
13.2.59. ExternalServiceTemplate
スキーマ参照
ExternalServiceTemplate
スキーマプロパティーの完全リスト
ロードバランサーまたはノードポートを使用して OpenShift 外部で Kafka を公開する場合、ラベルとアノテーションの他にプロパティーを使用してサービスの作成をカスタマイズできます。
カスタマイズした外部サービスの例
# ... template: externalBootstrapService: externalTrafficPolicy: Local loadBalancerSourceRanges: - 10.0.0.0/8 - 88.208.76.87/32 perPodService: externalTrafficPolicy: Local loadBalancerSourceRanges: - 10.0.0.0/8 - 88.208.76.87/32 # ...
13.2.59.1. ExternalServiceTemplate
スキーマプロパティー
プロパティー | 説明 |
---|---|
metadata | リソースに適用済みのメタデータ。 |
externalTrafficPolicy |
|
string ([Local、Cluster] のいずれか) | |
loadBalancerSourceRanges |
|
string array |
13.2.60. PodDisruptionBudgetTemplate
スキーマ参照
CruiseControlTemplate
、KafkaBridgeTemplate
、KafkaClusterTemplate
、KafkaConnectTemplate
、KafkaMirrorMakerTemplate
、ZookeeperClusterTemplate
で使用
PodDisruptionBudgetTemplate
スキーマプロパティーの完全リスト
AMQ Streams は、新しい StatefulSet
または Deployment
ごとに PodDisruptionBudget
を作成します。デフォルトでは、Pod の Disruption Budget (停止状態の予算) は単一の Pod を指定時に利用不可能にすることのみ許可します。PodDisruptionBudget.spec
リソースの maxUnavailable
プロパティーのデフォルト値を変更することで、許容される利用不可能な Pod の数を増やすことができます。
PodDisruptionBudget
テンプレートの例
# ... template: podDisruptionBudget: metadata: labels: key1: label1 key2: label2 annotations: key1: label1 key2: label2 maxUnavailable: 1 # ...
13.2.60.1. PodDisruptionBudgetTemplate
スキーマプロパティー
プロパティー | 説明 |
---|---|
metadata |
|
maxUnavailable |
自動 Pod エビクションを許可するための利用不可能な Pod の最大数。Pod エビクションは、 |
integer |
13.2.61. ContainerTemplate
スキーマ参照
CruiseControlTemplate
、EntityOperatorTemplate
、KafkaBridgeTemplate
、KafkaClusterTemplate
、KafkaConnectTemplate
、KafkaExporterTemplate
、KafkaMirrorMakerTemplate
、ZookeeperClusterTemplate
で使用
ContainerTemplate
スキーマプロパティーの完全リスト
コンテナーのカスタムのセキュリティーコンテキストおよび環境変数を設定できます。
環境変数は、env
プロパティーで name
および value
フィールドのあるオブジェクトのリストとして定義されます。以下の例は、Kafka ブローカーコンテナーに設定された 2 つのカスタム環境変数と 1 つのセキュリティーコンテキストを示しています。
# ... template: kafkaContainer: env: - name: EXAMPLE_ENV_1 value: example.env.one - name: EXAMPLE_ENV_2 value: example.env.two securityContext: runAsUser: 2000 # ...
KAFKA_
で始まる環境変数は AMQ Streams 内部となるため、使用しないようにしてください。AMQ Streams によってすでに使用されているカスタム環境変数を設定すると、その環境変数は無視され、警告がログに記録されます。
13.2.61.1. ContainerTemplate
スキーマプロパティー
プロパティー | 説明 |
---|---|
env | コンテナーに適用する必要のある環境変数。 |
| |
securityContext | コンテナーのセキュリティーコンテキスト。詳細は、core/v1 securitycontext の外部ドキュメント を参照してください。 |
13.2.62. ContainerEnvVar
スキーマ参照
プロパティー | 説明 |
---|---|
name | 環境変数のキー。 |
string | |
value | 環境変数の値。 |
string |
13.2.63. ZookeeperClusterSpec
スキーマ参照
KafkaSpec
で使用
ZookeeperClusterSpec
スキーマプロパティーの完全リスト
ZooKeeper クラスターを設定します。
13.2.63.1. config
config
プロパティーを使用して、ZooKeeper オプションをキーとして設定します。
標準の Apache ZooKeeper 設定が提供されることがあり、AMQ Streams によって直接管理されないプロパティーに限定されます。
以下に関連する設定オプションは設定できません。
- セキュリティー (暗号化、認証、および承認)
- リスナーの設定
- データディレクトリーの設定
- ZooKeeper クラスターの構成
値は以下の JSON タイプのいずれかになります。
- 文字列
- 数値
- ブール値
AMQ Streams で直接管理されるオプション以外の、ZooKeeper ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。
-
server.
-
dataDir
-
dataLogDir
-
clientPort
-
authProvider
-
quorum.auth
-
requireClientAuthScheme
禁止されているオプションが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。サポートされるその他すべてのオプションは ZooKeeper に渡されます。
禁止されているオプションには例外があります。TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。
ZooKeeper の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... zookeeper: # ... config: autopurge.snapRetainCount: 3 autopurge.purgeInterval: 1 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" # ...
13.2.63.2. logging
ZooKeeper には設定可能なロガーがあります。
-
zookeeper.root.logger
ZooKeeper では Apache log4j
ロガー実装が使用されます。
logging
プロパティーを使用してロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # ... zookeeper: # ... logging: type: inline loggers: zookeeper.root.logger: "INFO" # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # ... zookeeper: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: zookeeper-log4j.properties # ...
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.63.3. ZookeeperClusterSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
replicas | クラスター内の Pod 数。 |
integer | |
image | Pod の Docker イメージ。 |
string | |
storage |
ストレージの設定 (ディスク)。更新はできません。タイプは、指定のオブジェクト内の |
config | ZooKeeper ブローカーの設定。次の接頭辞のあるプロパティーは設定できません: server.、 dataDir、dataLogDir、clientPort、authProvider、quorum.auth、requireClientAuthScheme、 snapshot.trust.empty、standaloneEnabled、reconfigEnabled、4lw.commands.whitelist、secureClientPort、ssl、serverCnxnFactory、sslQuorum (次の例外を除く: ssl.protocol、ssl.quorum.protocol、ssl.enabledProtocols、ssl.quorum.enabledProtocols、ssl.ciphersuites、ssl.quorum.ciphersuites、ssl.hostnameVerification、ssl.quorum.hostnameVerification) |
map | |
affinity |
|
tolerations |
|
Toleration array | |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
jvmOptions | Pod の JVM オプション。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
metrics |
|
map | |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
logging |
ZooKeeper のロギング設定。タイプは、指定のオブジェクト内の |
template |
ZooKeeper クラスターリソースのテンプレート。テンプレートを使用すると、ユーザーは |
tlsSidecar |
|
13.2.64. ZookeeperClusterTemplate
スキーマ参照
プロパティー | 説明 |
---|---|
statefulset |
ZooKeeper |
pod |
ZooKeeper |
clientService |
ZooKeeper クライアント |
nodesService |
ZooKeeper ノード |
persistentVolumeClaim |
すべての ZooKeeper |
podDisruptionBudget |
ZooKeeper |
zookeeperContainer | ZooKeeper コンテナーのテンプレート。 |
tlsSidecarContainer |
|
13.2.65. TopicOperatorSpec
スキーマ参照
TopicOperatorSpec
タイプは非推奨となり、API バージョン v1beta2
で削除されます。代わりに EntityTopicOperatorSpec
を使用してください。
KafkaSpec
で使用
プロパティー | 説明 |
---|---|
watchedNamespace | Topic Operator が監視する必要のある namespace。 |
string | |
image | Topic Operator に使用するイメージ。 |
string | |
reconciliationIntervalSeconds | 定期的な調整の間隔。 |
integer | |
zookeeperSessionTimeoutSeconds | ZooKeeper セッションのタイムアウト。 |
integer | |
affinity |
|
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
topicMetadataMaxAttempts | トピックメタデータの取得を試行する回数。 |
integer | |
tlsSidecar |
|
logging |
ロギング設定。タイプは、指定のオブジェクト内の |
jvmOptions | Pod の JVM オプション。 |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
startupProbe | Pod の起動チェック。 |
13.2.66. EntityOperatorSpec
スキーマ参照
KafkaSpec
で使用
プロパティー | 説明 |
---|---|
topicOperator | Topic Operator の設定。 |
userOperator | User Operator の設定。 |
affinity |
|
tolerations |
|
Toleration array | |
tlsSidecar | TLS サイドカーの設定。 |
template |
Entity Operator リソースのテンプレート。テンプレートを使用すると、ユーザーは |
13.2.67. EntityTopicOperatorSpec
スキーマ参照
EntityTopicOperatorSpec
スキーマプロパティーの完全リスト
Topic Operator を設定します。
13.2.67.1. logging
Topic Operator には設定可能なロガーがあります。
-
rootLogger.level
Topic Operator では Apache log4j2
ロガー実装が使用されます。
Kafka リソース Kafka
の entityOperator.topicOperator
フィールドの logging
プロパティーを使用して、ロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j2.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: # ... topicOperator: watchedNamespace: my-topic-namespace reconciliationIntervalSeconds: 60 logging: type: inline loggers: rootLogger.level: INFO # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: # ... topicOperator: watchedNamespace: my-topic-namespace reconciliationIntervalSeconds: 60 logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: topic-operator-log4j2.properties # ...
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.67.2. EntityTopicOperatorSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
watchedNamespace | Topic Operator が監視する必要のある namespace。 |
string | |
image | Topic Operator に使用するイメージ。 |
string | |
reconciliationIntervalSeconds | 定期的な調整の間隔。 |
integer | |
zookeeperSessionTimeoutSeconds | ZooKeeper セッションのタイムアウト。 |
integer | |
startupProbe | Pod の起動チェック。 |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
topicMetadataMaxAttempts | トピックメタデータの取得を試行する回数。 |
integer | |
logging |
ロギング設定。タイプは、指定のオブジェクト内の |
jvmOptions | Pod の JVM オプション。 |
13.2.68. EntityUserOperatorSpec
スキーマ参照
EntityUserOperatorSpec
スキーマプロパティーの完全リスト
User Operator を設定します。
13.2.68.1. logging
User Operator には設定可能なロガーがあります。
-
rootLogger.level
User Operator では Apache log4j2
ロガー実装が使用されます。
Kafka
リソースの entityOperator.userOperator
フィールドの logging
プロパティーを使用して、ロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j2.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: # ... userOperator: watchedNamespace: my-topic-namespace reconciliationIntervalSeconds: 60 logging: type: inline loggers: rootLogger.level: INFO # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: # ... entityOperator: # ... userOperator: watchedNamespace: my-topic-namespace reconciliationIntervalSeconds: 60 logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: user-operator-log4j2.properties # ...
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.68.2. EntityUserOperatorSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
watchedNamespace | User Operator が監視する必要のある namespace。 |
string | |
image | User Operator に使用するイメージ。 |
string | |
reconciliationIntervalSeconds | 定期的な調整の間隔。 |
integer | |
zookeeperSessionTimeoutSeconds | ZooKeeper セッションのタイムアウト。 |
integer | |
secretPrefix | KafkaUser 名に追加され、Secret 名として使用されるプレフィックス。 |
string | |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
logging |
ロギング設定。タイプは、指定のオブジェクト内の |
jvmOptions | Pod の JVM オプション。 |
13.2.69. EntityOperatorTemplate
スキーマ参照
プロパティー | 説明 |
---|---|
deployment |
Entity Operator |
pod |
Entity Operator |
tlsSidecarContainer | Entity Operator TLS サイドカーコンテナーのテンプレート。 |
topicOperatorContainer | Entity Topic Operator コンテナーのテンプレート。 |
userOperatorContainer | Entity User Operator コンテナーのテンプレート。 |
13.2.70. CertificateAuthority
スキーマ参照
KafkaSpec
で使用
TLS 証明書のクラスター内での使用方法の設定。これは、クラスター内の内部通信に使用される証明書および Kafka.spec.kafka.listeners.tls
を介したクライアントアクセスに使用される証明書の両方に適用されます。
プロパティー | 説明 |
---|---|
generateCertificateAuthority | true の場合、認証局の証明書が自動的に生成されます。それ以外の場合は、ユーザーは CA 証明書で Secret を提供する必要があります。デフォルトは true です。 |
boolean | |
generateSecretOwnerReference |
|
boolean | |
validityDays | 生成される証明書の有効日数。デフォルトは 365 です。 |
integer | |
renewalDays |
証明書更新期間の日数。これは、証明書の期限が切れるまでの日数です。この間に、更新アクションを実行することができます。 |
integer | |
certificateExpirationPolicy |
|
string ([replace-key、renew-certificate] のいずれか) |
13.2.71. CruiseControlSpec
スキーマ参照
KafkaSpec
で使用
プロパティー | 説明 |
---|---|
image | Pod の Docker イメージ。 |
string | |
tlsSidecar | TLS サイドカーの設定。 |
resources | Cruise Control コンテナー用に予約された CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
livenessProbe | Cruise Control コンテナーの Pod liveness チェック |
readinessProbe | Cruise Control コンテナーの Pod readiness チェック |
jvmOptions | Cruise Control コンテナーの JVM オプション |
logging |
Cruise Control のロギング設定 (Log4j 2)。タイプは、指定のオブジェクト内の |
template |
Cruise Control のリソースである |
brokerCapacity |
Cruise Control |
config | Cruise Control の設定。設定オプションの完全リストは、https://github.com/linkedin/cruise-control/wiki/Configurations を参照してください。次のプレフィックスのあるプロパティーは設定できません: bootstrap.servers、client.id、zookeeper.、network.、security.、failed.brokers.zk.path、webserver.http.、 webserver.api.urlprefix、webserver.session.path、webserver.accesslog.、two.step.、request.reason.required、metric.reporter.sampler.bootstrap.servers、 metric.reporter.topic、partition.metric.sample.store.topic、broker.metric.sample.store.topic、capacity.config.file、self.healing.、anomaly.detection.、ssl (例外は ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols、webserver.http.cors.enabled、webserver.http.cors.origin、webserver.http.cors.exposeheaders) |
map | |
metrics |
|
map | |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
13.2.72. CruiseControlTemplate
スキーマ参照
プロパティー | 説明 |
---|---|
deployment |
Cruise Control |
pod |
Cruise Control |
apiService |
Cruise Control API |
podDisruptionBudget |
Cruise Control |
cruiseControlContainer | Cruise Control コンテナーのテンプレート。 |
tlsSidecarContainer | Cruise Control TLS サイドカーコンテナーのテンプレート。 |
13.2.73. BrokerCapacity
スキーマ参照
プロパティー | 説明 |
---|---|
disk | ディスクのバイト単位のブローカー容量 (例: 100Gi) |
string | |
cpuUtilization | パーセントで表された CPU リソース使用率のブローカー容量 (0 - 100)。 |
integer | |
inboundNetwork | バイト毎秒単位のインバウンドネットワークスループットのブローカー容量 (例: 10000KB/s)。 |
string | |
outboundNetwork | バイト毎秒単位のアウトバウンドネットワークスループットのブローカー容量 (例: 10000KB/s)。 |
string |
13.2.74. KafkaExporterSpec
スキーマ参照
KafkaSpec
で使用
プロパティー | 説明 |
---|---|
image | Pod の Docker イメージ。 |
string | |
groupRegex |
収集するコンシューマーグループを指定する正規表現。デフォルト値は |
string | |
topicRegex |
収集するトピックを指定する正規表現。デフォルト値は |
string | |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
logging |
指定の重大度以上のログメッセージのみ。有効な値は [ |
string | |
enableSaramaLogging | Kafka Exporter によって使用される Go クライアントライブラリーである Sarama ロギングを有効にします。 |
boolean | |
template | デプロイメントテンプレートおよび Pod のカスタマイズ。 |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
13.2.75. KafkaExporterTemplate
スキーマ参照
プロパティー | 説明 |
---|---|
deployment |
Kafka Exporter |
pod |
Kafka Exporter |
service |
Kafka Exporter |
container | Kafka Exporter コンテナーのテンプレート。 |
13.2.76. KafkaStatus
スキーマ参照
Kafka
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
listeners | 内部リスナーおよび外部リスナーのアドレス。 |
| |
clusterId | Kafka クラスター ID。 |
string |
13.2.77. Condition
スキーマ参照
KafkaBridgeStatus
、KafkaConnectorStatus
、KafkaConnectS2IStatus
、KafkaConnectStatus
、KafkaMirrorMaker2Status
、KafkaMirrorMakerStatus
、KafkaRebalanceStatus
、KafkaStatus
、KafkaTopicStatus
、KafkaUserStatus
で使用
プロパティー | 説明 |
---|---|
type | リソース内の他の条件と区別するために使用される条件の固有識別子。 |
string | |
status | 条件のステータス (True、False、または Unknown のいずれか)。 |
string | |
lastTransitionTime | タイプの条件がある状態から別の状態へと最後に変更した時間。必須形式は、UTC タイムゾーンの 'yyyy-MM-ddTHH:mm:ssZ' です。 |
string | |
reason | 条件の最後の遷移の理由 (CamelCase の単一の単語)。 |
string | |
message | 条件の最後の遷移の詳細を示す、人間が判読できるメッセージ。 |
string |
13.2.78. ListenerStatus
スキーマ参照
KafkaStatus
で使用
プロパティー | 説明 |
---|---|
type |
リスナーのタイプ。次の 3 つのタイプのいずれかになります: |
string | |
addresses | このリスナーのアドレス一覧。 |
| |
bootstrapServers |
このリスナーを使用して Kafka クラスターに接続するための |
string | |
certificates |
指定のリスナーへの接続時に、サーバーのアイデンティティーを検証するために使用できる TLS 証明書の一覧。 |
string array |
13.2.79. ListenerAddress
スキーマ参照
ListenerStatus
で使用
プロパティー | 説明 |
---|---|
host | Kafka ブートストラップサービスの DNS 名または IP アドレス。 |
string | |
port | Kafka ブートストラップサービスのポート。 |
integer |
13.2.80. KafkaConnect
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka Connect クラスターの仕様。 |
status | Kafka Connect クラスターのステータス。 |
13.2.81. KafkaConnectSpec
スキーマ参照
KafkaConnect
で使用
KafkaConnectSpec
スキーマプロパティーの完全リスト
Kafka Connect クラスターを設定します。
13.2.81.1. config
config
プロパティーを使用して、Kafka オプションをキーとして設定します。
標準の Apache Kafka Connect 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
以下に関連する設定オプションは設定できません。
- Kafka クラスターブートストラップアドレス
- セキュリティー (暗号化、認証、および承認)
- リスナー / REST インターフェースの設定
- プラグインパスの設定
値は以下の JSON タイプのいずれかになります。
- 文字列
- 数値
- ブール値
AMQ Streams で直接管理されるオプションを除き、Apache Kafka ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションは禁止されています。
-
ssl.
-
sasl.
-
security.
-
listeners
-
plugin.path
-
rest.
-
bootstrap.servers
禁止されているオプションが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka Connect に渡されます。
提供された config
オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Connect クラスターが起動しなかったり、不安定になる可能性があります。この状況で、KafkaConnect.spec.config
または KafkaConnectS2I.spec.config
オブジェクトの設定を修正すると、Cluster Operator は新しい設定をすべての Kafka Connect ノードにロールアウトできます。
以下のオプションにはデフォルト値があります。
-
group.id
、デフォルト値connect-cluster
-
offset.storage.topic
、デフォルト値connect-cluster-offsets
-
config.storage.topic
、デフォルト値connect-cluster-configs
-
status.storage.topic
、デフォルト値connect-cluster-status
-
key.converter
、デフォルト値org.apache.kafka.connect.json.JsonConverter
-
value.converter
、デフォルト値org.apache.kafka.connect.json.JsonConverter
これらのオプションは、KafkaConnect.spec.config
または KafkaConnectS2I.spec.config
プロパティーになかった場合に自動的に設定されます。
禁止されているオプションには例外があります。TLS バージョンの特定の 暗号スイート を使用して、クライアント接続に許可される 3 つの ssl
設定オプションを使用します。暗号スイートは、セキュアな接続とデータ転送のためのアルゴリズムを組み合わせます。また、ssl.endpoint.identification.algorithm
プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。
Kafka Connect の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... config: group.id: my-connect-cluster offset.storage.topic: my-connect-cluster-offsets config.storage.topic: my-connect-cluster-configs status.storage.topic: my-connect-cluster-status key.converter: org.apache.kafka.connect.json.JsonConverter value.converter: org.apache.kafka.connect.json.JsonConverter key.converter.schemas.enable: true value.converter.schemas.enable: true config.storage.replication.factor: 3 offset.storage.replication.factor: 3 status.storage.replication.factor: 3 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" ssl.endpoint.identification.algorithm: HTTPS # ...
TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。また、ssl.endpoint.identification.algorithm
プロパティーを設定して、 ホスト名の検証を有効または無効にすることもできます。
13.2.81.2. logging
Kafka Connect (および Source2Image サポートのある Kafka Connect) には独自の設定可能なロガーがあります。
-
connect.root.logger.level
-
log4j.logger.org.reflections
実行中の Kafka Connect プラグインに応じて、さらにロガーが追加されます。
curl リクエストを使用して、Kafka ブローカー Pod から稼働している Kafka Connect ロガーの完全リストを取得します。
curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
Kafka Connect では Apache log4j
ロガー実装が使用されます。
logging
プロパティーを使用してロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect spec: # ... logging: type: inline loggers: connect.root.logger.level: "INFO" # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect spec: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: connect-logging.log4j # ...
設定されていない利用可能なロガーのレベルは OFF
に設定されています。
Cluster Operator を使用して Kafka Connect がデプロイされた場合、Kafka Connect のロギングレベルの変更は動的に適用されます。
外部ロギングを使用する場合は、ロギングアペンダーが変更されるとローリングアップデートがトリガーされます。
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.81.3. KafkaConnectSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
version | Kafka Connect のバージョン。デフォルトは 2.7.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。 |
string | |
replicas | Kafka Connect グループの Pod 数。 |
integer | |
image | Pod の Docker イメージ。 |
string | |
bootstrapServers | 接続するブートストラップサーバー。これは <hostname>:<port> ペアのコンマ区切りリストとして指定する必要があります。 |
string | |
tls | TLS 設定。 |
authentication |
Kafka Connect の認証設定。タイプは、指定のオブジェクト内の |
| |
config | Kafka Connect の設定。次の接頭辞を持つプロパティーは設定できません: ssl.、sasl.、security.、listeners、plugin.path、rest.、bootstrap.servers、consumer.interceptor.classes、producer.interceptor.classes (ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols を除く) |
map | |
resources | CPU とメモリーリソースおよび要求された初期リソースの上限。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
jvmOptions | Pod の JVM オプション。 |
jmxOptions | JMX オプション。 |
affinity |
|
tolerations |
|
Toleration array | |
logging |
Kafka Connect のロギング設定。タイプは、指定のオブジェクト内の |
metrics |
|
map | |
tracing |
Kafka Connect でのトレーシングの設定。タイプは、指定のオブジェクト内の |
template |
Kafka Connect および Kafka Connect S2I リソースのテンプレート。テンプレートを使用すると、ユーザーは |
externalConfiguration | Secret または ConfigMap から Kafka Connect Pod にデータを渡し、これを使用してコネクターを設定します。 |
build | Connect コンテナーイメージを構築する方法を設定します。任意設定。 |
clientRackInitImage |
|
string | |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
rack | client.rack コンシューマー設定として使用されるノードラベルの設定。 |
13.2.82. KafkaConnectTls
スキーマ参照
KafkaConnectS2ISpec
、KafkaConnectSpec
で使用
KafkaConnectTls
スキーマプロパティーの完全リスト
Kafka Connect をクラスターに接続するために TLS で信頼される証明書を設定します。
13.2.82.1. trustedCertificates
trustedCertificates
プロパティー を使用してシークレットのリストを提供します。
13.2.82.2. KafkaConnectTls
スキーマプロパティー
プロパティー | 説明 |
---|---|
trustedCertificates | TLS 接続の信頼済み証明書。 |
|
13.2.83. KafkaClientAuthenticationTls
スキーマ参照
KafkaBridgeSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2ClusterSpec
、KafkaMirrorMakerConsumerSpec
、KafkaMirrorMakerProducerSpec
で使用
KafkaClientAuthenticationTls
スキーマプロパティーの完全リスト
TLS クライアント認証を設定するには、type
プロパティーを tls
の値に設定します。TLS クライアント認証は TLS 証明書を使用して認証します。
13.2.83.1. certificateAndKey
証明書は certificateAndKey
プロパティーで指定され、常に OpenShift シークレットからロードされます。シークレットでは、公開鍵と秘密鍵の 2 つの鍵を使用して証明書を X509 形式で保存する必要があります。
User Operator によって作成されたシークレットを使用できます。または、認証に使用される鍵で独自の TLS 証明書ファイルを作成し、ファイルから Secret
を作成することもできます。
oc create secret generic MY-SECRET \ --from-file=MY-PUBLIC-TLS-CERTIFICATE-FILE.crt \ --from-file=MY-PRIVATE.key
TLS クライアント認証は TLS 接続でのみ使用できます。
TLS クライアント認証の設定例
authentication: type: tls certificateAndKey: secretName: my-secret certificate: my-public-tls-certificate-file.crt key: private.key
13.2.83.2. KafkaClientAuthenticationTls
スキーマプロパティー
type
プロパティーは、KafkaClientAuthenticationTls
タイプの使用を KafkaClientAuthenticationScramSha512
、KafkaClientAuthenticationPlain
、および KafkaClientAuthenticationOAuth
と区別する識別子です。KafkaClientAuthenticationTls
タイプには tls
の値が必要です。
プロパティー | 説明 |
---|---|
certificateAndKey |
証明書と秘密鍵のペアを保持する |
type |
|
string |
13.2.84. KafkaClientAuthenticationScramSha512
スキーマ参照
KafkaBridgeSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2ClusterSpec
、KafkaMirrorMakerConsumerSpec
、KafkaMirrorMakerProducerSpec
で使用
KafkaClientAuthenticationScramSha512
スキーマプロパティーの完全リスト
SASL ベースの SCRAM-SHA-512 認証を設定するには、type
プロパティーを scram-sha-512
に設定します。SCRAM-SHA-512 認証メカニズムには、ユーザー名とパスワードが必要です。
13.2.84.1. username
username
プロパティーでユーザー名を指定します。
13.2.84.2. passwordSecret
passwordSecret
プロパティーで、パスワードを含む Secret
へのリンクを指定します。
User Operator によって作成されたシークレットを使用できます。
必要に応じて、認証に使用するクリアテキストのパスワードが含まれるテキストファイルを作成できます。
echo -n PASSWORD > MY-PASSWORD.txt
次に、テキストファイルから Secret
を作成し、パスワードに独自のフィールド名 (鍵) を設定できます。
oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt
Kafka Connect の SCRAM-SHA-512 クライアント認証の Secret 例
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm
secretName
プロパティーには Secret
の名前が含まれ、password
プロパティーには Secret
内にパスワードが格納される鍵の名前が含まれます。
password
プロパティーには、実際のパスワードを指定しないでください。
Kafka Connect の SASL ベース SCRAM-SHA-512 クライアント認証の設定例
authentication: type: scram-sha-512 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field
13.2.84.3. KafkaClientAuthenticationScramSha512
スキーマプロパティー
type
プロパティーは、KafkaClientAuthenticationScramSha512
タイプの使用を KafkaClientAuthenticationTls
、KafkaClientAuthenticationPlain
、および KafkaClientAuthenticationOAuth
と区別する識別子です。KafkaClientAuthenticationScramSha512
タイプには scram-sha-512
の値が必要です。
プロパティー | 説明 |
---|---|
passwordSecret |
パスワードを保持する |
type |
|
string | |
username | 認証に使用されるユーザー名。 |
string |
13.2.85. PasswordSecretSource
スキーマ参照
KafkaClientAuthenticationPlain
、KafkaClientAuthenticationScramSha512
で使用
プロパティー | 説明 |
---|---|
password | パスワードが保存される Secret のキーの名前。 |
string | |
secretName | パスワードを含むシークレットの名前。 |
string |
13.2.86. KafkaClientAuthenticationPlain
スキーマ参照
KafkaBridgeSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2ClusterSpec
、KafkaMirrorMakerConsumerSpec
、KafkaMirrorMakerProducerSpec
で使用
KafkaClientAuthenticationPlain
スキーマプロパティーの完全リスト
SASL ベースの PLAIN 認証を設定するには、type
プロパティーを plain
に設定します。SASL PLAIN 認証メカニズムには、ユーザー名とパスワードが必要です。
SASL PLAIN メカニズムは、クリアテキストでユーザー名とパスワードをネットワーク全体に転送します。TLS による暗号化が有効になっている場合にのみ SASL PLAIN 認証を使用します。
13.2.86.1. username
username
プロパティーでユーザー名を指定します。
13.2.86.2. passwordSecret
passwordSecret
プロパティーで、パスワードを含む Secret
へのリンクを指定します。
User Operator によって作成されたシークレットを使用できます。
必要に応じて、認証に使用するクリアテキストのパスワードが含まれるテキストファイルを作成します。
echo -n PASSWORD > MY-PASSWORD.txt
次に、テキストファイルから Secret
を作成し、パスワードに独自のフィールド名 (鍵) を設定できます。
oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt
Kafka Connect の PLAIN クライアント認証の Secret 例
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm
secretName
プロパティーには Secret
の名前が含まれ、password
プロパティーには Secret
内にパスワードが格納されるキーの名前が含まれます。
password
プロパティーには、実際のパスワードを指定しないでください。
SASL ベースの PLAIN クライアント認証の設定例
authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name
13.2.86.3. KafkaClientAuthenticationPlain
スキーマプロパティー
type
プロパティーは、KafkaClientAuthenticationPlain
タイプの使用を KafkaClientAuthenticationTls
、KafkaClientAuthenticationScramSha512
、および KafkaClientAuthenticationOAuth
と区別する識別子です。KafkaClientAuthenticationPlain
タイプには plain
の値が必要です。
プロパティー | 説明 |
---|---|
passwordSecret |
パスワードを保持する |
type |
|
string | |
username | 認証に使用されるユーザー名。 |
string |
13.2.87. KafkaClientAuthenticationOAuth
スキーマ参照
KafkaBridgeSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2ClusterSpec
、KafkaMirrorMakerConsumerSpec
、KafkaMirrorMakerProducerSpec
で使用
KafkaClientAuthenticationOAuth
スキーマプロパティーの完全リスト
OAuth クライアント認証を設定するには、type
プロパティーを oauth
に設定します。
OAuth 認証は、以下のオプションのいずれかを使用して設定できます。
- クライアント ID およびシークレット
- クライアント ID および更新トークン
- アクセストークン
- TLS
クライアント ID およびシークレット
認証で使用されるクライアント ID およびクライアントシークレットとともに、tokenEndpointUri
プロパティーで承認サーバーのアドレスを設定できます。OAuth クライアントは OAuth サーバーに接続し、クライアント ID およびシークレットを使用して認証し、Kafka ブローカーとの認証に使用するアクセストークンを取得します。clientSecret
プロパティーで、クライアントシークレットが含まれる Secret
へのリンクを指定します。
クライアント ID およびクライアントシークレットを使用した OAuth クライアント認証の例
authentication: type: oauth tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token clientId: my-client-id clientSecret: secretName: my-client-oauth-secret key: client-secret
クライアント ID および更新トークン
OAuth クライアント ID および更新トークンとともに、tokenEndpointUri
プロパティーで OAuth サーバーのアドレスを設定できます。OAuth クライアントは OAuth サーバーに接続し、クライアント ID と更新トークンを使用して認証し、Kafka ブローカーとの認証に使用するアクセストークンを取得します。refreshToken
プロパティーで、更新トークンが含まれる Secret
へのリンクを指定します。
クライアント ID と更新トークンを使用した OAuth クライアント認証の例
authentication: type: oauth tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token clientId: my-client-id refreshToken: secretName: my-refresh-token-secret key: refresh-token
アクセストークン
Kafka ブローカーとの認証に使用されるアクセストークンを直接設定できます。この場合、tokenEndpointUri
は指定しません。accessToken
プロパティーで、アクセストークンが含まれる Secret
へのリンクを指定します。
アクセストークンのみを使用した OAuth クライアント認証の例
authentication: type: oauth accessToken: secretName: my-access-token-secret key: access-token
TLS
HTTPS プロトコルを使用して OAuth サーバーにアクセスする場合、信頼される認証局によって署名された証明書を使用し、そのホスト名が証明書に記載されている限り、追加の設定は必要ありません。
OAuth サーバーが自己署名証明書を使用している場合、または信頼されていない認証局によって署名されている場合は、カスタムリソースで信頼済み証明書の一覧を設定できます。tlsTrustedCertificates
プロパティーには、保存される証明書のキー名があるシークレットのリストが含まれます。証明書は X509 形式で保存する必要があります。
提供される TLS 証明書の例
authentication: type: oauth tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token clientId: my-client-id refreshToken: secretName: my-refresh-token-secret key: refresh-token tlsTrustedCertificates: - secretName: oauth-server-ca certificate: tls.crt
OAuth クライアントはデフォルトで、OAuth サーバーのホスト名が、証明書サブジェクトまたは別の DNS 名のいずれかと一致することを確認します。必要でない場合は、ホスト名の検証を無効にできます。
無効にされた TLS ホスト名の検証例
authentication: type: oauth tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token clientId: my-client-id refreshToken: secretName: my-refresh-token-secret key: refresh-token disableTlsHostnameVerification: true
13.2.87.1. KafkaClientAuthenticationOAuth
スキーマプロパティー
type
プロパティーは、KafkaClientAuthenticationOAuth
タイプの使用を KafkaClientAuthenticationTls
、KafkaClientAuthenticationScramSha512
、および KafkaClientAuthenticationPlain
と区別する識別子です。KafkaClientAuthenticationOAuth
タイプには oauth
の値が必要です。
プロパティー | 説明 |
---|---|
accessToken | 承認サーバーから取得したアクセストークンが含まれる OpenShift シークレットへのリンク。 |
accessTokenIsJwt |
アクセストークンを JWT として処理すべきかどうかを設定します。承認サーバーが不透明なトークンを返す場合は |
boolean | |
clientId | Kafka クライアントが OAuth サーバーに対する認証に使用し、トークンエンドポイント URI を使用することができる OAuth クライアント ID。 |
string | |
clientSecret | Kafka クライアントが OAuth サーバーに対する認証に使用し、トークンエンドポイント URI を使用することができる OAuth クライアントシークレットが含まれる OpenShift シークレットへのリンク。 |
disableTlsHostnameVerification |
TLS ホスト名の検証を有効または無効にします。デフォルト値は |
boolean | |
maxTokenExpirySeconds | アクセストークンの有効期間を指定の秒数に設定または制限します。これは、承認サーバーが不透明なトークンを返す場合に設定する必要があります。 |
integer | |
refreshToken | 承認サーバーからアクセストークンを取得するために使用できる更新トークンが含まれる OpenShift シークレットへのリンク。 |
scope |
承認サーバーに対して認証を行うときに使用する OAuth スコープ。一部の承認サーバーでこれを設定する必要があります。許可される値は、承認サーバーの設定によります。デフォルトでは、トークンエンドポイントリクエストを実行する場合は |
string | |
tlsTrustedCertificates | OAuth サーバーへの TLS 接続の信頼済み証明書。 |
| |
tokenEndpointUri | 承認サーバートークンエンドポイント URI。 |
string | |
type |
|
string |
13.2.88. JaegerTracing
スキーマ参照
KafkaBridgeSpec
、KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
、KafkaMirrorMakerSpec
で使用
type
プロパティーは、JaegerTracing
タイプの使用を、今後追加される可能性のある他のサブタイプと区別する識別子です。JaegerTracing
タイプには jaeger
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.89. KafkaConnectTemplate
スキーマ参照
KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
で使用
プロパティー | 説明 |
---|---|
deployment |
Kafka Connect |
pod |
Kafka Connect |
apiService |
Kafka Connect API |
buildConfig | 新しいコンテナーイメージをビルドするために使用される Kafka Connect BuildConfig のテンプレート。BuildConfig は OpenShift でのみ使用されます。 |
buildContainer | Kafka Connect Build コンテナーのテンプレート。build コンテナーは OpenShift でのみ使用されます。 |
buildPod |
Kafka Connect Build |
clusterRoleBinding | Kafka Connect ClusterRoleBinding のテンプレート。 |
connectContainer | Kafka Connect コンテナーのテンプレート。 |
initContainer | Kafka init コンテナーのテンプレート。 |
podDisruptionBudget |
Kafka Connect |
13.2.90. DeploymentTemplate
スキーマ参照
KafkaBridgeTemplate
、KafkaConnectTemplate
、KafkaMirrorMakerTemplate
で使用
プロパティー | 説明 |
---|---|
metadata | リソースに適用済みのメタデータ。 |
deploymentStrategy |
このデプロイメントに使用される DeploymentStrategy。有効な値は |
string ([RollingUpdate、Recreate] のいずれか) |
13.2.91. ExternalConfiguration
スキーマ参照
KafkaConnectS2ISpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
で使用
ExternalConfiguration
スキーマプロパティーの完全リスト
Kafka Connect コネクターの設定オプションを定義する外部ストレージプロパティーを設定します。
ConfigMap またはシークレットを環境変数またはボリュームとして Kafka Connect Pod にマウントできます。ボリュームおよび環境変数は、KafkaConnect.spec
および KafkaConnectS2I.spec
の externalConfiguration
プロパティーで設定されます。
これが適用されると、コネクターの開発時に環境変数とボリュームを使用できます。
13.2.91.1. env
env
プロパティーは、1 つ以上の環境変数を指定するために使用されます。これらの変数には ConfigMap または Secret からの値を含めることができます。
環境変数の値が含まれるシークレットの例
apiVersion: v1 kind: Secret metadata: name: aws-creds type: Opaque data: awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg= awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=
ユーザー定義の環境変数に、KAFKA_
または STRIMZI_
で始まる名前を付けることはできません。
Secret から環境変数に値をマウントするには、valueFrom
プロパティーおよび secretKeyRef
を使用します。
Secret からの値に設定された環境変数の例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... externalConfiguration: env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: aws-creds key: awsAccessKey - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: aws-creds key: awsSecretAccessKey
シークレットを環境変数にマウントする一般的なユースケースとして、コネクターが Amazon AWS と通信する必要があり、クレデンシャルで AWS_ACCESS_KEY_ID
および AWS_SECRET_ACCESS_KEY
環境変数を読み取る必要がある場合が挙げられます。
ConfigMap から環境変数に値をマウントするには、以下の例のように valueFrom
プロパティーで configMapKeyRef
を使用します。
ConfigMap からの値に設定された環境変数の例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... externalConfiguration: env: - name: MY_ENVIRONMENT_VARIABLE valueFrom: configMapKeyRef: name: my-config-map key: my-key
13.2.91.2. volumes
ConfigMap またはシークレットをボリュームとして Kafka Connect Pod にマウントすることもできます。
以下の場合、環境変数の代わりにボリュームを使用すると便利です。
- TLS 証明書でのトラストストアまたはキーストアのマウント
- Kafka Connect コネクターの設定に使用されるプロパティーファイルのマウント
プロパティーのある Secret の例
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque stringData: connector.properties: |- 1 dbUsername: my-user 2 dbPassword: my-password
この例では、mysecret
という名前の Secret が connector-config
という名前のボリュームにマウントされます。config
プロパティーでは、外部ソースから設定値を読み込む設定プロバイダー (FileConfigProvider
) が指定されます。Kafka FileConfigProvider
にはエイリアス file
が指定され、コネクター設定で使用するファイルからデータベースの ユーザー名 プロパティーおよび パスワード プロパティーの値を読み取りおよび展開します。
Secret からの値に設定された外部ボリュームの例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... config: config.providers: file 1 config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider 2 #... externalConfiguration: volumes: - name: connector-config 3 secret: secretName: mysecret 4
- 1
- 他の設定パラメーターを定義するために使用される設定プロバイダーのエイリアス。複数のプロバイダーを追加する場合は、コンマ区切りリストを使用します。
- 2
FileConfigProvider
は、プロパティーファイルから値を提供する設定プロバイダーです。パラメーターはconfig.providers
からエイリアスを使用し、config.providers.${alias}.class
という形式を取ります。- 3
- Secret が含まれるボリュームの名前。各ボリュームは
name
プロパティーに名前を指定し、ConfigMap またはシークレットを参照する必要があります。 - 4
- Secret の名前。
ボリュームは、パス /opt/kafka/external-configuration/<volume-name>
の Kafka Connect コンテナーの内部にマウントされます。たとえば、connector-config
いう名前のボリュームからのファイルは /opt/kafka/external-configuration/connector-config
ディレクトリーにあります。
FileConfigProvider
を使用して、コネクター設定でマウントされたプロパティーファイルから値を読み取ります。
13.2.91.3. ExternalConfiguration
スキーマプロパティー
プロパティー | 説明 |
---|---|
env | Secret または ConfigMap からのデータを環境変数として Kafka Connect Pod に渡すことを許可します。 |
| |
volumes | Secret または ConfigMap からのデータをボリュームとして Kafka Connect Pod に渡すことを許可します。 |
13.2.92. ExternalConfigurationEnv
スキーマ参照
プロパティー | 説明 |
---|---|
name |
Kafka Connect Pod に渡される環境変数の名前。環境変数に、 |
string | |
valueFrom | Kafka Connect Pod に渡される環境変数の値。Secret または ConfigMap フィールドのいずれかへ参照として渡すことができます。このフィールドでは、Secret または ConfigMap を 1 つだけ指定する必要があります。 |
13.2.93. ExternalConfigurationEnvVarSource
スキーマ参照
プロパティー | 説明 |
---|---|
configMapKeyRef | ConfigMap のキーへの参照。詳細は、core/v1 configmapkeyselector の外部ドキュメントを参照してください。 |
secretKeyRef | Secret のキーへの参照。詳細は、core/v1 secretkeyselector の外部ドキュメント を参照してください。 |
13.2.94. ExternalConfigurationVolumeSource
スキーマ参照
プロパティー | 説明 |
---|---|
configMap | ConfigMap のキーへの参照。Secret または ConfigMap を 1 つだけ指定する必要があります。詳細は、core/v1 configmapvolumesource の外部ドキュメント を参照してください。 |
name | Kafka Connect Pod に追加されるボリュームの名前。 |
string | |
secret | Secret のキーへの参照。Secret または ConfigMap を 1 つだけ指定する必要があります。詳細は、core/v1 secretvolumesource の外部ドキュメント を参照してください。 |
13.2.95. Build
スキーマ参照
KafkaConnectS2ISpec
、KafkaConnectSpec
で使用
Kafka Connect デプロイメントの追加コネクターを設定します。
13.2.95.1. output
追加のコネクタープラグインで新しいコンテナーイメージをビルドするには、イメージをプッシュ、保存、およびプルできるコンテナーレジストリーが AMQ Streams に必要です。AMQ Streams は独自のコンテナーレジストリーを実行しないため、レジストリーを指定する必要があります。AMQ Streams は、プライベートコンテナーレジストリーだけでなく、Quay や Docker Hub などのパブリックレジストリーもサポートします。コンテナーレジストリーは、KafkaConnect
カスタムリソースの .spec.build.output
セクションで設定されます。output
設定は必須で、docker
と imagestream
の 2 つのタイプをサポートします。
Docker レジストリーの使用
Docker レジストリーを使用するには、type
を docker
として指定し、image
フィールドに新しいコンテナーイメージのフルネームを指定する必要があります。フルネームには以下が含まれる必要があります。
- レジストリーのアドレス
- ポート番号 (標準以外のポートでリッスンしている場合)
- 新しいコンテナーイメージのタグ
有効なコンテナーイメージ名の例:
-
docker.io/my-org/my-image/my-tag
-
quay.io/my-org/my-image/my-tag
-
image-registry.image-registry.svc:5000/myproject/kafka-connect-build:latest
Kafka Connect デプロイメントごとに個別のイメージを使用する必要があります。これは、最も基本的なレベルで異なるタグを使用する可能性があることを意味します。
レジストリーに認証が必要な場合は、pushSecret
を使用してレジストリーのクレデンシャルで Secret の名前を設定します。Secret には、kubernetes.io/dockerconfigjson
タイプと .dockerconfigjson
ファイルを使用して Docker クレデンシャルを格納します。プライベートレジストリーからイメージをプルする方法の詳細は、「Create a Secret based on existing Docker credentials」を参照してください。
output
の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster spec: #... build: output: type: docker 1 image: my-registry.io/my-org/my-connect-cluster:latest 2 pushSecret: my-registry-credentials 3 #...
OpenShift ImageStream の使用
Docker の代わりに OpenShift ImageStream を使用して、新しいコンテナーイメージを保存できます。Kafka Connect をデプロイする前に、ImageStream を手動で作成する必要があります。ImageStream を使用するには、type
を imagestream
に設定し、image
プロパティーを使用して ImageStream と使用するタグの名前を指定します。例: my-connect-image-stream:latest
output
の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster spec: #... build: output: type: imagestream 1 image: my-connect-build:latest 2 #...
13.2.95.2. plugins
コネクタープラグインは、特定タイプの外部システムへの接続に必要な実装を定義するファイルのセットです。コンテナーイメージに必要なコネクタープラグインは、KafkaConnect
カスタムリソースの .spec.build.plugins
プロパティーを使用して設定する必要があります。各コネクタープラグインには、Kafka Connect デプロイメント内で一意となる名前が必要です。さらに、プラグインアーティファクトもリストする必要があります。これらのアーティファクトは AMQ Streams によってダウンロードされ、新しいコンテナーイメージに追加され、Kafka Connect デプロイメントで使用されます。コネクタープラグインアーティファクトには、シリアライザーやデシリアライザーなどの追加のコンポーネントを含めることもできます。各コネクタープラグインは、異なるコネクターとそれらの依存関係が適切に サンドボックス化 されるように、個別のディレクトリーにダウンロードされます。各プラグインは、1 つ以上の artifact
で設定する必要があります。
2 つのコネクタープラグインを持つ plugins
の設定例
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
name: my-connect-cluster
spec:
#...
build:
output:
#...
plugins: 1
- name: debezium-postgres-connector
artifacts:
- type: tgz
url: https://repo1.maven.org/maven2/io/debezium/debezium-connector-postgres/1.3.1.Final/debezium-connector-postgres-1.3.1.Final-plugin.tar.gz
sha512sum: 962a12151bdf9a5a30627eebac739955a4fd95a08d373b86bdcea2b4d0c27dd6e1edd5cb548045e115e33a9e69b1b2a352bee24df035a0447cb820077af00c03
- name: camel-telegram
artifacts:
- type: tgz
url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.7.0/camel-telegram-kafka-connector-0.7.0-package.tar.gz
sha512sum: a9b1ac63e3284bea7836d7d24d84208c49cdf5600070e6bd1535de654f6920b74ad950d51733e8020bf4187870699819f54ef5859c7846ee4081507f48873479
#...
- 1
- (必須) コネクタープラグインおよびそれらのアーティファクトの一覧。
AMQ Streams は、ダウンロードされ直接使用される JAR ファイルと、ダウンロードされ展開される TGZ アーカイブの 2種類のアーティファクトをサポートします。
AMQ Streams は、ダウンロードしたアーティファクトのセキュリティースキャンを実行しません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドと Kafka Connect デプロイメントで同じアーティファクトが使用されるようにする必要があります。
JAR アーティファクトの使用
JAR アーティファクトは、コンテナーイメージにダウンロードされ、追加されたリソースを表します。JAR アーティファクトは主に JAR ファイルのダウンロードに使用されますが、他のファイルタイプをダウンロードするために使用することもできます。JAR アーティファクトを使用するには、type
プロパティーを jar
に設定し、url
プロパティーを使用してダウンロードする場所を指定します。
さらに、アーティファクトの SHA-512 チェックサムを指定することもできます。指定された場合、AMQ Streams は新しいコンテナーイメージのビルド中にアーティファクトのチェックサムを検証します。
JAR アーティファクトの例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster spec: #... build: output: #... plugins: - name: my-plugin artifacts: - type: jar 1 url: https://my-domain.tld/my-jar.jar 2 sha512sum: 589...ab4 3 - type: jar url: https://my-domain.tld/my-jar2.jar #...
TGZ アーティファクトの使用
TGZ アーティファクトは、Gzip 圧縮を使用して圧縮された TAR アーカイブをダウンロードするために使用されます。複数の異なるファイルで構成される場合でも、TGZ アーティファクトに Kafka Connect コネクター全体を含めることができます。TGZ アーティファクトは、新しいコンテナーイメージのビルド時に AMQ Streams によって自動的にダウンロードおよび展開されます。TGZ アーティファクトを使用するには、type
プロパティーを tgz
に設定し、url
プロパティーを使用してダウンロードする場所を指定します。
さらに、アーティファクトの SHA-512 チェックサムを指定することもできます。指定された場合、展開して新しいコンテナイメージをビルドする前に、チェックサムが AMQ Streams によって検証されます。
TGZ アーティファクトの例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster spec: #... build: output: #... plugins: - name: my-plugin artifacts: - type: tgz 1 url: https://my-domain.tld/my-connector-archive.jar 2 sha512sum: 158...jg10 3 #...
13.2.95.3. Build
スキーマプロパティー
プロパティー | 説明 |
---|---|
output |
新たにビルドされたイメージの保存先を設定します。必須です。タイプは、指定のオブジェクト内の |
resources | ビルド用に予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
plugins | Kafka Connect に追加する必要のあるコネクタープラグインのリスト。必須です。 |
|
13.2.96. DockerOutput
スキーマ参照
Build
で使用
type
プロパティーは、DockerOutput
タイプの使用を ImageStreamOutput
と区別する識別子です。DockerOutput
タイプには docker
の値が必要です。
プロパティー | 説明 |
---|---|
image |
新たにビルドされたイメージのタグ付けおよびプッシュに使用されるフルネーム。例: |
string | |
pushSecret | 新たにビルドされたイメージをプッシュするための、クレデンシャルが含まれる Container Registry Secret。 |
string | |
additionalKanikoOptions | 新しい Connect イメージをビルドする際に、Kaniko エグゼキューターに渡される追加オプションを設定します。指定できるオプションは --customPlatform、--insecure、--insecure-pull、--insecure-registry、--log-format、--log-timestamp、--registry-mirror、--reproducible、--single-snapshot、--skip-tls-verify、--skip-tls-verify-pull、--skip-tls-verify-registry、--verbosity、--snapshotMode、--use-new-run です。これらのオプションは、Kaniko エグゼキューターが使用される OpenShift でのみ使用されます。OpenShift では無視されます。オプションは、「Kaniko GitHub repository」に記載されています。このフィールドを変更しても、Kafka Connect イメージのビルドは新たにトリガーされません。 |
string array | |
type |
|
string |
13.2.97. ImageStreamOutput
スキーマ参照
Build
で使用
type
プロパティーは、ImageStreamOutput
タイプの使用を DockerOutput
と区別する識別子です。ImageStreamOutput
タイプには imagestream
の値が必要です。
プロパティー | 説明 |
---|---|
image |
新たにビルドされたイメージがプッシュされる ImageStream の名前およびタグ。例: |
string | |
type |
|
string |
13.2.98. Plugin
スキーマ参照
Build
で使用
プロパティー | 説明 |
---|---|
name |
コネクタープラグインの一意名。コネクターアーティファクトが保存されるパスの生成に使用されます。名前は KafkaConnect リソース内で一意である必要があります。この名前は、 |
string | |
artifacts | このコネクタープラグインに属するアーティファクトの一覧。必須です。 |
|
13.2.99. JarArtifact
スキーマ参照
Plugin
で使用
プロパティー | 説明 |
---|---|
url | ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。必須です。 |
string | |
sha512sum | アーティファクトの SHA512 チェックサム。任意設定。指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。 |
string | |
type |
|
string |
13.2.100. TgzArtifact
スキーマ参照
Plugin
で使用
プロパティー | 説明 |
---|---|
url | ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。必須です。 |
string | |
sha512sum | アーティファクトの SHA512 チェックサム。任意設定。指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。 |
string | |
type |
|
string |
13.2.101. ZipArtifact
スキーマ参照
Plugin
で使用
プロパティー | 説明 |
---|---|
url | ダウンロードされるアーティファクトの URL。AMQ Streams では、ダウンロードしたアーティファクトのセキュリティースキャンは行いません。セキュリティー上の理由から、最初にアーティファクトを手動で検証し、チェックサムの検証を設定して、自動ビルドで同じアーティファクトが使用されるようにする必要があります。必須です。 |
string | |
sha512sum | アーティファクトの SHA512 チェックサム。任意設定。指定すると、新しいコンテナーのビルド時にチェックサムが検証されます。指定のない場合は、ダウンロードしたアーティファクトは検証されません。 |
string | |
type |
|
string |
13.2.102. KafkaConnectStatus
スキーマ参照
KafkaConnect
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
url | Kafka Connect コネクターの管理および監視用の REST API エンドポイントの URL。 |
string | |
connectorPlugins | この Kafka Connect デプロイメントで使用できるコネクタープラグインの一覧。 |
| |
labelSelector | このリソースを提供する Pod のラベルセレクター。 |
string | |
replicas | このリソースを提供するために現在使用されている Pod の数。 |
integer |
13.2.103. ConnectorPlugin
スキーマ参照
KafkaConnectS2IStatus
、KafkaConnectStatus
、KafkaMirrorMaker2Status
で使用
プロパティー | 説明 |
---|---|
type |
コネクタープラグインのタイプ。利用可能なタイプは、 |
string | |
version | コネクタープラグインのバージョン。 |
string | |
class | コネクタープラグインのクラス。 |
string |
13.2.104. KafkaConnectS2I
スキーマ参照
KafkaConnectS2I
タイプは非推奨になりました。代わりに Build
を使用してください。
プロパティー | 説明 |
---|---|
spec | Kafka Connect Source-to-Image (S2I) クラスターの仕様。 |
status | Kafka Connect Source-to-Image (S2I) クラスターのステータス。 |
13.2.105. KafkaConnectS2ISpec
スキーマ参照
KafkaConnectS2I
で使用
KafkaConnectS2ISpec
スキーマプロパティーの完全リスト
Source-to-Image (S2I) サポートで Kafka Connect クラスターを設定します。
OpenShift (のみ) のコネクタープラグインで Kafka Connect を拡張する場合、OpenShift ビルドおよび S2I を使用して、Kafka Connect デプロイメントによって使用されるコンテナーイメージを作成できます。
設定オプションは、KafkaConnectSpec
スキーマ を使用した Kafka Connect 設定に似ています。
13.2.105.1. KafkaConnectS2ISpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
version | Kafka Connect のバージョン。デフォルトは 2.7.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。 |
string | |
replicas | Kafka Connect グループの Pod 数。 |
integer | |
image | Pod の Docker イメージ。 |
string | |
buildResources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
bootstrapServers | 接続するブートストラップサーバー。これは <hostname>:<port> ペアのコンマ区切りリストとして指定する必要があります。 |
string | |
tls | TLS 設定。 |
authentication |
Kafka Connect の認証設定。タイプは、指定のオブジェクト内の |
| |
config | Kafka Connect の設定。次の接頭辞を持つプロパティーは設定できません: ssl.、sasl.、security.、listeners、plugin.path、rest.、bootstrap.servers、consumer.interceptor.classes、producer.interceptor.classes (ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols を除く) |
map | |
resources | CPU とメモリーリソースおよび要求された初期リソースの上限。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
jvmOptions | Pod の JVM オプション。 |
jmxOptions | JMX オプション。 |
affinity |
|
tolerations |
|
Toleration array | |
logging |
Kafka Connect のロギング設定。タイプは、指定のオブジェクト内の |
metrics |
|
map | |
tracing |
Kafka Connect でのトレーシングの設定。タイプは、指定のオブジェクト内の |
template |
Kafka Connect および Kafka Connect S2I リソースのテンプレート。テンプレートを使用すると、ユーザーは |
externalConfiguration | Secret または ConfigMap から Kafka Connect Pod にデータを渡し、これを使用してコネクターを設定します。 |
build | Connect コンテナーイメージを構築する方法を設定します。任意設定。 |
clientRackInitImage |
|
string | |
insecureSourceRepository | true の場合、'Local' 参照ポリシーとセキュアでないソースタグを受け入れるインポートポリシーを使用してソースリポジトリーを設定します。 |
boolean | |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
rack | client.rack コンシューマー設定として使用されるノードラベルの設定。 |
13.2.106. KafkaConnectS2IStatus
スキーマ参照
KafkaConnectS2I
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
url | Kafka Connect コネクターの管理および監視用の REST API エンドポイントの URL。 |
string | |
connectorPlugins | この Kafka Connect デプロイメントで使用できるコネクタープラグインの一覧。 |
| |
buildConfigName | ビルド設定の名前。 |
string | |
labelSelector | このリソースを提供する Pod のラベルセレクター。 |
string | |
replicas | このリソースを提供するために現在使用されている Pod の数。 |
integer |
13.2.107. KafkaTopic
スキーマ参照
プロパティー | 説明 |
---|---|
spec | トピックの仕様。 |
status | トピックのステータス。 |
13.2.108. KafkaTopicSpec
スキーマ参照
KafkaTopic
で使用
プロパティー | 説明 |
---|---|
partitions | トピックに存在するパーティション数。この数はトピック作成後に減らすことはできません。トピック作成後に増やすことはできますが、その影響について理解することが重要となります。特にセマンティックパーティションのあるトピックで重要となります。 |
integer | |
replicas | トピックのレプリカ数。 |
integer | |
config | トピックの設定。 |
map | |
topicName | トピックの名前。これがない場合、デフォルトではトピックの metadata.name に設定されます。トピック名が有効な OpenShift リソース名ではない場合を除き、これを設定しないことが推奨されます。 |
string |
13.2.109. KafkaTopicStatus
スキーマ参照
KafkaTopic
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer |
13.2.110. KafkaUser
スキーマ参照
プロパティー | 説明 |
---|---|
spec | ユーザーの仕様。 |
status | Kafka User のステータス。 |
13.2.111. KafkaUserSpec
スキーマ参照
KafkaUser
で使用
プロパティー | 説明 |
---|---|
authentication |
この Kafka ユーザーに対して有効になっている認証メカニズム。タイプは、指定のオブジェクト内の |
| |
authorization |
この Kafka ユーザーの承認ルール。タイプは、指定のオブジェクト内の |
quotas | クライアントによって使用されるブローカーリソースを制御する要求のクォータ。ネットワーク帯域幅および要求レートクォータの適用が可能です。Kafka ユーザークォータの Kafka ドキュメントは http://kafka.apache.org/documentation/#design_quotas を参照してください。 |
template |
Kafka User |
13.2.112. KafkaUserTlsClientAuthentication
スキーマ参照
KafkaUserSpec
で使用
type
プロパティーは、KafkaUserTlsClientAuthentication
タイプの使用を KafkaUserScramSha512ClientAuthentication
と区別する識別子です。KafkaUserTlsClientAuthentication
タイプには tls
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.113. KafkaUserScramSha512ClientAuthentication
スキーマ参照
KafkaUserSpec
で使用
type
プロパティーは、KafkaUserScramSha512ClientAuthentication
タイプの使用を KafkaUserTlsClientAuthentication
と区別する識別子です。KafkaUserScramSha512ClientAuthentication
タイプには scram-sha-512
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.114. KafkaUserAuthorizationSimple
スキーマ参照
KafkaUserSpec
で使用
type
プロパティーは、KafkaUserAuthorizationSimple
タイプの使用を、今後追加される可能性のある他のサブタイプと区別する識別子です。KafkaUserAuthorizationSimple
タイプには simple
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
ACL | このユーザーに適用される必要のある ACL ルールの一覧。 |
|
13.2.115. AclRule
スキーマ参照
KafkaUserAuthorizationSimple
で使用
ブローカーが AclAuthorizer
を使用する場合に KafkaUser
のアクセス制御ルールを設定します。
承認を使用した KafkaUser
の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: # ... authorization: type: simple acls: - resource: type: topic name: my-topic patternType: literal operation: Read - resource: type: topic name: my-topic patternType: literal operation: Describe - resource: type: group name: my-group patternType: prefix operation: Read
13.2.115.1. resource
resource
プロパティーを使用して、ルールが適用されるリソースを指定します。
簡易承認は、type
プロパティーに指定される、以下の 4 つのリソースタイプをサポートします。
-
トピック (
topic
) -
コンシューマーグループ (
group
) -
クラスター (
cluster
) -
トランザクション ID (
transactionalId
)
Topic、Group、および Transactional ID リソースでは、name
プロパティーでルールが適用されるリソースの名前を指定できます。
クラスタータイプのリソースには名前がありません。
名前は、patternType
プロパティーを使用して literal
または prefix
として指定されます。
-
リテラル (literal) 名には、
name
フィールドに指定された名前がそのまま使われます。 -
接頭辞 (prefix) 名には、
name
からの値が接頭辞として使用され、その値で始まる名前を持つすべてのリソースにルールが適用されます。
13.2.115.2. type
ルールの type
。allow
(操作の許可) または deny
(操作の拒否、現在未サポート) です。
type
フィールドの設定は任意です。type
の指定がない場合、ACL ルールは allow
ルールとして処理されます。
13.2.115.3. operation
ルールが許可または拒否する operation
を指定します。
以下の操作がサポートされます。
- Read
- Write
- Delete
- Alter
- Describe
- All
- IdempotentWrite
- ClusterAction
- Create
- AlterConfigs
- DescribeConfigs
特定の操作のみが各リソースで機能します。
AclAuthorizer
、ACL、およびサポートされるリソースと操作の組み合わせの詳細は、「Authorization and ACL」 を参照してください。
13.2.115.4. host
host
プロパティーを使用して、ルールが許可または拒否されるリモートホストを指定します。
アスタリスク (*
) を使用して、すべてのホストからの操作を許可または拒否します。host
フィールドの設定は任意です。host
を指定しないと、値 *
がデフォルトで使用されます。
13.2.115.5. AclRule
スキーマプロパティー
プロパティー | 説明 |
---|---|
host | ACL ルールに記述されているアクションを許可または拒否するホスト。 |
string | |
operation | 許可または拒否される操作。サポートされる操作: Read、Write、Create、Delete、Alter、Describe、ClusterAction、AlterConfigs、DescribeConfigs、IdempotentWrite、All |
string ([Read、Write、Delete、Alter、Describe、All、IdempotentWrite、ClusterAction、Create、AlterConfigs、DescribeConfigs] のいずれか) | |
resource |
指定の ACL ルールが適用されるリソースを示します。タイプは、指定のオブジェクト内の |
| |
type |
ルールのタイプ。現在サポートされているタイプは |
string ([allow、deny] のいずれか) |
13.2.116. AclRuleTopicResource
スキーマ参照
AclRule
で使用
type
プロパティーは、AclRuleTopicResource
タイプの使用を AclRuleGroupResource
、AclRuleClusterResource
、および AclRuleTransactionalIdResource
と区別する識別子です。AclRuleTopicResource
タイプには topic
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
name |
指定の ACL ルールが適用されるリソースの名前。 |
string | |
patternType |
リソースフィールドで使用されるパターンを指定します。サポートされるタイプは |
string ([prefix、literal] のいずれか) |
13.2.117. AclRuleGroupResource
スキーマ参照
AclRule
で使用
type
プロパティーは、AclRuleGroupResource
タイプの使用を AclRuleTopicResource
、AclRuleClusterResource
、および AclRuleTransactionalIdResource
と区別する識別子です。AclRuleGroupResource
タイプには group
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
name |
指定の ACL ルールが適用されるリソースの名前。 |
string | |
patternType |
リソースフィールドで使用されるパターンを指定します。サポートされるタイプは |
string ([prefix、literal] のいずれか) |
13.2.118. AclRuleClusterResource
スキーマ参照
AclRule
で使用
type
プロパティーは、AclRuleClusterResource
タイプの使用を AclRuleTopicResource
、AclRuleGroupResource
、および AclRuleTransactionalIdResource
と区別する識別子です。AclRuleClusterResource
タイプには cluster
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string |
13.2.119. AclRuleTransactionalIdResource
スキーマ参照
AclRule
で使用
type
プロパティーは、AclRuleTransactionalIdResource
タイプの使用を AclRuleTopicResource
、AclRuleGroupResource
、および AclRuleClusterResource
と区別する識別子です。AclRuleTransactionalIdResource
タイプには transactionalId
の値が必要です。
プロパティー | 説明 |
---|---|
type |
|
string | |
name |
指定の ACL ルールが適用されるリソースの名前。 |
string | |
patternType |
リソースフィールドで使用されるパターンを指定します。サポートされるタイプは |
string ([prefix、literal] のいずれか) |
13.2.120. KafkaUserQuotas
スキーマ参照
KafkaUserSpec
で使用
KafkaUserQuotas
スキーマプロパティーの完全リスト
Kafka では、ユーザーは quotas
を設定してクライアントによるリソースの使用を制御できます。
13.2.120.1. quotas
クォータは、2 つのカテゴリーに分類されます。
- ネットワーク使用率 クォータ。これは、クォータを共有するクライアントの各グループのバイトレートしきい値として定義されます。
- CPU 使用率 クォータ。これは、クライアントがクォータウィンドウ内の各ブローカーのリクエストハンドラー I/O スレッドおよびネットワークスレッドで使用可能な時間の割合として定義されます。
Kafka クライアントにクォータを使用することは、さまざまな状況で役に立つ場合があります。レートが高すぎる要求を送信する Kafka プロデューサーを誤って設定したとします。このように設定が間違っていると、他のクライアントにサービス拒否を引き起こす可能性があるため、問題のあるクライアントはブロックする必要があります。ネットワーク制限クォータを使用すると、他のクライアントがこの状況の著しい影響を受けないようにすることが可能です。
AMQ Streams はユーザーレベルのクォータをサポートしますが、クライアントレベルのクォータはサポートしません。
Kafka ユーザークォータの例
spec: quotas: producerByteRate: 1048576 consumerByteRate: 2097152 requestPercentage: 55
Kafka ユーザークォータの詳細は Apache Kafka ドキュメント を参照してください。
13.2.120.2. KafkaUserQuotas
スキーマプロパティー
プロパティー | 説明 |
---|---|
consumerByteRate | グループのクライアントにスロットリングが適用される前に、各クライアントグループがブローカーから取得できる最大 bps (ビット毎秒) のクオータ。ブローカーごとに定義されます。 |
integer | |
producerByteRate | グループのクライアントにスロットリングが適用される前に、各クライアントグループがブローカーにパブリッシュできる最大 bps (ビット毎秒) のクオータ。ブローカーごとに定義されます。 |
integer | |
requestPercentage | 各クライアントグループの最大 CPU 使用率のクォータ。ネットワークと I/O スレッドの比率 (パーセント) として指定。 |
integer |
13.2.121. KafkaUserTemplate
スキーマ参照
KafkaUserSpec
で使用
KafkaUserTemplate
スキーマプロパティーの完全リスト
User Operator によって作成されるシークレットの追加ラベルおよびアノテーションを指定します。
KafkaUserTemplate
を示す例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: tls template: secret: metadata: labels: label1: value1 annotations: anno1: value1 # ...
13.2.121.1. KafkaUserTemplate
スキーマプロパティー
プロパティー | 説明 |
---|---|
secret |
KafkaUser リソースのテンプレート。テンプレートを使用すると、ユーザーはパスワードまたは TLS 証明書のある |
13.2.122. KafkaUserStatus
スキーマ参照
KafkaUser
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
username | ユーザー名。 |
string | |
secret |
認証情報が保存される |
string |
13.2.123. KafkaMirrorMaker
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka MirrorMaker の仕様。 |
status | Kafka MirrorMaker のステータス。 |
13.2.124. KafkaMirrorMakerSpec
スキーマ参照
KafkaMirrorMaker
で使用
KafkaMirrorMakerSpec
スキーマプロパティーの完全リスト
Kafka MirrorMaker を設定します。
13.2.124.1. whitelist
whitelist
プロパティーを使用して、Kafka MirrorMaker がソースからターゲット Kafka クラスターにミラーリングするトピックのリストを設定します。
このプロパティーでは、簡単な単一のトピック名から複雑なパターンまですべての正規表現が許可されます。たとえば、「A|B」を使用してトピック A と B をミラーリングでき、「*」を使用してすべてのトピックをミラーリングできます。また、複数の正規表現をコンマで区切って Kafka MirrorMaker に渡すこともできます。
13.2.124.2. KafkaMirrorMakerConsumerSpec
および KafkaMirrorMakerProducerSpec
KafkaMirrorMakerConsumerSpec
および KafkaMirrorMakerProducerSpec
を使用して、ソース (コンシューマー) およびターゲット (プロデューサー) クラスターを設定します。
Kafka MirrorMaker は常に 2 つの Kafka クラスター (ソースおよびターゲット) と連携します。接続を確立するため、ソースおよびターゲット Kafka クラスターのブートストラップサーバーは HOSTNAME:PORT
ペアのコンマ区切りリストとして指定されます。それぞれのコンマ区切りリストには、HOSTNAME:PORT
ペアとして指定された 1 つ以上の Kafka ブローカーまたは Kafka ブローカーを示す 1 つの Service
が含まれます。
13.2.124.3. logging
Kafka MirrorMaker には、独自の設定可能なロガーがあります。
-
mirrormaker.root.logger
MirrorMaker では Apache log4j
ロガー実装が使用されます。
logging
プロパティーを使用してロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties
を使用して記述されます。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker spec: # ... logging: type: inline loggers: mirrormaker.root.logger: "INFO" # ...
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker spec: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: mirror-maker-log4j.properties # ...
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.124.4. KafkaMirrorMakerSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
version | Kafka MirrorMaker のバージョン。デフォルトは 2.7.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ドキュメントを参照してください。 |
string | |
replicas |
|
integer | |
image | Pod の Docker イメージ。 |
string | |
consumer | ソースクラスターの設定。 |
producer | ターゲットクラスターの設定。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
whitelist |
ミラーリングに含まれるトピックの一覧。このオプションは、Java スタイルの正規表現を使用するあらゆる正規表現を許可します。 |
string | |
affinity |
|
tolerations |
|
Toleration array | |
jvmOptions | Pod の JVM オプション。 |
logging |
MirrorMaker のロギング設定。タイプは、指定のオブジェクト内の |
metrics |
|
map | |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
tracing |
Kafka MirrorMaker でのトレーシングの設定。タイプは、指定のオブジェクト内の |
template |
Kafka MirrorMaker のリソースである |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
13.2.125. KafkaMirrorMakerConsumerSpec
スキーマ参照
KafkaMirrorMakerConsumerSpec
スキーマプロパティーの完全リスト
MirrorMaker コンシューマーを設定します。
13.2.125.1. numStreams
consumer.numStreams
プロパティーを使用して、コンシューマーのストリームの数を設定します。
コンシューマースレッドの数を増やすと、ミラーリングトピックのスループットを増やすことができます。コンシューマースレッドは、Kafka MirrorMaker に指定されたコンシューマーグループに属します。トピックパーティションはコンシューマースレッド全体に割り当てられ、メッセージが並行して消費されます。
13.2.125.2. offsetCommitInterval
consumer.offsetCommitInterval
プロパティーを使用して、コンシューマーのオフセット自動コミット間隔を設定します。
Kafka MirrorMaker によってソース Kafka クラスターのデータが消費された後に、オフセットがコミットされる通常の間隔を指定できます。間隔はミリ秒単位で設定され、デフォルト値は 60,000 です。
13.2.125.3. config
consumer.config
プロパティーを使用して、コンシューマーの Kafka オプションを設定します。
config
プロパティーには、Kafka MirrorMaker コンシューマー設定オプションが鍵として含まれ、値は以下の JSON タイプのいずれかに設定されます。
- 文字列
- 数値
- ブール値
TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。また、ssl.endpoint.identification.algorithm
プロパティーを設定して、 ホスト名の検証を有効または無効にすることもできます。
例外
コンシューマー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。
しかし、以下に関連する AMQ Streams によって自動的に設定され、直接管理されるオプションには例外があります。
- Kafka クラスターブートストラップアドレス
- セキュリティー (暗号化、認証、および承認)
- コンシューマーグループ識別子
- インターセプター
以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。
-
bootstrap.servers
-
group.id
-
interceptor.classes
-
ssl.
(特定の例外は除外) -
sasl.
-
security.
禁止されているオプションが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka MirrorMaker に渡されます。
Cluster Operator では、提供された config
オブジェクトのキーまたは値は検証されません。無効な設定が指定されると、Kafka MirrorMaker が起動しなかったり、不安定になったりする場合があります。このような場合、KafkaMirrorMaker.spec.consumer.config
オブジェクトの設定を修正し、Cluster Operator によって Kafka MirrorMaker の新しい設定がロールアウトされるようにします。
13.2.125.4. groupId
consumer.groupId
プロパティーを使用して、コンシューマーにコンシューマーグループ ID を設定します。
Kafka MirrorMaker は Kafka コンシューマーを使用してメッセージを消費し、他の Kafka コンシューマークライアントと同様に動作します。ソース Kafka クラスターから消費されるメッセージは、ターゲット Kafka クラスターにミラーリングされます。パーティションの割り当てには、コンシューマーがコンシューマーグループの一部である必要があるため、グループ ID が必要です。
13.2.125.5. KafkaMirrorMakerConsumerSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
numStreams | 作成するコンシューマーストリームスレッドの数を指定します。 |
integer | |
offsetCommitInterval | オフセットの自動コミット間隔をミリ秒単位で指定します。デフォルト値は 60000 です。 |
integer | |
bootstrapServers | Kafka クラスターへの最初の接続を確立するための host:port ペアの一覧。 |
string | |
groupId | このコンシューマーが属するコンシューマーグループを識別する一意の文字列。 |
string | |
authentication |
クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の |
| |
config | MirrorMaker コンシューマーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、group.id、sasl.、security.、interceptor.classes (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols). |
map | |
tls | MirrorMaker をクラスターに接続するための TLS 設定。 |
13.2.126. KafkaMirrorMakerTls
スキーマ参照
KafkaMirrorMakerConsumerSpec
、KafkaMirrorMakerProducerSpec
で使用
KafkaMirrorMakerTls
スキーマプロパティーの完全リスト
MirrorMaker をクラスターに接続するため、TLS によって信頼される証明書を設定します。
13.2.126.1. trustedCertificates
trustedCertificates
プロパティー を使用してシークレットのリストを提供します。
13.2.126.2. KafkaMirrorMakerTls
スキーマプロパティー
プロパティー | 説明 |
---|---|
trustedCertificates | TLS 接続の信頼済み証明書。 |
|
13.2.127. KafkaMirrorMakerProducerSpec
スキーマ参照
KafkaMirrorMakerProducerSpec
スキーマプロパティーの完全リスト
MirrorMaker プロデューサーを設定します。
13.2.127.1. abortOnSendFailure
producer.abortOnSendFailure
プロパティーを使用して、プロデューサーからメッセージ送信の失敗を処理する方法を設定します。
デフォルトでは、メッセージを Kafka MirrorMaker から Kafka クラスターに送信する際にエラーが発生した場合、以下が行われます。
- Kafka MirrorMaker コンテナーが OpenShift で終了します。
- その後、コンテナーが再作成されます。
abortOnSendFailure
オプションを false
に設定した場合、メッセージ送信エラーは無視されます。
13.2.127.2. config
producer.config
プロパティーを使用して、プロデューサーの Kafka オプションを設定します。
config
プロパティーには、Kafka MirrorMaker プロデューサー設定オプションが鍵として含まれ、値は以下の JSON タイプのいずれかに設定されます。
- 文字列
- 数値
- ブール値
TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。また、ssl.endpoint.identification.algorithm
プロパティーを設定して、 ホスト名の検証を有効または無効にすることもできます。
例外
プロデューサー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。
しかし、以下に関連する AMQ Streams によって自動的に設定され、直接管理されるオプションには例外があります。
- Kafka クラスターブートストラップアドレス
- セキュリティー (暗号化、認証、および承認)
- インターセプター
以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。
-
bootstrap.servers
-
interceptor.classes
-
ssl.
(特定の例外は除外) -
sasl.
-
security.
禁止されているオプションが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka MirrorMaker に渡されます。
Cluster Operator では、提供された config
オブジェクトのキーまたは値は検証されません。無効な設定が指定されると、Kafka MirrorMaker が起動しなかったり、不安定になったりする場合があります。このような場合、KafkaMirrorMaker.spec.producer.config
オブジェクトの設定を修正し、Cluster Operator によって Kafka MirrorMaker の新しい設定がロールアウトされるようにします。
13.2.127.3. KafkaMirrorMakerProducerSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
bootstrapServers | Kafka クラスターへの最初の接続を確立するための host:port ペアの一覧。 |
string | |
abortOnSendFailure |
送信失敗時に MirrorMaker が終了するように設定するフラグ。デフォルト値は |
boolean | |
authentication |
クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の |
| |
config | MirrorMaker プロデューサーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、sasl.、security.、interceptor.classes (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols). |
map | |
tls | MirrorMaker をクラスターに接続するための TLS 設定。 |
13.2.128. KafkaMirrorMakerTemplate
スキーマ参照
プロパティー | 説明 |
---|---|
deployment |
Kafka MirrorMaker |
pod |
Kafka MirrorMaker |
mirrorMakerContainer | Kafka MirrorMaker コンテナーのテンプレート。 |
podDisruptionBudget |
Kafka MirrorMaker |
13.2.129. KafkaMirrorMakerStatus
スキーマ参照
KafkaMirrorMaker
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
labelSelector | このリソースを提供する Pod のラベルセレクター。 |
string | |
replicas | このリソースを提供するために現在使用されている Pod の数。 |
integer |
13.2.130. KafkaBridge
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka Bridge の仕様。 |
status | Kafka Bridge のステータス。 |
13.2.131. KafkaBridgeSpec
スキーマ参照
KafkaBridge
で使用
KafkaBridgeSpec
スキーマプロパティーの完全リスト
Kafka Bridge クラスターを設定します。
設定オプションは以下に関連しています。
- Kafka クラスターブートストラップアドレス
- セキュリティー (暗号化、認証、および承認)
- コンシューマー設定
- プロデューサーの設定
- HTTP の設定
13.2.131.1. logging
Kafka Bridge には独自の設定可能なロガーがあります。
-
logger.bridge
-
logger.<operation-id>
logger.<operation-id>
ロガーの <operation-id>
を置き換えると、特定の操作のログレベルを設定できます。
-
createConsumer
-
deleteConsumer
-
subscribe
-
unsubscribe
-
poll
-
assign
-
commit
-
send
-
sendToPartition
-
seekToBeginning
-
seekToEnd
-
seek
-
healthy
-
ready
-
openapi
各操作は OpenAPI 仕様にしたがって定義されます。各操作にはブリッジが HTTP クライアントから要求を受信する対象の API エンドポイントがあります。各エンドポイントのログレベルを変更すると、送信および受信 HTTP リクエストに関する詳細なログ情報を作成できます。
各ロガーは name
を http.openapi.operation.<operation-id>
として割り当てるように設定する必要があります。たとえば、send
操作ロガーのロギングレベルを設定すると、以下が定義されます。
logger.send.name = http.openapi.operation.send logger.send.level = DEBUG
Kafka Bridge では Apache log4j2
ロガー実装が使用されます。ロガーは log4j2.properties
ファイルで定義されます。このファイルには healthy
および ready
エンドポイントの以下のデフォルト設定が含まれています。
logger.healthy.name = http.openapi.operation.healthy logger.healthy.level = WARN logger.ready.name = http.openapi.operation.ready logger.ready.level = WARN
その他すべての操作のログレベルは、デフォルトで INFO
に設定されます。
logging
プロパティーを使用してロガーおよびロガーレベルを設定します。
ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name
プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。logging.valueFrom.configMapKeyRef.name
および logging.valueFrom.configMapKeyRef.key
プロパティーは必須です。name
または key
が設定されていない場合、デフォルトのロギングが使用されます。ConfigMap 内では、ロギング設定は log4j.properties
を使用して記述されます。ログレベルの詳細は、「Apache logging services」を参照してください。
inline
および external
ロギングの例は次のとおりです。
inline ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge spec: # ... logging: type: inline loggers: logger.bridge.level: "INFO" # enabling DEBUG just for send operation logger.send.name: "http.openapi.operation.send" logger.send.level: "DEBUG" # ...
外部ロギング
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge spec: # ... logging: type: external valueFrom: configMapKeyRef: name: customConfigMap key: bridge-logj42.properties # ...
設定されていない利用可能なロガーのレベルは OFF
に設定されています。
Cluster Operator を使用して Kafka Bridge がデプロイされた場合、Kafka Bridge のロギングレベルの変更は動的に適用されます。
外部ロギングを使用する場合は、ロギングアペンダーが変更されるとローリングアップデートがトリガーされます。
ガベッジコレクター (GC)
ガベッジコレクターのロギングは、jvmOptions
プロパティー を使用して有効 (または無効) にすることもできます。
13.2.131.2. KafkaBridgeSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
replicas |
|
integer | |
image | Pod の Docker イメージ。 |
string | |
bootstrapServers | Kafka クラスターへの最初の接続を確立するための host:port ペアの一覧。 |
string | |
tls | Kafka Bridge をクラスターに接続するための TLS 設定。 |
authentication |
クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の |
| |
http | HTTP 関連の設定。 |
consumer | Kafka コンシューマーに関連する設定。 |
producer | Kafka プロデューサーに関連する設定。 |
resources | 予約する CPU およびメモリーリソース。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
jvmOptions | 現時点でサポートされていない Pod の JVM オプション。 |
logging |
Kafka Bridge のロギング設定。タイプは、指定のオブジェクト内の |
enableMetrics | Kafka Bridge のメトリクスを有効にします。デフォルトは false です。 |
boolean | |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
template |
Kafka Bridge リソースのテンプレート。テンプレートを使用すると、ユーザーは |
tracing |
Kafka Bridge でのトレーシングの設定。タイプは、指定のオブジェクト内の |
13.2.132. KafkaBridgeTls
スキーマ参照
KafkaBridgeSpec
で使用
プロパティー | 説明 |
---|---|
trustedCertificates | TLS 接続の信頼済み証明書。 |
|
13.2.133. KafkaBridgeHttpConfig
スキーマ参照
KafkaBridgeSpec
で使用
KafkaBridgeHttpConfig
スキーマプロパティーの完全リスト
Kafka Bridge の Kafka クラスターへの HTTP アクセスを設定します。
デフォルトの HTTP 設定では、8080 番ポートで Kafka Bridge をリッスンします。
13.2.133.1. cors
HTTP プロパティーは、Kafka クラスターへの HTTP アクセスを有効にする他に、CPRS (Cross-Origin Resource Sharing) により Kafka Bridge のアクセス制御を有効化または定義する機能を提供します。CORS は、複数のオリジンから指定のリソースにブラウザーでアクセスできるようにする HTTP メカニズムです。CORS を設定するには、許可されるリソースオリジンのリストと、HTTP のアクセス方法を定義します。オリジンには、URL または Java 正規表現を使用できます。
Kafka Bridge HTTP の設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... http: port: 8080 cors: allowedOrigins: "https://strimzi.io" allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH" # ...
13.2.133.2. KafkaBridgeHttpConfig
スキーマプロパティー
プロパティー | 説明 |
---|---|
port | サーバーがリッスンするポート。 |
integer | |
cors | HTTP Bridge の CORS 設定。 |
13.2.134. KafkaBridgeHttpCors
スキーマ参照
プロパティー | 説明 |
---|---|
allowedOrigins | 許可されるオリジンのリスト。Java の正規表現を使用できます。 |
string array | |
allowedMethods | 許可される HTTP メソッドのリスト。 |
string array |
13.2.135. KafkaBridgeConsumerSpec
スキーマ参照
KafkaBridgeSpec
で使用
KafkaBridgeConsumerSpec
スキーマプロパティーの完全リスト
Kafka Bridge のコンシューマーオプションを鍵として設定します。
値は以下の JSON タイプのいずれかになります。
- 文字列
- 数値
- ブール値
AMQ Streams で直接管理されるオプションを除き、コンシューマー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。
-
ssl.
-
sasl.
-
security.
-
bootstrap.servers
-
group.id
禁止されているオプションの 1 つが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka に渡されます。
config
オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Bridge クラスターが起動しなかったり、不安定になる可能性があります。Cluster Operator が新しい設定をすべての Kafka Bridge ノードにロールアウトできるように設定を修正します。
禁止されているオプションには例外があります。TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。
Kafka Bridge コンシューマーの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... consumer: config: auto.offset.reset: earliest enable.auto.commit: true ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" ssl.endpoint.identification.algorithm: HTTPS # ...
13.2.135.1. KafkaBridgeConsumerSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
config | ブリッジによって作成されたコンシューマーインスタンスに使用される Kafka コンシューマーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、group.id、sasl.、security. (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols). |
map |
13.2.136. KafkaBridgeProducerSpec
スキーマ参照
KafkaBridgeSpec
で使用
KafkaBridgeProducerSpec
スキーマプロパティーの完全リスト
Kafka Bridge のプロデューサーオプションを鍵として設定します。
値は以下の JSON タイプのいずれかになります。
- 文字列
- 数値
- ブール値
AMQ Streams で直接管理されるオプションを除き、プロデューサー向けの Apache Kafka 設定ドキュメント に記載されているオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションはすべて禁止されています。
-
ssl.
-
sasl.
-
security.
-
bootstrap.servers
禁止されているオプションの 1 つが config
プロパティーにある場合、そのオプションは無視され、警告メッセージが Cluster Operator ログファイルに出力されます。その他のオプションはすべて Kafka に渡されます。
config
オブジェクトのキーまたは値は Cluster Operator によって検証されません。無効な設定を指定すると、Kafka Bridge クラスターが起動しなかったり、不安定になる可能性があります。Cluster Operator が新しい設定をすべての Kafka Bridge ノードにロールアウトできるように設定を修正します。
禁止されているオプションには例外があります。TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。
Kafka Bridge プロデューサーの設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... producer: config: acks: 1 delivery.timeout.ms: 300000 ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" ssl.enabled.protocols: "TLSv1.2" ssl.protocol: "TLSv1.2" ssl.endpoint.identification.algorithm: HTTPS # ...
13.2.136.1. KafkaBridgeProducerSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
config | ブリッジによって作成されたプロデューサーインスタンスに使用される Kafka プロデューサーの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、bootstrap.servers、sasl.、security. (次の例外を除く: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols). |
map |
13.2.137. KafkaBridgeTemplate
スキーマ参照
KafkaBridgeSpec
で使用
プロパティー | 説明 |
---|---|
deployment |
Kafka Bridge |
pod |
Kafka Bridge |
apiService |
Kafka Bridge API |
bridgeContainer | Kafka Bridge コンテナーのテンプレート。 |
podDisruptionBudget |
Kafka Bridge |
13.2.138. KafkaBridgeStatus
スキーマ参照
KafkaBridge
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
url | 外部クライアントアプリケーションが Kafka Bridge にアクセスできる URL。 |
string | |
labelSelector | このリソースを提供する Pod のラベルセレクター。 |
string | |
replicas | このリソースを提供するために現在使用されている Pod の数。 |
integer |
13.2.139. KafkaConnector
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka Connector の仕様。 |
status | Kafka Connector のステータス。 |
13.2.140. KafkaConnectorSpec
スキーマ参照
KafkaConnector
で使用
プロパティー | 説明 |
---|---|
class | Kafka Connector のクラス。 |
string | |
tasksMax | Kafka Connector のタスクの最大数。 |
integer | |
config | Kafka Connector の設定。次のプロパティーは設定できません: connector.class、tasks.max |
map | |
pause | コネクターを一時停止すべきかどうか。デフォルトは false です。 |
boolean |
13.2.141. KafkaConnectorStatus
スキーマ参照
KafkaConnector
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
connectorStatus | Kafka Connect REST API によって報告されるコネクターのステータス。 |
map | |
tasksMax | Kafka Connector のタスクの最大数。 |
integer | |
topics | Kafka Connector によって使用されるトピックのリスト。 |
string array |
13.2.142. KafkaMirrorMaker2
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka MirrorMaker 2.0 クラスターの仕様。 |
status | Kafka MirrorMaker 2.0 クラスターのステータス。 |
13.2.143. KafkaMirrorMaker2Spec
スキーマ参照
プロパティー | 説明 |
---|---|
version | Kafka Connect のバージョン。デフォルトは 2.7.0 です。バージョンのアップグレードまたはダウングレードに必要なプロセスを理解するには、ユーザードキュメントを参照してください。 |
string | |
replicas | Kafka Connect グループの Pod 数。 |
integer | |
image | Pod の Docker イメージ。 |
string | |
connectCluster |
Kafka Connect に使用されるクラスターエイリアス。エイリアスは |
string | |
clusters | ミラーリング用の Kafka クラスター。 |
mirrors | MirrorMaker 2.0 コネクターの設定。 |
resources | CPU とメモリーリソースおよび要求された初期リソースの上限。詳細は、core/v1 resourcerequirements の外部ドキュメント を参照してください。 |
livenessProbe | Pod の liveness チェック。 |
readinessProbe | Pod の readiness チェック。 |
jvmOptions | Pod の JVM オプション。 |
jmxOptions | JMX オプション。 |
affinity |
|
tolerations |
|
Toleration array | |
logging |
Kafka Connect のロギング設定。タイプは、指定のオブジェクト内の |
metrics |
|
map | |
tracing |
Kafka Connect でのトレーシングの設定。タイプは、指定のオブジェクト内の |
template |
Kafka Connect および Kafka Connect S2I リソースのテンプレート。テンプレートを使用すると、ユーザーは |
externalConfiguration | Secret または ConfigMap から Kafka Connect Pod にデータを渡し、これを使用してコネクターを設定します。 |
metricsConfig |
メトリクスの設定。タイプは、指定のオブジェクト内の |
13.2.144. KafkaMirrorMaker2ClusterSpec
スキーマ参照
KafkaMirrorMaker2ClusterSpec
スキーマプロパティーの完全リスト
ミラーリング用の Kafka クラスターを設定します。
13.2.144.1. config
config
プロパティーを使用して Kafka オプションを設定します。
標準の Apache Kafka 設定が提供されることがありますが、AMQ Streams によって直接管理されないプロパティーに限定されます。
TLS バージョンに特定の 暗号スイート を使用するクライアント接続では、許可された ssl
プロパティー を設定できます。また、ssl.endpoint.identification.algorithm
プロパティーを設定して、 ホスト名の検証を有効または無効にすることもできます。
13.2.144.2. KafkaMirrorMaker2ClusterSpec
スキーマプロパティー
プロパティー | 説明 |
---|---|
alias | Kafka クラスターの参照に使用されるエイリアス。 |
string | |
bootstrapServers |
Kafka クラスターへの接続を確立するための |
string | |
tls | MirrorMaker 2.0 コネクターをクラスターに接続するための TLS 設定。 |
authentication |
クラスターに接続するための認証設定。タイプは、指定のオブジェクト内の |
| |
config | MirrorMaker 2.0 クラスターの設定。次の接頭辞を持つプロパティーは設定できません: ssl.、sasl.、security.、listeners、plugin.path、rest.、bootstrap.servers、consumer.interceptor.classes、producer.interceptor.classes (ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols を除く) |
map |
13.2.145. KafkaMirrorMaker2Tls
スキーマ参照
KafkaMirrorMaker2ClusterSpec
で使用
プロパティー | 説明 |
---|---|
trustedCertificates | TLS 接続の信頼済み証明書。 |
|
13.2.146. KafkaMirrorMaker2MirrorSpec
スキーマ参照
プロパティー | 説明 |
---|---|
sourceCluster |
Kafka MirrorMaker 2.0 コネクターによって使用されるソースクラスターのエイリアス。エイリアスは |
string | |
targetCluster |
Kafka MirrorMaker 2.0 コネクターによって使用されるターゲットクラスターのエイリアス。エイリアスは |
string | |
sourceConnector | Kafka MirrorMaker 2.0 ソースコネクターの仕様。 |
heartbeatConnector | Kafka MirrorMaker 2.0 ハートビートコネクターの仕様。 |
checkpointConnector | Kafka MirrorMaker 2.0 チェックポイントコネクターの仕様。 |
topicsPattern | ミラーリングするトピックに一致する正規表現 (例: "topic1|topic2|topic3")。コンマ区切りリストもサポートされます。 |
string | |
topicsBlacklistPattern | ミラーリングから除外するトピックに一致する正規表現。コンマ区切りリストもサポートされます。 |
string | |
groupsPattern | ミラーリングされるコンシューマーグループに一致する正規表現。コンマ区切りリストもサポートされます。 |
string | |
groupsBlacklistPattern | ミラーリングから除外するコンシューマーグループに一致する正規表現。コンマ区切りリストもサポートされます。 |
string |
13.2.147. KafkaMirrorMaker2ConnectorSpec
スキーマ参照
KafkaMirrorMaker2MirrorSpec
で使用
プロパティー | 説明 |
---|---|
tasksMax | Kafka Connector のタスクの最大数。 |
integer | |
config | Kafka Connector の設定。次のプロパティーは設定できません: connector.class、tasks.max |
map | |
pause | コネクターを一時停止すべきかどうか。デフォルトは false です。 |
boolean |
13.2.148. KafkaMirrorMaker2Status
スキーマ参照
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
url | Kafka Connect コネクターの管理および監視用の REST API エンドポイントの URL。 |
string | |
connectorPlugins | この Kafka Connect デプロイメントで使用できるコネクタープラグインの一覧。 |
| |
connectors | Kafka Connect REST API によって報告される MirrorMaker 2.0 コネクターステータスの一覧。 |
map array | |
labelSelector | このリソースを提供する Pod のラベルセレクター。 |
string | |
replicas | このリソースを提供するために現在使用されている Pod の数。 |
integer |
13.2.149. KafkaRebalance
スキーマ参照
プロパティー | 説明 |
---|---|
spec | Kafka のリバランス (再分散) の仕様。 |
status | Kafka のリバランス (再分散) のステータス。 |
13.2.150. KafkaRebalanceSpec
スキーマ参照
KafkaRebalance
で使用
プロパティー | 説明 |
---|---|
goals | リバランスプロポーザルの生成および実行に使用されるゴールのリスト (優先度順)。サポートされるゴールは https://github.com/linkedin/cruise-control#goals を参照してください。空のゴールリストを指定すると、default.goals Cruise Control 設定パラメーターに宣言されたゴールが使用されます。 |
string array | |
skipHardGoalCheck | 最適化プロポーザルの生成で、Kafka CR に指定されたハードゴールのスキップを許可するかどうか。これは、これらのハードゴールの一部が原因で分散ソリューションが検索できない場合に便利です。デフォルトは false です。 |
boolean | |
excludedTopics | 一致するトピックが最適化プロポーザルの計算から除外される正規表現。この正規表現は java.util.regex.Pattern クラスによって解析されます。サポートされる形式の詳細は、このクラスのドキュメントを参照してください。 |
string | |
concurrentPartitionMovementsPerBroker | 各ブローカーに出入りする継続中であるパーティションレプリカの移動の上限。デフォルトは 5 です。 |
integer | |
concurrentIntraBrokerPartitionMovements | 各ブローカー内のディスク間で継続中のパーティションレプリカ移動の上限。デフォルトは 2 です。 |
integer | |
concurrentLeaderMovements | 継続中のパーティションリーダーシップ移動の上限。デフォルトは 1000 です。 |
integer | |
replicationThrottle | レプリカの移動に使用される帯域幅の上限 (バイト/秒単位)。デフォルトでは制限はありません。 |
integer | |
replicaMovementStrategies | 生成された最適化プロポーザルでのレプリカ移動の実行順序を決定するために使用されるストラテジークラス名のリスト。デフォルトでは、生成された順序でレプリカの移動が実行される BaseReplicaMovementStrategy が使用されます。 |
string array |
13.2.151. KafkaRebalanceStatus
スキーマ参照
KafkaRebalance
で使用
プロパティー | 説明 |
---|---|
conditions | ステータス条件の一覧。 |
| |
observedGeneration | 最後に Operator によって調整された CRD の生成。 |
integer | |
sessionId | この KafkaRebalance リソースに関する Cruise Control へのリクエストのセッション識別子。これは、継続中のリバランス操作の状態を追跡するために、Kafka Rebalance operator によって使用されます。 |
string | |
optimizationResult | 最適化の結果を示す JSON オブジェクト。 |
map |
付録A サブスクリプションの使用
AMQ Streams は、ソフトウェアサブスクリプションから提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。
アカウントへのアクセス
- access.redhat.com に移動します。
- アカウントがない場合は、作成します。
- アカウントにログインします。
サブスクリプションのアクティベート
- access.redhat.com に移動します。
- サブスクリプション に移動します。
- Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。
Zip および Tar ファイルのダウンロード
zip または tar ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合は、この手順は必要ありません。
- ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
- INTEGRATION AND AUTOMATION カテゴリーで Red Hat AMQ Streams エントリーを見つけます。
- 必要な AMQ Streams 製品を選択します。Software Downloads ページが開きます。
- コンポーネントの Download リンクをクリックします。
改訂日時: 2021-06-07 00:19:03 UTC