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](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)* de volumen: aws ElasticBlockStore
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:
MountOptions:
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events:
```
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 adjunto`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'
```
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](https://github.com/kubernetes-csi/csi-proxy), un binario independiente y administrado por la comunidad que debe estar preinstalado en cada nodo de Windows.
[La AMI de Windows optimizada para Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) se incluye CSI-proxy a partir de abril de 2022. Los clientes pueden utilizar el [controlador CSI SMB](https://github.com/kubernetes-csi/csi-driver-smb) en los nodos de Windows para acceder a [Amazon FSx for Windows File Server, Amazon FSx NetApp for](https://aws.amazon.com/fsx/windows/) [ONTAP SMB Shares y AWS and/or [Storage](https://aws.amazon.com/storagegateway/file/) Gateway — File](https://aws.amazon.com/fsx/netapp-ontap/) Gateway.
El siguiente [blog contiene](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/) detalles de implementación sobre cómo configurar el controlador SMB CSI para utilizar Amazon FSx for Windows File Server como almacenamiento persistente para los pods de Windows.
## 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](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage) Mapping, que permite montar un recurso compartido SMB en el host y, a continuación, pasar los directorios de ese recurso compartido a un contenedor. No es necesario configurar el contenedor con un servidor, recurso compartido, nombre de usuario o contraseña específicos, sino que todo se gestiona en el host. El contenedor funcionará igual que si tuviera almacenamiento local.
El mapeo global de pequeñas y medianas empresas es transparente para el organizador y se monta a través de él, HostPath lo que puede **implicar problemas de seguridad**.
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 '