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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Panoramica

Questo documento è rivolto agli utenti esistenti di Cloud Service Mesh che hanno il 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 di Traffic Director. 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 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 senza problemi queste funzionalità edge nel seguente modello di ingresso del mesh. Il gateway cloud del mesh di servizi fornisce un modo unificato per configurare contemporaneamente il gateway in entrata di 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 guida utente precedente, 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 può ora essere implementato tramite una risorsa Kubernetes Gateway, il che semplifica la procedura di deployment congiunto 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 multi-cluster 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 in entrata di Cloud Service Mesh. Questa limitazione si applica a tutti gli utenti del Google Cloud bilanciatore del carico HTTP(S).
Se le GatewayClasses di Cloud Service Mesh vengono eliminate da un cluster, non verranno reinstallate 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. Nelle versioni future, questa logica verrà modificata in modo da seguire le specifiche dell'API Gateway.

Requisiti

Cloud Service Mesh gestito installato su un cluster Google Kubernetes Engine (GKE) con 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 in entrata di Cloud Service Mesh.

Abilita l'API Gateway con Cloud Service Mesh gestito

Abilita l'API Gateway nel cluster. Il cluster GKE deve essere la versione 1.24 o successive.
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 in entrata di 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 la sezione Gateway Kubernetes e gateway Istio. Ogni gateway Kubernetes ha una GatewayClass che indica il tipo e le funzionalità intrinseche. Il gateway cloud del mesh di servizi ha una GatewayClass in grado di eseguire il deployment sia di Cloud Load Balancing sia del gateway in entrata di 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.

Verrà visualizzata 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 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 cluster nello spazio dei nomi istio-ingress:
```
kubectl apply -f gateway.yaml
```

Verifica che gli oggetti 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. Potrebbe essere necessario attendere alcuni minuti prima che venga visualizzato, ma quando ciò accade, il gateway indicherà l'indirizzo IP e verrà annotato con i nomi delle risorse del bilanciatore del carico di Compute Engine create.
Viene creato un deployment del gateway in entrata di Cloud Service Mesh nello spazio dei nomi istio-ingress. Vengono create le istanze del 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 nel mesh. Tieni presente che questo è il deployment del gateway più semplice possibile. Nelle sezioni seguenti aggiungerai altre policy e funzionalità che lo renderanno pronto per la produzione.

Deployment di app e routing

A scopo illustrativo, per dimostrare appieno le funzionalità, eseguirai il deployment di un'applicazione in Cloud Service Mesh e riceverai il traffico internet tramite il gateway.

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

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

Salva il seguente manifest 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 la sua posizione. Eseguirai il deployment di due versioni diverse.

Crea i servizi e i deployment:
```
kubectl apply -f whereami.yaml
```
Una volta che è 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 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 in entrata di Cloud Service Mesh sottostante con queste regole di routing. HTTPRoute svolge la stessa funzione di Istio VirtualService, ma utilizza l'API Kubernetes Gateway. 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 (come i proxy e i bilanciatori del carico di Cloud Service Mesh).

Recupera l'indirizzo IP dal gateway in modo da poter inviare traffico all'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 tra le 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 del mesh di servizi. I passaggi seguenti 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 traffico HTTPS con un certificato autofirmato.

Crea un indirizzo IP esterno statico. Un indirizzo 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 dalla riga di comando, utilizzando i 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 i servizi pubblici, dimostrano più facilmente questi concetti.

Per ulteriori informazioni sulla creazione di un certificato autofirmato tramite il secret Kubernetes, consulta la sezione Proteggi 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 di nuovo il deployment del gateway nel cluster:
```
kubectl apply -f gateway.yaml
```

Ottieni l'indirizzo 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 dell'applicazione simile all'output seguente. Ciò dimostra che TLS viene terminato correttamente nel gateway e che l'applicazione risponde al client in modo sicuro.

Hai eseguito correttamente il deployment della seguente architettura:

Architettura ASM

servicemesh-cloud-gw e la relativa GatewayClass asm-l7-gxlb 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. The whereami-route di cui è stato eseguito il deployment in Deployment di app e routing configura i proxy del gateway in entrata di Cloud Service Mesh per instradare il traffico al servizio ospitato nel mesh corretto.