1. Home
  2. Confluent for Kubernetes

Confluent Operator インストールの計画

このトピックでは、Confluent Operator を使用した Confluent Platform のインストールおよびデプロイを計画する際に検討すべき前提条件や推奨事項について説明します。

このトピックでは、プロバイダー環境の例として Google Kubernetes Engine（GKE）を使用します。このトピックを参考に、Operator と Confluent Platform を他の サポートされるプロバイダー環境 にデプロイしてください。

このガイドの例では、以下が想定されています。

  • $VALUES_FILE は「グローバル構成ファイルの作成」でセットアップする構成ファイルのことです。

  • Operator ドキュメントで簡潔で明快な例を提示できるよう、すべての構成パラメーターが構成ファイル（ $VALUES_FILE ）に指定されます。ただし、本稼働環境でのデプロイにおいて、Helm を使用して機密データを扱う場合には、--set または --set-file オプションを使用します。以下に例を示します。

    helm upgrade --install kafka \
 --set kafka.services.mds.ldap.authentication.simple.principal="cn=mds\,dc=test\,dc=com" \
 --set kafka.services.mds.ldap.authentication.simple.credentials=”Developer!” \
 --set kafka.enabled=true
    Copy

  • operator は Confluent Platform のデプロイ先となる名前空間です。

  • コマンドはすべて、Confluent Operator のダウンロード先ディレクトリにある helm ディレクトリで実行されます。

全般的な前提条件

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

  • Kubernetes クラスターが サポートされる環境 のいずれかに準拠している。
  • クラスターサイズが「サイズ設定の推奨事項」に基づいている。
  • kubectl がインストールされ、初期化され、コンテキストが設定済みである。使用するクラスター用に構成済みの kubeconfig ファイルも必要です。
  • Helm 3 がインストールされている。
  • Confluent Operator バンドルにアクセスできる。
  • ストレージ : StorageClass に基づく ストレージプロビジョナーがサポートされている。これが、使用されるデフォルトのストレージクラスです。ユーザーは、他のストレージクラスを用意して使用できます。永続ストレージ用に SSD または SSD に類するディスクが必要です。
  • セキュリティ : コンポーネントごとに TLS 証明書が必要です（TLS を使用する場合）。この例のステップでは、デフォルトの SASL/PLAIN セキュリティが使用されます。追加セキュリティの構成方法については、「Confluent Operator でのセキュリティの構成」を参照してください。
  • ネットワーク
    • DNS: デプロイ後の Confluent Platform コンポーネントへの外部アクセスには、使用プラットフォーム環境での DNS サポートが必要です。個々の Confluent Platform コンポーネントへの外部アクセスを有効にするには、デプロイ後に DNS エントリを作成します。開発テスト用の外部アクセスが組織から許可されない場合については、「非 DNS 開発アクセス」を参照してください。
    • ロードバランサーを使用した外部アクセス:
      • Kafka ブローカーには、パススルー（アプリケーションで終了）をサポートするレイヤー 4 ロードバランシングが必要です。
      • レイヤー 7 ロードバランシングは、Operator とその他すべての Confluent Platform コンポーネントで使用できます。
    • ホストベースまたはポートベースのルーティングを使用する静的外部アクセス: TLS パススルーをサポートし、TCP トラフィックをルーティングする、Ingress コントローラーが必要です。

サイズ設定の推奨事項

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

Kubernetes のワーカーノード数とコンピュートリソースに関する推奨事項

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

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

    Confluent では、ZooKeeper や Kafka を個別の Kubernetes ノードにある個別のポッドで実行することを推奨します。他のコンポーネントは "ビンパッキング" できます。ビンパッキングを使用すると、コンポーネントタスクは CPU キャパシティとメモリー容量の残りが最も少ないクラスターに属するノードに配置されます。ビンパッキングによってノードの使用率が最大化され、必要なノードの数が削減されます。

    ビンパッキングは、デフォルトでは名前空間レベルで無効になっています。ビンパッキングを有効にするには、構成ファイル（ $VALUES_FILE ）のコンポーネントセクションに oneReplicaPerNode: false パラメーターを設定します。

    oneReplicaPerNode は、名前空間レベルで非推奨の disableHostPort の代わりです。

    コンポーネントのビンパッキングは、本稼働環境へのデプロイでは 推奨されません。また、false に設定した場合、使用されるデフォルトポートが 28130 であることにもご注意ください。

  • 本稼働クラスター : グローバルプロバイダーファイル helm/providers/<provider>.yaml でデフォルトのキャパシティ値を確認します。指定されている値が本稼働アプリケーションに与える影響をふまえてノードを用意します。オンプレミスの システム要件 をもとにパブリック/プライベートクラウドの本稼働環境に何が必要かを判断することもできます。指定されているオンプレミスストレージ情報はクラウド環境には該当しないことにご注意ください。

    注釈

    アプリケーションに必要なノード数の判断に関する情報が必要な場合は、Confluent サポート までご相談ください。

Operator と Confluent Platform をデプロイするためのワークフロー

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

  1. 「全般的な前提条件」と「サイズ設定の推奨事項」を確認し、環境を用意します。
  2. Operator バンドルをダウンロード します。
  3. Kubernetes クラスターをクラスター管理者として準備します。
  4. ストレージ、 外部アクセス、 セキュリティ などを必要に応じて 構成 します。
  5. インストール します。

Kubernetes アクセス制御のための Operator デプロイのシナリオ

一般的には、Confluent Operator のデプロイプロセスに 3 名の担当者が関わっています。2 名は人間の担当者で、1 名は、次のようなサービスアカウントです。

  • Kubernetes クラスター管理者

    Kubernetes 管理者は、名前空間と、Confluent Operator ユーザーおよび Confluent Operator サービスアカウントの特定のアクセス許可をプロビジョンします。

  • Confluent Operator ユーザー

    Confluent Operator ユーザーは、Confluent Operator および Confluent Platform コンポーネントをデプロイします。

  • Confluent Operator サービスアカウント

    この Kubernetes サービスアカウントにより、Confluent Operator コンポーネントが Kubernetes API にアクセスし、Confluent Platform に必要な StatefulSets、Services、Secrets などを作成することができます。

Confluent Operator サービスアカウントに許可するアクセスのレベルを制御するために、そのスコープを 1 つの Kubernetes 名前空間に制限し、クラスターレベルのリソースのインストールを禁止することができます。

  • 名前空間によるデプロイ

    Operator サービスアカウントは、デプロイ先の名前空間内のリソースのみを管理します。

  • クラスターリソースの定義

    Operator サービスは、クラスタースコープの Kubernetes リソース（ストレージクラス、カスタムリソース定義、クラスターロール、クラスターロールバインディングなど）にアクセスすることなく動作できます。

以下の質問に答えることは、適切なデプロイシナリオを選択するために役立ちます。

  • Confluent Operator で、特定の名前空間内のみと、あらゆる名前空間内のどちらで Confluent Platform クラスターの作成と削除を行うのか。
  • Confluent Operator サービスアカウントがクラスターレベルのリソースを作成できるようにするのか、または、Kubernetes クラスター管理者がクラスターレベルのリソースを事前に作成するのか。

Confluent Operator を使用して Confluent Platform をデプロイするシナリオの選択肢は 4 つあります。

シナリオ 1:

Operator と Confluent Platform は、1 つの名前空間内でのみデプロイし、管理します。

Confluent Operator サービスアカウントには、クラスターレベルの Kubernetes リソースを管理する権限がありません。

シナリオ 2:

Operator と Confluent Platform は、1 つの名前空間内でのみデプロイし、管理します。

Confluent Operator サービスアカウントには、クラスターレベルの Kubernetes リソースを管理する権限があります。

シナリオ 3:

Operator と Confluent Platform を複数の名前空間内でデプロイし、管理します。

Confluent Operator サービスアカウントには、名前空間によっては、クラスターレベルの Kubernetes リソースを管理する権限がありません。

シナリオ 4（デフォルトオプション）:

Operator と Confluent Platform を、Kubernetes クラスター内の複数の名前空間でデプロイし、管理します。

Confluent Operator サービスアカウントには、すべての名前空間でクラスターレベルの Kubernetes リソースを管理する権限があります。

上で説明した各シナリオのワークフローの要約を、以下に示します。

シナリオ 1 のワークフロー

クラスターレベルの Kubernetes リソースを管理するアクセス許可のない Operator ユーザーが、1 つの名前空間で Operator をデプロイします。

Kubernetes クラスター管理者は、以下を実行します。

  1. Operator と Confluent Platform をデプロイする名前空間を作成します。

  2. 以下のコマンドを使用して CRD をインストールします。

    kubectl apply -f resources/rbac
    Copy

  3. Confluent Operator サービスアカウントのロールおよびロールバインディングを作成します。必要なロールおよびロールバインディングの詳細については、「名前空間を使用するデプロイに必要なアクセス許可の付与」を参照してください。

Operator ユーザーは、以下を実行します。

  1. Operator 構成ファイルを構成します。

    namespace: true
installClusterResources: false
    Copy

  2. Operator と Confluent Platform をデプロイします。

シナリオ 2 のワークフロー

クラスターレベルの Kubernetes リソースを管理するアクセス許可のある Operator ユーザーが、1 つの名前空間で Operator をデプロイします。

Operator ユーザーは、以下を実行します。

  1. Operator と Confluent Platform をデプロイする名前空間を作成します。

  2. Operator 構成ファイルを構成します。

    namespace: true
installClusterResources: true
    Copy

  3. Operator と Confluent Platform をデプロイします。

    このプロセスの間に Operator は、ロールとロールバインディングを自動的に作成し、Operator と Confluent Platform に必要な CRD を自動的にインストールします。

シナリオ 3 のワークフロー

クラスターレベルの Kubernetes リソースを管理するアクセス許可のない Operator ユーザーが、クラスター全体で Operator をデプロイします。

Kubernetes 管理者は、以下を実行します。

  1. Operator と Confluent Platform をデプロイする名前空間を作成します。

  2. 以下のコマンドを使用して CRD をインストールします。

    kubectl apply -f resources/rbac
    Copy

  3. Operator サービスアカウントのクラスターロールおよびクラスターロールバインディングを作成します。必要なクラスターロールおよびクラスターロールバインディングの詳細については、「名前空間を使用するデプロイに必要なアクセス許可の付与」を参照してください。

Operator ユーザーは、以下を実行します。

  1. Operator 構成ファイルを構成します。

    namespace: false
installClusterResources: false
    Copy

  2. Operator と Confluent Platform をデプロイします。

シナリオ 4 のワークフロー

クラスターレベルの Kubernetes リソースを管理するアクセス許可のない Operator ユーザーが、クラスター全体で Operator をデプロイします。

Operator ユーザーは、以下を実行します。

  1. Operator と Confluent Platform をデプロイする名前空間を作成します。

  2. Operator 構成ファイルを構成します。

    namespace: false
installClusterResources: true
    Copy

  3. Operator と Confluent Platform をデプロイします。

    このプロセスの間に Operator は、クラスターロールとクラスターロールバインディングを自動的に作成し、Operator と Confluent Platform に必要な CRD を自動的にインストールします。