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

  • Artigo

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

Vários pods podem precisar:

  • Partilhe os mesmos volumes de dados.
  • Reanexe volumes de dados se o pod for reagendado em um nó diferente.

Também pode ser necessário 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 de opções de armazenamento para aplicativos em um cluster de Serviços Kubernetes (AKS) do Azure.

Disco de 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 que o estado local persista, esse comportamento oferece valor limitado enquanto fornece algumas desvantagens. Essas desvantagens incluem, mas não estão limitadas a, provisionamento de nó mais lento e latência de leitura/gravação mais alta.

Por outro lado, os discos efêmeros do sistema operacional são armazenados apenas na máquina host, assim como um disco temporário. Com essa configuração, você obtém menor latência de leitura/gravação, juntamente com escalonamento de nó mais rápido e atualizações de cluster.

Nota

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

Requisitos de tamanho e recomendações para discos de SO efêmeros estão disponíveis na documentação da VM do Azure. A seguir estão algumas considerações gerais de dimensionamento:

  • Se você optar por usar o tamanho padrão da VM AKS Standard_DS2_v2 SKU com o tamanho de disco padrão do sistema operacional de 100 GiB, o tamanho padrão da VM suporta SO efêmero, mas tem apenas 86 GiB de tamanho de cache. Essa configuração seria padrão para discos gerenciados se você não a especificar explicitamente. Se você solicitar um sistema operacional efêmero, receberá um erro de validação.

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

  • Se você selecionar o Standard_D8s_v3 SKU com disco de 100 GB de sistema operacional, esse tamanho de VM suporta sistema operacional efêmero e tem 200 GiB de espaço em cache. Se você não especificar o tipo de disco do sistema operacional, o pool de nós receberá um sistema operacional efêmero por padrão.

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

Chaves geridas pelo cliente

Você pode gerenciar a criptografia para seu disco efêmero do sistema operacional com suas próprias chaves em um cluster AKS. Para obter mais informações, consulte 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 para o uso e persistência de dados. Um volume representa uma maneira de armazenar, recuperar e persistir dados em pods e durante o ciclo de vida do aplicativo.

Os volumes tradicionais são criados como recursos do Kubernetes apoiados pelo Armazenamento do Azure. Você pode criar manualmente volumes de dados para serem atribuídos a pods diretamente ou fazer com que o Kubernetes os crie automaticamente. Os volumes de dados podem usar: Disco do Azure, Arquivos do Azure, Arquivos NetApp do Azure ou Blobs do Azure.

Nota

Dependendo da SKU da VM que você está usando, o driver CSI do Disco do Azure 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 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.

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

Disco do Azure

Use o Disco do Azure para criar um recurso Kubernetes DataDisk . Os tipos de discos incluem:

  • Discos Ultra
  • Discos SSD Premium
  • SSDs Standard
  • Discos HDD Standard

Gorjeta

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

Como o Disco do Azure é montado como ReadWriteOnce, eles só estão disponíveis para um único nó. Para volumes de armazenamento acessíveis por pods em vários nós simultaneamente, use os Arquivos do Azure.

Ficheiros do Azure

Use Arquivos do Azure para montar um compartilhamento SMB (Server Message Block) versão 3.1.1 ou um compartilhamento NFS (Network File System) versão 4.1 apoiado por uma conta de armazenamento do Azure em pods. Os Arquivos do Azure permitem compartilhar dados entre vários nós e pods e podem usar:

  • Armazenamento Premium do Azure apoiado por SSDs de alto desempenho
  • Armazenamento padrão do Azure apoiado por HDDs normais

Azure NetApp Files

  • Armazenamento Ultra
  • Armazenamento Premium
  • Armazenamento Standard

Armazenamento de Blobs do Azure

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

  • Blobs de Blocos

Tipos de volume

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

Os tipos de volume comuns no Kubernetes incluem:

emptyDir

Comumente 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 a vida útil do pod. Depois de excluir o pod, o volume é excluído. Esse volume normalmente usa o armazenamento em disco do nó local subjacente, embora também possa 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 seu pod ou implantação e solicite um Segredo específico.
    • Os segredos são fornecidos apenas a nós com um pod agendado que os exija.
    • O segredo é armazenado em tmpfs, não gravado em disco.
  3. Quando você exclui o último pod em um nó que requer um Segredo, o Segredo é excluído do tmpfs do nó.
    • Os segredos são armazenados dentro de um determinado namespace e só são acessados por pods dentro do mesmo namespace.

configMap

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

Como usar um segredo:

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

Volumes persistentes

Os volumes definidos e criados como parte do ciclo de vida do pod só existem até que você exclua o pod. Os pods geralmente esperam que seu armazenamento permaneça se um pod for reprogramado em um host diferente durante um evento de manutenção, especialmente em StatefulSets. Um volume persistente (PV) é 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 à camada de desempenho.

Diagrama de volumes persistentes em um cluster do Azure Kubernetes Services (AKS).

Um administrador de cluster pode criar estaticamente um PersistentVolume ou o volume é criado dinamicamente pelo servidor de API do Kubernetes. Se um pod estiver agendado e solicitar armazenamento indisponível no momento, o Kubernetes poderá criar o disco do Azure subjacente ou o armazenamento de arquivos e anexá-lo ao pod. O provisionamento dinâmico usa uma StorageClass para identificar que tipo de armazenamento do Azure precisa ser criado.

Importante

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

Classes de armazenamento

Para definir diferentes níveis de armazenamento, como Premium e Standard, você pode criar um StorageClass.

O StorageClass também define a reclaimPolicy. Quando você exclui o volume persistente, a 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 CSI (Container Storage Interface), são criados os seguintes extrasStorageClasses:

Classe de armazenamento Description
managed-csi Utiliza o armazenamento localmente redundante (LRS) do Azure StandardSSD para criar um Managed Disk. A política de recuperação garante que o Disco do Azure subjacente seja excluído quando o volume persistente que o usou for excluído. A classe de armazenamento também configura os volumes persistentes para serem expansíveis, você só precisa editar a declaração de volume persistente com o novo tamanho.
managed-csi-premium Usa o LRS (armazenamento localmente redundante) Premium do Azure para criar um Disco Gerenciado. A política de recuperação novamente garante que o Disco do Azure subjacente seja excluído quando o volume persistente que o usou for excluído. Da mesma forma, essa classe de armazenamento permite que volumes persistentes sejam expandidos.
azurefile-csi Usa o armazenamento padrão do Azure para criar um compartilhamento de arquivos do Azure. A política de recuperação garante que o compartilhamento de arquivos subjacente do Azure seja excluído quando o volume persistente que o usou for excluído.
azurefile-csi-premium Usa o armazenamento Premium do Azure para criar um compartilhamento de arquivos do Azure. A política de recuperação garante que o compartilhamento de arquivos subjacente do Azure seja excluído quando o volume persistente que o usou for excluído.
azureblob-nfs-premium Usa o armazenamento Premium do Azure para criar um contêiner de armazenamento de Blob do Azure e conectar-se usando o protocolo NFS v3. A política de recuperação garante que o contêiner de armazenamento de Blob do Azure subjacente seja excluído quando o volume persistente que o usou for excluído.
azureblob-fuse-premium Usa o armazenamento Premium do Azure para criar um contêiner de armazenamento de Blob do Azure e conectar-se usando BlobFuse. A política de recuperação garante que o contêiner de armazenamento de Blob do Azure subjacente seja excluído quando o volume persistente que o usou for excluído.

A menos que você especifique um StorageClass para um volume persistente, o StorageClass padrão é usado. Certifique-se de que os volumes usem o armazenamento apropriado de que você precisa ao solicitar volumes persistentes.

Importante

A partir da versão 1.21 do Kubernetes, o AKS usa apenas drivers CSI por padrão e a migração CSI está habilitada. Embora os volumes persistentes existentes na árvore continuem a funcionar, a partir da versão 1.26, o AKS não suportará mais volumes criados usando driver na árvore e armazenamento provisionado para arquivos e disco.

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

Você pode criar um StorageClass para outras necessidades usando kubectlo . O exemplo a seguir usa Discos Gerenciados Premium e especifica que o Disco do Azure subjacente deve ser mantido quando você exclui 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

Nota

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

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

Afirmações de volumes persistentes

Um PersistentVolumeClaim solicita armazenamento de uma determinada StorageClass, modo de acesso e tamanho. O servidor de API do Kubernetes pode provisionar dinamicamente o recurso de armazenamento subjacente do Azure se nenhum recurso existente puder atender à declaração com base no StorageClass definido.

A definição do pod inclui a montagem do volume uma vez que o volume tenha sido conectado ao pod.

Diagrama de declarações de volume persistentes em um cluster dos Serviços Kubernetes do Azure (AKS).

Depois que um recurso de armazenamento disponível tiver sido atribuído ao pod que solicita armazenamento, PersistentVolume será vinculado a um PersistentVolumeClaim. Os volumes persistentes são mapeados 1:1 para declarações.

O exemplo de manifesto YAML a seguir mostra uma declaração de volume persistente que usa o StorageClass premium gerenciado e solicita um tamanho de disco 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 reivindicação de volume persistente para solicitar o armazenamento desejado.
  • O volumeMount para seus aplicativos lerem e gravarem dados.

O exemplo de manifesto YAML a seguir mostra como a declaração de volume persistente anterior 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 da unidade e o caminho. Por exemplo:

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

Próximos passos

Para obter as práticas recomendadas associadas, consulte Práticas recomendadas para armazenamento e backups em Considerações sobre armazenamento AKS e AKS.

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

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