1. Home
  2. Confluent for Kubernetes

Confluent for Kubernetes リリースノート

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

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

Confluent for Kubernetes 2.3.1 リリースノート

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

注目すべき機能強化

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

注目すべき修正

  • アーカイブパスに誤ったサフィックスがある場合、コネクタープラグインのインストールが正常に失敗するようになりました。
  • spec.clustersScopeByIds.kafkaClusterId 設定を反映するように ConfluentRoleBinding を修正しました。
  • 移行前に設定されていなかったグローバル Telemetry は設定しないように CFK の移行が修正されました。
  • セキュリティと脆弱性の問題が修正されました。

Confluent for Kubernetes 2.3.0 リリースノート

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

新機能

マルチリージョンクラスター（GA）

複数の Kubernetes リージョンで Kafka、ZooKeeper、Schema Registry クラスターをデプロイできるようになりました。

組み込みのマルチリージョンレプリケーションを使用すると、災害時に自動クライアントフェイルオーバーによってリージョンのデータセンター全体に Confluent Platform をデプロイできます。また、トピック単位で同期および非同期レプリケーションを実行でき、すべてのレプリケーションでオフセットが保持されます。

「Confluent Platform のマルチリージョンデプロイ」を参照してください。

Confluent Platform コンポーネントポッドのカスタムボリュームマウント

CFK では、さまざまなタイプのカスタムボリュームを設定できるよう Confluent Platform ポッドを構成することが可能です。これらを同時にポッドに接続して、ポッド内の任意のパスにマウントできます。

「カスタムボリュームのマウント」を参照してください。

Schema Linking の宣言型管理

Schema Linking は、2 つの Schema Registry クラスター間でスキーマの同期を継続する Confluent の機能です。CFK には、スキーマエクスポーターの作成と管理のワークフロー全体をサポートする、SchemaExporter のカスタムリソース定義（CRD）を使用した宣言型 API が用意されています。

「スキーマのリンク」を参照してください。

すべてのシークレットを HashiCorp Vault で管理し Confluent Platform ポッドに挿入することが可能に

Confluent Platform コンポーネントの CR に加えて、HashCorp Vault を使用して、トピック、スキーマ、コネクターなどの CFK アプリケーションリソースのシークレットを管理できるようになりました。

「Vault でのシークレットの提供」を参照してください。

意図的ではないクラスターの削除からの保護（早期アクセス）

クラスターオブジェクトの削除リクエストを拒否するように CFK を構成できます。

「クラスターオブジェクトの削除から保護する Confluent for Kubernetes のデプロイ」を参照してください。

注目すべき機能強化

注目すべき修正

  • Operator でグローバル Telemetry が無効になっている場合、Operator から CFK への移行で Telemetry の移行が適切に処理されない問題が修正されました。
  • CFK によってデプロイされた Control Center で、RBAC が有効になっている複数の Kafka クラスターをモニタリングできるようになりました。
  • パブリックライセンスキーが CFK Helm チャートに含まれなくなりました。
  • ClusterLink の CR の作成時に検証エラーの原因となっていた ClusterLink の CRD の spec.mirrorTopics.configs 内の重複スペースが修正されました。

Known issues

  • 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" が頻繁に表示されます。

  • 一元的な RBAC で Confluent Platform 7.0.2 または 7.1.0 をデプロイする場合、セカンダリ Kafka クラスターに接続する際に "無効なライセンス" の問題が発生することがあります。

    これを回避するには、セカンダリ Kafka クラスターを再起動します。

  • Confluent のライセンスに関する問題が発生し、CFK のエラーログ invalid license illegal base64 data at input byte 223 が記録された場合は、--set image.pullPolicy=Always または --set image.tag=0.435.11-1 オプションで CFK を再インストールします。

    helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set image.pullPolicy=Always \
  --namespace <namespace>

    helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set image.tag=0.435.11-1 \
  --namespace <namespace>

    インストールコマンドの詳細については、「Confluent for Kubernetes のデプロイ」を参照してください。

  • モニタリングインターセプターが構成された REST Proxy では、RBAC が有効になっている場合、コールバックハンドラーのプロパティが欠落します。インターセプターは機能せず、KafkaRestProxy ログにエラーメッセージが記録されます。

    これを回避するには、KafkaRestProxy の CR で次のように構成のオーバーライドを手動で追加します。

    configOverrides:
  server:
    - confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    - consumer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    - producer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler

  • カスタムオーソライザーの構成

    構成のオーバーライドを使用してカスタムオーソライザー（RBAC または ACL 以外）を構成している場合は、構成のオーバーライド を使用して kafka.rest.client プロパティを構成する必要があります。たとえば、Kafka ブローカーで mTLS を有効にするには、kafka.rest.client.security.protocol を SSL または SASL_SSL に設定する必要があります。

    サポートされているオプションについては、「Admin REST APIs と Kafka ブローカー間の SSL 暗号化の構成オプション」を参照してください。

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

CFK 2.3.0 does not support the following Confluent Platform 7.1 functionality:

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