1. Home
  2. Confluent for Kubernetes

Confluent for Kubernetes リリースノート

Confluent for Kubernetes （CFK）には、Kubernetes に Confluent Platform をデプロイして管理するための、宣言型 API を主軸としたコントロールプレーンが備わっています。

以降のセクションでは、このリリースの技術的な詳細について説明します。

Confluent for Kubernetes 2.0.4 リリースノート

Confluent for Kubernetes 2.0.4 では、Confluent Platform バージョン 6.0.x、6.1.x、6.2.x を Kubernetes にデプロイして管理することができます。

注目すべき修正

  • CFK で、ブートストラップロードバランサーの cluster と、ブローカーロードバランサーの local に外部トラフィックポリシーが正しく設定されるようになりました。
  • 異なる名前空間で作成された KafkaTopic のカスタムリソースが、参照されている KafkaClusterRef の場所から CFK によって自動削除されません。
  • Schema Registry の依存関係を有効にしていない場合に Confluent Control Center の移行が nil ポインター参照により失敗するという問題が修正されました。
  • Connect、ksqlDB、または Schema Registry の依存関係が mTLS 認証で構成されている場合の Confluent Control Center のサーバープロパティの冗長な構成が削除されました。
  • セキュリティと脆弱性に関する修正。

既知の問題

  • Red Hat の Operator Lifecycle Manager を使用して（つまり、Operator Hub を使用して）|co-long| を Red Hat OpenShift にデプロイする場合、OpenShift バージョン 4.9 を使用する必要があります。

    この OpenShift のバージョン制限は、このドキュメントで説明されている、Red Hat Operator Lifecycle Manager を使用しない標準的な方法で CFK を Red Hat OpenShift にデプロイする場合は適用されません。これは、サポート対象のすべての Kubernetes ディストリビューション全体に該当します。

  • 自動生成された証明書が ksqlDB REST エンドポイントで使用されている場合、Confluent Cloud を参照する ksqlDB デプロイは、Let's Encrypt CA を信頼する必要があります。

    これが機能するためには、（1） Confluent Cloud CA と（2）自己署名 CA の両方を含んだ CA バンドルを、cacerts.pem を通じて ksqlDB のカスタムリソース（CR）に指定する必要があります。

  • TLS が有効で、Confluent Control Center が MDS または Confluent Cloud Schema Registry との通信に別の TLS 証明書を使用している場合、Control Center は MDS または Confluent Cloud Schema Registry との接続に自動生成された TLS 証明書を使用することができません。ワークロードについては、トラブルシューティングのガイド を参照してください。

  • Schema Registry と Kafka の CR を同時にデプロイすると、レプリケーション係数が 3 のトピックを作成できないために、Schema Registry でエラーが発生する場合があります。これは Kafka ブローカーが完全には起動していないためです。

    これを回避するには、Schema Registry のデプロイを削除し、Kafka が完全に起動した後で再度デプロイします。

  • RBAC のメタデータを格納するために別途 "セカンダリ" Kafka が使用される集中型モードで RBAC 対応の Kafka クラスターをデプロイすると、セカンダリ Kafka クラスターで "License Topic could not be created" というエラーが返されることがあります。

  • Confluent Platform 6.1.1 バージョンでは、ksqlDB の REST インターフェイスに対して基本認証を有効にすることができません。この問題への回避策はありません。

  • ZooKeeper TLS 証明書に機密の構成を提供するために DirectoryInPathContainer を使用する場合、このメカニズムでは JKS トラストストアとキーストアのパスワードを指定できません。secretRef または configOverrides を使用して、これを提供できます。

Confluent Platform 6.2 からの既知のギャップ

CFK 2.0.4 は、次の Confluent Platform 6.2 機能をサポートしていません。

  • Kafka の認証メカニズム: Kerberos と SASL/Scram

  • マルチリージョンクラスターデプロイ

  • Confluent REST Proxy

    これは、スタンドアロンの REST Proxy を CFK の外部でデプロイ、管理し、CFK によって管理される Kafka クラスターを参照するように設定することで回避できます。

Confluent for Kubernetes 2.0.3 リリースノート

Confluent for Kubernetes 2.0.3 では、Confluent Platform バージョン 6.0.x、6.1.x、6.2.x を Kubernetes にデプロイして管理することができます。

注目すべき機能強化

  • このリリースには、新しい機能強化はありません。

注目すべき修正

  • Confluent Control Center 構成 - Schema Registry REST TLS 用の適切なプレフィックスを追加するように構成設定が修正されました。
  • Kafka ローリング再起動 - 各 Kafka ブローカーを正常にシャットダウンするようにローリング再起動を修正しました。
  • Red Hat Universal Base Images（UBI）- 最新バージョンの UBI が組み込まれました。

既知の問題

  • Red Hat の Operator Lifecycle Manager を使用して（つまり、Operator Hub を使用して）|co-long| を Red Hat OpenShift にデプロイする場合、OpenShift バージョン 4.9 を使用する必要があります。

    この OpenShift のバージョン制限は、このドキュメントで説明されている、Red Hat Operator Lifecycle Manager を使用しない標準的な方法で CFK を Red Hat OpenShift にデプロイする場合は適用されません。これは、サポート対象のすべての Kubernetes ディストリビューション全体に該当します。

  • 自動生成された証明書が ksqlDB REST エンドポイントで使用されている場合、Confluent Cloud を参照する ksqlDB デプロイは、Let's Encrypt CA を信頼する必要があります。

    これが機能するためには、（1） Confluent Cloud CA と（2）自己署名 CA の両方を含んだ CA バンドルを、cacerts.pem を通じて ksqlDB のカスタムリソース（CR）に指定する必要があります。

  • TLS が有効で、Confluent Control Center が MDS または Confluent Cloud Schema Registry との通信に別の TLS 証明書を使用している場合、Control Center は MDS または Confluent Cloud Schema Registry との接続に自動生成された TLS 証明書を使用することができません。ワークロードについては、トラブルシューティングのガイド を参照してください。

  • Schema Registry と Kafka の CR を同時にデプロイすると、レプリケーション係数が 3 のトピックを作成できないために、Schema Registry でエラーが発生する場合があります。これは Kafka ブローカーが完全には起動していないためです。

    これを回避するには、Schema Registry のデプロイを削除し、Kafka が完全に起動した後で再度デプロイします。

  • RBAC のメタデータを格納するために別途 "セカンダリ" Kafka が使用される集中型モードで RBAC 対応の Kafka クラスターをデプロイすると、セカンダリ Kafka クラスターで "License Topic could not be created" というエラーが返されることがあります。

  • Confluent Platform 6.1.1 バージョンでは、ksqlDB の REST インターフェイスに対して基本認証を有効にすることができません。この問題への回避策はありません。

  • ZooKeeper TLS 証明書に機密の構成を提供するために DirectoryInPathContainer を使用する場合、このメカニズムでは JKS トラストストアとキーストアのパスワードを指定できません。secretRef または configOverrides を使用して、これを提供できます。

Confluent Platform 6.2 からの既知のギャップ

CFK 2.0.3 は、次の Confluent Platform 6.2 機能をサポートしていません。

  • Kafka の認証メカニズム: Kerberos と SASL/Scram

  • マルチリージョンクラスターデプロイ

  • Confluent REST Proxy

    これは、スタンドアロンの REST Proxy を CFK の外部でデプロイ、管理し、CFK によって管理される Kafka クラスターを参照するように設定することで回避できます。

Confluent for Kubernetes 2.0.2 リリースノート

Confluent for Kubernetes 2.0.2 では、Confluent Platform バージョン 6.0.x、6.1.x、6.2.x を Kubernetes にデプロイして管理することができます。

注目すべき機能強化

  • デプロイメント中のトラブルシューティングの改善 - シークレットが欠落しているために Confluent のカスタムリソースがデプロイできない場合、CFK がメッセージをログに記録します。
  • 内部リスナーや外部リスナーなどの複数の Kafka リスナーが、Kafka カスタムリソースの TLS 証明書に対して同じシークレット参照を共有できます。
  • すべての Confluent コンポーネントのカスタムリソースに対して、イメージプルポリシー（Always、Never、IfNotPresent）を指定できます。

注目すべき修正

  • ZooKeeper TLS - ZooKeeper 不要な "Unsuccessful handshake" メッセージがログに記録されなくなりました。
  • 構成 - CFK は、構成シークレットのテキストファイルでクォートなしでのユーザー名とパスワードの指定をサポートするようになりました。
  • 構成 - ユーザー名とパスワードに「=」文字を含めることができるようになりました。
  • ノードポートの作成 - NodePort サービスが、適切なポートを使用して nodePortOffset 構成入力を考慮して作成されるようになりました。
  • CFK Helm 構成 - 名前空間のリストが含まれる Helm コマンドで、名前空間名の間のスペース文字に対応するようになりました。
  • ライセンス構成 - ライセンスシークレットに空白と改行文字を含めることができるようになりました。
  • 不確定なシークレット - CFK は、作成したシークレットが不要になった場合に削除するようになりました。
  • テレメトリの構成 - 空のプロキシ構成を作成して、プロキシが不要であることを示すように構成できるようになりました。
  • Connect mTLS 構成がサポートされています。
  • Kubectl Confluent プラグイン - Microsoft Azure にデプロイされた CFK クラスターで使用できるようになりました。
  • ZooKeeper 構成オーバーライド - zookeeper.connect プロパティをオーバーライドできるようになりました。
  • 自動化されたローリングアップデート - Kafka 構成オーバーライドについて、CFK は Kafka のデプロイを自動的にローリングできるようになりました。
  • CFK で、デフォルトのブローカー間ユーザーと ZooKeeper クォーラムユーザーのパスワードの変更がサポートされます。

既知の問題

  • 自動生成された証明書が ksqlDB REST エンドポイントで使用されている場合、Confluent Cloud を参照する ksqlDB デプロイは、Let's Encrypt CA を信頼する必要があります。

    これが機能するためには、（1） Confluent Cloud CA と（2）自己署名 CA の両方を含んだ CA バンドルを、cacerts.pem を通じて ksqlDB の CR に指定する必要があります。

  • TLS が有効で、Confluent Control Center が MDS または Confluent Cloud Schema Registry との通信に別の TLS 証明書を使用している場合、Control Center は MDS または Confluent Cloud Schema Registry との接続に自動生成された TLS 証明書を使用することができません。ワークロードについては、トラブルシューティングのガイド を参照してください。

  • Schema Registry と Kafka の CR を同時にデプロイすると、レプリケーション係数が 3 のトピックを作成できないために、Schema Registry でエラーが発生する場合があります。これは Kafka ブローカーが完全には起動していないためです。

    これを回避するには、Schema Registry のデプロイを削除し、Kafka が完全に起動した後で再度デプロイします。

  • RBAC のメタデータを格納するために別途 "セカンダリ" Kafka が使用される集中型モードで RBAC 対応の Kafka クラスターをデプロイすると、セカンダリ Kafka クラスターで "License Topic could not be created" というエラーが返されることがあります。

  • Confluent Platform 6.1.1 バージョンでは、ksqlDB の REST インターフェイスに対して基本認証を有効にすることができません。この問題への回避策はありません。

  • ZooKeeper TLS 証明書に機密の構成を提供するために DirectoryInPathContainer を使用する場合、このメカニズムでは JKS トラストストアとキーストアのパスワードを指定できません。secretRef または configOverrides を使用して、これを提供できます。

Confluent Platform 6.2 からの既知のギャップ

CFK 2.0.2 は、次の Confluent Platform 6.2 機能をサポートしていません。

  • Kafka の認証メカニズム: Kerberos と SASL/Scram

  • マルチリージョンクラスターデプロイ

  • Confluent REST Proxy

    これは、スタンドアロンの REST Proxy を CFK の外部でデプロイ、管理し、CFK によって管理される Kafka クラスターを参照するように設定することで回避できます。

Confluent for Kubernetes 2.0.1 リリースノート

Confluent for Kubernetes 2.0.1 では、Confluent Platform バージョン 6.0.x、6.1.x、6.2.x を Kubernetes にデプロイして管理することができます。

注目すべき機能強化

  • Kubernetes RBAC セキュリティフットプリントの向上 - Confluent for Kubernetes に pod/exec Kubernetes リソース権限は不要になりました。

注目すべき修正

  • トピックのクリーンアップ - Kafka クラスターのカスタムリソースが削除されると、その Kafka クラスターに関連付けられているトピックのカスタムリソースも削除されます。
  • トピックの作成 - トピックのカスタムリソースに、そのトピックの構成を複数含めることができます。
  • トピックの作成 - トピックのカスタムリソースに、トピックの confluent.placement.constraints をサポートするための replicationFactor をオプションで指定できます。
  • SASL/PLAIN と Kafka ACL を使用したブローカー間の通信 - operator ユーザーは、Kafka スーパーユーザーとして、またブローカー間通信を認証するユーザーとして構成されます。

既知の問題

  • 自動生成された証明書が ksqlDB REST エンドポイントで使用されている場合、Confluent Cloud を参照する ksqlDB デプロイは、Let's Encrypt CA を信頼する必要があります。

    これが機能するためには、（1） Confluent Cloud CA と（2）自己署名 CA の両方を含んだ CA バンドルを、cacerts.pem を通じて ksqlDB の CR に指定する必要があります。

  • TLS が有効で、Confluent Control Center が MDS または Confluent Cloud Schema Registry との通信に別の TLS 証明書を使用している場合、Control Center は MDS または Confluent Cloud Schema Registry との接続に自動生成された TLS 証明書を使用することができません。ワークロードについては、トラブルシューティングのガイド を参照してください。

  • Schema Registry と Kafka の CR を同時にデプロイすると、レプリケーション係数が 3 のトピックを作成できないために、Schema Registry でエラーが発生する場合があります。これは Kafka ブローカーが完全には起動していないためです。

    これを回避するには、Schema Registry のデプロイを削除し、Kafka が完全に起動した後で再度デプロイします。

  • RBAC のメタデータを格納するために別途 "セカンダリ" Kafka が使用される集中型モードで RBAC 対応の Kafka クラスターをデプロイすると、セカンダリ Kafka クラスターで "License Topic could not be created" というエラーが返されることがあります。

  • Confluent Platform 6.1.1 バージョンでは、ksqlDB の REST インターフェイスに対して基本認証を有効にすることができません。この問題への回避策はありません。

Confluent Platform 6.2 からの既知のギャップ

CFK 2.0.1 は、次の Confluent Platform 6.2 機能をサポートしていません。

  • Kafka の認証メカニズム: Kerberos と SASL/Scram

  • マルチリージョンクラスターデプロイ

  • Confluent REST Proxy

    これは、スタンドアロンの REST Proxy を CFK の外部でデプロイ、管理し、CFK によって管理される Kafka クラスターを参照するように設定することで回避できます。

Confluent for Kubernetes 2.0.0 リリースノート

新機能

Confluent サービス用の Kubernetes ネイティブインターフェイス
  • 各コンポーネントの CustomResourceDefinition（CRD）を使用して宣言的に Confluent サービスを管理できます。
  • すべての Confluent サービスについて、サーバー、log4j、JVM プロパティのオーバーライドで構成を拡張できます。
  • Kubernetes シークレットまたは HashiCorp Vault で、機密の認証情報のライフサイクルを個別に安全に管理できます。
データプレーンリソースの管理
  • ConfluentRolebinding の CRD で RoleBindings を宣言的に管理できます。
  • KafkaTopic の CRD で Kafka のトピックを宣言的に管理できます。
セキュアなデプロイの自動化
  • 認証、RBAC 認可、TLS 暗号化により、本稼働環境に使用する条件が整ったセキュアなデプロイを自動化できます。必要な Confluent コンポーネントロールバインディングが CFK によって自動的に作成されます。
  • Confluent コンポーネントのネットワーク暗号化には、自動的に生成される TLS 証明書が使用されます。認証機関を指定すれば、それらの証明書が署名されます。
  • ZooKeeper のダイジェスト認証とサーバー間の TLS 暗号化を構成します。
  • Confluent サービスの REST エンドポイントには基本認証を構成します。

サポートされる環境

  • CFK 2.0.x は Confluent Platform 6.0 と 6.1 のデプロイをサポートします。
  • CFK 2.0.x は Kubernetes 1.15 ～ 1.20 へのデプロイをサポートします。

アップグレードパス

Confluent Operator 1.6 または 1.7 を使用していて、かつ Confluent Platform 6.0 または 6.1 を実行している場合は、移行の自動化スクリプトを使用して CFK 2.0.x に移行できます。

既知の問題

  • 自動生成された証明書が ksqlDB REST エンドポイントで使用されている場合、Confluent Cloud を参照する ksqlDB デプロイは、Let's Encrypt CA を信頼する必要があります。

    これが機能するためには、（1） Confluent Cloud CA と（2）自己署名 CA の両方を含んだ CA バンドルを、cacerts.pem を通じて ksqlDB の CR に指定する必要があります。

  • TLS が有効で、Confluent Control Center が MDS または Confluent Cloud Schema Registry との通信に別の TLS 証明書を使用している場合、Control Center は MDS または Confluent Cloud Schema Registry との接続に自動生成された TLS 証明書を使用することができません。ワークロードについては、トラブルシューティングのガイド を参照してください。

  • Schema Registry と Kafka の CR を同時にデプロイすると、レプリケーション係数が 3 のトピックを作成できないために、Schema Registry でエラーが発生する場合があります。これは Kafka ブローカーが完全には起動していないためです。

    これを回避するには、Schema Registry のデプロイを削除し、Kafka が完全に起動した後で再度デプロイします。

  • RBAC のメタデータを格納するために別途 "セカンダリ" Kafka が使用される集中型モードで RBAC 対応の Kafka クラスターをデプロイすると、セカンダリ Kafka クラスターで "License Topic could not be created" というエラーが返されることがあります。

  • Confluent Platform 6.1.1 バージョンでは、ksqlDB の REST インターフェイスに対して基本認証を有効にすることができません。この問題への回避策はありません。

Confluent Platform 6.1 からの既知のギャップ

CFK 2.0.0 は、次の Confluent Platform 6.1 機能をサポートしていません。

  • Kafka の認証メカニズム: Kerberos と SASL/Scram

  • マルチリージョンクラスターデプロイ

  • Confluent REST Proxy

    これは、スタンドアロンの REST Proxy を CFK の外部でデプロイ、管理し、CFK によって管理される Kafka クラスターを参照するように設定することで回避できます。