Compartilhar via

Usar o driver da CSI (Interface de Armazenamento de Contêiner) para Discos do Azure no AKS (Serviço de Kubernetes do Azure)

  • Artigo

O driver da CSI (Interface de Armazenamento de Contêiner) para Discos do Azure é um driver em conformidade com a especificação CSI usada pelo AKS (Serviço de Kubernetes do Azure) para gerenciar o ciclo de vida do Disco do Azure.

A CSI é um padrão para expor sistemas de blocos e de armazenamento de arquivos arbitrários a cargas de trabalho em contêineres no Kubernetes. Ao adotar e usar a CSI, o AKS pode escrever, implantar e iterar plug-ins para expor novos sistemas de armazenamento ou aprimorar os existentes no Kubernetes. O uso de drivers CSI no AKS evita ter que tocar no código principal do Kubernetes e aguardar os ciclos de lançamento dele.

Para criar um cluster do AKS com suporte ao driver da CSI, confira Habilitar drivers da CSI no AKS. Este artigo descreve como usar o driver da CSI do Azure Data Box Disk versão 1.

Observação

O driver da CSI do Azure Data Box Disk v2 (versão prévia) melhora a escalabilidade e reduz a latência de failover do pod. Ele usa discos compartilhados para provisionar réplicas de anexo em vários nós de cluster e integra-se ao agendamento de pod para garantir que um nó com uma réplica de anexo seja escolhido no failover do pod. O driver da CSI do Azure Data Box Disk v2 (versão prévia) também fornece a capacidade de ajustar o desempenho. Se você estiver interessado em participar da versão prévia, envie uma solicitação: https://aka.ms/DiskCSIv2Preview. Essa versão prévia é fornecida sem um contrato de nível de serviço, e você pode esperar, ocasionalmente, alterações significativas durante a versão prévia. A versão prévia não é recomendada para cargas de trabalho de produção. Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

Observação

O termo Drivers na árvore refere-se a drivers de armazenamento atuais que fazem parte do código principal do Kubernetes versus os novos drivers da CSI, que são plug-ins.

Recursos do driver da CSI do Azure Data Box Disk

Além dos recursos do driver na árvore, a CSI do Azure Data Box Disk dá suporte aos seguintes recursos:

  • Melhorias de desempenho durante a anexação e a desanexação de disco simultâneo
    • Os drivers na árvore anexam ou desanexam discos em série, enquanto os drivers da CSI anexam ou desanexam discos em lote. Há uma melhoria significativa quando vários discos são anexados a um nó.
  • Há suporte para SSD Premium v1 e v2.
    • PremiumV2_LRS suporta apenas o modo de cache None
  • Suporte de disco para o ZRS (armazenamento com redundância de zona)
    • Há suporte para os tipos de disco Premium_ZRS, StandardSSD_ZRS. O disco ZRS pode ser agendado no nó de zona ou que não é de zona, sem a restrição de que o volume de disco deve estar localizado na mesma zona que determinado nó. Para obter mais informações, incluindo quais regiões têm suporte, consulte Armazenamento com redundância de zona para discos gerenciados.
  • Instantâneo
  • Clone de volume
  • Redimensionar o PV do disco sem tempo de inatividade

Observação

Dependendo da SKU da VM que esteja sendo usada, o driver da CSI do Azure Data Box Disk pode ter um limite de volume por nó. Para algumas VMs avançadas (por exemplo, de 16 núcleos), o limite é de 64 volumes por nó. Para identificar o limite segundo o SKU da VM, examine a coluna Máximo de discos de dados de cada SKU de VM oferecida. Para obter uma lista dos SKUs de VM oferecidos e os limites de capacidade detalhados correspondentes, consulte Tamanhos de máquina virtual de uso geral.

Usar volumes persistentes da CSI com Discos do Azure

Um PV (volume persistente) representa um armazenamento provisionado para uso com pods do Kubernetes. Um PV pode ser usado por um ou vários pods e pode ser provisionado estática ou dinamicamente. Este artigo mostra como criar dinamicamente PVs com Discos do Azure para uso por um só pod em um cluster do AKS. Para provisionamento estático, confira Criar um volume estático com Discos do Azure.

Para obter mais informações sobre o Kubernetes, veja Opções de armazenamento para aplicativos no AKS.

Criar dinamicamente PVs de Discos do Azure usando as classes de armazenamento internas

Uma classe de armazenamento é usada para definir como uma unidade de armazenamento é criada dinamicamente com um volume persistente. Para obter mais informações sobre classes de armazenamento Kubernetes, confira Classes de Armazenamento Kubernetes.

Quando você usa o driver da CSI do Azure Data Box Disk no AKS, há mais dois StorageClasses internos que usam o driver de armazenamento da CSI do Azure Data Box Disk. As outras classes de armazenamento da CSI são criadas com o cluster juntamente com as classes de armazenamento padrão na árvore.

  • managed-csi: usa o LRS (armazenamento com redundância local) do Azure SSD Standard para criar um disco gerenciado. A partir do Kubernetes versão 1.29, em clusters do AKS (Serviço de Kubernetes do Azure) implantados em várias zonas de disponibilidade, essa classe de armazenamento utiliza o ZRS (armazenamento com redundância de zona) para Standard SSD do Azure, para criar discos gerenciados.
  • managed-csi-premium: usa o LRS Premium do Azure para criar um disco gerenciado. A partir do Kubernetes versão 1.29, em clusters do AKS (Serviço de Kubernetes do Azure) implantados em várias zonas de disponibilidade, essa classe de armazenamento utiliza o ZRS (armazenamento com redundância de zona) Premium do Azure, para criar discos gerenciados.

A política de recuperação em ambas as classes de armazenamento garante que os Discos do Azure subjacentes sejam excluídos, quando o respectivo PV for excluído. As classes de armazenamento também configuram o PVs para que sejam expansíveis. Você só precisa editar a PVC (declaração de volume persistente) com o novo tamanho.

Para usar essas classes de armazenamento, crie uma PVC e o respectivo pod que a referencie e utilize. Uma PVC é usada para provisionar automaticamente o armazenamento com base em uma classe de armazenamento. Uma PVC pode usar uma das classes de armazenamento criadas previamente ou uma classe de armazenamento definida pelo usuário para criar um disco gerenciado pelo Azure para o SKU e o tamanho desejados. Quando você cria uma definição de pod, a PVC é especificada para solicitar o armazenamento desejado.

Criar um pod de exemplo e a respectiva PVC executando o comando kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/pvc-azuredisk-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/nginx-pod-azuredisk.yaml

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

persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created

Depois que o pod estiver no estado de execução,execute o comando a seguir para criar um arquivo chamado test.txt.

kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt

Para validar que o disco está montado corretamente execute o seguinte comando e verifique se você exibe o arquivo test.txt na saída:

kubectl exec nginx-azuredisk -- ls /mnt/azuredisk

lost+found
outfile
test.txt

Criar uma classe de armazenamento personalizada

As classes de armazenamento padrão são adequadas para os cenários mais comuns. Para alguns casos, talvez você queira ter a própria classe de armazenamento personalizada com os próprios parâmetros. Por exemplo, pode ser que você queira alterar a classe volumeBindingMode.

Você pode usar uma classe volumeBindingMode: Immediate que garante que isso ocorra imediatamente depois da criação da PVC. Quando os pools de nós são restritos à topologia, por exemplo, ao usar zonas de disponibilidade, o PVs serão associados ou provisionados sem o conhecimento dos requisitos de agendamento do pod.

Para resolver esse cenário, você pode usar volumeBindingMode: WaitForFirstConsumer, que atrasa a associação e o provisionamento de um VP até que um pod que usa a PVC seja criado. Assim, o PV está em conformidade e é provisionado na zona de disponibilidade (ou em outra topologia) especificada pelas restrições de agendamento do pod. As classes de armazenamento padrão usam a classe volumeBindingMode: WaitForFirstConsumer.

Crie um arquivo chamado sc-azuredisk-csi-waitforfirstconsumer.yaml e cole o manifesto a seguir: A classe de armazenamento é igual à classe de armazenamento managed-csi, mas com uma classe volumeBindingMode diferente.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Crie a classe de armazenamento executando o comando kubectl apply e especifique seu arquivo sc-azuredisk-csi-waitforfirstconsumer.yaml:

kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

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

storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

Instantâneos de volume

O driver da CSI do Azure Data Box Disk dá suporte à criação de instantâneos de volumes persistentes. Como parte dessa funcionalidade, o driver pode executar instantâneos completos ou incrementais, dependendo do valor definido no parâmetro incremental (por padrão, é true).

A tabela a seguir fornece detalhes para todos os parâmetros.

Nome Significado Valor disponível Obrigatório Valor padrão
resourceGroup Grupo de recursos para armazenar capturas de instantâneo GRUPO DE RECURSOS EXISTENTE Não Se não for especificado, o instantâneo será armazenado no mesmo grupo de recursos que os Discos do Azure de origem
incremental Tirar instantâneo completo ou incremental true, false Não true
marcas Marcas dos Discos do Azure Formato da marca: 'key1=val1,key2=val2' Não ""
userAgent Agente de usuário usado para atribuição de uso do cliente Não Useragent gerado formatado driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Especificar a ID da assinatura do Azure em que os Discos do Azure serão criados ID de assinatura do Azure Não Se não estiver vazio, resourceGroup deve ser fornecido, incremental deve ser definido como false

Criar um instantâneo de volume

Observação

Antes de continuar, verifique se o aplicativo não está gravando dados no disco de origem.

Para obter um exemplo dessa funcionalidade, crie uma classe de instantâneo de volume com o comando kubectl apply:

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

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

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

Agora, vamos criar um instantâneo de volume da PVC que criamos dinamicamente no início deste tutorial, pvc-azuredisk.

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

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

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

Para verificar se o instantâneo foi criado corretamente, execute o seguinte comando:

kubectl describe volumesnapshot azuredisk-volume-snapshot

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

Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

Criar uma PVC com base em um instantâneo de volume

Você pode criar uma PVC com base em um instantâneo de volume. Use o instantâneo criado na etapa anterior e crie uma PVC e um pod para consumi-la.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml

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

persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

Por fim, vamos confirmar se é a mesma PVC criada antes de verificar o conteúdo, executando o seguinte comando:

kubectl exec nginx-restored -- ls /mnt/azuredisk

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

lost+found
outfile
test.txt

Como esperado, ainda podemos ver nosso arquivo test.txt criado anteriormente.

Clonar volumes

Um volume clonado é definido como uma duplicata de um volume do Kubernetes existente. Para obter mais informações sobre como clonar volumes no Kubernetes, confira a documentação conceitual para clonagem de volume.

O driver da CSI para Discos do Azure dá suporte à clonagem de volume. Para demonstrar, crie um volume clonado do azuredisk-pvc criado anteriormente e um pod para consumi-lo.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml

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

persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

Você pode verificar o conteúdo do volume clonado executando o comando a seguir e confirmando que o arquivo test.txt foi criado:

kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

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

lost+found
outfile
test.txt

Redimensionar um volume persistente sem tempo de inatividade

Você pode solicitar um volume maior para uma PVC. Edite o objeto PVC e especifique um tamanho maior. Essa alteração dispara a expansão do volume subjacente que faz o backup do VP.

Observação

Um VP nunca é criado para atender à declaração. Em vez disso, um volume é redimensionado.

No AKS, a classe de armazenamento managed-csi interna já permite a expansão, portanto, use a PVC criada anteriormente com essa classe de armazenamento. A PVC solicitou um volume persistente de 10 Gi. Você pode confirmar ao executar o seguinte comando:

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

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

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

Expanda o PVC aumentando o campo spec.resources.requests.storage ao executar o seguinte comando:

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

Observação

Atualmente, não há suporte para a redução de volumes persistentes. Tentar corrigir um PVC existente com um tamanho menor do que o atual leva à seguinte mensagem de erro: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

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

persistentvolumeclaim/pvc-azuredisk patched

Execute o seguinte comando para confirmar se o tamanho do volume aumentou:

kubectl get pv

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

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

Após alguns minutos, execute os comandos a seguir e confirme o tamanho da PVC:

kubectl get pvc pvc-azuredisk

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

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

Execute o seguinte comando para confirmar o tamanho do disco dentro do pod:

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

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

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

Intermitência sob demanda

O modelo de bursting de disco sob demanda, permite a intermitência de discos sempre que eles precisarem exceder a sua capacidade atual. Esse modelo incorre encargos adicionais, sempre que ocorre intermitência de disco. O estouro sob demanda só está disponível para SSDs Premium com mais de 512 GiB. Para obter mais informações sobre IOPS provisionado por SSDs Premium e taxa de transferência por disco, consulte Tamanho do SSD Premium. Alternativamente, o bursting baseado em crédito é onde o disco terá intermitência somente se ele tiver créditos de intermitência acumulados em seu bucket de crédito. A intermitência baseada em crédito não gera encargos adicionais, quando ocorre intermitência de disco. A intermitência baseada em crédito só está disponível para SSDs Premium de 512 GiB e menores, e SSDs Standard de 1024 GiB e menores. Para obter mais informações sobre o bursting sob demanda, confira Bursting de disco sob demanda.

Importante

A classe de armazenamento managed-csi-premium padrão tem o bursting sob demanda desabilitado e usa o bursting baseado em crédito. Todo SSD Premium criado dinamicamente por uma declaração de volume persistente com base na classe de armazenamento managed-csi-premium padrão também tem a intermitência sob demanda desabilitada.

Para criar um volume persistente SSD Premium com bursting sob demanda habilitado, você pode criar uma nova classe de armazenamento com o parâmetro enableBursting definido como true conforme mostrado no modelo YAML a seguir. Para obter mais informações sobre como habilitar o bursting sob demanda, confira Bursting de disco sob demanda. Para obter mais informações sobre como criar sua própria classe de armazenamento com bursting sob demanda habilitada, consulte Criar uma classe de armazenamento Premium de CSI gerenciada com capacidade de intermitência.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Contêineres do Windows

O driver da CSI para discos do Azure também permite nós e contêineres do Windows. Se desejar usar contêineres do Windows, siga o Início rápido de contêineres do Windows para adicionar um pool de nós do Windows.

Depois de ter um pool de nós do Windows, você pode usar as classes de armazenamento internas como managed-csi. Você pode implantar um conjunto com estado baseado em Windows de exemplo que salva carimbos de data/hora no arquivo data.txt ao executar o seguinte comando kubectl apply:

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

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

statefulset.apps/busybox-azuredisk created

Para validar o conteúdo do volume, execute o seguinte comando:

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

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

2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

Próximas etapas