Partilhar via

Usar o driver CSI (Disk Container Storage Interface) do Azure no Serviço Kubernetes do Azure (AKS)

  • Artigo

O driver CSI (Interface de Armazenamento de Contêiner) do Azure Disks é um driver compatível com a especificação CSI usado pelo Serviço Kubernetes do Azure (AKS) para gerenciar o ciclo de vida do Disco do Azure.

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

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

Nota

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

Nota

Os drivers na árvore referem-se aos drivers de armazenamento atuais que fazem parte do código principal do Kubernetes versus os novos drivers CSI, que são plug-ins.

Recursos do driver do Azure Disk CSI

Além dos recursos de driver na árvore, o driver CSI do Azure Disk dá suporte aos seguintes recursos:

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

Nota

Dependendo da SKU da VM que está sendo usada, o driver CSI do Azure Disk pode ter um limite de volume por nó. Para algumas VMs poderosas (por exemplo, 16 núcleos), o limite é de 64 volumes por nó. Para identificar o limite por SKU de VM, revise a coluna Máximo de discos de dados para cada SKU de VM oferecida. Para obter uma lista de SKUs de VM oferecidas e seus limites de capacidade detalhados correspondentes, consulte Tamanhos de máquinas virtuais de uso geral.

Usar volumes persistentes CSI com Discos do Azure

Um volume persistente (PV) representa uma parte do armazenamento que é provisionada para uso com pods do Kubernetes. Um PV pode ser usado por um ou vários pods e pode ser provisionado dinamicamente ou estaticamente. Este artigo mostra como criar dinamicamente PVs com o disco do Azure para uso por um único pod em um cluster AKS. Para provisionamento estático, consulte Criar um volume estático com discos do Azure.

Para obter mais informações sobre volumes do Kubernetes, consulte 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 do Kubernetes, consulte Classes de armazenamento do Kubernetes.

Quando você usa o driver Azure Disk CSI no AKS, há mais dois internos StorageClasses que usam o driver de armazenamento Azure Disk CSI. As outras classes de armazenamento CSI são criadas com o cluster ao lado das classes de armazenamento padrão na árvore.

  • managed-csi: Usa o armazenamento localmente redundante (LRS) do SSD padrão do Azure para criar um disco gerenciado. Em vigor a partir da versão 1.29 do Kubernetes, nos clusters do Serviço Kubernetes do Azure (AKS) implantados em várias zonas de disponibilidade, essa classe de armazenamento utiliza o armazenamento com redundância de zona (ZRS) do SSD padrão do Azure para criar discos gerenciados.
  • managed-csi-premium: Usa o Azure Premium LRS para criar um disco gerenciado. Em vigor a partir da versão 1.29 do Kubernetes, nos clusters do Serviço Kubernetes do Azure (AKS) implantados em várias zonas de disponibilidade, essa classe de armazenamento utiliza o ZRS (Armazenamento com Redundância de Zona Premium) do Azure Premium 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 respetivo PV for excluído. As classes de armazenamento também configuram os PVs para serem expansíveis. Você só precisa editar a declaração de volume persistente (PVC) com o novo tamanho.

Para usar essas classes de armazenamento, crie um PVC e seu respetivo pod que faça referência e os utilize. Um PVC é usado para provisionar automaticamente o armazenamento com base em uma classe de armazenamento. Um PVC pode usar uma das classes de armazenamento pré-criadas ou uma classe de armazenamento definida pelo usuário para criar um disco gerenciado pelo Azure para a SKU e o tamanho desejados. Quando você cria uma definição de pod, o PVC é especificado para solicitar o armazenamento desejado.

Crie um pod de exemplo e o respetivo 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 seguinte comando para criar um novo 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ê vê o test.txt arquivo 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, você pode querer ter sua própria classe de armazenamento personalizada com seus próprios parâmetros. Por exemplo, talvez você queira alterar a volumeBindingMode classe.

Você pode usar uma volumeBindingMode: Immediate classe que garanta que ela ocorra imediatamente após a criação do PVC. Quando seus pools de nós são restritos à topologia, por exemplo, ao usar zonas de disponibilidade, os PVs seriam vinculados ou provisionados sem conhecimento dos requisitos de agendamento do pod.

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

Crie um arquivo chamado sc-azuredisk-csi-waitforfirstconsumer.yamle, em seguida, cole o manifesto a seguir. A classe de armazenamento é a mesma que a nossa managed-csi classe de armazenamento, mas com uma classe diferente volumeBindingMode .

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 sc-azuredisk-csi-waitforfirstconsumer.yaml arquivo:

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 Azure Disk CSI dá suporte à criação de instantâneos de volumes persistentes. Como parte desse recurso, o driver pode executar instantâneos completos ou incrementais, dependendo do valor definido no incremental parâmetro (por padrão, é verdadeiro).

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

Nome Significado Valor disponível Obrigatório Default value
resourceGroup Grupo de recursos para armazenar fotos instantâneas 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 Tire instantâneos completos ou incrementais true, false Não true
etiquetas Tags do Azure Disks Formato da etiqueta: '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)
ID da subscrição Especifique a ID da assinatura do Azure onde os Discos do Azure serão criados Id de subscrição do Azure Não Se não estiver vazio, resourceGroup deve ser fornecido, incremental deve definir como false

Criar um instantâneo de volume

Nota

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

Para obter um exemplo desse recurso, 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 a partir do 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>

Crie um novo PVC com base em um instantâneo de volume

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

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

Finalmente, vamos certificar-nos de que é o mesmo PVC criado antes, verificando 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 criado test.txt anteriormente.

Volumes de clonagem

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

O driver CSI para Discos do Azure dá suporte à clonagem de volume. Para demonstrar, crie um volume clonado do criado azuredisk-pvc anteriormente e um novo 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 seguinte comando 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

Pode pedir um volume maior para um PVC. Edite o objeto PVC e especifique um tamanho maior. Esta alteração aciona a expansão do volume subjacente que suporta o PV.

Nota

Um novo PV nunca é criado para satisfazer a reivindicação. Em vez disso, é redimensionado um volume existente.

No AKS, a classe de armazenamento integrada managed-csi já suporta expansão, por isso utilize o PVC criado anteriormente com esta classe de armazenamento. O PVC solicitou um volume persistente de 10 Gi. Você pode confirmar executando 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 spec.resources.requests.storage campo executando o seguinte comando:

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

Nota

Atualmente, a redução de volumes persistentes não é suportada. 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 que 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
(...)

E depois de alguns minutos, execute os seguintes comandos para confirmar o tamanho do 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

Explosão sob demanda

O modelo de bursting de disco sob demanda permite picos de disco sempre que suas necessidades excederem sua capacidade atual. Este modelo gera cargas extras sempre que o disco rebenta. O bursting sob demanda só está disponível para SSDs premium maiores que 512 GiB. Para obter mais informações sobre IOPS provisionadas de SSDs premium e taxa de transferência por disco, consulte Tamanho de SSD premium. Alternativamente, o bursting baseado em crédito é onde o disco irá explodir somente se tiver créditos de burst acumulados em seu bucket de crédito. O bursting baseado em crédito não gera cobranças extras quando o disco é rebentado. O bursting baseado em crédito só está disponível para SSDs premium de 512 GiB e menores, e SSDs padrão de 1024 GiB e menores. Para obter mais informações sobre bursting sob demanda, consulte Bursting sob demanda.

Importante

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

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, consulte Bursting sob demanda. Para obter mais informações sobre como criar sua própria classe de armazenamento com bursting sob demanda habilitado, consulte Criar uma classe de armazenamento Premium CSI gerenciada Burstable .

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

Contentores do Windows

O controlador CSI do Disco do Azure suporta nós e contentores do Windows. Se você quiser 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, agora você pode usar as classes de armazenamento internas, como managed-csi. Você pode implantar um exemplo de conjunto stateful baseado no Windows que salva carimbos de data/hora no arquivo data.txt executando 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óximos passos