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

Configura il bilanciatore del carico delle applicazioni classico per Cloud Service Mesh

Panoramica

Questo documento è rivolto agli utenti esistenti di Cloud Service Mesh che dispongono del control plane gestito Istiod e vogliono configurare il bilanciatore del carico delle applicazioni classico come gateway in entrata. Il bilanciatore del carico delle applicazioni classico è noto anche come bilanciatore del carico delle applicazioni esterno classico.

Non utilizzare questo documento se sei un nuovo utente di Cloud Service Mesh. I nuovi utenti vengono configurati automaticamente con il control plane gestito da Cloud Service Mesh. Non puoi utilizzare la configurazione descritta in questo documento con il control plane gestito di Cloud Service Mesh

Cloud Load Balancing offre molte funzionalità edge gestite dal cloud, tra cui bilanciamento del carico anycast globale, certificati gestiti da Google, Identity and Access Management, Cloud Next Generation Firewall e Cloud Intrusion Detection System. Cloud Service Mesh può integrare perfettamente queste funzionalità perimetrali nel seguente modello di ingresso mesh. Il gateway cloud service mesh fornisce un modo unificato per configurare il gateway in entrata Cloud Service Mesh con Cloud Load Balancing contemporaneamente tramite l'API Kubernetes Gateway.

Diagramma che mostra un bilanciatore del carico con Cloud Service Mesh

Rispetto alla nostra guida utente precedente, Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi mediante GKE Ingress, con il gateway cloud di service mesh, questo modello ora può essere implementato tramite una risorsa Kubernetes Gateway, che semplifica il processo di deployment del bilanciamento del carico ospitato nel cloud e nel cluster.

Limitazioni dell'anteprima

Per la release di anteprima di questa funzionalità, si applicano le seguenti limitazioni:

I gateway multicluster non sono supportati.
I cluster Autopilot non sono supportati.
È supportato solo il bilanciatore del carico delle applicazioni classico. Il bilanciatore del carico delle applicazioni esterno globale (a volte chiamato bilanciatore del carico avanzato) e il bilanciatore del carico delle applicazioni interno non sono supportati.
Il traffico tra il bilanciatore del carico delle applicazioni classico e il gateway in entrata di Cloud Service Mesh viene criptato utilizzando TLS. Tuttavia, il bilanciatore del carico delle applicazioni classico non verificherà il certificato fornito dal gateway di ingresso Cloud Service Mesh. Questa limitazione si applica a tutti gli utenti del bilanciatore del carico HTTP(S) Google Cloud .
Se i GatewayClasses di Cloud Service Mesh vengono eliminati da un cluster, non verranno reinstallati automaticamente. Tuttavia, ciò non influirà sull'usabilità della funzionalità.
La logica di corrispondenza delle route non segue le specifiche dell'API Gateway e corrisponde invece all'ordine di HTTPRoute. Questo cambierà nelle versioni future per seguire le specifiche dell'API Gateway.

Requisiti

Managed Cloud Service Mesh installato su un cluster Google Kubernetes Engine (GKE) che esegue la versione 1.24 o successive. Gli altri cluster GKE Enterprise non sono supportati.
Solo la versione v1beta1 dell'API Kubernetes Gateway.

Prerequisiti

Abilita le seguenti API nel tuo progetto:

compute.googleapis.com
container.googleapis.com
certificatemanager.googleapis.com
serviceusage.googleapis.com

gcloud services enable \
   compute.googleapis.com \
   container.googleapis.com \
   certificatemanager.googleapis.com \
   serviceusage.googleapis.com

Esegui il deployment del gateway cloud del mesh di servizi per un mesh a cluster singolo

Questa sezione mostra come eseguire il deployment di una risorsa Kubernetes Gateway che esegue il deployment di un bilanciatore del carico delle applicazioni classico e di un gateway di ingresso Cloud Service Mesh.

Abilita l'API Gateway con Cloud Service Mesh gestito

Abilita l'API Gateway nel tuo cluster. Il cluster GKE deve essere la versione 1.24 o successiva.
Installa Cloud Service Mesh gestito con rapid o regular come canale di rilascio.

Esegui il deployment della risorsa Gateway

Quando viene eseguito il deployment del gateway cloud mesh di servizi, le risorse Kubernetes Gateway vengono utilizzate per eseguire il deployment sia del gateway in entrata Cloud Load Balancing sia di Cloud Service Mesh in un unico passaggio. Tieni presente che le risorse Kubernetes Gateway sono diverse dalle risorse Istio Gateway.

Per saperne di più sulle differenze, consulta Gateway Kubernetes e gateway Istio. Ogni gateway Kubernetes ha una GatewayClass che indica il suo tipo e le sue funzionalità intrinseche. Il gateway cloudmesh di servizih ha una GatewayClass che ha la capacità di eseguire il deployment sia deCloud Load Balancingud sia del gateway in entrata Cloud Service Mesh.

Salva il seguente manifest GatewayClass in un file denominato l7-gateway-class.yaml:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: asm-l7-gxlb
spec:
  controllerName: mesh.cloud.google.com/gateway

Esegui il deployment di GatewayClass nel tuo cluster:
```
kubectl apply -f l7-gateway-class.yaml
```
Verifica che GatewayClass sia presente dopo l'installazione:
```
kubectl get gatewayclasses.gateway.networking.k8s.io
```
L'output è simile al seguente:
```
NAME          CONTROLLER
asm-l7-gxlb   mesh.cloud.google.com/gateway
gke-l7-rilb   networking.gke.io/gateway
gke-l7-gxlb   networking.gke.io/gateway
```
Potrebbero essere necessari alcuni minuti prima che tutte le risorse vengano implementate. Se non vedi l'output previsto, verifica di aver soddisfatto correttamente i prerequisiti.

Vedrai anche la seguente GatewayClass:
```
gke-l7-gxlb   networking.gke.io/gateway
```
Viene utilizzato per eseguire il deployment del bilanciatore del carico delle applicazioni classico di Google Cloud sottostante.
Crea uno spazio dei nomi dedicato per il gateway cloud del mesh di servizi:
```
kubectl create namespace istio-ingress
```

Salva il seguente manifest del gateway in un file denominato gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: servicemesh-cloud-gw
  namespace: istio-ingress
spec:
  gatewayClassName: asm-l7-gxlb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

Esegui il deployment del gateway nel tuo cluster nello spazio dei nomi istio-ingress:
```
kubectl apply -f gateway.yaml
```

Verifica che siano stati creati gli oggetti API Kubernetes Gateway:

kubectl get gateways.gateway.networking.k8s.io -n istio-ingress

L'output è simile al seguente:

NAME                                CLASS         ADDRESS         READY   AGE
asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
servicemesh-cloud-gw                asm-l7-gxlb                           9m44s

Quando viene eseguito il deployment di questo oggetto API Kubernetes Gateway, si verificano le seguenti operazioni:

Un bilanciatore del carico HTTP(S) esterno è di cui è stato eseguito il deployment e la configurazione. Potrebbero essere necessari alcuni minuti prima che venga visualizzato, ma quando lo sarà, il gateway indicherà l'indirizzo IP e sarà annotato con i nomi delle risorse del bilanciatore del carico Compute Engine che sono state create.
Viene creato un deployment del gateway in entrata Cloud Service Mesh nello spazio dei nomi istio-ingress. Vengono create le istanze proxy Envoy che riceveranno il traffico dal bilanciatore del carico.
Il bilanciatore del carico cripta e instrada tutto il traffico al gateway in entrata di Cloud Service Mesh.

Ora hai l'infrastruttura completa necessaria per accettare il traffico internet nella tua mesh. Tieni presente che questo è il deployment del gateway più semplice possibile. Nelle sezioni successive aggiungi ulteriori criteri e funzionalità che lo renderanno pronto per la produzione.

Deployment di app e routing

Per dimostrare appieno le funzionalità, eseguirai il deployment di un'applicazione in Cloud Service Mesh e riceverai traffico internet tramite il gateway, ad esempio per scopi dimostrativi.

Etichetta lo spazio dei nomi default per attivare l'inserimento di sidecar.

kubectl label namespace default istio-injection=enabled istio.io/rev- --overwrite

Salva il seguente manifest del gateway in un file denominato whereami.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami-v1
  template:
    metadata:
      labels:
        app: whereami-v1
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
          - containerPort: 8080
        env:
        - name: METADATA
          value: "whereami-v1"
---
apiVersion: v1
kind: Service
metadata:
  name: whereami-v1
spec:
  selector:
    app: whereami-v1
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-v2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami-v2
  template:
    metadata:
      labels:
        app: whereami-v2
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
          - containerPort: 8080
        env:
        - name: METADATA
          value: "whereami-v2"
---
apiVersion: v1
kind: Service
metadata:
  name: whereami-v2
spec:
  selector:
    app: whereami-v2
  ports:
  - port: 8080
    targetPort: 8080

Questo manifest crea Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 e Deployment/whereami-v2 per whereami, una semplice applicazione che restituisce JSON per indicare la sua identità e posizione. Eseguirai il deployment di due versioni diverse.

Crea i servizi e i deployment:
```
kubectl apply -f whereami.yaml
```
Una volta in esecuzione, nel cluster saranno in esecuzione quattro pod whereami.

Verifica che tutti e quattro i pod siano in esecuzione:

kubectl get pods

L'output è simile al seguente:

whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s

Salva il seguente manifest HTTPRoute in un file denominato http-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: where-route
spec:
 parentRefs:
 - kind: Gateway
   name: servicemesh-cloud-gw
   namespace: istio-ingress
 hostnames:
 - "where.example.com"
 rules:
 - matches:
   - headers:
     - name: version
       value: v2
   backendRefs:
   - name: whereami-v2
     port: 8080
 - backendRefs:
   - name: whereami-v1
     port: 8080

Esegui il deployment di http-route.yaml nel tuo cluster:
```
kubectl apply -f http-route.yaml
```
Questo HTTPRoute fa riferimento a servicemesh-cloud-gw, il che significa che configurerà il gateway cloud del mesh di servizi in modo che configuri il gateway di ingresso Cloud Service Mesh sottostante con queste regole di routing. HTTPRoute svolge la stessa funzione di Istio VirtualService, ma utilizza l'API Gateway di Kubernetes per farlo. Poiché l'API Gateway è una specifica OSS con molte implementazioni sottostanti, è l'API più adatta per definire il routing in una combinazione di diversi bilanciatori del carico (ad esempio proxy Cloud Service Mesh e bilanciatori del carico).

Recupera l'indirizzo IP dal gateway in modo da poter inviare traffico alla tua applicazione:

VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)

L'output è un indirizzo IP.

echo $VIP

34.111.61.135

Invia traffico all'indirizzo IP del gateway per verificare che questa configurazione funzioni correttamente. Invia una richiesta con l'intestazione version: v2 e una senza per determinare che il routing venga eseguito correttamente nelle due versioni dell'applicazione.

curl ${VIP} -H "host: where.example.com"

{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "whereami-v1",
  "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
  "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
  "pod_name_emoji": "⚒",
  "project_id": "church-243723",
  "timestamp": "2021-02-08T18:55:01",
  "zone": "us-central1-a"
}

curl ${VIP} -H "host: where.example.com" -H "version: v2"

{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "whereami-v2",
  "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
  "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
  "pod_name_emoji": "⚒",
  "project_id": "church-243723",
  "timestamp": "2021-02-08T18:55:01",
  "zone": "us-central1-a"
}

Deployment del gateway di produzione

La sezione precedente mostrava un esempio molto semplice di gateway cloud mesh di servizi. I seguenti passaggi si basano sull'esempio semplice per mostrare una configurazione pronta per la produzione che dimostra i vantaggi della delega di alcune funzionalità di routing in entrata al bilanciatore del carico.

Nell'esempio seguente, prenderai servicemesh-cloud-gw dalla sezione precedente e aggiungerai le seguenti funzionalità per creare un gateway più sicuro e gestibile:

Esegui il deployment del gateway con un indirizzo IP statico che verrà mantenuto anche se l'infrastruttura sottostante cambia.
Converti il gateway per ricevere il traffico HTTPS con un certificato autofirmato.

Crea un indirizzo IP esterno statico. Un IP statico è utile perché l'infrastruttura sottostante può cambiare in futuro, ma l'indirizzo IP può essere mantenuto.
```
gcloud compute addresses create whereami-ip \
    --global \
    --project PROJECT_ID
```

Crea un certificato autofirmato per il dominio where-example-com:

openssl genrsa -out key.pem 2048
cat <<EOF >ca.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = where.example.com
[sans_list]
DNS.1                     = where.example.com
EOF

openssl req -new -key key.pem \
    -out csr.pem \
    -config ca.conf

openssl x509 -req \
    -signkey key.pem \
    -in csr.pem \
    -out cert.pem \
    -extfile ca.conf \
    -extensions extension_requirements \
    -days 365

gcloud compute ssl-certificates create where-example-com \
    --certificate=cert.pem \
    --private-key=key.pem \
    --global \
    --project PROJECT_ID

Esistono molti modi per generare certificati TLS. Possono essere generati manualmente sulla riga di comando, utilizzando certificati gestiti da Google o internamente dal sistema di infrastruttura a chiave pubblica (PKI) della tua azienda. In questo esempio, generi manualmente un certificato autofirmato. Sebbene i certificati autofirmati non vengano in genere utilizzati per servizi pubblici, dimostrano più facilmente questi concetti.

Per ulteriori informazioni sulla creazione di un certificato autofirmato tramite Kubernetes Secret, vedi Proteggere un gateway.

Aggiorna gateway.yaml con il seguente manifest:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: servicemesh-cloud-gw
  namespace: istio-ingress
spec:
  gatewayClassName: asm-l7-gxlb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: where-example-com
  addresses:
  - type: NamedAddress
    value: whereami-ip

Esegui nuovamente il deployment del gateway nel tuo cluster:
```
kubectl apply -f gateway.yaml
```

Ottieni l'indirizzo IP dell'IP statico:

VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")

Utilizza curl per accedere al dominio del gateway. Poiché il DNS non è configurato per questo dominio, utilizza l'opzione --resolve per indicare a curl di risolvere il nome di dominio nell'indirizzo IP del gateway:

curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v

Al termine, l'output è simile al seguente:

...
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=where.example.com
*  start date: Apr 19 15:54:50 2021 GMT
*  expire date: Apr 19 15:54:50 2022 GMT
*  common name: where.example.com (matched)
*  issuer: O=example; CN=where.example.com
*  SSL certificate verify ok.
...
{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "where-v1",
  "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
  "pod_name": "where-v1-84b47c7f58-tj5mn",
  "pod_name_emoji": "😍",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-04-19T16:30:08",
  "zone": "us-west1-a"
}

L'output dettagliato include un handshake TLS riuscito seguito da una risposta dall'applicazione, come nell'output seguente. Ciò dimostra che TLS viene terminato correttamente nel gateway e che l'applicazione risponde al client in modo sicuro.

Hai eseguito il deployment della seguente architettura:

Architettura ASM

servicemesh-cloud-gw e la relativa asm-l7-gxlb GatewayClass hanno estratto alcuni componenti infrastrutturali interni per semplificare l'esperienza utente. Cloud Load Balancing termina il traffico TLS utilizzando un certificato interno e controlla anche l'integrità del livello proxy del gateway in entrata di Cloud Service Mesh. whereami-route di cui è stato eseguito il deployment in App & Routing Deployment configura i proxy del gateway di ingresso Cloud Service Mesh per instradare il traffico al servizio corretto ospitato nel mesh.