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 ou hors de l'arbre ?
Avant l'introduction de l'interface CSI (Container Storage Interface), tous les plugins de volume étaient intégrés dans une arborescence, ce qui signifie qu'ils étaient créés, liés, compilés et livrés avec les fichiers binaires principaux de Kubernetes et étendaient l'API principale de Kubernetes. Cela signifiait que l'ajout d'un nouveau système de stockage à Kubernetes (un plug-in de volume) nécessitait d'archiver 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 de Kubernetes et sont déployés (installés) sur des clusters Kubernetes en tant qu'extensions. Cela donne aux fournisseurs la possibilité de mettre à jour les pilotes hors bande, c'est-à-dire séparément 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 Amazon Elastic Kubernetes Services (EKS) et les pilotes CSI 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, avec 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 de mettre en œuvre ces actions de gestion des volumes pour un back-end ou un protocole de stockage spécifique est fourni sous la forme d'un plug-in 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 Volume : AWS ElasticBlockStore
Pour utiliser le plug-in In-tree Volume sur les nœuds Windows, il est nécessaire d'en créer un supplémentaire StorageClass pour utiliser NTFS comme 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: <unset> MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: <none>
Pour créer le nouveau manifeste 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 provisionné dynamiquement à l'aide de PVC. Il s'agit d'une ressource du cluster, tout comme un nœud est une ressource de cluster. Cet objet d'API capture les détails de la mise en œuvre du stockage, qu'il s'agisse de NFS, d'iSCSI ou d'un système de stockage spécifique au fournisseur de cloud.
A 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 PersistentVolumes fonctionnalités 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 StorageClass une ressource.
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 VolumeMount configure 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 hors 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 de volumes dans Kubernetes. Les plugins CSI se composent généralement de plug-ins de nœud (qui s'exécutent sur chaque nœud en tant que tel DaemonSet) et de plugins de contrôleur.
Les plug-ins de nœuds CSI (en particulier ceux associés à des volumes persistants exposés en tant que périphériques en mode bloc ou via 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 plugins de nœuds CSI conteneurisés sont prises en charge à l'aide de csi-proxy
L'AMI Windows optimisée pour Amazon EKS est incluse à CSI-proxy partir d'avril 2022. Les clients peuvent utiliser le pilote CSI SMB
Le blog suivant
Amazon FSx for Windows File Server
Une option consiste à utiliser Amazon FSx pour Windows File Server via une fonctionnalité SMB appelée SMB Global Mapping,
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 '<html><body><br/><br/><marquee><H1>Hello EKS!!!<H1><marquee></body><html>' > C:\\inetpub\\wwwroot\\default.html; C:\\ServiceMonitor.exe 'w3svc'; " volumeMounts: - mountPath: C:\dotnetapp\app-state name: test-mount volumes: - name: test-mount hostPath: path: G:\Directory\app-state type: Directory nodeSelector: beta.kubernetes.io/os: windows beta.kubernetes.io/arch: amd64
Le blog suivant
