Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

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úster gke-1. El service payments en el clúster gke-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úster gke-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ó el serviceImports 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 manifiesto HTTPRoute:

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 servicio store:

# 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 en gke-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",
...
}

¿Qué sigue?

Obtén información para solucionar problemas de la implementación.