En este documento, se explica cómo implementar una aplicación de muestra en dos clústeres de GKE en diferentes regiones y se muestra cómo la puerta de enlace de varios clústeres enruta el tráfico de forma inteligente cuando supera los límites de capacidad del servicio.
El balanceo de cargas basado en la capacidad es una función de las puertas de enlace de varios clústeres que te ayuda a compilar aplicaciones altamente confiables y resistentes. Si defines la capacidad de tus servicios, puedes protegerlos de la sobrecarga y garantizar una experiencia coherente para tus usuarios. Cuando un servicio en un clúster alcanza su capacidad, el balanceador de cargas redirecciona automáticamente el tráfico a otro clúster con capacidad disponible. Para obtener más información sobre la administración del tráfico, consulta Administración del tráfico de GKE.
En este instructivo, usarás una aplicación de ejemplo de store para simular una situación real en la que un servicio de compras en línea es propiedad de equipos independientes y está operado por ellos, y se implementa en una flota de clústeres de GKE compartidos.
Antes de comenzar
Las puertas de enlace de varios clústeres requieren cierta preparación del entorno antes de que puedan implementarse. Antes de continuar, sigue los pasos que se indican en Prepara tu entorno para las puertas de enlace de varios clústeres:
Implemente clústeres de GKE
Registra tus clústeres en una flota (si aún no lo hiciste).
Habilita el Service de varios clústeres y los controladores de puertas de enlace de varios clústeres.
Por último, revisa las limitaciones y los problemas conocidos del controlador de puerta de enlace de GKE antes de usarlo en tu entorno.
Implementa el balanceo de cargas basado en la capacidad
En el ejercicio de esta sección, se muestran los conceptos del balanceo de cargas global y la capacidad del Service mediante la implementación de una aplicación en dos clústeres de GKE en diferentes regiones. El tráfico generado se envía en varios niveles de solicitudes por segundo (RPS) para mostrar cómo se balancean las cargas del tráfico entre los clústeres y las regiones.
En el siguiente diagrama, se muestra la topología que implementarás y cómo el tráfico se desborda entre clústeres y regiones cuando el tráfico supera la capacidad del Service:
Prepara el entorno
Sigue Prepara tu entorno para las puertas de enlace de varios clústeres para preparar tu entorno.
Confirma que los recursos de GatewayClass estén instalados en el clúster de configuración:
kubectl get gatewayclasses --context=gke-west-1El resultado es similar a este:
NAME CONTROLLER ACCEPTED AGE gke-l7-global-external-managed networking.gke.io/gateway True 16h gke-l7-global-external-managed-mc networking.gke.io/gateway True 14h gke-l7-gxlb networking.gke.io/gateway True 16h gke-l7-gxlb-mc networking.gke.io/gateway True 14h gke-l7-regional-external-managed networking.gke.io/gateway True 16h gke-l7-regional-external-managed-mc networking.gke.io/gateway True 14h gke-l7-rilb networking.gke.io/gateway True 16h gke-l7-rilb-mc networking.gke.io/gateway True 14h
Implementa una aplicación
Implementa el servidor de aplicaciones web de muestra en ambos clústeres:
kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-traffic-deploy.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-traffic-deploy.yaml
El resultado es similar a este:
namespace/store created
deployment.apps/store created
Implementa un Service, una puerta de enlace y una HTTPRoute
Aplica el siguiente manifiesto
Servicea los clústeresgke-west-1ygke-east-1:cat << EOF | kubectl apply --context gke-west-1 -f - apiVersion: v1 kind: Service metadata: name: store namespace: traffic-test annotations: networking.gke.io/max-rate-per-endpoint: "10" spec: ports: - port: 8080 targetPort: 8080 name: http selector: app: store type: ClusterIP --- kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: store namespace: traffic-test EOFcat << EOF | kubectl apply --context gke-east-1 -f - apiVersion: v1 kind: Service metadata: name: store namespace: traffic-test annotations: networking.gke.io/max-rate-per-endpoint: "10" spec: ports: - port: 8080 targetPort: 8080 name: http selector: app: store type: ClusterIP --- kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: store namespace: traffic-test EOFEl Service se anota con
max-rate-per-endpointconfigurado en 10 solicitudes por segundo. Con 2 réplicas por clúster, cada Service tiene 20 RPS de capacidad por clúster.A fin de obtener más información sobre cómo elegir un nivel de capacidad de servicio para tu Service, consulta Determina la capacidad de tu Service.
Aplica el siguiente manifiesto
Gatewayal clúster de configuración,gke-west-1en este ejemplo:cat << EOF | kubectl apply --context gke-west-1 -f - kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: store namespace: traffic-test spec: gatewayClassName: gke-l7-global-external-managed-mc listeners: - name: http protocol: HTTP port: 80 allowedRoutes: kinds: - kind: HTTPRoute EOFEn el manifiesto, se describe una puerta de enlace externa, global y de varios clústeres que implementa un balanceador de cargas de aplicaciones externo con una dirección IP de acceso público.
Aplica el siguiente manifiesto
HTTPRouteal clúster de configuración,gke-west-1en este ejemplo:cat << EOF | kubectl apply --context gke-west-1 -f - kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: store namespace: traffic-test labels: gateway: store spec: parentRefs: - kind: Gateway namespace: traffic-test name: store rules: - backendRefs: - name: store group: net.gke.io kind: ServiceImport port: 8080 EOFEl manifiesto describe una HTTPRoute que configura la puerta de enlace con una regla de enrutamiento que dirige todo el tráfico al ServiceImport de almacenamiento. Los
storegrupos de ServiceImportstoreagrupa los Pods del Service de almacenamiento en ambos clústeres y permite que los balanceadores de cargas se dirijan a ellos como un solo Service.Puedes verificar los eventos de la puerta de enlace después de unos minutos para ver si finalizó la implementación:
kubectl describe gateway store -n traffic-test --context gke-west-1El resultado es similar a este:
... Status: Addresses: Type: IPAddress Value: 34.102.159.147 Conditions: Last Transition Time: 2023-10-12T21:40:59Z Message: The OSS Gateway API has deprecated this condition, do not depend on it. Observed Generation: 1 Reason: Scheduled Status: True Type: Scheduled Last Transition Time: 2023-10-12T21:40:59Z Message: Observed Generation: 1 Reason: Accepted Status: True Type: Accepted Last Transition Time: 2023-10-12T21:40:59Z Message: Observed Generation: 1 Reason: Programmed Status: True Type: Programmed Last Transition Time: 2023-10-12T21:40:59Z Message: The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use. GKE Gateway will stop emitting it in a future update, use "Programmed" instead. Observed Generation: 1 Reason: Ready Status: True Type: Ready Listeners: Attached Routes: 1 Conditions: Last Transition Time: 2023-10-12T21:40:59Z Message: Observed Generation: 1 Reason: Programmed Status: True Type: Programmed Last Transition Time: 2023-10-12T21:40:59Z Message: The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use. GKE Gateway will stop emitting it in a future update, use "Programmed" instead. Observed Generation: 1 Reason: Ready Status: True Type: Ready Name: http Supported Kinds: Group: gateway.networking.k8s.io Kind: HTTPRoute Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 12m mc-gateway-controller traffic-test/store Normal SYNC 6m43s mc-gateway-controller traffic-test/store Normal UPDATE 5m40s (x4 over 12m) mc-gateway-controller traffic-test/store Normal SYNC 118s (x6 over 10m) mc-gateway-controller SYNC on traffic-test/store was a successEn este resultado, se muestra que la puerta de enlace se implementó de forma correcta. Es posible que el tráfico tarde unos minutos en comenzar a pasar después de que se implemente la puerta de enlace. Toma nota de la dirección IP en este resultado, ya que se usa en el siguiente paso.
Confirma el tráfico
Para confirmar que el tráfico pase a la aplicación, prueba la dirección IP de la puerta de enlace con un comando curl:
curl GATEWAY_IP_ADDRESS
El resultado es similar a este:
{
"cluster_name": "gke-west-1",
"host_header": "34.117.182.69",
"pod_name": "store-54785664b5-mxstv",
"pod_name_emoji": "👳🏿",
"project_id": "project",
"timestamp": "2021-11-01T14:06:38",
"zone": "us-west1-a"
}
En este resultado, se muestran los metadatos del Pod, que indican la región desde la que se entregó la solicitud.
Verifica el tráfico mediante pruebas de carga
Para verificar que el balanceador de cargas funcione, puedes implementar un generador de tráfico en tu clúster gke-west-1. El generador de tráfico genera tráfico en diferentes niveles de carga para demostrar la capacidad y las funciones de desbordamiento del balanceador de cargas. En los siguientes pasos, se demuestran tres niveles de carga:
- 10 RPS, que está por debajo de la capacidad del Service de almacenamiento en
gke-west-1. - 30 RPS, que está por sobre la capacidad para el Service de almacenamiento
gke-west-1y provoca un desbordamiento de tráfico agke-east-1. - 60 RPS, que está por sobre la capacidad de los Services en ambos clústeres.
Configurar panel
Obtén el nombre del URLmap subyacente para tu puerta de enlace:
kubectl get gateway store -n traffic-test --context=gke-west-1 -o=jsonpath="{.metadata.annotations.networking\.gke\.io/url-maps}"El resultado es similar a lo siguiente:
/projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-traffic-test-store-armvfyupay1tEn la consola de Google Cloud , ve a la página Explorador de métricas.
En Seleccionar una métrica, haz clic en CÓDIGO: MQL.
Ingresa la siguiente consulta para observar las métricas de tráfico del Service de almacenamiento en tus dos clústeres:
fetch https_lb_rule | metric 'loadbalancing.googleapis.com/https/backend_request_count' | filter (resource.url_map_name == 'GATEWAY_URL_MAP') | align rate(1m) | every 1m | group_by [resource.backend_scope], [value_backend_request_count_aggregate: aggregate(value.backend_request_count)]Reemplaza
GATEWAY_URL_MAPpor el nombre del URLmap del paso anterior.Haga clic en Run query. Espera al menos 5 minutos después de implementar el generador de cargas en la siguiente sección para que las métricas se muestren en el gráfico.
Realiza pruebas con 10 RPS
Implementa un Pod en tu clúster
gke-west-1:kubectl run --context gke-west-1 -i --tty --rm loadgen \ --image=cyrilbkr/httperf \ --restart=Never \ -- /bin/sh -c 'httperf \ --server=GATEWAY_IP_ADDRESS \ --hog --uri="/zone" --port 80 --wsess=100000,1,1 --rate 10'Reemplaza
GATEWAY_IP_ADDRESSpor la dirección IP de la puerta de enlace del paso anterior.El resultado es similar al siguiente, lo que indica que el generador de tráfico está enviando tráfico:
If you don't see a command prompt, try pressing enter.El generador de cargas envía de forma continua 10 RPS a la puerta de enlace. Aunque el tráfico proviene de una región de Google Cloud , el balanceador de cargas lo trata como el tráfico de clientes que proviene de la costa oeste de EE.UU. Para simular una diversidad de clientes realista, el generador de cargas envía cada solicitud HTTP como una conexión TCP nueva, lo que significa que el tráfico se distribuye de manera más uniforme entre los Pods de backend.
El generador tarda hasta 5 minutos en generar tráfico para el panel.
Ve el panel Explorador de métricas. Aparecen dos líneas que indican cuánto tráfico tiene balanceo de cargas en cada clúster:
Deberías ver que
us-west1-arecibe alrededor de 10 RPS de tráfico, mientras queus-east1-bno recibe tráfico. Debido a que el generador de tráfico se ejecuta enus-west1, todo el tráfico se envía al Service en el clústergke-west-1.Detén el generador de cargas con Ctrl+C y, luego, borra el Pod:
kubectl delete pod loadgen --context gke-west-1
Realiza pruebas con 30 RPS
Vuelve a implementar el generador de cargas, pero configúralo para enviar 30 RPS:
kubectl run --context gke-west-1 -i --tty --rm loadgen \ --image=cyrilbkr/httperf \ --restart=Never \ -- /bin/sh -c 'httperf \ --server=GATEWAY_IP_ADDRESS \ --hog --uri="/zone" --port 80 --wsess=100000,1,1 --rate 30'El generador tarda hasta 5 minutos en generar tráfico para el panel.
Ve el panel de Cloud Ops.
Deberías ver que se envían alrededor de 20 RPS a
us-west1-ay 10 RPS aus-east1-b. Esto indica que el Service engke-west-1se usa por completo y desborda 10 RPS de tráfico al Service engke-east-1.Detén el generador de cargas con Ctrl+C y, luego, borra el Pod:
kubectl delete pod loadgen --context gke-west-1
Realiza pruebas con 60 RPS
Implementa el generador de cargas configurado para enviar 60 RPS:
kubectl run --context gke-west-1 -i --tty --rm loadgen \ --image=cyrilbkr/httperf \ --restart=Never \ -- /bin/sh -c 'httperf \ --server=GATEWAY_IP_ADDRESS \ --hog --uri="/zone" --port 80 --wsess=100000,1,1 --rate 60'Espera 5 minutos y ve tu panel Cloud Ops. Ahora, debería mostrar que ambos clústeres reciben aproximadamente 30 RPS. Dado que todos los Services están sobreutilizados a nivel global, no hay desbordamiento de tráfico y los Services absorben todo el tráfico que pueden.
Detén el generador de cargas con Ctrl+C y, luego, borra el Pod:
kubectl delete pod loadgen --context gke-west-1
Realiza una limpieza
Después de completar los ejercicios de este documento, sigue estos pasos para quitar los recursos a fin de prevenir cobros no deseados en tu cuenta:
Anula el registro de tus clústeres en la flota si no es necesario que estén registrados para otro propósito.
Inhabilita la función
multiclusterservicediscovery:gcloud container fleet multi-cluster-services disableInhabilitar entrada de varios clústeres
gcloud container fleet ingress disableInhabilita las API:
gcloud services disable \ multiclusterservicediscovery.googleapis.com \ multiclusteringress.googleapis.com \ trafficdirector.googleapis.com \ --project=PROJECT_ID
Soluciona problemas
Sin upstream en buen estado
Síntoma:
El siguiente problema puede ocurrir cuando creas una puerta de enlace, pero no puedes acceder a los servicios de backend (código de respuesta 503):
no healthy upstream
Motivo:
Este mensaje de error indica que el sistema de sondeo de verificación de estado no puede encontrar servicios de backend en buen estado. Es posible que tus servicios de backend estén en buen estado, pero es posible que debas personalizar las verificaciones de estado.
Solución alternativa:
Para resolver este problema, personaliza la verificación de estado según los requisitos de tu aplicación (por ejemplo, /health) mediante un HealthCheckPolicy.
¿Qué sigue?
- Obtén más información sobre el controlador de puerta de enlace.