Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os balanceadores de carga externos (ELB, na sigla em inglês) expõem serviços fora do projeto de um pool de endereços IP atribuídos ao projeto do pool maior de IP externo da instância.
Os endereços IP virtuais (VIPs) do ELB não entram em conflito entre organizações e são exclusivos em todas elas. Por isso, use os serviços do ELB apenas para serviços que os clientes fora do projeto precisam acessar.
As cargas de trabalho em execução no projeto podem acessar os serviços do ELB desde que você
permita que elas saiam do projeto. Esse padrão de tráfego exige efetivamente o tráfego de saída do projeto antes de retornar ao serviço interno.
Antes de começar
Para configurar os serviços do ELB, você precisa do seguinte:
Ser proprietário do projeto em que você está configurando o balanceador de carga. Para mais informações, consulte Criar um projeto.
Administrador da NetworkPolicy do projeto: tem acesso para gerenciar políticas de rede do projeto
no namespace do projeto. Peça ao administrador do IAM da organização para conceder a você o papel de
Administrador da NetworkPolicy do projeto (project-networkpolicy-admin).
Administrador do balanceador de carga: peça ao administrador do IAM da organização para conceder a você o papel de administrador do balanceador de carga (load-balancer-admin).
Configurar o PNP para permitir o tráfego para o ELB
Para que os serviços do ELB funcionem, é necessário configurar e aplicar sua própria política de entrada ProjectNetworkPolicy personalizada para permitir o tráfego para esse serviço do ELB. Especifique o endereço CIDR externo para permitir o tráfego para este ELB:
MANAGEMENT_API_SERVER: o caminho kubeconfig do
servidor da API Management. Se você ainda não gerou um arquivo
kubeconfig para o servidor da API na zona de destino, consulte Fazer
login para mais detalhes.
PROJECT: o nome do seu projeto do GDC.
CIDR: o CIDR externo de onde o ELB precisa ser
acessado. Essa política é necessária porque o balanceador de carga externo usa o retorno direto do servidor (DSR, na sigla em inglês), que preserva o endereço IP externo de origem e ignora o balanceador de carga no caminho de retorno.
PORT: a porta de back-end nos pods atrás do
balanceador de carga. Esse valor é encontrado no campo .spec.ports[].targetPort
do manifesto para o recurso Service.
É possível segmentar cargas de trabalho de pods ou VMs usando a API KRM e a CLI gdcloud. Só é possível segmentar cargas de trabalho no cluster em que o objeto Service é criado ao usar o serviço do Kubernetes diretamente no cluster do Kubernetes.
[[["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-09-04 UTC."],[],[],null,["# Configure external load balancers\n\nExternal load balancers (ELB) expose services outside the project from a\npool's IP addresses assigned to the project from the larger\ninstance-external IP pool.\n\nELB Virtual IP (VIP) addresses don't conflict between organizations and are\nunique across all organizations. For this reason, you must use ELB services only\nfor services that clients outside the project necessarily have to access.\n\nWorkloads running inside the project can access ELB services as long as you\nenable the workloads to exit the project. This traffic pattern effectively\nrequires outbound traffic from the project before returning to the internal\nservice.\n\nBefore you begin\n----------------\n\nTo configure ELB services, you must have the following:\n\n- Own the project you are configuring the load balancer for. For more information, see [Create a project](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/create-a-project).\n- A customized `ProjectNetworkPolicy` (PNP) ingress policy to allow traffic to this ELB service. For more information, see [Configure PNP to allow traffic to ELB](#configure-pnp-elb).\n- The necessary identity and access roles:\n\n - Project NetworkPolicy Admin: has access to manage project network policies in the project namespace Ask your Organization IAM Admin to grant you the Project NetworkPolicy Admin (`project-networkpolicy-admin`) role.\n - Load Balancer Admin: Ask your Organization IAM Admin to grant you the Load Balancer Admin (`load-balancer-admin`) role.\n\nConfigure PNP to allow traffic to ELB\n-------------------------------------\n\nFor ELB services to function, you must configure and apply your own customized `ProjectNetworkPolicy` ingress policy to allow traffic to this ELB service. Specify the external CIDR address to allow traffic to this ELB: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e apply -f - \u003c\u003cEOF\n apiVersion: networking.gdc.goog/v1\n kind: ProjectNetworkPolicy\n metadata:\n namespace: \u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e\n name: allow-inbound-traffic-from-external\n spec:\n policyType: Ingress\n subject:\n subjectType: UserWorkload\n ingress:\n - from:\n - ipBlock:\n cidr: \u003cvar translate=\"no\"\u003eCIDR\u003c/var\u003e\n ports:\n - protocol: TCP\n port: \u003cvar translate=\"no\"\u003ePORT\u003c/var\u003e\n EOF\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e: the kubeconfig path of the Management API server's kubeconfig path. If you have not yet generated a kubeconfig file for the API server in your targeted zone, see [Sign\n in](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/iam/sign-in#cli) for details.\n- \u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e: the name of your GDC project.\n- \u003cvar translate=\"no\"\u003eCIDR\u003c/var\u003e: the external CIDR that the ELB needs to be accessed from. This policy is required as the external load balancer uses Direct Server Return (DSR), which preserves the source external IP address and bypasses the load balancer on the return path.\n- \u003cvar translate=\"no\"\u003ePORT\u003c/var\u003e: the backend port on the pods behind the load balancer. This value is found in the `.spec.ports[].targetPort`field of the manifest for the `Service` resource.\n\n| **Note:** This configuration provides all of the resources inside of projects access to the specified CIDR range.\n\nCreate an external load balancer\n--------------------------------\n\nCreate ELBs using three different methods in\nGDC:\n\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-overview) to create ELBs.\n- Use the [Networking Kubernetes Resource Model (KRM)\n API](/distributed-cloud/hosted/docs/latest/appliance/apis/service/networking/networking-api-overview) to create ELBs.\n\nYou can target pod or VM workloads using the KRM API and gdcloud CLI. You can only target workloads in the cluster where the `Service` object is created when you use the Kubernetes Service directly in Kubernetes cluster."]]