Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Opciones de almacenamiento persistente
¿Qué es un complemento de volumen dentro del árbol o uno fuera del árbol?
Antes de la introducción de la interfaz de almacenamiento de contenedores (CSI), todos los complementos de volumen estaban integrados en un árbol, lo que significaba que se creaban, vinculaban, compilaban y distribuían con los archivos binarios principales de Kubernetes y ampliaban la API principal de Kubernetes. Esto significaba que para añadir un nuevo sistema de almacenamiento a Kubernetes (un complemento de volumen) era necesario introducir el código en el repositorio principal de códigos de Kubernetes.
Out-of-tree Los complementos de volumen se desarrollan de forma independiente del código base de Kubernetes y se despliegan (instalan) en los clústeres de Kubernetes como extensiones. Esto permite a los proveedores actualizar los controladores fuera de banda, es decir, de forma independiente del ciclo de lanzamiento de Kubernetes. Esto es posible en gran medida porque Kubernetes ha creado una interfaz de almacenamiento (CSI) que proporciona a los vendedores una forma estándar de interactuar con los k8s.
Puede obtener más información sobre las clases de almacenamiento de Amazon Elastic Kubernetes Services (EKS) y los controladores CSI en https://docs.aws.amazon.com/eks/latest/userguide/storage.html
In-tree Complemento de volumen para Windows
Los volúmenes de Kubernetes permiten implementar aplicaciones en Kubernetes con requisitos de persistencia de datos. La administración de los volúmenes persistentes consiste en provisioning/de: volúmenes, attaching/detaching un volumen (un nodo provisioning/resizing de Kubernetes) y to/from un volumen (contenedores individuales en un pod). mounting/dismounting to/from El código para implementar estas acciones de administración de volúmenes para un protocolo o servidor de almacenamiento específico se envía en forma de un complemento de volumen de Kubernetes (Volume Plugins). In-tree En Amazon Elastic Kubernetes Services (EKS), Windows admite la siguiente clase de complementos de volumen de Kubernetes:
In-tree Complemento
Para usar el complemento de In-tree volumen en los nodos de Windows, es necesario crear un complemento adicional StorageClass para usar NTFS como FSType. En EKS, el valor predeterminado StorageClass usa ext4 como FSType predeterminado.
A StorageClass proporciona a los administradores una forma de describir las «clases» de almacenamiento que ofrecen. Las diferentes clases pueden corresponder a los niveles de calidad de servicio, a las políticas de respaldo o a las políticas arbitrarias determinadas por los administradores del clúster. Kubernetes no tiene opiniones sobre lo que representan las clases. Este concepto a veces se denomina «perfiles» en otros sistemas de almacenamiento.
Puede comprobarlo ejecutando el siguiente comando:
kubectl describe storageclass gp2
Salida:
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>
Para crear el nuevo StorageClass que sea compatible con NTFS, usa el siguiente manifiesto:
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gp2-windows provisioner: kubernetes.io/aws-ebs parameters: type: gp2 fsType: ntfs volumeBindingMode: WaitForFirstConsumer
Cree el StorageClass ejecutando el siguiente comando:
kubectl apply -f NTFSStorageClass.yaml
El siguiente paso es crear una reclamación de volumen persistente (PVC).
Un PersistentVolume (PV) es una pieza de almacenamiento del clúster que ha sido aprovisionada por un administrador o aprovisionada dinámicamente mediante PVC. Es un recurso del clúster del mismo modo que un nodo es un recurso del clúster. Este objeto de API captura los detalles de la implementación del almacenamiento, ya sea NFS, iSCSI o un sistema de almacenamiento específico de un proveedor de nube.
Un PersistentVolumeClaim (PVC) es una solicitud de almacenamiento realizada por un usuario. Las reclamaciones pueden solicitar tamaños y modos de acceso específicos (por ejemplo, se pueden montar ReadWriteOnce ReadOnlyMany o ReadWriteMany).
Los usuarios necesitan PersistentVolumes diferentes atributos, como el rendimiento, para diferentes casos de uso. Los administradores de clústeres deben poder ofrecer una variedad PersistentVolumes que se diferencie en algo más que en el tamaño y los modos de acceso, sin exponer a los usuarios a los detalles de cómo se implementan esos volúmenes. Para estas necesidades, existe el StorageClass recurso.
En el siguiente ejemplo, el PVC se creó dentro de las ventanas del espacio de nombres.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ebs-windows-pv-claim namespace: windows spec: accessModes: - ReadWriteOnce storageClassName: gp2-windows resources: requests: storage: 1Gi
Cree el PVC ejecutando el siguiente comando:
kubectl apply -f persistent-volume-claim.yaml
El siguiente manifiesto crea un pod de Windows, VolumeMount lo configura C:\Data y utiliza el PVC como almacenamiento adjuntoC:\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'
Pruebe los resultados accediendo al pod de Windows mediante PowerShell:
kubectl exec -it podname powershell -n windows
Dentro del pod de Windows, ejecute: ls
Salida:
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
El directorio de datos lo proporciona el volumen de EBS.
Out-of-tree para Windows
El código asociado a los complementos de CSI se envía como scripts y binarios independientes que, por lo general, se distribuyen como imágenes de contenedores y se implementan mediante construcciones estándar de Kubernetes, como y. DaemonSets StatefulSets Los complementos de CSI gestionan una amplia gama de acciones de gestión de volúmenes en Kubernetes. Los complementos de CSI suelen consistir en complementos de nodos (que se ejecutan en cada nodo como si fueran) y complementos de controlador. DaemonSet
Los complementos de nodos CSI (especialmente los asociados a volúmenes persistentes expuestos como dispositivos de bloques o a través de un sistema de archivos compartido) deben realizar diversas operaciones privilegiadas, como escanear dispositivos de disco, montar sistemas de archivos, etc. Estas operaciones son diferentes para cada sistema operativo anfitrión. En el caso de los nodos de trabajo de Linux, los complementos de nodos CSI en contenedores se implementan normalmente como contenedores privilegiados. En el caso de los nodos de trabajo de Windows, las operaciones privilegiadas de los complementos de nodos CSI en contenedores se admiten mediante csi-proxy
La AMI de Windows optimizada para Amazon EKS se incluye CSI-proxy a partir de abril de 2022. Los clientes pueden utilizar el controlador CSI SMB
El siguiente blog contiene
Amazon FSx para Windows File Server
Una opción es utilizar Amazon FSx for Windows File Server a través de una función SMB denominada SMB Global
En el ejemplo siguiente, la ruta G:\Directory\app-state es un recurso compartido SMB en el nodo de 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
El siguiente blog
