Partilhar via

Opções de armazenamento para um cluster Kubernetes

  • Artigo

Este artigo compara os recursos de armazenamento do Amazon Elastic Kubernetes Service (Amazon EKS) e do Azure Kubernetes Service (AKS) e descreve as opções para armazenar dados de carga de trabalho no AKS.

Nota

Este artigo faz parte de uma série de artigos que ajudam os profissionais familiarizados com o Amazon EKS a entender o Serviço Kubernetes do Azure (AKS).

Opções de armazenamento do Amazon EKS

Ao executar aplicativos que exigem armazenamento de dados, o Amazon EKS oferece diferentes tipos de volumes para armazenamento temporário e duradouro.

Volumes Efémeros

Para aplicativos que exigem volumes locais temporários, mas não precisam persistir dados após reinicializações, volumes efêmeros podem ser usados. O Kubernetes suporta diferentes tipos de volumes efêmeros, como emptyDir, configMap, downwardAPI, secrete hostpath. Para garantir a eficiência de custos e o desempenho, é importante escolher o volume de host mais apropriado. No Amazon EKS, você pode usar gp3 como o volume raiz do host, que oferece preços mais baixos do que os volumes gp2.

Outra opção para volumes temporários é armazenamento de instâncias do Amazon EC2, que fornece armazenamento temporário em nível de bloco para instâncias Amazon EC2. Esses volumes são fisicamente conectados aos hosts e só existem durante o tempo de vida da instância. O uso de volumes de armazenamento local no Kubernetes requer particionamento, configuração e formatação dos discos usando dados de usuário do Amazon EC2.

Volumes persistentes

Embora o Kubernetes seja normalmente associado à execução de aplicativos sem monitoração de estado, há casos em que o armazenamento de dados persistente é necessário. Volumes Persistentes (PVs) do Kubernetes podem ser usados para armazenar dados independentemente dos pods, permitindo que os dados persistam além da vida útil de um determinado pod. O Amazon EKS oferece suporte a diferentes tipos de opções de armazenamento para PVs, incluindo Amazon EBS, Amazon EFS, Amazon FSx for Lustree Amazon FSx for NetApp ONTAP.

volumes de do Amazon EBS são adequados para armazenamento em nível de bloco e são ideais para bancos de dados e aplicações intensivas em throughput. Os usuários do Amazon EKS podem usar a última geração de armazenamento em bloco gp3 para obter um equilíbrio entre preço e desempenho. Para aplicações de alto desempenho, podem ser utilizados volumes io2 Block Express.

Amazon EFS é um sistema de arquivos elástico e sem servidor que pode ser compartilhado entre vários contêineres e nós. Ele cresce e diminui automaticamente à medida que os arquivos são adicionados ou removidos, eliminando a necessidade de planejamento de capacidade. O de driver do Amazon Elastic File System Container Storage Interface (CSI) é usado para integrar o Amazon EFS ao Kubernetes.

Amazon FSx for Lustre fornece armazenamento paralelo de arquivos de alto desempenho, ideal para cenários que exigem operações de alta taxa de transferência e baixa latência. Ele pode ser vinculado a um repositório de dados do Amazon S3 para armazenar grandes conjuntos de dados. O Amazon FSx for NetApp ONTAP é uma solução de armazenamento compartilhado totalmente gerenciada criada no sistema de arquivos ONTAP da NetApp.

Os usuários do Amazon EKS podem utilizar ferramentas como AWS Compute Optimizer e Velero para otimizar as configurações de armazenamento e gerenciar backups e snapshots.

Opções de armazenamento AKS

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 poderão precisar de:

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

Este artigo apresenta as opções de armazenamento e os principais conceitos que fornecem armazenamento para seus aplicativos no AKS.

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 por seus contêineres.

Os tipos de volume comuns no Kubernetes incluem EmptyDirs, Secrete ConfigMaps.

EmptyDirs

Para um Pod que define um volume emptyDir, o volume é criado assim que o Pod é atribuído a um nó. Como o nome sugere, o volume emptyDir está inicialmente vazio. Todos os contentores no Pod podem ler e gravar os mesmos arquivos no volume emptyDir, embora esse volume possa ser montado nos mesmos ou em diferentes caminhos em cada contentor. Quando um Pod é removido de um nó por qualquer motivo, os dados no emptyDir são excluídos permanentemente.

Segredos

Um Secret é um objeto que contém uma pequena quantidade de dados confidenciais, tal como uma senha, token ou chave. Caso contrário, essas informações seriam incluídas em uma especificação do Pod ou imagem de contêiner. Ao usar um segredo, você evita incorporar dados confidenciais diretamente no código do aplicativo. Como os Segredos podem ser criados independentemente dos Pods que os usam, há um risco reduzido de expor o Segredo (e seus dados) durante os processos de criação, visualização e edição de Pods. O Kubernetes, juntamente com os aplicativos em execução em seu cluster, também pode tomar precauções extras com o Secrets, como impedir que dados confidenciais sejam gravados em armazenamento não volátil. Embora os Segredos sejam semelhantes ao ConfigMaps, eles são projetados especificamente para armazenar dados confidenciais.

Você pode usar o Secrets para os seguintes fins:

O plano de controle do Kubernetes também usa Secrets, como token de bootstrap Secrets, que são um mecanismo para ajudar a automatizar o registro de nós.

ConfigMaps

Um ConfigMap é um objeto Kubernetes usado para armazenar dados não confidenciais em pares chave-valor. Pods podem consumir ConfigMaps como variáveis de ambiente, argumentos de linha de comando ou como ficheiros de configuração num volume . Um ConfigMap permite-lhe desacoplar a configuração específica do ambiente das suas imagens de contentor, de modo a que as suas aplicações sejam facilmente portáteis.

ConfigMap não fornece sigilo ou criptografia. Se os dados que você deseja armazenar forem confidenciais, use um Secret em vez de um ConfigMap, ou use ferramentas adicionais (de terceiros) para manter seus dados privados.

Você pode usar um ConfigMap para definir dados de configuração separadamente do código do aplicativo. Por exemplo, imagine que está a desenvolver uma aplicação que pode executar no seu próprio computador (para desenvolvimento) e na nuvem (para lidar com tráfego real). Você escreve o código para procurar em uma variável de ambiente chamada DATABASE_HOST. Localmente, você define essa variável como localhost. Na nuvem, defina-o para se referir a um serviço do Kubernetes que expõe o componente de base de dados ao cluster. Isso permite que você busque uma imagem de contêiner em execução na nuvem e depure exatamente o mesmo código localmente, se necessário.

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 gerido 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 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 Azure Kubernetes Services (AKS).

Um administrador de cluster pode estaticamente criar um volume persistente ou um volume pode ser criado dinamicamente pelo servidor de API do Kubernetes. Se um pod estiver agendado e solicitar armazenamento que não está disponível no momento, o Kubernetes poderá criar o disco do Azure ou o armazenamento de ficheiros subjacente e anexá-lo ao pod. O provisionamento dinâmico usa uma classe de armazenamento para identificar que tipo de recurso 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.

Se tu quiseres uma solução totalmente gerida para acesso a dados ao nível de bloco, considera usar Armazenamento de Contentores do Azure em vez dos drivers CSI. O Armazenamento de Contêineres do Azure integra-se ao Kubernetes, permitindo o provisionamento dinâmico e automático de volumes persistentes. O Armazenamento de Contêiner do Azure dá suporte a Discos do Azure, Discos Efémeros e Azure Elastic SAN (visualização) como armazenamento de suporte, oferecendo flexibilidade e escalabilidade para aplicações com estado executadas em clusters do Kubernetes.

Classes de armazenamento

Para especificar diferentes níveis de armazenamento, como premium ou standard, você pode criar uma classe de armazenamento .

Uma classe de armazenamento também define uma política de recuperação de . 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 de Armazenamento de Contêiner do Azure, você verá uma classe de armazenamento adicional chamada acstor-<storage-pool-name>. Uma classe de armazenamento interno também é criada.

Para clusters que usam drivers CSI (Container Storage Interface), as seguintes classes de armazenamento extra são criadas:

Classe de armazenamento Descrição
managed-csi Usa o armazenamento localmente redundante (LRS) do SSD padrão 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 usou for 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. Em vigor a partir da versão 1.29 do Kubernetes, nos clusters do Serviço Kubernetes do Azure (AKS) implantados em várias zonas de disponibilidade, essa classe de armazenamento utiliza o armazenamento com redundância de zona (ZRS) do SSD padrão do Azure para criar discos gerenciados.
managed-csi-premium Usa o armazenamento localmente redundante (LRS) do Azure Premium 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. Em vigor a partir da versão 1.29 do Kubernetes, nos clusters do Serviço Kubernetes do Azure (AKS) implantados em várias zonas de disponibilidade, essa classe de armazenamento utiliza o ZRS (Armazenamento com Redundância de Zona Premium) do Azure Premium para criar discos gerenciados.
azurefile-csi Usa o armazenamento padrão do Azure para criar um compartilhamento de arquivos do Azure. A política de recuperação assegura que a partilha de ficheiros do Azure subjacente seja eliminada quando o volume persistente que a utilizava é eliminado.
azurefile-csi-premium Usa o armazenamento Premium do Azure para criar um compartilhamento de arquivos do Azure. A política de recuperação assegura que a partilha de ficheiros do Azure subjacente seja eliminada quando o volume persistente que a utilizava é eliminado.
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 contentor de armazenamento de blobs do Azure subjacente seja eliminado quando o volume persistente que o utilizou for eliminado.
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 contentor de armazenamento de blobs do Azure subjacente seja eliminado quando o volume persistente que o utilizou for eliminado.

A menos que você especifique uma classe de armazenamento para um volume persistente, a classe de armazenamento padrão é usada. 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 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 classe default será a mesma que managed-csi.

Em vigor a partir da versão 1.29 do Kubernetes, quando você implanta clusters do Serviço Kubernetes do Azure (AKS) em várias zonas de disponibilidade, o AKS agora utiliza o armazenamento com redundância de zona (ZRS) para criar discos gerenciados dentro de classes de armazenamento internas. O ZRS garante a replicação síncrona de seus discos gerenciados do Azure em várias zonas de disponibilidade do Azure na região escolhida. Essa estratégia de redundância aumenta a resiliência de seus aplicativos e protege seus dados contra falhas no datacenter.

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

Você pode criar uma classe de armazenamento para outras necessidades usando kubectl. O exemplo seguinte usa discos geridos premium e especifica que o disco Azure subjacente deve ser retido ao 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

Lembre-se de que 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.

Declarações de volume persistentes

Uma declaração de volume persistente (PVC) solicita armazenamento de uma determinada classe de armazenamento, modo de acesso e tamanho. O servidor de API do Kubernetes pode 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 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 do Azure Kubernetes Services (AKS).

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

O exemplo de manifesto YAML a seguir mostra uma reivindicação de volume persistente que usa a classe de armazenamento gerenciado-premium e solicita um Disco do Azure de 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 de montagem de volume para que seus aplicativos leiam e gravem 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
...

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

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.

Os requisitos de tamanho e as recomendações para discos temporários do sistema operacional estão disponíveis na documentação da VM do Azure no. 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 sistema operacional 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.

  • Se você solicitar o mesmo tamanho Standard_E2bds_v5 VM com um disco de sistema operacional de 60 GiB, essa configuração será padronizada para discos de sistema operacional efêmeros. A dimensão solicitada de 60 GiB é inferior ao armazenamento temporário máximo de 75 GiB.
  • Se você selecionar Standard_E4bds_v5 SKU com disco de 100 GiB do sistema operacional, esse tamanho de VM suporta sistema operacional efêmero e tem 150 GiB de armazenamento temporário. Se você não especificar o tipo de disco do sistema operacional, por padrão, o Azure provisiona um disco efêmero do sistema operacional para o pool de nós.

Chaves gerenciadas 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 os "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 de volume de 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, Azure NetApp Files, ou Blobs do Azure.

Nota

Dependendo da SKU da VM que estiveres a usar, 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, examine a coluna Max discos de dados para cada SKU de VM oferecido. 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.

Azure Disk

Por padrão, um cluster AKS vem com classes de armazenamento pré-criadas managed-csi que managed-csi-premium usam o armazenamento em disco. Semelhante ao Amazon EBS, essas classes criam um disco gerenciado ou dispositivo de bloco conectado ao nó para acesso ao pod.

As classes de disco permitem o provisionamento de volume estático e dinâmico . A política de recuperação garante que o disco seja excluído com o volume persistente. Você pode expandir o disco editando a declaração de volume persistente.

Essas classes de armazenamento usam discos gerenciados do Azure com LRS (armazenamento com redundância local). LRS significa que os dados têm três cópias síncronas em um único local físico em uma região primária do Azure. O LRS é a opção de replicação menos dispendiosa, mas não oferece proteção contra uma falha no datacenter. Você pode definir classes de armazenamento personalizadas que usam discos gerenciados de armazenamento com redundância de zona (ZRS). O armazenamento com redundância de zona (ZRS) replica de forma síncrona o disco gerenciado do Azure em três zonas de disponibilidade do Azure na região selecionada. Cada zona de disponibilidade é um local físico separado com alimentação, refrigeração e rede independentes. Os discos ZRS fornecem pelo menos 99,9999999999% (12 9's) de durabilidade ao longo de um determinado ano. Um disco gerenciado pelo ZRS pode ser conectado por uma máquina virtual em uma zona de disponibilidade de diferente. Atualmente, os discos ZRS não estão disponíveis em todas as regiões do Azure. Para obter mais informações sobre discos ZRS, consulte opção de armazenamento redundante de zona (ZRS) para discos do Azure parade alta disponibilidade . Além disso, para reduzir o risco de perda de dados, pode fazer cópias de segurança regulares ou instantâneos dos dados de Armazenamento em Disco, usando a funcionalidade de Backup do Serviço Kubernetes do Azure ou soluções de terceiros, como o Velero ou o Backup do Azure , que podem usar tecnologias de instantâneo incorporadas.

Você pode usar o Disco do Azure para criar um recurso de Kubernetes Disco de Dados. Os tipos de discos incluem:

Dica

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

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

Discos SSD Premium v2 do Azure

Os discos SSD Premium v2 do Azure oferecem cargas de trabalho empresariais intensas de E/S, uma latência de disco de submilissegundos consistente e IOPS e taxa de transferência elevadas. O desempenho (capacidade, taxa de transferência e IOPS) dos discos SSD Premium v2 pode ser configurado de forma independente a qualquer momento, tornando mais fácil para mais cenários serem econômicos e, ao mesmo tempo, atender às necessidades de desempenho. Para obter mais informações sobre como configurar um cluster AKS novo ou existente para usar discos SSD Premium v2 do Azure, consulte Usar discos SSD Premium v2 do Azure no Serviço Kubernetes do Azure.

Armazenamento de Discos Ultra

O Ultra Disk Storage é uma camada de disco gerenciado do Azure que oferece alta taxa de transferência, IOPS alta e armazenamento em disco consistente de baixa latência para VMs do Azure. O Ultra Disk Storage destina-se a cargas de trabalho pesadas em dados e transações. Como outros SKUs de armazenamento em disco e o Amazon EBS, o Ultra Disk Storage monta um pod de cada vez e não fornece acesso simultâneo.

Use o sinalizador --enable-ultra-ssd para ativar o Ultra Disk Storage no seu cluster AKS.

Se você escolher Ultra Disk Storage, esteja ciente de suas limitações e certifique-se de selecionar um tamanho de VM compatível. O Ultra Disk Storage está disponível com replicação LRS (Local Redundant Storage, armazenamento com redundância local).

Traga as suas próprias chaves (BYOK)

O Azure criptografa todos os dados em um disco gerenciado em repouso. Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter mais controle sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia em repouso para o sistema operacional e discos de dados para seus clusters AKS. Para obter mais informações, consulte Traga suas próprias chaves (BYOK) com discos gerenciados do Azure no Serviço Kubernetes do Azure (AKS).

Ficheiros do Azure

O Armazenamento em Disco não pode fornecer acesso simultâneo a um volume, mas você pode usar 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 com suporte do Armazenamento do Azure. Esse processo fornece um armazenamento conectado à rede semelhante ao Amazon EFS. Tal como acontece com o armazenamento em disco, existem duas opções:

  • O armazenamento padrão dos Arquivos do Azure é apoiado por unidades de disco rígido (HDDs) regulares.
  • O armazenamento Premium do Azure Files faz backup do compartilhamento de arquivos com unidades SSD de alto desempenho. O tamanho mínimo de compartilhamento de arquivos para Premium é de 100 GB.

O Azure Files tem as seguintes opções de replicação de conta de armazenamento para proteger seus dados em caso de falha:

Para otimizar os custos dos Arquivos do Azure, adquira reservas de capacidade dos Arquivos do Azure.

Azure NetApp Files

Azure NetApp Files é um serviço de armazenamento de arquivos de classe empresarial, de alto desempenho e com cobrança por utilização, em execução no Azure e oferece suporte a volumes que usam NFS (NFSv3 ou NFSv4.1), SMB, e protocolo duplo (NFSv3 e SMB, ou NFSv4.1 e SMB). Os usuários do Kubernetes têm duas opções para usar os volumes do Azure NetApp Files para cargas de trabalho do Kubernetes:

  • Crie volumes de Arquivos NetApp do Azure estaticamente. Neste cenário, a criação de volumes é externa ao AKS. Os volumes são criados usando a CLI do Azure ou a partir do portal do Azure e, em seguida, são expostos ao Kubernetes pela criação de um PersistentVolume. Os volumes de Arquivos NetApp do Azure criados estaticamente têm muitas limitações (por exemplo, incapacidade de serem expandidos, necessidade de provisionamento excessivo e assim por diante). Volumes criados estaticamente não são recomendados para a maioria dos casos de uso.
  • Crie volumes de Arquivos NetApp do Azure dinamicamente, orquestrando através do Kubernetes. Este método é a maneira preferida para criar vários volumes diretamente através do Kubernetes, e isso é conseguido usando Astra Trident. O Astra Trident é um orquestrador de armazenamento dinâmico compatível com CSI que ajuda a provisionar volumes nativamente através do Kubernetes.

Para obter mais informações, consulte Configure Azure NetApp Files para o Serviço Azure Kubernetes.

Armazenamento de Blob do Azure

O de driver CSI (Container Storage Interface) de armazenamento de Blob do Azure é um driver compatível com de especificação CSIusado pelo Serviço Kubernetes do Azure (AKS) para gerenciar o ciclo de vida do armazenamento de Blob do Azure. O CSI é um padrão para expor sistemas arbitrários de armazenamento de blocos e arquivos a cargas de trabalho em contêineres no Kubernetes.

Ao adotar e usar o CSI, o AKS agora pode escrever, implantar e iterar plug-ins para expor sistemas de armazenamento novos ou melhorar os existentes no Kubernetes. Usar drivers CSI no AKS evita a necessidade de mexer no código principal do Kubernetes e esperar pelos seus ciclos de lançamento.

Quando você monta o armazenamento de Blob do Azure como um sistema de arquivos em um contêiner ou pod, ele permite que você use o armazenamento de blob com vários aplicativos que trabalham grandes quantidades de dados não estruturados. Por exemplo:

  • Dados do arquivo de log
  • Imagens, documentos e streaming de vídeo ou áudio
  • Dados de recuperação de desastres

Os dados no armazenamento de objetos podem ser acedidos por aplicações que usam o BlobFuse ou o protocolo NFS (Network File System) 3.0. Antes da introdução do driver CSI de armazenamento de Blob do Azure, a única opção era instalar manualmente um driver sem suporte para acessar o armazenamento de Blob a partir do seu aplicativo em execução no AKS. Quando o driver CSI de armazenamento de Blob do Azure está habilitado no AKS, há duas classes de armazenamento internas: azureblob-fuse-premium e azureblob-nfs-premium.

Para criar um cluster AKS com suporte aos controladores CSI, consulte controladores CSI no AKS. Para saber mais sobre as diferenças de acesso entre cada um dos tipos de armazenamento do Azure usando o protocolo NFS, consulte Comparação do acesso aos Arquivos do Azure, Armazenamento Blob e Arquivos NetApp do Azure com NFS.

Azure HPC Cache

O Cache HPC do Azure acelera o acesso aos seus dados para tarefas HPC, com toda a escalabilidade das soluções na nuvem. Se você escolher essa solução de armazenamento, certifique-se de implantar seu cluster AKS em uma região que ofereça suporte ao cache HPC do Azure.

Servidor NFS

A melhor opção para acesso NFS compartilhado é usar Arquivos do Azure ou Arquivos NetApp do Azure. Você também pode criar um Servidor NFS em uma VM do Azure que exporta volumes.

Lembre-se de que essa opção oferece suporte apenas ao provisionamento estático. Você deve provisionar os compartilhamentos NFS manualmente no servidor e não pode fazê-lo do AKS automaticamente.

Esta solução baseia-se na infraestrutura como serviço (IaaS) e não na plataforma como serviço (PaaS). Você é responsável por gerenciar o servidor NFS, incluindo atualizações do sistema operacional, alta disponibilidade, backups, recuperação de desastres e escalabilidade.

Traga suas próprias chaves (BYOK) com discos do Azure

O Armazenamento do Azure encripta todos os dados numa conta de armazenamento em repouso, incluindo o SO e os discos de dados de um cluster AKS. Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter mais controle sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia no restante do sistema operacional e discos de dados de seus clusters AKS. Para obter mais informações, consulte:

Armazenamento de Contentores do Azure

O Armazenamento de Contêineres do Azure é um serviço de gerenciamento, implantação e orquestração de volumes baseado em nuvem criado nativamente para contêineres. Integra-se com o Kubernetes, permitindo-lhe aprovisionar dinamicamente e automaticamente volumes persistentes para armazenar dados para aplicações com estado em execução em clusters do Kubernetes.

O Armazenamento de Contêineres do Azure utiliza ofertas de Armazenamento do Azure existentes para armazenamento de dados real e oferece uma solução de orquestração e gerenciamento de volumes criada propositalmente para contêineres. As opções de armazenamento de backup suportadas incluem:

  • Azure Disks: controle granular de SKUs e configurações de armazenamento. São adequados para bases de dados de nível 1 e de uso geral.
  • Discos efêmeros: Utiliza recursos de armazenamento local em nós AKS (NVMe ou SSD temporário). Mais adequado para aplicativos sem requisitos de durabilidade de dados ou com suporte integrado à replicação de dados. O AKS descobre o armazenamento efêmero disponível nos nós AKS e os adquire para implantação em volume.
  • Azure Elastic SAN: provisione recursos sob demanda e totalmente gerenciados. Adequado para bancos de dados de uso geral, serviços de streaming e mensagens, ambientes de CD/CI e outras cargas de trabalho de nível 1/camada 2. Vários clusters podem acessar uma única SAN simultaneamente, no entanto, os volumes persistentes só podem ser anexados por um consumidor de cada vez.

Até agora, o fornecimento de armazenamento em nuvem para contêineres exigia o uso de drivers de interface de armazenamento de contêiner individual (CSI) para usar serviços de armazenamento destinados a cargas de trabalho centradas em infraestrutura como serviço (IaaS) e fazê-las funcionar para contêineres. Isso cria sobrecarga operacional e aumenta o risco de problemas com disponibilidade, escalabilidade, desempenho, usabilidade e custo do aplicativo.

O Armazenamento de Contêineres do Azure é derivado do OpenEBS, uma solução de código aberto que fornece recursos de armazenamento de contêiner para o Kubernetes. Ao oferecer uma solução de orquestração de volumes gerenciados por meio de controladores de armazenamento baseados em microsserviços em um ambiente Kubernetes, o Armazenamento de Contêiner do Azure permite um verdadeiro armazenamento nativo de contêiner.

O Armazenamento de Contêiner do Azure é adequado nos seguintes cenários:

  • Acelere iniciativas de VM para contêiner: o Armazenamento de Contêineres do Azure apresenta todo o espectro de ofertas de armazenamento em bloco do Azure que antes estavam disponíveis apenas para VMs e as disponibiliza para contêineres. Isso inclui disco efêmero que fornece latência extremamente baixa para cargas de trabalho como Cassandra, bem como o Azure Elastic SAN que fornece iSCSI nativo e destinos provisionados compartilhados.

  • Simplifique o gerenciamento de volumes com o Kubernetes: ao fornecer orquestração de volumes por meio do plano de controle do Kubernetes, o Armazenamento de Contêineres do Azure facilita a implantação e o gerenciamento de volumes no Kubernetes - sem a necessidade de ir e voltar entre diferentes planos de controle.

  • Reduzir o custo total de propriedade (TCO): melhore a eficiência de custos aumentando a escala de volumes persistentes suportados por pod ou nó. Reduza os recursos de armazenamento necessários para provisionamento compartilhando dinamicamente os recursos de armazenamento. Observe que o suporte de expansão para o pool de armazenamento em si não é suportado.

O Armazenamento de Contêiner do Azure fornece os seguintes benefícios principais:

  • Escalabilidade rápida de pods com monitoração de estado: o Armazenamento de Contêiner do Azure monta volumes persistentes em protocolos de armazenamento de bloco de rede (NVMe-oF ou iSCSI), oferecendo conexão e desconexão rápidas de volumes persistentes. Você pode começar pequeno e implantar recursos conforme necessário, certificando-se de que seus aplicativos não sejam prejudicados ou interrompidos, seja durante a inicialização ou na produção. A resiliência do aplicativo é melhorada com respawns pod em todo o cluster, exigindo movimento rápido de volumes persistentes. Usando protocolos de rede remotos, o Armazenamento de Contêiner do Azure combina perfeitamente com o ciclo de vida do pod para oferecer suporte a aplicativos com estado altamente resilientes e de alta escala no AKS.

  • Desempenho aprimorado para cargas de trabalho com monitoração de estado: o Armazenamento de Contêiner do Azure permite um desempenho de leitura superior e fornece desempenho de gravação próximo ao disco usando NVMe-oF sobre RDMA. Isso permite que os clientes atendam de forma econômica aos requisitos de desempenho para várias cargas de trabalho de contêiner, incluindo uso intensivo de E/S de nível 1, uso geral, sensível à taxa de transferência e desenvolvimento/teste. Acelere o tempo de conexão/desanexação de volumes persistentes e minimize o tempo de failover do pod.

  • Orquestração de volumes nativa do Kubernetes: crie pools de armazenamento e volumes persistentes, capture snapshots e gerencie todo o ciclo de vida dos volumes usando kubectl comandos sem alternar entre conjuntos de ferramentas para diferentes operações do plano de controle.

Soluções de terceiros

Como o Amazon EKS, o AKS é uma implementação do Kubernetes e você pode integrar soluções de armazenamento Kubernetes de terceiros. Aqui estão alguns exemplos de soluções de armazenamento de terceiros para Kubernetes:

  • O Rook transforma sistemas de armazenamento distribuídos em serviços de armazenamento autogerenciáveis automatizando as tarefas do administrador de armazenamento. A Rook fornece seus serviços por meio de um operador Kubernetes para cada provedor de armazenamento.
  • O GlusterFS é um sistema de arquivos de rede escalável gratuito e de código aberto que usa hardware comum pronto para uso para criar soluções de armazenamento grandes e distribuídas para tarefas com uso intensivo de dados e largura de banda.
  • O Ceph fornece um serviço de armazenamento unificado confiável e escalável com interfaces de objetos, blocos e arquivos a partir de um único cluster construído a partir de componentes de hardware de mercadoria.
  • O armazenamento de objetos multicloud MinIO permite que as empresas criem infraestrutura de dados compatível com o AWS S3 em qualquer nuvem, fornecendo uma interface consistente e portátil para seus dados e aplicativos.
  • O Portworx é uma solução completa de armazenamento e gerenciamento de dados para projetos Kubernetes e iniciativas baseadas em contêineres. O Portworx oferece armazenamento granular de contêiner, recuperação de desastres, segurança de dados e migrações multicloud.
  • O Quobyte fornece armazenamento de arquivos e objetos de alto desempenho que você pode implantar em qualquer servidor ou nuvem para dimensionar o desempenho, gerenciar grandes quantidades de dados e simplificar a administração.
  • O Ondat oferece uma camada de armazenamento consistente em qualquer plataforma. Você pode executar um banco de dados ou qualquer carga de trabalho persistente em um ambiente Kubernetes sem precisar gerenciar a camada de armazenamento.

Considerações sobre armazenamento do Kubernetes

Considere os seguintes fatores ao escolher uma solução de armazenamento para Amazon EKS ou AKS.

Modos de acesso à classe de armazenamento

No Kubernetes versão 1.21 e mais recente, as classes de armazenamento AKS e Amazon EKS usam drivers CSI (Container Storage Interface) somente e por padrão.

Diferentes serviços suportam classes de armazenamento que têm diferentes modos de acesso.

Serviço ReadWriteOnce ReadOnlyMuitos ReadWriteMuitos
Discos do Azure X
Ficheiros do Azure X X X
Azure NetApp Files X X X
Servidor NFS X X X
Azure HPC Cache X X X

Provisionamento dinâmico vs estático

Provisione volumes dinamicamente para reduzir a sobrecarga de gerenciamento da criação estática de volumes persistentes. Defina uma política de recuperação correta para evitar ter discos não utilizados ao excluir pods.

Backup

Escolha uma ferramenta para fazer backup de dados persistentes. A ferramenta deve corresponder ao seu tipo de armazenamento, como instantâneos, Backup do Azure, Velero ou Kasten.

Otimização de custos

Para otimizar os custos de Armazenamento do Azure, use as reservas do Azure. Certifique-se de verificar quais serviços oferecem suporte às Reservas do Azure. Consulte também Gerenciamento de custos para um cluster Kubernetes.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos