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 per volumi interno all'albero e uno esterno all'albero?
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 fuori banda, vale a dire separatamente dal ciclo di rilascio di Kubernetes. 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 https://docs.aws.amazon.com/eks/latest/userguide/storage.html
In-tree Volume Plugin per Windows
I volumi Kubernetes consentono di implementare applicazioni con requisiti di persistenza dei dati su Kubernetes. La gestione dei volumi persistenti è composta da provisioning/de: provisioning/resizing volumi, un volume, attaching/detaching un nodo Kubernetes e to/from un volume, singoli contenitori in un pod. mounting/dismounting 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 (Volume Plugins). In-tree Su Amazon Elastic Kubernetes Services (EKS), la seguente classe di plugin di volume Kubernetes è supportata su Windows:
In-tree Plugin di volume: aws ElasticBlockStore
Per utilizzare il plug-in di In-tree volume 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 ai livelli di qualità del servizio, alle politiche di backup o alle 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: <unset> MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: <none>
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 specifico del provider cloud.
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 collegatoC:\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 script e binari out-of-tree, generalmente 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
L'AMI Windows ottimizzata per Amazon EKS è inclusa CSI-proxy a partire da aprile 2022. I clienti possono utilizzare il driver CSI SMB
Il seguente blog
Amazon FSx per Windows File Server
Un'opzione consiste nell'utilizzare Amazon FSx for Windows File Server tramite una funzionalità SMB denominata SMB Global
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 '<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
Il seguente blog
