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:

• Volumes
• Volumes persistentes
• Classes de armazenamento
• Declarações de volume persistente

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:

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.

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.

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

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:

• Disco do Azure
• Arquivos do Azure
• Armazenamento de Contêiner do Azure (versão prévia)

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.

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.

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:

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.

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

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.

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:

• Drivers da CSI (Interface de Armazenamento de Contêiner) para Disco do Azure, Arquivos do Azure e Armazenamento de Blobs do Azure no Serviço de Kubernetes do Azure
• Usar o driver CSI dos Disco do Azure no Serviço de Kubernetes do Azure
• Usar o driver CSI dos Arquivos do Azure no Serviço de Kubernetes do Azure
• Usar o driver CSI do Armazenamento de Blobs do Azure no Serviço de Kubernetes do Azure
• Configurar o Azure NetApp Files com o Serviço de Kubernetes do Azure

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

• Clusters e cargas de trabalho do Kubernetes/AKS
• Identidade do Kubernetes/AKS
• Kubernetes / segurança AKS
• Redes virtuais do Kubernetes/AKS
• Escala do Kubernetes/AKS