Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los balanceadores de cargas externos (ELB) exponen servicios fuera del proyecto desde las direcciones IP de un grupo asignado al proyecto desde el grupo más grande de IPs externas de instancias.
Las direcciones IP virtuales (VIP) de ELB no entran en conflicto entre las organizaciones y son únicas en todas las organizaciones. Por este motivo, debes usar los servicios de ELB solo para los servicios a los que los clientes externos al proyecto necesariamente deben acceder.
Las cargas de trabajo que se ejecutan dentro del proyecto pueden acceder a los servicios de ELB siempre que habilites las cargas de trabajo para que salgan del proyecto. Este patrón de tráfico requiere de manera efectiva tráfico saliente del proyecto antes de regresar al servicio interno.
Antes de comenzar
Para configurar los servicios de ELB, debes tener lo siguiente:
Ser propietario del proyecto para el que configuras el balanceador de cargas Para obtener más información, consulta Cómo crear un proyecto.
Una política de entrada ProjectNetworkPolicy (PNP) personalizada para permitir el tráfico a este servicio de ELB. Para obtener más información, consulta Configura PNP para permitir el tráfico al ELB.
Los roles de identidad y acceso necesarios son los siguientes:
Administrador de NetworkPolicy del proyecto: Tiene acceso para administrar las políticas de red del proyecto en el espacio de nombres del proyecto. Pídele al administrador de IAM de la organización que te otorgue el rol de administrador de NetworkPolicy del proyecto (project-networkpolicy-admin).
Administrador de balanceador de cargas: Pídele al administrador de IAM de tu organización que te otorgue el rol de administrador de balanceador de cargas (load-balancer-admin).
Configura PNP para permitir el tráfico al ELB
Para que los servicios de ELB funcionen, debes configurar y aplicar tu propia política de entrada ProjectNetworkPolicy personalizada para permitir el tráfico a este servicio de ELB. Especifica la dirección CIDR externa para permitir el tráfico a este ELB:
MANAGEMENT_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API de administración. Si aún no generaste un archivo kubeconfig para el servidor de la API en la zona de destino, consulta Acceder para obtener más detalles.
PROJECT: Es el nombre de tu proyecto de GDC.
CIDR: Es el CIDR externo desde el que se debe acceder al ELB. Esta política es obligatoria, ya que el balanceador de cargas externo usa el retorno directo del servidor (DSR), que conserva la dirección IP externa de origen y omite el balanceador de cargas en la ruta de retorno.
PORT: Es el puerto de backend en los Pods detrás del balanceador de cargas. Este valor se encuentra en el campo .spec.ports[].targetPort del manifiesto del recurso Service.
Puedes segmentar las cargas de trabajo de pods o VM con la API de KRM y la CLI de gdcloud. Solo puedes segmentar cargas de trabajo en el clúster en el que se crea el objeto Service cuando usas el servicio de Kubernetes directamente en el clúster de Kubernetes.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
