Amazon EFS CSI ドライバー - Amazon EKS

Amazon EFS CSI ドライバー

Amazon EFS コンテナストレージインターフェイス (CSI) ドライバーは、Amazon EKS クラスターがファイルシステムの Amazon EFS ボリュームのライフサイクルを管理できるようにする CSI インターフェイスを提供します。

このトピックでは、Amazon EFS CSI ドライバーを Amazon EKS クラスターにデプロイし、動作することを確認する方法を示します。

注記

このドライバーは、Kubernetes バージョン 1.14 以降の Amazon EKS クラスターおよびワーカーノードでサポートされています。Fargate では、ドライバはサポートされていません。Amazon EFS CSI ドライバーのアルファ機能は、Amazon EKS クラスターではサポートされていません。このドライバーはベータリリースです。本番稼働用に Amazon EKS によって十分にテストされ、サポートされています。ドライバーのサポートは削除されませんが、詳細は変更される可能性があります。ドライバーのスキーマまたはセマンティクスが変更された場合は、次のバージョンへの移行手順が提供されます。

使用可能なパラメータの詳細と、ドライバーの機能を示す完全な例については、GitHub の Amazon EFS コンテナストレージインターフェイス (CSI) ドライバープロジェクトを参照してください。

Amazon EFS CSI ドライバーを Amazon EKS クラスターにデプロイするには

  • 次のコマンドを使用して Amazon EFS CSI ドライバーをデプロイします。

    注記

    このコマンドには kubectl バージョン 1.14 以降が必要です。kubectl のバージョンは、以下のコマンドを使用して確認できます。kubectl バージョンをインストールまたはアップグレードするには、「kubectl のインストール」を参照してください。 

    kubectl version --client --short
    kubectl apply -k "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"
    注記

    前のコマンドは、ポッド仕様で TLS のマウントオプションをサポートしていないバージョン 0.3.0 のドライバーをデプロイします。

Amazon EKS クラスターの Amazon EFS ファイルシステムを作成するには

  1. Amazon EKS クラスターの VPC ID を見つけます。この ID は Amazon EKS コンソールで確認するか、次の AWS CLI コマンドを使用できます。

    aws eks describe-cluster --name cluster_name --query "cluster.resourcesVpcConfig.vpcId" --output text

    出力:

    vpc-exampledb76d3e813

  2. クラスターの VPC の CIDR 範囲を見つけます。これは Amazon VPC コンソールで確認するか、次の AWS CLI コマンドを使用できます。

    aws ec2 describe-vpcs --vpc-ids vpc-exampledb76d3e813 --query "Vpcs[].CidrBlock" --output text

    出力:

    192.168.0.0/16

  3. Amazon EFS マウントポイントのインバウンド NFS トラフィックを許可するセキュリティグループを作成します。

    1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

    2. 左のナビゲーションペインで [セキュリティグループ]、[セキュリティグループの作成] の順に選択します。

    3. セキュリティグループの名前と説明を入力し、Amazon EKS クラスターが使用している VPC を選択します。

    4. [作成]、[閉じる] の順に選択して終了します。

  4. VPC CIDR 範囲からのインバウンド NFS トラフィックを許可するルールをセキュリティグループに追加します。

    1. 前のステップで作成したセキュリティグループを選択します。

    2. [インバウンドルール] タブを選択してから、[ルールの編集] を選択します。

    3. [ルールの追加] を選択し、以下のフィールドに入力して、[Save rules (ルールの保存)] を選択します。

      • [タイプ]: NFS

      • [ソース]: カスタムVPC CIDR 範囲を貼り付けます。

      • [説明]:「VPC 内からのインバウンド NFS トラフィックを許可する」などの説明を追加します。

  5. Amazon EKS クラスターに Amazon EFS ファイルシステムを作成します。

    1. Amazon Elastic File System コンソール (https://console.aws.amazon.com/efs/) を開きます。

    2. [Create file system] を選択します。

    3. [Configure file system access (ファイルシステムアクセスの設定)] ページで、Amazon EKS クラスターが使用している VPC を選択します。

    4. [セキュリティグループ] で、前のセクションで作成したセキュリティグループを各マウントターゲットに追加し [次のステップ] を選択します。

    5. ファイルシステムのオプション設定を行い、[次のステップ] および [ファイルシステムの作成] を選択して終了します。

      重要

      デフォルトでは、新しい Amazon EFS ファイルシステムは root:root によって所有され、root ユーザー (UID 0) のみが読み取り/書き込み/実行のアクセス許可があります。コンテナが root として実行されていない場合は、Amazon EFS ファイルシステムのアクセス許可を変更して、他のユーザーがファイルシステムを変更できるようにする必要があります。詳細については、『Amazon Elastic File System ユーザーガイド』の「ネットワークファイルシステム (NFS) レベルでのユーザー、グループ、アクセス許可の使用」を参照してください 。

サンプルアプリケーションをデプロイし、CSI ドライバーが動作していることを確認するには

この手順では、Amazon EFS コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリの Multiple Pods Read Write Many の例を使用して、静的にプロビジョニングされた Amazon EFS 永続ボリュームを使用し、ReadWriteMany アクセスモードで複数のポッドからアクセスします。

  1. Amazon EFS コンテナストレージインターフェイス (CSI) ドライバー GitHub リポジトリをローカルシステムにクローンします。 

    git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git

  2. multiple_pods サンプルディレクトリに移動します。 

    cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/

  3. Amazon EFS ファイルシステム ID を取得します。これは Amazon EFS コンソールで確認するか、次の AWS CLI コマンドを使用します。

    aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text

    出力:

    fs-582a03f3

  4. specs/pv.yaml ファイルを編集し、volumeHandle 値を Amazon EFS ファイルシステム ID に置き換えます。 

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-582a03f3
    注記

    Amazon EFS は伸縮自在なファイルシステムであるため、ファイルシステムの容量制限は強制されません。永続ボリュームと永続ボリュームクレームの実際のストレージ容量の値は、ファイルシステムを作成するときには使用されません。ただし、ストレージ容量は Kubernetes の必須フィールドであるため、この例では 5Gi などの有効な値を指定する必要があります。この値は、Amazon EFS ファイルシステムのサイズを制限しません。

  5. specs ディレクトリから、efs-sc ストレージクラス、efs-claim 永続ボリュームクレーム、efs-pv 永続ボリューム、app1 および app2 サンプルアプリケーションをデプロイします。 

    kubectl apply -f specs/

  6. デフォルトの名前空間のポッドを監視し、app1 および app2 ポッドが準備されるまで待ちます。 

    kubectl get pods --watch

  7. デフォルトの名前空間の永続的ボリュームを一覧表示します。default/efs-claim クレームがある永続的なボリュームを探します。 

    kubectl get pv

    出力:

    NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Bound    default/efs-claim   efs-sc                  2m50s

  8. 永続的ボリュームの詳細を表示します。

    kubectl describe pv efs-pv

    出力:

    Name:            efs-pv
Labels:          <none>
Annotations:     kubectl.kubernetes.io/last-applied-configuration:
                   {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"name":"efs-pv"},"spec":{"accessModes":["ReadWriteMany"],"capaci...
                 pv.kubernetes.io/bound-by-controller: yes
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    efs-sc
Status:          Bound
Claim:           default/efs-claim
Reclaim Policy:  Retain
Access Modes:    RWX
VolumeMode:      Filesystem
Capacity:        5Gi
Node Affinity:   <none>
Message:
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            efs.csi.aws.com
    VolumeHandle:      fs-582a03f3
    ReadOnly:          false
    VolumeAttributes:  <none>
Events:                <none>

    Amazon EFS ファイルシステム ID は VolumeHandle として表示されます。

  9. app1 ポッドがボリュームにデータを正常に書き込んでいることを確認します。 

    kubectl exec -ti app1 -- tail /data/out1.txt

    出力:

    Wed Sep 18 20:30:48 UTC 2019
Wed Sep 18 20:30:53 UTC 2019
Wed Sep 18 20:30:58 UTC 2019
Wed Sep 18 20:31:03 UTC 2019
Wed Sep 18 20:31:08 UTC 2019
Wed Sep 18 20:31:13 UTC 2019

  10. app2 ポッドがボリューム内に同じデータを表示していることを確認します。 

    kubectl exec -ti app2 -- tail /data/out1.txt

    出力:

    Wed Sep 18 20:30:48 UTC 2019
Wed Sep 18 20:30:53 UTC 2019
Wed Sep 18 20:30:58 UTC 2019
Wed Sep 18 20:31:03 UTC 2019
Wed Sep 18 20:31:08 UTC 2019
Wed Sep 18 20:31:13 UTC 2019

  11. 実験が終了したら、このサンプルアプリケーションのリソースを削除してクリーンアップします。

    kubectl delete -f specs/