Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Google Distributed Cloud oferece suporte a duas opções de balanceador de carga: em pacote e manual.
Modo de balanceador de carga em pacote
Se você escolher o balanceamento de carga em pacote, o balanceador de carga será fornecido para você. Não é necessário ter um balanceador de carga externo.
Há dois tipos de balanceamento de carga em pacote:
Camada 2: todos os nós e VIPs do balanceador de carga precisam estar na mesma sub-rede da
camada 2. O gateway da sub-rede do balanceador de carga precisa ouvir mensagens ARP gratuitas
e encaminhar pacotes ARP para os nós do balanceador de carga. Consulte
Balanceamento de carga em pacote com o MetalLB.
BGP: esse modo de balanceamento de carga é compatível com a divulgação de endereços IP virtuais (VIPs, na sigla em inglês)
do ServiceType LoadBalancer por meio do protocolo de gateway
de borda externo (eBGP) para os clusters. A rede do cluster é um sistema autônomo, que se conecta a outro sistema autônomo, uma rede externa, por meio de peering. Consulte
Balanceamento de carga em pacote com o BGP.
O diagrama a seguir mostra um exemplo de topologia de rede em que os balanceadores de carga MetalLB em pacote estão localizados nos nós do plano de controle.
Modo de balanceador de carga manual
Se você escolher o balanceamento de carga manual, o Google Distributed Cloud não vai implantar a carga de
balanceadores de carga. Isso proporciona mais flexibilidade do que o balanceamento de carga em pacote e não há requisitos de rede L2.
Antes de instalar o cluster, é necessário configurar os VIPs dos nós do plano de controle em um balanceador de carga externo. Após a instalação, é necessário escolher uma solução de balanceamento de carga para os serviços e entradas do Kubernetes.
O diagrama a seguir mostra um exemplo de topologia de rede de um cluster usando o modo de balanceamento de carga manual com um balanceador de carga externo.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-31 UTC."],[],[],null,["# Overview of load balancers\n\nGoogle Distributed Cloud supports two load balancer options: bundled and manual.\n\n### Bundled load balancer mode\n\nIf you choose bundled load balancing, the load balancer is provided for you. An\nexternal load balancer is not needed.\n\nThere are two types of bundled load balancing:\n\n- **Layer 2** : All load balancer nodes and VIPs must be in the same Layer 2\n subnet. The gateway of the load balancer subnet must listen to gratuitous ARP\n messages and forward ARP packets to the load balancer nodes. See\n [Bundled load balancing with MetalLB](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/bundled-lb).\n\n- **BGP** : This load-balancing mode supports the advertisement of ServiceType\n LoadBalancer virtual IP addresses (VIPs) through external Border\n Gateway Protocol (eBGP) for your clusters. Your cluster network is an autonomous\n system, which interconnects with another autonomous system, an external network,\n through peering. See\n [Bundled load balancing with BGP](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/lb-bundled-bgp).\n\nThe following diagram shows an example network topology where bundled MetalLB\nload balancers are located on the control plane nodes.\n\n### Manual load balancer mode\n\nIf you choose manual load balancing, Google Distributed Cloud does not deploy load\nbalancers. This allows more flexibility than bundled load balancing and there\nare no L2 network requirements.\n\nYou must configure your control plane nodes' VIPs on an external load\nbalancer before installing the cluster. After installation, you must pick a load\nbalancing solution for Kubernetes Services and Ingresses.\n\nThe following diagram shows an example network topology of a cluster using\nmanual load balancing mode with an external load balancer."]]