Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
À medida que cria e gere clusters no Serviço de Kubernetes do Azure (AKS), as suas aplicações geralmente precisam de armazenamento. Certifique-se de entender as necessidades de desempenho do pod e os métodos de acesso para que possa selecionar o melhor armazenamento para a sua aplicação. O tamanho do nó AKS pode afetar as suas escolhas de armazenamento. Planeje maneiras de fazer backup e testar o processo de restauração para armazenamento anexado.
Este artigo de práticas recomendadas centra-se em considerações de armazenamento para operadores de cluster. Neste artigo, vai aprender a:
- Que tipos de armazenamento estão disponíveis.
- Como dimensionar corretamente os nós AKS para o desempenho do armazenamento.
- Como planear e operar cache distribuído para leituras repetidas do Azure Blob.
- Diferenças entre provisionamento dinâmico e estático de volumes.
- Maneiras de fazer backup e proteger os seus volumes de dados.
Escolha o tipo de armazenamento apropriado
Orientações sobre boas práticas
Entenda as necessidades do seu aplicativo para escolher o armazenamento certo. Utilize armazenamento de alto desempenho apoiado por SSD para cargas de trabalho de produção. Planeje o armazenamento baseado em rede quando precisar de várias conexões simultâneas.
Os aplicativos geralmente exigem diferentes tipos e velocidades de armazenamento. Determine o tipo de armazenamento mais apropriado fazendo as seguintes perguntas.
- Seus aplicativos precisam de armazenamento que se conecta a pods individuais?
- As suas aplicações precisam de armazenamento partilhado entre vários pods?
- O armazenamento é para acesso somente leitura aos dados?
- O armazenamento será usado para gravar grandes quantidades de dados estruturados?
A tabela a seguir descreve os tipos de armazenamento disponíveis e seus recursos:
| Caso de uso | Plugin de volume | Leitura/escrita única | Muitos só de leitura | Leitura/escrita múltipla | Suporte a contêineres do Windows Server |
|---|---|---|---|---|---|
| Configuração partilhada | Ficheiros do Azure | Sim | Sim | Sim | Sim |
| Dados estruturados da aplicação | Discos do Azure | Sim | Não | Não | Sim |
| Dados não estruturados, operações do sistema de ficheiros | BlobFuse | Sim | Sim | Sim | No |
O AKS fornece dois tipos principais de armazenamento seguro para volumes apoiados por Discos do Azure ou Ficheiros do Azure. Ambos usam a Criptografia de Serviço de Armazenamento do Azure (SSE) padrão que criptografa dados em repouso. Os discos não podem ser criptografados usando o Azure Disk Encryption no nível do nó AKS. Com as partilhas do Ficheiros do Azure, não há limite para quantas podem ser montadas num nó.
Os Arquivos do Azure e os Discos do Azure estão disponíveis nas camadas de desempenho Standard e Premium:
-
Discos Premium
- Apoiado por discos de estado sólido (SSDs) de alto desempenho.
- Recomendado para todas as cargas de trabalho de produção.
-
Discos padrão
- Baseado em discos rígidos (HDDs).
- Bom para arquivamento ou dados acessados com pouca frequência.
Embora a camada de armazenamento padrão para o driver CSI do Azure Disk seja SSD Premium, seu StorageClass personalizado pode usar SSD Premium, SSD Standard ou HDD Padrão.
Compreenda as necessidades de desempenho da aplicação e os padrões de acesso para escolher o escalão de armazenamento apropriado. Para obter mais informações sobre tamanhos de Managed Disks e camadas de desempenho, consulte Descrição geral dos Managed Disks do Azure.
Criar e usar classes de armazenamento para definir as necessidades do aplicativo
Defina o tipo de armazenamento desejado usando classes de armazenamento do Kubernetes. A classe de armazenamento é então referenciada no pod ou na especificação de deployment. As definições de classe de armazenamento trabalham juntas para criar o armazenamento apropriado e conectá-lo a pods.
Para obter mais informações, consulte Classes de armazenamento no AKS.
Dimensionar os nós de acordo com as necessidades de armazenamento
Orientações sobre boas práticas
Cada tamanho de nó suporta um número máximo de discos. Diferentes tamanhos de nós também fornecem diferentes quantidades de armazenamento local e largura de banda de rede. Planeie adequadamente para as suas necessidades da aplicação, de modo a implementar o tamanho certo de nós.
Os nós AKS são executados em vários tipos e tamanhos de VM do Azure. Cada tamanho da VM fornece:
- Uma quantidade diferente de recursos de núcleo, como CPU e memória.
- Um número máximo de discos que podem ser anexados.
O desempenho de armazenamento também varia entre tamanhos de VM para o máximo de IOPS de disco local e anexado (operações de entrada/saída por segundo).
Se os seus aplicativos exigirem Discos do Azure como solução de armazenamento, defina um tamanho adequado da VM do nó. Os recursos de armazenamento e as quantidades de CPU e memória desempenham um papel importante ao decidir sobre o tamanho de uma VM.
Por exemplo, embora os tamanhos de VM Standard_B2ms e Standard_DS2_v2 incluam uma quantidade semelhante de recursos de CPU e memória, os seus desempenhos potenciais de armazenamento são diferentes:
| Tipo e tamanho do nó | vCPU | Memória (GiB) | Máx. de discos de dados | Máximo de IOPS de disco sem cache | Débito máximo sem cache (MBps) |
|---|---|---|---|---|---|
| Standard_B2ms | 2 | 8 | 4 | 1 920 | 22,5 |
| Standard_DS2_v2 | 2 | 7 | 8 | 6 400 | 96 |
Neste exemplo, o Standard_DS2_v2 oferece o dobro de discos conectados e três a quatro vezes a quantidade de IOPS e taxa de transferência de disco. Se você comparou apenas os recursos de computação principais e os custos, talvez tenha escolhido o tamanho de VM Standard_B2ms com baixo desempenho de armazenamento e limitações.
Trabalhe com a sua equipa de desenvolvimento de aplicações para entender as suas necessidades de capacidade de armazenamento e desempenho. Escolha o tamanho de VM apropriado para que os nós AKS atendam ou excedam as respetivas necessidades de desempenho. Defina regularmente uma linha de base para as aplicações para ajustar o tamanho da VM conforme necessário.
Nota
Por padrão, o tamanho e o desempenho do disco para discos geridos são atribuídos de acordo com a SKU da VM selecionada e a contagem de vCPU. O dimensionamento predefinido do disco do SO só é utilizado em novos clusters ou conjuntos de nós quando os discos do SO Ephemeral OS não são suportados e não estiver especificado um tamanho predefinido do disco do SO. Para obter mais informações, consulte Dimensionamento predefinido do disco do SO.
Para obter mais informações sobre tamanhos de VM disponíveis, consulte Tamanhos para máquinas virtuais Linux no Azure.
Considere discos de dados NVMe efêmeros para obter o máximo desempenho
Orientações sobre boas práticas
Considere discos de dados NVMe temporários quando precisar da mais alta taxa de transferência de armazenamento e IOPS, e a sua carga de trabalho puder tolerar a natureza temporária do armazenamento do nodo local. Os discos de dados NVMe efêmeros fornecem armazenamento conectado ao host de baixa latência que oferece as IOPS e a taxa de transferência mais altas disponíveis no Azure. Os discos NVMe estão disponíveis em VMs das séries L, E e GPU, com suporte em expansão para as famílias VM v6 e v7 do Azure mais recentes, como as séries D, F e H.
O armazenamento apoiado por NVMe aprimora cargas de trabalho que exigem cache de alta velocidade, armazenamento temporário ou processamento de dados transitório. Ele elimina a dependência de discos remotos de alto desempenho, que normalmente exigem as configurações de VM maiores e mais caras para alcançar o desempenho ideal.
Os cenários comuns que se beneficiam de discos de dados NVMe efêmeros incluem:
- Treinamento de IA ou pipelines de inferência que preparam grandes conjuntos de dados ou pontos de verificação entre iterações
- Bancos de dados de alto desempenho ou mecanismos de streaming que mantêm réplicas ou logs em pods
- Trabalhos de análise em lote que exigem espaço temporário de trabalho ou armazenamento aleatório
Como os dados NVMe estão vinculados à instância do nó, planeje orçamentos de interrupção de pod e garanta que seu aplicativo possa ser reconstruído rapidamente a partir de armazenamento ou replicação duráveis. Os dados colocados nesses discos são perdidos sempre que um nó é deslocalizado, recriado ou falha.
Para obter mais recomendações sobre discos de dados NVMe efêmeros, consulte Práticas recomendadas para discos de dados NVMe efêmeros no Serviço Kubernetes do Azure (AKS). Para expor a capacidade do NVMe a pods, use o Armazenamento de Contêiner do Azure, que poderá orquestrar e criar volumes efêmeros ou persistentes apoiados por discos NVMe locais. Para obter orientações de implementação, consulte Usar o Armazenamento de Contêiner do Azure com AKS.
Importante
Use discos de dados NVMe apenas para cargas de trabalho que podem tolerar perda de dados e recuperar rapidamente. Mantenha dados críticos para os negócios em armazenamento durável, como o Disco do Azure ou os Arquivos do Azure.
Utilize o acelerador distribuído para armazenamento na cloud (pré-visualização)
Orientações sobre boas práticas
Considere o acelerador distribuído para armazenamento na nuvem (DACS) quando as aplicações leem repetidamente ficheiros de modelo ou conjuntos de dados do Armazenamento de Blobs do Azure. Planeie a capacidade do cache, o aquecimento e a recuperação com base nos padrões de acesso da sua carga de trabalho.
O DACS utiliza discos NVMe locais nos nós de cache do Linux para armazenar em cache dados do Azure Blob. Pode reduzir o tempo de carregamento do modelo para inferência de IA e acelerar leituras repetidas de conjuntos de dados para treino. Ativar e gerir o DACS através do Azure Container Storage. O DACS não aprovisiona volumes persistentes nem classes de armazenamento.
Quando planeia e opera DACS:
- Dedique armazenamento à cache. Use nós de cache Linux com discos NVMe locais dedicados a DACS. Os pré-requisitos da cache podem exigir a formatação desses discos. Manter as etiquetas dos nós de cache na configuração do pool de nós para que sobrevivam à substituição dos nós.
- Tamanho para o conjunto de trabalho ativo. Incluir margem para versões sobrepostas de modelos e alterações de conjuntos de dados. Tem em conta leitores concorrentes, CPU e memória do nó, e largura de banda da rede, não apenas capacidade NVMe.
- Planeie os cold reads. Considere pré-buscar dados do modelo antes de implantações de inferência ou scale-out. Verifique os acertos na cache antes de aumentar a concorrência. O prefetch não mantém os dados na memória, e a evicção, substituição de nó ou manutenção podem exigir outro aquecimento. Planeie o tráfego Blob adicional para quando os dados em cache não estiverem disponíveis.
- Meça o comportamento da aplicação e da cache. Compare acessos frios e quentes sob concorrência esperada. Monitorizar acessos na cache do cliente, pedidos do servidor de cache, latência, capacidade e tráfego Blob. Leituras bem-sucedidas ou mais rápidas por si só não provam o uso do cache porque os clientes podem recorrer ao Armazenamento de Blobs do Azure.
- Mantenha os dados de referência persistentes. Armazenar ficheiros de modelo e conjuntos de dados no Armazenamento de Blobs do Azure, preferencialmente em caminhos imutáveis e versionados. Os dados em cache são efémeros e não são replicados para durabilidade. Não uses DACS como armazenamento persistente para resultados de treino ou checkpoints.
Importante
O DACS está em pré-visualização. As funcionalidades de pré-visualização são fornecidas sem um acordo de nível de serviço, não sendo recomendadas para cargas de trabalho de produção. Para mais informações, consulte Termos Suplementares de Utilização para Microsoft Azure Previews.
Utilize DACS dentro de um cluster de confiança; a cache não isola inquilinos mutuamente não confiáveis. Conceda às cargas de trabalho apenas as permissões de acesso ao Blob de que precisam.
Para orientações de implementação e operações, consulte Gerir acelerador distribuído para armazenamento na nuvem e Monitorizar acelerador distribuído para armazenamento na nuvem.
Provisionar dinamicamente volumes
Orientações sobre boas práticas
Para reduzir a sobrecarga de gerenciamento e habilitar o dimensionamento, evite criar e atribuir estaticamente volumes persistentes. Utilize o provisionamento dinâmico. Nas suas classes de armazenamento, defina a política de libertação apropriada para minimizar os custos de armazenamento desnecessários depois que os pods forem excluídos.
Para anexar armazenamento a pods, use volumes persistentes. Os volumes persistentes podem ser criados manual ou dinamicamente. A criação manual de volumes persistentes adiciona sobrecarga de gestão e limita a sua capacidade de escalar. Em vez disso, provisione o volume persistente dinamicamente para simplificar a gestão do armazenamento e permitir que as suas aplicações cresçam e sejam dimensionadas conforme necessário.
Um pedido de volume persistente (PVC) permite criar armazenamento dinamicamente conforme necessário. Os discos subjacentes do Azure são criados à medida que os pods os solicitam. Na definição do pod, solicite que um volume seja criado e anexado a um caminho de montagem designado.
Para obter os conceitos sobre como criar e usar volumes dinamicamente, consulte PersistentVolumeClaims.
Para ver esses volumes em ação, veja como criar e usar dinamicamente um volume persistente com Azure Disks ou Arquivos do Azure.
Como parte das suas definições de classe de armazenamento, defina a reclaimPolicy apropriada. Esta reclaimPolicy controla o comportamento do recurso de armazenamento subjacente do Azure quando o pod é excluído. O recurso de armazenamento subjacente pode ser excluído ou retido para uso futuro do pod. Defina a reclaimPolicy para retain ou delete.
Compreenda as necessidades da sua aplicação e implemente verificações regulares do armazenamento retido para minimizar a quantidade de armazenamento não utilizado pelo qual lhe é cobrado.
Para obter mais informações sobre opções de classe de armazenamento, consulte políticas de recuperação de armazenamento.
Proteja e faça backup dos seus dados
Boas práticas
Faça backup dos seus dados usando uma ferramenta apropriada para o seu tipo de armazenamento, como Velero ou Backup do Azure. Verifique a integridade e a segurança dessas cópias de segurança.
Quando as suas aplicações armazenam e consomem dados persistidos em discos ou em ficheiros, é necessário fazer cópias de segurança ou instantâneos regulares desses dados. Os Azure Disks podem utilizar tecnologias de capturas instantâneas integradas. As suas aplicações podem precisar de forçar a escrita no disco antes de executar a operação de snapshot. O Velero pode fazer backup de volumes persistentes juntamente com recursos e configurações adicionais de cluster. Se não for possível remover o estado de seus aplicativos, faça backup dos dados de volumes persistentes e teste regularmente as operações de restauração para verificar a integridade dos dados e os processos necessários.
Compreenda as limitações das diferentes abordagens para cópias de segurança de dados e se precisa de colocar os dados em estado consistente antes do instantâneo. Os backups de dados não permitem necessariamente restaurar o ambiente da aplicação ou da implementação do cluster. Para obter mais informações sobre esses cenários, consulte Práticas recomendadas para continuidade de negócios e recuperação de desastres no AKS.
Se usar DACS, proteja os ficheiros de modelo e conjuntos de dados autoritativos no Armazenamento de Blobs do Azure em vez de fazer backup do conteúdo efémero da cache. Mantém a configuração da cache no controlo de versões e testa recriar e aquecer a cache após a substituição do nó ou recuperação do cluster. O DACS não é uma solução de backup.
Próximos passos
Este artigo concentrou-se nas práticas recomendadas de armazenamento no AKS. Para obter mais informações sobre as noções básicas de armazenamento no Kubernetes, consulte Conceitos de armazenamento para aplicações no AKS.
Para mais informações sobre cache distribuída para dados do Azure Blob, consulte os seguintes artigos: