1. Home
  2. Confluent for Kubernetes

Confluent for Kubernetes リリースノート

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

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

Confluent for Kubernetes 2.2.2 リリースノート

Confluent for Kubernetes 2.2.2 では、Confluent Platform バージョン 6.2.x および 7.0.x を Kubernetes にデプロイし、管理することができます。

注目すべき機能強化

  • LoadBalancer、Nodeport、Route サービスにラベルを追加する機能。

注目すべき修正

  • アーカイブパスに誤ったサフィックスがある場合、コネクタープラグインのインストールが正常に失敗するようになりました。
  • 移行前に設定されていなかったグローバル Telemetry は設定しないように CFK の移行が修正されました。
  • ClusterLink の CR の作成時に検証エラーの原因となっていた ClusterLink の CRD の spec.mirrorTopics.configs 内の重複スペースが修正されました。
  • セキュリティと脆弱性の問題が修正されました。

Confluent for Kubernetes 2.2.1 リリースノート

Confluent for Kubernetes 2.2.1 では、Confluent Platform バージョン 6.2.x および 7.0.x を Kubernetes にデプロイし、管理することができます。

注目すべき修正

  • CFK は、参照されている KafkaClusterRef がある場所とは異なる名前空間で作成された KafkaTopic のカスタムリソースを自動削除しません。
  • 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 にデプロイする場合は適用されません。

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

    これが機能するためには、（1）|ccloud| 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" というエラーが返されることがあります。

  • 警告ログを有効にすると、ZooKeeper 上の定期的な Kubernetes TCP プローブにより、警告メッセージ "client has closed socket" が頻繁に表示されます。

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

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

  • Kafka の認証メカニズム: Kerberos と SASL/Scram
  • マルチリージョンクラスターデプロイ: 早期アクセスプログラムでのみサポート

Confluent for Kubernetes 2.2.0 リリースノート

Confluent for Kubernetes 2.2.0 では、Confluent Platform バージョン 6.2.x および 7.0.x を Kubernetes にデプロイし、管理することができます。

新機能

Confluent for Kubernetes 2.2.0 では、以下の新機能がサポートされています。

  • ClusterLink のカスタムリソース定義（CRD）を使用してクラスターリンクを宣言的に管理します。「cluster-link-configs」を参照してください。

  • Kafka クラスターを "縮小" するための自動化されたワークフローを提供します。

    CFK により、残りのブローカーでパーティションのバランスが調整され、削除するブローカーが正常に終了します。「Confluent Platform クラスターのスケーリングとデータのバランス調整」を参照してください。

注目すべき機能強化

  • CFK と Confluent Platform を Kubernetes 1.22 でデプロイできます。

注目すべき修正

  • Kafka ACL が有効になっていたときに、KafkaTopic のカスタムリソースを適用して Kafka のトピックを作成することができませんでした。
  • Kafka ACL が有効になっていたときに、誤った Confluent Admin REST API 構成が生成されました。
  • 外部トラフィックポリシーが外部ブローカーロードバランサーに対して、Cluster ではなく、Local に正しく設定されています。

既知の問題

  • 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 にデプロイする場合は適用されません。

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

    これが機能するためには、（1）|ccloud| 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" というエラーが返されることがあります。

  • 警告ログを有効にすると、ZooKeeper 上の定期的な Kubernetes TCP プローブにより、警告メッセージ "client has closed socket" が頻繁に表示されます。

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

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

  • Kafka の認証メカニズム: Kerberos と SASL/Scram
  • マルチリージョンクラスターデプロイ: 早期アクセスプログラムでのみサポート