Configura una malla de servicios de varios clústeres
Esta configuración es compatible con los clientes de la versión preliminar, pero no se recomienda para los usuarios nuevos de Cloud Service Mesh. Para obtener más información, consulta la Descripción general de Cloud Service Mesh.
En esta guía, se muestra cómo agregar un clúster de GKE nuevo a una malla de servicios existente.
Antes de comenzar
Antes de agregar un clúster, asegúrate de completar las instrucciones en Prepárate para implementar con la API de puerta de enlace de GKE, incluida Habilita Services de varios clústeres.
Crea un nuevo clúster de GKE
Crea un clúster nuevo con el siguiente comando:
gcloud container clusters create gke-2 \ --zone=us-west1-a \ --enable-ip-alias \ --workload-pool=PROJECT_ID.svc.id.goog \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --release-channel regular \ --project=PROJECT_ID
Cambia al clúster que acabas de crear mediante el siguiente comando:
gcloud container clusters get-credentials gke-2 --zone us-west1-a
Cambia el nombre del contexto del clúster:
kubectl config rename-context gke_PROJECT_ID_us-west1-a_gke-2 gke-2
Registra el clúster en una flota
Después de crear el clúster, regístralo en tu flota:
gcloud alpha container hub memberships register gke-2 \ --gke-cluster us-west1-a/gke-2 \ --enable-workload-identity \ --project=PROJECT_ID
Verifica que los clústeres estén registrados en la flota:
gcloud alpha container hub memberships list --project=PROJECT_ID
La flota incluye el clúster que acabas de crear y el clúster que creaste anteriormente:
NAME EXTERNAL_ID gke-1 657e835d-3b6b-4bc5-9283-99d2da8c2e1b gke-2 f3727836-9cb0-4ffa-b0c8-d51001742f19
Implementa el inyector de sidecar de Envoy en el nuevo clúster de GKE
Sigue las instrucciones para implementar el inyector de sidecar de Envoy y, luego, implementa el inyector en el clúster gke-2
.
Expande tu malla de servicios al nuevo clúster de GKE
Implementa una malla de servicios de sidecar de Envoy te muestra cómo configurar una malla de servicios en el clúster gke-1
, en el que se ejecuta el service store
. En esta sección, se muestra cómo expandir la malla de servicios para incluir un service payments
que se ejecute en el clúster gke-2
. Un Mesh
recurso ya existe en el clúster de configuración, por lo que no necesitas crear un
Mesh
en el clúster nuevo.
Implemente el servicio payments
En el archivo
payments.yaml
, guarda el siguiente manifiesto:kind: Namespace apiVersion: v1 metadata: name: payments --- apiVersion: apps/v1 kind: Deployment metadata: name: payments namespace: payments spec: replicas: 2 selector: matchLabels: app: payments version: v1 template: metadata: labels: app: payments version: v1 spec: containers: - name: whereami image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20 ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: payments namespace: payments spec: selector: app: payments ports: - port: 8080 targetPort: 8080
Aplica el manifiesto al clúster
gke-2
:kubectl apply --context gke-2 -f payments.yaml
Exporta el service payments
Todos los recursos de la API de puerta de enlace se almacenan de forma centralizada en el clúster de configuración gke-1
.
Los servicios en otros clústeres de la flota deben exportarse para que los recursos de la API de puerta de enlace en el clúster gke-1
puedan hacer referencia a ellos cuando configures el comportamiento de herramientas de redes de la malla de servicios.
Para obtener una explicación detallada de cómo funcionan ServiceExport
y ServiceImport
, lee Services de varios clústeres.
Crea el espacio de nombres
payments
en el clústergke-1
. El servicepayments
en el clústergke-1
se exporta a todos los clústeres en la flota que se encuentran en el mismo espacio de nombres.kubectl create namespace payments --context gke-1
En el archivo
export-payments.yaml
, guarda el siguiente manifiesto:kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: payments namespace: payments
Aplica el manifiesto
ServiceExport
en el clústergke-2
:kubectl apply --context gke-2 -f export-payments.yaml
Después de unos minutos, ejecuta el siguiente comando para verificar que el controlador de Services de varios clústeres de
gke-1
creó elserviceImports
adjunto:kubectl get serviceimports --context gke-1 --namespace payments
El resultado debería ser similar al siguiente:
NAME TYPE IP AGE payments ClusterSetIP ["10.112.31.15"] 6m54s
Configura un recurso HTTPRoute
para el service payments
En el archivo
payments-route.yaml
, guarda el siguiente manifiestoHTTPRoute
:apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: payments-route namespace: payments spec: parentRefs: - name: td-mesh namespace: default group: net.gke.io kind: TDMesh hostnames: - "example.com" rules: - matches: - path: type: PathPrefix value: /payments backendRefs: - group: net.gke.io kind: ServiceImport namespace: payments name: payments port: 8080
Aplica el manifiesto de ruta a
gke-1
:kubectl apply --context gke-1 -f payments-route.yaml
Valida la implementación
Inspecciona el estado y los eventos de Mesh
para verificar que Mesh
y HTTPRoute
.
se implementaron correctamente.
Ejecuta el siguiente comando:
kubectl describe tdmesh td-mesh -–context gke-1
El resultado debería ser similar al siguiente ejemplo:
... Status: Conditions: Last Transition Time: 2022-04-14T22:49:56Z Message: Reason: MeshReady Status: True Type: Ready Last Transition Time: 2022-04-14T22:27:17Z Message: Reason: Scheduled Status: True Type: Scheduled Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 23m mc-mesh-controller Processing mesh default/td-mesh Normal UPDATE 23m mc-mesh-controller Processing mesh default/td-mesh Normal SYNC 23m mc-mesh-controller Processing mesh default/td-mesh Normal SYNC 71s mc-mesh-controller SYNC on default/td-mesh was a success
Para verificar la implementación, implementa un Pod cliente en uno de los clústeres. En el archivo
client.yaml
, guarda lo siguiente:apiVersion: apps/v1 kind: Deployment metadata: labels: run: client name: client namespace: default spec: replicas: 1 selector: matchLabels: run: client template: metadata: labels: run: client spec: containers: - name: client image: curlimages/curl command: - sh - -c - while true; do sleep 1; done
Aplica el manifiesto
kubectl apply -f client.yaml --context $CLUSTER
El inyector de sidecar que se ejecuta en el clúster inserta de forma automática un contenedor de Envoy en el Pod del cliente.
Para verificar que se inserte el contenedor de Envoy, ejecuta el siguiente comando:
kubectl describe pods -l run=client --context $CLUSTER
El resultado es similar a este:
... Init Containers: # Istio-init sets up traffic interception for the Pod. istio-init: ... # td-bootstrap-writer generates the Envoy bootstrap file for the Envoy container td-bootstrap-writer: ... Containers: # client is the client container that runs application code. client: ... # Envoy is the container that runs the injected Envoy proxy. envoy: ...
Después de aprovisionar el Pod cliente y la
mesh
, envía una solicitud desde el Pod cliente al serviciostore
:# Get the name of the client Pod. CLIENT_POD=$(kubectl get pod --context $CLUSTER -l run=client -o=jsonpath='{.items[0].metadata.name}') # The VIP where the following request will be sent. Because requests from the # Busybox container are redirected to the Envoy proxy, the IP address can # be any other address, such as 10.0.0.2 or 192.168.0.1. VIP='10.0.0.1' # Command to send a request to store. TEST_CMD="curl -v -H 'Host: example.com' $VIP/store" # Execute the test command in the client container. kubectl exec -it $CLIENT_POD -c client --context $CLUSTER -- /bin/sh -c "$TEST_CMD"
El resultado debe mostrar que uno de los Pods
store
engke-1
entrega la solicitud:{ "cluster_name": "gke-1", "zone": "us-central1-a", "host_header": "example.com", ... }
Envía una solicitud al service
payments
:# Command to send a request to payments. TEST_CMD="curl -v -H 'host: example.com' $VIP/payments" # Execute the test command in the client container. kubectl exec -it $CLIENT_POD -c client -- /bin/sh -c "$TEST_CMD"
El resultado debe mostrar que uno de los Pods
payments
en gke-2 entrega la solicitud:{ "cluster_name": "gke-2", "zone": "us-west1-a", "host_header": "example.com", ... }