Configura balanceadores de cargas internos

Los balanceadores de cargas internos (ILB) exponen servicios dentro de la organización desde un grupo de IPs internas asignado a la organización. Nunca se puede acceder a un servicio de ILB desde ningún extremo fuera de la organización.

De forma predeterminada, puedes acceder a los servicios del ILB dentro del mismo proyecto desde cualquier clúster de la organización. La política de red del proyecto predeterminada no te permite acceder a ningún recurso del proyecto desde fuera de él, y esta restricción también se aplica a los servicios de ILB. Si el administrador de la plataforma (PA) configura políticas de red del proyecto que permiten el acceso a tu proyecto desde otros proyectos, el servicio de ILB también será accesible desde esos otros proyectos en la misma organización.

Antes de comenzar

Para configurar ILB, 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 los roles de identidad y acceso necesarios:

  • Pídele al administrador de IAM de la organización que te otorgue el rol de administrador del balanceador de cargas (load-balancer-admin).
  • En el caso de los ILB globales, pídele al administrador de IAM de tu organización 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 roles predefinidos.

• Conoce el tipo de clúster que aloja tus cargas de trabajo. Existen instrucciones distintas para configurar ILB para clústeres compartidos y estándar.

Crea un balanceador de cargas interno para clústeres compartidos

Puedes crear ILB globales o zonales para clústeres compartidos. El alcance de los ILB globales abarca un universo de GDC. El alcance de los ILB 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.

Crea ILB con tres métodos diferentes en GDC:

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

Puedes segmentar 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 desde el clúster de Kubernetes.

Crea un ILB zonal

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

gdcloud

Crea un ILB que apunte a cargas de trabajo de pods o VM con la CLI de gcloud.

Este ILB segmenta todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend.

Para crear un ILB con gcloud CLI, sigue estos pasos:

1. Crea un recurso Backend para definir el extremo del ILB:

   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 los Pods y las 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 requieren, 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 seleccionarán todos los extremos con la etiqueta determinada. Este campo es opcional.

2. Omite este paso si este ILB es para cargas de trabajo de Pod. Si configuras un ILB para cargas de trabajo de VM, define el tipo de verificación de estado para el ILB. 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. Este campo es opcional.
   • HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben aprobarse para que el extremo se considere en buen estado. El valor predeterminado es 5. Este campo es opcional.
   • TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5. Este campo es opcional.
   • 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. Este campo es opcional.
   • 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 ILB.

3. Crea un recurso BackendService y agrégale el recurso Backend creado anteriormente:

   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: Es el nombre elegido para este servicio de backend.
   • TARGET_PORTS: Es una lista separada por comas de los 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 ILB para cargas de trabajo de VM.

4. Agrega el recurso BackendService al recurso Backend creado anteriormente:

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

5. Crea un recurso ForwardingRule interno que defina la VIP en la que está disponible el servicio:

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=INTERNAL \
     --zone=ZONE \
     --project=PROJECT_NAME
   

   Reemplaza lo siguiente:

   • BACKEND_SERVICE_NAME: El nombre de tu servicio de backend.
   • FORWARDING_RULE_INTERNAL_NAME con 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 de IPv4/32 del grupo de IP 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 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.

6. Para validar el ILB 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_INTERNAL_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: Es 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 ILB que apunte a cargas de trabajo de pods o VM con la API de KRM. Este ILB segmenta todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend.

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

1. Crea un recurso Backend para definir los extremos del ILB. Crea recursos de 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 administración zonal. Para obtener más información, consulta Cómo cambiar 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.

   Puedes usar el mismo recurso Backend para cada zona o crear recursos Backend con diferentes conjuntos de etiquetas para cada zona.

2. Omite este paso si este ILB es para cargas de trabajo de Pod. Si configuras un ILB para cargas de trabajo de VM, define una verificación de estado para el ILB:

   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.
   • 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.
   • HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben aprobarse para que el extremo se considere en buen estado. El valor predeterminado es 2.
   • 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.

3. Crea un objeto BackendService con el recurso Backend creado anteriormente. Si configuras un ILB 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 ILB para cargas de trabajo de Pod.

4. Crea un recurso ForwardingRule interno 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: ForwardingRuleInternal
   metadata:
     namespace: PROJECT_NAME
     Name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       Protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Reemplaza lo siguiente:

   • FORWARDING_RULE_INTERNAL_NAME: Es el nombre elegido para tu recurso ForwardingRuleInternal.
   • CIDR: Este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR de IPv4/32 del grupo de IP 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 Ejemplo de recursos personalizados.
   • PORT: Usa el campo ports para especificar un array de puertos de L4 para los que los paquetes se reenvían 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 expone la aplicación real 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
     

5. Para validar el ILB 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 forwardingruleinternal -n PROJECT_NAME
      

      El resultado luce de la siguiente manera:

      NAME           BACKENDSERVICE                               CIDR              READY
      ilb-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.

Service de Kubernetes

Puedes crear ILB en GDC creando un objeto Service de Kubernetes de tipo LoadBalancer en un clúster de Kubernetes. Este ILB solo segmenta las cargas de trabajo en el clúster en el que se crea el objeto Service.

Para crear un ILB con el objeto Service, sigue estos pasos:

1. Crea un archivo YAML para la definición de Service del tipo LoadBalancer. Debes diseñar el servicio de ILB como interno con la anotación networking.gke.io/load-balancer-type: internal.

   Nota: El valor internal distingue mayúsculas de minúsculas y debe estar en minúsculas.

   El siguiente objeto Service es un ejemplo de un servicio de ILB:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       networking.gke.io/load-balancer-type: internal
     name: ILB_SERVICE_NAME
     namespace: PROJECT_NAME
   spec:
     ports:
     - port: 1234
       protocol: TCP
       targetPort: 1234
     selector:
       k8s-app: my-app
     type: LoadBalancer
   

   Reemplaza lo siguiente:

   • ILB_SERVICE_NAME: Es el nombre del servicio de ILB.
   • 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 retransmitir 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.

2. 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 tomarán como cargas de trabajo de backend para este servicio, en función de 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 los que defines 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 de backend. El servicio de ILB solo puede seleccionar cargas de trabajo que se encuentren en el mismo clúster que la definición de Service.

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

   kubectl apply -f ILB_FILE
   

   Reemplaza ILB_FILE por el nombre del archivo de definición de Service para el servicio de ILB.

   Cuando creas un servicio de ILB, este obtiene una dirección IP. Para obtener la dirección IP del servicio de ILB, consulta el estado del servicio:

   kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME
   

   Reemplaza lo siguiente:

   • PROJECT_NAME: Es el espacio de nombres de tu proyecto que contiene las cargas de trabajo de backend.
   • ILB_SERVICE_NAME: Es el nombre del servicio de ILB.

   Debes obtener un resultado similar al siguiente ejemplo:

   NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
   ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h
   

   Los campos CLUSTER-IP y EXTERNAL-IP deben mostrar el mismo valor, que es la dirección IP del servicio de ILB. Ahora se puede acceder a esta dirección IP desde otros clústeres de la organización, de acuerdo con las políticas de red del proyecto que tiene el proyecto.

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

   GDC admite nombres del sistema de nombres de dominio (DNS) para los servicios. Sin embargo, esos nombres solo funcionan en el mismo clúster para los servicios de ILB. Desde otros clústeres, debes usar la dirección IP para acceder al servicio del ILB.

   Importante: Si los valores de CLUSTER-IP y EXTERNAL-IP no son iguales, significa que configuraste el servicio como un servicio de balanceador de cargas externo (ELB). Asegúrate de que la anotación networking.gke.io/load-balancer-type: internal sea correcta en la definición de Service. Las claves y los valores de las anotaciones distinguen mayúsculas de minúsculas.

Crea un ILB global

Crea un ILB global con la CLI de gcloud o la API de KRM.

gdcloud

Crea un ILB que apunte a cargas de trabajo de pods o VM con la CLI de gcloud.

Este ILB segmenta 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 de zona.

Para crear un ILB con gcloud CLI, sigue estos pasos:

1. Crea un recurso Backend para definir el extremo del ILB:

   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 los Pods y las 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 seleccionarán 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 requieren, ejecuta gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos multizonales. Este campo es opcional.

2. Omite este paso si este ILB es para cargas de trabajo de Pod. Si configuras un ILB para cargas de trabajo de VM, define una verificación de estado para el ILB:

   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. Este campo es opcional.
   • HEALTHY_THRESHOLD: Es el tiempo que se debe esperar antes de declarar una falla. El valor predeterminado es 5. Este campo es opcional.
   • TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5. Este campo es opcional.
   • 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. Este campo es opcional.
   • PORT: Es el puerto en el que se realiza la verificación de estado. El valor predeterminado es 80. Este campo es opcional.

3. Crea un recurso BackendService y agrégale el recurso Backend creado anteriormente:

   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: Es el nombre elegido para este servicio de backend.
   • TARGET_PORTS: Es una lista separada por comas de los 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 ILB para cargas de trabajo de VM.

4. Agrega el recurso BackendService al recurso Backend creado anteriormente:

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

5. Crea un recurso ForwardingRule interno que defina la VIP en la que está disponible el servicio:

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=INTERNAL \
     --project=PROJECT_NAME \
     --global
   

   Reemplaza lo siguiente:

   • FORWARDING_RULE_INTERNAL_NAME: Es el nombre que elegiste para la regla de reenvío.
   • CIDR: Es 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. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del grupo de IP global. Este campo es opcional.
   • 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.

6. Para validar el ILB 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_INTERNAL_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: Es 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 ILB que apunte a cargas de trabajo de pods o VM con la API de KRM. Este ILB segmenta todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend. Para crear un ILB zonal con la API de KRM, sigue estos pasos:

1. Crea un recurso Backend para definir los extremos del ILB. Crea recursos de Backend para cada zona en la que se colocan las cargas de trabajo:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.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 administración global. Para obtener más información, consulta Cómo cambiar 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.

   Puedes usar el mismo recurso Backend para cada zona o crear recursos Backend con diferentes conjuntos de etiquetas para cada zona.

2. Omite este paso si este ILB es para cargas de trabajo de Pod. Si configuras un ILB para cargas de trabajo de VM, define una verificación de estado para el ILB:

   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
   

   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.
   • 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.
   • HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben aprobarse para que el extremo se considere en buen estado. El valor predeterminado es 2.
   • 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.

   Dado que se trata de un ILB global, crea la verificación de estado en la API global.

3. Crea un objeto BackendService con el recurso Backend creado anteriormente. Si configuras un ILB 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 anteriormente. No incluyas este campo si configuras un ILB para cargas de trabajo de Pod.

   • 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. En este recurso, se enumeran 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 de 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
       

4. Crea un recurso ForwardingRule interno 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: ForwardingRuleInternal
   metadata:
     namespace: PROJECT_NAME
     Name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       Protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Reemplaza lo siguiente:

   • FORWARDING_RULE_INTERNAL_NAME: Es el nombre elegido para tu recurso ForwardingRuleInternal.
   • CIDR: Es 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. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del grupo de IP global. Este campo es opcional.
   • PORT: Usa el campo ports para especificar un array de puertos de L4 para los que los paquetes se reenvían 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 expone la aplicación real 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
     

5. Para validar el ILB 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 forwardingruleinternal -n PROJECT_NAME
      

      El resultado luce de la siguiente manera:

      NAME           BACKENDSERVICE                               CIDR              READY
      ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
      

   2. Prueba 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 interno para clústeres estándar

Puedes crear ILB zonales para clústeres estándar, pero no se admiten los ILB globales. El alcance de los ILB 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.

Crea ILB zonales para clústeres estándar usando el servicio de Kubernetes directamente en el clúster de Kubernetes. 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 desde el clúster de Kubernetes.

Crea un ILB zonal para clústeres estándar

Puedes crear ILB en GDC creando un objeto Service de Kubernetes de tipo LoadBalancer en un clúster de Kubernetes. Este ILB solo segmenta las cargas de trabajo en el clúster en el que se crea el objeto Service.

Para crear un ILB con el objeto Service, sigue estos pasos:

1. Crea un archivo YAML para la definición de Service del tipo LoadBalancer. Debes diseñar el servicio de ILB como interno con la anotación networking.gke.io/load-balancer-type: internal.

   Nota: El valor internal distingue mayúsculas de minúsculas y debe estar en minúsculas.

   El siguiente objeto Service es un ejemplo de un servicio de ILB:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       networking.gke.io/load-balancer-type: internal
     name: ILB_SERVICE_NAME
     namespace: ILB_SERVICE_NAMESPACE
   spec:
     ports:
     - port: 1234
       protocol: TCP
       targetPort: 1234
     selector:
       k8s-app: my-app
     type: LoadBalancer
   

   Reemplaza lo siguiente:

   • ILB_SERVICE_NAME: Es el nombre del servicio de ILB.
   • ILB_SERVICE_NAMESPACE: Es el espacio de nombres 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 retransmitir 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.

2. En el campo selector de la definición de Service, especifica los Pods que actuarán 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 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 los que defines 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 la especificación Service en un archivo YAML. Sustituye el nombre del archivo por ILB_FILE en el siguiente comando. El servicio de ILB solo puede seleccionar cargas de trabajo que se encuentren en el mismo clúster que la definición de Service.

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

   export KUBECONFIG=KUBECONFIG_PATH
   kubectl apply -f ILB_FILE
   

   Reemplaza lo siguiente:

   • ILB_FILE:Es el nombre del archivo de definición de Service para el servicio de ILB.
   • KUBECONFIG_PATH: Es la ruta al archivo kubeconfig del clúster estándar.

   Cuando creas un servicio de ILB, este obtiene una dirección IP. Para obtener la dirección IP del servicio de ILB, consulta el estado del servicio:

   kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME
   

   Reemplaza lo siguiente:

   • ILB_SERVICE_NAMESPACE: Es el espacio de nombres que contiene las cargas de trabajo de backend.
   • ILB_SERVICE_NAME: Es el nombre del servicio de ILB.
   • KUBECONFIG_PATH: Es la ruta al archivo kubeconfig del clúster estándar.

   Obtendrás un resultado similar al siguiente ejemplo:

   NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
   ilb-service             LoadBalancer   10.0.0.1      198.51.0.1        1234:31930/TCP   22h
   

   Ahora se puede acceder a esta dirección IP desde otros clústeres de la organización, de acuerdo con las políticas de red del proyecto que tiene el proyecto.

Selecciona una VM como backend para un balanceador de cargas

Para vincular una VM al balanceador de cargas, haz lo siguiente:

1. 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 desde el 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 LabelSelector en la configuración del balanceador de cargas, como app=server.
   • VM_NAME: Es el nombre de la máquina virtual que se vincula.
   • PROJECT_NAME: nombre del proyecto.

2. Asegúrate de que el servidor esté escuchando en el mismo puerto que se especificó en el objeto HealthCheck.