Partilhar via

Opções de armazenamento para aplicativos no Serviço de Kubernetes do Azure (AKS)

  • Artigo

Os aplicativos AKS (Serviço de Kubernetes do Azure) podem precisar armazenar e recuperar dados. Embora algumas cargas de trabalho de aplicativos possam usar armazenamento rápido local em nós desnecessários e vazios, outras exigem armazenamento persistente em volumes de dados mais regulares na plataforma Azure.

Pods múltiplos podem precisar:

  • Compartilhar os mesmos volumes de dados.
  • Reanexar os volumes de dados se o pod for reprogramado em um nó diferente.

Talvez você precise coletar e armazenar dados confidenciais ou informações de configuração do aplicativo em pods.

Este artigo apresenta os principais conceitos que fornecem armazenamento para seus aplicativos no AKS:

Diagrama das opções de armazenamento para aplicativos em um cluster do AKS (Serviço de Kubernetes do Azure).

Dimensionamento padrão do disco do sistema operacional

Quando você cria um cluster ou quando um novo pool de nós é adicionado a um cluster existente, o número de VCPUs por padrão determina o tamanho de disco do sistema operacional. O número de vCPUs é baseado na SKU da VM. A tabela a seguir lista o tamanho do disco do sistema operacional padrão para cada SKU de VM:

Núcleos da SKU da VM (vCPUs) Camada Padrão do Disco do Sistema Operacional IOPS provisionado Taxa de Transferência Provisionada (Mpbs)
1 – 7 P10/128 G 500 100
8 – 15 P15/256 G 1100 125
16 – 63 P20/512 G 2300 150
64+ P30/1024 G 5.000 200

Importante

O dimensionamento padrão do disco do sistema operacional só é usado em novos clusters ou pools de nós quando não há suporte para discos de SO Efêmero e um tamanho padrão do disco do sistema operacional não foi especificado. O tamanho do disco do sistema operacional padrão pode afetar o desempenho ou o custo do cluster. Não é possível alterar o tamanho do disco do sistema operacional após a criação do pool de nós ou cluster. Esse dimensionamento padrão do disco afeta os clusters ou os pools de nós criados em julho de 2022 ou após essa data.

Disco do SO efêmero

Por padrão, o Azure replica automaticamente o disco do sistema operacional de uma máquina virtual para o Armazenamento do Azure para evitar perda de dados quando a VM é realocada para outro host. No entanto, como os contêineres não são projetados para ter o estado local persistido, esse comportamento agrega um valor limitado e tem algumas desvantagens. Essas desvantagens incluem, mas não se limitam a provisionamento de nó mais lento e maior latência de leitura/gravação.

Por outro lado, os discos de SO efêmero são armazenados apenas no computador host, assim como um disco temporário. Essa configuração proporciona menor latência de leitura/gravação, bem como escala de nós e atualizações de cluster mais rápidos.

Observação

Quando você não solicita explicitamente discos gerenciados do Azure para o SO, o AKS usa como padrão o SO efêmero, se possível, para uma determinada configuração de pool de nós.

Os requisitos de tamanho e as recomendações para discos do sistema operacional efêmero estão disponíveis na documentação da VM do Azure. A seguir, algumas considerações gerais sobre o dimensionamento:

  • Se você optar por usar a SKU Standard_DS2_v2 de tamanho de VM padrão do AKS com o tamanho padrão do disco do sistema operacional de 100 GB, o tamanho padrão da VM será compatível com o sistema operacional efêmero, mas terá um tamanho de cache de apenas 86 GiB. Essa configuração seria padronizada para discos gerenciados se você não especificasse explicitamente. Se você solicitar um SO efêmero, um erro de validação será exibido.

  • Se você solicitar o mesmo SKU Standard_DS2_v2 com um disco do sistema operacional de 60 GiB, essa configuração usará como padrão o sistema operacional efêmero. O tamanho solicitado de 60 GiB é menor que o tamanho máximo do cache de 86 GiB.

  • Se você selecionar o SKU Standard_D8s_v3 com um disco do sistema operacional de 100 GB, esse tamanho de VM será compatível com o sistema operacional efêmero e terá um tamanho de cache de 200 GiB. Se você não especificar o tipo de disco do SO, o pool de nós receberá o SO efêmero por padrão.

A última geração da série de VMs não tem um cache dedicado, mas apenas armazenamento temporário. Por exemplo, se você selecionou o tamanho da VM Standard_E2bds_v5 com o tamanho padrão do disco do sistema operacional de 100 GiB, ele dá suporte a discos do sistema operacional efêmero, mas tem apenas 75 GB de armazenamento temporário. Essa configuração seria padronizada para discos de SO gerenciados se você não especificasse explicitamente. Se você solicitar um disco SO efêmero, um erro de validação será exibido.

  • Se você solicitar o mesmo tamanho de VM Standard_E2bds_v5 com um disco do sistema operacional de 60 GiB, essa configuração usará como padrão discos de sistema operacional efêmero. O tamanho solicitado de 60 GiB é menor que o armazenamento temporário máximo de 75 GiB.

  • Se você selecionar o SKU Standard_E4bds_v5 com disco do sistema operacional de 100 GiB, esse tamanho de VM será compatível com o sistema operacional efêmero e terá um armazenamento temporário de 150 GiB. Se você não especificar o tipo de disco do sistema operacional, por padrão o Azure provisionará um disco do sistema operacional efêmero para o pool de nós.

Chaves gerenciadas pelo cliente

Você pode gerenciar a criptografia do disco do sistema operacional efêmero com suas próprias chaves em um cluster do AKS. Para obter mais informações, confira Usar a chave Gerenciada pelo Cliente com o disco do Azure no AKS.

Volumes

O Kubernetes normalmente trata pods individuais como recursos efêmeros e descartáveis. Os aplicativos têm diferentes abordagens disponíveis de uso e persistência de dados. Um volume representa uma maneira de armazenar, recuperar e persistir dados entre os pods e por meio do ciclo de vida do aplicativo.

Os volumes tradicionais são criados como recursos do Kubernetes com suporte do Armazenamento do Azure. Você pode criar volumes de dados de forma manual para atribuí-los diretamente aos pods ou fazer com que o Kubernetes os crie automaticamente. Os volumes de dados podem usar: Discos do Azure, Arquivos do Azure, Azure NetApp Files ou Blobs do Azure.

Observação

Dependendo da SKU da VM que você está usando, o driver da CSI do Azure Data Box Disk pode ter um limite de volume por nó. Para algumas VMs de alto desempenho (por exemplo, 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.

Para ajudar a determinar o melhor ajuste para sua carga de trabalho entre Arquivos do Azure e Azure NetApp Files, examine as informações fornecidas no artigo comparação entre Arquivos do Azure e Azure NetApp Files.

Disco do Azure

Use os Discos do Azure para criar um recurso DataDisk do Kubernetes. Os tipos de disco incluem:

  • SSDs Premium (recomendado para a maioria das cargas de trabalho)
  • Discos Ultra
  • SSDs Standard
  • HDDs Standard

Dica

Para a maioria das cargas de trabalho de desenvolvimento e produção, use os SDDs Premium.

Devido ao fato de ser montado como ReadWriteOnce, o Disco do Azure é disponibilizado apenas para um único nó. Para volumes de armazenamento que podem ser acessados por pods simultaneamente em vários nós, use Arquivos do Azure.

Arquivos do Azure

Use Arquivos do Azure para montar um compartilhamento por protocolo SMB versão 3.1.1 ou NFS (Sistema de Arquivos de Rede) versão 4.1. Os Arquivos do Azure permitem que você compartilhe dados em vários nós e pods e podem usar:

  • O armazenamento Premium do Azure, com suporte de SSDs de alto desempenho
  • Armazenamento Standard do Azure com suporte de HDDs regulares

Azure NetApp Files

  • Armazenamento Ultra
  • Armazenamento Premium
  • Armazenamento Standard

Armazenamento do Blobs do Azure

Use Armazenamento de Blobs do Azure para criar um contêiner de armazenamento de blobs e montá-lo usando o protocolo NFS v3.0 ou BlobFuse.

  • Blobs de bloco

Tipos de volumes

Os volumes do Kubernetes representam mais do que apenas um disco tradicional para armazenar e recuperar informações. Volumes Kubernetes também podem ser usados como uma forma de injetar dados em um pod para uso pelos contêineres.

Tipos comuns de volume no Kubernetes incluem:

emptyDir

Normalmente usado como espaço temporário para um pod. Todos os contêineres dentro de um pod podem acessar os dados no volume. Os dados gravados nesse tipo de volume persistem apenas durante o ciclo de vida do pod. Depois de excluir o pod, o volume é removido. Este volume normalmente usa o armazenamento subjacente em disco do nó local, no entanto, ele também pode existir apenas na memória do nó.

segredo

Você pode usar volumes secretos para injetar dados confidenciais em pods, como senhas.

  1. Crie um segredo usando a API do Kubernetes.
  2. Defina o pod ou a implantação e solicite um segredo específico.
    • Os segredos só são fornecidos a nós com um pod agendado que os exige.
    • O segredo é armazenado em tmpfs, não gravado em disco.
  3. Quando você exclui o último pod em um nó que exige um segredo, o segredo é excluído do tmpfs do nó.
    • Os segredos são armazenados dentro de um determinado namespace e só podem ser acessados por pods dentro do mesmo namespace.

configMap

Você pode usar o configMap para injetar propriedades do par chave-valor nos pods, como informações de configuração do aplicativo. Defina as informações de configuração do aplicativo como um recurso do Kubernetes, que pode ser facilmente atualizado e aplicado a novas instâncias de pods à medida que são implantadas.

Como usar um segredo:

  1. Crie um ConfigMap usando a API do Kubernetes.
  2. Solicite o ConfigMap ao definir um pod ou uma implantação.
    • Os ConfigMaps são armazenados dentro de um determinado namespace e só podem ser acessados por pods dentro do mesmo namespace.

Volumes persistentes

Os volumes definidos e criados como parte do ciclo de vida do pod existirão somente enquanto o pod não for excluído. Pods geralmente esperam que seu armazenamento permaneça se um pod ser reagendado em um host diferente durante um evento de manutenção, especialmente em StatefulSets. Um volume persistente (VP) é um recurso de armazenamento criado e gerenciado pela API do Kubernetes que pode existir além do tempo de vida de um pod individual.

Você pode usar os seguintes serviços de dados do Armazenamento do Azure para fornecer o volume persistente:

Conforme observado na seção Volumes, a escolha de Discos do Azure ou Arquivos do Azure geralmente é determinada pela necessidade de acesso simultâneo aos dados ou ao nível de desempenho.

Diagrama de volumes persistentes em um cluster do AKS (Serviço de Kubernetes do Azure)

Um administrador de cluster pode criar um volume persistente estaticamente ou um volume pode ser criado dinamicamente pelo servidor de API do Kubernetes. Se um pod for agendado e solicitar armazenamento não disponível no momento, o Kubernetes poderá criar o armazenamento subjacente de Arquivo ou Discos do Azure e anexá-lo ao pod. A dinâmica de provisionamento usa uma classe de armazenamento para identificar qual tipo de recurso precisa ser criado.

Importante

Volumes persistentes não podem ser compartilhados por pods do Windows e do Linux devido a diferenças no suporte do sistema de arquivos entre os dois sistemas operacionais.

Classes de armazenamento

Para especificar diferentes camadas de armazenamento, como Premium e Standard, você pode criar uma classe de armazenamento.

Uma classe de armazenamento também define uma política de recuperação. Quando você exclui o volume persistente, a política de recuperação controla o comportamento do recurso de armazenamento do Azure subjacente. O recurso subjacente pode ser excluído ou mantido para uso com um pod futuro.

Para clusters que usam os drivers de CSI (Interface de Armazenamento de Contêiner), as seguintes classes de armazenamento extra são criadas:

Classe de armazenamento Descrição
managed-csi Usa o LRS (armazenamento com redundância local) do Azure SSD Standard para criar um disco gerenciado. A política de recuperação garante que o Disco do Azure subjacente é excluído quando o volume persistente que o usa é excluído. A classe de armazenamento também configura os volumes persistentes para serem expansíveis. Você pode editar a declaração de volume persistente para especificar o novo tamanho. 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 (armazenamento com redundância local) Premium do Azure para criar um disco gerenciado. A política de recuperação novamente garante que o Disco do Azure subjacente é excluído quando o volume persistente que o usa é excluído. Da mesma forma, essa classe de armazenamento permite que volumes persistentes sejam expandidos. 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.
azurefile-csi Usa o armazenamento Standard do Azure para criar um Compartilhamento de Arquivo do Azure. A política de recuperação garante que o Compartilhamento de Arquivos do Azure subjacente é excluído quando o volume persistente que o usa é excluído.
azurefile-csi-premium Usa o armazenamento Premium do Azure para criar um Compartilhamento de Arquivo do Azure. A política de recuperação garante que o Compartilhamento de Arquivos do Azure subjacente é excluído quando o volume persistente que o usa é excluído.
azureblob-nfs-premium Usa o armazenamento Premium do Azure para criar um contêiner de armazenamento de Blobs do Azure e conectar-se usando o protocolo NFS v3. A política de recuperação garante que o contêiner de armazenamento de blobs do Azure subjacente seja excluído quando o volume persistente que o usa for excluído.
azureblob-fuse-premium Usa o armazenamento Premium do Azure para criar um contêiner de armazenamento de Blobs do Azure e conectar-se usando o BlobFuse. A política de recuperação garante que o contêiner de armazenamento de blobs do Azure subjacente seja excluído quando o volume persistente que o usa for excluído.

A menos que você especifique uma classe de armazenamento para um volume persistente, a classe de armazenamento padrão será usada. Verifique se os volumes usam o armazenamento apropriado necessário ao solicitar volumes persistentes.

Importante

Da versão 1.21 do Kubernetes em diante, o AKS usa apenas drivers da CSI por padrão e a migração para CSI está habilitada. Embora os volumes persistentes na árvore continuem funcionando, começando com a versão 1.26, o AKS não dará mais suporte a volumes criados usando o driver na árvore e o armazenamento provisionado para arquivos e disco.

A classe default será a mesma que managed-csi.

A partir do Kubernetes versão 1.29, ao implantar clusters do AKS (Serviço de Kubernetes do Azure) em várias zonas de disponibilidade, o AKS agora utiliza o ZRS (armazenamento com redundância de zona) para criar discos gerenciados em classes de armazenamento internas. O ZRS garante a replicação síncrona dos discos gerenciados do Azure em várias zonas de disponibilidade do Azure na região escolhida. Essa estratégia de redundância melhora a resiliência dos aplicativos e protege os dados contra falhas de datacenter.

No entanto, é importante observar que o ZRS (armazenamento com redundância de zona) tem um custo mais alto em comparação ao LRS (armazenamento com redundância local). Se a otimização de custo for uma prioridade, você poderá criar uma nova classe de armazenamento com o parâmetro skuname definido como LRS. Em seguida, você poderá usar a nova classe de armazenamento na PVC (Declaração de Volume Persistente).

Você pode criar uma classe de armazenamento para outras necessidades usando kubectl. O seguinte exemplo usa discos gerenciados Premium e especifica que o Disco do Azure subjacente deverá ser mantido quando você excluir o pod:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Observação

O AKS reconcilia as classes de armazenamento padrão e substituirá as alterações feitas nessas classes de armazenamento.

Para obter mais informações sobre classes de armazenamento, consulte StorageClass no Kubernetes.

Declarações de volume persistente

Solicitações PVC (declaração de volume persistente) de uma classe de armazenamento particular, modo de acesso e tamanho. O servidor de API do Kubernetes poderá provisionar dinamicamente o recurso de Armazenamento do Azure subjacente se nenhum recurso existente puder atender à declaração com base na classe de armazenamento definida.

A definição de pod inclui a montagem de volume depois que o volume for conectado no pod.

Diagrama de declarações de volumes persistentes em um cluster do AKS (Serviço de Kubernetes do Azure)

Depois que um recurso de armazenamento disponível é atribuído ao armazenamento de solicitação de pod, o volume persistente é vinculado a uma declaração de volume persistente. Volumes persistentes são mapeados para declarações em um mapeamento 1:1.

O manifesto YAML do exemplo a seguir mostra uma declaração de volume persistente que usa a classe de armazenamento managed-premium e solicita um Disco do Azure 5Gi:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Ao criar uma definição de pod, você também especifica:

  • A declaração de volume persistente para solicitar o armazenamento desejado.
  • A montagem de volume para que seus aplicativos leiam e gravem dados.

O manifesto YAML do exemplo a seguir mostra como a declaração anterior de volume persistente pode ser usada para montar um volume em /mnt/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Para montar um volume em um contêiner do Windows, especifique a letra e o caminho da unidade. Por exemplo:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

Próximas etapas

Para ver as práticas recomendadas associadas, confira Melhores práticas de armazenamento e backup no AKS e Considerações de armazenamento do AKS.

Para ver como usar drivers CSI, consulte os seguintes artigos de instruções:

Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, confira os seguintes artigos: