Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Optionen für persistenten Speicher
Was ist ein In-Tree- oder Out-of-Tree-Volume-Plugin?
Vor der Einführung des Container Storage Interface (CSI) waren alle Volume-Plugins in-tree, d. h. sie wurden mit den wichtigsten Kubernetes-Binärdateien erstellt, verknüpft, kompiliert und ausgeliefert und erweitern die zentrale Kubernetes-API. Das bedeutete, dass das Hinzufügen eines neuen Speichersystems zu Kubernetes (ein Volume-Plugin) das Einchecken von Code in das zentrale Kubernetes-Code-Repository erforderte.
Out-of-tree Volume-Plugins werden unabhängig von der Kubernetes-Codebasis entwickelt und als Erweiterungen auf Kubernetes-Clustern bereitgestellt (installiert). Dies gibt Anbietern die Möglichkeit, Treiber Out-of-Band zu aktualisieren, d. h. getrennt vom Kubernetes-Veröffentlichungszyklus. Dies ist größtenteils möglich, da Kubernetes eine Speicherschnittstelle (CSI) entwickelt hat, die Anbietern eine Standardmethode für die Schnittstelle zu k8s bietet.
Weitere Informationen zu den Speicherklassen und CSI-Treibern von Amazon Elastic Kubernetes Services (EKS) finden Sie unter https://docs.aws.amazon.com/eks/latest/userguide/storage.html
In-tree Volumen-Plugin für Windows
Kubernetes-Volumes ermöglichen die Bereitstellung von Anwendungen mit Anforderungen an die Datenpersistenz auf Kubernetes. Die Verwaltung persistenter Volumes besteht aus provisioning/de — provisioning/resizing aus Volumes, attaching/detaching einem Volume als Kubernetes-Knoten und to/from einem Volume aus einzelnen Containern in mounting/dismounting einem Pod. to/from Der Code für die Implementierung dieser Volume-Management-Aktionen für ein bestimmtes Speicher-Back-End oder -Protokoll wird in Form eines Kubernetes-Volume-Plugins (Volume Plugins) geliefert. In-tree In Amazon Elastic Kubernetes Services (EKS) wird die folgende Klasse von Kubernetes-Volume-Plugins unter Windows unterstützt:
In-tree Volumen-Plugin: aws ElasticBlockStore
Um das In-tree Volume-Plugin auf Windows-Knoten verwenden zu können, ist es notwendig, ein zusätzliches zu erstellen, StorageClass um NTFS als FSType zu verwenden. Auf EKS StorageClass verwendet die Standardeinstellung ext4 als Standard-FSType.
A StorageClass bietet Administratoren die Möglichkeit, die von ihnen angebotenen „Speicherklassen“ zu beschreiben. Verschiedene Klassen können Servicequalitätsstufen, Backup-Richtlinien oder beliebigen Richtlinien zugeordnet werden, die von den Cluster-Administratoren festgelegt werden. Kubernetes ist unvoreingenommen darüber, wofür Klassen stehen. Dieses Konzept wird in anderen Speichersystemen manchmal als „Profile“ bezeichnet.
Sie können es überprüfen, indem Sie den folgenden Befehl ausführen:
kubectl describe storageclass gp2
Ausgabe:
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>
Verwenden Sie das folgende Manifest StorageClass , um das neue Programm zur Unterstützung von NTFS zu erstellen:
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gp2-windows provisioner: kubernetes.io/aws-ebs parameters: type: gp2 fsType: ntfs volumeBindingMode: WaitForFirstConsumer
Erstellen Sie das, StorageClass indem Sie den folgenden Befehl ausführen:
kubectl apply -f NTFSStorageClass.yaml
Der nächste Schritt besteht darin, einen Persistent Volume Claim (PVC) zu erstellen.
A PersistentVolume (PV) ist ein Speicherelement im Cluster, das von einem Administrator oder dynamisch mithilfe von PVC bereitgestellt wurde. Es ist eine Ressource im Cluster, genau wie ein Knoten eine Cluster-Ressource ist. Dieses API-Objekt erfasst die Details der Speicherimplementierung, sei es NFS, iSCSI oder ein für den Cloud-Anbieter spezifisches Speichersystem.
A PersistentVolumeClaim (PVC) ist eine Speicheranfrage eines Benutzers. Bei Ansprüchen können bestimmte Größen und Zugriffsmodi angefordert werden (z. B. können sie gemountet ReadWriteOnce werden ReadOnlyMany oder ReadWriteMany).
Benutzer benötigen PersistentVolumes unterschiedliche Eigenschaften, wie z. B. Leistung, für unterschiedliche Anwendungsfälle. Cluster-Administratoren müssen in der Lage sein, eine Vielzahl davon anzubieten PersistentVolumes , die sich nicht nur in Bezug auf Größe und Zugriffsmodi unterscheiden, ohne die Benutzer mit den Einzelheiten der Implementierung dieser Volumes vertraut zu machen. Für diese Bedürfnisse gibt es die richtige StorageClass Ressource.
Im folgenden Beispiel wurde das PVC innerhalb der Namespace-Fenster erstellt.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ebs-windows-pv-claim namespace: windows spec: accessModes: - ReadWriteOnce storageClassName: gp2-windows resources: requests: storage: 1Gi
Erstellen Sie den PVC, indem Sie den folgenden Befehl ausführen:
kubectl apply -f persistent-volume-claim.yaml
Das folgende Manifest erstellt einen Windows-Pod, richtet den VolumeMount als ein C:\Data und verwendet den PC als angeschlossenen SpeicherC:\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'
Testen Sie die Ergebnisse, indem Sie auf den Windows-Pod zugreifen über PowerShell:
kubectl exec -it podname powershell -n windows
Führen Sie im Windows Pod Folgendes aus: ls
Ausgabe:
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
Das Datenverzeichnis wird vom EBS-Volume bereitgestellt.
Out-of-tree für Windows
Code, der mit CSI-Plug-ins verknüpft ist, wird als Out-of-Tree-Skripte und Binärdateien geliefert, die in der Regel als Container-Images verteilt und mithilfe von Kubernetes-Standardkonstrukten wie und bereitgestellt werden. DaemonSets StatefulSets CSI-Plugins übernehmen eine Vielzahl von Aktionen zur Volume-Verwaltung in Kubernetes. CSI-Plugins bestehen in der Regel aus Node-Plugins (die auf jedem Knoten als A ausgeführt werden DaemonSet) und Controller-Plugins.
CSI-Knoten-Plugins (insbesondere solche, die mit persistenten Volumes verknüpft sind, die entweder als Blockgeräte oder über ein gemeinsam genutztes Dateisystem verfügbar sind) müssen verschiedene privilegierte Operationen wie das Scannen von Festplattengeräten, das Mounten von Dateisystemen usw. ausführen. Diese Operationen sind für jedes Host-Betriebssystem unterschiedlich. Für Linux-Worker-Knoten werden containerisierte CSI-Knoten-Plugins in der Regel als privilegierte Container bereitgestellt. Für Windows-Worker-Knoten werden privilegierte Operationen für containerisierte CSI-Knoten-Plugins mithilfe von csi-proxy unterstützt
Das Amazon EKS-optimierte Windows-AMI umfasst ab April 2022. CSI-proxy Kunden können den SMB-CSI-Treiber
Der folgende Blog
Amazon FSx für Windows File Server
Eine Option besteht darin, Amazon FSx for Windows File Server über eine SMB-Funktion namens SMB Global Mapping zu verwenden,
Im folgenden Beispiel G:\Directory\app-state ist der Pfad eine SMB-Freigabe auf dem Windows Node.
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
Der folgende Blog
