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 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 piano di controllo gestito di Istio e vogliono configurare il bilanciatore del carico delle applicazioni classico come gateway di ingresso. Il bilanciatore del carico delle applicazioni classico è conosciuto 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 piano di controllo gestito di Cloud Service Mesh. Non puoi utilizzare la configurazione descritta in questo documento con il piano di controllo gestito di Cloud Service Mesh

Cloud Load Balancing offre molte funzionalità di edge gestite dal cloud, tra cui il bilanciamento del carico anycast globale, i 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à di edge nel seguente modello di ingresso mesh. Service Mesh Cloud Gateway offre un modo unificato per configurare contemporaneamente il gateway di ingresso Cloud Service Mesh con Cloud Load Balancing tramite l'API Kubernetes Gateway.

Diagramma che mostra un bilanciatore del carico con Cloud Service Mesh

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

Limitazioni dell'anteprima

Per la versione 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 di ingresso 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) di Google Cloud.
Se Cloud Service Mesh GatewayClasses viene eliminato da un cluster, non verrà reinstallato 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 nell'ordine del HTTPRoute. Questo cambierà nelle versioni future per rispettare le specifiche dell'API Gateway.

Requisiti

Cloud Service Mesh gestito installato su un cluster Google Kubernetes Engine (GKE) che esegue la versione 1.24 o successive. Altri cluster GKE Enterprise non sono supportati.
Solo 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 un cluster

Questa sezione mostra come eseguire il deployment di una risorsa gateway Kubernetes 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 cluster. Il cluster GKE deve essere della 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 esegui il deployment del gateway cloud del mesh di servizi, le risorse Kubernetes Gateway vengono utilizzate per eseguire il deployment sia di Cloud Load Balancing sia del gateway di ingresso Cloud Service Mesh in un unico passaggio. Tieni presente che le risorse Kubernetes Gateway sono diverse dalle risorse Istio Gateway.

Per ulteriori informazioni sulle differenze, consulta Gateway Kubernetes e gateway Istio. Ogni gateway Kubernetes ha un GatewayClass che indica il tipo e le funzionalità intrinseche. Il gateway cloud di mesh di servizi ha un GatewayClass che ha la capacità di eseguire il deployment sia di Cloud Load Balancing sia del gateway di ingresso 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 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
```
Il deployment di tutte le risorse potrebbe richiedere alcuni minuti. Se non vedi l'output previsto, verifica di aver soddisfatto correttamente i prerequisiti.

Vedrai anche la seguente classe Gateway:
```
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 di mesh di servizi:
```
kubectl create namespace istio-ingress
```

Salva il seguente manifest di 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 gli oggetti dell'API Kubernetes Gateway siano stati creati:

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:

Viene eseguito il deployment e la configurazione di un bilanciatore del carico HTTP(S) esterno. Potrebbero essere necessari alcuni minuti prima che venga visualizzato, ma quando ciò avviene, il gateway indicherà l'indirizzo IP e verrà annotato con i nomi delle risorse del bilanciatore del carico Compute Engine create.
Viene creato un deployment del gateway di ingresso 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 di ingresso Cloud Service Mesh.

Ora hai l'intera infrastruttura necessaria per accettare il traffico internet nella tua mesh. Tieni presente che si tratta del deployment di Gateway più semplice possibile. Nelle sezioni seguenti aggiungerai criteri e funzionalità aggiuntivi che lo renderanno pronto per la produzione.

Deployment di app e routing

Per dimostrare completamente le funzionalità, eseguirai il deployment di un'applicazione in Cloud Service Mesh e riceverai il traffico internet tramite il tuo gateway a scopo di esempio.

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

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

Salva il seguente manifest di 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.2.20
        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.2.20
        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 semplicità applicazione che genera output JSON per indicare la propria identità e posizione. Ne eseguirai il deployment in due versioni diverse.

Crea i servizi e i deployment:
```
kubectl apply -f whereami.yaml
```
Una volta che il servizio è attivo e funzionante, 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 parametro HTTPRoute fa riferimento a servicemesh-cloud-gw, il che significa che configurerà il gateway cloud del mesh di servizi in modo da configurare 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 Kubernetes Gateway per farlo. Poiché l'API Gateway è una specifica OSS con molte implementazioni di base, è l'API più adatta per definire il routing in una combinazione di diversi bilanciatori del carico (come i proxy e i bilanciatori del carico di Cloud Service Mesh).

Recupera l'indirizzo IP dal gateway per 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 verificare 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 per mesh di servizi. I passaggi che seguono si basano sull'esempio semplice per mostrare una configurazione pronta per la produzione che dimostra i vantaggi della delega di alcune funzionalità di routing di ingresso al bilanciatore del carico.

Nell'esempio seguente, utilizzerai il servicemesh-cloud-gw della 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 di base cambia.
Converti il gateway in modo che riceva il traffico HTTPS con un certificato autofirmato.

Crea un indirizzo IP esterno statico. Un indirizzo IP statico è utile perché l'infrastruttura di base 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 i certificati gestiti da Google o possono essere generati 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 i servizi pubblici, dimostrano più facilmente questi concetti.

Per ulteriori informazioni sulla creazione di un certificato autofirmato tramite il secret Kubernetes, consulta 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 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 l'output seguente. Ciò dimostra che il protocollo TLS viene terminato correttamente nel gateway e che l'applicazione risponde al cliente in modo sicuro.

Hai eseguito il deployment della seguente architettura:

Architettura ASM

servicemesh-cloud-gw e il relativo asm-l7-gxlb GatewayClass hanno astratto alcuni componenti dell'infrastruttura interna 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 di ingresso di Cloud Service Mesh. Il whereami-route di cui è stato eseguito il deployment in Deployment di app e routing configura i proxy gateway di ingresso Cloud Service Mesh per instradare il traffico al servizio ospitato nel mesh corretto.