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

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).

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:

  • Discos Ultra
  • SSDs Premium
  • SSDs Standard
  • HDDs Standard

Dica

Para a maioria das cargas de trabalho de desenvolvimento e produção, use o SDD 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 com suporte de conta de armazenamento do Azure para pods. 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 blocos

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 PersistentVolume:

Conforme observado na seção Volumes, a escolha de Discos ou Arquivos 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 PersistentVolume estaticamente, ou o volume 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 um StorageClass para identificar qual tipo de armazenamento do Azure 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 definir diferentes camadas de armazenamento, como Premium e Standard, você pode criar uma StorageClass.

O StorageClass também define a reclaimPolicy. Quando você exclui o volume persistente, o reclaimPolicy controla o comportamento do recurso de armazenamento subjacente do Azure. O recurso de armazenamento 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 StorageClasses extra são criadas:

Classe de armazenamento Descrição
managed-csi Usa o LRS (armazenamento com redundância local) StandardSSD do Azure para criar um Disco Gerenciado. A política de recuperação garante que o Disco do Azure subjacente seja excluído quando o volume persistente que o utilizava for excluído. A classe de armazenamento também configura os volumes persistentes para que sejam expansíveis, você só precisa editar a declaração do volume persistente para incluir o novo tamanho.
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, repetindo, garante que o Disco do Azure subjacente seja excluído quando o volume persistente que o utilizava for excluído. Da mesma forma, essa classe de armazenamento permite que volumes persistentes sejam expandidos.
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 seja excluído quando o volume persistente que o utilizava for 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 utilizava 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 utilizava for excluído.

A menos que você especifique uma StorageClass para um volume persistente, a StorageClass 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.

Você pode criar uma StorageClass para outras necessidades usando kubectl. O seguinte exemplo usa Managed Disks 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 PersistentVolumeClaim de um StorageClass 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 StorageClass 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 PersistentVolume é vinculado a uma PersistentVolumeClaim. Os volumes persistentes são mapeados em 1:1 para declarações.

O manifesto YAML do exemplo a seguir mostra uma declaração de volume persistente que usa o Storage Class premium gerenciado e solicita um Disco Gi 5 de tamanho:

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 volumeMount 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: