Editar

Compartilhar via

Arquitetura de rede para o Serviço de Kubernetes do Azure no Azure Stack HCI

Azure Stack Hub
Windows Server

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

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

Arquitetura

A imagem a seguir mostra a arquitetura de rede para o Serviço de Kubernetes do Azure no Azure Stack HCI ou clusters de datacenter do Windows Server 2019/2022:

Conceptual graphic showing network baseline architecture.

Baixe um Arquivo Visio dessa arquitetura.

O cenário consiste nos seguintes componentes e recursos:

  • O Azure Stack HCI (20H2) é uma solução de cluster de HCI (infraestrutura hiperconvergente) que hospeda cargas de trabalho virtualizadas do Windows e do Linux e seus armazenamentos em um ambiente híbrido local. O cluster do Azure Stack HCI é implementado como um cluster de 2 a 4 nós.
  • O cluster de failover do datacenter do Windows Server 2019/2022 é um conjunto de computadores independentes que trabalham em conjunto para aumentar a disponibilidade e a escalabilidade de funções clusterizadas.
  • O Serviço de Kubernetes do Azure no Azure Stack HCI (AKS híbrido) é uma implementação local do AKS (Serviço de Kubernetes do Azure), que automatiza a execução de aplicativos conteinerizados em escala.
  • O [Active Directory Domain Services] [] é uma estrutura hierárquica que armazena informações sobre objetos na rede. Ele fornece uma 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 do AKS, é responsável por implantar e gerenciar vários clusters de carga de trabalho. O cluster de gerenciamento consome um endereço IP do pool de nós, mas você deve reservar outros dois IPs para operações de atualização. O cluster de gerenciamento também consome um IP do pool de VIPs.
  • 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.
    • Painel de controle. É executado em uma distribuição do Linux e contém componentes do servidor de API para interação com a API do Kubernetes e um repositório de chave-valor distribuído, etcd, para armazenar toda a configuração e os dados do cluster. Ele consome um IP do pool de nós e um IP do pool de VIPs.
    • Balanceador de carga. É executado em uma VM do 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 de VIPs.
    • Nós de trabalho. Executado em um sistema operacional Windows ou Linux que hospeda aplicativos em contêineres. Ele consome endereços IP do pool de nós, mas você deve planejar pelo menos mais três endereços IP para operações de atualização.
    • Recursos do Kubernetes. Os pods representam uma única instância do aplicativo, que geralmente tem um mapeamento 1:1 com um contêiner, mas determinados 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 um IP por pod do pool de VIPs.
  • 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 sejam do Azure, incluindo máquinas virtuais (VMs), clusters do Kubernetes e bancos de dados em contêineres.
  • O [Azure Policy] [] é um serviço baseado em nuvem que avalia os recursos locais e do Azure por meio da integração com o Azure Arc comparando propriedades com regras de negócios personalizáveis.
  • O [Azure Monitor][] é um serviço baseado em nuvem que maximiza a disponibilidade e o desempenho de seus aplicativos e serviços fornecendo uma solução abrangente para coletar, analisar e agir em relação a dados telemétricos de seus ambientes locais e de nuvem.
  • O [Microsoft Defender para Nuvem][] é um sistema unificado de gerenciamento de segurança de infraestrutura que reforça a postura de segurança dos datacenters e fornece proteção avançada contra ameaças para todas às cargas de trabalho híbridas na nuvem e local.

Componentes

  • [Azure Stack HCI (20H2)][1]
  • [Cluster de failover do datacenter do Windows Server 2019/2022] []
  • [Serviço de Kubernetes do Azure (AKS)][]
  • [Windows Admin Center][]
  • [Uma assinatura do Azure][]
  • [Azure Arc][2]
  • [Controle de acesso baseado em função (RBAC) do Azure][]
  • [Azure Monitor][3]
  • [Microsoft Defender para Nuvem][4]

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 Serviço de Kubernetes do Azure no Azure Stack HCI é selecionar o modelo de rede que fornece endereços IP suficientes. O Serviço de Kubernetes do Azure no Azure Stack HCI usa a rede virtual para alocar endereços IP para os recursos de nó do Kubernetes. Você pode usar dois modelos de atribuição de endereços IP:

  • A rede IP estática é mais previsível, mas adiciona esforço extra para a configuração inicial.
  • A rede de protocolo DHCP usa a 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 os pools de IP virtuais e determinados recursos em todo o cluster, como o serviço do agente de nuvem.

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

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

Pool de IP virtual

Um pool de IP virtual é um conjunto de endereços IP obrigatórios para qualquer implantação do Serviço de Kubernetes do Azure no Azure Stack HCI. 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 nos serviços do 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 do servidor de API executado dentro da máquina virtual (cluster de gerenciamento) de KVA (solução de virtualização do Kubernetes) usa um endereço IP do pool de IP virtual. O servidor de API é um componente do painel de controle do Kubernetes que expõe a API do Kubernetes. O servidor de API é o front-end do painel de controle do Kubernetes. A KVA é uma máquina virtual que executa o Mariner Linux e hospeda um cluster do Kubernetes. O endereço IP é flutuante e também é usado para qualquer outra VM de KVA implantada no Serviço de Kubernetes do Azure no Azure Stack HCI. A máquina virtual de KVA também hospeda um serviço de balanceador de carga de IP virtual do Kubernetes.

  • Planeje o endereçamento IP para o número de VMs do painel 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 do 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 nos 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 da VM do nó do Kubernetes

Os nós do Kubernetes são implantados como máquinas virtuais em uma implantação do Serviço de Kubernetes do Azure no Azure Stack HCI. Planeje o número de endereços IP de acordo com o número total de nós do Kubernetes e inclua pelo menos mais três endereços IP são 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 IP da VM do nó do Kubernetes. Isso não é necessário para alocação DHCP. Planeje endereços IP adicionais para:

  • A VM da KVA também usa mais endereço IP para Kubernetes do pool de IP da VM do nó do Kubernetes. Planeje adicionar endereços IP durante o processo de atualização, pois a VM da 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ó do Kubernetes.
  • As VMs do Painel de Controle consomem um IP do pool de IP da VM do nó do Kubernetes para o serviço de servidor de API. Essas máquinas virtuais também hospedam o agente do Azure ARC 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ó do Kubernetes.

Serviço de nuvem local da Microsoft

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

  • Nós do cluster do Azure Stack HCI com um modo de alocação de endereço IP baseado em DHCP. O serviço de MOC obtém um endereço IP do serviço DHCP apresentado na rede física.
  • Nós do cluster do Azure Stack HCI 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 de IP no formato CIDR (Roteamento entre Domínios sem Classificação) e deve estar na mesma sub-rede que os endereços IP dos nós de cluster do Azure Stack HCI.

Balanceador de carga no Serviço de Kubernetes do Azure no Azure Stack HCI

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

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 Serviço de Kubernetes do Azure no Azure Stack HCI funcione junto com implantações existentes, como implantações de SDN (Rede Definida por Software) que usam balanceadores de carga. Para balanceadores de carga personalizados, o IP kube-virtual fornece clusters do Kubernetes com um IP virtual e balanceador de carga para o painel de controle e os Serviços do Kubernetes do tipo LoadBalancer. O serviço de IP kube-virtual é implantado automaticamente em cada nó de trabalho.

O AKS no Azure Stack HCI também dá suporte ao uso do MetalLB ou de outros balanceadores de carga baseados no Kubernetes de software de código aberto 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 de computador bare-metal do Kubernetes, usando protocolos de roteamento padrão, como o BGP (Border Gateway Protocol). Ele pode funcionar com complementos de rede, Calico e Flannel, mas você precisa garantir que o intervalo de endereços IP virtual fornecido durante a instalação do AKS no Azure Stack HCI não esteja sobreposto com o intervalo de endereços IP planejado para o balanceador de carga personalizado.

Implantar este cenário

Implantar um controlador de entrada

Considere implementar 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 de aplicativos. Os recursos de entrada de Kubernetes são usados para configurar as regras de entrada e as rotas para os serviços de Kubernetes individuais. Quando você define um controlador de entrada, consolida as regras de roteamento de tráfego em um único recurso 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 do 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 por meio 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 AKS (Serviço de Kubernetes do Azure) no Azure Stack HCI

O Kubernetes fornece uma camada de abstração para uma rede virtual, para que os aplicativos baseados em contêiner possam se comunicar internamente 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 aplicativo mais complexo. O Kubernetes usa serviços para agrupar logicamente um conjunto de pods e fornecer conectividade de rede. Os seguintes serviços do Kubernetes estão disponíveis:

  • Cluster IP: esse serviço cria um endereço IP interno para aplicativos somente internos.
  • NodePort: esse serviço cria um mapeamento de porta no nó subjacente, o que torna o aplicativo diretamente acessível com o endereço IP do nó e a porta.
  • LoadBalancer: você pode expor os serviços do Kubernetes externamente usando regras de balanceador de carga ou um controlador de entrada.
  • ExternalName:. Esse serviço usa uma entrada DNS específica para o aplicativo Kubernetes.

Redes do Kubernetes

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

  • [Rede do Projeto Calico][]. Esse é um modelo de rede padrão para o AKS no Azure Stack HCI e se baseia em uma rede de software livre 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 do Calico pode ser aplicada em qualquer tipo de ponto de extremidade, 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 pontos de extremidade de origem e destino. O Calico pode usar tanto o Linux Extended Berkeley Packet Filter (eBPF) quanto o pipeline de rede do kernel Linux para a entrega de tráfego. O Calico também tem suporte no Windows usando o HNS (Serviço de Rede do Host) para criar namespaces de rede por ponto de extremidade de contêiner. No modelo de rede do Kubernetes, cada pod obtém seu próprio endereço IP compartilhado entre contêineres dentro desse pod. Os pods se comunicam na rede usando endereços IP de pod e o isolamento é definido usando políticas de rede. O Calico está usando plug-ins de CNI (Interface de Rede do Contêiner) para adicionar ou excluir pods de e para a rede de pod do Kubernetes e plug-ins de IPAM (Gerenciamento de Endereço IP) para alocar e liberar endereços IP.
  • [Rede de sobreposição Flannel.] [] O Flannel cria uma camada de rede virtual que sobrepõe a rede de host. A rede de sobreposição usa o encapsulamento dos pacotes de rede pela rede física existente. O Flannel simplifica o IPAM (Gerenciamento de Endereços IP), dá suporte à reutilização de IP entre diferentes aplicativos e namespaces e fornece separação lógica de redes de contêiner da rede de base usada pelos nós do Kubernetes. O isolamento de rede é obtido usando a VXLAN (Virtual eXtensible Local Area Network), um protocolo de encapsulamento que fornece conectividade em datacenters usando túneis para estender conexões de Camada 2 sobre uma rede subjacente de Camada 3. O Flannel é compatível com contêineres do Linux usando contêineres DaemonSet e do Windows usando plug-in de CNI do Flannel.

Design de rede do Azure Stack HCI

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

Primeiro, comece planejando o hardware e a instalação do Azure Stack HCI. Você pode comprar sistemas integrados de um parceiro de hardware da Microsoft com o sistema operacional Azure Stack HCI pré-instalado ou comprar nós validados e instalar o sistema operacional por conta própria. O Azure Stack HCI destina-se a 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 Stack HCI

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

  • Padrão: IEEE 802.1Q, que define uma VLAN (rede local virtual).
  • Padrão: IEEE 802.1Qbb, que define o controle do fluxo de prioridade (PFC).
  • Padrão: IEEE 802.1Qaz, que define a ETS (seleção de transmissão avançada).
  • Padrão: IEEE 802.1AB, que define o protocolo LLTD (descoberta de topologia da camada de link).

Requisitos de rede de host para o Azure Stack HCI

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

Verifique se o adaptador de rede dá suporte a:

  • [Várias Filas de Máquina Virtual Dinâmica][] (VMMQ dinâmico ou d.VMMQ): é uma tecnologia inteligente do lado do recebimento para ajuste automático do processamento de tráfego de rede para núcleos de CPU.
  • RDMA (Acesso remoto à memória direta): é um descarregamento de pilha de rede para o adaptador de rede. Ele permite que o tráfego de armazenamento do SMB ignore o sistema operacional para processamento.
  • O RDMA convidado permite que cargas de trabalho do SMB para VMs obtenham os mesmos benefícios de usar RDMA em hosts.
  • O Switch Embedded Teaming (SET) é uma tecnologia de agrupamento baseada em software.

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

O AKS em um Azure Stack HCI requer uma conexão de rede confiável de alta largura de banda e baixa latência entre cada nó do 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 em sua rede estão configurados para permitir o tráfego em qualquer VLANs que você usará.

Comutador virtual

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

  • Rede de gerenciamento. A rede de gerenciamento faz parte da rede norte-sul e é usada para comunicação de host.
  • Rede de computação. A rede de computação faz parte da rede norte-sul e é usada para tráfego de máquina virtual. Use a QOS (Qualidade de Serviço), a virtualização de E/S de raiz única (SR-IOV) e o vRDMA (Acesso remoto direto à memória) 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 10 GB ou mais. Ele é usado para migração dinâmica das VMs.
  • Rede de convidados da VM.

Benefício do tráfego leste-oeste ao usar 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 comutador Top of Rack (ToR) e do limite de Camada 2. Ele inclui os seguintes tipos de tráfego:

  • Pulsações de cluster e comunicação entre nós
  • [SMB] Camada do Barramento de Armazenamento
  • [SMB] Volume Compartilhado de Cluster
  • [SMB] Recompilação de armazenamento

Tráfego norte-sul

O tráfego norte-sul é o tráfego externo que atinge o AKS no cluster do Azure Stack HCI. Você pode planejar o tráfego para o intervalo de serviços do Azure que habilitam o monitoramento, a cobrança e o gerenciamento de segurança por meio da integração do Azure ARC. O tráfego norte-sul tem as seguintes características:

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

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

  • Rede convergida combinando várias intenções de rede (MGMT, computação, armazenamento). Essa é 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 comutadores ToR. O ROCEv2 é altamente recomendado.
  • A implantação sem comutador 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 seguintes recomendações aplicam-se à maioria dos cenários. Siga as recomendações, a menos que você tenha um requisito específico que o substitua.

Recomendações de rede

A principal preocupação no design de rede do AKS no Azure Stack HCI é selecionar um modelo de rede que fornece endereços IP suficientes para o cluster do Kubernetes e seus serviços e aplicativos.

  • Considere implementar endereços IP estáticos para permitir que o AKS no Azure Stack HCI controle a atribuição de endereço 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. Verifique se o pool de IP virtual é grande o suficiente para que sempre que você for atualizar, possa usar atualizações sem interrupção, 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 painel de controle do cluster de destino
    • Endereços IP para o Azure ARC
    • Endereços IP para dimensionamento horizontal de nós do painel de controle e trabalho nos clusters de destino

  • Seu pool de IP virtual deve ser grande o suficiente para dar suporte à implantação dos serviços de aplicativo que exigem conectividade com o roteador externo.

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

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

  • Desabilite o IPv6 em todos os adaptadores de rede.

  • Verifique se o comutador virtual existente e seu nome são iguais em todos os nós de 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 do Azure Stack HCI e as VMs do locatário.

  • Habilite atualizações DNS dinâmicas em seu ambiente DNS para permitir que o AKS no Azure Stack HCI 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:

    • O tráfego norte-sul é o tráfego do Azure Stack HCI e o restante da rede,
      • Gerenciamento
      • Computação
      • Tráfego de cluster estendido entre sites
    • Tráfego leste-oeste dentro do Azure Stack HCI:
      • Tráfego de armazenamento, incluindo migração dinâmica entre nós no mesmo cluster.
      • Comutador Ethernet ou conexão direta.

Modelos de tráfego de armazenamento

  • Use várias sub-redes e VLANs para separar o tráfego de armazenamento no Azure Stack HCI.
  • Considere implementar a 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 nesse cenário. As considerações a seguir são enquadradas no contexto desses princípios.

Confiabilidade

  • Resiliência interna, inerente à computação definida pelo software da Microsoft (cluster de failover de nós do Hyper-V), armazenamento (resiliência aninhada dos Espaços de Armazenamento Diretos) e rede (Rede Definida pelo Software).
  • Considere selecionar o comutador de rede que dá suporte aos padrões do setor e garante comunicações confiáveis entre nós. Os seguintes padrões 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 do Kubernetes para atender ao nível mínimo de disponibilidade para cargas de trabalho.
  • O AKS no Azure Stack HCI usa o clustering de failover e a migração dinâmica para alta disponibilidade e tolerância a falhas. A migração dinâmica é um recurso do Hyper-V que permite mover de forma transparente as máquinas virtuais em execução de um host do Hyper-V para outro sem tempo de inatividade percebido.
  • Você deve garantir que os serviços referenciados na seção de Arquitetura tenham suporte na região na qual o Azure Arc está implantado.

Segurança

  • Proteger o tráfego entre pods usando políticas de rede no AKS no Azure Stack HCI.
  • O servidor de API no AKS no Azure Stack HCI contém a Autoridade de Certificação que assina certificados para comunicação do servidor de API do Kubernetes para kubelet.
  • Use o SSO (logon único) 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 locais e do Azure usando identidades do Microsoft Entra. Para saber mais, confira [Usar o RBAC do Azure para autorização do Kubernetes][].

Otimização de custo

  • Use a [calculadora de preços do Azure][] para estimar os custos para os serviços usados na arquitetura. Outras melhores práticas são descritas na seção [Otimização de custos][] no [Microsoft Azure Well-Architected Framework.][]
  • Considere implementar o hiper-threading em seu computador físico, para otimizar o custo, pois a unidade de cobrança do AKS no Azure Stack HCI é um núcleo virtual.
  • A funcionalidade de painel de controle do Azure Arc é fornecida sem custo adicional. Isso inclui suporte para a organização de recursos por meio de grupos de gerenciamento e marcas do Azure e controle de acesso por meio do RBAC do Azure. Os serviços do Azure usados em conjunto com servidores habilitados para Azure Arc incorrem em custos de acordo com seu uso.
  • Para fins de custo-benefício, você pode usar apenas dois nós de cluster com apenas quatro discos e 64 GB (gigabytes) de memória por nó. Para minimizar ainda mais os custos, você pode usar interconexões sem comutadores entre nós, eliminando assim a necessidade de comutadores 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 Stack HCI. Ele pode ser instalado na VM do Windows 10/11 ou do Windows Server que precisa ser registrada no Azure e está no mesmo domínio que o cluster do Azure Stack HCI 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 [anexado ao Azure Arc][serviço de Kubernetes habilitado para Azure Arc], você poderá [gerenciar o cluster do Kubernetes usando o GitOps][]. Para examinar as melhores práticas para conectar um cluster do Kubernetes híbrido ao Azure Arc, consulte o cenário [Gerenciamento e implantação híbrida do Azure Arc para clusters do Kubernetes][].
  • A plataforma do Azure Stack HCI também ajuda a simplificar a rede virtual para clusters do AKS no Azure Stack HCI, fornecendo a rede "subjacente" de maneira altamente disponível.

Eficiência de desempenho

  • Use o hardware certificado pelo Azure Stack HCI para melhorar o tempo de atividade e o desempenho do aplicativo, simplificar o gerenciamento e as operações e ter o menor custo total de propriedade.
  • Armazenamento: Espaços de Armazenamento Diretos
    • Configuração de volume (espelho bidirecional aninhado versus paridade aninhada acelerada por espelho)
    • Configuração de disco (cache, camadas)
  • Verifique se os nós de cluster estão fisicamente localizados no mesmo rack e conectados aos mesmos comutadores ToR.
  • Planeje reservas de endereço IP para configurar hosts do AKS, clusters de carga de trabalho, servidores de API do cluster, Serviços do Kubernetes e serviços de aplicativo. A Microsoft recomenda reservar um mínimo de 256 endereços IP para implantação do AKS no Azure Stack HCI.
  • 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 GPU (unidade de processamento gráfico) para cargas de trabalho extensas.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autores principais:

Outros colaboradores:

Próximas etapas