As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Armazenamento

Visão geral

Há cenários em que talvez você queira executar aplicativos que precisam preservar os dados por um curto ou longo prazo. Para esses casos de uso, os volumes podem ser definidos e montados por pods para que seus contêineres possam acessar diferentes mecanismos de armazenamento. O Kubernetes oferece suporte a diferentes tipos de volumes para armazenamento temporário e persistente. A escolha do armazenamento depende muito dos requisitos do aplicativo. Para cada abordagem, há implicações de custo e as práticas detalhadas abaixo que ajudarão você a obter eficiência de custos para cargas de trabalho que precisam de alguma forma de armazenamento em seus ambientes EKS.

Volumes efêmeros

Os volumes temporários são para aplicativos que exigem volumes locais transitórios, mas não exigem que os dados sejam persistidos após a reinicialização. Exemplos disso incluem requisitos de espaço temporário, armazenamento em cache e dados de entrada somente para leitura, como dados de configuração e segredos. Você pode encontrar mais detalhes sobre os volumes efêmeros do Kubernetes aqui. A maioria dos volumes efêmeros (por exemplo, emptyDir, ConfigMap, DownwardAPI, secret, hostpath) é suportada por dispositivos graváveis conectados localmente (geralmente o disco raiz) ou RAM, por isso é importante escolher o volume de host mais econômico e com melhor desempenho.

Usando volumes do EBS

Recomendamos começar com gp3 como volume raiz do host. É o último volume SSD de uso geral oferecido pelo Amazon EBS e também oferece um preço mais baixo (até 20%) por GB em comparação com os volumes gp2.

Usando lojas de EC2 instâncias da Amazon

As lojas de EC2 instâncias da Amazon fornecem armazenamento temporário em nível de bloco para suas EC2 instâncias. O armazenamento fornecido pelos armazenamentos de EC2 instâncias pode ser acessado por meio de discos fisicamente conectados aos hosts. Ao contrário do Amazon EBS, você só pode anexar volumes de armazenamento de instâncias quando a instância é iniciada, e esses volumes só existem durante a vida útil da instância. Eles não podem ser desanexados e reconectados a outras instâncias. Você pode aprender mais sobre as lojas de EC2 instâncias da Amazon aqui. Não há taxas adicionais associadas a um volume de armazenamento de instâncias. Isso as torna (volumes de armazenamento de instâncias) mais econômicas do que as EC2 instâncias gerais com grandes volumes do EBS.

Para usar volumes de armazenamento local no Kubernetes, você deve particionar, configurar e formatar os discos usando os EC2 dados do usuário da Amazon para que os volumes possam ser montados conforme a especificação do pod. HostPath Como alternativa, você pode aproveitar o Provisionador Estático de Volume Persistente Local para simplificar o gerenciamento do armazenamento local. O provisionador estático Local Persistent Volume permite que você acesse volumes de armazenamento de instâncias locais por meio da interface padrão do Kubernetes PersistentVolumeClaim (PVC). Além disso, ele provisionará PersistentVolumes (PVs) que contém informações de afinidade de nós para programar pods para os nós corretos. Embora use o Kubernetes PersistentVolumes, os volumes de armazenamento de EC2 instâncias são efêmeros por natureza. Os dados gravados em discos temporários só estão disponíveis durante a vida útil da instância. Quando a instância é encerrada, os dados também são encerrados. Consulte este blog para obter mais detalhes.

Lembre-se de que, ao usar volumes de armazenamento de EC2 instâncias da Amazon, o limite total de IOPS é compartilhado com o host e vincula os pods a um host específico. Você deve analisar minuciosamente seus requisitos de carga de trabalho antes de adotar os volumes de armazenamento de EC2 instâncias da Amazon.

Volumes persistentes

O Kubernetes geralmente está associado à execução de aplicativos sem estado. No entanto, há cenários em que talvez você queira executar microsserviços que precisem preservar dados ou informações persistentes de uma solicitação para a outra. Os bancos de dados são um exemplo comum desses casos de uso. No entanto, os pods e os contêineres ou processos dentro deles são de natureza efêmera. Para manter os dados além da vida útil de um pod, você pode usar PVs para definir o acesso ao armazenamento em um local específico que seja independente do pod. Os custos associados ao armazenamento PVs são altamente dependentes do tipo de armazenamento que está sendo usado e de como os aplicativos o estão consumindo.

Há diferentes tipos de opções de armazenamento compatíveis com o Kubernetes no PVs Amazon EKS listados aqui. As opções de armazenamento abordadas abaixo são Amazon EBS, Amazon EFS, Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP.

Volumes do Amazon Elastic Block Store (EBS)

Os volumes do Amazon EBS podem ser consumidos como Kubernetes PVs para fornecer volumes de armazenamento em nível de bloco. Eles são adequados para bancos de dados que dependem de leituras e gravações aleatórias e aplicativos de alto rendimento que realizam leituras e gravações longas e contínuas. O driver Amazon Elastic Block Store Container Storage Interface (CSI) permite que os clusters do Amazon EKS gerenciem o ciclo de vida dos volumes do Amazon EBS para volumes persistentes. A Container Storage Interface permite e facilita a interação entre o Kubernetes e um sistema de armazenamento. Quando um driver CSI é implantado em seu cluster EKS, você pode acessar seus recursos por meio dos recursos de armazenamento nativos do Kubernetes, como Volumes Persistentes (PVs), Declarações de Volume Persistentes () e Classes de Armazenamento (PVCs). SCs Este link fornece exemplos práticos de como interagir com volumes do Amazon EBS com o driver CSI do Amazon EBS.

Escolhendo o volume certo

Recomendamos usar a última geração de armazenamento em bloco (gp3), pois ela fornece o equilíbrio certo entre preço e desempenho. Ele também permite que você escale o volume de IOPS e a taxa de transferência independentemente do tamanho do volume, sem precisar provisionar capacidade adicional de armazenamento em blocos. Se você estiver usando volumes gp2 no momento, é altamente recomendável migrar para volumes gp3. A postagem do blog Como migrar clusters do Amazon EKS de volumes do EBS gp2 para gp3 explica como migrar de gp2 para gp3 em clusters Amazon EKS com backup e restauração usando o recurso CSI Volume Snapshots, que exige tempo de inatividade do aplicativo.

O Amazon EBS permite alterar as características do volume, como tamanho do volume, IOPS e taxa de transferência on-line. Utilizando esse recurso, é possível migrar de gp2 para gp3 sem tempo de inatividade do aplicativo usando anotações de PVC, conforme descrito neste blog, que requer o driver EBS CSI v1.19.0+, ou começando com o Amazon EKS v1.31 e o driver EBS CSI 1.35 usando a API conforme descrito aqui. VolumeAttributesClass

Quando você tem aplicativos que exigem maior desempenho e precisam de volumes maiores do que o que um único volume gp3 pode suportar, considere usar o io2 block express. Esse tipo de armazenamento é ideal para sua implantação maior, mais I/O intensiva e de missão crítica, como SAP HANA ou outros bancos de dados grandes com requisitos de baixa latência. Lembre-se de que o desempenho do EBS de uma instância é limitado pelos limites de desempenho da instância, portanto, nem todas as instâncias oferecem suporte a volumes expressos de blocos io2. Você pode verificar os tipos de instância compatíveis e outras considerações neste documento.

Um único volume gp3 pode suportar até 16.000 IOPS no máximo, 1.000 taxa de transferência máxima, no MiB/s máximo 16 TiB. A última geração de volume SSD de IOPS provisionadas que fornece até 256.000 IOPS, 4.000 MiB/s, taxa de transferência e 64 TiB.

Entre essas opções, você deve adaptar melhor o desempenho e o custo do armazenamento às necessidades de seus aplicativos.

Monitore e otimize ao longo do tempo

É importante entender o desempenho básico do seu aplicativo e monitorá-lo em relação aos volumes selecionados para verificar se ele está atendendo ao seu requirements/expectations ou se está superprovisionado (por exemplo, um cenário em que as IOPS provisionadas não estão sendo totalmente utilizadas).

Em vez de alocar um grande volume desde o início, você pode aumentar gradualmente o tamanho do volume à medida que acumula dados. Você pode redimensionar volumes dinamicamente usando o recurso de redimensionamento de volume no driver CSI do Amazon Elastic Block Store (). aws-ebs-csi-driver Lembre-se de que você só pode aumentar o tamanho do volume do EBS.

Para identificar e remover quaisquer volumes pendentes do EBS, você pode usar a categoria de otimização de custos do AWS Trusted Advisor. Esse recurso ajuda a identificar volumes não conectados ou com atividade de gravação muito baixa por um período de tempo. Há uma ferramenta nativa da nuvem, de código aberto e somente para leitura, chamada Popeye, que escaneia clusters Kubernetes ativos e relata possíveis problemas com recursos e configurações implantados. Por exemplo, ele pode verificar se não estão sendo usados PVs PVCs e verificar se eles estão vinculados ou se há algum erro na montagem do volume.

Para se aprofundar no monitoramento, consulte o guia de observabilidade da otimização de custos do EKS.

Outra opção que você pode considerar são as recomendações de volume do AWS Compute Optimizer Amazon EBS. Essa ferramenta identifica automaticamente a configuração ideal do volume e o nível correto de desempenho necessário. Por exemplo, ele pode ser usado para configurações ideais relacionadas a IOPS provisionadas, tamanhos de volume e tipos de volumes do EBS com base na utilização máxima durante os últimos 14 dias. Também quantifica a possível economia mensal de custos derivada de suas recomendações. Você pode revisar este blog para obter mais detalhes.

Backup retention policy (Política de retenção de backup)

Você pode fazer backup dos dados em seus volumes do Amazon EBS tirando point-in-time snapshots. O driver CSI do Amazon EBS oferece suporte a snapshots de volume. Você pode aprender como criar um snapshot e restaurar um EBS PV usando as etapas descritas aqui.

Os instantâneos subsequentes são backups incrementais, o que significa que somente os blocos no dispositivo que foram alterados após o instantâneo mais recente são salvos. Isso minimiza o tempo necessário para criar o snapshot e economiza em custos de armazenamento ao não duplicar os dados. No entanto, aumentar o número de snapshots antigos do EBS sem uma política de retenção adequada pode causar custos inesperados ao operar em grande escala. Se você estiver fazendo backup direto dos volumes do Amazon EBS por meio da API da AWS, você pode aproveitar o Amazon Data Lifecycle Manager (DLM), que fornece uma solução de gerenciamento de ciclo de vida automatizada e baseada em políticas para snapshots do Amazon Elastic Block Store (EBS) e Amazon Machine Images () apoiado pelo EBS. AMIs O console facilita a automatização da criação, retenção e exclusão de snapshots do EBS e. AMIs

Em um ambiente Kubernetes, você pode aproveitar uma ferramenta de código aberto chamada Velero para fazer backup de seus volumes persistentes do EBS. Você pode definir um sinalizador TTL ao programar a tarefa para expirar os backups. Aqui está um guia da Velero como exemplo.

Amazon Elastic File System (EFS)

O Amazon Elastic File System (EFS) é um sistema de arquivos totalmente elástico e sem servidor que permite compartilhar dados de arquivos usando a interface padrão do sistema de arquivos e a semântica do sistema de arquivos para um amplo espectro de cargas de trabalho e aplicativos. Exemplos de cargas de trabalho e aplicativos incluem Wordpress e Drupal, ferramentas para desenvolvedores, como JIRA e Git, e sistemas de notebooks compartilhados, como o Jupyter, além de diretórios pessoais.

Um dos principais benefícios do Amazon EFS é que ele pode ser montado por vários contêineres espalhados por vários nós e várias zonas de disponibilidade. Outro benefício é que você paga apenas pelo armazenamento que usa. Os sistemas de arquivos EFS aumentarão e diminuirão automaticamente à medida que você adiciona e remove arquivos, o que elimina a necessidade de planejamento de capacidade.

Para usar o Amazon EFS no Kubernetes, você precisa usar o driver Amazon Elastic File System Container Storage Interface (CSI),. aws-efs-csi-driver Atualmente, o motorista pode criar pontos de acesso dinamicamente. No entanto, o sistema de arquivos do Amazon EFS precisa ser provisionado primeiro e fornecido como uma entrada para o parâmetro da classe de armazenamento Kubernetes.

Escolhendo a classe de armazenamento EFS certa

O Amazon EFS oferece quatro classes de armazenamento.

Duas classes de armazenamento padrão:

Duas classes de armazenamento de uma zona:

As classes de armazenamento de acesso infrequente (IA) são econômicas para arquivos que não são acessados todos os dias. Com o gerenciamento do ciclo de vida do Amazon EFS, você pode mover arquivos que não foram acessados durante a política de ciclo de vida (7, 14, 30, 60 ou 90 dias) para as classes de armazenamento IA, o que pode reduzir o custo de armazenamento em até 92% em comparação com as classes de armazenamento EFS Standard e EFS One Zone, respectivamente.

Com o EFS Intelligent-Tiering, o gerenciamento do ciclo de vida monitora os padrões de acesso do seu sistema de arquivos e move automaticamente os arquivos para a classe de armazenamento mais adequada.

Amazon FSx para Lustre

O Lustre é um sistema de arquivos paralelo de alto desempenho comumente usado em cargas de trabalho que exigem uma taxa de transferência de até centenas de GB/s latências inferiores a milissegundos por operação. Ele é usado para cenários como treinamento de aprendizado de máquina, modelagem financeira, HPC e processamento de vídeo. O Amazon FSx for Lustre fornece um armazenamento compartilhado totalmente gerenciado com escalabilidade e desempenho, perfeitamente integrado ao Amazon S3.

Você pode usar volumes de armazenamento persistente do Kubernetes apoiados pelo FSx for Lustre usando o driver CSI FSx for Lustre do Amazon EKS ou seu cluster Kubernetes autogerenciado na AWS. Consulte a documentação do Amazon EKS para obter mais detalhes e exemplos.

Link para o Amazon S3

É recomendável vincular um repositório de dados de longo prazo altamente durável que reside no Amazon S3 ao FSx seu sistema de arquivos for Lustre. Uma vez vinculados, grandes conjuntos de dados são carregados lentamente, conforme necessário, do Amazon S3 para FSx os sistemas de arquivos Lustre. Você também pode executar suas análises e resultados no S3 e, em seguida, excluir seu sistema de arquivos Lustre.

Escolhendo as opções certas de implantação e armazenamento

FSx for Lustre oferece diferentes opções de implantação. A primeira opção é chamada de scratch e não replica dados, enquanto a segunda opção é chamada de persistente, que, como o nome indica, persiste os dados.

A primeira opção (scratch) pode ser usada para reduzir o custo do processamento temporário de dados de curto prazo. A opção de implantação persistente foi projetada para armazenamento de longo prazo que replica automaticamente os dados dentro de uma zona de disponibilidade da AWS. Ele também suporta armazenamento SSD e HDD.

Você pode configurar o tipo de implantação desejado nos parâmetros do Kubernetes do sistema de arquivos FSx for lustre. StorageClass Aqui está um link que fornece exemplos de modelos.

Ativar compactação de dados

Você também pode ativar a compactação de dados em seu sistema de arquivos especificando "LZ4" como o Tipo de compactação de dados. Depois de habilitado, todos os arquivos recém-gravados serão automaticamente compactados FSx para o Lustre antes de serem gravados no disco e descompactados quando forem lidos. LZ4 o algoritmo de compressão de dados não tem perdas, então os dados originais podem ser totalmente reconstruídos a partir dos dados compactados.

Você pode configurar o tipo de compactação de dados LZ4 conforme os parâmetros do Kubernetes do sistema de arquivos FSx for lustre. StorageClass A compactação é desativada quando o valor é definido como NONE, que é o padrão. Esse link fornece exemplos de modelos.

Amazon FSx para NetApp ONTAP

O Amazon FSx for NetApp ONTAP é um armazenamento compartilhado totalmente gerenciado baseado no sistema NetApp de arquivos ONTAP. FSx for ONTAP fornece armazenamento de arquivos compartilhado rico em recursos, rápido e flexível que é amplamente acessível a partir de instâncias computacionais Linux, Windows e macOS executadas na AWS ou localmente.

O Amazon FSx for NetApp ONTAP oferece suporte a dois níveis de armazenamento: 1/nível primário e 2/nível de pool de capacidade.

A camada primária é uma camada provisionada e baseada em SSD de alto desempenho para dados ativos e sensíveis à latência. A camada de pool de capacidade totalmente elástica é otimizada em termos de custo para dados acessados com pouca frequência, é escalada automaticamente à medida que os dados são hierarquizados e oferece petabytes de capacidade praticamente ilimitados. Você pode ativar a compactação e a desduplicação de dados no armazenamento do pool de capacidade e reduzir ainda mais a quantidade de capacidade de armazenamento que seus dados consomem. NetAppO FabricPool recurso nativo baseado em políticas da monitora continuamente os padrões de acesso aos dados, transferindo automaticamente os dados bidirecionalmente entre os níveis de armazenamento para otimizar o desempenho e o custo.

NetAppO Astra Trident da fornece orquestração dinâmica de armazenamento usando um driver CSI que permite que os clusters do Amazon EKS gerenciem o ciclo de vida de volumes persistentes apoiados PVs pela Amazon para sistemas de arquivos ONTAP. FSx NetApp Para começar, consulte Usar o Astra Trident com a Amazon FSx para NetApp ONTAP na documentação do Astra Trident.

Outras considerações

Minimize o tamanho da imagem do contêiner

Depois que os contêineres são implantados, as imagens dos contêineres são armazenadas em cache no host como várias camadas. Ao reduzir o tamanho das imagens, a quantidade de armazenamento necessária no host pode ser reduzida.

Ao usar imagens básicas reduzidas, como imagens de rascunho ou imagens de contêiner sem distribuição (que contêm somente seu aplicativo e suas dependências de tempo de execução) desde o início, você pode reduzir o custo de armazenamento, além de outros benefícios auxiliares, como reduzir a área da superfície de ataque e reduzir os tempos de extração da imagem.

Você também deve considerar o uso de ferramentas de código aberto, como o Slim.ai, que fornece uma maneira fácil e segura de criar imagens mínimas.

Várias camadas de pacotes, ferramentas, dependências de aplicativos e bibliotecas podem facilmente aumentar o tamanho da imagem do contêiner. Ao usar construções de vários estágios, você pode copiar seletivamente artefatos de um estágio para outro, excluindo tudo o que não é necessário da imagem final. Você pode conferir mais práticas recomendadas de criação de imagens aqui.

Outra coisa a considerar é por quanto tempo as imagens em cache devem ser mantidas. Talvez você queira limpar as imagens obsoletas do cache de imagens quando uma certa quantidade de disco for utilizada. Isso ajudará a garantir que você tenha espaço suficiente para a operação do host. Por padrão, o kubelet realiza a coleta de lixo em imagens não utilizadas a cada cinco minutos e em contêineres não utilizados a cada minuto.

Para configurar opções para coleta de lixo de contêineres e imagens não utilizados, ajuste o kubelet usando um arquivo de configuração e altere os parâmetros relacionados à coleta de lixo usando o tipo de recurso. KubeletConfiguration

Você pode aprender mais sobre isso na documentação do Kubernetes.