Editar

Share via

Arquitetura de rede para AKS no Azure Stack HCI

Azure Stack
Windows Server

Este cenário ilustra como projetar e implementar conceitos de rede para implantar nós do Serviço Kubernetes do Azure (AKS) em clusters híbridos 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 Stack HCI ou Windows Server 2019/2022:

Conceptual graphic showing network baseline architecture.

Transfira um ficheiro do Visio desta arquitetura.

O cenário consiste nos seguintes componentes e recursos:

  • O Azure Stack HCI (20H2) é 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. O cluster HCI do Azure Stack é implementado 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.
  • O Serviço Kubernetes do Azure no Azure Stack HCI (AKS híbrido) é uma implementação local do Serviço Kubernetes do Azure (AKS), que automatiza a execução de aplicativos em contêineres em escala.
  • [Serviços de Domínio Ative Directory] [] é 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.
  • [Cluster de gestão] [] 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.
  • [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 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.
  • [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.
  • [Política do Azure] [] é 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.
  • [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 telemetria de seus ambientes de nuvem e locais.
  • [Microsoft Defender para 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

  • [Azure Stack HCI (20H2)] [1]
  • [Cluster de failover de datacenter do Windows Server 2019/2022] []
  • [Serviço Kubernetes do Azure (AKS)] []
  • [Centro de Administração do Windows] []
  • [Uma subscrição do Azure] []
  • [Azure Arc] [2]
  • [RBAC (controle de acesso baseado em função) do Azure] []
  • [Azure Monitor] [3]
  • [Microsoft Defender para Cloud] [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 AKS no Azure Stack HCI é selecionar o modelo de rede que fornece endereços IP suficientes. AKS no Azure Stack HCI usa rede virtual para alocar endereços IP para os 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 implantação do AKS 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 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 implantada no AKS no Azure Stack HCI. 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 do AKS on Azure Stack HCI. 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 Stack HCI sejam gerenciadas na nuvem. A alocação de endereços IP para o serviço MOC está na rede física subjacente e os endereços IP configurados para os nós de cluster HCI do Azure Stack estão em seu data center. Você pode configurar endereços IP para os nós físicos do seu Azure Stack HCI em um dos seguintes:

  • Nós de cluster HCI do Azure Stack 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 HCI do Azure Stack 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 entre Domínios sem Classe) e deve estar na mesma sub-rede que os endereços IP dos nós de cluster HCI do Azure Stack.

Balanceador de carga no AKS no Azure Stack HCI

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 Stack HCI 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 Stack HCI também oferece suporte ao 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 Stack HCI 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 [ingress controller][] 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 do contentor no Azure Kubernetes Service (AKS) 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 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 Stack HCI, o cluster pode ser implantado usando um dos seguintes modelos de rede:

  • [Projeto Calico networking] []. Este é um modelo de rede padrão para AKS no Azure Stack HCI 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.

Design de rede HCI do Azure Stack

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 pode comprar nós validados e instalar o sistema operacional por conta própria. O Azure Stack HCI 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 Stack HCI

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 HCI do Azure Stack

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:

  • [Máquina Virtual Dinâmica Multi-Fila] [] (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 de [Network ATC][], que fornece controle baseado em intenção para simplificar a configuração de rede do host.

O AKS em um HCI do Azure Stack 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 Stack HCI 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

O tráfego Norte-Sul é o tráfego externo que atinge o AKS no cluster HCI do Azure Stack. 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 Stack HCI 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 Stack HCI é 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 Stack HCI 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 HCI do Azure Stack e as VMs locatárias.

  • Habilite atualizações de 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 do resto da rede,
      • Gestão
      • Computação
      • Tráfego de cluster estendido entre locais
    • Tráfego Leste-Oeste no Azure Stack HCI:
      • 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 Stack HCI.
  • 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 Stack HCI 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 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 o 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 [otimização de custos][] em [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 Stack HCI é 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 Stack HCI. 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 Azure Stack HCI ou 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 Kubernetes estiver [anexado ao Azure Arc][serviço Kubernetes habilitado para Azure Arc], você poderá [gerenciar seu cluster Kubernetes usando o GitOps][]. Para revisar as práticas recomendadas para conectar um cluster Kubernetes híbrido ao Azure Arc, consulte o cenário [Gerenciamento e implantação híbridos do Azure Arc para clusters Kubernetes][].
  • A plataforma Azure Stack HCI também ajuda a simplificar a rede virtual para AKS em clusters HCI do Azure Stack, fornecendo a rede "subjacente" de uma maneira altamente disponível.

Eficiência de desempenho

  • Use o hardware certificado HCI do Azure Stack 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 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 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:

Próximos passos