Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura balanceadores de cargas externos

Los balanceadores de cargas externos (ELB) exponen los servicios para que se pueda acceder a ellos desde fuera de la organización desde un grupo de direcciones IP asignadas a la organización desde el grupo de IP externas de instancias más grande.

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 deben acceder los clientes ajenos a la organización.

Las cargas de trabajo que se ejecutan dentro de la organización pueden acceder a los servicios de ELB siempre que habilites las cargas de trabajo para que salgan de la organización. Este patrón de tráfico requiere de forma eficaz el tráfico saliente de la organización antes de volver al servicio interno.

Existen instrucciones distintas para configurar los ELB para clústeres compartidos y estándar.

Crea un balanceador de cargas externo para clústeres compartidos

Puedes crear ELB globales o zonales. El alcance de los ELB globales abarca un universo de GDC. El alcance de los ELB zonales se limita a la zona especificada en el momento de la creación. Para obtener más información, consulta Balanceadores de cargas globales y zonales.

Antes de comenzar

Para configurar los servicios de ELB, debes hacer 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.
Tener una política de entrada de 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 a ELB.
Tener los roles de identidad y acceso necesarios:
- 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 la organización de IAM que te otorgue el rol de Administrador de NetworkPolicy del proyecto (project-networkpolicy-admin).
- Administrador del balanceador de cargas: Pídele al administrador de la organización de IAM que te otorgue el rol de Administrador del balanceador de cargas (load-balancer-admin).
- Administrador de balanceador de cargas global: Para los ELB globales, pídele al administrador de la organización de IAM que te otorgue el rol de administrador de balanceador de cargas global (global-load-balancer-admin). Para obtener más información, consulta Descripciones de los roles predefinidos.

Configura la 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 las cargas de trabajo de este servicio de ELB. Las políticas de red controlan el acceso a tus cargas de trabajo, no al balanceador de cargas en sí. Los ELB exponen las cargas de trabajo a la red de tu cliente, lo que requiere políticas de red explícitas para permitir el tráfico externo al puerto de la carga de trabajo, como 8080.

Especifica la dirección CIDR externa para permitir el tráfico a las cargas de trabajo de este ELB:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

Reemplaza lo siguiente:

MANAGEMENT_API_SERVER: 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 Accede para obtener más detalles.
PROJECT: Es el nombre de tu proyecto de GDC.
CIDR: el CIDR externo desde el que se debe acceder al ELB. Esta política es obligatoria, ya que el balanceador de cargas externo usa la devolución directa del servidor (DSR), que conserva la dirección IP externa de origen y omite el balanceador de cargas en la ruta de datos de retorno. Para obtener más información, consulta Crea una regla de firewall de entrada global para el tráfico externo a la organización.
PORT: 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. Este campo es opcional.

Crea ELB con tres métodos diferentes en GDC:

Usa la CLI de gdcloud para crear ELB globales o zonales.
Usa la API del modelo de recursos de Kubernetes (KRM) de redes para crear ELB globales o zonales.
Usa el Service de Kubernetes directamente en el clúster de Kubernetes. Este método solo está disponible para los ELB zonales.

Puedes orientar las cargas de trabajo de Pods o VM con la API de KRM y la CLI de gdcloud. Solo puedes orientar las cargas de trabajo en el clúster en el que se crea el objeto Service cuando usas el Service de Kubernetes directamente en el clúster de Kubernetes.

Crea un ELB zonal

Crea un ELB zonal con la CLI de gdcloud, la API de KRM o el Service de Kubernetes en el clúster de Kubernetes:

gdcloud

Crea un ELB que se dirija a las cargas de trabajo de Pods o VM con la CLI de gdcloud.

Este ELB se orienta a todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend.

Para crear un ELB con la CLI de gdcloud, sigue estos pasos:

Crea un recurso Backend para definir el extremo del ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME
```
Reemplaza lo siguiente:
- BACKEND_NAME: Es el nombre que elegiste para el recurso de backend, como my-backend.
- LABELS: Es un selector que define qué extremos entre Pods y VMs se usarán para este recurso de backend. Por ejemplo, app=web
- PROJECT_NAME: nombre del proyecto.
- ZONE: Es la zona que se usará para esta invocación. Para preestablecer la marca de zona para todos los comandos que la requieran, ejecuta gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos de varias zonas. Este campo es opcional.
- CLUSTER_NAME: Es el clúster al que se limita el alcance de los selectores definidos. Si no se especifica este campo, se seleccionan todos los extremos con la etiqueta determinada. Este campo es opcional.
Omite este paso si este ELB es para cargas de trabajo de Pods. Si configuras un ELB para cargas de trabajo de VM, define el tipo de verificación de estado para el ELB. Por ejemplo, para crear una verificación de estado de TCP, defínela de la siguiente manera:
```
gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE
```
Reemplaza lo siguiente:
- HEALTH_CHECK_NAME: Es el nombre que elegiste para el recurso de verificación de estado, como my-health-check.
- CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben pasar para que el extremo se considere en buen estado. El valor predeterminado es 5 cuando se omite o se establece en 0.
- TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2 cuando se omite o se establece en 0.
- PORT: Es el puerto en el que se realiza la verificación de estado. El valor predeterminado es 80. Este campo es opcional.
- ZONE: Es la zona en la que crearás este ELB.
Crea un recurso BackendService y agrégale el recurso Backend creado antes:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: el nombre elegido para este servicio de backend.
- TARGET_PORT: Es una lista separada por comas de puertos de destino que traduce este servicio de backend, en la que cada puerto de destino especifica el protocolo, el puerto en la regla de reenvío y el puerto en la instancia de backend. Puedes especificar varios puertos de destino. Este campo debe tener el formato protocol:port:targetport, como TCP:80:8080. Este campo es opcional.
- HEALTH_CHECK_NAME: Es el nombre del recurso de verificación de estado. Este campo es opcional. Incluye este campo solo si configuras un ELB para cargas de trabajo de VM.

Agrega el recurso BackendService al recurso Backend creado antes:

gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

Opcional: Usa la afinidad de sesión para los ELB para asegurarte de que las solicitudes del mismo cliente se enruten de forma coherente al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de cargas, crea una política de servicio de backend con el comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Reemplaza lo siguiente:
- POLICY_NAME: el nombre que elegiste para la política de servicio de backend.
- MODE: Es el modo de afinidad de sesión. Se admiten dos modos:
  - NONE: La afinidad de sesión está inhabilitada. Las solicitudes se enrutan a cualquier backend disponible. Este es el modo predeterminado.
  - CLIENT_IP_DST_PORT_PROTO: Las solicitudes de la misma tupla de cuatro elementos (dirección IP de origen, dirección IP de destino, puerto de destino y protocolo) se enrutan al mismo backend.
- RESOURCE_LABEL: Es el selector de etiquetas que elige a qué servicio de backend se aplica el recurso BackendServicePolicy en el espacio de nombres del proyecto. Si varios recursos BackendServicePolicy coinciden con el mismo servicio de backend y al menos una de estas políticas tiene habilitada la afinidad de sesión, se habilitará la afinidad de sesión para este recurso BackendService.
Crea un recurso ForwardingRule externo que defina la VIP en la que está disponible el servicio:
```
gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: El nombre de tu servicio de backend.
- FORWARDING_RULE_EXTERNAL_NAME: el nombre que elegiste para la regla de reenvío.
- CIDR: Este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del grupo de IP zonal. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred zonal. Para obtener más información sobre los recursos de Subnet, consulta Ejemplos de recursos personalizados.
- PROTOCOL_PORT: el protocolo y el puerto que se expondrán en la regla de reenvío. Este campo debe tener el formato ip-protocol=TCP:80. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.
Para verificar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Para obtener la dirección IP asignada del balanceador de cargas, describe la regla de reenvío:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Para validar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:
1. Para obtener la VIP asignada, describe la regla de reenvío:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
2. Verifica el tráfico con una solicitud curl a la VIP en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Reemplaza lo siguiente:
  - FORWARDING_RULE_VIP: la VIP de la regla de reenvío.
  - PORT: Es el número de puerto del campo PROTOCOL_PORT en la regla de reenvío.

API

Crea un ELB que se dirija a las cargas de trabajo de Pods o VM con la API de KRM. Este ELB se orienta a todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend.

Para crear un ELB zonal con la API de KRM, sigue estos pasos:

Crea un recurso Backend para definir los extremos del ELB. Crea recursos Backend para cada zona en la que se colocan las cargas de trabajo:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF
```
Reemplaza lo siguiente:
- MANAGEMENT_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API de Management zonal. Para obtener más información, consulta Cambia a un contexto zonal.
- PROJECT_NAME: nombre del proyecto.
- BACKEND_NAME: El nombre del recurso Backend.
- CLUSTER_NAME: Este es un campo opcional. Este campo especifica el clúster al que se limita el alcance de los selectores definidos. Este campo no se aplica a las cargas de trabajo de VM. Si un recurso Backend no incluye el campo clusterName, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto.
Omite este paso si este ELB es para cargas de trabajo de Pods. Si configuras un ELB para cargas de trabajo de VM, define una verificación de estado para el ELB:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF
```
Reemplaza lo siguiente:
- HEALTH_CHECK_NAME: Es el nombre que elegiste para el recurso de verificación de estado, como my-health-check.
- PORT: Es el puerto en el que se realiza la verificación de estado. El valor predeterminado es 80.
- TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben pasar para que el extremo se considere en buen estado. El valor predeterminado es 2 cuando se omite o se establece en 0.
- UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2 cuando se omite o se establece en 0.
Crea un objeto BackendService con el recurso Backend creado anteriormente. Si configuras un ELB para cargas de trabajo de VM, incluye el recurso HealthCheck.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: Es el nombre elegido para tu recurso BackendService.
- HEALTH_CHECK_NAME: Es el nombre del recurso HealthCheck que creaste anteriormente. No incluyas este campo si configuras un ELB para cargas de trabajo de Pods.
Opcional: Usa la afinidad de sesión para los ELB para asegurarte de que las solicitudes del mismo cliente se enruten de forma coherente al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de cargas, crea un recurso BackendServicePolicy. Este recurso define la configuración de afinidad de sesión y aplica el recurso BackendServicePolicy al recurso BackendService. Crea y aplica el recurso BackendServicePolicy:
```
 kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL
```
Reemplaza lo siguiente:
- POLICY_NAME: el nombre que elegiste para la política de servicio de backend.
- MODE: Es el modo de afinidad de sesión. Se admiten dos modos:
  - NONE: La afinidad de sesión está inhabilitada. Las solicitudes se enrutan a cualquier backend disponible. Este es el modo predeterminado.
  - CLIENT_IP_DST_PORT_PROTO: Las solicitudes de la misma tupla de cuatro elementos (dirección IP de origen, dirección IP de destino, puerto de destino y protocolo) se enrutan al mismo backend.
- RESOURCE_LABEL: Es el selector de etiquetas que elige a qué servicio de backend se aplica el recurso BackendServicePolicy en el espacio de nombres del proyecto. Si varios recursos BackendServicePolicy coinciden con el mismo servicio de backend y al menos una de estas políticas tiene habilitada la afinidad de sesión, se habilitará la afinidad de sesión para este recurso BackendService.
Crea un recurso ForwardingRule externo que defina la VIP en la que está disponible el servicio.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: Es el nombre de tu recurso BackendService.
- FORWARDING_RULE_EXTERNAL_NAME: Es el nombre que elegiste para tu recurso ForwardingRuleExternal.
- CIDR_NAME: El campo cidrRef es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del grupo de IP zonal. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred zonal. Para obtener más información sobre los recursos de Subnet, consulta Ejemplo de recursos personalizados.
- PORT: Usa el campo ports para especificar un array de puertos de L4 para los que se reenvían paquetes a los backends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Usa el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que la aplicación real expone dentro del contenedor.
- PROTOCOL: Es el protocolo que se usará para la regla de reenvío, como TCP. Una entrada en el array ports debe verse de la siguiente manera:
```
ports:
- port: 80
  protocol: TCP
```
Para validar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:
1. Para obtener la VIP, usa kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  El resultado luce de la siguiente manera:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Verifica el tráfico con una solicitud curl a la VIP en el puerto especificado en el campo PORT de la regla de reenvío:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Reemplaza FORWARDING_RULE_VIP por la VIP de la regla de reenvío.

Servicio de Kubernetes

Puedes crear ELB en GDC creando un Service de Kubernetes de tipo LoadBalancer en un clúster de Kubernetes.

Para crear un servicio de ELB, haz lo siguiente:

Crea un archivo YAML para la definición de Service del tipo LoadBalancer.

Nota: A diferencia del proceso para los balanceadores de cargas internos, no agregues anotaciones en el archivo. Si no especificas la anotación internal, el servicio es externo de forma predeterminada.

El siguiente objeto Service es un ejemplo de un servicio de ELB:
```
apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer
```
Reemplaza lo siguiente:
- ELB_SERVICE_NAME: Es el nombre del servicio de ELB.
- PROJECT_NAME: Es el espacio de nombres de tu proyecto que contiene las cargas de trabajo de backend.
El campo port configura el puerto de frontend que expones en la dirección VIP. El campo targetPort configura el puerto de backend al que deseas reenviar el tráfico en las cargas de trabajo de backend. El balanceador de cargas admite la traducción de direcciones de red (NAT). Los puertos de frontend y backend pueden ser diferentes.
En el campo selector de la definición de Service, especifica Pods o máquinas virtuales como las cargas de trabajo de backend.

El selector define qué cargas de trabajo se deben tomar como cargas de trabajo de backend para este Service, según la coincidencia de las etiquetas que especifiques con las etiquetas de las cargas de trabajo. El Service solo puede seleccionar cargas de trabajo de backend en el mismo proyecto y en el mismo clúster en el que defines el Service.

Para obtener más información sobre la selección de Service, consulta https://kubernetes.io/docs/concepts/services-networking/service/.
Guarda el archivo de definición de Service en el mismo proyecto que las cargas de trabajo de backend.
Aplica el archivo de definición Service al clúster:
```
kubectl apply -f ELB_FILE
```
Reemplaza ELB_FILE por el nombre del archivo de definición de Service para el servicio de ELB.

Cuando creas un ELB, el servicio obtiene dos direcciones IP. Una es una dirección IP interna a la que solo se puede acceder desde el mismo clúster. La otra es la dirección IP externa, a la que se puede acceder desde dentro y fuera de la organización. Puedes obtener las direcciones IP del servicio de ELB si consultas el estado del servicio:
```
kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME
```
Reemplaza lo siguiente:
- PROJECT_NAME: Es el espacio de nombres de tu proyecto que contiene las cargas de trabajo de backend.
- ELB_SERVICE_NAME: Es el nombre del servicio de ELB.
Deberías obtener un resultado similar al siguiente:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h
```
EXTERNAL-IP es la dirección IP del servicio a la que se puede acceder desde fuera de la organización.

Si no obtienes un resultado, asegúrate de haber creado el servicio de ELB correctamente.

Crea un ELB global

Crea un ELB global con la CLI de gdcloud o la API de KRM.

gdcloud

Crea un ELB que se dirija a las cargas de trabajo de Pods o VM con la CLI de gdcloud.

Este ELB se orienta a todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend. El recurso personalizado Backend debe tener un alcance limitado a una zona.

Para crear un ELB con la CLI de gdcloud, sigue estos pasos:

Crea un recurso Backend para definir el extremo del ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE
```
Reemplaza lo siguiente:
- BACKEND_NAME: Es el nombre que elegiste para el recurso de backend, como my-backend.
- LABELS: Es un selector que define qué extremos entre Pods y VMs se usarán para este recurso de backend. Por ejemplo, app=web
- PROJECT_NAME: nombre del proyecto.
- CLUSTER_NAME: Es el clúster al que se limita el alcance de los selectores definidos. Si no se especifica este campo, se seleccionan todos los extremos con la etiqueta determinada. Este campo es opcional.
- ZONE: Es la zona que se usará para esta invocación. Para preestablecer la marca de zona para todos los comandos que la requieran, ejecuta gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos de varias zonas. Este campo es opcional.
Omite este paso si este ELB es para cargas de trabajo de Pods. Si configuras un ELB para cargas de trabajo de VM, define una verificación de estado para el ELB:
```
gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global
```
Reemplaza lo siguiente:
- HEALTH_CHECK_NAME: Es el nombre que elegiste para el recurso de verificación de estado, como my-health-check.
- CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- HEALTHY_THRESHOLD: Es el tiempo que se debe esperar antes de declarar un error. El valor predeterminado es 5 cuando se omite o se establece en 0.
- TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2 cuando se omite o se establece en 0.
- PORT: Es el puerto en el que se realiza la verificación de estado. El valor predeterminado es 80. Este campo es opcional.
Crea un recurso BackendService y agrégale el recurso Backend creado antes:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: el nombre elegido para este servicio de backend.
- TARGET_PORTS: Es una lista separada por comas de puertos de destino que traduce este servicio de backend, en la que cada puerto de destino especifica el protocolo, el puerto en la regla de reenvío y el puerto en la instancia de backend. Puedes especificar varios puertos de destino. Este campo debe tener el formato protocol:port:targetport, como TCP:80:8080. Este campo es opcional.
- HEALTH_CHECK_NAME: Es el nombre del recurso de verificación de estado. Este campo es opcional. Incluye este campo solo si configuras un ELB para cargas de trabajo de VM.

Agrega el recurso BackendService al recurso Backend creado antes:

gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

Opcional: Usa la afinidad de sesión para los ELB para asegurarte de que las solicitudes del mismo cliente se enruten de forma coherente al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de cargas, crea una política de servicio de backend con el comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Reemplaza lo siguiente:
- POLICY_NAME: el nombre que elegiste para la política de servicio de backend.
- MODE: Es el modo de afinidad de sesión. Se admiten dos modos:
  - NONE: La afinidad de sesión está inhabilitada. Las solicitudes se enrutan a cualquier backend disponible. Este es el modo predeterminado.
  - CLIENT_IP_DST_PORT_PROTO: Las solicitudes de la misma tupla de cuatro elementos (dirección IP de origen, dirección IP de destino, puerto de destino y protocolo) se enrutan al mismo backend.
- RESOURCE_LABEL: Es el selector de etiquetas que elige a qué servicio de backend se aplica el recurso BackendServicePolicy en el espacio de nombres del proyecto. Si varios recursos BackendServicePolicy coinciden con el mismo servicio de backend y al menos una de estas políticas tiene habilitada la afinidad de sesión, se habilitará la afinidad de sesión para este recurso BackendService.
Crea un recurso ForwardingRule externo que defina la VIP en la que está disponible el servicio:
```
gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT_NAME \
  --global
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: El nombre de tu servicio de backend.
- FORWARDING_RULE_EXTERNAL_NAME: el nombre que elegiste para la regla de reenvío.
- CIDR: Este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del grupo de IP global. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred global. Para obtener más información sobre los recursos de Subnet, consulta Ejemplo de recursos personalizados.
- PROTOCOL_PORT: el protocolo y el puerto que se expondrán en la regla de reenvío. Este campo debe tener el formato ip-protocol=TCP:80. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.
Para verificar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Para obtener la dirección IP asignada del balanceador de cargas, describe la regla de reenvío:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Para validar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:
1. Para obtener la VIP asignada, describe la regla de reenvío:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global
```
2. Verifica el tráfico con una solicitud curl a la VIP en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Reemplaza lo siguiente:
  - FORWARDING_RULE_VIP: la VIP de la regla de reenvío.
  - PORT: Es el número de puerto del campo PROTOCOL_PORT en la regla de reenvío.

API

Crea un recurso Backend para definir los extremos del ELB. Crea recursos Backend para cada zona en la que se colocan las cargas de trabajo:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF
```
Reemplaza lo siguiente:
- MANAGEMENT_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API de Management global. Para obtener más información, consulta Cambia al contexto global.
- PROJECT_NAME: nombre del proyecto.
- BACKEND_NAME: El nombre del recurso Backend.
- CLUSTER_NAME: Este es un campo opcional. Este campo especifica el clúster al que se limita el alcance de los selectores definidos. Este campo no se aplica a las cargas de trabajo de VM. Si un recurso Backend no incluye el campo clusterName, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto.
Omite este paso si este ELB es para cargas de trabajo de Pods. Si configuras un ELB para cargas de trabajo de VM, define una verificación de estado para el ELB:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF
```
Reemplaza lo siguiente:
- HEALTH_CHECK_NAME: Es el nombre que elegiste para el recurso de verificación de estado, como my-health-check.
- PORT: Es el puerto en el que se realiza la verificación de estado. El valor predeterminado es 80.
- TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5 cuando se omite o se establece en 0. No se recomienda establecer un tiempo de espera superior a checkInterval.
- HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben pasar para que el extremo se considere en buen estado. El valor predeterminado es 2 cuando se omite o se establece en 0.
- UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2 cuando se omite o se establece en 0.
Como se trata de un ELB global, crea la verificación de estado en la API global.
Crea un objeto BackendService con el recurso Backend creado anteriormente. Si configuras un ELB para cargas de trabajo de VM, incluye el recurso HealthCheck.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: Es el nombre elegido para tu recurso BackendService.
- HEALTH_CHECK_NAME: Es el nombre del recurso HealthCheck que creaste antes. No incluyas este campo si configuras un ELB para cargas de trabajo de Pods.
- ZONE: Es la zona en la que se crea el recurso Backend. Puedes especificar varios backends en el campo backendRefs. Por ejemplo:
```
- name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B
```
- El campo targetPorts es opcional. Este recurso enumera los puertos que traduce este recurso BackendService. Si usas este objeto, proporciona valores para lo siguiente:
  - PORT: Es el puerto que expone el servicio.
  - PROTOCOL: Es el protocolo de capa 4 con el que debe coincidir el tráfico. Solo se admiten TCP y UDP.
  - TARGET_PORT: Es el puerto al que se traduce el valor PORT, como 8080. El valor de TARGET_PORT no se puede repetir en un objeto determinado. Un ejemplo para targetPorts podría verse de la siguiente manera:
```
targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080
```
Opcional: Usa la afinidad de sesión para los ELB para asegurarte de que las solicitudes del mismo cliente se enruten de forma coherente al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de cargas, crea un recurso BackendServicePolicy. Este recurso define la configuración de afinidad de sesión y aplica el recurso BackendServicePolicy al recurso BackendService. Crea y aplica el recurso BackendServicePolicy:
```
 kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL
```
Reemplaza lo siguiente:
- POLICY_NAME: el nombre que elegiste para la política de servicio de backend.
- MODE: Es el modo de afinidad de sesión. Se admiten dos modos:
  - NONE: La afinidad de sesión está inhabilitada. Las solicitudes se enrutan a cualquier backend disponible. Este es el modo predeterminado.
  - CLIENT_IP_DST_PORT_PROTO: Las solicitudes de la misma tupla de cuatro elementos (dirección IP de origen, dirección IP de destino, puerto de destino y protocolo) se enrutan al mismo backend.
- RESOURCE_LABEL: Es el selector de etiquetas que elige a qué servicio de backend se aplica el recurso BackendServicePolicy en el espacio de nombres del proyecto. Si varios recursos BackendServicePolicy coinciden con el mismo servicio de backend y al menos una de estas políticas tiene habilitada la afinidad de sesión, se habilitará la afinidad de sesión para este recurso BackendService.
Crea un recurso ForwardingRule externo que defina la VIP en la que está disponible el servicio.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Reemplaza lo siguiente:
- FORWARDING_RULE_EXTERNAL_NAME: Es el nombre elegido para tu recurso ForwardingRuleExternal.
- CIDR_NAME: El campo cidrRef es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del grupo de IP global. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred global. Para obtener más información sobre los recursos de Subnet, consulta Ejemplo de recursos personalizados.
- PORT: Usa el campo ports para especificar un array de puertos de L4 para los que se reenvían paquetes a los backends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Usa el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que la aplicación real expone dentro del contenedor.
- PROTOCOL: Es el protocolo que se usará para la regla de reenvío, como TCP. Una entrada en el array ports debe verse de la siguiente manera:
```
ports:
- port: 80
  protocol: TCP
```
Para validar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:
1. Para obtener la VIP, usa kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  El resultado luce de la siguiente manera:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Verifica el tráfico con una solicitud curl a la VIP en el puerto especificado en el campo PORT de la regla de reenvío:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Reemplaza FORWARDING_RULE_VIP por la VIP de la regla de reenvío.

Crea un balanceador de cargas externo para clústeres de Standard

Un propietario de la aplicación (AO) puede crear un Service de Kubernetes de tipo LoadBalancer para exponer servicios de forma externa. Este servicio solo puede seleccionar los backends dentro del clúster estándar en el que se crea el servicio. Esto equivale a un ELB con alcance de clúster zonal. El ELB global no es compatible con los clústeres estándar. Para obtener más información, consulta Balanceadores de cargas globales y zonales.

Antes de comenzar

Para configurar los servicios de ELB, debes hacer 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.
Tener una política de entrada de 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 a ELB en clústeres estándar.
Tener los roles de identidad y acceso necesarios:
- 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 la organización de IAM que te otorgue el rol de administrador de NetworkPolicy del proyecto (project-networkpolicy-admin).
- Administrador del balanceador de cargas: Pídele al administrador de la organización de IAM que te otorgue el rol de Administrador del balanceador de cargas (load-balancer-admin).

Configura la PNP para permitir el tráfico al ELB en clústeres de Standard

En el siguiente archivo YAML de ejemplo de política de red del proyecto, se permite que el tráfico de una carga de trabajo de otro proyecto acceda a una carga de trabajo del proyecto actual a través del ELB.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

Crea un ELB zonal para clústeres estándar

Puedes crear ELB en GDC creando un Service de Kubernetes de tipo LoadBalancer en el clúster de Kubernetes estándar.

Para crear un servicio de ELB, haz lo siguiente:

Crea un archivo YAML para la definición de Service del tipo LoadBalancer.

Nota: A diferencia del proceso para los balanceadores de cargas internos, no agregues anotaciones en el archivo. Si no especificas la anotación internal, el servicio es externo de forma predeterminada.

El siguiente objeto Service es un ejemplo de un servicio de ELB:
```
apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer
```
Reemplaza lo siguiente:
- ELB_SERVICE_NAME: Es el nombre del servicio de ELB.
- ELB_SERVICE_NAMESPACE: Es el espacio de nombres en tu clúster estándar que contiene las cargas de trabajo de backend.
- PORT: Es el puerto que expone el Service de Kubernetes. Otros servicios o clientes externos dentro del clúster se conectarán a este puerto en la dirección IP del Service.
- TARGET_PORT: Es el puerto dentro del contenedor de tu Pod en el que tu aplicación se ejecuta de forma activa y escucha las conexiones entrantes. Este puede ser un puerto numérico o un puerto con nombre definido en la especificación del contenedor del Pod.
El campo port configura el puerto de frontend que expones en la dirección VIP. El campo targetPort configura el puerto de backend al que deseas reenviar el tráfico en las cargas de trabajo de backend. El balanceador de cargas admite la traducción de direcciones de red (NAT). Los puertos de frontend y backend pueden ser diferentes.
En el campo selector de la definición de Service, especifica pares clave-valor para que coincidan con las cargas de trabajo de backend. En los clústeres estándar, solo se admiten los Pods como cargas de trabajo.

que definas, según la coincidencia de las etiquetas que especifiques con las etiquetas de las cargas de trabajo. El Service solo puede seleccionar cargas de trabajo de backend en el mismo proyecto y el mismo clúster en el que defines el Service.

Para obtener más información sobre la selección de Service, consulta https://kubernetes.io/docs/concepts/services-networking/service/.
Guarda la especificación Service en un archivo YAML. Sustituye el nombre de archivo por ELB_FILE en el siguiente comando.
Aplica el archivo de definición Service al clúster:
```
export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE
```
Reemplaza lo siguiente:
- ELB_FILE:Es el nombre del archivo de definición de Service para el servicio de ELB.
- KUBECONFIG_PATH: Es la ruta de acceso al archivo kubeconfig del clúster estándar.
Para obtener las direcciones IP del servicio de ELB, consulta el estado del servicio:
```
kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME
```
Reemplaza lo siguiente:
- ELB_SERVICE_NAMESPACE: Es el espacio de nombres que contiene las cargas de trabajo de backend.
- ELB_SERVICE_NAME: Es el nombre del servicio de ELB.
Deberías obtener un resultado similar al siguiente:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h
```
EXTERNAL-IP es la dirección IP del servicio a la que se puede acceder desde fuera de la organización.

Selecciona una VM como backend para un balanceador de cargas

Para vincular una VM al balanceador de cargas, sigue estos pasos:

Asegúrate de que la VM tenga una etiqueta que coincida con el selector de etiquetas que se usa en la configuración del balanceador de cargas.

Por ejemplo, si tu VM no tiene una etiqueta adecuada, puedes agregar la etiqueta especificada del objeto de backend de la zona correspondiente a la VM:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL
```
Reemplaza lo siguiente:
- LABEL: Es una etiqueta que coincide con el LabelSelector en la configuración del balanceador de cargas, como app=server.
- VM_NAME: Es el nombre de la máquina virtual que se vinculará.
- PROJECT_NAME: nombre del proyecto.
Asegúrate de que el servidor escuche en el mismo puerto que se especifica en el objeto HealthCheck.

Configura balanceadores de cargas externos Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Crea un balanceador de cargas externo para clústeres compartidos

Antes de comenzar

Configura la PNP para permitir el tráfico al ELB

Crea un ELB zonal

gdcloud

API

Servicio de Kubernetes

Crea un ELB global

gdcloud

API

Crea un balanceador de cargas externo para clústeres de Standard

Antes de comenzar

Configura la PNP para permitir el tráfico al ELB en clústeres de Standard

Crea un ELB zonal para clústeres estándar

Selecciona una VM como backend para un balanceador de cargas

Configura balanceadores de cargas externos