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 i volumi in-tree e out-of-tree?
Prima dell'introduzione della Container Storage Interface (CSI), tutti i plug-in di volume erano integrati nell'albero, il che significa che venivano creati, collegati, compilati e forniti con i binari principali di Kubernetes ed estendevano l'API di base 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 base di codice Kubernetes e vengono distribuiti (installati) sui cluster Kubernetes come estensioni. Ciò offre ai fornitori la possibilità di aggiornare i driver fuori banda, cioè separatamente dal ciclo di rilascio di Kubernetes. Ciò è in gran parte possibile perché Kubernetes ha creato un'interfaccia di archiviazione o CSI che fornisce 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 Plugin Volume per Windows
I volumi Kubernetes consentono di distribuire le applicazioni, con requisiti di persistenza dei dati, su Kubernetes. La gestione dei volumi persistenti è costituita 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 plug-in di volume Kubernetes (Volume Plugins). In-tree Su Amazon Elastic Kubernetes Services (EKS), la seguente classe di plug-in di volume Kubernetes è supportata su Windows:
In-tree Plugin di volume: aws ElasticBlockStore
Per utilizzare il plug-in In-tree del volume sui nodi Windows, è necessario crearne un aggiuntivo per StorageClass utilizzare NTFS come FSType. In EKS, l'impostazione predefinita StorageClass utilizza ext4 come FSType predefinito.
A StorageClass consente agli amministratori di descrivere le «classi» di archiviazione offerte. Le diverse classi possono corrispondere a livelli di qualità del servizio, politiche di backup o politiche arbitrarie determinate dagli amministratori del cluster. Kubernetes è indeciso 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 il nuovo file StorageClass che supporti NTFS, usa 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 seguente comando:
kubectl apply -f NTFSStorageClass.yaml
Il passaggio successivo consiste nel creare un Persistent Volume Claim (PVC).
A PersistentVolume (PV) è un elemento di storage nel cluster che è stato fornito da un amministratore o fornito dinamicamente tramite PVC. È una risorsa nel 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 di cloud.
A PersistentVolumeClaim (PVC) è una richiesta di archiviazione da parte di un utente. I reclami possono richiedere dimensioni e modalità di accesso specifiche (ad esempio, possono essere montati ReadWriteOnce ReadOnlyMany o ReadWriteMany).
Gli utenti hanno bisogno PersistentVolumes di attributi diversi, come le prestazioni, per diversi casi d'uso. Gli amministratori di cluster devono essere in grado di offrirne una varietà PersistentVolumes che si differenzia non solo per le dimensioni e le 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 dello spazio dei nomi.
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 dispositivo di archiviazione 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 di 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 contenitori 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 sono in genere costituiti da plug-in di nodo (che vengono eseguiti su ogni nodo come un) e plug-in di controller. DaemonSet
I plug-in dei nodi CSI (in particolare quelli associati a volumi persistenti esposti come dispositivi a blocchi o su un file system condiviso) devono eseguire varie operazioni privilegiate come la scansione dei dispositivi disco, il montaggio dei file system, ecc. Queste operazioni sono diverse 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 CSI-proxy per Amazon EKS include a partire da aprile 2022. I clienti possono utilizzare il driver SMB CSI
Il seguente blog
Amazon FSx per Windows File Server
Un'opzione è utilizzare Amazon FSx for Windows File Server tramite una funzionalità SMB chiamata SMB Global Mapping
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
