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 ein out-of-tree Volume-Plugin?
Vor der Einführung des Container Storage Interface (CSI) befanden sich alle Volume-Plugins in der Baumstruktur, d. h. sie wurden mit den Kern-Binärdateien von Kubernetes erstellt, verknüpft, kompiliert und ausgeliefert und erweiterten die Kern-Kubernetes-API. Das bedeutete, dass für das Hinzufügen eines neuen Speichersystems zu Kubernetes (ein Volume-Plugin) 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 zu aktualisieren out-of-band, d. h. unabhängig vom Kubernetes-Release-Zyklus. Dies ist weitgehend möglich, da Kubernetes eine Speicherschnittstelle oder CSI entwickelt hat, die Anbietern eine Standardschnittstelle für K8s bietet.
Weitere Informationen zu den Speicherklassen und CSI-Treibern von Amazon Elastic Kubernetes Services (EKS) finden Sie unter .html https://docs.aws.amazon.com/eks/ latest/userguide/storage
## In-Tree-Volume-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 of volumes, attaching/detaching a volume to/from a Kubernetes node, and mounting/dismounting a volume to/from einzelnen Containern in einem Pod. Der Code für die Implementierung dieser Volume-Management-Aktionen für ein bestimmtes Speicher-Back-End oder ein bestimmtes Speicherprotokoll wird in Form eines Kubernetes-Volume-Plug-ins **(In-Tree Volume Plugins)** ausgeliefert. Auf Amazon Elastic Kubernetes Services (EKS) werden die folgenden Klassen von Kubernetes-Volume-Plug-ins unter Windows unterstützt:
[Volume-Plugin im Baum: *Store* awsElasticBlock](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)
Um das In-Tree Volume Plugin auf Windows-Knoten verwenden zu können, ist es notwendig, ein zusätzliches Plugin zu erstellen, um NTFS als FSType StorageClass 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 quality-of-service Ebenen, Backup-Richtlinien oder beliebigen Richtlinien zugeordnet werden, die von den Cluster-Administratoren festgelegt 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:
MountOptions:
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events:
```
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-specific 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 Speicher`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'
```
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 Standard-Kubernetes-Konstrukten 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](https://github.com/kubernetes-csi/csi-proxy) unterstützt, einer von der Community verwalteten, eigenständigen Binärdatei, die auf jedem Windows-Knoten vorinstalliert werden muss.
[Das Amazon EKS-optimierte Windows-AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) umfasst ab April 2022 CSI-Proxy. Kunden können den [SMB CSI-Treiber](https://github.com/kubernetes-csi/csi-driver-smb) auf Windows-Knoten verwenden, um auf [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/), [Amazon FSx for NetApp ONTAP SMB Shares](https://aws.amazon.com/fsx/netapp-ontap/) und and/or [AWS Storage Gateway — File Gateway](https://aws.amazon.com/storagegateway/file/) zuzugreifen.
Der folgende [Blog](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/) enthält Implementierungsdetails zur Einrichtung des SMB CSI-Treibers für die Verwendung von Amazon FSx for Windows File Server als persistenten Speicher für Windows Pods.
## Amazon FSx für Windows-Dateiserver
Eine Option besteht darin, Amazon FSx for Windows File Server über eine SMB-Funktion namens [SMB Global Mapping](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage) zu verwenden, die es ermöglicht, eine SMB-Freigabe auf dem Host zu mounten und dann Verzeichnisse auf dieser Freigabe an einen Container zu übergeben. Der Container muss nicht mit einem bestimmten Server, einer bestimmten Freigabe, einem Benutzernamen oder einem Passwort konfiguriert werden — das alles wird stattdessen auf dem Host abgewickelt. Der Container funktioniert genauso, als ob er lokalen Speicher hätte.
Das SMB Global Mapping ist für den Orchestrator transparent und wird über diesen bereitgestellt, HostPath was **Sicherheitsbedenken nach sich ziehen** kann.
Im folgenden Beispiel handelt es sich bei dem Pfad um `G:\Directory\app-state` 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 '