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 などのコンポーネントごとに異なるストレージクラスの指定ができます。
定義済みのストレージクラスを使用するには、次の手順に従います。
Kubernetes クラスターで使用する定義済み StorageClass を作成または使用します。
ストレージクラスには、次の設定が第一に推奨されます。
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
特に本稼働環境のデプロイでは、この設定が必要となります。
allowVolumeExpansion: true
既存の StorageClass を使用しないで新たに作成する場合は、Kubernetes クラスターにおいて StorageClass を作成および変更できるアクセス許可が必要です。
詳細および例については、Kubernetes のストレージクラス を参照してください。
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 コンポーネントに使用するには、次の手順に従います。
ローカルプロビジョニング用に、Kubernetes に StorageClass を作成します。以下に例を示します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: my-storage-class provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer
必要な各ワーカーノードについて、必要なホストパスとホスト名ラベルを使用して、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
storageClass をコンポーネントの CR に追加します。たとえば、次のようにします。
spec: storageClass: name: my-storage-class
新しい 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
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 ブローカーにストレージバケットへの適切なアクセス許可があることを確認する必要があります。以下のいずれかのオプションを使用します。
-
これが推奨されるオプションです。
Kubernetes シークレット
- サービスアカウントを使用してストレージバケットへのアクセス権を 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.backend
をS3
に設定します。[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.backend
をGCS
に設定します。[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