Opções de armazenamento para aplicações no Azure Kubernetes Service (AKS)

  • Artigo

As aplicações em execução no Azure Kubernetes Service (AKS) poderão ter de armazenar e obter dados. Embora algumas cargas de trabalho de aplicação possam utilizar armazenamento local e rápido em nós desnecessários e esvaziados, outras necessitam de armazenamento que persista em volumes de dados mais regulares na plataforma do Azure.

Vários pods podem ter de:

  • Partilhe os mesmos volumes de dados.
  • Volte a anexar volumes de dados se o pod for reagendado num nó diferente.

Também poderá ter de recolher e armazenar dados confidenciais ou informações de configuração da aplicação em pods.

Este artigo apresenta os principais conceitos que fornecem armazenamento às suas aplicações no AKS:

Opções de armazenamento para aplicações num cluster do Azure Kubernetes Services (AKS)

Disco de SO efémero

Por predefinição, o Azure replica automaticamente o disco do sistema operativo de uma máquina virtual para o armazenamento do Azure para evitar a perda de dados quando a VM é relocalizada para outro anfitrião. No entanto, uma vez que os contentores não foram concebidos para manter o estado local, este comportamento oferece um valor limitado ao mesmo tempo que fornece algumas desvantagens. Estas desvantagens incluem, mas não se limitam a, aprovisionamento de nós mais lento e latência de leitura/escrita mais elevada.

Por outro lado, os discos de SO efémeros são armazenados apenas no computador anfitrião, tal como num disco temporário. Com esta configuração, obtém uma latência de leitura/escrita mais baixa, juntamente com o dimensionamento mais rápido de nós e atualizações do cluster.

Nota

Quando não pede explicitamente discos geridos do Azure para o SO, o AKS é predefinido como SO efémero, se possível, para uma determinada configuração do conjunto de nós.

Os requisitos de tamanho e as recomendações para discos de SO efémeros estão disponíveis na documentação da VM do Azure. Seguem-se algumas considerações gerais de dimensionamento:

  • Se optar por utilizar o tamanho predefinido da VM do AKS Standard_DS2_v2 SKU com o tamanho de disco de SO predefinido de 100 GiB, o tamanho predefinido da VM suporta o SO efémero, mas tem apenas 86 GiB de tamanho de cache. Esta configuração seria predefinida para discos geridos se não o especificar explicitamente. Se pedir um SO efémero, receberá um erro de validação.

  • Se pedir o mesmo SKU Standard_DS2_v2 com um disco de SO de 60 GiB, esta configuração seria predefinida como SO efémero. O tamanho pedido de 60 GiB é inferior ao tamanho máximo da cache de 86 GiB.

  • Se selecionar o SKU Standard_D8s_v3 com um disco de SO de 100 GB, este tamanho de VM suporta o SO efémero e tem 200 GiB de espaço em cache. Se não especificar o tipo de disco do SO, o conjunto de nós receberá o SO efémero por predefinição.

A última geração de séries de VMs não tem uma cache dedicada, mas apenas armazenamento temporário. Por exemplo, se tiver selecionado o tamanho da VM Standard_E2bds_v5 com o tamanho de disco de SO predefinido de 100 GiB, este suporta discos de SO efémeros, mas tem apenas 75 GB de armazenamento temporário. Esta configuração seria predefinida para discos de SO geridos se não o especificar explicitamente. Se pedir um disco de SO efémero, receberá um erro de validação.

  • Se pedir o mesmo Standard_E2bds_v5 tamanho da VM com um disco de SO de 60 GiB, esta configuração é predefinida para discos de SO efémeros. O tamanho pedido de 60 GiB é inferior ao armazenamento temporário máximo de 75 GiB.

  • Se selecionar Standard_E4bds_v5 SKU com um disco de SO de 100 GiB, este tamanho de VM suporta o SO efémero e tem 150 GiB de armazenamento temporário. Se não especificar o tipo de disco do SO, por predefinição, o Azure aprovisiona um disco de SO efémero para o conjunto de nós.

Chaves geridas pelo cliente

Pode gerir a encriptação do disco do SO efémero com as suas próprias chaves num cluster do AKS. Para obter mais informações, veja Utilizar a chave Gerida pelo Cliente com o disco do Azure no AKS.

Volumes

Normalmente, o Kubernetes trata pods individuais como recursos efémeros e descartáveis. As aplicações têm diferentes abordagens disponíveis para utilizar e manter dados. Um volume representa uma forma de armazenar, obter e manter dados entre pods e através do ciclo de vida da aplicação.

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

Nota

Consoante o SKU da VM que estiver a utilizar, o controlador CSI do Disco do Azure pode ter um limite de volume por nó. Para algumas VMs de elevado desempenho (por exemplo, 16 núcleos), o limite é de 64 volumes por nó. Para identificar o limite por SKU de VM, reveja a coluna Máximo de discos de dados para cada SKU de VM oferecido. Para obter uma lista dos SKUs de VM oferecidos e os respetivos limites de capacidade detalhados correspondentes, veja Tamanhos de máquinas virtuais para fins gerais.

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

Disco do Azure

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

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

Dica

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

Uma vez que o Disco do Azure está montado como ReadWriteOnce, só estão disponíveis para um único nó. Para volumes de armazenamento acessíveis por pods em vários nós em simultâneo, utilize Ficheiros do Azure.

Ficheiros do Azure

Utilize Ficheiros do Azure para montar uma partilha do Bloco de Mensagens de Servidor (SMB) versão 3.1.1 ou uma partilha do Sistema de Ficheiros de Rede (NFS) versão 4.1 com o apoio de uma conta de armazenamento do Azure para pods. Ficheiros do Azure permite-lhe partilhar dados entre vários nós e pods e pode utilizar:

  • Armazenamento Premium do Azure apoiado por SSDs de elevado desempenho
  • Armazenamento Standard do Azure suportado por HDDs normais

Azure NetApp Files

  • Armazenamento Ultra
  • Armazenamento Premium
  • Armazenamento Standard

Armazenamento de Blobs do Azure

Utilize Armazenamento de Blobs do Azure para criar um contentor de armazenamento de blobs e montá-lo com 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 obter informações. Os volumes do Kubernetes também podem ser utilizados como forma de injetar dados num pod para utilização pelos contentores.

Os tipos de volume comuns no Kubernetes incluem:

emptyDir

Normalmente utilizado como espaço temporário para um pod. Todos os contentores num pod podem aceder aos dados no volume. Os dados escritos neste tipo de volume persistem apenas durante o ciclo de vida do pod. Depois de eliminar o pod, o volume é eliminado. Normalmente, este volume utiliza o armazenamento do disco do nó local subjacente, embora também possa existir apenas na memória do nó.

segredo

Pode utilizar volumes secretos para injetar dados confidenciais em pods, como palavras-passe.

  1. Crie um Segredo com a API do Kubernetes.
  2. Defina o pod ou a implementação e solicite um Segredo específico.
    • Os segredos só são fornecidos aos nós com um pod agendado que os exija.
    • O Segredo é armazenado em tmpfs, não escrito no disco.
  3. Quando elimina o último pod num nó que requer um Segredo, o Segredo é eliminado dos tmpfs do nó.
    • Os segredos são armazenados num determinado espaço de nomes e só são acedidos por pods no mesmo espaço de nomes.

configMap

Pode utilizar configMap para injetar propriedades do par chave-valor em pods, como informações de configuração da aplicação. Defina as informações de configuração da aplicação como um recurso do Kubernetes, facilmente atualizado e aplicado a novas instâncias de pods à medida que são implementados.

Como utilizar um segredo:

  1. Crie um ConfigMap com a API do Kubernetes.
  2. Peça o ConfigMap quando definir um pod ou implementação.
    • Os ConfigMaps são armazenados num determinado espaço de nomes e só são acedidos por pods no mesmo espaço de nomes.

Volumes persistentes

Os volumes definidos e criados como parte do ciclo de vida do pod só existem até eliminar o pod. Muitas vezes, os pods esperam que o armazenamento permaneça se um pod for reagendado num anfitrião diferente durante um evento de manutenção, especialmente em StatefulSets. Um volume persistente (PV) é um recurso de armazenamento criado e gerido pela API do Kubernetes que pode existir para além da duração de um pod individual.

Pode utilizar o Disco do Azure ou Ficheiros do Azure para fornecer o PersistentVolume. Conforme indicado na secção Volumes , a escolha de Discos ou Ficheiros é muitas vezes determinada pela necessidade de acesso simultâneo aos dados ou à camada de desempenho.

Volumes persistentes num cluster do Azure Kubernetes Services (AKS)

Um administrador de cluster pode criar estaticamente um PersistentVolume ou o volume é criado dinamicamente pelo servidor da API do Kubernetes. Se um pod estiver agendado e os pedidos estiverem atualmente indisponíveis de armazenamento, o Kubernetes pode criar o armazenamento de Ficheiros ou Disco do Azure subjacente e anexá-lo ao pod. O aprovisionamento dinâmico utiliza uma StorageClass para identificar que tipo de armazenamento do Azure precisa de ser criado.

Importante

Os volumes persistentes não podem ser partilhados por pods do Windows e linux devido a diferenças no suporte do sistema de ficheiros entre os dois sistemas operativos.

Classes de armazenamento

Para definir diferentes camadas de armazenamento, como Premium e Standard, pode criar uma StorageClass.

StorageClass também define a reclaimPolicy. Quando elimina o volume persistente, a reclaimPolicy controla o comportamento do recurso de armazenamento do Azure subjacente. O recurso de armazenamento subjacente pode ser eliminado ou mantido para utilização com um pod futuro.

Para clusters que utilizam os controladores da Interface de Armazenamento de Contentores (CSI), são criados os seguintes elementos adicionais StorageClasses :

Permissão Razão
managed-csi Utiliza o armazenamento localmente redundante (LRS) do Azure StandardSSD para criar um Disco Gerido. A política de recuperação garante que o Disco do Azure subjacente é eliminado quando o volume persistente que o utilizou é eliminado. A classe de armazenamento também configura os volumes persistentes para serem expansíveis. Só precisa de editar a afirmação de volume persistente com o novo tamanho.
managed-csi-premium Utiliza o armazenamento localmente redundante (LRS) do Azure Premium para criar um Disco Gerido. A política de recuperação garante novamente que o Disco do Azure subjacente é eliminado quando o volume persistente que o utilizou é eliminado. Da mesma forma, esta classe de armazenamento permite a expansão de volumes persistentes.
azurefile-csi Utiliza o armazenamento Standard do Azure para criar uma partilha de ficheiros do Azure. A política de recuperação garante que a partilha de ficheiros subjacente do Azure é eliminada quando o volume persistente que a utilizou é eliminado.
azurefile-csi-premium Utiliza o armazenamento do Azure Premium para criar uma partilha de ficheiros do Azure. A política de recuperação garante que a partilha de ficheiros subjacente do Azure é eliminada quando o volume persistente que a utilizou é eliminado.
azureblob-nfs-premium Utiliza o armazenamento Premium do Azure para criar um contentor de armazenamento de Blobs do Azure e ligar com o protocolo NFS v3. A política de recuperação garante que o contentor de armazenamento de Blobs do Azure subjacente é eliminado quando o volume persistente que o utilizou é eliminado.
azureblob-fuse-premium Utiliza o armazenamento do Azure Premium para criar um contentor de armazenamento de Blobs do Azure e ligar com o BlobFuse. A política de recuperação garante que o contentor de armazenamento de Blobs do Azure subjacente é eliminado quando o volume persistente que o utilizou é eliminado.

A menos que especifique uma StorageClass para um volume persistente, é utilizada a StorageClass predefinida. Certifique-se de que os volumes utilizam o armazenamento adequado de que precisa ao pedir volumes persistentes.

Importante

A partir da versão 1.21 do Kubernetes, o AKS utiliza apenas controladores CSI por predefinição e a migração CSI está ativada. Embora os volumes persistentes existentes na árvore continuem a funcionar, a partir da versão 1.26, o AKS deixará de suportar volumes criados com o controlador na árvore e o armazenamento aprovisionado para ficheiros e disco.

A default classe será igual a managed-csi.

Pode criar uma StorageClass para outras necessidades com kubectl. O exemplo seguinte utiliza Managed Disks Premium e especifica que o Disco do Azure subjacente deve ser mantido quando eliminar 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 predefinidas e substituirá todas as alterações que fizer a essas classes de armazenamento.

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

Afirmações de volumes persistentes

Um PersistentVolumeClaim pede o armazenamento de um storageClass específico, modo de acesso e tamanho. O servidor da API do Kubernetes pode aprovisionar dinamicamente o recurso de armazenamento do Azure subjacente se nenhum recurso existente conseguir cumprir a afirmação com base no StorageClass definido.

A definição do pod inclui a montagem do volume depois de o volume ter sido ligado ao pod.

Afirmações de volume persistentes num cluster do Azure Kubernetes Services (AKS)

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

O seguinte manifesto YAML de exemplo mostra uma afirmação de volume persistente que utiliza o StorageClass gerido-premium e pede um Disco 5Gi de tamanho:

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

Quando cria uma definição de pod, também especifica:

  • A afirmação de volume persistente para pedir o armazenamento pretendido.
  • O volumeMount para as suas aplicações lerem e escreverem dados.

O seguinte manifesto YAML de exemplo mostra como a afirmação de volume persistente anterior pode ser utilizada 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 num contentor do Windows, especifique a letra e o caminho da unidade. Por exemplo:

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

Passos seguintes

Para obter as melhores práticas associadas, veja Melhores práticas para armazenamento e cópias de segurança no AKS e Considerações de Armazenamento do AKS.

Para ver como utilizar controladores CSI, veja os seguintes artigos de procedimentos:

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