1. Home
2. Confluent for Kubernetes

Confluent Platform のデプロイ計画

このトピックでは、Confluent for Kubernetes （CFK）を使用した Confluent Platform のデプロイを計画する際に検討すべき、サポートされるオプションや推奨されるオプションについて説明します。

デプロイのワークフロー

CFK を使用して Confluent Platform を構成、デプロイ、管理するためのワークフローの概要は以下のとおりです。

1. このトピックの内容を振り返り、デプロイ環境に必要なオプションや推奨されるオプションを再確認します。

2. Kubernetes 環境を準備します。

   詳細については、「Confluent Platform 用の Kubernetes クラスターの準備」を参照してください。

3. Confluent for Kubernetes をデプロイします。

   詳細については、「Confluent for Kubernetes のデプロイ」を参照してください。

4. Confluent Platform を構成します。

   詳細については、「Confluent Platform の構成」を参照してください。

5. Confluent Platform をデプロイします。

   詳細については、「Confluent Platform のデプロイ」を参照してください。

6. Confluent Platform を管理します。

   詳細については、「Confluent for Kubernetes での Confluent Platform の管理」を参照してください。

デプロイのチェックリスト

以下に示したのは、Confluent Platform をデプロイするための準備のチェックリストです。

• Kubernetes プラットフォーム
• クラスターのサイジング
• Docker レジストリ
• ストレージ
• Kubernetes のセキュリティ
• Confluent のセキュリティ
• ネットワーク
• アップグレードとアップデート

サポートされる環境と前提条件

インストールを始める前に、以下の前提条件を確認し、対応します。

Kubernetes

• Confluent for Kubernetes 2.3.1 では、任意の Cloud Native Computing Foundation（CNCF） 準拠製品を使用する Kubernetes バージョン 1.18 ～ 1.23（OpenShift 4.6 ～ 4.10）がサポートされています。
• kubectl をインストールします。
• クラスターの kubeconfig ファイルを構成します。

Kubernetes ディストリビューションとして Red Hat OpenShift を使用している場合は、Red Hat の SCC（Security Context Constraint）への対応方法を確認しておく必要があります。その方法については、こちらの ドキュメント を参照してください。

オペレーティングシステム

Kubernetes ワーカーノードのベースとなるオペレーティングシステム（OS）のバージョンが、デプロイを検討している Confluent Platform バージョンのサポート対象であることが必要です。

特定のバージョンの Confluent Platform でサポートされる OS については、「サポートされているバージョンおよび相互運用性」を参照してください。

Helm

Confluent for Kubernetes には Helm 3 が必要です。

Confluent Platform

Confluent for Kubernetes 2.3.1 では、Confluent Platform バージョン 7.0.x と 7.1.x がサポートされています。

注釈

Confluent for Kubernetes で cp-helm-chart を使用することは避けてください。これは Confluent ではサポートされないオープンソースの Helm チャートです。

Confluent for Kubernetes のイメージ タグとバージョン

Confluent Platform および Confluent for Kubernetes イメージは、Docker Hub の confluentinc リポジトリ でホストされます。

Confluent Operator のタグの一覧 で、Confluent for Kubernetes イメージのバージョンおよび一致するタグを確認できます。

以下の表は、Confluent for Kubernetes / Confluent Operator のバージョン、対応するイメージタグ、およびその他の互換性情報の対応を示しています。

バージョン	CFK イメージタグ	Confluent Platform のバージョン	Kubernetes のバージョン	リリース日
Operator 1.6.0	0.419.0	5.5.x、6.0.x	1.15 - 1.18	2020 年 9 月 24 日
Operator 1.6.1	0.419.6	5.5.x、6.0.x	1.15 - 1.18	2021 年 1 月 4 日
Operator 1.6.2	0.419.10	5.5.x、6.0.x	1.15 - 1.18	2021 年 1 月 29 日
Operator 1.7.0	0.419.10	6.0.x、6.1.x	1.16 - 1.19	2021 年 2 月 9 日
Operator 1.7.1	0.419.13	6.0.x、6.1.x	1.16 - 1.19	2021 年 6 月 14 日
Operator 1.7.2	0.419.15	6.0.x、6.1.x	1.16 - 1.19	2021 年 7 月 20 日
CFK 2.0.0	0.174.6	6.0.x、6.1.x、6.2.x	1.15 - 1.20	2021 年 5 月 12 日
CFK 2.0.1	0.174.13	6.0.x、6.1.x、6.2.x	1.15 - 1.20	2021 年 6 月 10 日
CFK 2.0.2	0.174.21	6.0.x、6.1.x、6.2.x	1.15 - 1.20	2021 年 8 月 11 日
CFK 2.0.3	0.174.25	6.0.x、6.1.x、6.2.x	1.15 - 1.20	2021 年 9 月 10 日
CFK 2.0.4	0.174.34	6.0.x、6.1.x、6.2.x	1.15 - 1.20	2022 年 1 月 25 日
CFK 2.1.0	0.280.1	6.0.x、6.1.x、6.2.x	1.17 - 1.22 （OpenShift 4.6 ～ 4.9）	2021 年 10 月 12 日
CFK 2.1.1	0.280.22	6.0.x、6.1.x、6.2.x	1.17 - 1.22 （OpenShift 4.6 ～ 4.9）	2022 年 1 月 25 日
CFK 2.1.2	0.280.42	6.0.x、6.1.x、6.2.x	1.17 - 1.22 （OpenShift 4.6 ～ 4.9）	2022 年 5 月 5 日
CFK 2.2.0	0.304.2	6.2.x、7.0.x	1.17 - 1.22 （OpenShift 4.6 ～ 4.9）	2021 年 11 月 3 日
CFK 2.2.1	0.304.17	6.2.x、7.0.x	1.17 - 1.22 （OpenShift 4.6 ～ 4.9）	2022 年 1 月 25 日
CFK 2.2.2	0.304.41	6.2.x、7.0.x	1.17 - 1.22 （OpenShift 4.6 ～ 4.9）	2022 年 5 月 5 日
CFK 2.3.0	0.435.11	7.0.x、7.1.x	1.18 - 1.23 （OpenShift 4.6 ～ 4.10）	2022 年 4 月 5 日
CFK 2.3.1	0.435.23	7.0.x、7.1.x	1.18 - 1.23 （OpenShift 4.6 ～ 4.10）	2022 年 5 月 5 日

クラスターのサイジング

Confluent クラスターを作成する前に、このセクションのサイズの決定に関するガイドラインを参考にしてください。

クラスターの最小サイジングに関するガイダンスを次のテーブルに示します。

クラスターのタイプ	本稼働環境			最小
Confluent コンポーネント	CPU	メモリ	Disk	CPU	メモリ	Disk
ZooKeeper	4	14 GB	100 GB	2	8 GB	100 GB
Kafka ブローカー	12	64 GB	12 TB	4	16 GB	1 TB
Connect ワーカー	12	24 GB	50 GB [1]	4	16 GB	50 GB [1]
Schema Registry	2	4 GB	該当なし	2	4 GB	該当なし
Confluent Control Center	12	32 GB	300 GB	4	16 GB	250 GB
ksqlDB	4	32 GB	100 GB SSD [2]	4	20 GB	100 GB SSD
Confluent REST Proxy	16	[3]	1 GB+ [4]	16	[3]	1 GB+ [4]

• ZooKeeper と Kafka は、個別の Kubernetes ノードの個別のポッドにインストールされている必要があります。
• Confluent Platform デプロイのすべての機能を正常に動作させるには、Kafka ブローカーが少なくとも 3 つ必要です。1 ブローカー構成と 2 ブローカー構成は、どちらもサポートされていないため、開発、テスト、本稼働環境では使用しないでください。
• ^[1] Connect ワーカーのディスクストレージ要件は、Connect クラスターごとにダウンロードする Connect プラグインの数によって決まります。
• ^[2] ksqlDB のディスクストレージ要件は、同時クエリの数と実行される集約によって決まります。
• ^[3] インストールにのみ必要です。
• ^[4] 1 GB のオーバーヘッドに、プロデューサーあたり 64 MB、コンシューマーあたり 16 MB を追加します。

クラスターで必要となる Kubernetes ワーカーノードの数は、デプロイしているクラスターが、開発テスト用と本稼働環境用のどちらであるかに応じて異なります。

本稼働環境クラスター

Confluent Platform コンポーネントのカスタムリソース（CR）でデフォルトのキャパシティ値を確認してください。指定されている値が本稼働アプリケーションに与える影響をふまえてノードを用意します。

オンプレミスの システム要件 をもとにクラウドの本稼働環境に何が必要かを判断することもできます。指定されているオンプレミスストレージ情報はクラウド環境には該当しないことにご注意ください。

開発時のクラスターのテスト

一般に、各ノードには少なくとも 2 個または 4 個の CPU と 7 ～ 16 GB の RAM が必要です。CFK と全 Confluent Platform コンポーネントのデプロイをテストしている場合は、10 ノードからなるクラスターを作成し、6 ノードを Apache ZooKeeper™ ポッドと Apache Kafka® ポッドに（3 レプリカずつ）、4 ノードをその他すべてのコンポーネントポッドに割り当てます。

サイジングの推奨事項の詳細については、「Sizing Calculator for Apache Kafka and Confluent Platform」を参照してください。

コンポーネントのサイジングの構成

CFK では、カスタムリソース（CR）の制限とリクエストのプロパティを使用して、ユーザーがリソースの要件を指定します。Confluent Platform のリソース要件の定義については、「CPU リソースとメモリーリソース」を参照してください。

Docker レジストリ

Confluent for Kubernetes は、Confluent Docker イメージを Docker レジストリからプルして Kubernetes クラスターにデプロイします。

デフォルトで、Confluent for Kubernetes により、Docker Hub でホストされ公開されている Docker イメージが confluentinc リポジトリからデプロイされます。

独自の Docker レジストリとリポジトリを使用する場合は、Confluent リポジトリからイメージをプルし、お使いの Docker レジストリリポジトリにアップロードする必要があります。

カスタムプライベートレジストリの使用について詳しくは、「Confluent Platform に対するカスタム Docker レジストリの使用」を参照してください。

ストレージ

すべての Confluent Platform コンポーネントの動的永続ストレージには、AWS EBS、Azure Disk、GCE Disk、Ceph RBD、Portworx などブロックレベルのストレージソリューションを用意する必要があります。

ストレージの構成オプションの詳細については、「Confluent Platform のストレージの構成」を参照してください。

Kubernetes のセキュリティ

Kubernetes のロールベースアクセス制御（RBAC）と名前空間を使用して Confluent Platform をデプロイする場合、次の 2 通りの方法が考えられます。

• （推奨）ある特定の名前空間に属する Confluent Platform リソースのプロビジョニングと管理のアクセス権を Confluent for Kubernetes に与えます。
• Kubernetes クラスターのすべての名前空間にわたる Confluent Platform リソースのプロビジョニングと管理のアクセス権を Confluent for Kubernetes に与えます。

上記のどちらのオプションも、Kubernetes のロールバインディング構成が必要となります。詳細については、「Kubernetes RBAC およびカスタムリソース定義の構成」を参照してください。

Confluent のセキュリティ

セキュリティを徹底するために、Confluent では次のプロセスがサポートされます。

• 認証
• 認可
• ネットワーク暗号化
• 構成シークレット

本稼働環境のデプロイに関して、Confluent は次のセキュリティメカニズムを推奨しています。

• Kafka クライアントの認証方法として、次のいずれかを有効にします。

  • mTLS

  • SASL/PLAIN

  • LDAP による SASL/PLAIN

    SASL/PLAIN では、LDAP サーバーから ID を取得できます。

• 認可には Confluent のロールベースアクセス制御（RBAC）を有効にし、ユーザーとグループの ID は LDAP サーバーから取得します。

• Confluent Platform コンポーネント間の 内部トラフィックと、クライアントから Confluent Platform コンポーネントへの外部トラフィックの両方について、TLS によるネットワーク暗号化を有効にします。

これらのセキュリティ設定を構成するチュートリアルシナリオについては、「Production recommended secure setup」を参照してください。

ネットワーク

Confluent Platform コンポーネントには、ユーザーおよびクライアントアプリケーションが次のいずれかからアクセスできます。

• 内部 Kubernetes ネットワーク
• Kubernetes ネットワーク外部

Confluent Platform を外部に公開する場合の選択肢を次に示します。

• ロードバランサー
  • Kafka には、TLS パススルーをサポートするレイヤー 4 ロードバランサーが必要です。
  • HTTP エンドポイントを備えた他の Confluent コンポーネントには、レイヤー 4/7 ロードバランサーが必要です。
• Kubernetes ノードポート
• ホストベースまたはポートベースルーティングを使用した静的外部アクセス
• OpenShift ルート

Confluent for Kubernetes のデフォルトポート

CFK では、Confluent Platform コンポーネントに次のデフォルトポートが使用されます。デフォルトポートは、コンポーネントのカスタムリソースでオーバーライドできます。

• 7203: JMX ポート
• 7777: Jolokia ポート
• 7778: Prometheus ポート
• 8081: Schema Registry ポート
• 8082: Confluent REST Proxy ポート
• 8083: Connect ポート
• 8088: ksqlDB ポート
• 8090: MDS ポート
• 9021: Control Center ポート
• 9071: Kafka 内部ポート
• 9072: レプリケーションポート
• 9073: トークンポート
• 9092: Kafka 外部ポート

アップグレードとアップデート

CFK は、Kubernetes で Confluent Platform を実行するための、宣言型 API および構成の自動化を備えています。アップデートされた宣言型仕様をカスタムリソースファイルで適用して、構成をアップデートし、既存のデプロイのバージョンをアップグレードすることができます。

ただし、以下の構成シナリオは、既存のデプロイ向けに有効にすることも、変更することもできません。

• Confluent RBAC。既存のクラスターで Confluent RBAC を有効にすることはできません。
• TLS 証明書のメカニズム。自動生成された証明書と、ユーザーが提供した証明書の間で TLS 証明書が提供されるメカニズムは変更できません。
• TLS 暗号化。TLS が無効になっているクラスターで TLS 暗号化を有効にすることはできません。
• Kafka リスナー認証。既存の Kafka リスナーに使用される認証メカニズムは変更できません。
• Kafka ブローカー用の外部ネットワークアクセスのメカニズム。ロードバランサー、ノードポート、静的 Ingress コントローラーベースルーティングの間の Kafka ブローカー用の外部ネットワークアクセスのメカニズムは変更できません。
• 永続ストレージのストレージクラス。Confluent コンポーネントの永続ボリュームクレームの作成に使用されるストレージクラスは変更できません。
• 構成シークレットのメカニズム。Kubernetes シークレットとコンテナーのディレクトリパスを使用する構成シークレットのメカニズムは変更できません。

Kubernetes エコシステムのサポート

Confluent for Kubernetes （CFK）製品は、一連の Kubernetes コントローラーと、任意の Kubernetes で Confluent Platform の構成、デプロイ、さまざまな管理を自動化するビジネスロジックを備えています。

Confluent for Kubernetes （CFK）は標準的な Kubernetes API を採用しています。この Kubernetes API を呼び出し、Kubernetes API が本来の処理を実行すると想定します。CFK は、Kubernetes API の範囲を超える側面、たとえば Amazon LoadBalancer のようなベンダー実装や Amazon EBS のような StorageClass を管理しません。

以下の例では、CFK がサポートする範囲について説明します。

ストレージに関しては、Kubernetes API は StorageClass、PersistentVolume、PersistentVolumeClaim の API を実装し提供します。CFK が Kafka ブローカーを構成しデプロイする場合、ユーザー提供の StorageClass を使用し、Kafka ブローカーストレージの PersistentVolumeClaim を作成します。CFK は、ユーザー提供の StorageClass の中身についてはチェックも検証もしません。永続ボリュームが作成されているかを確認せず、その点についてはストレージベンダーの実装に依存しています。

ロードバランサーを使用したネットワーキングに関しては、Kubernetes API は ネットワークサービス および LoadBalancer の API を実装し提供します。CFK がロードバランサーを使用する Kafka を構成しデプロイする場合、Kafka ブローカーごとに 1 個ずつ、LoadBalancer タイプのサービスを作成します。その後の Kafka は、構成とデプロイの対象である実際の LoadBalancer インスタンスの LoadBalancer ベンダー実装に依存します。Amazon ELB、Google LB、Azure LB、MetalLB はすべて、このような LoadBalancer ベンダー実装の例です。

前述した範囲内で、CFK が Kubernetes API を適切な方法で呼び出し、適切な Kubernetes オブジェクトを作成しているかがテストされます。CFK のテストによって、LoadBalancer タイプのサービスが、Kafka ブローカーのカスタムリソースでユーザーが指定した構成で作成されていることを検証できます。CFK では、Google のロードバランサーが Kafka ブローカーにトラフィックを転送するように適切に構成およびデプロイされていることをテストしません。この点について、Confluent はロードバランサーの Google による実装に依存しています。

前述の内容を念頭に置き、CFK をデプロイする際は、本稼働環境で効率的かつ効果的に運用できるよう、以下のガイドラインに従ってください。

1. 使用するアーキテクチャ（Confluent コンポーネントおよび Kubernetes ランタイム）を特定し、自分の環境でのデプロイと管理の中核的な機能を検証する。
2. 自分のデプロイのランブックとトラブルシューティング手順を準備する。本稼働環境で運用を開始する前に、チーム全体でこのランブックを精査するようにしてください。
3. デプロイで発生した問題のサポートを受ける必要がある場合は、ベンダー各社を関与させ、アーキテクチャ全体に対応できるようにする。CFK デプロイでネットワーキングに関する問題が発生した場合は、Kubernetes のベンダーと、Confluent と併用しているネットワーキングサービスのベンダーを関与させるようにしてください。