翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 永続的ストレージオプション
## ツリー内ボリュームプラグインとout-of-treeボリュームプラグインとは
Container Storage Interface (CSI) の導入前は、すべてのボリュームプラグインがツリー内にあり、コア Kubernetes バイナリで構築、リンク、コンパイル、出荷され、コア Kubernetes API を拡張していました。つまり、新しいストレージシステムを Kubernetes (ボリュームプラグイン) に追加するには、コア Kubernetes コードリポジトリにコードをチェックする必要があります。
Out-of-tree ボリュームプラグインは Kubernetes コードベースとは独立して開発され、拡張機能として Kubernetes クラスターにデプロイ (インストール) されます。これにより、ベンダーはドライバーをout-of-band、つまり Kubernetes リリースサイクルとは別に更新できます。これは、Kubernetes が k8 とやり取りする標準的な方法をベンダーに提供するストレージインターフェイスまたは CSI を作成しているため、ほとんどの場合可能です。
Amazon Elastic Kubernetes Services (EKS) ストレージクラスと CSI ドライバーの詳細については、https://docs.aws.amazon.com/eks/latest/userguide/storage.html を参照してください。
## Windows 用ツリー内ボリュームプラグイン
Kubernetes ボリュームを使用すると、データ永続性要件を持つアプリケーションを Kubernetes にデプロイできます。永続的ボリュームの管理は、ボリュームのプロビジョニング/プロビジョニング解除/サイズ変更、Kubernetes ノードへのボリュームのアタッチ/デタッチ、ポッド内の個々のコンテナへのボリュームのマウント/デタッチで構成されます。特定のストレージバックエンドまたはプロトコルに対してこれらのボリューム管理アクションを実装するためのコードは、Kubernetes ボリュームプラグイン **(ツリー内ボリュームプラグイン)** の形式で出荷されます。Amazon Elastic Kubernetes Services (EKS) では、次のクラスの Kubernetes ボリュームプラグインが Windows でサポートされています。
*ツリー内ボリュームプラグイン:* [awsElasticBlockStore](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)
Windows ノードでツリー内ボリュームプラグインを使用するには、NTFS を fsType として使用する追加の StorageClass を作成する必要があります。EKS では、デフォルトの StorageClass はデフォルトの fsType として ext4 を使用します。
StorageClass は、管理者が提供するストレージの「クラス」を記述する方法を提供します。異なるクラスは、クラスター管理者によって決定されるquality-of-serviceレベル、バックアップポリシー、または任意のポリシーにマッピングされる場合があります。Kubernetes は、クラスが表すものについては考えていません。この概念は、他のストレージシステムでは「プロファイル」と呼ばれることもあります。
これを確認するには、次のコマンドを実行します。
```
kubectl describe storageclass gp2
```
出力:
```
Name: gp2
IsDefaultClass: Yes
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClas
","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"name":"gp2"},"parameters":{"fsType"
"ext4","type":"gp2"},"provisioner":"kubernetes.io/aws-ebs","volumeBindingMode":"WaitForFirstConsumer"}
,storageclass.kubernetes.io/is-default-class=true
Provisioner: kubernetes.io/aws-ebs
Parameters: fsType=ext4,type=gp2
AllowVolumeExpansion:
MountOptions:
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events:
```
**NTFS** をサポートする新しい StorageClass を作成するには、次のマニフェストを使用します。
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: gp2-windows
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
fsType: ntfs
volumeBindingMode: WaitForFirstConsumer
```
次のコマンドを実行して StorageClass を作成します。
```
kubectl apply -f NTFSStorageClass.yaml
```
次のステップでは、永続ボリュームクレーム (PVC) を作成します。
PersistentVolume (PV) は、管理者によってプロビジョニングされたか、PVC を使用して動的にプロビジョニングされたクラスター内のストレージです。これは、ノードがクラスターリソースであるかのように、クラスター内のリソースです。この API オブジェクトは、NFS、iSCSI、またはcloud-provider-specificストレージシステムなど、ストレージの実装の詳細をキャプチャします。
PersistentVolumeClaim (PVC) は、ユーザーによるストレージのリクエストです。クレームは、特定のサイズとアクセスモードをリクエストできます (例えば、ReadWriteOnce、ReadOnlyMany、または ReadWriteMany をマウントできます）。
ユーザーには、さまざまなユースケースでパフォーマンスなどのさまざまな属性を持つ PersistentVolumes が必要です。クラスター管理者は、ユーザーがそれらのボリュームの実装方法の詳細を公開することなく、サイズやアクセスモードだけでなく、さまざまな方法で異なるさまざまな PersistentVolumes を提供できる必要があります。これらのニーズには、StorageClass リソースがあります。
以下の例では、名前空間ウィンドウ内に PVC が作成されています。
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-windows-pv-claim
namespace: windows
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2-windows
resources:
requests:
storage: 1Gi
```
次のコマンドを実行して PVC を作成します。
```
kubectl apply -f persistent-volume-claim.yaml
```
次のマニフェストは Windows Pod を作成し、VolumeMount を として設定`C:\Data`し、 のアタッチされたストレージとして PVC を使用します`C:\Data`。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: windows-server-ltsc2019
namespace: windows
spec:
selector:
matchLabels:
app: windows-server-ltsc2019
tier: backend
track: stable
replicas: 1
template:
metadata:
labels:
app: windows-server-ltsc2019
tier: backend
track: stable
spec:
containers:
- name: windows-server-ltsc2019
image: mcr.microsoft.com/windows/servercore:ltsc2019
ports:
- name: http
containerPort: 80
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: "C:\\data"
name: test-volume
volumes:
- name: test-volume
persistentVolumeClaim:
claimName: ebs-windows-pv-claim
nodeSelector:
kubernetes.io/os: windows
node.kubernetes.io/windows-build: '10.0.17763'
```
PowerShell 経由で Windows ポッドにアクセスして結果をテストします。
```
kubectl exec -it podname powershell -n windows
```
Windows Pod 内で、以下を実行します。 `ls`
出力:
```
PS C:\> ls
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/8/2021 1:54 PM data
d----- 3/8/2021 3:37 PM inetpub
d-r--- 1/9/2021 7:26 AM Program Files
d----- 1/9/2021 7:18 AM Program Files (x86)
d-r--- 1/9/2021 7:28 AM Users
d----- 3/8/2021 3:36 PM var
d----- 3/8/2021 3:36 PM Windows
-a---- 12/7/2019 4:20 AM 5510 License.txt
```
**データディレクトリ**は EBS ボリュームによって提供されます。
## Windows Out-of-tree
CSI プラグインに関連付けられたコードは、通常コンテナイメージとして配布され、DaemonSets や StatefulSets などの標準 Kubernetes コンストラクトを使用してデプロイされるout-of-treeスクリプトおよびバイナリとして出荷されます。 StatefulSets CSI プラグインは、Kubernetes で幅広いボリューム管理アクションを処理します。CSI プラグインは通常、ノードプラグイン (各ノードで DaemonSet として実行される) とコントローラープラグインで構成されます。
CSI ノードプラグイン (特にブロックデバイスまたは共有ファイルシステムを介して公開される永続的ボリュームに関連付けられているもの) は、ディスクデバイスのスキャン、ファイルシステムのマウントなど、さまざまな特権オペレーションを実行する必要があります。これらのオペレーションは、ホストオペレーティングシステムごとに異なります。Linux ワーカーノードの場合、コンテナ化された CSI ノードプラグインは通常、特権コンテナとしてデプロイされます。Windows ワーカーノードの場合、コンテナ化された CSI ノードプラグインの特権オペレーションは、各 Windows ノードにプリインストールする必要があるコミュニティ管理のスタンドアロンバイナリである [csi-proxy](https://github.com/kubernetes-csi/csi-proxy) を使用してサポートされます。
[Amazon EKS 最適化 Windows AMI ](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html)には、2022 年 4 月以降の CSI プロキシが含まれています。お客様は、Windows ノードで [SMB CSI ドライバー](https://github.com/kubernetes-csi/csi-driver-smb)を使用して、[Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/)、[Amazon FSx for NetApp ONTAP SMB 共有](https://aws.amazon.com/fsx/netapp-ontap/)、および/または [AWS Storage Gateway — File Gateway](https://aws.amazon.com/storagegateway/file/) にアクセスできます。
次の[ブログ](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/)では、Amazon FSx for Windows File Server を Windows Pod の永続ストレージとして使用するように SMB CSI ドライバーを設定する方法の実装の詳細について説明しています。
## Amazon FSx for Windows File Server
オプションとして、[SMB グローバルマッピング](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage)と呼ばれる SMB 機能を使用して Amazon FSx for Windows File Server を使用する方法があります。これにより、ホストに SMB 共有をマウントし、その共有のディレクトリをコンテナに渡すことができます。コンテナは、特定のサーバー、共有、ユーザー名、パスワードで設定する必要はありません。すべてホストで処理されます。コンテナは、ローカルストレージがある場合と同じように機能します。
SMB グローバルマッピングはオーケストレーターに対して透過的であり、HostPath を介してマウントされるため、**安全な懸念が生じる**可能性があります。
以下の例では、パス`G:\Directory\app-state`は Windows ノード上の SMB 共有です。
```
apiVersion: v1
kind: Pod
metadata:
name: test-fsx
spec:
containers:
- name: test-fsx
image: mcr.microsoft.com/windows/servercore:ltsc2019
command:
- powershell.exe
- -command
- "Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\\ServiceMonitor.exe'; echo '