Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Options de stockage permanent
## Qu'est-ce qu'un plugin de volume intégré à l'arbre par rapport à un plugin de volume extérieur à l'arbre ?
Avant l'introduction de l'interface de stockage de conteneurs (CSI), tous les plugins de volume étaient intégrés à l'arborescence, ce qui signifie qu'ils étaient créés, liés, compilés et livrés avec les principaux binaires Kubernetes et étendaient l'API Kubernetes principale. Cela signifiait que l'ajout d'un nouveau système de stockage à Kubernetes (un plugin de volume) nécessitait de vérifier le code dans le référentiel de code principal de Kubernetes.
Out-of-tree les plugins de volume sont développés indépendamment de la base de code Kubernetes et sont déployés (installés) sur les clusters Kubernetes en tant qu'extensions. Cela permet aux fournisseurs de mettre à jour les pilotes hors bande, c'est-à-dire indépendamment du cycle de publication de Kubernetes. Cela est largement possible car Kubernetes a créé une interface de stockage ou CSI qui fournit aux fournisseurs un moyen standard d'interfaçage avec k8s.
Vous pouvez en savoir plus sur les classes de stockage et les pilotes CSI d'Amazon Elastic Kubernetes Services (EKS) sur https://docs.aws.amazon.com/eks/latest/userguide/storage.html
## In-tree Plug-in Volume pour Windows
Les volumes Kubernetes permettent de déployer des applications présentant des exigences de persistance des données sur Kubernetes. La gestion des volumes persistants comprend provisioning/de : provisioning/resizing des volumes, attaching/detaching un volume to/from , un nœud Kubernetes et mounting/dismounting un volume, des conteneurs to/from individuels dans un pod. Le code permettant d'implémenter ces actions de gestion des volumes pour un backend ou un protocole de stockage spécifique est fourni sous la forme d'un plugin de volume Kubernetes **(Volume Plugins) In-tree **. Sur Amazon Elastic Kubernetes Services (EKS), la classe suivante de plug-ins de volume Kubernetes est prise en charge sous Windows :
*In-tree Plug-in de volume :* [aws ElasticBlockStore](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)
Pour utiliser le plugin de In-tree volume sur les nœuds Windows, il est nécessaire d'en créer un supplémentaire StorageClass pour utiliser NTFS en tant que FSType. Sur EKS, la valeur par défaut StorageClass utilise ext4 comme FSType par défaut.
A StorageClass permet aux administrateurs de décrire les « classes » de stockage qu'ils proposent. Les différentes classes peuvent correspondre à des niveaux de qualité de service, à des politiques de sauvegarde ou à des politiques arbitraires déterminées par les administrateurs du cluster. Kubernetes n'a aucune opinion quant à ce que représentent les classes. Ce concept est parfois appelé « profils » dans d'autres systèmes de stockage.
Vous pouvez le vérifier en exécutant la commande suivante :
```
kubectl describe storageclass gp2
```
Sortie :
```
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:
```
Pour créer le nouveau fichier StorageClass compatible avec **NTFS**, utilisez le manifeste suivant :
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: gp2-windows
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
fsType: ntfs
volumeBindingMode: WaitForFirstConsumer
```
Créez le StorageClass en exécutant la commande suivante :
```
kubectl apply -f NTFSStorageClass.yaml
```
L'étape suivante consiste à créer une réclamation de volume persistante (PVC).
Un PersistentVolume (PV) est un élément de stockage du cluster qui a été provisionné par un administrateur ou approvisionné dynamiquement à l'aide de PVC. Il s'agit d'une ressource du cluster, tout comme un nœud est une ressource du cluster. Cet objet API capture les détails de la mise en œuvre du stockage, qu'il s'agisse d'un système NFS, iSCSI ou d'un système de stockage spécifique à un fournisseur de cloud.
Un PersistentVolumeClaim (PVC) est une demande de stockage par un utilisateur. Les réclamations peuvent demander une taille et des modes d'accès spécifiques (par exemple, elles peuvent être montées ReadWriteOnce ReadOnlyMany ou ReadWriteMany).
Les utilisateurs ont besoin PersistentVolumes de différents attributs, tels que les performances, pour différents cas d'utilisation. Les administrateurs de clusters doivent être en mesure de proposer une variété de solutions PersistentVolumes qui ne se limitent pas à la taille et aux modes d'accès, sans exposer les utilisateurs aux détails de la mise en œuvre de ces volumes. Pour répondre à ces besoins, il existe des StorageClass ressources.
Dans l'exemple ci-dessous, le PVC a été créé dans les fenêtres de l'espace de noms.
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-windows-pv-claim
namespace: windows
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2-windows
resources:
requests:
storage: 1Gi
```
Créez le PVC en exécutant la commande suivante :
```
kubectl apply -f persistent-volume-claim.yaml
```
Le manifeste suivant crée un Windows Pod, le configure en VolumeMount tant que `C:\Data` et utilise le PVC comme espace de stockage attaché`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'
```
Testez les résultats en accédant au module Windows via PowerShell :
```
kubectl exec -it podname powershell -n windows
```
Dans le Windows Pod, exécutez : `ls`
Sortie :
```
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
```
Le **répertoire de données** est fourni par le volume EBS.
## Out-of-tree pour Windows
Le code associé aux plugins CSI est livré sous forme de scripts et de fichiers binaires sortis de l'arborescence qui sont généralement distribués sous forme d'images de conteneur et déployés à l'aide de constructions Kubernetes standard telles que et. DaemonSets StatefulSets Les plugins CSI gèrent un large éventail d'actions de gestion des volumes dans Kubernetes. Les plugins CSI se composent généralement de plugins de nœud (qui s'exécutent sur chaque nœud en tant que DaemonSet) et de plugins de contrôleur.
Les plug-ins de nœuds CSI (en particulier ceux associés à des volumes persistants exposés sous forme de périphériques en mode bloc ou sur un système de fichiers partagé) doivent effectuer diverses opérations privilégiées, telles que l'analyse des périphériques de disque, le montage de systèmes de fichiers, etc. Ces opérations sont différentes pour chaque système d'exploitation hôte. Pour les nœuds de travail Linux, les plugins de nœuds CSI conteneurisés sont généralement déployés en tant que conteneurs privilégiés. Pour les nœuds de travail Windows, les opérations privilégiées pour les plug-ins de nœuds CSI conteneurisés sont prises en charge à l'aide de [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), un binaire autonome géré par la communauté qui doit être préinstallé sur chaque nœud Windows.
[L'AMI Windows optimisée Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) est incluse CSI-proxy à partir d'avril 2022. Les clients peuvent utiliser le [pilote CSI SMB](https://github.com/kubernetes-csi/csi-driver-smb) sur les nœuds Windows pour accéder à [Amazon FSx for Windows File Server, Amazon FSx NetApp for](https://aws.amazon.com/fsx/windows/) [ONTAP SMB Shares et AWS and/or [Storage](https://aws.amazon.com/storagegateway/file/) Gateway —](https://aws.amazon.com/fsx/netapp-ontap/) File Gateway.
Le [blog](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/) suivant contient des informations d'implémentation sur la façon de configurer le pilote SMB CSI pour utiliser Amazon FSx for Windows File Server comme stockage persistant pour les modules Windows.
## Amazon FSx for Windows File Server
Une option consiste à utiliser Amazon FSx for Windows File Server via une fonctionnalité SMB [appelée SMB Global](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage) Mapping, qui permet de monter un partage SMB sur l'hôte, puis de transmettre les répertoires de ce partage dans un conteneur. Le conteneur n'a pas besoin d'être configuré avec un serveur, un partage, un nom d'utilisateur ou un mot de passe spécifiques. Tout cela est géré sur l'hôte. Le conteneur fonctionnera de la même manière que s'il était entreposé localement.
Le mappage global des PME est transparent pour l'orchestrateur et il est monté, HostPath ce qui peut **impliquer des problèmes de sécurité**.
Dans l'exemple ci-dessous, le chemin `G:\Directory\app-state` est un partage SMB sur le nœud Windows.
```
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 '