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 y qué es un complemento de volumen fuera del árbol?
Antes de la introducción de la interfaz de almacenamiento de contenedores (CSI), todos los complementos de volumen formaban parte de un árbol, lo que significa que se creaban, vinculaban, compilaban y enviaban con los 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 por volumen) era necesario introducir el código en el repositorio de código principal de Kubernetes.
Out-of-tree Los complementos de volumen se desarrollan independientemente del código base de Kubernetes y se implementan (instalan) en los clústeres de Kubernetes como extensiones. Esto permite a los proveedores actualizar los controladores fuera de banda, es decir, independientemente del ciclo de lanzamiento de Kubernetes. Esto es posible en gran medida porque Kubernetes ha creado una interfaz de almacenamiento o CSI que proporciona a los proveedores una forma estándar de interactuar con k8s.
Puede obtener más información sobre las clases de almacenamiento y los controladores CSI de Amazon Elastic Kubernetes Services (EKS) en https://docs.aws.amazon.com/eks/latest/userguide/storage.html
In-tree Plugin de volumen para Windows
Los volúmenes de Kubernetes permiten que las aplicaciones, con requisitos de persistencia de datos, se desplieguen en Kubernetes. La administración de los volúmenes persistentes consiste en provisioning/de: volúmenes, un volumen, attaching/detaching 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 suministra 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 Plugin de volumen: aws ElasticBlockStore
Para usar el complemento de In-tree volumen en los nodos de Windows, es necesario crear uno adicional StorageClass para usar NTFS como FSType. En EKS, el modo predeterminado StorageClass usa ext4 como FSType predeterminado.
A StorageClass proporciona una forma para que los administradores describan 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, utilice 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
Créelo 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 parte de almacenamiento del clúster que ha sido aprovisionada por un administrador o que se ha aprovisionado 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 de un usuario. Las solicitudes pueden solicitar tamaños y modos de acceso específicos (por ejemplo, pueden ReadWriteOnce montarse 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 de opciones PersistentVolumes que difieran en otros aspectos además del 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 ejemplo siguiente, 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 Windows Pod, configura el VolumeMount AS C:\Data y usa 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'
Comprueba los resultados accediendo al pod de Windows a través de PowerShell:
kubectl exec -it podname powershell -n windows
Dentro del Windows Pod, ejecuta: 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 archivos binarios y scripts fuera de árbol que, por lo general, se distribuyen como imágenes de contenedor y se implementan mediante construcciones estándar de Kubernetes, como y. DaemonSets StatefulSets Los complementos de CSI gestionan una amplia gama de acciones de administración de volúmenes en Kubernetes. Los complementos de CSI suelen consistir en complementos de nodo (que se ejecutan en cada nodo como un DaemonSet) y complementos de controlador.
Los complementos de nodo CSI (especialmente los asociados a volúmenes persistentes expuestos como dispositivos de bloque o a través de un sistema de archivos compartido) necesitan realizar varias operaciones privilegiadas, como el escaneo de dispositivos de disco, el montaje de 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, se admiten operaciones privilegiadas para los complementos de nodos CSI en contenedores mediante csi-proxy
La AMI de Windows optimizada para Amazon EKS se incluye a partir de abril de 2022. CSI-proxy Los clientes pueden usar el controlador CSI para pequeñas y medianas empresas
El siguiente blog
Amazon FSx para Windows File Server
Una opción es utilizar Amazon FSx para Windows File Server mediante una función para pequeñas y medianas empresas denominada SMB Global Mapping,
En el ejemplo siguiente, la ruta G:\Directory\app-state es un recurso compartido de una pyme 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
