Las redes multiclúster son una herramienta valiosa que permite casos prácticos como la alta disponibilidad regional, la proximidad distribuida a nivel mundial para reducir la latencia y el aislamiento organizativo entre equipos. Google Kubernetes Engine (GKE) ofrece funciones integradas para redes multiclúster que puedes habilitar y usar a gran escala en una flota de clústeres de GKE. Esta función también te permite combinar o migrar la infraestructura desplegada entre GKE Standard y Autopilot para satisfacer las necesidades de arquitectura de cada aplicación.
Con los clústeres Autopilot de GKE, Google gestiona la infraestructura, incluido el plano de control y los nodos. Si quieres configurar y gestionar tus nodos, GKE te ofrece el modo Estándar. Para obtener más información sobre las diferencias entre los modos, consulta Elegir un modo de funcionamiento del clúster.
En esta página se muestran estas funciones a través de varias topologías de implementación. Aprenderás a migrar una aplicación desplegada en un solo clúster de GKE a un despliegue multiclúster en clústeres Standard y Autopilot de GKE. Utiliza los servicios de varios clústeres de GKE para el tráfico este-oeste y las pasarelas de varios clústeres para habilitar la red norte-sur de varios clústeres.
Esta página está dirigida a arquitectos de la nube y equipos de operaciones que usan o tienen previsto usar GKE para desplegar servicios en varios clústeres de Kubernetes. Antes de leer esta página, asegúrate de que conoces Kubernetes.
Servicios y pasarelas de varios clústeres
Kubernetes puede ejecutarse con un único plano de control en distintas zonas de la nube para proporcionar resiliencia y mayor disponibilidad a tus servicios.
GKE va un paso más allá y proporciona servicios multiclúster (MCS) que ofrecen un mecanismo de descubrimiento e invocación de servicios entre clústeres.
Los servicios que usan esta función se pueden descubrir y acceder a ellos en todos los clústeres con una IP virtual, lo que coincide con el comportamiento de un ClusterIPservicio accesible en un clúster. Este enfoque ofrece las siguientes ventajas:
- Los servicios se pueden balancear entre varios clústeres de la misma región o de regiones diferentes (tráfico este-oeste).
- Se pueden conseguir opciones de alta disponibilidad de servicios entre regiones.
- Las cargas de trabajo con y sin reconocimiento del estado se pueden desplegar y gestionar en clústeres independientes.
- Los servicios compartidos están disponibles en todos los clústeres.
Para obtener más información sobre cómo implementar MCS, consulta Configurar servicios de varios clústeres.
GKE proporciona una implementación de la API Gateway de Kubernetes que usa el controlador Gateway de GKE. Gateway permite a GKE desplegar balanceadores de carga para proporcionar enrutamiento de tráfico entrante (norte-sur) a los servicios desplegados en GKE. Google Cloud GKE también proporciona pasarelas multiclúster (MCG), que amplían el controlador de pasarela de GKE para aprovisionar balanceadores de carga que enrutan el tráfico a servicios desplegados en clústeres de GKE distintos.
En el siguiente diagrama se muestra cómo, al combinar MCS y MCG, puedes gestionar los aspectos complementarios de la implementación de servicios y el enrutamiento del tráfico desde un único plano de control:
Para obtener más información, consulta Desplegar pasarelas de varios clústeres.
Información general sobre la migración
Las funciones de redes de varios clústeres de GKE benefician a las cargas de trabajo de varios perfiles. Por ejemplo, puede que tengas componentes sin estado con tráfico de ráfagas que quieras migrar a Autopilot debido a su modelo de costes más eficiente.
También puedes colocar los front-ends de tu aplicación más cerca de los usuarios. Este enfoque proporciona una latencia más baja y un almacenamiento en caché que mejora el rendimiento de las aplicaciones y la experiencia de usuario. Al mismo tiempo, es posible que tengas algunos componentes con estado de los que dependa tu aplicación y que solo puedan residir en una ubicación. Esta configuración requiere un balanceo de carga multiclúster de norte a sur para enviar el tráfico de los clientes al clúster correcto de esa ubicación. También necesitas un balanceo de carga entre clústeres y de este a oeste para enviar tráfico entre clústeres y llegar a los componentes con estado.
En esta página se usa la aplicación de demostración de microservicios en la nube Online Boutique para mostrar un patrón de varios clústeres que se puede usar para mejorar la implementación de la demostración de una sola zona. Empiezas con una versión de la aplicación de una sola zona. Después, añade elementos de alta disponibilidad y resiliencia mediante servicios y gateways multiclúster, y reduce el esfuerzo operativo aprovechando Autopilot.
Despliegue inicial de un solo clúster
En el siguiente diagrama, la aplicación Online Boutique se despliega inicialmente en un solo clúster en modo estándar de GKE llamado std-west y se expone mediante un LoadBalancer Service:
Migrar a servicios de varios clústeres
En el siguiente paso intermedio, crearás dos clústeres adicionales y los servicios sin estado se implementarán en regiones adicionales. Crea dos clústeres de Autopilot de GKE llamados auto-east y auto-central en dos regiones independientes del clúster estándar de GKE std-west y registra los clústeres en la Google Cloud flota.
Las flotas son un concepto para organizar de forma lógica clústeres y otros recursos, y te permiten usar y gestionar funciones de varios clústeres, así como aplicar políticas coherentes en tus sistemas. Google Cloud
Exporta el cartservice en el clúster std-west del espacio de nombres onlineboutique
a los nuevos clústeres de la flota mediante
ServiceExport.
Despliega el servicio frontend de Online Boutique en los tres clústeres y lo expone a través de un servicio ClusterIP. A continuación, exporta el servicio a la flota con ServiceExports.
Los servicios, como la capa intermedia de Online Boutique (por ejemplo, productcatalog, shipping y adservice), también se implementan en los tres clústeres.
Un Pod que se ejecuta en cualquier clúster de la flota puede acceder a un Service exportado
enviando una solicitud al URI ClusterSet de ese servicio. La solicitud
se dirige a un endpoint que respalda el servicio.
El servicio frontend puede consumir los servicios de middleware (como productcatalogservice o currencyservice) de forma local en el mismo clúster. Esta arquitectura ayuda a mantener las solicitudes entrantes en las regiones cuyo frontend responde a la solicitud y evita los cargos innecesarios por tráfico de red entre regiones.
En el siguiente diagrama se muestran los dos servicios multiclúster. El servicio frontend sin estado se despliega en tres clústeres, y el servicio cartservice con estado se despliega en un clúster. El diagrama también muestra que, en este paso intermedio, el tráfico entrante del servicio frontend sigue dirigiéndose al clúster estándar de GKE original en us-west1 mediante un balanceador de carga de red de transferencia externo creado por el servicio LoadBalancer frontend-external:
Migrar a una pasarela de varios clústeres
En el último paso, enruta el tráfico entrante del servicio frontend desde solicitudes de clientes externos a servicios de varios clústeres de la flota mediante una puerta de enlace multiclúster.
Se añade un cuarto clúster llamado config-central a la flota para alojar y gestionar la configuración de los recursos Gateway y HTTPRoute que se crean como parte de esta configuración. El recurso HTTPRoute
mapea el prefijo / al frontend
ServiceImport.
El tráfico del frontend de Online Boutique se envía a un endpoint en buen estado de una de las regiones disponibles. Este enfoque añade elementos de alta disponibilidad a la arquitectura de la aplicación Online Boutique.
En el siguiente diagrama, la puerta de enlace multiclúster implementa un balanceador de carga de Cloud global que enruta el tráfico externo al servicio frontend sin estado implementado en cada uno de los tres clústeres de aplicaciones de la flota.
En el estado final, este patrón basado en opiniones demuestra el acoplamiento flexible entre las partes con estado (cartservice y redis-cart) y sin estado de la aplicación (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice y adservice). Aunque no es el objetivo de esta página, este enfoque te ofrece la oportunidad de añadir resiliencia y alta disponibilidad a la capa de servicios con estado en el futuro.
Objetivos
- Crea y configura clústeres Standard y Autopilot de GKE.
- Despliega Online Boutique en un clúster de GKE Standard zonal.
- Exportar
Servicesde varios clústeres. - Despliega manifiestos en clústeres Standard y Autopilot.
- Habilita y configura pasarelas de varios clústeres.
- Prueba el comportamiento de la aplicación multirregional.
Costes
En este documento, se utilizan los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costes basada en el uso previsto,
utiliza la calculadora de precios.
Antes de empezar
Es posible que las restricciones de seguridad definidas por tu organización te impidan completar los siguientes pasos. Para obtener información sobre cómo solucionar problemas, consulta el artículo Desarrollar aplicaciones en un entorno limitado Google Cloud .
Antes de empezar, asegúrate de que cumples los siguientes requisitos:
- Te recomendamos que uses un proyecto nuevo para esta guía, ya que la forma más sencilla de limpiar es eliminar el proyecto cuando hayas terminado.
- En esta guía se presupone que tienes el rol Propietario de gestión de identidades y accesos de tuGoogle Cloud proyecto. En entornos de producción o reales, es recomendable limitar los permisos al mínimo necesario. Para obtener más información, consulta los artículos Usar la gestión de identidades y accesos de forma segura y Verificar explícitamente cada intento de acceso.
- Familiarízate con la arquitectura de la aplicación de demostración de microservicios Online Boutique.
Preparar el entorno
En esta guía, usarás Cloud Shell para introducir comandos. Cloud Shell te da acceso a la línea de comandos en laGoogle Cloud consola e incluye el SDK de Google Cloud y otras herramientas, como la CLI de Google Cloud. Cloud Shell aparece como una ventana en la parte inferior de la consolaGoogle Cloud . Puede tardar varios minutos en inicializarse, pero la ventana aparece inmediatamente.
In the Google Cloud console, activate Cloud Shell.
En Cloud Shell, define las variables de entorno que se usan en esta guía. Sustituye PROJECT_ID por el ID de tu proyecto:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Habilita los servicios necesarios para seguir los pasos de esta página:
gcloud services enable \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ dns.googleapis.com \ trafficdirector.googleapis.com \ cloudresourcemanager.googleapis.com \ multiclusterservicediscovery.googleapis.com \ container.googleapis.com gcloud container fleet multi-cluster-services enableMulti-cluster Services gestiona componentes como Cloud DNS, reglas de firewall y Cloud Service Mesh, por lo que estas APIs también deben estar habilitadas. Google Cloud Para obtener más información, consulta la información general sobre Cloud Service Mesh.
La salida es similar al siguiente ejemplo:
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.Comprueba que en Servicios de varios clústeres se muestra el estado ACTIVO:
gcloud container fleet multi-cluster-services describeLa salida es similar al siguiente ejemplo:
createTime: '2021-11-30T21:59:25.245190894Z' name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {} updateTime: '2021-11-30T21:59:27.459063070Z'Si el valor de state no es ACTIVE, consulta los detalles para solucionar problemas de servicios multiclúster.
Crea clústeres de GKE Standard y Autopilot:
gcloud container clusters create std-west \ --location us-west1-a \ --num-nodes=6 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --async gcloud container clusters create-auto auto-east \ --location us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --location us-central1 \ --release-channel regular \ --async gcloud container clusters create config-central \ --location us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --asyncWorkload Identity Federation for GKE está habilitado de forma predeterminada en los clústeres de GKE Autopilot, por lo que no tienes que usar la marca
--workload-poolcuando creas esos clústeres, como sí haces con los clústeres de GKE Standard.Espera a que el ESTADO de los clústeres cambie de PROVISIONING a RUNNING. Este proceso puede tardar hasta 10 minutos. Puedes monitorizar el progreso con un bucle de espera:
watch -n 20 --difference=permanent "gcloud container clusters list"La salida es similar al siguiente ejemplo:
NAME: auto-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 107.178.213.138 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: config-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 9 STATUS: PROVISIONING NAME: auto-east LOCATION: us-east1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.229.88.209 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: std-west LOCATION: us-west1-a MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.197.93.113 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 6 STATUS: PROVISIONINGCuando todos los clústeres estén en el estado RUNNING, pulsa
CTRL-Cpara interrumpir el comando.Añade una vinculación de política de gestión de identidades y accesos (IAM) que conceda a la cuenta de servicio de MCS del proyecto host de la flota el rol Usuario de red en su propio proyecto:
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"Usa Workload Identity Federation para GKE para conceder al servicio MCS acceso de lectura a la configuración de la red VPC de tu proyecto. Por lo tanto, la cuenta de servicio Importer GKE de MCS del proyecto host de la flota necesita este rol.
La salida es similar al siguiente ejemplo:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]Registra los clústeres Estándar y Autopilot de GKE en la flota de tu proyecto. Consulta más información en Registrar un clúster. Este paso puede tardar hasta 5 minutos:
gcloud container fleet memberships register std-west \ --gke-cluster us-west1-a/std-west \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-east \ --gke-cluster us-east1/auto-east \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-central \ --gke-cluster us-central1/auto-central \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register config-central \ --gke-cluster us-central1/config-central \ --enable-workload-identity \ --project=${PROJECT}En cada comando, el resultado es similar al siguiente ejemplo:
Waiting for membership to be created...done. Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west] Generating the Connect Agent manifest... Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]... Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect]. Finished registering the cluster [std-west] with the Hub.Conéctate a los clústeres y genera entradas kubeconfig:
gcloud container clusters get-credentials std-west \ --location us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --location us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --location us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --location us-central1 --project $PROJECTEn cada comando, el resultado es similar al siguiente ejemplo:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.Cambia el nombre de los contextos de los clústeres para que sea más fácil trabajar con ellos en el resto de esta página:
kubectl config rename-context \ gke_${PROJECT}_us-west1-a_std-west \ std-west kubectl config rename-context \ gke_${PROJECT}_us-east1_auto-east \ auto-east kubectl config rename-context \ gke_${PROJECT}_us-central1_auto-central \ auto-central kubectl config rename-context \ gke_${PROJECT}_us-central1_config-central \ config-centralEn esta guía, los contextos se denominan según su ubicación. Aunque puedes proporcionar nombres alternativos, en el resto de los pasos de esta guía se utilizan los nombres que se han indicado en este paso.
Crea el espacio de nombres onlineboutique en std-west:
kubectl create namespace onlineboutique --context std-westLa salida es similar al siguiente ejemplo:
namespace/onlineboutique createdClona el repositorio de GitHub de Online Boutique y configura una variable WORKDIR:
cd ~ git clone --branch release/v0.4.1 \ https://github.com/GoogleCloudPlatform/microservices-demo.git cd microservices-demo/release && export WORKDIR=`pwd`Despliega Online Boutique en std-west. Este proceso crea
DeploymentsyServicespara todos los microservicios de Online Boutique e incluye un servicio de tipo LoadBalancer que expone externamente el servicio frontend de Online Boutique:cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-westEspera a que el servicio
LoadBalancerobtenga una IP externa:watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"Al principio, el resultado es similar al siguiente ejemplo:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sCuando
Serviceesté listo, en la columna EXTERNAL-IP se mostrará la dirección IP pública del balanceador de carga.Cuando el
Serviceesté listo, obtén la dirección IP externa del balanceador de carga y usa curl para verificar que el frontend esté listo. Si este comando curl devuelve un error, espera unos instantes antes de volver a intentarlo:curl $(kubectl get svc frontend-external \ -n onlineboutique --context=std-west \ -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \ grep -e Cluster -e Zone -e PodEl resultado correcto del comando curl es similar al siguiente ejemplo:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjskCrea el espacio de nombres onlineboutique en los clústeres restantes:
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralEn cada comando, el resultado es similar al siguiente ejemplo:
namespace/onlineboutique createdExporta cartservice del clúster std-west a todos los demás clústeres de
ClusterSet. El objetoServiceExportregistra el servicio cartservice con los servicios multiclúster de GKE para exportarlo a todos los clústeres de la flota que tengan el espacio de nombres onlineboutique. Para obtener más información, consulta el artículo sobre registrar un servicio para la exportación.cat <<EOF>> $WORKDIR/cartservice-export.yaml kind: ServiceExport apiVersion: net.gke.io/v1 metadata: namespace: onlineboutique name: cartservice EOF kubectl apply -f $WORKDIR/cartservice-export.yaml \ -n onlineboutique --context=std-west- El primer archivo de manifiesto se usa para el frontend
Deployment,ServiceyServiceExport. - El segundo manifiesto se usa para implementar el middleware
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice y adservice) en todas las regiones en las que se ejecute un frontend. Si mantienes una solicitud local en una región el mayor tiempo posible, evitarás cargos innecesarios por el tráfico de red entre regiones. Define una variable de entorno para el repositorio de GitHub que contenga los manifiestos:
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migrationAplica los manifiestos para desplegar la capa frontend en los tres clústeres de carga de trabajo:
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-centralAplica los manifiestos para desplegar la capa intermedia en los tres clústeres de carga de trabajo:
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-centralConfirma que todos los clústeres se han registrado correctamente en la flota:
gcloud container fleet memberships list --project=$PROJECTEn el siguiente ejemplo de salida se muestra que todos los clústeres se han registrado correctamente:
NAME: auto-central EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f NAME: config-central EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98 NAME: std-west EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3 NAME: auto-east EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012Instala la definición de recurso personalizado de la API Gateway en el clúster config-central:
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \ | kubectl apply -f -En este paso se instalan las definiciones de recursos personalizados de la API Gateway, incluidos los recursos
GatewayClass,GatewayyHTTPRoute. Las definiciones de recursos personalizados las mantiene el grupo de interés especial de redes de Kubernetes. Una vez instalado, puedes usar el controlador de GKE Gateway.Habilita Multi Cluster Ingress en tu flota si aún no lo has hecho. Si habilitas esta función, también se habilitará el controlador de pasarela de varios clústeres.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTLa salida es similar al siguiente ejemplo:
createTime: '2021-12-08T23:10:52.505888854Z' name: projects/PROJECT_ID/locations/global/features/multiclusteringress resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central state: state: code: OK description: Ready to use updateTime: '2021-12-08T23:11:37.994971649Z' updateTime: '2021-12-08T23:11:38.098244178Z'Si el valor de state no es ACTIVE, consulta Solución de problemas y operaciones de Multi Cluster Ingress.
Confirma que
GatewayClassesestén disponibles en el clúster config-central:kubectl get gatewayclasses --context=config-centralLa salida es similar al siguiente ejemplo:
NAME CONTROLLER AGE gke-l7-global-external-managed networking.gke.io/gateway 18s gke-l7-global-external-managed-mc networking.gke.io/gateway 19s gke-l7-regional-external-managed networking.gke.io/gateway 18s gke-l7-regional-external-managed-mc networking.gke.io/gateway 19s gke-l7-gxlb networking.gke.io/gateway 74s gke-l7-gxlb-mc networking.gke.io/gateway 16s gke-l7-rilb networking.gke.io/gateway 74s gke-l7-rilb-mc networking.gke.io/gateway 16sLos distintos recursos de
GatewayClasstienen diferentes funciones. Para obtener más información sobre cuándo usar cada tipo, consulta Funciones de GatewayClass.Despliega el recurso de pasarela
external-httpenconfig-central:cat <<EOF>> $WORKDIR/external-http-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: external-http namespace: onlineboutique spec: gatewayClassName: gke-l7-global-external-managed-mc listeners: - protocol: HTTP port: 80 name: http EOF kubectl apply -f external-http-gateway.yaml \ -n onlineboutique --context=config-centralComo indica el campo
gatewayClassName, este recurso es deGatewayClassgke-l7-global-external-managed-mc, que gestiona el balanceo de carga de Cloud externo de la capa 7 y expone la aplicación multiclústerDespliega el
HTTPRoutellamado public-frontend-route en config-central:cat <<EOF>> $WORKDIR/public-frontend-route.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: public-frontend-route namespace: onlineboutique spec: parentRefs: - name: "external-http" hostnames: - "store.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: frontend group: net.gke.io kind: ServiceImport port: 80 EOF kubectl apply -f public-frontend-route.yaml \ -n onlineboutique --context=config-centralCuando despliega el recurso
HTTPRoute, se crea un recurso de balanceo de carga de capa 7 externo y se expone el frontendServiceImportrespaldado por los servicios de frontend que se ejecutan en los clústeres std-west, auto-east y auto-central.En el siguiente diagrama se muestra cómo, una vez desplegada la pasarela de varios clústeres, el tráfico se puede enrutar a cualquiera de los servicios de varios clústeres de frontend de cualquiera de los tres clústeres de aplicaciones:
Espera a que el balanceador de carga esté listo con una dirección IP externa aprovisionada antes de continuar con el siguiente paso. La dirección IP puede tardar hasta 10 minutos en asignarse. Puedes monitorizar el progreso usando un bucle de reloj. El balanceador de carga tiene un nombre con un patrón como gkemcg-onlineboutique-external-http-k09mfhk74gop:
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"La salida es similar al siguiente ejemplo:
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gopCuando el balanceador de carga esté listo, ejecuta el siguiente comando en Cloud Shell para exportar la dirección IP externa del balanceador de carga creado mediante la aplicación de los manifiestos external-http-gateway.yaml y public-frontend-route.yaml:
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')Cuando envías una solicitud al balanceador de carga con los encabezados adecuados, devuelve el contenido HTML que sirve el servicio frontend. Por ejemplo, como has configurado el recurso
HTTPRoutepara asignar el nombre de hoststore.example.comalServiceImportfrontend, debes proporcionar el encabezadoHOSTcuando hagas la solicitud HTTP. Si el siguiente ejemplo de curl devuelve un error, espera unos minutos y vuelve a intentarlo:curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodEl resultado correcto del comando curl es similar al siguiente ejemplo:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8fCrea los pods de cliente:
kubectl run --context=std-west \ --image=radial/busyboxplus:curl client-west \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-east \ --image=radial/busyboxplus:curl client-east \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-central \ --image=radial/busyboxplus:curl client-central \ -- sh -c 'while sleep 3600; do :; done'Una vez que los pods estén en funcionamiento, usa un comando curl para enviar una solicitud al endpoint del balanceador de carga desde el cliente
Poddel clúster std-west y revisa la respuesta:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodEl resultado correcto del comando curl es similar al siguiente ejemplo:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Ejecuta la misma solicitud curl desde el cliente
Poden el clúster auto-east y consulta la respuesta:kubectl exec -it --context=auto-east client-east \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodEl resultado correcto del comando curl es similar al siguiente ejemplo:
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsComo se trata de un clúster de Autopilot, es posible que el clúster tenga que aprovisionar recursos adicionales para programar el
Pod. Si ves un resultado similar al del ejemplo siguiente, espera un momento y vuelve a intentarlo:Error from server (BadRequest): pod client-east does not have a host assignedEjecuta el comando curl desde el cliente
Poden el clúster auto-central y comprueba la respuesta:kubectl exec -it --context=auto-central client-central \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodEl resultado correcto del comando curl es similar al siguiente ejemplo:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4Estos resultados confirman que el tráfico se dirige a los pods correspondientes en las ubicaciones más cercanas al origen de la solicitud.
Ejecuta el comando curl desde el cliente-oeste
Poddel clúster std-oeste y comprueba que el resultado procede del frontend de us-west1:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodEl resultado correcto del comando curl es similar al siguiente ejemplo:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Elimina el frontend
Deploymentdel clúster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westLa salida es similar al siguiente ejemplo:
deployment.apps "frontend" deletedEnvía otra solicitud desde el cliente-oeste
Poddel clúster std-oeste. Deberías ver una respuesta de uno de los frontendDeploymentsrestantes, que se encuentra en los clústeres auto-east o auto-central:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodUn resultado similar al siguiente ejemplo indica la ubicación del
Podcorrecto que responde a esta solicitud:<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4o
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsEjecuta el comando varias veces para ver resultados alternativos.
Crear y configurar clústeres de GKE
Para demostrar el patrón de varios clústeres en esta guía, se utilizan tres clústeres de aplicaciones en tres regiones de nube independientes y un clúster para alojar la configuración de los recursos de Gateway. Registra todos los clústeres en la flota asociada a tu proyecto. Un proyecto de Google Cloud solo puede tener una flota asociada. Este proyecto se conoce como proyecto host de la flota.
Desplegar Online Boutique en GKE Standard
En el primer paso del despliegue de demostración, desplegarás el conjunto completo de servicios de la aplicación Online Boutique en el clúster estándar de GKE std-west en us-west1.
Ahora tienes una versión de una sola zona de Online Boutique que se ejecuta en us-west1-a.
También puedes usar un navegador web para ir a la IP externa asignada al servicio frontend-external LoadBalancer para acceder a la aplicación y observar su comportamiento. Esta implementación inicial se muestra en el siguiente diagrama:
Exportar cartservice como un servicio de varios clústeres
En esta sección, empezarás a añadir elementos de alta disponibilidad a la aplicación. Exporta el backend cartservice como un servicio multiclúster a los clústeres de Autopilot de GKE.
Aplicar manifiestos de aplicaciones para el patrón de varios clústeres
En esta sección, aplicarás dos manifiestos seleccionados para desplegar el patrón multiclúster. Estos manifiestos contienen partes seleccionadas del archivo kubernetes-manifests.yaml que aplicaste anteriormente al clúster std-west:
Un Pod que se ejecuta en cualquier clúster de la flota puede acceder a un Service exportado
enviando una solicitud al URI ClusterSet de ese servicio con el formato
SERVICE_NAME.NAMESPACE.svc.clusterset.local. Por ejemplo, el frontend
Deployments de los tres clústeres de ejemplo puede consumir el cartservice del espacio de nombres onlineboutique haciendo una solicitud a cartservice.onlineboutique.svc.clusterset.local.
Por este motivo, en cada archivo de manifiesto, el nombre de host de cartservice se ha actualizado a su URI ClusterSet. Este paso es fundamental. Si el nombre de host de este servicio no se actualiza, el servicio frontend pedirá a kube-dns cartservice
en lugar de cartservice.onlineboutique.svc.clusterset.local. Este comportamiento provocaría errores de HTTP Status 500 en los clústeres en los que no estuviera disponible una versión local de cartservice y haría que los pods de frontend no estuvieran en buen estado.
Ahora tienes los frontend Deployment, Service y ServiceExport activos en los clústeres std-west, auto-east y auto-central. También tienes servicios de middleware de Online Boutique que se ejecutan localmente en cada clúster. Sin embargo, el tráfico externo sigue dirigiéndose únicamente al Service que se ejecuta en el clúster inicial de us-west1, tal como se muestra en el siguiente diagrama:
Habilitar y configurar pasarelas de varios clústeres
En esta sección, dirigirá el tráfico y balanceará la carga del tráfico externo entre los frontend de los tres clústeres. Para conseguir esta configuración, debes usar pasarelas multiclúster (MCG). Estos pasos para configurar MCG siguen las directrices que se describen con más detalle en el artículo Habilitar pasarelas de varios clústeres.
En estos pasos, se usa el clúster config-central para alojar la configuración de los recursos de Gateway.
Probar el comportamiento de enrutamiento multirregional de la aplicación
Una de las potentes funciones que se obtienen al usar servicios y pasarelas de varios clústeres es que las solicitudes externas se enrutan al clúster geográficamente más cercano.
Para probar el comportamiento multirregional de la aplicación, genera tráfico procedente de las distintas regiones en las que hayas desplegado clústeres. Crea tres pods pequeños, uno en cada uno de los clústeres de servicio (std-west, auto-east y auto-central), que puedes usar para enviar solicitudes HTTP al endpoint del balanceador de carga. Los resultados te permiten ver qué frontend Pod responde.
Probar la resiliencia multirregional de una aplicación
Además de enrutar el tráfico de forma eficiente, ejecutar tus servicios en varias regiones te proporciona resiliencia en el caso, poco probable pero posible, de que se produzca un fallo en la infraestructura.
Prueba el comportamiento eliminando el frontend Deployments en clústeres específicos
y, a continuación, vuelve a intentar ejecutar el comando curl desde el cliente Pod en esas regiones. Observa que la aplicación sigue disponible y mira la ubicación del Pod
que responde a la solicitud.
Con esta implementación de demostración, has añadido elementos de resiliencia y distribución geográfica a la aplicación Online Boutique mediante servicios y pasarelas de varios clústeres. Las solicitudes se enrutan a la región geográfica más cercana y, aunque los servicios de frontend o middleware de una región tengan problemas, el usuario final podrá seguir usando la aplicación correctamente.
Limpieza
Para evitar que los recursos utilizados en este tutorial se cobren en tu cuenta de Google Cloud, elimina el proyecto que contiene los recursos o conserva el proyecto y elimina los recursos.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Siguientes pasos
- Consulta más información sobre la Google Cloud gestión de flotas y de varios clústeres.
- Consulta cómo registrar un clúster, incluidos los clústeres de GKE, en una Google Cloud flota.
- Consulta más información sobre la API de Kubernetes Gateway y GKE Gateway.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.