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.
Persistente Speicheroptionen
Was ist ein In-Tree- oder Out-of-Tree-Volume-Plugin?
Vor der Einführung des Container Storage Interface (CSI) befanden sich alle Volume-Plugins in der Baumstruktur, was bedeutet, dass sie mit den Kern-Binärdateien von Kubernetes erstellt, verknüpft, kompiliert und ausgeliefert wurden und die Kern-Kubernetes-API erweitern. Das bedeutete, dass für das Hinzufügen eines neuen Speichersystems zu Kubernetes (ein Volume-Plugin) der Code in das Code-Repository von Kubernetes eingecheckt werden musste.
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, d. h. getrennt vom Kubernetes-Release-Zyklus, zu aktualisieren. Dies ist weitgehend möglich, da Kubernetes eine Speicherschnittstelle oder CSI entwickelt hat, die Anbietern eine Standardschnittstelle mit 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 Volumes, einem Volume, attaching/detaching einem Kubernetes-Knoten und to/from einem Volume provisioning/de — provisioning/resizing einzelnen Containern in mounting/dismounting einem Pod. to/from Der Code für die Implementierung dieser Volume-Management-Aktionen für ein bestimmtes Speicher-Backend oder ein bestimmtes Speicherprotokoll wird in Form eines Kubernetes-Volume-Plug-ins (Volume Plugins) ausgeliefert. In-tree Auf Amazon Elastic Kubernetes Services (EKS) werden die folgenden Klassen von Kubernetes-Volume-Plug-ins 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 Modul 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, von den Clusteradministratoren festgelegten Richtlinien zugeordnet werden. Kubernetes hat keine Meinung 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 zu erstellen, das NTFS unterstützt:
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.
Ein PersistentVolume (PV) ist ein Speicherelement im Cluster, das von einem Administrator oder dynamisch mithilfe von PVC bereitgestellt wurde. Es ist eine Ressource im Cluster, genauso wie ein Knoten eine Clusterressource ist. Dieses API-Objekt erfasst die Details der Implementierung des Speichers, sei es NFS, iSCSI oder ein Cloud-Provider-spezifisches Speichersystem.
A PersistentVolumeClaim (PVC) ist eine Speicheranforderung durch einen Benutzer. Für Ansprüche können bestimmte Größen und Zugriffsmodi angefordert werden (z. B. können sie montiert ReadWriteOnce werden ReadOnlyMany oder ReadWriteMany).
Benutzer benötigen PersistentVolumes unterschiedliche Eigenschaften, wie z. B. Leistung, für unterschiedliche Anwendungsfälle. Clusteradministratoren müssen in der Lage sein, eine Vielzahl von Optionen 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 entsprechende 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 das PVC, indem Sie den folgenden Befehl ausführen:
kubectl apply -f persistent-volume-claim.yaml
Das folgende Manifest erstellt einen Windows-Pod, richtet das VolumeMount AS ein C:\Data und verwendet das PVC 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 wie folgt auf den Windows-Pod zugreifen 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 ausgeliefert, die normalerweise als Container-Images verteilt und mithilfe von Kubernetes-Standardkonstrukten wie und bereitgestellt werden. DaemonSets StatefulSets CSI-Plugins verarbeiten eine Vielzahl von Volume-Management-Aktionen in Kubernetes. CSI-Plugins bestehen in der Regel aus Node-Plugins (die auf jedem Knoten als solches ausgeführt werden DaemonSet) und Controller-Plugins.
CSI-Knoten-Plugins (insbesondere solche, die sich auf persistente Volumes beziehen, 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 unterscheiden sich je nach Host-Betriebssystem. 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
Das Amazon EKS Optimized Windows AMI umfasst CSI-proxy ab April 2022. 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
Im folgenden Beispiel G:\Directory\app-state ist der Pfad eine SMB-Freigabe auf dem Windows-Knoten.
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
