Partilhar via

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

O driver CSI (Interface de Armazenamento de Contentor) do Azure Disks é um driver compatível com a especificação CSI usado pelo Azure Kubernetes Service (AKS) para gerenciar o ciclo de vida do Azure Disk.

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 do CSI no AKS evita ter que tocar no código principal do Kubernetes e esperar pelo seu ciclo de lançamentos.

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

Nota

Drivers integrados referem-se aos drivers de armazenamento atuais que fazem parte do código principal do Kubernetes, em contraste com os novos drivers CSI, que são plug-ins.

Funcionalidades do driver Azure Disk CSI

Além dos drivers incluídos na árvore de código, o driver CSI do Azure Disk suporta os seguintes recursos:

  • Melhorias de desempenho durante a conexão e desanexação simultânea de disco
    • Os drivers incorporados 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 para disco de armazenamento com redundância de zona (ZRS)
    • Premium_ZRS, StandardSSD_ZRS tipos de disco são suportados. O disco ZRS pode ser alocado em um nó em zona ou um nó fora de zona, sem a restrição de que o volume do disco deva ser localizado 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 máquinas virtuais poderosas, como aquelas com 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 porção de armazenamento que é provisionada para a utilização com pods do Kubernetes. Um PV pode ser usado por um ou vários pods e pode ser provisionado dinamicamente ou estaticamente. Este artigo demonstra como criar dinamicamente PVs utilizando discos do Azure para serem usados por um único pod num 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 subjacentes do Azure sejam eliminados quando o respetivo PV for eliminado. As classes de armazenamento também configuram os PVs para serem expansíveis. Basta editar a declaração de volume persistente (PVC) com o novo tamanho.

Para usar essas classes de armazenamento, crie um PVC e o respetivo pod que faça referência a elas e as 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 se cria uma definição de pod, o PVC é especificado para requerer 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 isso ocorra imediatamente uma vez que o PVC seja criado. Quando os conjuntos de nós são restritos pela topologia, por exemplo, ao usar zonas de disponibilidade, os PVs seriam vinculados ou provisionados sem conhecer os requisitos de escalonamento do pod.

Para resolver este cenário, podes usar volumeBindingMode: WaitForFirstConsumer, que atrasa a vinculação e o provisionamento de um PV até que um pod que utilize 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 Valor padrão
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 Etiquetas dos Discos Azure tags Formato da etiqueta: 'key1=val1,key2=val2' Não ""
agente de utilizador Agente do utilizador usado para atribuição de uso a clientes Não Agente de Utilizador 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 snapshot de volume. Use o instantâneo criado na etapa anterior para criar um novo PVC e um novo pod para o consumir.

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 o arquivo que criámos 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 anteriormente e azuredisk-pvc.

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 interrupção

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 reclamaçã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 expansão sob demanda, consulte Expansão sob demanda.

Importante

A classe de armazenamento padrão managed-csi-premium tem explosão sob demanda desativada e utiliza expansão baseada em créditos. 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 SSD premium com on-demand bursting ativado, pode criar uma nova classe de armazenamento com o parâmetro enableBursting definido como true como mostrado no modelo YAML a seguir. Para mais informações sobre como ativar o on-demand bursting, consulte On-demand bursting. 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 Azure Disk suporta contentores e nós Windows. Se pretender usar contentores do Windows, siga o guia de iniciação rápida de contentores 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. Pode implantar um exemplo de conjunto de estados com base em Windows que salva timestamps no ficheiro 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óximos passos