Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Opzioni di archiviazione persistente
## Che cos'è un plug-in in-tree e un plug-in di out-of-tree volume?
Prima dell'introduzione della Container Storage Interface (CSI), tutti i plugin di volume erano integrati nell'albero, ossia erano creati, collegati, compilati e forniti con i binari principali di Kubernetes ed estendevano l'API principale di Kubernetes. Ciò significava che l'aggiunta di un nuovo sistema di storage a Kubernetes (un plug-in di volume) richiedeva il controllo del codice nel repository di codice principale di Kubernetes.
Out-of-tree i plugin di volume sono sviluppati indipendentemente dalla codebase di Kubernetes e vengono distribuiti (installati) nei cluster Kubernetes come estensioni. Ciò offre ai fornitori la possibilità di aggiornare i driver, vale a dire separatamente dal ciclo di rilascio di Kubernetes. out-of-band Ciò è in gran parte possibile perché Kubernetes ha creato un'interfaccia di archiviazione o CSI che offre ai fornitori un modo standard di interfacciarsi con k8s.
Puoi trovare ulteriori informazioni sulle classi di storage Amazon Elastic Kubernetes Services (EKS) e sui driver CSI su .html https://docs.aws.amazon.com/eks/ latest/userguide/storage
## Plugin In-tree Volume per Windows
I volumi Kubernetes consentono di distribuire applicazioni con requisiti di persistenza dei dati su Kubernetes. La gestione dei volumi persistenti consiste in singoli contenitori in un pod. provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node, and mounting/dismounting a volume to/from **Il codice per l'implementazione di queste azioni di gestione dei volumi per uno specifico back-end o protocollo di archiviazione viene fornito sotto forma di un plug-in di volume Kubernetes (In-tree Volume Plugins).** Su Amazon Elastic Kubernetes Services (EKS), la seguente classe di plugin di volume Kubernetes è supportata su Windows:
*[awsElasticBlockPlugin](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)* In-tree Volume: Store
Per utilizzare il plug-in di volume In-tree sui nodi Windows, è necessario crearne uno aggiuntivo StorageClass per utilizzare NTFS come fsType. Su EKS, l'impostazione predefinita StorageClass utilizza ext4 come FSType predefinito.
A StorageClass fornisce agli amministratori un modo per descrivere le «classi» di storage che offrono. Classi diverse potrebbero corrispondere a quality-of-service livelli, politiche di backup o politiche arbitrarie determinate dagli amministratori del cluster. Kubernetes non ha opinioni su cosa rappresentino le classi. Questo concetto viene talvolta chiamato «profili» in altri sistemi di storage.
È possibile verificarlo eseguendo il seguente comando:
```
kubectl describe storageclass gp2
```
Output:
```
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:
```
Per creare una nuova versione StorageClass che supporti **NTFS**, utilizzate il seguente manifesto:
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: gp2-windows
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
fsType: ntfs
volumeBindingMode: WaitForFirstConsumer
```
Createlo StorageClass eseguendo il comando seguente:
```
kubectl apply -f NTFSStorageClass.yaml
```
Il passaggio successivo consiste nel creare un Persistent Volume Claim (PVC).
Un PersistentVolume (PV) è una parte di storage nel cluster che è stata fornita da un amministratore o fornita dinamicamente utilizzando PVC. È una risorsa del cluster proprio come un nodo è una risorsa del cluster. Questo oggetto API acquisisce i dettagli dell'implementazione dello storage, che si tratti di NFS, iSCSI o di un sistema di storage. cloud-provider-specific
A PersistentVolumeClaim (PVC) è una richiesta di archiviazione da parte di un utente. I claim possono richiedere dimensioni e modalità di accesso specifiche (ad esempio, possono essere montati ReadWriteOnce ReadOnlyMany o ReadWriteMany).
Gli utenti devono disporre PersistentVolumes di attributi diversi, ad esempio le prestazioni, per diversi casi d'uso. Gli amministratori dei cluster devono essere in grado di offrire una varietà di soluzioni PersistentVolumes che si differenziano non solo in termini di dimensioni e modalità di accesso, senza esporre gli utenti ai dettagli di come tali volumi vengono implementati. Per queste esigenze, c'è la StorageClass risorsa.
Nell'esempio seguente, il PVC è stato creato all'interno delle finestre del namespace.
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-windows-pv-claim
namespace: windows
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2-windows
resources:
requests:
storage: 1Gi
```
Create il PVC eseguendo il seguente comando:
```
kubectl apply -f persistent-volume-claim.yaml
```
Il seguente manifesto crea un Windows Pod, configura l' VolumeMount as `C:\Data` e utilizza il PVC come storage collegato`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'
```
Verifica i risultati accedendo al pod Windows tramite PowerShell:
```
kubectl exec -it podname powershell -n windows
```
All'interno del Windows Pod, esegui: `ls`
Output:
```
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
```
La **directory dei dati** è fornita dal volume EBS.
## Out-of-tree per Windows
Il codice associato ai plugin CSI viene fornito come out-of-tree script e file binari che in genere vengono distribuiti come immagini di container e distribuiti utilizzando costrutti Kubernetes standard come e. DaemonSets StatefulSets I plugin CSI gestiscono un'ampia gamma di azioni di gestione dei volumi in Kubernetes. I plugin CSI in genere sono costituiti da plug-in di nodo (che vengono eseguiti su ciascun nodo come plug-in di controllo) e plug-in di controllo. DaemonSet
I plugin dei nodi CSI (specialmente quelli associati a volumi persistenti esposti come dispositivi a blocchi o su un file system condiviso) devono eseguire diverse operazioni privilegiate come la scansione dei dispositivi a disco, il montaggio di file system, ecc. Queste operazioni differiscono per ogni sistema operativo host. Per i nodi di lavoro Linux, i plug-in dei nodi CSI containerizzati vengono in genere distribuiti come contenitori privilegiati. Per i nodi di lavoro Windows, le operazioni privilegiate per i plug-in dei nodi CSI containerizzati sono supportate utilizzando [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), un file binario autonomo gestito dalla comunità che deve essere preinstallato su ogni nodo Windows.
[L'AMI Windows ottimizzata per Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) include il proxy CSI a partire da aprile 2022. I clienti possono utilizzare il [driver CSI SMB](https://github.com/kubernetes-csi/csi-driver-smb) sui nodi Windows per accedere ad Amazon for [Windows File Server, Amazon FSx FSx for NetApp ](https://aws.amazon.com/fsx/windows/) [ONTAP SMB Shares](https://aws.amazon.com/fsx/netapp-ontap/), and/or [AWS Storage Gateway — File Gateway](https://aws.amazon.com/storagegateway/file/).
Il seguente [blog](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/) contiene dettagli di implementazione su come configurare SMB CSI Driver per utilizzare Amazon FSx for Windows File Server come storage persistente per Windows Pods.
## File server Amazon FSx per Windows
Un'opzione consiste nell'utilizzare Amazon FSx for Windows File Server tramite una funzionalità SMB denominata [SMB Global Mapping](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage) che consente di montare una condivisione SMB sull'host, quindi trasferire le directory di tale condivisione in un contenitore. Il contenitore non deve essere configurato con un server, una condivisione, un nome utente o una password specifici: tutto viene invece gestito sull'host. Il contenitore funzionerà come se avesse una memoria locale.
**La mappatura globale SMB è trasparente per l'orchestratore ed è montata, il HostPath che può implicare problemi di sicurezza.**
Nell'esempio seguente, il percorso `G:\Directory\app-state` è una condivisione SMB sul nodo 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 '