Configurar balanceadores de carga externos

Los balanceadores de carga externos (ELB) exponen los servicios para que se pueda acceder a ellos desde fuera de la organización a partir de las direcciones IP del pool asignadas a la organización desde el pool de IPs externas de instancias más grande.

Las direcciones IP virtuales (VIP) de ELB no entran en conflicto entre organizaciones y son únicas en todas las organizaciones. Por este motivo, solo debes usar los servicios de ELB para los servicios a los que los clientes externos a la organización tengan que acceder.

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 tráfico saliente de la organización antes de volver al servicio interno.

Antes de empezar

Para configurar los servicios de ELB, debe tener lo siguiente:

  • Ser propietario del proyecto en el que vas a configurar el balanceador de carga. Para obtener más información, consulta Crear un proyecto.
  • 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 Configurar PNP para permitir el tráfico a ELB.

  • Los roles de identidad y acceso necesarios:

    • Administrador de NetworkPolicy de proyectos: tiene acceso para gestionar las políticas de red de proyectos en el espacio de nombres del proyecto. Pide al administrador de gestión de identidades y accesos de tu organización que te asigne el rol Administrador de NetworkPolicy de proyectos (project-networkpolicy-admin).
    • Administrador de balanceadores de carga: pide al administrador de IAM de tu organización que te asigne el rol Administrador de balanceadores de carga (load-balancer-admin).
    • Administrador de balanceadores de carga globales: en el caso de los ELBs globales, pide al administrador de IAM de tu organización que te conceda el rol Administrador de balanceadores de carga globales (global-load-balancer-admin). Para obtener más información, consulta Descripciones de los roles predefinidos.

Configurar PNP para permitir el tráfico a ELB

Para que los servicios de ELB funcionen, debes configurar y aplicar tu propia política de entrada personalizada para permitir el tráfico a las cargas de trabajo de este servicio de ELB.ProjectNetworkPolicy Las políticas de red controlan el acceso a tus cargas de trabajo, no al balanceador de carga en sí. Los ELBs exponen las cargas de trabajo a la red de tus clientes, 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

Haz los cambios siguientes:

  • MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API de gestión. Si aún no has generado un archivo kubeconfig para el servidor de la API en tu zona de destino, consulta Iniciar sesión para obtener más información.
  • PROJECT: el nombre de tu proyecto de GDC.
  • CIDR: el CIDR externo desde el que se debe acceder al ELB. Esta política es obligatoria porque el balanceador de carga externo usa la opción de retorno directo del servidor (DSR), que conserva la dirección IP externa de origen y evita el balanceador de carga en la ruta de retorno. Para obtener más información, consulta el artículo Crear una regla de firewall de entrada global para el tráfico externo a la organización.
  • PORT: el puerto de backend de los pods que hay detrás del balanceador de carga. Este valor se encuentra en el campo .spec.ports[].targetPort del manifiesto del recurso Service. Este campo es opcional.

Crear un balanceador de carga externo

Puedes crear ELBs globales o zonales. El ámbito de los ELBs globales abarca todo un universo de GDCs. El ámbito de los ELBs zonales se limita a la zona especificada en el momento de la creación. Para obtener más información, consulta Balanceadores de carga globales y zonales.

Crea ELBs con tres métodos diferentes en GDC:

Puedes orientar las cargas de trabajo de pods o de máquinas virtuales mediante la API de KRM y la CLI de gdcloud. Solo puedes orientar las cargas de trabajo del clúster en el que se crea el objeto Service cuando usas el servicio de Kubernetes directamente en el clúster de Kubernetes.

Crear un ELB zonal

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

gdcloud

Crea un ELB que tenga como destino cargas de trabajo de pods o de VMs mediante la CLI de gcloud.

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

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

  1. Crea un recurso Backend para definir el endpoint del ELB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME

    Haz los cambios siguientes:

    • BACKEND_NAME: el nombre que elijas para el recurso de backend, como my-backend.
    • LABELS: un selector que define qué endpoints entre pods y VMs se deben usar para este recurso de backend. Por ejemplo, app=web.
    • PROJECT_NAME: el nombre de tu proyecto.
    • ZONE: la zona que se va a usar en esta invocación. Para predefinir la marca de zona en todos los comandos que la requieran, ejecute gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos multizona. Este campo es opcional.
    • CLUSTER_NAME: el clúster al que se limita el ámbito de los selectores definidos. Si no se especifica este campo, se seleccionarán todos los endpoints con la etiqueta indicada. Este campo es opcional.

  2. Omite este paso si este ELB es para cargas de trabajo de pods. Si vas a configurar un ELB para cargas de trabajo de VMs, define una comprobación del 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 \
  --zone=ZONE

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre que elijas para el recurso de comprobación de estado, como my-health-check.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5. Este campo es opcional.
    • HEALTHY_THRESHOLD: el tiempo que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
    • PORT: el puerto en el que se realiza la comprobación del estado. El valor predeterminado es 80. Este campo es opcional.
    • ZONE: la zona en la que estás creando este ELB.

  3. Crea un recurso BackendService y añádele el recurso Backend que has creado anteriormente:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre elegido para este servicio de backend.
    • TARGET_PORT: lista separada por comas de los puertos de destino que traduce este servicio de backend. Cada puerto de destino especifica el protocolo, el puerto de la regla de reenvío y el puerto de la instancia de backend. Puede 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: el nombre del recurso de comprobación de estado. Este campo es opcional. Incluya este campo solo si está configurando un ELB para cargas de trabajo de máquinas virtuales.

  4. Añade el recurso BackendService al recurso Backend que has creado anteriormente:

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

  5. Opcional: Usa la afinidad de sesión para los ELBs para asegurarte de que las solicitudes del mismo cliente se dirijan siempre al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de carga, 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

    Haz los cambios siguientes:

    • POLICY_NAME: el nombre que elijas para la política del servicio de backend.

    • MODE: el modo de afinidad de sesión. Se admiten dos modos:

      • NONE: la afinidad de sesión está inhabilitada. Las solicitudes se dirigen 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: el selector de etiquetas que selecciona a qué servicio 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.

  6. Crea un recurso ForwardingRule externo que defina la IP virtual 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

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre de tu servicio de backend.
    • FORWARDING_RULE_EXTERNAL_NAME: el nombre que elijas para la regla de reenvío.
    • CIDR: este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del pool de IPs zonales. 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 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.

  7. 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 carga, describe la regla de reenvío:

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. Para validar el ELB configurado, confirme la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una curl solicitud a la dirección IP virtual:

    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 IP virtual en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Haz los cambios siguientes:

      • FORWARDING_RULE_VIP: el VIP de la regla de reenvío.
      • PORT: número de puerto del campo PROTOCOL_PORT de la regla de reenvío.

API

Crea un ELB que tenga como destino cargas de trabajo de pods o VMs mediante la API de KRM. Este ELB se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend.

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

  1. Crea un recurso Backend para definir los endpoints del ELB. Crea recursos Backend para cada zona en la que se coloquen 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

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API Management zonal. Para obtener más información, consulta Cambiar a un contexto zonal.
    • PROJECT_NAME: el nombre de tu proyecto.
    • BACKEND_NAME: el nombre del recurso Backend.
    • CLUSTER_NAME: este campo es opcional. Este campo especifica el clúster al que se limita el ámbito de los selectores definidos. Este campo no se aplica a las cargas de trabajo de máquinas virtuales. Si un recurso Backend no incluye el campo clusterName, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto.

  2. Omite este paso si este ELB es para cargas de trabajo de pods. Si vas a configurar un ELB para cargas de trabajo de VMs, define una comprobación del 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

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre que elijas para el recurso de comprobación de estado, como my-health-check.
    • PORT: el puerto en el que se realiza la comprobación del estado. El valor predeterminado es 80.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5.
    • HEALTHY_THRESHOLD: número de sondeos secuenciales que deben superarse para que el endpoint se considere correcto. El valor predeterminado es 2.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2.

  3. Crea un objeto BackendService usando el recurso Backend que has creado anteriormente. Si vas a configurar un ELB para cargas de trabajo de máquinas virtuales, 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

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre que elijas para tu recurso BackendService.
    • HEALTH_CHECK_NAME: el nombre del recurso HealthCheck que has creado anteriormente. No incluyas este campo si vas a configurar un ELB para cargas de trabajo de pods.

  4. Opcional: Usa la afinidad de sesión para los ELBs para asegurarte de que las solicitudes del mismo cliente se dirijan siempre al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de carga, crea un recurso BackendServicePolicy. Este recurso define los ajustes 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

    Haz los cambios siguientes:

    • POLICY_NAME: el nombre que elijas para la política del servicio de backend.

    • MODE: el modo de afinidad de sesión. Se admiten dos modos:

      • NONE: la afinidad de sesión está inhabilitada. Las solicitudes se dirigen 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: el selector de etiquetas que selecciona a qué servicio 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.

  5. Crea un recurso ForwardingRule externo que defina la IP virtual 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: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre de tu recurso BackendService.
    • FORWARDING_RULE_EXTERNAL_NAME: el nombre que elijas para tu recurso ForwardingRuleExternal.
    • CIDR: este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del pool de IPs zonales. 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 Subnet recursos, consulta Ejemplo de recursos personalizados.
    • PORT: usa el campo ports para especificar una matriz de puertos L4 a los que se reenvían los paquetes a los backends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Utilice el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.

    • PROTOCOL: el protocolo que se va a usar en la regla de reenvío, como TCP. Una entrada del array ports debe tener el siguiente formato:

      ports:
- port: 80
  protocol: TCP

  6. Para validar el ELB configurado, confirme la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una curl solicitud a la dirección IP virtual:

    1. Para obtener la insignia VIP, usa kubectl get:

      kubectl get forwardingruleexternal -n PROJECT_NAME

      La salida tiene este aspecto:

      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 IP virtual en el puerto especificado en el campo PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Sustituye FORWARDING_RULE_VIP por la IP virtual de la regla de reenvío.

Servicio de Kubernetes

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

Para crear un servicio ELB, siga estos pasos:

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

    El siguiente objeto Service es un ejemplo de un servicio 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

    Haz los cambios siguientes:

    • ELB_SERVICE_NAME: el nombre del servicio ELB.
    • PROJECT_NAME: el espacio de nombres de tu proyecto que contiene las cargas de trabajo del backend.

    El campo port configura el puerto frontend que expones en la dirección VIP. El campo targetPort configura el puerto de backend al que quieres reenviar el tráfico de las cargas de trabajo de backend. El balanceador de carga admite la traducción de direcciones de red (NAT). Los puertos de frontend y backend pueden ser diferentes.

  2. En el campo selector de la definición de Service, especifica pods o máquinas virtuales como cargas de trabajo de backend.

    El selector define qué cargas de trabajo se tomarán como cargas de trabajo de backend para este servicio, en función de las etiquetas que especifiques en 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 definas el Service.

    Para obtener más información sobre la selección de servicios, consulta https://kubernetes.io/docs/concepts/services-networking/service/.

  3. Guarda el archivo de definición Service en el mismo proyecto que las cargas de trabajo del backend.

  4. Aplica el archivo de definición Service al clúster:

    kubectl apply -f ELB_FILE

    Sustituye ELB_FILE por el nombre del archivo de definición Service del servicio 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. Para obtener las direcciones IP del servicio ELB, consulta el estado del servicio:

    kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME

    Haz los cambios siguientes:

    • PROJECT_NAME: el espacio de nombres de tu proyecto que contiene las cargas de trabajo del backend.
    • ELB_SERVICE_NAME: el nombre del servicio ELB.

    Debes obtener un resultado similar al siguiente ejemplo:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h

    La EXTERNAL-IP es la dirección IP del servicio al que se puede acceder desde fuera de la organización.

    Si no obtienes ningún resultado, asegúrate de que has creado el servicio ELB correctamente.

Crear un ELB global

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

gdcloud

Crea un ELB que tenga como destino cargas de trabajo de pods o de VMs mediante la CLI de gcloud.

Este ELB se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend. El recurso personalizado Backend debe tener un ámbito de zona.

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

  1. Crea un recurso Backend para definir el endpoint del ELB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster=CLUSTER_NAME \
  --zone=ZONE

    Haz los cambios siguientes:

    • BACKEND_NAME: el nombre que elijas para el recurso de backend, como my-backend.
    • LABELS: un selector que define qué endpoints entre pods y VMs se deben usar para este recurso de backend. Por ejemplo, app=web.
    • PROJECT_NAME: el nombre de tu proyecto.
    • CLUSTER_NAME: el clúster al que se limita el ámbito de los selectores definidos. Si no se especifica este campo, se seleccionarán todos los endpoints con la etiqueta indicada. Este campo es opcional.
    • ZONE: la zona que se va a usar en esta invocación. Para predefinir la marca de zona en todos los comandos que la requieran, ejecuta gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos multizona. Este campo es opcional.

  2. Omite este paso si este ELB es para cargas de trabajo de pods. Si vas a configurar un ELB para cargas de trabajo de VMs, define una comprobación del 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

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre que elijas para el recurso de comprobación de estado, como my-health-check.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5. Este campo es opcional.
    • HEALTHY_THRESHOLD: el tiempo que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
    • PORT: el puerto en el que se realiza la comprobación del estado. El valor predeterminado es 80. Este campo es opcional.

  3. Crea un recurso BackendService y añádele el recurso Backend que has creado anteriormente:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre elegido para este servicio de backend.
    • TARGET_PORTS: lista separada por comas de los puertos de destino que traduce este servicio de backend. Cada puerto de destino especifica el protocolo, el puerto de la regla de reenvío y el puerto de la instancia de backend. Puede 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: el nombre del recurso de comprobación de estado. Este campo es opcional. Incluya este campo solo si está configurando un ELB para cargas de trabajo de máquinas virtuales.

  4. Añade el recurso BackendService al recurso Backend que has creado anteriormente:

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

  5. Opcional: Usa la afinidad de sesión para los ELBs para asegurarte de que las solicitudes del mismo cliente se dirijan siempre al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de carga, 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

    Haz los cambios siguientes:

    • POLICY_NAME: el nombre que elijas para la política del servicio de backend.

    • MODE: el modo de afinidad de sesión. Se admiten dos modos:

      • NONE: la afinidad de sesión está inhabilitada. Las solicitudes se dirigen 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: el selector de etiquetas que selecciona a qué servicio 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.

  6. Crea un recurso ForwardingRule externo que defina la IP virtual 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

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre de tu servicio de backend.
    • FORWARDING_RULE_EXTERNAL_NAME: el nombre que elijas para la regla de reenvío.
    • CIDR: este campo es opcional. Si no se especifica ninguna, se reserva automáticamente un IPv4/32 CIDR del grupo de IPs 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 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.

  7. 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 carga, describe la regla de reenvío:

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. Para validar el ELB configurado, confirme la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una curl solicitud a la dirección IP virtual:

    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 IP virtual en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Haz los cambios siguientes:

      • FORWARDING_RULE_VIP: el VIP de la regla de reenvío.
      • PORT: número de puerto del campo PROTOCOL_PORT de la regla de reenvío.

API

Crea un ELB que tenga como destino cargas de trabajo de pods o VMs mediante la API de KRM. Este ELB se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend. Para crear un ELB zonal con la API KRM, sigue estos pasos:

  1. Crea un recurso Backend para definir los endpoints del ELB. Crea recursos Backend para cada zona en la que se coloquen 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

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API de gestión global. Para obtener más información, consulta Cambiar al contexto global.
    • PROJECT_NAME: el nombre de tu proyecto.
    • BACKEND_NAME: el nombre del recurso Backend.
    • CLUSTER_NAME: este campo es opcional. Este campo especifica el clúster al que se limita el ámbito de los selectores definidos. Este campo no se aplica a las cargas de trabajo de máquinas virtuales. Si un recurso Backend no incluye el campo clusterName, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto.

  2. Omite este paso si este ELB es para cargas de trabajo de pods. Si vas a configurar un ELB para cargas de trabajo de VMs, define una comprobación del 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

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre que elijas para el recurso de comprobación de estado, como my-health-check.
    • PORT: el puerto en el que se realiza la comprobación del estado. El valor predeterminado es 80.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5.
    • HEALTHY_THRESHOLD: número de sondeos secuenciales que deben superarse para que el endpoint se considere correcto. El valor predeterminado es 2.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2.

    Como se trata de un ELB global, crea la comprobación del estado en la API global.

  3. Crea un objeto BackendService usando el recurso Backend que has creado anteriormente. Si vas a configurar un ELB para cargas de trabajo de máquinas virtuales, 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

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre que elijas para tu recurso BackendService.
    • HEALTH_CHECK_NAME: el nombre del recurso HealthCheck que has creado anteriormente. No incluyas este campo si vas a configurar un ELB para cargas de trabajo de pods.

    • ZONE: la zona en la que se crea el recurso Backend. Puedes especificar varios back-ends en el campo backendRefs. Por ejemplo:

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • El campo targetPorts es opcional. En este recurso se enumeran los puertos que traduce este recurso BackendService. Si usas este objeto, proporciona valores para lo siguiente:

      • PORT: el puerto expuesto por el servicio.
      • PROTOCOL: el protocolo de capa 4 con el que debe coincidir el tráfico. Solo se admiten TCP y UDP.

      • TARGET_PORT: 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 de targetPorts podría ser el siguiente:

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. Opcional: Usa la afinidad de sesión para los ELBs para asegurarte de que las solicitudes del mismo cliente se dirijan siempre al mismo backend. Para habilitar la afinidad de sesión en los balanceadores de carga, crea un recurso BackendServicePolicy. Este recurso define los ajustes 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

    Haz los cambios siguientes:

    • POLICY_NAME: el nombre que elijas para la política del servicio de backend.

    • MODE: el modo de afinidad de sesión. Se admiten dos modos:

      • NONE: la afinidad de sesión está inhabilitada. Las solicitudes se dirigen 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: el selector de etiquetas que selecciona a qué servicio 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.

  5. Crea un recurso ForwardingRule externo que defina la IP virtual 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: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Haz los cambios siguientes:

    • FORWARDING_RULE_EXTERNAL_NAME: el nombre que elijas para tu recurso ForwardingRuleExternal.
    • CIDR: este campo es opcional. Si no se especifica ninguna, se reserva automáticamente un IPv4/32 CIDR del grupo de IPs 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 Subnet, consulta Ejemplo de recursos personalizados.
    • PORT: usa el campo ports para especificar una matriz de puertos L4 a los que se reenvían los paquetes a los backends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Utilice el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.

    • PROTOCOL: el protocolo que se va a usar en la regla de reenvío, como TCP. Una entrada del array ports debe tener el siguiente formato:

      ports:
- port: 80
  protocol: TCP

  6. Para validar el ELB configurado, confirme la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una curl solicitud a la dirección IP virtual:

    1. Para obtener la insignia VIP, usa kubectl get:

      kubectl get forwardingruleexternal -n PROJECT_NAME

      La salida tiene este aspecto:

      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 IP virtual en el puerto especificado en el campo PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Sustituye FORWARDING_RULE_VIP por la IP virtual de la regla de reenvío.