Preparar o Linux para Volumes de Borda

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

Pré-requisitos

Desinstale a instância anterior da extensão do Armazenamento de Contêineres do Azure habilitado pelo Azure Arc

Se você instalou anteriormente uma versão do Armazenamento de Contêineres do Azure habilitado pelo Azure Arc anterior a 2.1.0-preview, você deve desinstalar essa instância anterior para instalar a versão mais recente. Se você instalou a versão 1.2.0-preview ou anterior, utilize estas instruções. Versões posteriores a 2.1.0-preview são atualizáveis e não exigem essa desinstalação.

1. Para excluir a versão antiga da extensão, os recursos do Kubernetes que mantêm referências à versão antiga da extensão devem ser limpos. Qualquer recurso pendente pode atrasar a limpeza da extensão. Existem 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 são tipicamente os pods, o PVC referenciado e o CRD de subvolume (se o Volume de Borda de Ingestão de Nuvem foi configurado). Como alternativa, os quatro arquivos YAML a seguir podem ser passados para kubectl delete -f usando os seguintes comandos na ordem especificada. Essas variáveis devem ser atualizadas com suas informações:

   • YOUR_DEPLOYMENT_FILE_NAME_HERE: adicionar os nomes dos arquivos de implantação. No exemplo deste artigo, o nome do arquivo usado foi deploymentExample.yaml. Se você criou várias implantações, cada uma deve ser excluída em uma linha separada.
   • YOUR_PVC_FILE_NAME_HERE: adicionar os nomes dos arquivos de Declaração de Volume Persistente. No exemplo deste artigo, se você usou o Volume de Borda de Ingestão de Nuvem, o nome do arquivo utilizado foi cloudIngestPVC.yaml. Se você usou o Volume de Borda Compartilhada Local, o nome do arquivo utilizado 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: adicionar os nomes dos arquivos 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: adicionar 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 das 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 seguinte comando. Substitua YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HERE e YOUR_EXTENSION_NAME_HERE pelas suas respectivas 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 do Kubernetes conectado ao Azure Arc

Essas instruções pressupõem que você já tenha um cluster do Kubernetes conectado ao Arc. Para conectar um cluster do Kubernetes existente ao Azure Arc, confira essas instruções.

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

Clusters de nó único ou com vários nós

Um cluster de nó único geralmente é usado para fins de desenvolvimento ou testes devido à sua simplicidade de instalação e seus requisitos de recursos mínimos. Esses clusters oferecem um ambiente leve e simples de lidar para os desenvolvedores experimentarem o Kubernetes sem a complexidade de uma configuração de vários nós. Além disso, um cluster de nó único é mais prático em situações nas quais recursos como a CPU, a memória e o armazenamento são limitados. Sua facilidade de instalação e requisitos de recursos mínimos fazem dele uma opção adequada para ambientes com restrição de recursos.

No entanto, os clusters de nó único têm limitações, principalmente no que se refere a recursos ausentes, incluindo sua falta de alta disponibilidade, tolerância a falhas, escalabilidade e desempenho.

Uma configuração de Kubernetes de múltiplos nós é tipicamente usada para produção, preparo ou cenários em grande escala devido a recursos como alta disponibilidade, tolerância a falhas, escalabilidade e desempenho. Um cluster com vários nós também apresenta desafios e compensações, incluindo considerações de complexidade, sobrecarga, custo e eficiência. Por exemplo, configurar e manter um cluster de vários nós requer conhecimento, habilidades, ferramentas e recursos extras (rede, armazenamento, computação). O cluster precisa se encarregar da coordenação e da comunicação entre os nós, o que pode resultar em possíveis latências e erros. Além disso, executar um cluster com vários nós requer um uso mais intensivo de recursos e é mais caro do que um cluster de nó único. A otimização do uso de recursos entre os nós é crucial para manter a eficiência e o desempenho de clusters e aplicativos.

Em resumo, um cluster de Kubernetes de nó único pode ser adequado para desenvolvimento, testes e ambientes com restrições de recursos. Um cluster de vários nós é mais apropriado para implantações em produção, alta disponibilidade, escalabilidade e cenários em que aplicações distribuídas são uma exigência. Essa escolha depende, em última análise, de suas necessidades e metas específicas para a sua implantação.

Requisitos mínimos de hardware

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

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

Cluster de vários nós

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

32 GB de RAM servem como um buffer; no entanto, 16 GB de RAM devem ser suficientes. As configurações do Edge Essentials requerem 8 CPUs com 10 GB de RAM por nó, fazendo de 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, o Volumes de Borda aloca 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 a replicação de três vias para garantir a 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 (tamanho estático de 1 GB) e um volume de dados (dimensionado para o tamanho do volume solicitado, por exemplo, 10 GB). O volume do sistema reservado 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óximas etapas

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