Las redes de varios clústeres son una herramienta valiosa que habilita casos de uso como la alta disponibilidad regional, la proximidad distribuida globalmente a los usuarios para lograr una menor latencia y el aislamiento organizativo entre equipos. Google Kubernetes Engine (GKE) proporciona funciones integradas para las redes de varios clústeres que puedes habilitar y usar a gran escala en una flota de clústeres de GKE. Esta función también te permite combinar GKE Standard y Autopilot, o migrar la infraestructura implementada entre ambos, para satisfacer las necesidades de arquitectura de cada aplicación.
En este documento, se muestran estas funciones a través de varias topologías de implementación. Aprenderás a tomar una aplicación implementada en un clúster de GKE único y migrarla a una implementación de varios clústeres de GKE Standard y Autopilot. Usa los Services de varios clústeres de GKE para el tráfico de este a oeste y Gateways de varios clústeres a fin de habilitar las redes de norte a sur de varios clústeres.
El documento está dirigido a los arquitectos de nube y equipos de operaciones que usan o planean usar GKE para implementar servicios en varios clústeres de Kubernetes. En este documento, se da por sentado que estás familiarizado con Kubernetes.
GKE Standard y GKE Autopilot
GKE proporciona una implementación de Kubernetes administrada con un conjunto de funciones completo, incluido un plano de control de alta disponibilidad. Los clústeres de GKE se pueden iniciar con rapidez y escalar hasta 15,000 nodos. Con los clústeres de Autopilot de GKE, Google administra la infraestructura, incluidos el plano de control y los nodos. Si, en cambio, deseas configurar y administrar tus nodos, GKE proporciona el modo Standard.
Para obtener más información sobre las diferencias entre modos, consulta Elige un modo de operación de clúster.
Services de varios clústeres y Gateways de varios clústeres
Kubernetes puede ejecutarse mediante un solo plano de control en diversas zonas de la nube para proporcionar resiliencia y mayor disponibilidad a tus servicios.
GKE va un paso más allá y proporciona Services de varios clústeres (MCS) de GKE que proporciona un mecanismo de invocación y descubrimiento de servicios entre clústeres.
Los Services que usan esta función son detectables y son accesibles en todos los clústeres con una IP virtual, que coincide con el comportamiento de un Service ClusterIP accesible en un clúster. Este enfoque tiene los siguientes beneficios:
- Los Services pueden tener balanceo de cargas en varios clústeres de la misma región o en regiones diferentes (tráfico de este a oeste).
- Se pueden lograr opciones de alta disponibilidad entre servicios de varias regiones.
- Las cargas de trabajo con estado y sin estado se pueden implementar y administrar 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 Configura servicios de varios clústeres.
GKE proporciona una implementación de la API de Gateway de Kubernetes que usa el controlador de Gateway de GKE. Gateway permite que GKE implemente balanceadores de cargas de Google Cloud a fin de proporcionar enrutamiento de tráfico entrante (de norte a sur) para los servicios implementados en GKE. GKE también proporciona Gateways de varios clústeres (MCG) que extienden el controlador de Gateway de GKE para aprovisionar balanceadores de cargas que enruten el tráfico a los servicios implementados en clústeres diversos de GKE.
En el siguiente diagrama, se muestra cómo, cuando combinas MCS y MCG, puedes administrar los aspectos complementarios de la implementación de servicios y el enrutamiento de tráfico desde un solo plano de control:
Para obtener más información, consulta Implementa Gateways de varios clústeres.
Descripción general de la migración
Las funciones de redes de varios clústeres de GKE benefician a las cargas de trabajo de varios perfiles. Por ejemplo, es posible que tengas componentes sin estado con tráfico inestable que desees pasar a Autopilot debido a su modelo de costos más eficiente.
O bien, puede que quieras colocar los frontends de tu aplicación más cerca de los usuarios. Este enfoque proporciona una latencia menor y un almacenamiento en caché que mejora el rendimiento de la aplicación y la experiencia del usuario. Al mismo tiempo, es posible que tengas algunos componentes con estado de los que depende tu aplicación que solo puedan residir en una ubicación. Esta configuración requiere que el balanceo de cargas de varios clústeres de norte a sur envíe tráfico de cliente al clúster correcto en esa ubicación. También necesitas que el balanceo de cargas de varios clústeres de este a oeste envíe tráfico entre clústeres a fin de llegar a los componentes con estado.
En este documento, se usa la aplicación de demostración de microservicios en la nube Online Boutique a fin de demostrar un patrón de varios clústeres que se puede usar para mejorar la implementación de la demostración de zona única. Comienzas con una versión de zona única de la aplicación. Luego, debes agregar elementos de alta disponibilidad y resiliencia mediante Services de varios clústeres y Gateways de varios clústeres. Además, debes aprovechar Autopilot para reducir el trabajo repetitivo de la operación.
Implementación inicial en un solo clúster
En el siguiente diagrama, la aplicación Online Boutique se implementa inicialmente en un solo clúster del modo Standard de GKE llamado std-west y se expone mediante un Service LoadBalancer:
Migra a Services 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. Crearás dos clústeres de GKE Autopilot llamados auto-east y auto-central en dos regiones diferentes, distintas del clúster de GKE Standard std-west, y registrarás los clústeres en la flota de Google Cloud.
Las flotas son un concepto de Google Cloud que organiza de manera lógica los clústeres y otros recursos que te permiten usar y administrar funciones de varios clústeres y aplicar políticas coherentes en tus sistemas.
Debes exportar cartservice en el clúster std-west en el espacio de nombres onlineboutique a los nuevos clústeres de flota mediante el uso de ServiceExport.
Debes implementar el Service de frontend de Online Boutique en los tres clústeres y exponerlo a través de un servicio ClusterIP. Luego, exportas el Service a la flota mediante ServiceExports.
Los Services como la capa middleware de Online Boutique (como 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 mediante el envío de una solicitud al URI ClusterSet para ese Service. La solicitud se enruta a un extremo que respalda el Service.
El Service de frontend puede consumir los Services de middleware (como productcatalogservice o currencyservice) de forma local en el mismo clúster. Esta arquitectura ayuda a mantener las solicitudes entrantes locales en las regiones cuyo frontend responde a la solicitud y evita los cargos innecesarios de tráfico de red interregional.
En el siguiente diagrama, se ilustran los dos Services de varios clústeres. El Service de frontend sin estado se implementa en tres clústeres y el backend con estado cartservice se implementa en un clúster. En el diagrama, también se muestra que en este paso intermedio, el tráfico entrante para el servicio de frontend permanece enrutado al clúster de GKE Standard original en us-west1 mediante un balanceador de cargas de red de transferencia externo creado por el Service LoadBalancer de frontend externo:
Migra a Gateway de varios clústeres
En el paso final, enrutas el tráfico entrante para el Service de frontend desde las solicitudes de clientes externos a servicios en varios clústeres de la flota mediante una Gateway de varios clústeres.
Un cuarto clúster llamado config-central se agrega a la flota para alojar y administrar la configuración de los recursos Gateway y HTTPRoute que se crean como parte de esta configuración. El recurso HTTPRoute asigna el prefijo / al ServiceImport de frontend.
El tráfico del frontend de Online Boutique se envía a un extremo en buen estado en una de las regiones disponibles. Este enfoque agrega elementos de alta disponibilidad a la arquitectura de la aplicación de Online Boutique.
En el siguiente diagrama, la Gateway de varios clústeres implementa un balanceador de cargas global de Cloud que enruta el tráfico externo al Service de frontend sin estado implementado en cada uno de los tres clústeres de aplicación en la flota.
En el estado final, este patrón bien definido demuestra el acoplamiento bajo entre las porciones con estado (cartservice y redis-cart) y sin estado de la aplicación (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice y adservice). Si bien está fuera del alcance de este documento, este enfoque te brinda una oportunidad futura de agregar resiliencia y alta disponibilidad a la capa de Services con estado.
Objetivos
- Crear y configurar clústeres de GKE Standard y Autopilot.
- Implementar Online Boutique en un clúster zonal de GKE Standard.
- Exportar
Servicesde varios clústeres. - Implementar manifiestos en clústeres Standard y Autopilot.
- Habilitar y configurar Gateways de varios clústeres.
- Probar el comportamiento de la aplicación multirregional.
Costos
En este documento, usarás los siguientes componentes facturables de Google Cloud:
- GKE
- Compute Engine para los nodos trabajadores de GKE
- Cloud Load Balancing
- Entrada de varios clústeres
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Antes de comenzar
Es posible que las restricciones de seguridad que define tu organización no te permitan completar los siguientes pasos. Para obtener información sobre la solución de problemas, consulta Desarrolla aplicaciones en un entorno de Google Cloud restringido.
Antes de comenzar, asegúrate de cumplir con los siguientes requisitos:
- Se recomienda que uses un proyecto nuevo para esta guía, ya que la forma más fácil de realizar una limpieza es borrar el proyecto una vez que termines.
- En esta guía, se supone que tienes el rol Owner de IAM para tu proyecto de Google Cloud. Para la configuración del entorno de producción o del mundo real, se recomienda definir permisos con privilegio mínimo. Si deseas obtener más información, consulta Usa IAM de forma segura y Administra la identidad y el acceso.
- Familiarízate con la arquitectura de aplicaciones de demostración de microservicios de Online Boutique.
Prepare el entorno
En este instructivo, usarás Cloud Shell para ingresar comandos. Cloud Shell te brinda acceso a la línea de comandos en la consola de Google Cloud e incluye el SDK de Google Cloud y otras herramientas, como Google Cloud CLI. Cloud Shell aparece como una ventana en la parte inferior de la consola de Google Cloud. Es posible que la inicialización tome unos minutos, pero la ventana aparecerá de inmediato.
En la consola de Google Cloud, activa Cloud Shell.
En Cloud Shell, define las variables de entorno que se usan en esta guía. Reemplaza PROJECT_ID por el ID de tu proyecto:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Habilita los servicios necesarios para este documento:
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 enableLos Services de varios clústeres administran los componentes de Google Cloud, como Cloud DNS, las reglas de firewall y Traffic Director, por lo que estas API también deben estar habilitadas. Para obtener más información, consulta Descripción general de Traffic Director.
El resultado 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.Verifica que los Services de varios clústeres muestren el estado ACTIVE:
gcloud container fleet multi-cluster-services describeEl resultado 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 la sección de solución de problemas de la documentación de MCS.
Crea y configura clústeres de GKE
A fin de demostrar el patrón de varios clústeres en esta guía, debes usar tres clústeres de aplicación en tres regiones de nube separadas y un clúster para alojar la configuración para recursos Gateway. Registra todos los clústeres con la flota asociada con tu proyecto. Un proyecto de Cloud solo puede tener una flota asociada. Este proyecto se conoce como el proyecto host de la flota.
Crea clústeres de GKE Standard y Autopilot:
gcloud container clusters create std-west \ --zone 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 \ --region us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --region us-central1 \ --release-channel regular \ --async gcloud container clusters create config-central \ --region us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --asyncLa federación de identidades para cargas de trabajo para GKE está habilitada de forma predeterminada en los clústeres de Autopilot de GKE para que no tengas que usar la marca
--workload-poolcuando creas esos clústeres como lo haces con los clústeres de GKE Standard.Espera a que el STATUS del clúster cambie de PROVISIONING a RUNNING. Este proceso puede tardar hasta 10 minutos. Para supervisar el progreso, puedes usar un bucle de observación mientras bebes un café o haces ejercicios suaves de estiramiento antes de continuar con el resto del documento:
watch -n 20 --difference=permanent "gcloud container clusters list"El resultado 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: PROVISIONINGUna vez que todos los clústeres estén en el estado RUNNING, presiona
CTRL-Cpara interrumpir el comando.Agrega una vinculación de política de Identity and Access Management (IAM) que otorgue a la cuenta de servicio de MCS del proyecto host de la flota el rol Network User para 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 la federación de identidades para cargas de trabajo para GKE para otorgar al servicio de MCS acceso de lectura a la configuración de la red de VPC de tu proyecto. Como resultado, la cuenta de servicio de importador de GKE de MCS del proyecto host de la flota necesita este rol.
El resultado 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 de GKE Standard y Autopilot en la flota de tu proyecto. Consulta Registra un clúster para obtener más detalles. Esta acción 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}Para 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 de kubeconfig:
gcloud container clusters get-credentials std-west \ --zone us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --region us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --region us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --region us-central1 --project $PROJECTPara 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 a fin de facilitar el trabajo con ellos en el resto de este documento:
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 nombran según su ubicación. Aunque puedes proporcionar nombres alternativos, en los pasos restantes de esta guía se usan los nombres usados en este paso.
Implementa Online Boutique en GKE Standard
En el primer paso de la implementación de demostración, implementarás el conjunto completo de servicios de la aplicación Online Boutique en el único clúster de GKE Standard std-west en us-west1.
Crea el espacio de nombres onlineboutique en std-west:
kubectl create namespace onlineboutique --context std-westEl resultado 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`Implementa Online Boutique en std-west. Este proceso crea
DeploymentsyServicespara todos los microservicios de Online Boutique e incluye un Service de tipo LoadBalancer que expone de forma externa el Service de frontend de Online Boutique:cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-westEspera a que el Service
LoadBalancerobtenga una IP externa:watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"Inicialmente, 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, la columna EXTERNAL-IP muestra la dirección IP pública del balanceador de cargas.Una vez que
Serviceesté listo, obtén la dirección IP externa del balanceador de cargas y usa curl para verificar que el frontend esté listo. Si este comando curl muestra un error, espera unos minutos 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-wdjsk
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 navegar a la IP externa asignada al Service de LoadBalancer frontend-external a fin de acceder a la aplicación y observar su comportamiento. Esta implementación única inicial se muestra en el siguiente diagrama:
Exporta cartservice como un Service de varios clústeres
En esta sección, comenzarás a agregar elementos de alta disponibilidad a la aplicación. Exportas el cartservice de backend como un Service de varios clústeres a los clústeres de GKE Autopilot.
Crea 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-centralPara cada comando, el resultado es similar al siguiente ejemplo:
namespace/onlineboutique createdExporta cartservice desde el clúster std-west a todos los otros clústeres en
ClusterSet. El objetoServiceExportregistra el Service cartservice, con Services de varios clústeres de GKE, para la exportación a todos los clústeres de la flota que tienen el espacio de nombres onlineboutique presente. A fin de obtener más detalles, consulta registra 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
Aplica manifiestos de aplicaciones para el patrón de varios clústeres
En esta sección, aplicarás dos manifiestos seleccionados para implementar el patrón de varios clústeres. Estos manifiestos contienen porciones seleccionadas del kubernetes-manifests.yaml que aplicaste antes al clúster std-west:
- El primer manifiesto se usa para
Deployment,ServiceyServiceExportdel frontend. - El segundo manifiesto se usa para implementar los
Servicesde middleware (emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice y adservice) a todas las regiones que tienen un frontend en ejecución. Si mantienes una solicitud local en una región el mayor tiempo posible, evitas los cargos innecesarios de tráfico de red interregional.
Un Pod que se ejecuta en cualquier clúster de la flota puede acceder a un Service exportado mediante el envío de una solicitud al URI de ClusterSet para ese Service en el formato SERVICE_NAME.NAMESPACE.svc.clusterset.local. Por ejemplo, Deployments del frontend en los tres clústeres de ejemplo pueden consumir cartservice, en el espacio de nombres onlineboutique, mediante una solicitud a cartservice.onlineboutique.svc.clusterset.local.
Por este motivo, en cada manifiesto, el nombre de host para cartservice se actualizó a su URI de ClusterSet. Este paso es fundamental. Si este nombre de host del servicio no se actualiza, el Service del frontend le pedirá a kube-dns cartservice en lugar de cartservice.onlineboutique.svc.clusterset.local. Este comportamiento generaría errores HTTP Status 500 en clústeres en los que una versión local de cartservice no está disponible y hace que los Pods del frontend estén en mal estado.
Configura un entorno variable 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 implementar la capa de 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 implementar la capa de middleware 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-central
Ahora tienes Deployment, Service y ServiceExport del frontend activos en clústeres std-west, auto-east y auto-central. También tienes servicios de middleware de Online Boutique que se ejecutan de manera local en cada clúster. Sin embargo, el tráfico externo aún se enruta solo al Service que se ejecuta en el clúster inicial en us-west1, como se muestra en el siguiente diagrama:
Habilita y configura Gateways de varios clústeres
En esta sección, enrutarás el tráfico externo a los frontends y balancerás las cargas del tráfico externo entre frontends en los tres clústeres. Para lograr esta configuración, debes usar Gateways de varios clústeres (MCG). En este documento, se siguen las instrucciones para configurar MCG como se describe en Habilita Gateways de varios clústeres.
En esta guía, usarás el clúster config-central para alojar la configuración de los recursos de Gateway.
Confirma que todos los clústeres se hayan registrado de forma correcta en la flota:
gcloud container fleet memberships list --project=$PROJECTEn el siguiente resultado de ejemplo, se muestra que todos los clústeres se registraron de forma correcta:
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 personalizada de recursos de la API de 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 de Gateway, incluidos los recursos
GatewayClass,GatewayyHTTPRoute. El grupo de interés especial de la red de Kubernetes mantiene las definiciones de recursos personalizados. Una vez instalado, puedes usar el controlador de Gateway de GKE.Habilita Ingress de varios clústeres para tu flota si aún no lo has hecho. Cuando habilitas esta función, también se habilita el controlador de puertas de enlace de varios clústeres.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTEl resultado 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 para Ingress de varios clústeres.
Confirma que
GatewayClassesestén disponibles en el clúster config-central:kubectl get gatewayclasses --context=config-centralEl resultado 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 diferentes recursos
GatewayClasstienen funciones diferentes. Para obtener más información sobre cuándo usar qué tipo, consulta Funciones de GatewayClass.Implementa el recurso de Gateway
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 lo indica el campo
gatewayClassName, este recurso es deGatewayClassgke-l7-global-external-managed-mc que administra Cloud Load Balancing externo de capa 7 y expone la aplicación de varios clústeres.Implementa el recurso
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 implementas el recurso
HTTPRoute, crea un recurso externo de capa 7 de Cloud Load Balancing y expone elServiceImportdel frontend con el respaldo de 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, después de implementar la Gateway de varios clústeres, el tráfico se puede enrutar a cualquiera de los Services de varios clústeres de frontend en cualquiera de los tres clústeres de aplicaciones:
Espera a que el balanceador de cargas 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 supervisar el progreso mediante un bucle de observación. El balanceador de cargas tiene un nombre en el patrón como gkemcg-onlineboutique-external-http-k09mfhk74gop:
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"El resultado 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-k09mfhk74gopUna vez que el balanceador de cargas esté listo, ejecuta el siguiente comando en Cloud Shell para exportar la dirección IP externa del balanceador de cargas 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 cargas con los encabezados adecuados, se muestra el contenido HTML que entrega el Service de frontend. Por ejemplo, dado que configuraste el recurso
HTTPRoutepara asignar el nombre de hoststore.example.comalServiceImportde frontend, debes proporcionar el encabezadoHOSTcuando realizas la solicitud HTTP. Si en el siguiente ejemplo con curl se muestra 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-jdh8f
Prueba el comportamiento de enrutamiento multirregión
Una de las funciones potentes que se obtienen mediante el uso de Services de varios clústeres y Gateways de varios clústeres es que las solicitudes externas se enrutan al clúster más cercano geográficamente.
Para probar el comportamiento multirregional de la aplicación, genera tráfico que se origine en las diversas regiones en las que implementaste los clústeres. Crea tres pods pequeños, uno en cada uno de los clústeres de entrega (std-west, auto-east y auto-central), que puedes usar para enviar solicitudes HTTP al extremo del balanceador de cargas. Los resultados te permiten ver qué Pod de frontend responde.
Crea los Pods 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'Después de que los Pods se ejecuten, usa un comando curl para enviar una solicitud al extremo del balanceador de cargas desde el cliente
Poden el 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
Podcliente en el clúster auto-east y observa 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 este es un clúster de Autopilot, es posible que el clúster deba aprovisionar recursos adicionales para programar el
Pod. Si ves un resultado similar al del siguiente ejemplo, espera un momento y vuelve a intentarlo:Error from server (BadRequest): pod client-east does not have a host assignedEjecuta el curl desde el
Podcliente en el clúster auto-central y verifica 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 enruta a los Pods correspondientes en las ubicaciones más cercanas al origen de la solicitud.
Prueba la resiliencia multirregional de la aplicación
Además de un enrutamiento de tráfico eficiente, la ejecución de tus servicios en varias regiones proporciona resiliencia en el caso poco probable, pero de todas maneras posible, de que falle la infraestructura.
Para probar el comportamiento, borra los Deployments de frontend en clústeres específicos y, luego, vuelve a ejecutar el comando curl desde el Pod cliente en esas regiones. Observa que la aplicación aún esté disponible y mira la ubicación del Pod que responde a la solicitud.
Ejecuta el comando curl desde el
Podclient-west en el clúster std-west y observa que el resultado proviene del frontend en 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-trzc4Borra el
Deploymentde frontend en el clúster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westEl resultado es similar al siguiente ejemplo.
deployment.apps "frontend" deletedEnvía otra solicitud desde el
Podclient-west en el clúster std-west. Deberías ver una respuesta de uno de losDeploymentsde frontend restantes ubicados 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
Poden buen estado 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.
Con esta implementación de demostración, agregaste elementos de resiliencia y distribución geográfica a la aplicación Online Boutique mediante Services de varios clústeres y Gateways de varios clústeres. Las solicitudes se enrutan a la región geográfica más cercana y, aunque los Services de frontend o middleware de una región tengan problemas, el usuario final aún puede usar la aplicación de forma correcta.
Limpia
Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.
¿Qué sigue?
- Obtén más información sobre la flota de Google Cloud y la administración de varios clústeres.
- Obtén más información sobre cómo registrar un clúster, incluidos los clústeres de GKE Enterprise, en una flota de Google Cloud.
- Obtén más información sobre la API de Gateway de Kubernetes y Gateway de GKE.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.