はじめに
みなさん、こんにちは。
AWS EKS をマルチテナント（チームごとに Namespace で分離）で運用していると、チーム（Namespace）をまたいで Pod 間でファイルを受け渡したい場面が出てきます。こうしたケースでは、共有ストレージとして Amazon EFS やS3を選択肢にしやすいです。
本記事では EKS + EFS の検証結果をもとに、EFS CSI Driver の動的/静的プロビジョニングの考え方と、複数 Namespace が同一の共有領域を利用する際の設計ポイントを整理します。
具体的には、次の2点を扱います。
-
プロビジョニングは 動的？ 静的？
-
ファイルの 排他制御 はどう設計する？
※1 本記事の「マルチテナント」は「1クラスターを複数チームが共有し、Namespaceで分離する」構成を指します。
※2 本記事の「テナント横断共有」は「複数Namespaceが同一の共有領域（同一ディレクトリ）を利用する」ケースを指します。
※3 EFS CSI Driver の導入手順や Access Point の基礎は既存記事が豊富なため、本記事では詳細を省略します。
プロビジョニングは動的？静的？
結論から言うと、チーム（Namespace）をまたいで同じストレージ領域（同一ディレクトリ）を共有したいなら、静的プロビジョニングが扱いやすいです。
EFS CSI Driver の動的プロビジョニングは、PVC 作成をトリガーに EFS Access Point を自動作成し、さらに PV ごとに専用ディレクトリを割り当てます。Access Point はコンテナに見せるルートディレクトリを強制できるため、結果として「PVごとに見える範囲が分離される」方向の設計になります。
一方、テナント横断共有では「複数Namespaceから同一ディレクトリを共同利用したい」ことが多く、ここが動的プロビジョニングの仕様（分離）と噛み合いにくいポイントとなっています。
このため、横断共有を要件にする場合は、共有用の入口（Access Point や共有パス）を固定し、各 Namespace から同じ共有領域へ到達できる形（静的寄り）に寄せる方がシンプルになります。
（言葉だけだと伝わりづらいので、動的/静的のイメージ図を貼ります。）
ファイルの排他制御はどうする？
テナント横断共有では、複数 Pod が同じファイルを処理対象として二重処理(重複実行処理)してしまう可能性があります。EFS(NFS)はファイル共有ができる一方で、ファイル操作の担当決めや重複排除といった"ワークフロー寄りの排他"は提供しないため、アプリケーション側での設計が前提になります。
二重処理の対策としては、特定のコマンドに成功(例えばrename)したPodがファイルをほかのディレクトリに移動して実行する方式がシンプルです。この対策で複数Podが同じファイルを取り合う状況を減らせます。
(下図のようなイメージです)
一方で、同一ファイルを同時更新する要件がある場合はfcntl ロックなどの Advisory Lock(協調ロック)を併用します。この場合は、ロック順序の固定・タイムアウト・リトライ・処理中断時の回収まで含めて設計するのが重要です。
※補足：EFSのNFS v4.1ではshare deny(share reservation)をサポートしないため、強制排他(mandatory)を活用した設計は取りづらいです。強制排他をサポートしないことは下記の公式ドキュメントに記載されています。
https://docs.aws.amazon.com/ja_jp/efs/latest/ug/features.html#consistency
まとめ
今回は、EKS + EFS 構成で マルチテナント横断共有を行う際の Tips を整理しました。
-
横断共有（複数 Namespace で同一ディレクトリ利用）の要件は静的プロビジョニングが扱いやすい
-
排他制御はアプリ側で設計を考える
AI 開発などのトレンドもあり、Kubernetes 上で共有ストレージを利用するステートフルワークロードが今後増えるかもしれません。本記事が何かの一助になれば幸いです。
参考文献
-
EFS CSI Driver
https://github.com/kubernetes-sigs/aws-efs-csi-driver/ -
Amazon EFS
https://aws.amazon.com/efs/