Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare un mesh di servizi multi-cluster

Questa configurazione è supportata per i clienti Preview, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa guida illustra come aggiungere un nuovo cluster GKE a un mesh di servizi esistente.

Prima di iniziare

Prima di aggiungere un cluster, assicurati di completare le istruzioni riportate in Prepararsi al deployment con l'API Gateway di GKE, incluse le istruzioni per abilitare i servizi multi-cluster.

Crea un nuovo cluster GKE

Crea un nuovo cluster utilizzando il seguente 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

Passa al cluster appena creato emettendo il seguente comando:

gcloud container clusters get-credentials gke-2 --zone us-west1-a

Rinomina il contesto del cluster:

kubectl config rename-context gke_PROJECT_ID_us-west1-a_gke-2 gke-2

Registra il cluster in un parco risorse

Dopo aver creato il cluster, registralo nel tuo Parco risorse:

gcloud alpha container hub memberships register gke-2 \
  --gke-cluster us-west1-a/gke-2 \
  --enable-workload-identity \
  --project=PROJECT_ID

Verifica che i cluster siano registrati nel parco risorse:

gcloud alpha container hub memberships list --project=PROJECT_ID

Il parco risorse include sia il cluster appena creato sia quello creato in precedenza:

NAME          EXTERNAL_ID
gke-1  657e835d-3b6b-4bc5-9283-99d2da8c2e1b
gke-2  f3727836-9cb0-4ffa-b0c8-d51001742f19

Esegui il deployment dell'iniettore sidecar Envoy nel nuovo cluster GKE

Segui le istruzioni per implementare l'iniettore sidecar Envoy e implementa l'iniettore nel cluster gke-2.

Espandi il tuo service mesh al nuovo cluster GKE

L'articolo Esegui il deployment di un mesh di servizi sidecar Envoy illustra come configurare un mesh di servizi nel cluster gke-1, dove viene eseguito il servizio store. Questa sezione mostra come espandere il servizio mesh per includere un servizio payments in esecuzione nel cluster gke-2. Nel cluster di configurazione esiste già una risorsa Mesh, quindi non è necessario crearne una nel nuovo cluster.Mesh

Esegui il deployment del servizio `payments`

Nel file payments.yaml, salva il seguente manifest:

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
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: payments
  namespace: payments
spec:
  selector:
    app: payments
  ports:
  - port: 8080
    targetPort: 8080

Applica il manifest al cluster gke-2:

kubectl apply --context gke-2 -f payments.yaml

Esportare il servizio `payments`

Tutte le risorse dell'API Gateway vengono archiviate centralmente nel cluster di configurazione gke-1. I servizi in altri cluster del parco risorse devono essere esportati in modo che le risorse dell'API Gateway nel cluster gke-1 possano farvi riferimento quando configuri il comportamento di rete del mesh di servizi.

Per una spiegazione dettagliata del funzionamento di ServiceExport e ServiceImport, consulta Servizi multicluster.

Crea lo spazio dei nomi payments nel cluster gke-1. Il servizio payments nel cluster gke-1 viene esportato in tutti i cluster del parco risorse che si trovano nello stesso spazio dei nomi.
```
kubectl create namespace payments --context gke-1
```

Nel file export-payments.yaml, salva il seguente manifest:

kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: payments
  namespace: payments

Applica il manifest ServiceExport nel cluster gke-2:

kubectl apply --context gke-2 -f export-payments.yaml

Dopo alcuni minuti, esegui il seguente comando per verificare che i serviceImports aggiuntivi siano stati creati dal controller dei servizi multi-cluster in gke-1:
```
kubectl get serviceimports --context gke-1 --namespace payments
```
L'output dovrebbe essere simile al seguente:
```
NAME           TYPE           IP                  AGE
payments       ClusterSetIP   ["10.112.31.15"]    6m54s
```

Configura una risorsa `HTTPRoute` per il servizio `payments`

Nel file payments-route.yaml, salva il seguente manifest 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

Applica il manifest del percorso a gke-1:

kubectl apply --context gke-1 -f payments-route.yaml

Convalida il deployment

Controlla lo stato e gli eventi di Mesh per verificare che Mesh e HTTPRoute siano stati implementati correttamente.

Esegui questo comando:

kubectl describe tdmesh td-mesh -–context gke-1

L'output dovrebbe essere simile al seguente:

...
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

Per verificare il deployment, esegui il deployment di un pod client in uno dei cluster. Nel client.yaml file, salva quanto segue:

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

Applica il manifest:
```
kubectl apply -f client.yaml --context $CLUSTER
```
L'iniettore sidecar in esecuzione nel cluster inietta automaticamente un contenitore Envoy nel pod client.

Per verificare che il contenitore Envoy sia stato inserito, esegui il seguente comando:

kubectl describe pods -l run=client --context $CLUSTER

L'output è simile al seguente:

...
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:
...

Dopo aver eseguito il provisioning di mesh e del pod client, invia una richiesta dal pod client al servizio 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"

L'output dovrebbe indicare che uno dei pod store in gke-1 gestisce la richiesta:

{
  "cluster_name": "gke-1",
  "zone": "us-central1-a",
  "host_header": "example.com",
...
}

Invia una richiesta al servizio 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"

L'output dovrebbe mostrare che uno dei pod payments in gke-2 gestisce la richiesta:

{
  "cluster_name": "gke-2",
  "zone": "us-west1-a",
  "host_header": "example.com",
...
}

Passaggi successivi

Scopri come risolvere i problemi di implementazione.