AWSでPVCをセットアップしたいのですが、アクセスモードとしてReadWriteMany
が必要です。残念ながら、EBSはReadWriteOnce
のみをサポートしています。
どうすればこれを解決できますか?
ReadWriteMany
をサポートするAWS EFSのベータプロバイダーがあることを確認しましたが、前述のように、これはまだベータ版であり、そのインストールは多少不安定に見えます。ReadWriteOnce
のままにすることができますが、これによりスケーラビリティが制限されます。これを解決する方法は他にありますか?基本的に、必要なのは、互いに独立しているポッド間でデータを共有する永続的な方法でデータを保存する方法です。
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オペレーター もあり、すでにいくつかの安定したリリースがあるようです。
affinity
とnode selector
を使用したEBSボリュームはスケーラビリティを停止しますが、EBSを使用した場合のみReadWriteOnce
が機能します。
私の経験を共有すると、ファイルシステムで多くの操作を実行し、ファイルを頻繁にプッシュおよびフェッチする場合、EFS
によって遅くなり、アプリケーションのパフォーマンスが低下する可能性があります。 EFSの操作速度が遅い。
ただし、EBSボリュームをプロビジョニングするためにGlusterFs
を使用できます。 GlusterFS
はReadWriteMany
もサポートしており、ブロックストレージ(SSD)であるため、EFS
に比べて高速です。