Usando o SMB CSI Driver nos Windows Nodes do Amazon EKS

Por Marcio Morales, Principal Solutions Architect da Amazon Web Services 

Em 2020, publicamos pela primeira vez um blog post sobre como os Windows pods no Amazon Elastic Kubernetes Services (Amazon EKS) podem acessar o Amazon FSx for Windows File Server como armazenamento persistente. Isso foi feito usando o AWS Systems Manager para automatizar o domain join. Em segundo plano, um recurso do protocolo SMB chamado “SMB Global Mapping” foi usado para montar compartilhamentos SMB no host e oferecê-los como unidades locais nos pods Windows. Embora essa solução funcione, ela não usa a Container Storage Interface (CSI), que oferece gerenciamento e automação adicionais para lidar com o armazenamento persistente em nodes groups Windows.

Em abril de 2022, começamos a disponibilizar a Amazon EKS Optimized Windows AMI junto com o CSI Proxy, que permite que os clientes usem drivers CSI nos Windows Nodes. De acordo com a documentação oficial do Kubernetes, “O CSI Proxy é um binário que expõe um conjunto de APIs gRPC sobre operações de armazenamento em canais nomeados no Windows. Um container, como plugins de CSI Nodes, pode montar os named pipes dependendo das operações que deseja exercer no host e invocar as APIs. Semelhante ao plugin CSI no Linux, este permite que os plugins de armazenamento executem ações privilegiadas no sistema operacional host do Windows.”

O CSI Proxy usa a Container Storage Interface (CSI), que, de acordo com a documentação oficial do Kubernetes, é “um padrão usado para expor sistemas arbitrários de armazenamento de blocos e arquivos à cargas de trabalho em containers no Kubernetes e em outros sistemas de orquestração de containers”. Os drivers CSI, como o SMB CSI Driver, permitem que os clusters do Amazon Elastic Kubernetes Service (Amazon EKS) gerenciem o ciclo de vida dos compartilhamentos do Amazon FSx para volumes persistentes.

Com essa nova versão, os clientes agora podem usar o SMB CSI Driver Driver em Windows Nodes para acessar o Amazon FSx for Windows File Server, o Amazon FSx para NetApp ONTAP SMB Shares e/ou o AWS Storage Gateway – File Gateway.

Neste blog post, mostraremos as etapas para instalar corretamente o SMB CSI Driver nos Amazon EKS Windows node groups.

Pré-requisitos:

• Cluster Amazon EKS com suporte ao Windows ativado.
• Implantação do Amazon FSx for Windows File Server.
• Domínio Microsoft Active Directory implantado para dar suporte ao Amazon FSx for Windows File Server.
• Os Windows Nodes no cluster EKS devem ser capazes de resolver os fully qualified domain name (FQDN) do Amazon FSx for Windows File Server.

1. Instalando o SMB CSI Driver

No momento em que este artigo foi escrito, a versão mais recente do SMB CSI Driver era 1.9.0. Você pode verificar a versão mais recente no repositório oficial do GitHub. Como esses comandos instalam o SMB CSI Driver versão 1.9.0, você precisará atualizar as linhas de comando para corresponder à versão a ser instalada.

1.1 Execute o seguinte comando usando kubectl:

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

Or using helm chart:

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. Crie um Kubernetes secret

Os Windows Nodes precisam de permissões de leitura/gravação no compartilhamento SMB para oferecê-lo como diretórios locais para o pod Windows. Crie um segredo (secret) que contenha um nome de usuário e senha do Active Directory com privilégios de leitura/gravação no compartilhamento do Amazon FSx for Windows File Server.

2.1 Execute o seguinte comando para criar um secret chamado “smbcreds”:

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

Substitua pelo seguinte:

DOMAINNAME: O domínio FQDN do Active Directory ao qual o Amazon FSx for Windows File Server está vinculado.

USERNAME: O nome de usuário do domínio com acesso de leitura/gravação ao compartilhamento raiz do Amazon FSx for Windows File Server.

PASSWORD: A senha do usuário especificado.

3. Crie um StorageClass para ser usado com o Amazon FSx for Windows File Server

De acordo com a documentação oficial do Kubernetes:

“Um StorageClass fornece uma maneira de administradores descreverem as ’classes’ de armazenamento que oferecem. Classes diferentes podem ser mapeadas para níveis de qualidade de serviço, para políticas de backup ou para políticas arbitrárias determinadas pelos administradores do cluster. O próprio Kubernetes não tem opinião sobre o que as classes representam. Esse conceito às vezes é chamado de ‘perfis’ em outros sistemas de armazenamento.”

3.1 Copie e salve o manifesto abaixo 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 Execute o seguinte comando kubectl para criar o recurso SMB StorageClass:

kubectl apply -f smb-storageclass.yaml

Agora, você tem duas opções para testá-lo. Você pode usar StatefulSets ou Deployments. Ambas as opções serão abordadas na próxima sessão.

4. Montagem de diretórios locais no Windows Pod usando o SMB CSI Driver em um StatefulSet

Per Kubernetes official documentation:

De acordo com a documentação oficial do Kubernetes:

“Os StatefulSets devem ser usados com aplicações stateful e sistemas distribuídos. Ao contrário de um Deployment, um StatefulSet mantém uma identidade fixa para cada um de seus pods. Esses pods são criados com a mesma especificação, mas não são intercambiáveis: cada um tem um identificador persistente que é mantido em qualquer reagendamento. Se você quiser usar volumes de armazenamento para fornecer persistência à sua carga de trabalho, você pode usar um StatefulSet como parte da solução. Embora os pods individuais em um StatefulSet sejam suscetíveis à falhas, os identificadores de pod persistentes facilitam a combinação de volumes existentes com os novos pods que substituem os que falharam.”

O seguinte manifesto StatefulSet implanta um Windows Pod Busybox e cria um arquivo data.txt no diretório local montado “C:\sc\smb” que é provido pelo compartilhamento SMB. Ao usar StatefulSet, um subdiretório com um ID PersistentVolumeClaim (PVC) será criado no compartilhamento SMB raiz de cada réplica.

4.1 Copie o seguinte manifesto e salve-o 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 Execute o seguinte comando kubectl para implantar o StatefulSet:

kubectl apply -f statefulset-smb.yaml

4.3 Para validar se o SMB CSI Driver foi configurado corretamente, vamos prosseguir com um simples teste de gravação de um arquivo “Hello” no compartilhamento SMB, a partir de um diretório local no Windows Busybox.

Execute o seguinte 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 um teste adicional, abra o compartilhamento do Amazon FSx e procure um subdiretório com um ID PersistentVolumeClaim (PVC) criado no compartilhamento SMB raiz. O “hello.txt” estará lá.

5. Montando diretórios locais no Windows Pod usando o SMB CSI Driver em implantações com PV e PVC.

De acordo com a documentação oficial do Kubernetes:

“Gerenciar o armazenamento é um problema distinto do gerenciamento de instâncias de computação. O subsistema PersistentVolume fornece uma API para usuários e administradores que abstrai detalhes de como o armazenamento é fornecido e como ele é consumido. O Kubernetes inclui dois recursos de API: PersistentVolume e PersistentVolumeClaim.

Um PersistentVolume (PV) é uma parte do armazenamento no cluster que foi provisionado por um administrador ou provisionado dinamicamente usando classes de armazenamento. É um recurso no cluster, assim como um Node é um recurso de cluster. Os PVs são plugins de volume, como Volumes, mas têm um ciclo de vida independente de qualquer pod individual que use o PV. Esse objeto de API captura os detalhes da implementação do armazenamento, seja SMB, NFS, iSCSI ou um sistema de armazenamento específico do provedor de nuvem.

Um PersistentVolumeClaim (PVC) é uma solicitação de armazenamento feita por um usuário. É semelhante a um Pod. Os pods consomem recursos de Nodes e os PVCs consomem recursos PV. Os pods podem solicitar níveis específicos de recursos (CPU e memória). As Claims podem solicitar tamanhos e modos de acesso específicos (por exemplo, elas podem ser montadas em ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja mais em AccessModes).”

5.1 Crie um manifesto chamado PersistentVolume. Copie o seguinte manifesto e salve-o como pv-smb.yaml. Substitua “AMAZON_FSX_FQDN” pelo FQDN do Amazon FSx for Windows File Share que você está usando:

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 Execute o seguinte comando kubectl para criar o recurso PersistentVolume:

kubectl apply -f pv-smb.yaml

5.3 Crie um manifesto PersistentVolumeClaim. Copie o seguinte manifesto e salve-o 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 Execute o seguinte comando kubectl para criar o recurso PersistentVolumeClaim:

kubectl apply -f pvc-smb.yaml

5.5 Implante um pod que consuma o PersistentVolumeClaim. Copie o seguinte manifesto e salve-o 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 Execute o seguinte comando kubectl para implantar os pods Windows:

kubectl apply -f busybox-smb.yaml

5.7 Para validar se o SMB CSI Driver foi configurado corretamente, vamos prosseguir com um simples teste de escrever um arquivo “Hello” no diretório local “C:\mnt\smb” provido pelo compartilhamento SMB de um Pod1, e acessar o arquivo a partir do Pod2.

5.8 Identifique o nome dos pods do busybox. Execute o seguinte comando kubectl.

kubectl get pods

5.9 Crie um arquivo Hello.txt do Pod1 executando o seguinte 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 Leia o arquivo Hello.txt do Pod2 executando o seguinte comando kubectl:

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

Se o conteúdo do arquivo de texto for impresso na tela, o teste foi bem-sucedido.

Conclusão

O Container Storage Interface (CSI) do Kubernetes permite o controle central de diferentes opções de armazenamento persistente no cluster Kubernetes. Com a adição do proxy CSI ao Amazon EKS Optimized Windows AMI, os clientes agora podem usar o CSI facilmente em suas cargas de trabalho do Windows executadas no Amazon EKS.

Para obter informações adicionais sobre o SMB CSI Driver, visite o repositório oficial do GitHub. Para saber mais sobre o Kubernetes Container Storage Interface (CSI), visite a documentação oficial do Kubernetes.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre o autor

Marcio Morales é Principal Solutions Architect da Amazon Web Services. Marcio é um SME global para Windows Containers e ajuda os clientes da AWS a projetar, criar, proteger e otimizar cargas de trabalho de Windows Containers na AWS.

Revisores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 15 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em LATAM e US, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.