[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-03-25。"],[],[],null,["This document explains the load balancing options supported by\nGoogle Distributed Cloud for new clusters.\n\nThere are two load balancing options available to you. Choose the option\nthat seems most suited to your environment and your needs. For example, you\nmight choose an option that requires minimal configuration. Or you might choose\nan option that aligns with the load balancers you already have in your network.\n\nThese are the available options:\n\n- MetalLB bundled\n\n- Manual load balancing for any third-party load balancer, such as F5 BIG-IP\n Citrix\n\nWhen you create user clusters using the Google Cloud console, the\ngcloud CLI, or Terraform, the kind of load balancer for the admin\ncluster and its user clusters must be the same. The only exception is if the\nadmin cluster uses Seesaw, then the user clusters can use MetalLB. If you want\nyour admin and user clusters to use different kinds of load balancers, you must\ncreate user clusters using the `gkectl` command-line tool.\n\nMetalLB\n\nThe MetalLB load balancer is bundled with Google Distributed Cloud and is\nespecially easy to configure. The MetalLB components run on your cluster nodes,\nso you don't have to create separate VMs for your load balancer.\n\nYou can configure MetalLB to perform IP address management. This means that when\na developer creates a Service of type `LoadBalancer`, they don't have to specify\na VIP for the Service. Instead, MetalLB automatically chooses a VIP from an\naddress pool that you provide ahead of time.\n\nFor more information, see\n[Bundled load balancing with MetalLB](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/bundled-load-balance-metallb).\n\nCitrix\n\nWe document how to set up the Citrix load balancer as an example of setting up\na load balancer manually. With any load balancer that you set up manually, you\nmust configure mappings between VIPs, node addresses, and `nodePort` values.\nFor information, on how to do this for the Citrix load balancer, see\n[Manual load balancing with Citrix](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/citrix-load-balance).\n\nManual load balancing in general\n\nYou can use any load balancer of your choice as long as you set it up manually.\nWith any load balancer that you set up manually, you must configure mappings\nbetween VIPs, node addresses, and `nodePort` values. For general information on\nhow to do this, see\n[Manual load balancing](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/manual-load-balance).\n\nSetting aside virtual IP addresses\n\nRegardless of which load balancer you use, you must set aside several virtual\nIP addresses (VIPs) that you intend to use for load balancing.\n\nFor your admin cluster, you must set aside these VIPs:\n\n- VIP for Kubernetes API server\n- VIP for add-ons\n\nFor each user cluster you intend to create, you must set aside these VIPs:\n\n- VIP for the Kubernetes API server\n- VIP for the ingress service\n\nFor example, suppose you intend to have two user clusters. Then you would need\ntwo VIPs for your admin cluster and two VIPs for each of your user clusters. So\nyou would need to set aside six VIPs.\n\nNode IP addresses\n\nIf you choose MetalLB as your load balancer, then you can either use static IP\naddresses for your cluster nodes, or you can have your cluster nodes get their\nIP addresses from a DHCP server\n\nIf you choose a manual load-balancing option, then you must use static\nIP addresses for your cluster nodes.\n\nIf you choose to use static IP addresses, you must set aside enough addresses\nfor the nodes in the admin cluster and the nodes in all the user clusters you\nintend to create. For details about how many node IP addresses to set aside, see\n[Plan your IP addresses](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/plan-ip-addresses).\n\nCreating Services in your cluster\n\nAfter your user cluster is running, application developers might want to create\n[Kubernetes Services](/kubernetes-engine/docs/concepts/service)\nand expose them to external clients.\n\nFor Services of type `LoadBalancer`, VIPs must be configured on the load\nbalancer. How those VIPs get configured depends on your choice of load balancer.\n\nMetalLB\n\nIn the user cluster configuration file, you specify address pools that the\nMetalLB controller uses to assign VIPs to Services. When a developer creates\na Service of type `LoadBalancer`, the MetalLB controller chooses an address from\na pool and assigns the address to the Service. The developer does not have to\nspecify a value for `loadBalancerIP` in the Service manifest.\n\nManually configured load balancer\n\nIf you have chosen a manual load balancing option, developers can follow these\nsteps to expose a Service to external clients:\n\n- Create a Service of type NodePort.\n\n- Choose a VIP for the Service.\n\n- Manually configure the load balancer so that traffic sent to the VIP\n is forwarded to the Service."]]
