Implementa Services LoadBalancer de varias redes

En este documento, se muestra cómo exponer Pods de varias redes a clientes internos o externos creando recursos de balanceador de cargas de red de transferencia externo y balanceador de cargas de red de transferencia interno en GKE. Google Cloud Describe la configuración, las capacidades y las limitaciones requeridas de los servicios de LoadBalancer de varias redes.

Si conectas cargas de trabajo a varias redes de VPC, usa un servicio de Kubernetes de tipo LoadBalancer para enrutar el tráfico a los Pods en una red secundaria específica. Cuando creas el Service, GKE crea un balanceador de cargas de red de transferencia para administrar este tráfico.

Para obtener más información sobre las redes múltiples en GKE, consulta Información sobre la compatibilidad de varias redes para Pods.

Cómo funcionan los servicios LoadBalancer de varias redes

Para exponer una carga de trabajo de varias redes, crea un Service de type: LoadBalancer. El Service debe incluir un selector especial que apunte a los Pods según la red de su interfaz secundaria. Agrega una anotación para especificar si se debe crear un balanceador de cargas interno o externo.

La etiqueta networking.gke.io/network en el selector filtra los extremos por red. Esta etiqueta garantiza que el balanceador de cargas solo envíe tráfico a las interfaces de Pod conectadas a la red especificada.

Limitaciones

Los balanceadores de cargas de varias redes tienen las siguientes limitaciones:

  • No se admiten los servicios que usan externalTrafficPolicy: Cluster.
  • No se admiten los servicios que segmentan Pods de hostNetwork.
  • No se admiten las redes IPv6 ni de pila doble.
  • No puedes cambiar la red de un servicio existente.
  • Solo se admiten redes de capa 3.
  • No se admiten los balanceadores de cargas basados en grupos de destino o backends de grupos de instancias.
  • Los Services ClusterIP y NodePort no son compatibles con las redes secundarias (no predeterminadas).

Antes de comenzar

Antes de comenzar, completa las siguientes tareas:

  1. Sigue los pasos que se indican en Configura la compatibilidad con varias redes para Pods para preparar tus redes de VPC y crear un clúster de GKE con una red adicional.
  2. Asegúrate de que tu clúster tenga habilitada la subdivisión para los balanceadores de cargas internos de capa 4. Para habilitar esta función, usa la marca --enable-l4-ilb-subsetting cuando crees o actualices el clúster.
  3. Asegúrate de que tu clúster ejecute la versión 1.37 o posterior de GKE.

Implementa Pods de varias redes

Para adjuntar Pods a una red adicional, crea una Deployment con la anotación networking.gke.io/interfaces. Esta anotación especifica las redes y las interfaces para los Pods.

  1. Guarda el siguiente manifiesto como web-app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
      annotations:
        networking.gke.io/default-interface: 'eth1'
        networking.gke.io/interfaces: '[
          {"interfaceName":"eth0","network":"default"},
          {"interfaceName": "eth1","network": "dmz"}
        ]'
spec:
  containers:
  - name: whereami
    image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
    ports:
    - containerPort: 8080

    En este manifiesto, se crea un Deployment llamado web-app con tres Pods. Los Pods tienen dos interfaces: eth0 conectada a la red default y eth1 conectada a la red dmz. La anotación networking.gke.io/default-interface establece eth1 como la interfaz predeterminada para los Pods.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f web-app-deployment.yaml

Si usas una interfaz no predeterminada para tu servicio, debes configurar el enrutamiento dentro del Pod. Para configurar el enrutamiento, agrega un initContainer a la especificación del Pod que tenga la capacidad NET_ADMIN.

En el siguiente ejemplo, se muestra un initContainer que agrega una ruta predeterminada para la interfaz eth1:

initContainers:
      - name: init-routes-busybox
        image: busybox
        command: ['sh', '-c', 'ip route add default dev eth1 table 200 && ip rule add from 172.16.1.0/24 table 200']
        securityContext:
          capabilities:
            add: ["NET_ADMIN"]

En el comando initContainer, reemplaza 172.16.1.0/24 por el rango de direcciones IP secundario de tu red de Pods.

Implementa un Service LoadBalancer interno

Para exponer la Deployment de web-app en la red de dmz, crea un servicio LoadBalancer interno.

  1. Guarda el siguiente manifiesto como internal-lb-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: web-app-internal-lb
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  externalTrafficPolicy: Local
  ports:
  -   port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    networking.gke.io/network: dmz
    app: web-app
  type: LoadBalancer

    Este manifiesto crea un Service con las siguientes propiedades:

    • networking.gke.io/load-balancer-type: "Internal": Especifica un balanceador de cargas de red de transferencia interno.
    • selector: Selecciona los Pods con la etiqueta app: web-app que están conectados a la red dmz.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f internal-lb-service.yaml

Implementa un objeto Service LoadBalancer externo

Para exponer el Deployment de web-app a clientes externos, crea un objeto Service LoadBalancer externo.

  1. Guarda el siguiente manifiesto como external-lb-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: web-app-external-lb
  namespace: default
  annotations:
    cloud.google.com/l4-rbs: "enabled"
spec:
  externalTrafficPolicy: Local
  ports:
  -   port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    networking.gke.io/network: dmz
    app: web-app
  type: LoadBalancer

    Este manifiesto crea un Service con las siguientes propiedades:

    • cloud.google.com/l4-rbs: "enabled": Especifica un balanceador de cargas de red de transferencia externo basado en servicios de backend.
    • selector: Selecciona los Pods con la etiqueta app: web-app que están conectados a la red dmz.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f external-lb-service.yaml

Verifica los servicios

Después de implementar los servicios, verifica que los balanceadores de cargas se hayan creado y configurado correctamente.

  1. Verifica el estado de los Servicios:

    kubectl get services

    El resultado es similar a lo siguiente:

    NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
web-app-external-lb   LoadBalancer   10.8.47.77    35.239.57.231   80:31550/TCP   5m
web-app-internal-lb   LoadBalancer   10.8.43.251   172.16.0.43     80:32628/TCP   6m
kubernetes            ClusterIP      10.8.32.1     <none>          443/TCP        43h

    La dirección EXTERNAL-IP del balanceador de cargas interno pertenece a la red dmz.

  2. Enumera las reglas de reenvío de tu proyecto:

    gcloud compute forwarding-rules list

    El resultado es similar a lo siguiente:

    NAME                                                   REGION        IP_ADDRESS     IP_PROTOCOL  TARGET
af901673cc0f24907a6aa8c3ce4afc21                       us-central1   35.239.57.231  TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-external-lb-u4xbs4ot
k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a us-central1   172.16.0.43    TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-internal-lb-vp1x1d6a

  3. Describe la regla de reenvío del balanceador de cargas interno para verificar que esté adjunta a la red correcta:

    gcloud compute forwarding-rules describe k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a --region=$REGION

    Reemplaza REGION por la región de tu clúster.

    El resultado es similar al siguiente. Verifica que los campos network y subnetwork coincidan con los detalles de la red dmz.

    IPAddress: 172.16.0.43
IPProtocol: TCP
...
loadBalancingScheme: INTERNAL
name: k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
network: https://www.googleapis.com/compute/v1/projects/projectId/global/networks/dmz-vpc
...
subnetwork: https://www.googleapis.com/compute/v1/projects/projectId/regions/us-central1/subnetworks/dmz-subnet

Prueba los balanceadores de cargas

  1. Para probar el balanceador de cargas externo, envía una solicitud a su dirección IP externa:

    curl EXTERNAL_LB_IP:80

    Reemplaza EXTERNAL_LB_IP por la dirección IP externa del servicio web-app-external-lb.

  2. Para probar el balanceador de cargas interno, envía una solicitud desde un host en la misma VPC que el balanceador de cargas:

    curl INTERNAL_LB_IP:80

    Reemplaza INTERNAL_LB_IP por la dirección IP del servicio web-app-internal-lb.

Soluciona problemas

En esta sección, se describe cómo solucionar problemas relacionados con los balanceadores de cargas de varias redes.

Falla la creación del balanceador de cargas

Si falla la creación del balanceador de cargas, verifica los eventos del Service en busca de mensajes de error:

kubectl describe service SERVICE_NAME

Reemplaza SERVICE_NAME por el nombre de tu servicio.

Un mensaje de error como network some-other-network does not exist indica que la red especificada en el selector de servicio no está definida en el clúster. Verifica que la red exista:

kubectl get networks

Si la red existe, verifica que el objeto Network haga referencia correctamente a un recurso GKENetworkParamSet válido. Para comprobar si hay errores de configuración, inspecciona el estado del recurso Network:

kubectl get networks NETWORK_NAME -o yaml

Reemplaza NETWORK_NAME por el nombre de la red.

En una configuración válida, las condiciones ParamsReady y Ready son True. Si ParamsReady no es True, asegúrate de que el parametersRef en la especificación de Network coincida correctamente con el nombre, el tipo y el grupo de un recurso GKENetworkParamSet existente.

Si el recurso Network es correcto, pero aún no está listo, verifica el estado del recurso GKENetworkParamSet al que se hace referencia para detectar errores, como una subred faltante:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Reemplaza GNP_NAME por el nombre de tu GKENetworkParamSet.

El balanceador de cargas no tiene backends

Si el balanceador de cargas se aprovisionó, pero no tiene backends en buen estado, haz lo siguiente:

  1. Verifica que exista un grupo de nodos con interfaces de red en la red que usa el servicio.
  2. Verifica que los Pods seleccionados por el Servicio se estén ejecutando.

  3. Verifica los extremos del servicio:

    kubectl describe endpointslice -l kubernetes.io/service-name=SERVICE_NAME

    El controlador multinet-endpointslice-controller.gke.io crea los extremos de varias redes. Las direcciones IP de Pod que se indican en EndpointSlice pertenecen a la red que usa el Service. Si el objeto EndpointSlice no tiene extremos, verifica que las etiquetas del selector de Service coincidan con los Pods en ejecución y que el selector de red coincida con la red de los Pods.

¿Qué sigue?