Preparar Linux para Volumes de Borda (visualização)

O artigo descreve como preparar o Linux para Volumes de Borda usando o AKS habilitado pelo Azure Arc, Edge Essentials ou Ubuntu.

Pré-requisitos

Desinstalar instância anterior do Armazenamento de Contêiner do Azure habilitada pela extensão Azure Arc

Se você instalou anteriormente uma versão do Armazenamento de Contêiner do Azure habilitada pelo Azure Arc anterior à 2.1.0-preview, deverá desinstalar essa instância anterior para instalar a versão mais recente. Se você instalou a versão 1.2.0-preview ou anterior, use estas instruções. As versões posteriores à 2.1.0-preview podem ser atualizadas e não requerem esta desinstalação.

1. Para excluir a versão antiga da extensão, os recursos do Kubernetes que contêm referências à versão antiga da extensão devem ser limpos. Quaisquer recursos pendentes podem atrasar a limpeza da extensão. Há pelo menos duas maneiras de limpar esses recursos: usando kubectl delete <resource_type> <resource_name>ou "desaplicando" os arquivos YAML usados para criar os recursos. Os recursos que precisam ser excluídos normalmente são os pods, o PVC referenciado e o subvolume CRD (se o Cloud Ingest Edge Volume tiver sido configurado). Como alternativa, os quatro arquivos YAML a seguir podem ser passados para kubectl delete -f usar os seguintes comandos na ordem especificada. Estas variáveis devem ser atualizadas com as suas informações:

   • YOUR_DEPLOYMENT_FILE_NAME_HERE: Adicione seus nomes de arquivo de implantação. No exemplo deste artigo, o nome do arquivo usado foi deploymentExample.yaml. Se você criou várias implantações, cada uma delas deve ser excluída em uma linha separada.
   • YOUR_PVC_FILE_NAME_HERE: Adicione seus nomes de arquivo de Declaração de Volume Persistente. No exemplo deste artigo, se você usou o Cloud Ingest Edge Volume, o nome do arquivo usado foi cloudIngestPVC.yaml. Se você usou o Volume de Borda Local Compartilhado, o nome do arquivo usado foi localSharedPVC.yaml. Se você criou vários PVCs, cada um deve ser excluído em uma linha separada.
   • YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE: Adicione seus nomes de arquivo de subvolume de Borda. No exemplo deste artigo, o nome do arquivo usado foi edgeSubvolume.yaml. Se você criou vários subvolumes, cada um deve ser excluído em uma linha separada.
   • YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE: Adicione o nome do arquivo de configuração de armazenamento de borda aqui. No exemplo deste artigo, o nome do arquivo usado foi edgeConfig.yaml.

   kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>"
   kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>"   
   kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>"
   kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
   

2. Depois de excluir os arquivos para suas implantações, PVCs, subvolumes de Borda e configuração de armazenamento de Borda da etapa anterior, você pode desinstalar a extensão usando o comando a seguir. Substitua YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HERE, e YOUR_EXTENSION_NAME_HERE com suas respetivas informações:

   az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
   

Cluster Kubernetes conectado a arco

Estas instruções pressupõem que você já tenha um cluster Kubernetes conectado ao Arc. Para conectar um cluster Kubernetes existente ao Azure Arc, consulte estas instruções.

Se você quiser usar o Armazenamento de Contêiner do Azure habilitado pelo Azure Arc com as Operações do Azure IoT, siga as instruções para criar um cluster para as Operações do Azure IoT.

Clusters de nó único e de vários nós

Um cluster de nó único é comumente usado para fins de desenvolvimento ou teste devido à sua simplicidade na configuração e requisitos mínimos de recursos. Esses clusters oferecem um ambiente leve e direto para os desenvolvedores experimentarem o Kubernetes sem a complexidade de uma configuração de vários nós. Além disso, em situações em que recursos como CPU, memória e armazenamento são limitados, um cluster de nó único é mais prático. Sua facilidade de configuração e requisitos mínimos de recursos o tornam uma escolha adequada em ambientes com restrição de recursos.

No entanto, os clusters de nó único vêm com limitações, principalmente na forma de recursos ausentes, incluindo sua falta de alta disponibilidade, tolerância a falhas, escalabilidade e desempenho.

Uma configuração do Kubernetes de vários nós é normalmente usada para cenários de produção, preparação ou grande escala devido a recursos como alta disponibilidade, tolerância a falhas, escalabilidade e desempenho. Um cluster de vários nós também apresenta desafios e compensações, incluindo considerações de complexidade, despesas gerais, custo e eficiência. Por exemplo, configurar e manter um cluster de vários nós requer conhecimentos, habilidades, ferramentas e recursos extras (rede, armazenamento, computação). O cluster deve lidar com a coordenação e a comunicação entre nós, levando a latência e erros potenciais. Além disso, a execução de um cluster de vários nós consome mais recursos e é mais cara do que um cluster de nó único. A otimização do uso de recursos entre nós é crucial para manter a eficiência e o desempenho do cluster e do aplicativo.

Em resumo, um cluster Kubernetes de nó único pode ser adequado para ambientes de desenvolvimento, teste e restrição de recursos. Um cluster de vários nós é mais apropriado para implantações de produção, alta disponibilidade, escalabilidade e cenários nos quais os aplicativos distribuídos são um requisito. Essa escolha depende, em última análise, de suas necessidades e metas específicas para sua implantação.

Requisitos mínimos de hardware

Cluster de nó único ou de 2 nós

• Standard_D8ds_v5 VM recomendada
• Especificações equivalentes por nó:
  • 4 CPUs
  • 16 GB de RAM

Cluster de vários nós

• Standard_D8as_v5 VM recomendada
• Especificações equivalentes por nó:
  • 8 CPUs
  • 32 GB de RAM

32 GB de RAM serve como buffer; no entanto, 16 GB de RAM devem ser suficientes. As configurações do Edge Essentials exigem 8 CPUs com 10 GB de RAM por nó, tornando 16 GB de RAM o requisito mínimo.

Requisitos mínimos de armazenamento

Requisitos de Volumes de Borda

Quando você usa a opção de armazenamento tolerante a falhas, os Volumes de Borda alocam espaço em disco de um pool de armazenamento tolerante a falhas, que é composto pelo armazenamento exportado por cada nó no cluster.

O pool de armazenamento está configurado para usar replicação de 3 vias para garantir tolerância a falhas. Quando um Volume de Borda é provisionado, ele aloca espaço em disco do pool de armazenamento e aloca armazenamento em 3 das réplicas.

Por exemplo, em um cluster de 3 nós com 20 GB de espaço em disco por nó, o cluster tem um pool de armazenamento de 60 GB. No entanto, devido à replicação, ele tem um tamanho de armazenamento efetivo de 20 GB.

Quando um Volume de Borda é provisionado com um tamanho solicitado de 10 GB, ele aloca um volume de sistema reservado (dimensionado estaticamente para 1 GB) e um volume de dados (dimensionado para o tamanho de volume solicitado, por exemplo, 10 GB). O volume reservado do sistema consome 3 GB (3 x 1 GB) de espaço em disco no pool de armazenamento e o volume de dados consome 30 GB (3 x 10 GB) de espaço em disco no pool de armazenamento, totalizando 33 GB.

Requisitos de volumes de cache

Os Volumes de Cache requerem pelo menos 4 GB por nó de armazenamento. Por exemplo, se você tiver um cluster de 3 nós, precisará de pelo menos 12 GB de armazenamento.

Próximos passos

• Preparar o Linux usando um cluster de nó único
• Preparar o Linux usando um cluster de vários nós