Arquitetura do AKS Arc e do cluster de cargas de trabalho

Artigo
05/11/2024

Aplica-se a: Azure Stack HCI, versão 23H2

Azure Kubernetes Service (AKS) no Azure Stack HCI é uma plataforma de contentores do Kubernetes de nível empresarial. Inclui o Kubernetes principal suportado pela Microsoft, um anfitrião de contentores windows criado de propósito e um anfitrião de contentores linux suportado pela Microsoft, com o objetivo de ter uma experiência de gestão de implementação e ciclo de vida simples.

Este artigo apresenta os componentes principais da infraestrutura do Kubernetes, como o plano de controlo, os nós e os conjuntos de nós. Também são introduzidos recursos de carga de trabalho, como pods, implementações e conjuntos, bem como agrupar recursos em espaços de nomes.

Arquitetura do cluster

Um cluster de Azure Kubernetes Service tem os seguintes componentes:

A Ponte de Recursos do Arc (também conhecida como aplicação Arc) fornece o mecanismo de orquestração principal e a interface para implementar e gerir um ou mais clusters de cargas de trabalho.
Os clusters de cargas de trabalho (também conhecidos como clusters de destino) são onde as aplicações em contentores são implementadas.

O AKS Arc utiliza um conjunto de configurações predefinidas para implementar clusters do Kubernetes de forma eficaz e tendo em conta a escalabilidade. Uma operação de implementação cria várias máquinas virtuais do Linux ou Windows e associa-as para criar um ou mais clusters do Kubernetes.

Nota

Para ajudar a melhorar a fiabilidade do sistema, se executar vários Volumes Partilhados de Cluster (CSVs) no cluster, por predefinição, os dados da máquina virtual são distribuídos automaticamente por todos os CSVs disponíveis no cluster. Isto garante que as aplicações sobrevivem em caso de indisponibilidade do CSV.

Ponte de Recursos do Arc

A Ponte de Recursos do Arc liga uma nuvem privada (por exemplo, Azure Stack HCI, VMWare/vSphere ou SCVMM) ao Azure e permite a gestão de recursos no local a partir do Azure. A Bridge de Recursos do Azure Arc fornece a linha de visão para clouds privadas necessárias para gerir recursos como clusters do Kubernetes no local através do Azure. A Ponte de Recursos do Arc inclui os seguintes componentes principais do AKS Arc:

Extensões de cluster do AKS Arc: uma extensão de cluster é o equivalente no local de um fornecedor de recursos do Azure Resource Manager. Tal como o fornecedor de recursos Microsoft.ContainerService gere clusters do AKS no Azure, a extensão de cluster do AKS Arc, uma vez adicionada à Bridge de Recursos do Arc, ajuda a gerir clusters do Kubernetes através do Azure.
Localização personalizada: uma localização personalizada é o equivalente no local de uma região do Azure e é uma extensão da construção de localização do Azure. As localizações personalizadas fornecem uma forma de os administradores inquilinos utilizarem o datacenter com as extensões corretas instaladas, como localizações de destino para implementar instâncias de serviço do Azure.

Clusters de cargas de trabalho

O cluster de cargas de trabalho é uma implementação de elevada disponibilidade do Kubernetes com VMs do Linux para executar componentes do plano de controlo do Kubernetes e nós de trabalho do Linux. As VMs baseadas no Windows Server Core são utilizadas para estabelecer nós de trabalho do Windows. Pode haver um ou mais clusters de carga de trabalho geridos por um cluster de gestão.

Um cluster de cargas de trabalho tem muitos componentes, conforme descrito nas secções seguintes.

Plano de controlo

Servidor de API: o servidor de API permite a interação com a API do Kubernetes. Este componente fornece a interação para ferramentas de gestão, como Windows Admin Center, módulos do PowerShell ou kubectl.
Etcd: Etcd é um arquivo de chave-valor distribuído que armazena os dados necessários para a gestão do ciclo de vida do cluster. Armazena o estado do plano de controlo.

Balanceador de carga

O balanceador de carga é uma máquina virtual que executa Linux e HAProxy e KeepAlive para fornecer serviços com balanceamento de carga para os clusters de carga de trabalho implementados pelo cluster de gestão. Para cada cluster de cargas de trabalho, o AKS Arc adiciona pelo menos uma máquina virtual de balanceador de carga. Qualquer serviço do Kubernetes do tipo LoadBalancer criado no cluster de carga de trabalho cria uma regra de balanceamento de carga na VM.

A extensão MetalLB Arc é uma ferramenta que lhe permite gerar IPs externos para as suas aplicações e serviços. Os clusters do Kubernetes compatíveis com o Arc podem ser integrados com o MetalLB com a Arc Networking extensão k8s. Para obter informações sobre o balanceamento de carga do MetalLB para o AKS ativado por clusters do Arc Kubernetes, veja Descrição Geral do MetalLB para clusters do Kubernetes.

Nós de trabalho

Para executar as suas aplicações e serviços de suporte, precisa de um nó do Kubernetes. Um cluster de carga de trabalho do AKS tem um ou mais nós de trabalho. Os nós de trabalho atuam como máquinas virtuais (VMs) que executam os componentes do nó do Kubernetes e alojam os pods e serviços que compõem a carga de trabalho da aplicação.

Existem componentes principais da carga de trabalho do Kubernetes que pode implementar em clusters de cargas de trabalho do AKS, como pods e implementações.

Gestão do ciclo de vida

O Azure Arc é ativado automaticamente em todos os clusters do Kubernetes criados com o AKS Arc. Pode utilizar a sua identidade de Microsoft Entra para ligar aos clusters a partir de qualquer lugar. O Azure Arc permite-lhe utilizar ferramentas familiares como o portal do Azure, a CLI do Azure e os modelos do Azure Resource Manager para criar e gerir os clusters do Kubernetes.

Implementações de SO misto

Se um determinado cluster de cargas de trabalho for composto por nós de trabalho do Linux e do Windows, tem de ser agendado para um SO que suporte o aprovisionamento da carga de trabalho. O Kubernetes oferece dois mecanismos para garantir que as cargas de trabalho são colocadas em nós com um sistema operativo de destino:

O Seletor de Nós é um campo simples na especificação do pod que restringe os pods a serem agendados apenas para nós em bom estado de funcionamento que correspondam ao sistema operativo.
As taints e as tolerâncias funcionam em conjunto para garantir que os pods não são agendados para nós involuntariamente. Um nó pode ser "manchado" para não aceitar pods que não toleram explicitamente o seu taint através de uma "tolerância" na especificação do pod.

Para obter mais informações, veja seletores de nós , taints e tolerâncias.