Balanceo de cargas avanzado en clústeres de GKE

En esta página, se muestra cómo configurar el balanceo de cargas avanzado en clústeres de GKE para usuarios de Cloud Service Mesh (TD) administrado con la API de Kubernetes. Para obtener la guía del usuario correspondiente para configurar el balanceo de cargas avanzado con la API deGoogle Cloud , consulta Configura el balanceo de cargas avanzado.

Puedes usar el balanceo de cargas avanzado para hacer lo siguiente:

  • Mantener el tráfico en una zona de servicio hasta que se agote la capacidad local
  • Envía tráfico al servicio en una ubicación "principal" con conmutación por error a una ubicación secundaria cuando una cantidad suficiente de extremos en la ubicación principal dejan de estar en buen estado.
  • Controla cuándo se produce la conmutación por error (según el porcentaje de hosts en buen estado).

Limitaciones

  • Se aplican limitaciones generales en torno al uso del balanceo de cargas avanzado en Google Cloud .
  • Esta función solo está disponible para los usuarios de Cloud Service Mesh administrado que usan Traffic Director como plano de control y requiere la versión 1.19.10-asm.22 o posterior del plano de datos.

  • No todos los campos de GCPTrafficDistributionPolicy y GCPBackendPolicy son compatibles con Cloud Service Mesh administrado (TD). Los campos admitidos son los siguientes:

    • GCPTrafficDistributionPolicy
      • ServiceLbAlgorithm
      • AutoCapacityDrain
      • FailoverConfig
    • GCPBackendPolicy
      • MaxRatePerEndpoint
      • BackendPreference

    Todos los campos que no se mencionan son campos no admitidos, y una política con al menos un campo no admitido configurado no surte efecto en Cloud Service Mesh .

  • El balanceo de cargas avanzado solo se puede aplicar a los servicios de Kubernetes respaldados por cargas de trabajo que se ejecutan en Google Cloud. No se admiten servicios o cargas de trabajo externos (como ServiceEntry).

  • Las políticas de balanceo de cargas solo se pueden aplicar a servicios de Kubernetes individuales. No se admiten las políticas de balanceo de cargas a nivel del espacio de nombres o de la malla.

  • Solo se admite la capacidad de QPS.

  • Solo se admiten las versiones de GKE >= 1.31.1.

  • Las políticas avanzadas de balanceo de cargas de la malla de servicios solo se deben aplicar a los servicios que solo atienden el tráfico de la malla. No se debe aplicar a los servicios que actúan como backends de GKE Gateway. Los comportamientos del tráfico no están definidos cuando un destino de tráfico de balanceo de cargas avanzado es un servicio de Kubernetes que entrega tráfico de malla y tráfico desde una puerta de enlace de GKE.

Configura el balanceo de cargas avanzado

Puedes usar los siguientes recursos personalizados para configurar el balanceo de cargas avanzado en GKE. Puedes encontrar la definición detallada del recurso en el repositorio de la API de gke-gateway.

GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy configura la política de balanceo de cargas a nivel del servicio para los servicios de Kubernetes. Te permite realizar las siguientes acciones:

Si varias GCPTrafficDistributionPolicies segmentan el mismo servicio, se aplicará la política más antigua.

GCPBackendPolicy

GCPBackendPolicy configura las propiedades de los backends de servicio que afectan el comportamiento del balanceo de cargas, incluidas las siguientes:

Si varias GCPBackendPolicies segmentan el mismo servicio en un clúster, se aplicará la política más antigua.

Estado de la política

Tanto GCPTrafficDistributionPolicy como GCPBackendPolicy tienen un campo de estado que indica el estado de vinculación de la política.

Por ejemplo, ejecutar kubectl describe gcpbackendpolicies example-policy -n example produciría un resultado similar al siguiente:

...
Status:
  Ancestors:
    Ancestor Ref:
      Group:
      Kind:       Service
      Name:       example-svc
      Namespace:  example
    Conditions:
      Last Transition Time:  2024-10-13T01:15:03Z
      Message:
      Observed Generation:   1
      Reason:                Attached
      Status:                True
      Type:                  Attached
    Controller Name:         gsmconfig.gke.io/controller

Configuración preliminar

Antes de completar esta guía, debes aprovisionar Cloud Service Mesh en un clúster de GKE.

  1. Verifica que las CRD estén instaladas:

    kubectl get crd

    El resultado es similar al siguiente:

    ...
gcptrafficdistributionpolicies.networking.gke.io   2024-07-18T21:50:12Z
gcpbackendpolicies.networking.gke.io               2024-07-18T21:50:12Z
...

  2. Instala la CRD de GCPBackendPolicy si aún no está instalada:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcpbackendpolicies.yaml

  3. Instala la CRD de GCPTrafficDistributionPolicy si aún no está instalada:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficdistributionpolicies.yaml

Las políticas de ejemplo de esta guía del usuario se dirigen al servicio foo en el espacio de nombres foo con fines de demostración. Puedes ejecutar el siguiente comando para crear el servicio y el espacio de nombres de prueba o, si lo prefieres, puedes usar tu propio servicio y espacio de nombres:

kubectl apply -f - <<EOF
kind: Namespace
apiVersion: v1
metadata:
  name: foo
  labels:
    istio-injection: enabled
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: foo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test-backend
  template:
    metadata:
      labels:
        app: test-backend
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.23
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: foo
spec:
  selector:
    app: test-backend
  ports:
  - port: 8080
    targetPort: 8080
EOF

Configura el algoritmo de balanceo de cargas

De forma predeterminada, el tráfico a un servicio se distribuye de manera uniforme a cada backend de servicio en buen estado en una malla de servicios de Cloud Service Mesh. Puedes crear la siguiente GCPTrafficDistributionPolicy para que el tráfico se distribuya a la zona más cercana hasta la capacidad del backend:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE
EOF

De forma predeterminada, los backends de servicio se tratan como si tuvieran capacidad infinita. Cuando hay suficientes hosts en buen estado en la zona local o más cercana, el tráfico nunca se distribuirá fuera de esa zona para una determinada localidad del cliente. De manera opcional, puedes configurar la capacidad del backend de tu servicio con GCPBackendPolicy para que una sola zona no se sobrecargue.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
  namespace: foo
spec:
  targetRef:
    kind: Service
    group: ""
    name: foo-backend
  default:
    maxRatePerEndpoint: 5
EOF

Ajusta el comportamiento de la conmutación por error

De forma predeterminada, no se activará la conmutación por error siempre que un porcentaje suficiente de hosts estén en buen estado en los backends principales. Para obtener más información sobre los servidores de backend principales y otros términos, consulta la Descripción general del balanceo de cargas avanzado. GCPTrafficDistributionPolicy te permite configurar el umbral de porcentaje de hosts en buen estado hasta que el tráfico se desvíe de los backends principales a los backends de conmutación por error. La conmutación por error se activa antes con un umbral más grande. Por ejemplo, si deseas que se active la conmutación por error en cuanto el porcentaje de hosts en buen estado descienda por debajo del 90% en los backends principales, puedes configurar la siguiente GCPTrafficDistributionPolicy:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
   failoverConfig:
     failoverHealthThreshold: 90
EOF

Configura el balanceo de cargas avanzado en una malla de servicios de varios clústeres

GCPTrafficDistributionPolicy y GCPBackendPolicy se aplican en diferentes ámbitos en una malla de servicios de varios clústeres.

Cuando un GCPTrafficDistributionPolicy segmenta un servicio de varios clústeres, define el comportamiento del balanceo de cargas a nivel del servicio en todos los clústeres. Solo se debe crear una GCPTrafficDistributionPolicy para un servicio de varios clústeres en particular. Si usas la API de Istio para configurar tu malla de servicios, puedes crear GCPTrafficDistributionPolicy en cualquier clúster de la flota. Puedes verificar si una política entra en conflicto con otra inspeccionando su estado.

Cuando una GCPBackendPolicy segmenta un servicio de varios clústeres, define la configuración a nivel del backend (por ejemplo, la capacidad por Pod) para los Pods de backend seleccionados por su servicio de segmentación en su clúster local. Para el mismo servicio de varios clústeres, es posible definir diferentes parámetros de configuración a nivel del backend en diferentes clústeres.

En el siguiente ejemplo, se crea una GCPTrafficDistributionPolicy en el clúster A para definir el algoritmo de balanceo de cargas que se usará en toda la flota, mientras que las GCPBackendPolicies se encuentran en cada clúster. Ambas políticas de GCPBackendPolicy configuran una capacidad de 10 QPS por pod para los pods de backend en su clúster local, mientras que la política de GCPBackendPolicy en el clúster A configura los pods de backend en el clúster A como backend preferido.

En conjunto, estas políticas configuran los comportamientos de balanceo de cargas para el tráfico dentro de la malla que se envía al servicio foo:

  • El tráfico de cualquier lugar prefiere los backends del clúster A hasta que los Pods de backend del clúster A necesiten controlar 10 QPS por Pod.
    • Este comportamiento se define principalmente en GCPBackendPolicy que establece backendPreference en PREFERRED en el clúster A.
  • El tráfico que supera la capacidad configurada de los backends en el clúster A se enruta al clúster B con el algoritmo WATERFALL_BY_ZONE. Para obtener una explicación más detallada de los servidores de backend preferidos, consulta la Descripción general del balanceo de cargas avanzado.
    • Este comportamiento se define principalmente con GCPTrafficDistributionPolicy, que define el algoritmo, en el clúster A y GCPBackendPolicy, que define la capacidad del backend, en los clústeres A y B.

Malla de servicios de varios clústeres con balanceo de cargas avanzado

En Istio, los servicios regulares de Kubernetes se vuelven "de varios clústeres" de forma implícita cuando hay varios clústeres en la malla de servicios y el servicio se crea a través de los límites del clúster. Si bien la siguiente política de GCPTrafficDistributionPolicy tiene como objetivo el servicio foo de Kubernetes normal, se aplica al servicio foo de varios clústeres que consta de cargas de trabajo correspondientes en dos clústeres.

  1. Crea el objeto GCPTrafficDistributionPolicy para el clúster A:

    kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPTrafficDistributionPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-traffic-distribution-policy
namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE

EOF

  2. Crea el objeto GCPBackendPolicy para el clúster A:

    kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 100
    backendPreference: PREFERRED
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

  3. Crea el objeto GCPBackendPolicy para el clúster B:

    kubectl apply --context cluster-b-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

Pasos siguientes