Criar e gerir volumes persistentes (PVs) com Ficheiros do Azure no Azure Kubernetes Service (AKS)

O Ficheiros do Azure permite que vários pods partilhem armazenamento persistente no AKS através dos protocolos SMB ou NFS, que sobrevive a reinícios dos pods, falhas dos nós e eventos de escalamento do cluster. Este artigo mostra-lhe como criar dinâmica e estaticamente uma partilha de ficheiros Azure para utilização por múltiplos pods num cluster Azure Kubernetes Service (AKS).

Lista de verificação de início rápido

1. Verificar pré-requisitos: Garantir que o CLI do Azure 2.0.59+, o driver CSI do Ficheiros do Azure esteja ativado e a conta de armazenamento disponível
2. Escolha ou crie uma classe de armazenamento: Use classes incorporadas (azurefile-csi, azurefile-csi-premium) ou crie uma personalizada
3. Criar um PersistentVolumeClaim (PVC): Definir o tamanho do armazenamento e o modo de acesso (tipicamente ReadWriteMany)
4. Crie um pod: Faça referência ao PVC na configuração de volume do seu pod
5. Verifique a montagem: Confirme que o volume está montado corretamente utilizando kubectl describe pod

Pré-requisitos

• CLI do Azure versão 2.0.59 ou posterior instalada e configurada. Encontre a versão usando o az --version comando. Para instalar ou atualizar, consulte Install CLI do Azure.
• O driver CSI Ficheiros do Azure foi ativado no seu cluster AKS.
• Uma conta de armazenamento Azure.
• Ao escolher entre partilhas de ficheiros SSD (Premium) e HDD (Standard), é importante que compreenda o modelo de provisionamento e os requisitos do padrão de utilização esperado que planeia executar no Ficheiros do Azure. Ficheiros do Azure tem três modelos de faturação: provisioned v2 (recomendado), pay-as-you-go, e o legado provisioned v1. Para mais informações, veja Escolher um Ficheiros do Azure nível de desempenho com base nos padrões de utilização.

Crie um volume completo com provisionamento dinâmico

O exemplo seguinte cria uma classe de armazenamento Ficheiros do Azure de uso geral, um PVC que provisiona dinamicamente uma partilha de ficheiros e um pod que monta a partilha de ficheiros. O exemplo utiliza o Standard_LRS SKU e o protocolo SMB. Para cargas de trabalho em produção, escolha o nível de desempenho do Ficheiros do Azure e a opção de redundância que satisfaça os seus requisitos de desempenho e disponibilidade.

1. Crie um arquivo nomeado azure-file-dynamic.yaml e cole no seguinte manifesto:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azurefile-csi-standard
   provisioner: file.csi.azure.com
   allowVolumeExpansion: true
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   parameters:
     skuName: Standard_LRS
     protocol: smb
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile-pvc
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi-standard
     resources:
       requests:
         storage: 5Gi
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: azurefile-app
   spec:
     containers:
       - name: nginx
         image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - name: azurefile-volume
             mountPath: /mnt/azure
     volumes:
       - name: azurefile-volume
         persistentVolumeClaim:
           claimName: azurefile-pvc
   

2. Aplique o manifesto usando o kubectl apply comando:

   kubectl apply -f azure-file-dynamic.yaml
   

3. Confirme que o PVC está no Bound estado e que a cápsula está no Running estado:

   kubectl get storageclass azurefile-csi-standard
   kubectl get pvc azurefile-pvc
   kubectl get pod azurefile-app
   

4. Verifique se o pod consegue escrever na e ler da partilha de ficheiros aprovisionada dinamicamente:

   kubectl exec azurefile-app -- sh -c "echo 'Azure Files is mounted' > /mnt/azure/test.txt"
   kubectl exec azurefile-app -- cat /mnt/azure/test.txt
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   Azure Files is mounted
   

5. Quando deixar de precisar dos recursos de exemplo, elimine-os:

   kubectl delete -f azure-file-dynamic.yaml
   

   Como a classe de armazenamento utiliza a Delete política de recuperação, eliminar o PVC também elimina a partilha de ficheiros Azure provisionada dinamicamente.

Use classes de armazenamento incorporadas para criar PVs dinâmicos com o Ficheiros do Azure

As classes de armazenamento definem como uma unidade de armazenamento é criada dinamicamente com um volume persistente. Uma conta de armazenamento é criada automaticamente no grupo de recursos node para ser usada com a classe de armazenamento que armazena a Ficheiros do Azure partilha de ficheiros. Quando usas drivers CSI no AKS, existem dois StorageClasses extra incorporados que usam os drivers de armazenamento CSI Ficheiros do Azure (as outras classes de armazenamento CSI são criadas com o cluster juntamente com as classes de armazenamento padrão na árvore):

• azurefile-csi: Cria uma partilha de ficheiros Azure no armazenamento HDD.
• azurefile-csi-premium: Cria uma partilha de ficheiros Azure no armazenamento SSD.

A política de reclaim em ambas as classes de armazenamento garante que a partilha de ficheiros subjacente do Azure é apagada quando o respetivo PV é eliminado. As classes de armazenamento também configuram os compartilhamentos de arquivos para serem expansíveis, você só precisa editar a declaração de volume persistente (PVC) com o novo tamanho.

Pode selecionar um dos seguintes SKUs de redundância de armazenamento do Azure para o parâmetro skuname na definição da classe de armazenamento:

• PremiumV2_LRS (recomendado): SSD provisionado v2, armazenamento localmente redundante
• PremiumV2_ZRS (recomendado): SSD provisionado v2, armazenamento redundante por zona
• Premium_LRS: SSD provisionado v1 (legacy), armazenamento localmente redundante
• Premium_ZRS: SSD provisionado v1 (legacy), armazenamento redundante em zona
• StandardV2_LRS: HDD provisionado v2, armazenamento localmente redundante
• StandardV2_ZRS: HDD provisionado v2, armazenamento redundante por zonas
• StandardV2_GRS: HDD provisionado v2, armazenamento geo-redundante
• StandardV2_GZRS: HDD pré-configurado v2, armazenamento geo-redundante por zona
• Standard_LRS: HDD pagamento conforme o uso, armazenamento localmente redundante
• Standard_GRS: HDD pago por utilização, armazenamento geo-redundante
• Standard_ZRS: HDD com pagamento conforme o uso, armazenamento de redundância zonal

Criar classes de armazenamento personalizadas para PVs dinâmicos com o Ficheiros do Azure

As classes de armazenamento padrão são adequadas para a maioria dos cenários. Em alguns casos, pode querer personalizar a sua própria classe de armazenamento com os seus próprios parâmetros. Por exemplo, pode querer configurar o mountOptions da partilha de ficheiros.

1. Crie um ficheiro com nome azure-file-sc.yaml e cole no seguinte manifesto de exemplo:

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: my-azurefile
   provisioner: file.csi.azure.com
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   allowVolumeExpansion: true
   mountOptions:
     # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
     # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
     - dir_mode=0755
     - file_mode=0755
     - uid=1000
     - gid=1000
     - mfsymlinks
     - cache=strict
     - actimeo=30
     - nosharesock
   parameters:
     skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)
   

2. Crie a classe de armazenamento usando o kubectl apply comando:

   kubectl apply -f azure-file-sc.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   storageclass.storage.k8s.io/my-azurefile created
   

Parâmetros de classe de armazenamento para PVs dinâmicos com Ficheiros do Azure

A tabela seguinte inclui parâmetros que pode usar para definir uma classe de armazenamento personalizada para as suas reivindicações de volume persistente (PVCs) com o Ficheiros do Azure:

az storage account update \
    --name mystorageaccount \
    --resource-group MC_myResourceGroup_myAKSCluster_eastus \
    --set tags.abc=ABC123

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-private-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, StandardV2_LRS, Standard_LRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Crie um PVC com Ficheiros do Azure

Um PVC utiliza o objeto de classe de armazenamento para aprovisionar de forma dinâmica uma partilha de ficheiros do Azure. Pode usar o manifesto YAML de exemplo nesta secção para criar um PVC que tem o tamanho de 100 GB com o acesso ReadWriteMany. Para mais informações sobre modos de acesso, veja Modos de acesso PV do Kubernetes.

1. Crie um ficheiro nomeado azure-file-pvc.yaml e cole o YAML seguinte. Certifica-te de que storageClassName corresponde ao nome da tua classe de armazenamento existente.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: my-azurefile
     resources:
       requests:
         storage: 100Gi
   

   Observação

   Se estiver usando a Premium_LRS SKU para sua classe de armazenamento, o valor mínimo para storage deve ser 100Gi.

2. Cria o PVC usando o kubectl apply comando.

   kubectl apply -f azure-file-pvc.yaml
   

3. Veja o estado do PVC usando o kubectl get comando:

   kubectl get pvc my-azurefile
   

   A sua saída deve assemelhar-se ao exemplo seguinte, que mostra que o PVC está num Bound estado, e que um PV foi criado dinamicamente para satisfazer a requisição.

   NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
   my-azurefile   Bound     pvc-aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb   100Gi       RWX            my-azurefile      5m
   

Use um PVC com Ficheiros do Azure num pod

O manifesto YAML de exemplo nesta seção cria um pod que usa o PVC my-azurefile para montar a partilha de ficheiros do Ficheiros do Azure no diretório /mnt/azure. Para Windows Server contentores, especifique um mountPath usando a convenção do caminho Windows, como 'D:'.

1. Crie um ficheiro chamado azure-pvc-files.yaml, e cole o seguinte YAML. Certifique-se de que o claimName corresponde ao nome do seu PVC existente.

   kind: Pod
   apiVersion: v1
   metadata:
     name: mypod
   spec:
     containers:
       - name: mypod
         image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - mountPath: /mnt/azure
             name: volume
             readOnly: false
     volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: my-azurefile
   

2. Crie o pod usando o kubectl apply comando.

   kubectl apply -f azure-pvc-files.yaml
   

3. Veja o estado do pod usando o kubectl describe comando:

   kubectl describe pod mypod
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que o pod está a funcionar e o volume está montado no caminho correto:

   Containers:
     mypod:
       Container ID:   docker://BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
       Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       Image ID:       docker-pullable://nginx@sha256:AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
       State:          Running
         Started:      Fri, 01 Mar 2019 23:56:16 +0000
       Ready:          True
       Mounts:
         /mnt/azure from volume (rw)
         /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
   [...]
   Volumes:
     volume:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  my-azurefile
       ReadOnly:   false
   [...]
   

Opções de montagem para Ficheiros do Azure

A localização para configurar as opções de montagem (mountOptions) depende se está a provisionar volumes persistentes dinâmicos ou estáticos:

• Se estiveres a provisionar dinamicamente um volume com uma classe de armazenamento, especifica as opções de montagem no objeto de classe de armazenamento (tipo: StorageClass).
• Se estiveres a provisionar um volume estaticamente, especifica as opções de montagem no objeto PV (tipo: PersistentVolume).
• Se estiver montando o compartilhamento de arquivos como um volume integrado, especifique as opções de montagem no objeto Pod (espécie: Pod).

Para obter mais informações, consulte Opções de montagem.

O valor padrão para fileMode e dirMode é 0777 para Kubernetes versões 1.13.0 e superiores. O exemplo a seguir define 0777:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com
allowVolumeExpansion: true
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)

Opções de montagem recomendadas para ações SMB

As opções de montagem recomendadas para compartilhamentos SMB são fornecidas no seguinte exemplo de classe de armazenamento:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
    skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, StandardV2_LRS, Standard_LRS, Standard_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
    # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
    # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
    - dir_mode=0755
    - file_mode=0755
    - uid=1000
    - gid=1000
    - mfsymlinks    # support symbolic links
    - cache=strict  # https://linux.die.net/man/8/mount.cifs
    - nosharesock  # reduces probability of reconnect race
    - actimeo=30  # reduces latency for metadata-heavy workload
    - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Se estiveres a usar partilhas de ficheiros premium (SSD) com o protocolo SMB e a tua carga de trabalho for pesada em metadados, inscreve-te para usar a funcionalidade de cache de metadados para melhorar o desempenho.

Para mais informações, veja Melhorar o desempenho para partilhas de ficheiros SMB Azure.

Opções de montagem recomendadas para ações NFS

As opções de montagem recomendadas para compartilhamentos NFS são fornecidas no seguinte exemplo de classe de armazenamento:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
parameters:
    protocol: nfs
    skuName: PremiumV2_LRS     # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
    - nconnect=4  # improves performance by enabling multiple connections to share
    - noresvport  # improves availability
    - actimeo=30  # reduces latency for metadata-heavy workloads

Aumente o tamanho da leitura antecipada para melhorar o rendimento de leitura.

Embora o Ficheiros do Azure suporte a configuração nconnect até à definição máxima de 16, recomendamos configurar as opções de montagem com a definição ótima de nconnect=4. Atualmente, não há ganhos além de quatro canais para a implementação do nconnect no Ficheiros do Azure.

Crie um snapshot de volume a partir de um PVC com o Ficheiros do Azure

O Ficheiros do Azure driver CSI suporta a criação de snapshots de volumes persistentes e das partilhas de ficheiros subjacentes.

1. Crie uma classe de snapshot de volume com o comando kubectl apply:

   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created
   

2. Crie um snapshot de volume a partir do PVC dinâmico que criou anteriormente neste tutorial usando o kubectl apply comando:

   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created
   

3. Veja o estado do instantâneo de volume usando o kubectl describe comando:

   kubectl describe volumesnapshot azurefile-volume-snapshot
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que o snapshot de volume não está pronto a ser usado porque o driver ainda está a criar o snapshot da partilha de ficheiros do Azure subjacente:

   Name:         azurefile-volume-snapshot
   Namespace:    default
   Labels:       <none>
   Annotations:  API Version:  snapshot.storage.k8s.io/v1beta1
   Kind:         VolumeSnapshot
   Metadata:
     Creation Timestamp:  2020-08-27T22:37:41Z
     Finalizers:
       snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
       snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
     Generation:        1
     Resource Version:  955091
     Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
     UID:               00aa00aa-bb11-cc22-dd33-44ee44ee44ee
   Spec:
     Source:
       Persistent Volume Claim Name:  pvc-azurefile
     Volume Snapshot Class Name:      csi-azurefile-vsc
   Status:
     Bound Volume Snapshot Content Name:  snapcontent-00aa00aa-bb11-cc22-dd33-44ee44ee44ee
     Ready To Use:                        false
   Events:                                <none>
   

Redimensione um volume persistente com Ficheiros do Azure

Pode pedir um volume maior para um PVC editando o objeto PVC para especificar um tamanho maior. Esta alteração aciona a expansão do volume subjacente que suporta o PV. Um novo PV nunca é criado para satisfazer a reclamação. Em vez disso, é redimensionado um volume existente.

No AKS, a classe de armazenamento incorporada azurefile-csi suporta expansão. As classes de armazenamento personalizadas devem definir allowVolumeExpansion: true. O PVC solicitou um compartilhamento de arquivos de 100 GiB.

1. Verifique o tamanho atual do PVC e do sistema de ficheiros dentro do pod usando o kubectl exec comando para executar o df -h comando dentro do pod:

   kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que o sistema de ficheiros tem 100 GB de tamanho:

   Filesystem                                                                                      Size  Used Avail Use% Mounted on
   //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee  100G  128K  100G   1% /mnt/azurefile
   

2. Expanda o PVC aumentando o campo spec.resources.requests.storage usando o comando kubectl patch. Neste exemplo, aumentamos a partilha de ficheiros para 200 GiB:

   kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage": "200Gi"}}}}'
   

   O resultado deve ser semelhante ao seguinte exemplo, que mostra que o PVC foi corrigido com sucesso.

   persistentvolumeclaim/pvc-azurefile patched
   

3. Verifique se o PVC foi redimensionado com sucesso e o novo tamanho é refletido no pod usando os comandos kubectl get pvc e df -h dentro do pod.

   kubectl get pvc pvc-azurefile
   

   A sua saída deve assemelhar-se ao seguinte exemplo, que mostra que o PVC ainda está num Bound estado, e a capacidade foi atualizada para 200 GiB:

   NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
   pvc-azurefile   Bound    pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee   200Gi      RWX            azurefile-csi   64m
   

4. Verifique o novo tamanho do sistema de ficheiros dentro do pod usando o kubectl exec comando para executar o df -h comando dentro do pod:

   kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que o sistema de ficheiros tem agora 200 GB de tamanho:

   Filesystem                                                                                Size  Used Avail Use% Mounted on
   //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-bbbbbbbb-1111-2222-3333-cccccccccccc  200G  128K  200G   1% /mnt/azurefile
   

Use um volume persistente com armazenamento privado do Ficheiros do Azure (endpoint privado)

Se os seus recursos do Ficheiros do Azure estiverem protegidos com um endpoint privado, deve criar a sua própria classe de armazenamento. Certifica-te de que configuraste as configurações de DNS para resolver o endereço IP do endpoint privado para o FQDN da cadeia de conexão. Ao criar a classe de armazenamento usando o driver Ficheiros do Azure CSI, precisa de especificar o parâmetro networkEndpointType com o valor privateEndpoint, e fornecer os seguintes parâmetros:

• resourceGroup: O grupo de recursos onde a conta de armazenamento é implantada.
• storageAccount: O nome da conta de armazenamento.
• server: O FQDN do ponto de extremidade privado da conta de armazenamento.

1. Crie um ficheiro com nome private-azure-file-sc.yaml e depois cole o manifesto seguinte. Certifique-se de substituir os marcadores de lugar para <resourceGroup> e <storageAccountName>.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azurefile-csi-private-custom
   provisioner: file.csi.azure.com
   allowVolumeExpansion: true
   parameters:
     skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, StandardV2_LRS
     resourceGroup: <resourceGroup>
     storageAccount: <storageAccountName>
     server: <storageAccountName>.file.core.windows.net
     networkEndpointType: privateEndpoint
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   mountOptions:
     # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
     # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
     - dir_mode=0755
     - file_mode=0755
     - uid=1000
     - gid=1000
     - mfsymlinks
     - cache=strict  # https://linux.die.net/man/8/mount.cifs
     - nosharesock  # reduce probability of reconnect race
     - actimeo=30  # reduce latency for metadata-heavy workload
     - nobrl
   

2. Crie a classe de armazenamento usando o kubectl apply comando:

   kubectl apply -f private-azure-file-sc.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   storageclass.storage.k8s.io/private-azurefile-csi created
   

3. Crie um ficheiro com nome private-pvc.yaml e cole no manifesto seguinte. Certifica-te de que storageClassName corresponde ao nome da tua classe de armazenamento existente.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: private-azurefile-pvc
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: private-azurefile-csi
     resources:
       requests:
         storage: 100Gi
   

4. Cria o PVC usando o kubectl apply comando.

   kubectl apply -f private-pvc.yaml
   

Use Ficheiros do Azure com contentores do Windows

O driver CSI do Ficheiros do Azure também suporta nós e contentores do Windows. Para usar contentores Windows, siga o início rápido dos contentores Windows para adicionar um pool de nós Windows. Depois de teres um pool de nós Windows, podes usar as classes de armazenamento incorporadas como azurefile-csi ou criar uma personalizada. O exemplo conjunto com estado baseado no Windows nesta secção guarda carimbos de data e hora num ficheiro data.txt a cada segundo, que é montado numa partilha de ficheiros do Azure usando o driver CSI do Ficheiros do Azure.

1. Crie o conjunto com estado usando o kubectl apply comando:

   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/windows/statefulset.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   statefulset.apps/busybox-azurefile created
   

2. Valide que os carimbos temporais estão a ser escritos na partilha de ficheiros usando os seguintes kubectl exec comandos para executar o cat comando dentro do pod:

   kubectl exec -it busybox-azurefile-0 -- cat c:\\mnt\\azurefile\\data.txt # on Linux/MacOS Bash
   kubectl exec -it busybox-azurefile-0 -- cat c:\mnt\azurefile\data.txt # on Windows Powershell/CMD
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que os carimbos temporais estão a ser escritos na partilha de ficheiros a cada segundo:

   2020-08-27 22:11:01Z
   2020-08-27 22:11:02Z
   2020-08-27 22:11:04Z
   (...)
   

Use o protocolo NFS com Ficheiros do Azure

Ficheiros do Azure suporta o protocolo NFS v4.1. O suporte NFS versão 4.1 para Ficheiros do Azure proporciona-lhe um sistema de ficheiros NFS totalmente gerido como um serviço, construído numa plataforma de armazenamento distribuído resiliente altamente disponível e muito durável.

Esta opção é otimizada para cargas de trabalho de acesso aleatório com atualizações de dados in-loco e fornece suporte completo ao sistema de arquivos POSIX. Esta secção mostra-lhe como usar partilhas NFS com o driver CSI do Ficheiros do Azure num cluster AKS.

Pré-requisitos para usar partilhas NFS com Ficheiros do Azure

• O NFS exige partilhas de ficheiros SSD (como PremiumV2_LRS, PremiumV2_ZRS, Premium_LRS, ou Premium_ZRS) e uma conta de armazenamento virtual habilitada para rede.
• A identidade do plano de controlo do seu cluster AKS (ou seja, o nome do cluster AKS) é adicionada ao papel de Contribuidor na VNet e no Grupo de Segurança da Rede.
• O principal de serviço ou a identidade gerida do seu cluster AKS devem ser atribuídos à função de Contribuidor na conta de armazenamento.

Otimizar opções de tamanho de leitura e escrita

Esta secção fornece informações sobre como abordar a otimização de desempenho NFS com o driver Ficheiros do Azure CSI, com as opções rsize e wsize. As rsize opções e wsize definem o tamanho máximo de transferência de uma operação NFS. Se rsize ou wsize não forem especificados durante a montagem, o cliente e o servidor negociarão o maior tamanho suportado por ambos. Atualmente, tanto o Ficheiros do Azure como as distribuições Linux modernas suportam tamanhos de leitura e escrita de até 1.048.576 Bytes (1 MiB).

O desempenho ideal baseia-se na comunicação eficiente cliente-servidor. Aumentar ou diminuir os valores de tamanho da opção de leitura e gravação mount pode melhorar o desempenho do NFS. O tamanho padrão dos pacotes de leitura/gravação transferidos entre cliente e servidor são 8 KB para NFS versão 2 e 32 KB para NFS versão 3 e 4. Estes valores podem ser demasiado grandes ou demasiado pequenos. Reduzir o rsize e wsize pode melhorar o desempenho do NFS numa rede congestionada ao enviar pacotes mais pequenos para cada resposta e pedido de escrita lido pelo NFS. No entanto, isso pode aumentar o número de pacotes necessários para enviar dados pela rede, aumentando o tráfego total da rede e a utilização da CPU no cliente e no servidor.

É importante que realizes testes para encontrar um rsize e um wsize que sustentem uma transferência eficiente de pacotes e que não diminuam o débito nem aumentem a latência.

O seguinte manifesto de exemplo configura a secção mountOptions numa classe de armazenamento para um máximo de rsize e wsize de 256 KiB:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

Para obter uma lista de opções suportadas mountOptions, consulte Opções de montagem NFS.

Criar classe de armazenamento de compartilhamento de arquivos NFS

1. Crie um ficheiro com nome nfs-sc.yaml e cole no manifesto seguinte. Certifique-se de especificar protocol: nfs na seção de parâmetros e ajuste o mountOptions conforme necessário para a sua carga de trabalho.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azurefile-csi-premiumv2-custom
   provisioner: file.csi.azure.com
   allowVolumeExpansion: true
   parameters:
     protocol: nfs
     skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
   mountOptions:
     - nconnect=4
     - noresvport
     - actimeo=30
   

2. Após editar e guardar o ficheiro, crie a classe de armazenamento usando o kubectl apply comando.

   kubectl apply -f nfs-sc.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   storageclass.storage.k8s.io/azurefile-csi-nfs created
   

Crie um conjunto com estado com uma partilha de ficheiros suportada por NFS

1. Crie um ficheiro com nome nfs-ss.yaml e cole no manifesto seguinte. Esta configuração guarda timestamps em um ficheiro data.txt.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-azurefile
     labels:
       app: nginx
   spec:
     podManagementPolicy: Parallel  # default is OrderedReady
     serviceName: statefulset-azurefile
     replicas: 1
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:
           "kubernetes.io/os": linux
         containers:
           - name: statefulset-azurefile
             image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
             command:
               - "/bin/bash"
               - "-c"
               - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
             volumeMounts:
               - name: persistent-storage
                 mountPath: /mnt/azurefile
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: nginx
     volumeClaimTemplates:
       - metadata:
           name: persistent-storage
         spec:
           storageClassName: azurefile-csi-premiumv2-custom
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

2. Crie o conjunto com estado usando o kubectl apply comando.

   kubectl apply -f nfs-ss.yaml
   

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   statefulset.apps/statefulset-azurefile created
   

3. Valide o conteúdo do volume usando o seguinte kubectl exec comando para executar o df -h comando dentro do pod:

   kubectl exec -it statefulset-azurefile-0 -- df -h
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que a partilha de ficheiros NFS está montada no caminho correto com o tamanho correto:

   Filesystem      Size  Used Avail Use% Mounted on
   ...
   /dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
   accountname.file.core.windows.net:/accountname/pvc-cccccccc-2222-3333-4444-dddddddddddd  100G     0  100G   0% /mnt/azurefile
   ...
   

   Como o compartilhamento de arquivos NFS está em uma conta de armazenamento Premium, o tamanho mínimo de compartilhamento de arquivos é de 100 GiB. Se você criar um PVC com um tamanho de armazenamento pequeno, poderá encontrar um erro semelhante ao seguinte: falha ao criar compartilhamento de arquivos ... tamanho (5)....

Encriptação em trânsito (EiT) para partilhas de ficheiros NFS

A encriptação em Trânsito (EiT) garante que todas as leituras e escritas nas partilhas de ficheiros NFS dentro da rede virtual são encriptadas, proporcionando uma camada extra de segurança.

Ao definir os parâmetros na StorageClass encryptInTransit: "true" ou no PersistentVolume volumeAttributes, pode ativar a encriptação de dados em trânsito para partilhas de ficheiros Azure NFS.

Provisão dinâmica (StorageClass)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-eit
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS
  encryptInTransit: "true"
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Volumes persistentes existentes

Para PVs que foram criados sem encriptação durante o trânsito, defina encryptInTransit: "true" em volumeAttributes:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azurefile-eit
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - nconnect=4
    - noresvport
    - actimeo=30
  csi:
    driver: file.csi.azure.com
    volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
    volumeAttributes:
      protocol: nfs
      encryptInTransit: "true"
      resourceGroup: "{resource-group-name}"
      storageAccount: "{account-name}"
      shareName: "{file-share-name}"

Use a identidade gerida para aceder ao armazenamento do Ficheiros do Azure

O Ficheiros do Azure agora suporta autenticação baseada em identidade gerida para acesso SMB. Isto permite que as suas aplicações acedam de forma segura ao Ficheiros do Azure sem armazenar ou gerir credenciais.

Pré-requisitos para usar a identidade gerida para aceder ao armazenamento do Ficheiros do Azure

• Verifique se a identidade do Kubelet atribuída pelo usuário tem a Storage File Data SMB MI Admin função na conta de armazenamento.
  • Se você usar sua própria conta de armazenamento, precisará atribuir Storage File Data SMB MI Admin função à identidade Kubelet atribuída pelo usuário nessa conta de armazenamento.
  • Se a conta de armazenamento for criada pelo driver CSI, conceda Storage File Data SMB MI Admin a função ao grupo de recursos onde a conta de armazenamento reside.

Ativar identidade gerida para PVs dinâmicos com Ficheiros do Azure

Para permitir a identidade gerida para volumes provisionados dinamicamente, precisa de criar uma nova classe de armazenamento com mountWithManagedIdentity: "true" e implementar o seu conjunto de estado usando esta classe de armazenamento.

O seguinte manifesto de exemplo configura uma classe de armazenamento para usar identidade gerida para aceder ao Ficheiros do Azure:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: azurefile-csi
provisioner: file.csi.azure.com
parameters:
   resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
   storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
   mountWithManagedIdentity: "true"
   # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
   clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
   # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
   # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
   - dir_mode=0755
   - file_mode=0755
   - uid=1000
   - gid=1000
   - mfsymlinks
   - cache=strict  # https://linux.die.net/man/8/mount.cifs
   - nosharesock  # reduce probability of reconnect race
   - actimeo=30  # reduce latency for metadata-heavy workload
   - nobrl  # disable sending byte range lock requests to the server

Ativar a identidade gerida para PVs estáticos com Ficheiros do Azure

Para usar identidade gerida com volumes persistentes Ficheiros do Azure estaticamente provisionados, assegure a seguinte configuração:

1. Ative o SMBOauth na conta de armazenamento executando:

   az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
   

2. Crie um PV com mountWithManagedIdentity: "true" e monte o PV no seu pod de aplicação.

O seguinte manifesto de exemplo configura um PV para usar identidade gerida para aceder ao Ficheiros do Azure:

apiVersion: v1
kind: PersistentVolume
metadata:
   name: pv-azurefile
spec:
   capacity:
   storage: 100Gi
   accessModes:
   - ReadWriteMany
   persistentVolumeReclaimPolicy: Retain
   storageClassName: azurefile-csi
   mountOptions:
   # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
   # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
   - dir_mode=0755
   - file_mode=0755
   - uid=1000
   - gid=1000
   - mfsymlinks
   - cache=strict  # https://linux.die.net/man/8/mount.cifs
   - nosharesock  # reduce probability of reconnect race
   - actimeo=30  # reduce latency for metadata-heavy workload
   - nobrl  # disable sending byte range lock requests to the server
   csi:
   driver: file.csi.azure.com
   # make sure volumeHandle is unique for every identical share in the cluster
   volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
   volumeAttributes:
       resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
       storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
       shareName: EXISTING_FILE_SHARE_NAME
       mountWithManagedIdentity: "true"
       # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
       clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Use a identidade da carga de trabalho para aceder ao armazenamento do Ficheiros do Azure

O Ficheiros do Azure agora suporta autenticação baseada em identidade de carga de trabalho para acesso a SMB. A identidade da carga de trabalho permite o acesso ao Ficheiros do Azure ao nível do pod, com privilégio mínimo, sem vincular a identidade da aplicação ao ciclo de vida do nó.

Pré-requisitos para usar a identidade de carga de trabalho para aceder ao armazenamento Ficheiros do Azure

Antes de usar a identidade da carga de trabalho para aceder ao Ficheiros do Azure a partir do AKS, cumpra os seguintes pré-requisitos.

1. Criar um cluster com oidc-issuer ativado e obter a credencial do cluster AKS

Crie um novo cluster AKS com o emissor OIDC ativado, ou verifique se já está ativado. Siga a documentação oficial para criar um novo cluster AKS com o --enable-oidc-issuer parâmetro e recupere as credenciais do cluster. E definir as seguintes variáveis de ambiente:

export RESOURCE_GROUP=<your resource group name>
export CLUSTER_NAME=<your cluster name>
export REGION=<your region>

2. Preparar a conta de armazenamento

Crie uma nova conta de armazenamento e partilha de ficheiros, ou use uma já existente. Consulte a documentação Ficheiros do Azure para instruções detalhadas. Defina as seguintes variáveis de ambiente:

export STORAGE_RESOURCE_GROUP=<your storage account resource group>
export ACCOUNT=<your storage account name>
export SHARE=<your fileshare name> # optional

3. Criar ou reutilizar uma identidade gerida e conceder as permissões necessárias

Crie uma identidade gerida atribuída pelo utilizador, ou reutilize uma existente (por exemplo, uma identidade gerida associada ao grupo de recursos de nós AKS). E recupere os detalhes necessários sobre identidade e recursos:

export UAMI=<your managed identity name>
az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show -g $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)
export ACCOUNT_SCOPE=$(az storage account show --name $ACCOUNT --query id -o tsv)

Conceder a função Storage File Data SMB MI Admin à identidade gerida. Esta função possibilita a montagem do Ficheiros do Azure apenas usando tokens de identidade de cargas de trabalho, sem depender de chaves de conta de armazenamento.

az role assignment create --role "Storage File Data SMB MI Admin" --assignee $USER_ASSIGNED_CLIENT_ID --scope $ACCOUNT_SCOPE

4. Criar uma Conta de Serviço Kubernetes

Cria uma Conta de Serviço Kubernetes que a tua carga de trabalho irá usar.

export SERVICE_ACCOUNT_NAME=<your sa name>
export SERVICE_ACCOUNT_NAMESPACE=<your sa namespace>

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

5. Criar a credencial de identidade federada

Crie a credencial de identidade federada entre a identidade gerida, o emissor da conta de serviço e o sujeito, usando o comando az identity federated-credential create.

export FEDERATED_IDENTITY_NAME=<your federated identity name>
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME \
--identity-name $UAMI \
--resource-group $RESOURCE_GROUP \
--issuer $AKS_OIDC_ISSUER \
--subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

Após completar estes passos, cargas de trabalho em execução com a ServiceAccount especificada podem autenticar-se junto ao Ficheiros do Azure utilizando a identidade de carga de trabalho Microsoft Entra, sem usar chaves de conta de armazenamento ou identidades geridas ao nível do nó.

Ativar a identidade da carga de trabalho para PVs dinâmicos com o Ficheiros do Azure

Para usar a identidade da carga de trabalho com volumes persistentes Ficheiros do Azure provisionados dinamicamente, assegure a seguinte configuração:

1. Conceder permissões à identidade do plano de controlo do condutor CSI

   • Atribuir a função Storage Account Contributor à identidade usada pelo plano de controle do driver CSI para a conta de armazenamento alvo.
   • Se a conta de armazenamento for criada dinamicamente pelo driver CSI, atribua o papel Storage Account Contributor ao grupo de recursos do nó.
   • Por padrão, a identidade do plano de controlo do cluster AKS já está atribuída à função no grupo de recursos de nós para a criação da conta de armazenamento.

2. Crie uma nova classe de armazenamento com mountWithWorkloadIdentityToken: "true" e implemente o seu conjunto com estado usando esta classe de armazenamento.

O seguinte manifesto de exemplo configura uma classe de armazenamento para usar a identidade da carga de trabalho para aceder ao Ficheiros do Azure:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-wi
provisioner: file.csi.azure.com
parameters:
  resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
  storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
  mountWithWorkloadIdentityToken: "true"
    # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
  clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server

Ativar identidade de carga de trabalho para PVs estáticos com o Ficheiros do Azure

Para usar a identidade da carga de trabalho com volumes persistentes do Ficheiros do Azure provisionados estaticamente, assegure a seguinte configuração:

1. Ative o SMBOauth na conta de armazenamento executando:

   az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
   

2. Crie um PV com mountWithWorkloadIdentityToken: "true" especificado e ligue o PV ao seu pod de aplicação.

O exemplo de manifesto a seguir configura uma PV para utilizar a identidade de workload e aceder ao Ficheiros do Azure:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azurefile
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: azurefile-csi
  mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server
  csi:
    driver: file.csi.azure.com
    # make sure volumeHandle is unique for every identical share in the cluster
    volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
    volumeAttributes:
      resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
      storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
      shareName: EXISTING_FILE_SHARE_NAME
      mountWithWorkloadIdentityToken: "true"
      # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
      clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Crie um PV estático com o Ficheiros do Azure

As secções seguintes fornecem instruções para criar um PV estático com Ficheiros do Azure. Um PV estático é um volume persistente que um administrador cria manualmente. Este PV está disponível para uso em cápsulas no cluster. Para usar um PV estático, cria-se um PVC que faz referência ao PV e depois cria-se um pod que faz referência ao PVC.

Parâmetros de classe de armazenamento para PVs estáticos com Ficheiros do Azure

A tabela seguinte inclui parâmetros que pode usar para definir uma classe de armazenamento personalizada para os seus PVCs estáticos com Ficheiros do Azure:

Criar uma partilha de ficheiros no Azure

Antes de poder usar uma partilha de ficheiros do Ficheiros do Azure como volume de Kubernetes, deve criar uma conta de Armazenamento Azure e a partilha de ficheiros.

1. Obtenha o nome do grupo de recursos de nós do seu cluster AKS usando o az aks show comando com o --query nodeResourceGroup parâmetro.

   az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
   

   A saída do comando é semelhante ao seguinte exemplo:

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Crie uma conta de armazenamento usando o az storage account create comando com o --sku parâmetro. O comando a seguir cria uma conta de armazenamento usando a Standard_LRS SKU. Certifique-se de substituir os seguintes espaços reservados:

   • myAKSStorageAccount com o nome da conta de armazenamento
   • nodeResourceGroupName com o nome do grupo de recursos no qual os nós do cluster AKS estão hospedados
   • location com o nome da região na qual criar o recurso. Deve ser a mesma região que os nós de cluster AKS.

   az storage account create --name myAKSStorageAccount --resource-group nodeResourceGroupName --location location --sku Standard_LRS
   

3. Exporta o cadeia de ligação como variável de ambiente, que usas para criar a partilha de ficheiros, usando o comando [az storage account show-connection-string][az-storage-account-show-connection-string]. Certifica-te de substituir storageAccountName e resourceGroupName com o nome da tua conta de armazenamento e o nome do grupo de recursos.

   export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string --name storageAccountName --resource-group resourceGroupName -o tsv)
   

   Observação

   As cadeias de ligação devem ser protegidas através da rotação de chaves ou armazenadas em um Azure Key Vault. Para mais informações sobre cadeias de ligação, veja Configure cadeias de ligação Armazenamento do Azure e Gerir chaves de acesso à conta de armazenamento. Para ambientes de produção, a Microsoft recomenda a utilização da autenticação Microsoft Entra ID. Para mais informações, consulte Autorizar o acesso a dados em Armazenamento do Azure.

4. Crie o compartilhamento de arquivos usando o az storage share create comando. Certifique-se de substituir shareName pelo nome do seu compartilhamento.

   az storage share create --name shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
   

5. Exporte a chave da conta de armazenamento como variável de ambiente usando o comando [az storage account keys list][az-storage-account-keys-list]. Certifica-te de substituir storageAccountName e resourceGroupName com o nome da tua conta de armazenamento e o nome do grupo de recursos.

   STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)
   

6. Eco o nome e a chave da conta de armazenamento usando o seguinte comando. Toma nota da chave da conta de armazenamento, que usas para criar um segredo Kubernetes no passo seguinte.

   echo Storage account key: $STORAGE_KEY
   

Criar um segredo do Kubernetes

O Kubernetes precisa de credenciais para acessar o compartilhamento de arquivos criado na etapa anterior. Essas credenciais são armazenadas em um segredo do Kubernetes, que é referenciado quando você cria um pod do Kubernetes.

• Crie o segredo usando o kubectl create secret comando. O exemplo a seguir cria um segredo chamado azure-secret e preenche azurestorageaccountname e azurestorageaccountkey da etapa anterior. Para usar uma conta de armazenamento Azure existente, forneça o nome e a chave da conta.

  kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
  

Monte o compartilhamento de arquivos como um volume persistente

1. Crie um novo arquivo com o nome azurefiles-pv.yaml e copie no conteúdo a seguir. Em csi, atualizar resourceGroup, volumeHandlee shareName. Para opções de montagem, o valor padrão para fileMode e dirMode é 0777.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: file.csi.azure.com
     name: azurefile
   spec:
     capacity:
       storage: 5Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     csi:
       driver: file.csi.azure.com
       volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"  # make sure this volumeid is unique for every identical share in the cluster
       volumeAttributes:
         shareName: aksshare
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
     mountOptions:
       # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
       # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
       - dir_mode=0755
       - file_mode=0755
       - uid=1000
       - gid=1000
       - mfsymlinks
       - cache=strict
       - nosharesock
       - actimeo=30
       - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   

2. Cria o PV usando o kubectl create comando.

   kubectl create -f azurefiles-pv.yaml
   

3. Crie um novo ficheiro chamado azurefiles-mount-options-pvc.yaml e cole o conteúdo seguinte. Certifica-te de que corresponde storageClassName ao nome da tua classe de armazenamento existente e volumeName ao nome do PV que criaste no passo anterior.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi
     volumeName: azurefile
     resources:
       requests:
         storage: 5Gi
   

4. Cria o PVC usando o kubectl apply comando.

   kubectl apply -f azurefiles-mount-options-pvc.yaml
   

5. Verifique se o seu PVC foi criado e ligado ao PV usando o comando kubectl get.

   kubectl get pvc azurefile
   

   A sua saída deve assemelhar-se à seguinte saída de exemplo, que mostra que o PVC está num Bound estado, e está ligado ao PV nomeado azurefile:

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

6. Atualize a especificação do seu contentor para referenciar o seu PVC e o seu pod no ficheiro YAML. Por exemplo:

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

7. Uma especificação do pod não pode ser atualizada no local, portanto, exclua o pod usando o kubectl delete comando e recrie-o usando o kubectl apply comando.

   kubectl delete pod mypod
   kubectl apply -f azure-files-pod.yaml
   

Monte a partilha de ficheiros como um volume integrado

Para montar a partilha de ficheiros Ficheiros do Azure no teu pod, configuras o volume na especificação do contentor.

1. Crie um novo arquivo com o nome azure-files-pod.yaml e copie no conteúdo a seguir. Se você alterou o nome do compartilhamento de arquivos ou o nome secreto, atualize o shareName e secretName. Você também pode atualizar o mountPath, que é o caminho onde a partilha de ficheiros está montada no pod. Para Windows Server contentores, especifique um mountPath usando a convenção do caminho Windows, como 'D:'.

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
       - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'
         name: mypod
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - name: azure
             mountPath: /mnt/azure
             readOnly: false
     volumes:
       - name: azure
         csi:
           driver: file.csi.azure.com
           volumeAttributes:
             secretName: azure-secret  # required
             shareName: aksshare  # required
             mountOptions: 'dir_mode=0755,file_mode=0755,uid=1000,gid=1000,cache=strict,actimeo=30,nosharesock,nobrl'  # optional
   

2. Crie o pod usando o kubectl apply comando.

   kubectl apply -f azure-files-pod.yaml
   

3. Veja o estado do pod usando o kubectl describe comando:

   kubectl describe pod mypod
   

Conteúdo relacionado

• usa etiquetas de Azure em Azure Kubernetes Service (AKS)