Confluent Platform のストレージの構成

概要

Confluent for Kubernetes (CFK)はほとんどの Confluent Platform コンポーネントについて、Kubernetes ストレージクラスを使用した永続ストレージボリュームのプロビジョニングをサポートしています。

Connect と Schema Registry では、永続ストレージボリュームが使用されないため、ストレージクラスを指定する必要はありません。

Kafka

Confluent for Kubernetes は、次のストレージオプションで Kafka をプロビジョニングできます。

  • 永続ストレージボリューム

    Kafka には、ブロックレベルのストレージソリューションが必要となります。以下はその例です。

    • AWS EBS
    • Azure ディスク
    • GCE ディスク
    • Ceph RBD
    • Portworx
  • Tiered Storage

    Confluent は Tiered Storage に関して、さまざまなオブジェクトストレージソリューションをサポートしています。以下はその例です。

    • AWS S3
    • GCP GCS
    • Pure Storage
    • FlashBlade

ZooKeeper

ZooKeeper には、Kafka と同じ永続ストレージボリュームソリューションが使用されます。

その他の Confluent コンポーネント

Confluent コンポーネントには、それぞれ永続ストレージボリュームを 1 つ構成する必要があります。サービスの存続期間中、各コンポーネントはそれを使用して作業中の状態を維持します。

また、Confluent コンポーネントで永続的な共有ストレージが必要となる場合には Kafka が利用されます。たとえば、Schema Registry は Kafka にスキーマを格納し、また Confluent Control Center は操作の状態やメトリクスを Kafka に格納します。

永続ストレージボリューム

ストレージクラスの構成は、Confluent for Kubernetes (CFK)の構成プロセスの中で最も重要なステップの 1 つです。

永続ストレージボリュームを使用するように Confluent コンポーネントを構成するときは、次のオプションがサポートされます。

  • 動的プロビジョニング: 定義済みの Kubernetes ストレージクラスを使用
  • 動的プロビジョニング: Kubernetes のデフォルトのストレージクラスを使用
  • カスタムプロビジョニング: プロビジョニング済みの永続ストレージボリュームを使用

CFK ではデフォルトで、ストレージ管理に Kubernetes が提供する動的ストレージプロビジョニングが使用されています。

Confluent for Kubernetes では、ストレージクラス間での移行はサポートされていません。

定義済みの Kubernetes StorageClass を使用した動的プロビジョニング

Confluent Platform 全体で使用するストレージクラスの指定、または ZooKeeper、Kafka、ksqlDB、Control Center などのコンポーネントごとに異なるストレージクラスの指定ができます。

定義済みのストレージクラスを使用するには、次の手順に従います。

  1. Kubernetes クラスターで使用する定義済み StorageClass を作成または使用します。

    ストレージクラスには、次の設定が第一に推奨されます。

    • volumeBindingMode: WaitForFirstConsumer

    • reclaimPolicy: Retain

      特に本稼働環境のデプロイでは、この設定が必要となります。

    • allowVolumeExpansion: true

    既存の StorageClass を使用しないで新たに作成する場合は、Kubernetes クラスターにおいて StorageClass を作成および変更できるアクセス許可が必要です。

    詳細および例については、Kubernetes のストレージクラス を参照してください。

  2. Confluent コンポーネントのカスタムリソース(CR)に、使用する StorageClass の名前を指定します。

    spec:
      storageClass:
        name: my-storage-class
    

本稼働環境でストレージクラスを作成するシナリオ例については、『Create a Production Storage Class on GKE』を参照してください。

デフォルトの Kubernetes StorageClass を使用した動的プロビジョニング

バージョン 1.11 以降の Kubernetes では、デフォルト StorageClass のサポートがデフォルトで有効になっています。CR で spec.storageClass を指定しなかった場合は、デフォルトのストレージクラスが CFK によって使用されます。

次のコマンドを使用して、現在のデフォルトストレージクラスの名前を取得します。

kubectl get sc

Kubernetes のデフォルトストレージクラスを使用するには、デフォルト StorageClass で次のプロパティが設定されていることを確認してください。

  • volumeBindingMode: WaitForFirstConsumer

  • reclaimPolicy: Retain

    特に本稼働環境のデプロイでは、この設定が必要となります。

  • allowVolumeExpansion: true

重要

デフォルト StorageClass を本稼働環境で使用することは推奨されません。

静的にプロビジョニングされた永続ボリュームの使用

CFK はデフォルトで、Kubernetes の動的ストレージプロビジョニングを利用してディスク管理を自動化します。Kubernetes クラスターが動的プロビジョニングをサポートしない場合には、このセクションの手順に従って、静的にプロビジョニングされたディスクを Confluent Platform のデプロイに使用することができます。

Connect と Schema Registry では、永続ストレージボリュームが使用されないため、このセクションの手順は必要ありません。

静的にプロビジョニングされた永続ボリュームを Confluent Platform コンポーネントに使用するには、次の手順に従います。

  1. ローカルプロビジョニング用に、Kubernetes に StorageClass を作成します。以下に例を示します。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: my-storage-class
    provisioner: kubernetes.io/no-provisioner
    volumeBindingMode: WaitForFirstConsumer
    
  2. 必要な各ワーカーノードについて、必要なホストパスとホスト名ラベルを使用して、PersistentVolumes を作成します。

    Confluent Platform コンポーネントには以下の数の永続ボリュームが必要です。

    • 各 ZooKeeper ホストに 2 つの永続ボリューム
    • Kafka、ksqlDB、Confluent Control Center の各ホストに 1 つの永続ボリューム

    以下に例を示します。

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv-1                                                --- [1]
    spec:
      capacity:
        storage: 10Gi                                           --- [2]
      volumeMode: Filesystem
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain                     --- [3]
      storageClassName: my-storage-class                        --- [4]
      local:
         path: /mnt/data/broker-1-data                          --- [5]
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - gke-myhost-cluster-default-pool-5cc13882-k0gb  --- [6]
    
    • [1] PersistentVolume の名前を選択します。

    • [2] 各 Kafka ブローカーインスタンスについて、必要なストレージ以上のストレージサイズを選択します。これは、コンポーネントの CR の spec.dataVolumeCapacity プロパティと一致します。

    • [3] CFK によって最終的に作成され、Kubernetes によって結果的にこの PersistentVolume とバインドされるデータを、PersitentVolumeClaim の削除後も保持する場合は Retain を選択します。

      PersistentVolumeClaim が削除される際にこのデータをガベージコレクションの対象にする場合は、Delete を選択します。

      重要

      With persistentVolumeReclaimPolicy: Delete, your data on the volume will be deleted when you delete the pod and consequently its persistent volume.

    • [4] storageClassName は、ステップ 1 で作成したものと一致している必要があります。

    • [5] これが、永続的なデータボリュームとしてブローカーのワーカーノード上で使用するディレクトリパスです。このパスはワーカーノード上に存在する必要があります。

    • [6] これが、このブローカーインスタンスのホストとして使用するワーカーノードの kubernetes.io/hostname ラベルの値です。このホスト名を見つけるには、以下のコマンドを実行します。

      kubectl get nodes \
        -o 'custom-columns=NAME:metadata.name,HOSTNAME:metadata.labels.kubernetes\.io/hostname'
      
      NAME                                           HOSTNAME
      gke-myhost-cluster-default-pool-5cc13882-k0gb   gke-myhost-cluster-default-pool-5cc13882-k0gb
      gke-myhost-cluster-default-pool-5cc13882-n8vr   gke-myhost-cluster-default-pool-5cc13882-n8vr
      gke-myhost-cluster-default-pool-5cc13882-tbbj   gke-myhost-cluster-default-pool-5cc13882-tbbj
      
  3. storageClass をコンポーネントの CR に追加します。たとえば、次のようにします。

    spec:
      storageClass:
        name: my-storage-class
    
  4. 新しい CR をデプロイ後、PersistentVolumes がバインドされていることを確認します。

    kubectl get pv
    
    NAME  CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM                   STORAGECLASS
    pv-1  10Gi     RWO          Retain         Bound  operator/data0-kafka-0  my-storage-class
    pv-2  10Gi     RWO          Retain         Bound  operator/data0-kafka-2  my-storage-class
    pv-3  10Gi     RWO          Retain         Bound  operator/data0-kafka-1  my-storage-class
    
  5. Confluent Platform ポッドが正常であることを確認します。以下に例を示します。

    kubectl get pods -l app=kafka
    
    NAME      READY   STATUS    RESTARTS   AGE
    kafka-0   1/1     Running   0          40m
    kafka-1   1/1     Running   0          40m
    kafka-2   1/1     Running   0          40m
    

Tiered Storage

Confluent for Kubernetes を使用して 階層型ストレージ を有効にすることができます。Confluent は、さまざまなオブジェクトストレージソリューションをサポートしています。以下はその例です。

  • AWS S3
  • GCP GCS
  • Pure Storage
  • FlashBlade

Tiered Storage の有効化

Tiered Storage を有効にする場合は、Kafka で以下を構成する必要があります。

  • 使用する Blob ストレージの種類。

  • 使用するストレージバケットの名前。

    このバケットはあらかじめ作成しておく必要があります。このバケットがユーザーに代わって CFK によって作成されることはありません。

また、Kafka ブローカーにストレージバケットへの適切なアクセス許可があることを確認する必要があります。以下のいずれかのオプションを使用します。

サービスアカウントを使用してストレージバケットへのアクセス権を Kafka ブローカーに与える

クラウド IAM へのアクセス許可を、Kafka ブローカーポッドに関連付けられている Kubernetes ServiceAccount にマッピングします。

AWS には、AWS IAM へのアクセス許可を EKS の ServiceAccount にネイティブで関連付ける機能が用意されています。

同様に、GCP には、IAM へのアクセス許可を GKE の ServiceAccount にネイティブでマップする機能が用意されています。

適切なバケットのアクセス許可は、Kafka のデプロイ先となる Kubernetes 名前空間のデフォルトの ServiceAccount にマップできます。または、別個の ServiceAccount にマップし、CFK を使用して Kafka ブローカーポッドがその ServiceAccount と関連付けられていることを確認することもできます。このアプローチの主な利点は、Confluent Platform を CFK からデプロイする際に、バケットにアクセスするための機密の認証情報を具体的に管理する必要がないことです。

EKS におけるサービスアカウントの AWS IAM ロールへの関連付けについては、「サービスアカウントの IAM ロール」を参照してください。

GKE におけるサービスアカウントの GCP IAM ロールへの関連付けについては、「Workload Identity の使用」を参照してください。

CFK によって管理されている Confluent Platform コンポーネントと関連付ける Kubernetes サービスアカウントの構成については、「Confluent Cloud を使用した Kafka Connect と ksqlDB の構成」を参照してください。

Kubernetes シークレットオブジェクトを使用してストレージバケットへのアクセス権を Kafka ブローカーに与える

AWS または GCP の認証情報をシークレットオブジェクトに格納し、CFK で Kafka をデプロイする際にそのオブジェクト内の認証情報を使用するように Kafka を構成します。

ストレージの認証情報が変わったときは、Kafka クラスターを再起動する必要があります。

上記の必須設定に加えて、他の Tiered Storage 設定を kafka セクションの configOverrides を使用して構成できます。可能な設定については、「階層型ストレージ」を参照してください。

Kafka クラスターが削除されると、CFK による Tiered Storage バケットのコンテンツに対するガベージコレクションは行われません。設定間隔だけ待機するか、Tiered Storage バケットでオブジェクトを手動で削除します。詳細については、「トピック削除の間隔」を参照してください。

AWS S3 用の Tiered Storage の構成

AWS S3 で Tiered Storage を有効にして構成するには、Kafka の CR で、次の構成オーバーライドを設定する必要があります。

spec:
  configOverrides:
    server:
      - confluent.tier.feature=true                ----- [1]
      - confluent.tier.enable=true                 ----- [2]
      - confluent.tier.backend=S3                  ----- [3]
      - confluent.tier.s3.bucket=                  ----- [4]
      - confluent.tier.s3.region=                  ----- [5]
      - confluent.tier.s3.cred.file.path=          ----- [6]
      - confluent.tier.topic.delete.check.interval.ms -- [7]

  mountedSecrets:                                  ----- [8]
    - secretRef:
  • [1] confluent.tier.feature=true と設定して、Tiered Storage を有効にします。

  • [2] confluent.tier.enable を、作成されたトピックのデフォルト値に指定します。true に設定すると、未圧縮のトピックがすべて階層型になります。

  • [3] confluent.tier.backendS3 に設定します。

  • [4] confluent.tier.s3.bucket を、使用する S3 バケットに設定します。

  • [5] confluent.tier.s3.region をリージョンに設定します。

  • [6](省略可)|tiered| の認証情報の提供にシークレットを使用する場合は、confluent.tier.s3.cred.file.path を指定します。サービスアカウントを使用する場合、このプロパティは不要です。

    シークレットのファイルに追加する必要のある内容については、「階層型ストレージ」を参照してください。

  • [7](省略可)``confluent.tier.topic.delete.check.interval.ms`` に、トピックまたはクラスターが削除されてからログセグメントファイルが削除されるまでの間隔を設定します。デフォルト値は 3 時間です。

  • [8](省略可)|tiered| の認証情報の提供にシークレットを使用する場合に限って必要です。

以下に例を示します。

spec:
  configOverrides:
    server:
      - confluent.tier.feature=true
      - confluent.tier.enable=true
      - confluent.tier.backend=S3
      - confluent.tier.s3.bucket=my-bucket
      - confluent.tier.s3.region=us-west-2
      - confluent.tier.s3.cred.file.path=/mnt/secrets/my-secret-aws/aws/creds

  mountedSecrets:
    - secretRef: my-secret-aws

GCS の Tiered Storage の構成

GCS で Tiered Storage を有効にして構成するには、Kafka の CR で、次の構成オーバーライドを設定する必要があります。

spec:
  configOverrides:
    server:
      - confluent.tier.feature=true                ----- [1]
      - confluent.tier.enable=true                 ----- [2]
      - confluent.tier.backend=GCS                 ----- [3]
      - confluent.tier.gcs.bucket=                 ----- [4]
      - confluent.tier.gcs.region=                 ----- [5]
      - confluent.tier.gcs.cred.file.path=         ----- [6]
      - confluent.tier.topic.delete.check.interval.ms -- [7]

  mountedSecrets:                                  ----- [8]
    - secretRef:
  • [1] confluent.tier.feature=true と設定して、Tiered Storage を有効にします。

  • [2] confluent.tier.enable を、作成されたトピックのデフォルト値に指定します。true に設定すると、未圧縮のトピックがすべて階層型になります。

  • [3] confluent.tier.backendGCS に設定します。

  • [4] confluent.tier.gcs.bucket を、使用する GCS バケットに設定します。

  • [5] confluent.tier.gcs.region を GCS リージョンに設定します。

  • [6](省略可)|tiered| 用にシークレットを使用する場合は、confluent.tier.gcs.cred.file.path を指定します。サービスアカウントを使用する場合、このプロパティは不要です。

    シークレットのファイルに追加する必要のある内容については、「/platform/current/」を参照してください。

  • [7](省略可)``confluent.tier.topic.delete.check.interval.ms`` に、トピックまたはクラスターが削除されてからログセグメントファイルが削除されるまでの間隔を設定します。デフォルト値は 3 時間です。

  • [8](省略可)|tiered| の認証情報の提供にシークレットを使用する場合に限って必要です。

以下に例を示します。

specify:
  configOverrides:
    server:
      - confluent.tier.feature=true
      - confluent.tier.enable=true
      - confluent.tier.backend=GCS
      - confluent.tier.gcs.bucket=my-bucket
      - confluent.tier.gcs.region=us-central1
      - confluent.tier.gcs.cred.file.path=/mnt/secrets/my-secret-gcs/credentials

  mountedSecrets:
  - secretRef: my-secret-gcs