Arquitetura de rede para AKS no Azure Local

Este cenário ilustra como projetar e implementar conceitos de rede para implantar nós do Serviço Kubernetes do Azure (AKS) em clusters AKS.

Este artigo inclui recomendações para design de rede para nós do Kubernetes e contêineres do Kubernetes. Faz parte de um conjunto de orientações de linha de base arquitetónica de dois artigos. Consulte as recomendações de arquitetura de linha de base aqui.

Arquitetura

A imagem a seguir mostra a arquitetura de rede do Serviço Kubernetes do Azure em clusters de datacenter do Azure Local ou do Windows Server 2019/2022:

Transfira um ficheiro do Visio desta arquitetura.

O cenário consiste nos seguintes componentes e recursos:

• Azure Stack HCI, versão 22H2, é uma solução de cluster de infraestrutura hiperconvergente (HCI) que hospeda cargas de trabalho virtualizadas do Windows e Linux e seu armazenamento em um ambiente local híbrido. A instância local do Azure é implementada como um cluster de 2 a 4 nós.
• O cluster de failover de datacenter do Windows Server 2019/2022 é um grupo de computadores independentes que trabalham juntos para aumentar a disponibilidade e a escalabilidade de funções clusterizadas.
• Serviço Kubernetes do Azure no Azure Local é uma implementação local do Serviço Kubernetes do Azure (AKS), que automatiza a execução de aplicativos em contêineres em escala.
• Os Serviços de Domínio Ative Directory são uma estrutura hierárquica que armazena informações sobre objetos na rede. Ele fornece solução de identidade e acesso para identidades associadas a usuários, computadores, aplicativos ou outros recursos incluídos em um limite de segurança.
• O cluster de gerenciamento, também conhecido como host AKS, é responsável pela implantação e gerenciamento de vários clusters de carga de trabalho. O cluster de gerenciamento consome 1 endereço IP do pool de nós, mas você deve reservar outros 2 IPs para operações de atualização. O cluster de gerenciamento também consome um IP do pool VIP.
• O Cluster de Carga de Trabalho é uma implantação altamente disponível do Kubernetes usando VMs Linux para executar componentes do plano de controle do Kubernetes e nós de trabalho do Linux e/ou Windows.
  • Plano de controlo. É executado em uma distribuição Linux e contém componentes de servidor de API para interação com a API do Kubernetes e um armazenamento de chave-valor distribuído, etcd, para armazenar toda a configuração e dados do cluster. Ele consome um IP do pool de nós e um IP do pool VIP.
  • Balanceador de carga. É executado em uma VM Linux e fornece serviços com balanceamento de carga para o cluster de carga de trabalho. Ele consome um IP do pool de nós e um IP do pool VIP.
  • Nós de trabalho. Execute em um sistema operacional Windows ou Linux que hospede aplicativos em contêineres. Ele consome endereços IP do pool de nós, mas você deve planejar pelo menos mais 3 endereços IP para operações de atualização.
  • Recursos do Kubernetes. Os pods representam uma única instância do seu aplicativo, que geralmente tem um mapeamento 1:1 com um contêiner, mas certos pods podem conter vários contêineres. As implantações representam um ou mais pods idênticos. Pods e implantações são agrupados logicamente em um namespace que controla o acesso ao gerenciamento dos recursos. Eles consomem 1 IP por pod do pool VIP.
• O Azure Arc é um serviço baseado em nuvem que estende o modelo de gerenciamento baseado no Azure Resource Manager para recursos que não são do Azure, incluindo máquinas virtuais (VMs), clusters Kubernetes e bancos de dados em contêineres.
• O Azure Policy é um serviço baseado na nuvem que avalia o Azure e os recursos locais através da integração com o Azure Arc, comparando propriedades com regras de negócio personalizáveis.
• O Azure Monitor é um serviço baseado na nuvem que maximiza a disponibilidade e o desempenho das suas aplicações e serviços, fornecendo uma solução abrangente para recolher, analisar e atuar na telemetria a partir dos seus ambientes na nuvem e no local.
• O Microsoft Defender for Cloud é um sistema unificado de gerenciamento de segurança de infraestrutura que fortalece a postura de segurança de seus data centers e fornece proteção avançada contra ameaças em suas cargas de trabalho híbridas na nuvem e no local.

Componentes

• Cluster de failover de datacenter do Windows Server 2019/2022
• Azure Kubernetes Service (AKS)
• Centro de Administração do Windows
• Uma assinatura do Azure
• Azure Arc
• Controlo de acesso baseado em funções do Azure (RBAC)
• Azure Monitor
• Microsoft Defender para Cloud

Detalhes do cenário

Os casos de uso para esse cenário são descritos no primeiro artigo da série, Arquitetura de linha de base.

Rede de nós do Kubernetes

A principal consideração no design de rede para o AKS no Azure Local é selecionar o modelo de rede que fornece endereços IP suficientes. O AKS no Azure Local usa a rede virtual para alocar endereços IP aos recursos do nó Kubernetes. Você pode usar dois modelos de atribuição de endereço IP:

• A rede IP estática é mais previsível, mas adiciona esforço extra para a configuração inicial.
• A rede DHCP (Dynamic Host Configuration Protocol) usa alocação dinâmica de endereços IP e menos esforço, mas você precisa ter cuidado para não esgotar o pool disponível de IPs. Você também precisa gerenciar reservas e intervalos de exclusão para pools de IP virtuais e certos recursos de todo o cluster, como o serviço de agente de nuvem.

Ambos os modelos de atribuição devem planejar endereços IP para:

• Pool de IP virtual
• Pool de IP de VM do nó Kubernetes

Pool de IP virtual

Um pool de IP virtual é um conjunto de endereços IP que são obrigatórios para qualquer AKS na implantação Local do Azure. Planeje o número de endereços IP no pool de IP virtual com base no número de clusters de carga de trabalho e serviços Kubernetes. O pool de IP virtual fornece endereços IP para os seguintes tipos de recursos:

• O agente de nuvem requer um endereço IP flutuante do pool de IP virtual.

• O componente de servidor de API que é executado dentro da máquina virtual do Kubernetes Virtual Appliance (KVA) (cluster de gerenciamento) usa um endereço IP do pool de IP virtual. O servidor de API é um componente do plano de controle do Kubernetes que expõe a API do Kubernetes. O servidor de API é o front-end para o plano de controle do Kubernetes. O KVA é uma máquina virtual que executa o Mariner Linux e hospeda um cluster Kubernetes. O endereço IP é flutuante e também é usado para qualquer outra VM KVA que você implantar no AKS no Azure Local. A máquina virtual KVA também hospeda um serviço de balanceador de carga IP virtual do Kubernetes.

• Planeje o endereçamento IP para o número de VMs do plano de controle implantadas nos servidores de destino, pois elas também consomem mais endereços IP do pool de IP virtual. As considerações são descritas na próxima seção.

• O cluster de destino contém uma VM de balanceador de carga, que é HAProxy e possui o Pool de IP virtual para o cluster de destino. Essa VM expõe todos os serviços do Kubernetes por meio do Pool de IP virtual.

• Os aplicativos executados em pods do Kubernetes usam endereços IP do pool de IP virtual.

• O balanceador de carga HAProxy é implantado como uma máquina virtual especializada e pode ser usado para balancear a carga de solicitações de entrada em vários pontos de extremidade. Eles consomem endereços IP do pool de IP virtual e você precisa planejar o endereçamento IP para cada cluster de carga de trabalho.

Pool de IP de VM do nó Kubernetes

Os nós do Kubernetes são implantados como máquinas virtuais em uma implantação AKS no Azure Local. Certifique-se de planejar o número de endereços IP de acordo com o número total de nós do Kubernetes e incluir pelo menos mais três endereços IP usados durante o processo de atualização. Para a configuração de endereço IP estático, você precisa especificar o intervalo do pool de VM do nó Kubernetes, isso não é necessário para a alocação DHCP. Planeje endereços IP adicionais para:

• A VM KVA também usa mais endereço IP para Kubernetes do pool de IP de VM do nó Kubernetes. Planeje adicionar endereços IP durante o processo de atualização, porque a VM KVA usa o mesmo IP virtual para o serviço de API, mas requer um IP separado do pool de IP da VM do nó Kubernetes.
• As VMs do Plano de Controle consomem um IP do pool de IP de VM do nó Kubernetes para o serviço do servidor de API. Essas máquinas virtuais também hospedam o agente ARC do Azure que está se conectando ao portal do Azure para fins de gerenciamento.
• Os nós em um pool de nós (Linux ou Windows) consumirão endereços IP do pool de IP alocado para a VM do nó Kubernetes.

Serviço de nuvem local da Microsoft

Planeje o intervalo de endereços IP para a nuvem local da Microsoft (MOC), que habilita a pilha de gerenciamento para que as VMs no Azure Local sejam gerenciadas na nuvem. A alocação de endereço IP para o serviço MOC está na rede física subjacente e os endereços IP configurados para os nós de cluster Local do Azure estão em seu data center. Você pode configurar endereços IP para os nós físicos do seu Azure Local em uma das seguintes opções:

• Nós de cluster locais do Azure com um modo de alocação de endereço IP baseado em DHCP. O serviço MOC obtém um endereço IP do serviço DHCP apresentado na rede física.
• Nós de cluster locais do Azure com um modelo de alocação de IP estático. O endereço IP do serviço de nuvem MOC deve ser especificado explicitamente como um intervalo IP no formato CIDR (Roteamento Inter-Domain sem Classe) e deve estar na mesma sub-rede que os endereços IP dos nós de cluster Local do Azure.

Balanceador de carga no AKS no Azure Local

Para uma pequena implantação, você pode usar o balanceador de carga interno, implantado como uma VM Linux que usa HAProxy + KeepAlive para enviar tráfego para serviços de aplicativos que são implantados como parte do cluster AKS. O balanceador de carga HAProxy configura pods como pontos de extremidade no balanceador de carga. Ele carrega solicitações de balanceamento para o servidor de API do Kubernetes e gerencia o tráfego para os serviços de aplicativos.

Você também pode usar um balanceador de carga personalizado para gerenciar o tráfego para seus serviços. O balanceador de carga personalizado fornece flexibilidade adicional à implantação e garante que o AKS no Azure Local funcione ao lado de implantações existentes, como implantações SDN (Software Defined Network) que usam balanceadores de carga. Para balanceadores de carga personalizados, o kube-virtual IP fornece aos clusters Kubernetes um IP virtual e um balanceador de carga para o plano de controle e os Serviços Kubernetes do tipo LoadBalancer. O serviço kube-virtual IP é implantado automaticamente em cada nó de trabalho.

O AKS no Azure Local também suporta o uso do MetalLB ou de outros balanceadores de carga baseados em Kubernetes do OSS para equilibrar o tráfego destinado a serviços em um cluster de carga de trabalho. O MetalLB é uma implementação de balanceador de carga para clusters Kubernetes bare metal, usando protocolos de roteamento padrão, como o protocolo BGP do Border Gateway. Ele pode funcionar com ambos os complementos de rede, Calico e Flannel, mas você precisa garantir que o intervalo de endereços IP virtuais fornecido durante a instalação do AKS no Azure Local não esteja sobreposto ao intervalo de endereços IP planejado para o balanceador de carga personalizado.

Implementar este cenário

Implantar um controlador de entrada

Considere a implementação de um controlador de entrada para terminação TLS, proxy reversível ou roteamento de tráfego configurável. Os controladores de entrada funcionam na Camada 7 e podem usar regras inteligentes para distribuir o tráfego do aplicativo. Os recursos de entrada do Kubernetes são utilizados para configurar regras e rotas de entrada para serviços individuais do Kubernetes. Ao definir um controlador de entrada, você consolida as regras de roteamento de tráfego em um único recurso que é executado como parte do cluster.

Use um controlador de entrada para expor serviços por meio de URLs acessíveis externamente. A entrada expõe rotas HTTP e HTTPS de fora do cluster para serviços dentro do cluster. O roteamento de tráfego é controlado por regras definidas no recurso de entrada. As regras HTTP de entrada contêm as seguintes informações:

• Um host opcional. Se você não fornecer informações de host, a regra será aplicada a todo o tráfego HTTP de entrada.
• Uma lista de caminhos que tem um back-end associado definido com um service.name e um service.port.name ou service.port.number.
• Um back-end que fornece uma combinação de nomes de serviço e porta.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Use um controlador de entrada para equilibrar o tráfego entre diferentes back-ends do aplicativo. O tráfego é dividido e enviado para diferentes pontos de extremidade de serviço e implantações, com base nas informações de caminho.

Para rotear o tráfego HTTP para vários nomes de host no mesmo endereço IP, você pode usar um recurso de entrada diferente para cada host. O tráfego que vem através do endereço IP do balanceador de carga é roteado com base no nome do host e no caminho fornecido na regra de entrada.

Conceitos de rede de contêiner no Serviço Kubernetes do Azure (AKS) no Azure Local

O Kubernetes fornece uma camada de abstração para uma rede virtual, para que os aplicativos baseados em contêiner possam se comunicar interna ou externamente. O componente kube-proxy é executado em cada nó e pode fornecer acesso direto ao serviço, distribuir tráfego usando balanceamentos de carga ou usar controladores de entrada para roteamento de aplicativos mais complexos. O Kubernetes usa serviços para agrupar logicamente um conjunto de pods e fornecer conectividade de rede. Os seguintes serviços Kubernetes estão disponíveis:

• IP do cluster: este serviço cria um endereço IP interno para aplicações apenas internas.
• NodePort: Este serviço cria mapeamento de porta no nó subjacente, o que torna o aplicativo diretamente acessível com o endereço IP e a porta do nó.
• LoadBalancer: Você pode expor os serviços do Kubernetes externamente usando regras de balanceador de carga ou um controlador de entrada.
• ExternalName:. Este serviço usa uma entrada DNS específica para o aplicativo Kubernetes.

Redes Kubernetes

No AKS no Azure Local, o cluster pode ser implantado usando um dos seguintes modelos de rede:

• Projeto Calico networking. Este é um modelo de rede padrão para o AKS no Azure Local e é baseado em uma rede de código aberto que fornece segurança de rede para contêineres, máquinas virtuais e cargas de trabalho nativas baseadas em host. A política de rede Calico pode ser aplicada em qualquer tipo de ponto final, como pods, contêineres, VMs ou interfaces de host. Cada política consiste em regras que controlam o tráfego de entrada e saída usando ações que podem, permitir, negar, registrar ou passar o tráfego entre os pontos de extremidade de origem e de destino. O Calico pode usar o Linux extended Berkeley Packet Filter (eBPF) ou o pipeline de rede do kernel Linux para entrega de tráfego. O Calico também é suportado no Windows usando o Host Networking Service (HNS) para criar namespaces de rede por ponto de extremidade de contêiner. No modelo de rede Kubernetes, cada pod recebe seu próprio endereço IP que é compartilhado entre contêineres dentro desse pod. Os pods se comunicam na rede usando endereços IP pod e o isolamento é definido usando políticas de rede. O Calico está usando plug-ins CNI (Container Network Interface) para adicionar ou excluir pods de e para a rede de pods Kubernetes e plug-ins CNI IPAM (IP Address Management) para alocar e liberar endereços IP.
• Rede de sobreposição de flanela. Flannel cria uma camada de rede virtual que sobrepõe a rede host. A rede de sobreposição usa o encapsulamento dos pacotes de rede na rede física existente. O Flannel simplifica o Gerenciamento de Endereço IP (IPAM), suporta a reutilização de IP entre diferentes aplicativos e namespaces e fornece separação lógica de redes de contêiner da rede subjacente usada pelos nós do Kubernetes. O isolamento de rede é obtido usando a Virtual eXtensible Local Area Network (VXLAN), um protocolo de encapsulamento que fornece conectividade de data center usando tunelamento para esticar conexões de Camada 2 em uma rede de Camada 3 subjacente. O Flannel é suportado tanto por contêineres Linux usando DaemonSet quanto por contêineres Windows usando o plug-in Flannel CNI.

Azure Design de rede local

O design geral de rede inclui atividades de planejamento para o Azure Local.

Primeiro, comece planejando o hardware e a instalação do Azure Local. Você pode comprar sistemas integrados de um parceiro de hardware da Microsoft com o sistema operacional HCI do Azure Stack pré-instalado ou pode comprar nós validados e instalar o sistema operacional por conta própria. O Azure Local destina-se a ser um host de virtualização, portanto, as funções de servidor do Kubernetes devem ser executadas dentro de VMs.

Requisitos de rede física para o Azure Local

A Microsoft não certifica comutadores de rede, mas tem certos requisitos que o fornecedor do equipamento deve satisfazer:

• Padrão: IEEE 802.1Q que define uma rede local virtual (VLAN).
• Padrão: IEEE 802.1Qbb que define o Controle de Fluxo Prioritário (PFC).
• Padrão: IEEE 802.1Qaz que define Enhanced Transmission Selection (ETS).
• Padrão: IEEE 802.1AB que define o protocolo LLTD (Link Layer Topology Discovery).

Requisitos de rede de host para o Azure Local

Considere o uso de um adaptador de rede que tenha obtido a certificação SDDC (Windows Server Software Defined Data Center) com a Qualificação Adicional Standard ou Premium (AQ).

Certifique-se de que o adaptador de rede suporta:

• Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ ou d.VMMQ) é uma tecnologia inteligente do lado da receção para ajuste automático do processamento de tráfego de rede para núcleos de CPU.
• O Acesso Remoto Direto à Memória (RDMA) é um descarregamento de pilha de rede para o adaptador de rede. Ele permite que o tráfego de armazenamento SMB ignore o sistema operacional para processamento.
• O RDMA convidado permite que as cargas de trabalho SMB para VMs obtenham os mesmos benefícios do uso do RDMA em hosts.
• Switch Embedded Teaming (SET) é uma tecnologia de agrupamento baseada em software.

Considere o uso do ATC de rede, que fornece controle baseado em intenção para simplificar a configuração de rede do host.

O AKS em um Azure Local requer uma conexão de rede confiável de alta largura de banda e baixa latência entre cada nó de servidor. Verifique se pelo menos um adaptador de rede está disponível e dedicado para gerenciamento de cluster. Verifique também se os comutadores físicos na sua rede estão configurados para permitir o tráfego em quaisquer VLANs que irá utilizar.

Comutador virtual

O Azure Local simplifica o design de rede configurando um comutador virtual que pode ser usado para classificação de rede. A placa de interface de rede virtual (vNIC) pode ser colocada em VLANs diferentes para que os hosts forneçam fluxo de tráfego diferente para as seguintes redes:

• Rede de gestão. A rede de gestão faz parte da rede norte-sul e é utilizada para a comunicação do anfitrião.
• Rede de computação. A rede de computação faz parte da rede norte-sul e é usada para o tráfego de máquinas virtuais. Use a Qualidade de Serviço (QOS), a virtualização de E/S de raiz única (SR-IOV) e o Acesso Remoto Direto à Memória (vRDMA) virtual para ajustar o desempenho da rede com base na demanda.
• Rede de armazenamento. A rede de armazenamento faz parte da rede leste-oeste e requer RDMA com taxa de transferência recomendada de 10GB+. Ele é usado para migração ao vivo das VMs.
• Rede de convidados VM.

Benefício do tráfego Leste-Oeste do tráfego RDMA

O tráfego de rede Leste-Oeste representa a comunicação entre os hosts e não expõe nenhum acesso externo. O tráfego permanece dentro do switch Top of Rack (ToR) e do limite da Layer-2. Inclui os seguintes tipos de tráfego:

• Batimentos cardíacos de cluster e comunicação entre nós
• [SMB] Camada de barramento de armazenamento
• [SMB] Volume Compartilhado do Cluster
• [SMB] Reconstrução de armazenamento

Tráfego Norte-Sul

North-South tráfego é o tráfego externo que chega ao AKS na instância Local do Azure. Pode planear o tráfego para a gama de serviços do Azure que permitem a monitorização, faturação e gestão de segurança através da integração do Azure ARC. O tráfego Norte-Sul tem as seguintes características:

• O tráfego flui de um interruptor ToR para a coluna ou da coluna para um interruptor ToR.
• O tráfego sai do rack físico ou atravessa um limite de camada 3 (IP).
• O tráfego inclui gerenciamento (PowerShell, Windows Admin Center), computação (VM) e tráfego de cluster estendido entre sites.
• Usa um switch Ethernet para conectividade com a rede física.

O AKS no Azure Local pode usar várias opções de implantação de rede de cluster:

• Rede convergente combinando várias intenções de rede (MGMT, computação, armazenamento). Esta é a implantação recomendada para mais de três nós físicos e requer que todos os adaptadores de rede física estejam conectados aos mesmos switches ToR. ROCEv2 é altamente recomendado.
• A implantação sem switch usa a comunicação Norte-Sul como uma equipe de rede, combinando redes de computação e gerenciamento.
• Implantação híbrida como uma combinação de ambas as implantações.

Recomendações

As recomendações seguintes aplicam-se à maioria dos cenários. Siga as recomendações, a menos que tenha um requisito específico que o substitua.

Recomendações de rede

A principal preocupação no design de rede para o AKS no Azure Local é selecionar um modelo de rede que forneça endereços IP suficientes para seu cluster Kubernetes e seus serviços e aplicativos.

• Considere a implementação de endereços IP estáticos para permitir que o AKS no Azure Local controle a atribuição de endereços IP.

• Dimensione corretamente os intervalos de endereços IP para que você tenha endereços IP livres suficientes para um pool de nós do Kubernetes e para um pool de IP virtual. Certifique-se de que seu pool de IP virtual seja grande o suficiente para que, sempre que estiver atualizando, possa usar atualizações contínuas, que exigem mais endereços IP. Você pode planejar o seguinte:

  • Endereçamento/nomes de host para configurações de proxy
  • Endereços IP para o plano de controle de cluster de destino
  • Endereços IP para o Azure ARC
  • Endereços IP para dimensionamento horizontal de nós do plano de trabalho e controle em clusters de destino

• Seu pool de IP virtual deve ser grande o suficiente para suportar a implantação dos serviços de aplicativos que exigem conectividade com o roteador externo.

• Implemente o Calico CNI para fornecer uma política de rede aprimorada para controlar a comunicação do pod e do aplicativo.

• Verifique se os nós de cluster físicos (HCI ou Windows Server) estão localizados no mesmo rack e conectados aos mesmos switches ToR.

• Desative o IPv6 em todos os adaptadores de rede.

• Certifique-se de que o comutador virtual existente e seu nome sejam os mesmos em todos os nós do cluster.

• Verifique se todas as sub-redes definidas para o cluster são roteáveis entre si e para a Internet.

• Verifique se há conectividade de rede entre os hosts locais do Azure e as VMs do locatário.

• Habilite atualizações de DNS dinâmicas em seu ambiente DNS para permitir que o AKS no Azure Local registre o nome do cluster genérico do agente de nuvem no sistema DNS para descoberta.

• Considere implementar a classificação do tráfego de rede por sua direção:

  • North-South tráfego é o tráfego do Azure Local e do resto da rede,
    • Gestão
    • Computação
    • Tráfego de cluster estendido entre locais
  • East-West tráfego no Azure Local:
    • Tráfego de armazenamento, incluindo migração ao vivo entre nós no mesmo cluster.
    • Comutador Ethernet ou ligação direta.

Modelos de tráfego de armazenamento

• Use várias sub-redes e VLANs para separar o tráfego de armazenamento no Azure Local.
• Considere a implementação da alocação de largura de banda de tráfego de vários tipos de tráfego.

Considerações

O Microsoft Azure Well-Architected Framework é um conjunto de princípios orientadores que são seguidos neste cenário. As considerações a seguir são enquadradas no contexto desses princípios.

Fiabilidade

• Resiliência integrada, inerente à computação definida por software da Microsoft (cluster de failover de nós Hyper-V), armazenamento (resiliência aninhada direta de Espaços de Armazenamento) e rede (Rede definida por software).
• Considere selecionar o switch de rede que suporta os padrões do setor e garante comunicações confiáveis entre nós. As seguintes normas incluem:
  • Padrão: IEEE 802.1Q
  • Padrão IEEE 802.1Qbb
  • Padrão IEEE 802.1 Qas
  • Padrão IEEE 802.1 AB
• Considere implementar vários hosts no cluster de gerenciamento e no cluster Kubernetes para atender ao nível mínimo de disponibilidade para cargas de trabalho.
• O AKS no Azure Local usa clustering de failover e migração ao vivo para alta disponibilidade e tolerância a falhas. A migração ao vivo é um recurso do Hyper-V que permite mover máquinas virtuais em execução de forma transparente de um host Hyper-V para outro sem tempo de inatividade percebido.
• Você deve garantir que os serviços referenciados na seção Arquitetura tenham suporte na região na qual o Azure Arc está implantado.

Segurança

• Proteja o tráfego entre pods usando políticas de rede no AKS no Azure Local.
• O servidor de API no AKS no Azure Local contém a Autoridade de Certificação que assina certificados para comunicação do servidor de API do Kubernetes para kubelet.
• Use o logon único (SSO) do Microsoft Entra para criar uma conexão segura com o servidor de API do Kubernetes.
• Você pode usar o RBAC do Azure para gerenciar o acesso ao Kubernetes habilitado para Azure Arc em ambientes do Azure e locais usando identidades do Microsoft Entra. Para obter mais informações, consulte Usar o RBAC do Azure para autorização do Kubernetes.

Otimização de custos

• Use a calculadora de preços do Azure para estimar os custos dos serviços usados na arquitetura. Outras práticas recomendadas são descritas na seção de otimização de custos no Microsoft Azure Well-Architected Framework.
• Considere implementar o hyper-threading no seu computador físico, para otimizar o custo, porque a unidade de faturação AKS on Azure Local é um núcleo virtual.
• A funcionalidade do plano de controle do Azure Arc é fornecida sem custo extra. Isso inclui suporte para organização de recursos por meio de grupos de gerenciamento e tags do Azure e controle de acesso por meio do Azure RBAC. Os serviços do Azure usados em conjunto com os servidores habilitados para Azure Arc incorrem em custos de acordo com seu uso.
• Para obter uma boa relação custo-benefício, você pode usar apenas dois nós de cluster com apenas quatro discos e 64 gigabytes (GB) de memória por nó. Para minimizar ainda mais os custos, você pode usar interconexões sem switch entre nós, eliminando assim a necessidade de dispositivos de switch redundantes.

Excelência operacional

• Gerenciamento simplificado usando o Windows Admin Center. O Windows Admin Center é a interface do usuário para criar e gerenciar o AKS no Azure Local. Ele pode ser instalado no Windows 10/11 ou na VM do Windows Server que precisam ser registradas no Azure e estão no mesmo domínio que o cluster do Azure Local ou do Windows Server Datacenter.
• Integração com o Azure Arc ou uma variedade de serviços do Azure que fornecem mais recursos de gerenciamento, manutenção e resiliência (Azure Monitor, Backup do Azure).
• Se o cluster do Kubernetes estiver conectado ao Azure Arc, você poderá gerenciar o cluster do Kubernetes usando o GitOps. Para revisar as práticas recomendadas para conectar um cluster Kubernetes híbrido ao Azure Arc, consulte o cenário de gerenciamento e implantação híbridos do Azure Arc para clusters Kubernetes.
• A plataforma Azure Local também ajuda a simplificar a rede virtual para AKS em instâncias locais do Azure, fornecendo a rede "subjacente" de uma forma altamente disponível.

Eficiência de desempenho

• Use o hardware certificado do Azure Local para melhorar o tempo de atividade e o desempenho do aplicativo, simplificar o gerenciamento e as operações e reduzir o custo total de propriedade.
• Armazenamento: Espaços de armazenamento diretos
  • Configuração de volume (espelho bidirecional aninhado versus paridade acelerada por espelho aninhada)
  • Configuração de disco (cache, camadas)
• Verifique se os nós do cluster estão fisicamente localizados no mesmo rack e conectados aos mesmos switches ToR.
• Planeje reservas de endereços IP para configurar hosts AKS, clusters de carga de trabalho, servidores de API de cluster, serviços Kubernetes e serviços de aplicativos. A Microsoft recomenda reservar um mínimo de 256 endereços IP para implantação do AKS no Azure Local.
• Considere implementar um controlador de entrada que funcione na camada 7 e use regras mais inteligentes para distribuir o tráfego do aplicativo.
• Use a aceleração da unidade de processamento gráfico (GPU) para cargas de trabalho extensas.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Lisa DenBeste - Brasil | Gerente do Programa de Gerenciamento de Projetos
• Kenny Harder - Brasil | Gestor de Projeto
• Mike Kostersitz - Brasil | Gerente Principal de Programa Líder
• Meg Olsen - Brasil | Mandante
• Nate Águas | Gerente de Marketing de Produto

Outros contribuidores:

• Walter Oliver - Brasil | Gerente de Programa Sênior

Próximos passos

• Descrição geral do AKS

Recursos relacionados

• Arquitetura de linha de base para AKS no Azure Local