Uso del controlador CSI SMB en nodos Windows de Amazon EKS

Con esta nueva versión, los clientes ahora pueden usar el controlador SMB CSI en los nodos de Windows para acceder a Amazon FSx para Windows File Server, Amazon FSx para ONTAP SMB Shares de NetApp y/o AWS Storage Gateway – File Gateway.

En esta entrada de blog, le mostraremos los pasos para instalar correctamente el controlador SMB CSI en los grupos de nodos de Amazon EKS Windows.

Prerrequisitos:

• Clúster de Amazon EKS con compatibilidad con Windows habilitada.
• Implementación de Amazon FSx para Windows File Server.
• Dominio de Microsoft Active Directory implementado para admitir Amazon FSx para Windows File Server.
• Los nodos de Windows del clúster EKS deben poder resolver el nombre de dominio completo (FQDN) del servidor de archivos Amazon FSx para Windows.

1. Instalación del controlador SMB CSI

En el momento de escribir este artículo, la versión más reciente del controlador SMB CSI era la 1.9.0. Puedes consultar la última versión en el repositorio oficial de GitHub. Dado que estos comandos instalan la versión 1.9.0 del controlador CSI SMB, tendrá que actualizar las líneas de comando para que coincidan con la versión que se va a instalar.

1.1 Ejecute el siguiente comando con kubectl:

curl -skSL https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/v1.9.0/deploy/install-driver.sh | bash -s v1.9.0 --

O usando la tabla de timones:

helm repo add csi-driver-smb https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/master/charts
helm install csi-driver-smb csi-driver-smb/csi-driver-smb —namespace kube-system —version v1.9.0

2. Crea un Kubernetes secreto

Los nodos de Windows necesitan permisos de lectura y escritura en el recurso compartido SMB para ofrecerlo como directorios locales para el pod de Windows. Cree un secreto que contenga un nombre de usuario y una contraseña de Active Directory con privilegios de lectura/escritura en el recurso compartido de Amazon FSx para Windows File Server.

2.1 Ejecute el siguiente comando para crear un secreto llamado «smbcreds»:

kubectl create secret generic smbcreds --from-literal domain=DOMAINNAME --from-literal username=USERNAME --from-literal password=PASSWORD

Sustitúyase por lo siguiente:

DOMAINNAME: El dominio FQDN de Active Directory al que está vinculado Amazon FSx para Windows File Server.

USERNAME: El nombre de usuario del dominio con acceso de lectura y escritura al recurso raíz de Amazon FSx para Windows File Server.

PASSWORD: La contraseña del usuario especificado.

3. Cree una StorageClass para usarla con Amazon FSx para Windows File Server

Según la documentación oficial de Kubernetes:

«Una StorageClass permite a los administradores describir las ‘clases’ de almacenamiento que ofrecen. Se pueden asignar diferentes clases a los niveles de calidad del servicio, a las políticas de respaldo o a las políticas arbitrarias determinadas por los administradores del clúster. El propio Kubernetes no tiene opinión sobre lo que representan las clases. Este concepto a veces se denomina «perfiles» en otros sistemas de almacenamiento».

3.1 Copia y guarda el siguiente manifiesto como smb-storageclass.yaml:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: smb
provisioner: smb.csi.k8s.io
parameters:
  source: "//AMAZON_FSX_FQDN/share" # Use the FQDN provided by Amazon FSx
  # if csi.storage.k8s.io/provisioner-secret is provided, will create a sub directory
  # with PV name under source
  csi.storage.k8s.io/provisioner-secret-name: "smbcreds"
  csi.storage.k8s.io/provisioner-secret-namespace: "default"
  csi.storage.k8s.io/node-stage-secret-name: "smbcreds"
  csi.storage.k8s.io/node-stage-secret-namespace: "default"
reclaimPolicy: Delete  # available values: Delete, Retain
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=1001
  - gid=1001

3.2 Ejecute el siguiente comando kubectl para crear el recurso StorageClass de SMB:

kubectl apply -f smb-storageclass.yaml

Ahora tienes dos opciones para probarlo. Puede utilizar StatefulSets o Deployments. Ambas opciones se analizarán en la próxima sesión.

4. Montar directorios locales en Windows Pod mediante el controlador SMB CSI en un StatefulSet

Según la documentación oficial de Kubernetes:

«Los StatefulSets deben usarse con aplicaciones con estado y sistemas distribuidos. A diferencia de un despliegue, un StatefulSet mantiene una identidad fija para cada uno de sus pods. Estos pods se crean con la misma especificación, pero no son intercambiables: cada uno tiene un identificador persistente que se mantiene durante cualquier reprogramación. Si desea utilizar volúmenes de almacenamiento para proporcionar persistencia a su carga de trabajo, puede utilizar un StatefulSet como parte de la solución. Si bien los pods individuales de un StatefulSet son susceptibles de fallar, los identificadores de pods persistentes facilitan la combinación de los volúmenes existentes con los nuevos pods que sustituyen a los que fallan».

El siguiente manifiesto de StatefulSet implementa un Windows Pod Busybox y crea un archivo data.txt en el directorio local montado «C:\sc\smb» que proporciona el recurso compartido SMB. Al usar StatefulSet, se creará un subdirectorio con un ID PersistentVolumeClaim (PVC) en el recurso compartido SMB raíz de cada réplica.

4.1 Copia el siguiente manifiesto y guárdalo como statefulset-smb.yaml:

apiVersion: v1
kind: Service
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: busybox
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-smb
  labels:
    app: busybox
spec:
  serviceName: statefulset-smb
  replicas: 1
  template:
    metadata:
      labels:
        app: busybox
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
        - name: statefulset-smb
          image: e2eteam/busybox:1.29
          command:
            - "powershell.exe"
            - "-Command"
            - "while (1) { Add-Content -Encoding Ascii C:\\sc\\smb\\data.txt $(Get-Date -Format u); sleep 1 }"
          volumeMounts:
            - name: smb
              mountPath: "/sc/smb"
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: busybox
  volumeClaimTemplates:
    - metadata:
        name: smb
        annotations:
          volume.beta.kubernetes.io/storage-class: smb
      spec:
        accessModes: ["ReadWriteMany"]
        resources:
          requests:
            storage: 10Gi

4.2 Ejecute el siguiente comando kubectl para implementar el StatefulSet:

kubectl apply -f statefulset-smb.yaml

4.3 Para comprobar que el controlador CSI SMB se ha configurado correctamente, procedamos con una sencilla prueba de escritura de un archivo «Hola» en el recurso compartido de SMB, desde un directorio local de Windows Busybox.

Ejecute el siguiente comando kubectl:

kubectl exec -it busybox-POD-NAME-1 -- powershell -c "Write-Output "Hello from StatefulSet" | Out-File -FilePath c:\sc\smb\hello.txt"

Como prueba adicional, abra el recurso compartido de Amazon FSx y busque un subdirectorio con un ID PersistentVolumeClaim (PVC) creado en el recurso compartido SMB raíz. El «hello.txt» estará allí.

5. Configuración de directorios locales en Windows Pod mediante el controlador SMB CSI en implementaciones con VPC y PVC.

Según la documentación oficial de Kubernetes:

«Administrar el almacenamiento es un problema distinto al de administrar instancias informáticas. El subsistema PersistentVolume proporciona una API para usuarios y administradores que resume los detalles de cómo se proporciona el almacenamiento y cómo se consume. Kubernetes incluye dos funciones de API: PersistentVolume y PersistentVolumClaim.

Un PersistentVolume (PV) es una parte del almacenamiento del clúster que aprovisionó un administrador o que se aprovisionó dinámicamente mediante clases de almacenamiento. Es un recurso del clúster, al igual que un nodo es un recurso del clúster. Los PV son complementos de volumen, como Volumes, pero tienen un ciclo de vida independiente de cualquier pod individual que utilice PV. Este objeto de API captura los detalles de la implementación del almacenamiento, ya sea para SMB, 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. Es similar a un Pod. Los pods consumen los recursos de los nodos y los PVC consumen los recursos fotovoltaicos. Los pods pueden solicitar niveles específicos de recursos (CPU y memoria). Las reclamaciones pueden solicitar tamaños y modos de acceso específicos (por ejemplo, se pueden montar en ReadWriteOnce, ReadOnlyMany o ReadWriteMany; consulte más información en AccessModes)».

5.1 Crea un manifiesto llamado PersistentVolume. Copia el siguiente manifiesto y guárdalo como pv-smb.yaml. Sustituya «AMAZON_FSX_FQDN» por el FQDN de intercambio de archivos de Amazon FSx para Windows que esté utilizando:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-smb
spec:
  capacity:
    storage: 100Gi # PV-Size
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: smb
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
  csi:
    driver: smb.csi.k8s.io
    readOnly: false
    volumeHandle: VOLUME_ID # Must be unique in the EKS Cluster, eg: PV-1
    volumeAttributes:
      source: "//AMAZON_FSX_FQDN/share"
    nodeStageSecretRef:
      name: smbcreds
      namespace: default

5.2 Ejecute el siguiente comando kubectl para crear el recurso PersistentVolume:

kubectl apply -f pv-smb.yaml

5.3 Crea un manifiesto PersistentVolueClaim. Copia el siguiente manifiesto y guárdalo como pvc-smb.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-smb
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi # Size of the PVC, must be lower then the PV-Size.
  volumeName: pv-smb
  storageClassName: smb

5.4 Ejecute el siguiente comando kubectl para crear el recurso PersistentVolumeClaim:

kubectl apply -f pvc-smb.yaml

5.5 Implemente un pod que consuma el PersistentVolumeClaim. Copia el siguiente manifiesto y guárdalo como busybox-smb.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-smb
  labels:
    app: busybox
spec:
  replicas: 2
  template:
    metadata:
      name: busybox
      labels:
        app: busybox
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
        - name: busybox
          image: e2eteam/busybox:1.29
          command:
            - "powershell.exe"
            - "-Command"
            - "while (1) { Add-Content -Encoding Ascii C:\\mnt\\smb\\data.txt $(Get-Date -Format u); sleep 1 }"
          volumeMounts:
            - name: smb
              mountPath: "/pv/pv-smb"
      volumes:
        - name: smb
          persistentVolumeClaim:
            claimName: pvc-smb
  selector:
    matchLabels:
      app: busybox

5.6 Ejecute el siguiente comando kubectl para implementar los pods de Windows:

kubectl apply -f busybox-smb.yaml

5.7 Para comprobar que el controlador CSI SMB se ha configurado correctamente, procedamos con una sencilla prueba de escritura de un archivo «Hola» en el directorio local «C:\mnt\smb» proporcionado por el recurso compartido SMB de un Pod1 y acceder al archivo desde Pod2.

5.8 Identifica el nombre de las cápsulas Busybox. Ejecute el siguiente comando kubectl.

kubectl get pods

5.9 Cree un archivo Pod1 Hello.txt ejecutando el siguiente comando kubectl:

kubectl exec -it busybox-POD-NAME-1 -- powershell -c "Write-Output "Hello from replica 1" | Out-File -FilePath c:\mnt\smb\hello.txt"

5.10 Lea el archivo Pod2 Hello.txt ejecutando el siguiente comando kubectl:

kubectl exec -it busybox-POD-NAME-2 -- powershell -c "Get-Content -Path c:\mnt\smb\hello.txt"

Si el contenido del archivo de texto se imprime en la pantalla, la prueba se ha realizado correctamente.

Conclusión

La interfaz de almacenamiento en contenedores (CSI) de Kubernetes permite el control central de las diferentes opciones de almacenamiento persistente en el clúster de Kubernetes. Con la incorporación del proxy CSI a la AMI de Windows optimizada para Amazon EKS, los clientes ahora pueden usar CSI fácilmente en sus cargas de trabajo de Windows que se ejecuten en Amazon EKS.

Para obtener información adicional sobre el controlador CSI SMB, visita el repositorio oficial de GitHub. Para obtener más información sobre la interfaz de almacenamiento en contenedores (CSI) de Kubernetes, visita la documentación oficial de Kubernetes.

Este artículo fue traducido del Blog de AWS en Inglés

Acerca del autor

Marcio Morales es el arquitecto principal de soluciones en Amazon Web Services.  Marcio es una pyme global dedicada a Windows Containers y ayuda a los clientes de AWS a diseñar, crear, proteger y optimizar las cargas de trabajo de Windows Container en AWS.

Revisores

Bruno Lopes es un arquitecto de soluciones sénior en el equipo de AWS LATAM. Lleva más de 14 años trabajando con soluciones de TI, y en su cartera cuenta con numerosas experiencias en cargas de trabajo de Microsoft, entornos híbridos y formación técnica para clientes como Technical Trainer y Evangelista. Ahora actúa como arquitecto de soluciones, combinando todas las capacidades para reducir la burocracia en la adopción de las mejores tecnologías a fin de ayudar a los clientes a superar sus desafíos diarios.

Luciano Bernardes trabaja actualmente como arquitecto de soluciones sénior en AWS y se especializa en cargas de trabajo de Microsoft. Con 15 años de experiencia en el mercado, trabajó principalmente en consultoría técnica especializada en Microsoft, con clientes de diversos sectores, con demandas centradas en la infraestructura local y en la nube. Como SA, trabaja en estrecha colaboración con clientes y socios consultores en Latinoamérica y EE. UU. para apoyarlos en la toma de decisiones y la revisión de la arquitectura de las cargas de trabajo de Microsoft en la nube de AWS.

JuanMa Silva quien es arquitecto de soluciones con especialidad en Microsoft para México y MCO. Cuenta con 15 años de experiencia en la industria de IT, en posiciones de Sysadmin, consultor para ayudar a migrar clientes a la nube y modernización de aplicaciones, soporte aplicaciones de misión crítica basados en tecnología Microsoft.