web-dev-qa-db-ja.com

AWSでのReadWriteManyを使用したKubernetes PVC

AWSでPVCをセットアップしたいのですが、アクセスモードとしてReadWriteManyが必要です。残念ながら、EBSはReadWriteOnceのみをサポートしています。

どうすればこれを解決できますか?

  • ReadWriteManyをサポートするAWS EFSのベータプロバイダーがあることを確認しましたが、前述のように、これはまだベータ版であり、そのインストールは多少不安定に見えます。
  • ノードアフィニティを使用して、EBSボリュームに依存するすべてのポッドを1つのノードに強制し、ReadWriteOnceのままにすることができますが、これによりスケーラビリティが制限されます。

これを解決する方法は他にありますか?基本的に、必要なのは、互いに独立しているポッド間でデータを共有する永続的な方法でデータを保存する方法です。

11
Golo Roden

自動プロビジョニングなしのEFSの使用

EFSプロビジョナーはベータ版である可能性がありますが、EFS自体はそうではありません。 EFSボリュームはNFSを介してマウントできるため、NFSボリュームソースを使用してPersistentVolumeを手動で作成できます-自動プロビジョニングがあなたの側で難しい要件ではないと仮定すると:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-efs-volume
spec:
  capacity:
    storage: 100Gi # Doesn't really matter, as EFS does not enforce it anyway
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  mountOptions:
    - hard
    - nfsvers=4.1
    - rsize=1048576
    - wsize=1048576
    - timeo=600
    - retrans=2
  nfs:
    path: /
    server: fs-XXXXXXXX.efs.eu-central-1.amazonaws.com

次に、PersistentVolumeClaimを使用してこのボリュームを要求し、通常どおりポッド(または複数のポッド)で使用できます。

代替ソリューション

自動プロビジョニングが難しい要件である場合は、別の解決策を検討してください。KubernetesやAWSの上にReadWriteManyストレージを提供する、クラスター上に展開できる分散ファイルシステムがいくつかあります。たとえば、 Rook (基本的にはCephのKubernetes演算子です)を見てみましょう。また、正式にはまだプレリリース段階にありますが、私はすでに少し作業しており、かなりうまく動作しています。 GlusterFSオペレーター もあり、すでにいくつかの安定したリリースがあるようです。

10
helmbert

affinitynode selectorを使用したEBSボリュームはスケーラビリティを停止しますが、EBSを使用した場合のみReadWriteOnceが機能します。

私の経験を共有すると、ファイルシステムで多くの操作を実行し、ファイルを頻繁にプッシュおよびフェッチする場合、EFSによって遅くなり、アプリケーションのパフォーマンスが低下する可能性があります。 EFSの操作速度が遅い。

ただし、EBSボリュームをプロビジョニングするためにGlusterFsを使用できます。 GlusterFSReadWriteManyもサポートしており、ブロックストレージ(SSD)であるため、EFSに比べて高速です。

0
Harsh Manvar