Crea un balanceador de cargas de protocolo mixto

En este documento, se muestra cómo exponer una aplicación que se ejecuta en un clúster de Google Kubernetes Engine (GKE) mediante un Service LoadBalancer externo o interno de protocolo mixto para el tráfico de TCP y UDP.

Para obtener más información sobre los balanceadores de cargas L4, consulta Acerca de los Services LoadBalancer.

Descripción general

Puedes exponer aplicaciones que usan protocolos TCP y UDP con dos Services LoadBalancer de GKE separados con una dirección IP compartida y coordinada de forma manual. Sin embargo, este enfoque es ineficiente porque requiere administrar varios Services para una sola aplicación y puede generar problemas, como errores de configuración o cuotas de direcciones IP agotadas.

Los Services LoadBalancer de protocolo mixto te permiten usar un solo Service para administrar el tráfico de TCP y UDP. El uso de un solo Service simplifica la configuración, ya que te permite usar una sola dirección IP y un conjunto consolidado de reglas de reenvío para ambos protocolos. Esta función es compatible con los balanceadores de cargas de red de transferencia externos y los balanceadores de cargas de red de transferencia internos.

GKE admite Services de protocolo mixto con configuraciones de IPv4, IPv6 y pila doble. Los Services de protocolo mixto usan reglas de reenvío de capa 3 (L3). Por diseño, estas reglas reenvían todo el tráfico que llega a la dirección IP virtual (VIP) del balanceador de cargas directamente a los nodos del clúster.

Para mantener la seguridad, GKE crea y administra automáticamente reglas de firewall con prioridad 999 que permiten solo el tráfico específico de TCP y UDP definido en tu manifiesto de Service. GKE bloquea todo el tráfico no autorizado dirigido a la dirección VIP del balanceador de cargas con reglas de firewall administradas mediante la prioridad 1000. Si creas reglas de firewall de mayor prioridad, asegúrate de que las reglas no permitan accidentalmente que el tráfico no autorizado llegue a tus nodos. Para obtener más información, consulta Reglas de firewall de Service de GKE.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa the gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.

Requisitos

Para crear un Service LoadBalancer que use protocolos mixtos, tu clúster debe cumplir con los siguientes requisitos:

  • El balanceo de cargas de protocolo mixto está disponible de forma general a partir de la versión 1.36.2-gke.1498000 de GKE y versiones posteriores. La versión disponible de forma general admite balanceadores de cargas externos e internos con configuraciones de IPv4, IPv6 y pila doble.
  • Para las versiones 1.34.1-gke.2190000 a 1.36.2-gke.1498000, el balanceo de cargas de protocolo mixto solo se admite para balanceadores de cargas externos que usan direcciones IPv4.
  • Debes tener habilitado el complemento HttpLoadBalancing en tu clúster.
  • Para los balanceadores de cargas internos, el clúster debe tener habilitada la subdivisión de GKE.
  • Para los nuevos Services LoadBalancer internos, en el manifiesto del Service, establece el valor del campo spec.loadBalancerClass en networking.gke.io/l4-regional-internal. Para los Services internos existentes, tu manifiesto ya tiene la anotación networking.gke.io/load-balancer-type: "Internal", y puedes dejar la anotación como está.
  • Para los nuevos Services LoadBalancer externos, establece el campo spec.loadBalancerClass en networking.gke.io/l4-regional-external en el manifiesto del Service. Para los Services externos existentes, tu manifiesto ya tiene la cloud.google.com/l4-rbs: "enabled" anotación, y puedes dejar la anotación como está.

Limitaciones

  • En las versiones 1.34.1-gke.2190000 a 1.36.2-gke.1498000, los balanceadores de cargas de protocolo mixto solo admiten direcciones IPv4.
  • Los Services existentes que tienen los finalizadores gke.networking.io/l4-ilb-v1 o gke.networking.io/l4-netlb-v1 no se pueden usar para el balanceo de cargas de protocolo mixto. Si deseas usar protocolos mixtos en estos Services, debes borrar y volver a crear el Service según los requisitos anteriores.
  • La actualización de los puertos en el Service puede causar una breve interrupción del tráfico para todo el tráfico enrutado a través del balanceador de cargas.

Precios

Google Cloud te factura por regla de reenvío, por cualquier dirección IP externa y por los datos enviados. En la siguiente tabla, se describe la cantidad de reglas de reenvío y direcciones IP externas que se usan para las configuraciones especificadas. Para obtener más información, consulta Precios de la red de VPC.

Tipo Capa de transporte Capa de Internet Cantidad de reglas de reenvío Cantidad de direcciones IP externas
Interno Único o mixto (TCP, UDP o ambos) IPv4 1 0
IPv6 1 0
IPv4 e IPv6 (pila doble) 2 0
Externo Único o mixto (TCP, UDP o ambos) IPv4 1 1
IPv6 1 1
IPv4 e IPv6 (pila doble) 2 2

Implementa una carga de trabajo

En esta sección, se muestra cómo implementar una carga de trabajo de muestra que escucha en los puertos TCP y UDP. Ten en cuenta que la configuración de Deployment es la misma, ya sea que uses un Service LoadBalancer de protocolo mixto o dos Services LoadBalancer de protocolo único separados.

  1. El siguiente manifiesto es para una aplicación de muestra que escucha en el puerto 8080 para el tráfico de TCP y UDP. Guarda el siguiente manifiesto como mixed-app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: mixed-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mixed-app
  template:
    metadata:
      labels:
        app: mixed-app
    spec:
      containers:
      - image: gcr.io/kubernetes-e2e-test-images/agnhost:2.6
        name: agnhost
        args: ["serve-hostname", "--port=8080", "--tcp=true", "--udp=true", "--http=false"]
        ports:
          - name: tcp8080
            protocol: TCP
            containerPort: 8080
          - name: udp8080
            protocol: UDP
            containerPort: 8080

  2. Aplica el manifiesto al clúster:

    kubectl apply -f mixed-app-deployment.yaml

Crea un balanceador de cargas de protocolo mixto

Crea un Service de tipo LoadBalancer que exponga la implementación al tráfico de TCP y UDP. Puedes crear un balanceador de cargas externo o interno.

  1. Para crear un balanceador de cargas externo, guarda el siguiente manifiesto como mixed-protocol-lb.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: mixed-protocol-external-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
  - name: udp-port
    protocol: UDP
    port: 8080

    Para crear un balanceador de cargas interno, establece el valor del campo spec.loadBalancerClass en networking.gke.io/l4-regional-internal.

    El Service anterior tiene dos puertos, uno para TCP y otro para UDP, ambos en el puerto 8080.

  2. Aplica el manifiesto al clúster:

    kubectl apply --server-side -f mixed-protocol-lb.yaml

Verifica el balanceador de cargas de protocolo mixto

Después de crear el Service, verifica que GKE haya creado el balanceador de cargas correctamente.

  1. Inspecciona el servicio:

    kubectl describe service SERVICE_NAME

    Reemplaza SERVICE_NAME por el nombre de tu Service (por ejemplo, mixed-protocol-lb).

    El resultado muestra la dirección IP del balanceador de cargas y las reglas de reenvío. Verifica los siguientes detalles en el resultado:

    • El campo status.loadBalancer.ingress.ip está propagado.
    • Para los clústeres en las versiones 1.34.1-gke.2190000 a 1.36.2-gke.1498000, verifica que estén presentes las siguientes anotaciones para tu balanceador de cargas externo:
      • service.kubernetes.io/tcp-forwarding-rule
      • service.kubernetes.io/udp-forwarding-rule
    • Para los clústeres que se crean en versiones posteriores a la 1.36.2-gke.1498000, verifica que estén presentes las siguientes anotaciones para tu balanceador de cargas, según tu configuración:
      • Para IPv4: service.kubernetes.io/l3-forwarding-rule
      • Para IPv6: service.kubernetes.io/l3-forwarding-rule-ipv6
      • Para pila doble: ambas anotaciones.
    • La sección Events no contiene mensajes de error.

Actualiza el balanceador de cargas de protocolo mixto

Puedes actualizar los puertos en un balanceador de cargas de protocolo mixto editando el manifiesto del Service. Para editar el Service, ejecuta el siguiente comando:

kubectl edit service SERVICE_NAME

Reemplaza SERVICE_NAME por el nombre de tu Service.

Actualiza los puertos

Para actualizar los puertos en un balanceador de cargas de protocolo mixto, modifica la sección ports del manifiesto del Service. Puedes agregar, quitar o modificar puertos.

En el siguiente ejemplo, se agrega un puerto UDP para la transmisión y un puerto TCP para los metadatos del servidor de juegos:

apiVersion: v1
kind: Service
metadata:
  name: mixed-protocol-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external"  # for internal LB, use: "networking.gke.io/l4-regional-internal"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
  - name: streaming
    protocol: UDP
    port: 10100
  - name: gameserver-metadata
    protocol: TCP
    port: 10400
  - name: https
    protocol: TCP
    port: 443

Actualiza un balanceador de cargas de protocolo único a protocolo mixto

Para cambiar un balanceador de cargas de protocolo único a un balanceador de cargas de protocolo mixto, edita el Service para incluir puertos para los protocolos TCP y UDP.

En el siguiente ejemplo, se agrega un puerto UDP para DNS a un balanceador de cargas existente solo de TCP:

apiVersion: v1
kind: Service
metadata:
  name: already-existing-single-protocol-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external" # for internal LB, use: "networking.gke.io/l4-regional-internal"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: http
    protocol: TCP
    port: 80
  - name: https
    protocol: TCP
    port: 443
  - name: dns
    protocol: UDP
    port: 53

Actualiza un balanceador de cargas de protocolo mixto a protocolo único

Para cambiar un balanceador de cargas de protocolo mixto a un balanceador de cargas de protocolo único, quita todos los puertos de uno de los protocolos.

En el siguiente ejemplo, se quita el puerto UDP para DNS, lo que convierte el balanceador de cargas en solo TCP:

apiVersion: v1
kind: Service
metadata:
  name: already-existing-mixed-protocol-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external" # for internal LB, use: "networking.gke.io/l4-regional-internal"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: http
    protocol: TCP
    port: 80
  - name: https
    protocol: TCP
    port: 443

Borra el LoadBalancer de protocolo mixto

Para borrar el Service LoadBalancer de protocolo mixto, ejecuta el siguiente comando:

kubectl delete service SERVICE_NAME

Reemplaza SERVICE_NAME por el nombre de tu Service (por ejemplo, mixed-protocol-external-lb).

GKE quita automáticamente todos los recursos del balanceador de cargas creados para el Service.

Soluciona problemas

En esta sección, se describe cómo resolver problemas comunes con los Services LoadBalancer de protocolo mixto.

Verifica si hay eventos de error

El primer paso para solucionar problemas es verificar los eventos asociados con tu Service.

  1. Obtén los detalles de tu Service:

    kubectl describe service SERVICE_NAME

    Reemplaza SERVICE_NAME por el nombre de tu Service.

  2. Revisa la sección Events al final del resultado para ver si hay mensajes de error.

Error: No se admite el protocolo mixto para LoadBalancer

Si creaste el Service con la cloud.google.com/l4-rbs: "enabled" anotación, es posible que veas un evento de advertencia del controlador de servicio original después de crear el balanceador de cargas de protocolo mixto: mixed-protocol is not supported for LoadBalancer.

Puedes ignorar este mensaje de forma segura porque el nuevo controlador, que admite protocolos mixtos, aprovisiona correctamente el balanceador de cargas.

Falta la definición de puerto después de una actualización

Síntoma:

Cuando actualizas un Service que usa el mismo puerto para TCP y UDP (por ejemplo, el puerto 8080), falta una de las definiciones de puerto en el Service actualizado.

Causa:

Este es un problema conocido en Kubernetes. Cuando actualizas un Service con varios protocolos en el mismo puerto, el cálculo de parches del cliente puede combinar de forma incorrecta la lista de puertos, lo que hace que se quite una de las definiciones de puerto. Este problema afecta a los clientes que usan parches del cliente, como kubectl apply y el cliente de Go con parches de combinación.

Solución:

La solución alternativa para este problema depende de tu cliente.

  • Para kubectl: Usa la marca --server-side con kubectl apply:

    kubectl apply --server-side -f YOUR_SERVICE_MANIFEST.yaml

    Reemplaza YOUR_SERVICE_MANIFEST por el nombre de tu manifiesto de Service.

  • Para go-client: No uses parches de combinación. En su lugar, usa una llamada de actualización para reemplazar el Service. Esto requiere una solicitud HTTP PUT con la especificación completa del objeto Service.

¿Qué sigue?