Introdução ao registro de cluster

Aprimore a resiliência de funções de rede nativas de nuvem com o CR (registro de cluster) do AOSM (Gerenciador de Serviços do Operador do Azure)

Histórico de documentos

• Criado e publicado pela primeira vez: 26 de julho de 2024
• Atualizado para alta disponibilidade: 16 de outubro de 2024
• Atualizado para GC: 5 de novembro de 2024

Dependências de recurso

Esse recurso requer o seguinte ambiente mínimo:

• Versão mínima da API do ARM do AOSM: 2023-09-01
• Primeira versão da extensão Kubernetes para Função de Rede (NF) sem alta disponibilidade (HA): 1.0.2711-7
• Primeira versão da extensão Kubernetes para NF com alta disponibilidade: 2.0.2810-144
• Primeira versão, com GC para a extensão Kubernetes para NF: 2.0.2860-160

Visão geral do registro do cluster

O CR (registro de cluster) do AOSM (Azure Operator Service Manager) permite uma cópia local de imagens de contêiner no cluster Nexus K8s. Quando a função de rede em contêiner (CNF) é instalada com o registro de cluster habilitado, as imagens de contêiner são extraídas do repositório remoto de artefatos AOSM e salvas nesse registro de cluster local. Usando um webhook de mutação, o registro de cluster intercepta automaticamente as solicitações de imagem e substitui o caminho do registro local, para evitar alterações de embalagem do fornecedor. Com o registro de cluster, o acesso da CNF a imagens de contêiner sobrevive à perda de conectividade com o repositório de artefatos remoto.

Principais casos de uso e benefícios

As CNF (funções de rede nativas de nuvem) precisam de acesso a imagens de contêiner não apenas durante a implantação inicial usando o repositório de artefatos do AOSM, mas também para manter a função de rede operacional. Alguns desses cenários incluem:

• Reinicializações do pod: parar e iniciar um pod pode resultar em um nó de cluster extraindo imagens de contêiner do registro.
• Operações do agendador do Kubernetes: durante as atribuições de pod para nó, de acordo com as regras de perfil do agendador, se o novo nó não tiver as imagens de contêiner armazenadas localmente em cache, o nó efetua o pull de imagens de contêiner do registro.

Benefícios de usar o registro de cluster AOSM:

• Fornece as imagens locais necessárias para evitar a interrupção do CNF em que a conectividade com o repositório de artefatos AOSM foi perdida.
• Diminui o número de extrações de imagem no repositório de artefatos AOSM, já que cada nó de cluster agora extrai imagens apenas do registro local.
• Supera problemas com URLs de registro malformadas, usando um webhook de mutação para substituir o caminho correto da URL do registro local.

Como funciona o registro de cluster

O registro de cluster AOSM é habilitado usando a extensão Arc K8s do Operador de Função de Rede (NFO). A CLI a seguir mostra como o registro de cluster está habilitado em um cluster Nexus K8s.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

Quando o recurso de registro de cluster estiver habilitado na extensão Arc K8s do Operador de Função de Rede, todas as imagens de contêiner implantadas do repositório de artefatos do AOSM ficam acessíveis localmente no cluster Nexus K8s. O usuário pode escolher o tamanho de armazenamento persistente para o registro do cluster.

Observação

Se o usuário não fornecer nenhuma entrada, será usado um volume persistente padrão de 100 GB.

Componentes do registro de cluster

O recurso de registro de cluster implanta pods auxiliares no cluster de borda de destino para ajudar a extensão NFO.

Reconciliador de componentes

• Esse pod principal cuida da reconciliação do componente Objetos de Recurso Personalizado (CROs) criado pelo K8sBridge com a ajuda do provedor de recursos Microsoft.Kubernetes (RP), Retransmissão Híbrida e agente Arc em execução no cluster.

Webhook de mutação de pods

• Esses pods implementam webhooks de admissão mutáveis do Kubernetes, servindo uma instância da API de mutação. A API de mutação faz duas coisas:
  • Modifica o caminho do registro de imagem para o IP do registro local, substituindo o registro de contêiner do Azure (ACR) do repositório de artefatos AOSM.
  • Cria um CR de Artefato no cluster de borda.

Reconciliador de artefatos

• Esse pod reconcilia CROs de artefato criados pelo webhook de mutação.

Registro

• Este pod armazena e recupera imagens de contêiner para o CNF.

Coleta de lixo do registro de cluster

A extensão de cluster do AOSM executa um trabalho de GC (coleta de lixo) em segundo plano para limpar as imagens de contêiner regularmente. Esse trabalho será executado com base em uma agenda verificará se o uso do registro de cluster atingiu o limite especificado e, em caso afirmativo, iniciará o processo de GC. O agendamento e o limite do trabalho são configurados pelo usuário final, mas, por padrão, o trabalho é executado uma vez por dia, com um limite de utilização de 0%.

Limpar manifestos de imagem de lixo

O AOSM mantém referências entre o recurso de proprietário do pod e o consumo de imagens no registro de cluster. Ao iniciar o processo de limpeza de imagens, serão identificadas imagens que não estão vinculadas a nenhum pod, emitindo uma exclusão reversível para removê-las do registro de cluster. Esse tipo de exclusão reversível não libera imediatamente o espaço de armazenamento do registro do cluster. A remoção real de arquivos de imagem depende da coleta de lixo do registro de distribuição CNCF descrita abaixo.

Observação

A referência entre o proprietário de um pod e suas imagens de contêiner garante que o AOSM não exclua imagens por engano. Por exemplo, se um pod de conjunto de réplicas falhar, o AOSM não desrefenciará as imagens de contêiner. O AOSM só desreferencia imagens de contêiner quando o conjunto de réplicas é excluído. O mesmo princípio se aplica a pods gerenciados por trabalhos e daemonsets do Kubernetes.

Distribuição da coleta de lixo CNCF

O AOSM configura o registro de cluster usando o registro de distribuição CNCF de software livre. Portanto, o AOSM depende dos recursos de coleta de lixo fornecidos pela coleta de lixo | Distribuição CNCF. No geral, ele segue o processo de "marca e varredura" da fase 2 padrão para excluir arquivos de imagem para liberar espaço de armazenamento do Registro.

Observação

Esse processo requer o registro de cluster no modo somente leitura. Se as imagens forem carregadas quando o registro não estiver no modo somente leitura, haverá o risco de que as camadas de imagens sejam excluídas erroneamente, levando a uma imagem corrompida. O Registro requer bloqueio no modo somente leitura por uma duração de até um minuto. Consequentemente, o AOSM adiará outra implantação de NF quando o registro de cluster estiver no modo somente leitura.

Parâmetros de configuração de coleta de lixo

Os parâmetros a seguir configuram o agendamento e o limite do trabalho de GC.

• global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence
• global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold
• Para obter mais detalhes de configuração, consulte as mais recentes Instruções de instalação da extensão de função de rede

Considerações sobre alta disponibilidade e resiliência

A extensão para NF do AOSM usa um webhook mutante e um registro de borda para dar suporte aos principais recursos.

• Integração de gráficos Helm sem a necessidade de personalização do caminho da imagem.
• Um registro de cluster local para acelerar as operações de pods e permitir suporte em modo desconectado. Esses componentes essenciais precisam ser altamente disponíveis e resilientes.

Resumo das alterações para HA

Com HA, o registro de cluster e os pods do webhook agora dão suporte a um conjunto de réplicas com um mínimo de três réplicas e um máximo de cinco réplicas. A configuração da chave do conjunto de réplicas é a seguinte:

• A estratégia de atualização é feita por meio de uma distribuição de pacote gradual.
• Os PodDisruptionBudgets (PDB) são usados para garantir a disponibilidade durante interrupções voluntárias.
• A anti-afinidade de pods é usada para distribuir os pods de maneira uniforme entre os nós.
• A investigação de preparação é usada para garantir que os pods estejam prontos antes de atender ao tráfego.
• Os pods de carga de trabalho do AOSM são atribuídos somente ao pool de nós do sistema.
• Os pods são dimensionados horizontalmente sob carga de CPU e memória.

Réplicas

• Um cluster que executa várias cópias ou réplicas de um aplicativo fornece o primeiro nível de redundância. Tanto o registro de cluster quanto o webhook são definidos como "kind:deployment" com um mínimo de três réplicas.

DeploymentStrategy

• Uma estratégia de rollingUpdate é usada para ajudar a alcançar atualizações sem tempo de inatividade e dar suporte à distribuição gradual de aplicativos. A configuração padrão de maxUnavailable permite que apenas um pod seja desligado por vez, até que um número suficiente de pods seja criado para atender à política de redundância.

Orçamentos de interrupção de pods

• Um orçamento de interrupção de política (PDB) protege pods de interrupções voluntárias e é implantado junto com os objetos Deployment, ReplicaSet ou StatefulSet. Para os pods do operador AOSM, é usado um PDB com o parâmetro minAvailable definido como 2.

Antia afinidade de pod

• A anti-afinidade de pods controla a distribuição dos pods de aplicativo entre vários nós no seu cluster. Com HA, a anti-afinidade de pods do AOSM usa os seguintes parâmetros:
  • Um modo de agendamento é usado para definir quão rigorosamente a regra é aplicada.
    • requiredDuringSchedulingIgnoredDuringExecution (Hard): os pods devem ser agendados de forma a atender à regra definida. Se nenhuma topologia que atenda aos requisitos da regra estiver disponível, o pod não será agendado.
    • preferredDuringSchedulingIgnoredDuringExecution (Soft): esse tipo de regra expressa uma preferência por agendamento de pods, mas não impõe um requisito estrito. Se as topologias que atendem aos critérios de preferência estiverem disponíveis, o Kubernetes agenda o pod. Se essas topologias não estiverem disponíveis, o pod ainda poderá ser agendado em outros nós que não atendam à preferência.
  • Um seletor de rótulo é usado para direcionar pods específicos aos quais a afinidade é aplicada.
  • Uma chave de topologia é usada para definir as necessidades do nó.
• A colocação de nós do Nexus é distribuída de forma uniforme entre as zonas por design. Portanto, espalhar os pods entre os nós também proporciona redundância de zona.
• Os pods do operador AOSM usam uma anti-afinidade flexível com peso 100, e a chave de topologia é baseada nos nomes dos hosts dos nós.

Armazenamento

• Como o registro de borda do AOSM possui várias réplicas espalhadas entre os nós, o volume persistente deve dar suporte ao modo de acesso ReadWriteMany (RWX). O volume PVC "nexus-shared" está disponível nos clusters Nexus e dá suporte ao modo de acesso RWX.

Monitoramento por meio de investigações de preparação

• O AOSM usa investigações de preparação HTTP para saber quando um contêiner está pronto para começar a aceitar tráfego. Um pod é considerado pronto quando todos os contêineres estão prontos. Quando um pod não está pronto, ele é removido dos balanceadores de carga do serviço.

Pool de nós do sistema

• Todos os pods do operador AOSM são atribuídos ao pool de nós do sistema. Esse pool evita que pods de aplicativos mal configurados ou indesejados impactem os pods do sistema.

Escalonamento horizontal

• No Kubernetes, um HPA (HorizontalPodAutoscaler) atualiza automaticamente um recurso de carga de trabalho com o objetivo de dimensionar automaticamente a carga de trabalho para atender à demanda. Os pods do operador AOSM têm os seguintes parâmetros de política do HPA configurados;
  • Uma réplica mínima de três.
  • Uma réplica máxima de cinco.
  • Uma targetAverageUtilization para CPU e memória de 80%.

Limites de recursos

• Os limites de recursos são usados para prevenir a sobrecarga de recursos nos nós onde os pods do AOSM estão em execução. O AOSM usa dois parâmetros de recursos para limitar o consumo de CPU e memória.
  • Solicitação de recurso – o valor mínimo que deve ser reservado para um pod. Esse valor deve ser configurado para o uso de recursos em carga normal para seu aplicativo.
  • Limite de recursos – a quantidade máxima que um pod deve usar, e se o uso atingir esse limite, ele é encerrado. Todos os contêineres do operador AOSM são configurados com solicitações e limites adequados para CPU e memória.

Limitações de HA conhecidas

• Os clusters Nexus AKS (NAKS) com um único nó ativo no pool de agentes do sistema não são adequados para alta disponibilidade. A topologia de produção do Nexus deve usar pelo menos três nós ativos no pool de agentes do sistema.
• A classe de armazenamento nexus-shared é um serviço de armazenamento NFS. Esse serviço de armazenamento NFS está disponível por meio de cada CSN (Rede de Serviço de Nuvem). Qualquer cluster do Kubernetes do Nexus anexado à CSN pode provisionar o volume persistente desse pool de armazenamento compartilhado. O pool de armazenamento está atualmente limitado a um tamanho máximo de 1 TiB a partir da Nuvem de Rede (NC) 3.10, enquanto o NC 3.12 tem uma opção de 16 TiB.
• A anti-afinidade de pods trata apenas da colocação inicial dos pods. O dimensionamento subsequente e a reparação de pods seguem a lógica de agendamento padrão do Kubernetes.

Perguntas frequentes

Posso usar o registro de cluster do AOSM com um aplicativo de CNF implantado anteriormente?

Se houver um aplicativo de CNF já implantado sem o registro de cluster, as imagens de contêiner não estarão disponíveis automaticamente. O registro de cluster deve ser habilitado antes da implantação da função de rede com o AOSM.

Posso alterar o tamanho do armazenamento após uma implantação?

O tamanho do armazenamento não pode ser modificado após a implantação inicial. Recomendamos configurar o tamanho do volume em 3 a 4 vezes o tamanho inicial.

Posso listar os arquivos atualmente armazenados no repositório de cluster?

O comando a seguir pode ser usado para listar arquivos em um formato legível para humanos:

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

Esse comando deve produzir uma saída semelhante ao seguinte:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0