Usar o driver CSI (Disk Container Storage Interface) do Azure no Serviço Kubernetes do Azure (AKS)
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.
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_LRSsuporta apenas oNonemodo de cache
- Suporte a disco de armazenamento com redundância de zona (ZRS)
Premium_ZRS,StandardSSD_ZRStipos 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.
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.
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
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
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 |
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>
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.
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
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
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
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
(...)
- Para saber como usar o driver CSI para Arquivos do Azure, consulte Usar arquivos do Azure com driver CSI.
- Para saber como usar o driver CSI para o armazenamento de Blob do Azure, consulte Usar o armazenamento de Blob do Azure com o driver CSI.
- Para obter mais informações sobre práticas recomendadas de armazenamento, consulte Práticas recomendadas para armazenamento e backups no Serviço Kubernetes do Azure.
- Para obter mais informações sobre soluções de armazenamento baseadas em disco, consulte Soluções baseadas em disco no AKS.
Comentários do Azure Kubernetes Service
O Azure Kubernetes Service é um projeto código aberto. Selecione um link para fornecer comentários: