Configurare 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 piano di controllo gestito Istiod e vuoi configurare il bilanciatore del carico delle applicazioni classico come gateway in entrata. L'Application Load Balancer classico noto anche come bilanciatore del carico delle applicazioni esterno classico.

Non utilizzare questo documento se sei un nuovo utente di Cloud Service Mesh. Nuovi gli utenti vengono configurati automaticamente con il piano di controllo gestito di Cloud Service Mesh. Tu non possono utilizzare la configurazione descritta in questo documento con Piano di controllo gestito da 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à perimetrali in: modello di traffico in entrata 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 dell'utente, Da perimetrale al mesh: esposizione delle applicazioni mesh di servizi tramite GKE Ingress, con il gateway cloud mesh di servizi, il deployment di questo modello ora può essere eseguito Gateway Kubernetes che semplifica il processo di deployment il bilanciamento del carico ospitato nel cluster.

Limitazioni dell'anteprima

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

  • I gateway multicluster non sono supportati.
  • I cluster Autopilot sono non 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.
  • Traffico tra il bilanciatore del carico delle applicazioni classico e il traffico in entrata di Cloud Service Mesh il gateway è criptato tramite 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) in esecuzione 1.24 o versioni 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

  1. Abilita l'API Gateway nel cluster. Il cluster GKE deve essere della versione 1.24 o successiva.

  2. 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 mesh di servizi, il cluster Kubernetes Le risorse del gateway vengono utilizzate per il deployment sia di Cloud Load Balancing che di Cloud Service Mesh gateway in entrata come singolo passaggio. Tieni presente che Le risorse del gateway Kubernetes sono diverso da Gateway Istio Google Cloud.

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 Service Mesh ha un GatewayClass che ha la capacità di eseguire il deployment sia del bilanciamento del carico cloud sia del gateway di ingresso Cloud Service Mesh.

  1. Salva il manifest GatewayClass seguente 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

  2. Esegui il deployment di GatewayClass nel cluster:

    kubectl apply -f l7-gateway-class.yaml

  3. Verifica che il 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.

  4. Crea uno spazio dei nomi dedicato per il gateway cloud di Service Mesh:

    kubectl create namespace istio-ingress

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

  6. Esegui il deployment del gateway nel tuo cluster nello spazio dei nomi istio-ingress:

    kubectl apply -f gateway.yaml

  7. Verifica che vengano creati gli oggetti dell'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:

  • È stato eseguito il deployment e la configurazione di un bilanciatore del carico HTTP(S) esterno. Potrebbero essere necessari alcuni minuti venga visualizzato, ma quando appare, il Gateway indicherà l'indirizzo IP verranno annotate con i nomi del bilanciatore del carico di Compute Engine le risorse che sono state create.
  • Viene creato un deployment del gateway in entrata Cloud Service Mesh nel server Istio-ingress nello spazio dei nomi. 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 questo è il il deployment del gateway più semplice possibile. Nelle sezioni seguenti aggiungi funzionalità e criteri aggiuntivi che lo renderanno pronto per la produzione.

Deployment di app e routing

Per dimostrare appieno le funzionalità di cui eseguirai il deployment di un'applicazione Cloud Service Mesh e ricevi traffico internet, ad esempio attraverso il tuo gateway scopi.

  1. Etichetta lo spazio dei nomi default per attivare l'inserimento del file collaterale.

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

  2. 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.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 file manifest crea Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 e Deployment/whereami-v2 per dove, una semplice applicazione che restituisce un codice JSON per indicarne l'identità e la posizione. Ne eseguirai il deployment in due diverse versioni.

  3. Crea i servizi e i deployment:

    kubectl apply -f whereami.yaml

    Quando è attivo e in esecuzione, nel cluster saranno in esecuzione quattro pod in cui sono in esecuzione.

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

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

  6. 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 VirtualService di Istio, 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).

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

  8. 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 il servizio mesh. 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 Application Load Balancer 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. Tu non possono utilizzare la configurazione descritta in questo documento con Piano di controllo gestito da Cloud Service Mesh

Cloud Load Balancing offre molti servizi perimetrali tra cui il bilanciamento del carico anycast globale, le funzionalità certificati, Identity and Access Management, Cloud Next Generation Firewall e Cloud Intrusion Detection System. Cloud Service Mesh può integrare perfettamente queste funzionalità perimetrali in: modello di traffico in entrata mesh. Il gateway cloud mesh di servizi fornisce un modo unificato Configurare il gateway in entrata di 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 precedente guida dell'utente, Da perimetrale al mesh: esposizione delle applicazioni mesh di servizi tramite GKE Ingress, con il gateway cloud mesh di servizi, il deployment di questo modello ora può essere eseguito Gateway Kubernetes che semplifica il processo di deployment il bilanciamento del carico ospitato nel cluster.

Limitazioni dell'anteprima

Per la versione in 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 in entrata Cloud Service Mesh. Questo limitazione si applica a tutti gli utenti del bilanciatore del carico HTTP(S) di Google Cloud.
  • Se Cloud Service Mesh GatewayClasses vengono eliminati 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 nell'ordine del HTTPRoute. Questo cambierà in futuro affinché seguano 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. Altro I 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 illustra come eseguire il deployment Risorsa gateway Kubernetes di cui viene eseguito il deployment un bilanciatore del carico delle applicazioni classico e un gateway in entrata Cloud Service Mesh.

Abilita l'API Gateway con Cloud Service Mesh gestito

  1. Abilita l'API Gateway nel cluster. Il cluster GKE deve essere della versione 1.24 o successiva.

  2. 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 mesh di servizi, il cluster Kubernetes Le risorse del gateway vengono utilizzate per il deployment sia di Cloud Load Balancing che di Cloud Service Mesh gateway in entrata come singolo passaggio. Tieni presente che Le risorse del gateway Kubernetes sono diverso da Gateway Istio Google Cloud.

Per ulteriori informazioni sulle differenze, consulta Gateway Kubernetes e gateway Istio. Ogni gateway Kubernetes ha un GatewayClass che indica il tipo e la le funzionalità di machine learning. il gateway cloud mesh di servizi ha un oggetto GatewayClass con per il deployment di Cloud Load Balancing e del gateway in entrata Cloud Service Mesh.

  1. Salva il manifest GatewayClass seguente 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

  2. Esegui il deployment di GatewayClass nel cluster:

    kubectl apply -f l7-gateway-class.yaml

  3. Verifica che il 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 il 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.

  4. Crea uno spazio dei nomi dedicato per il gateway cloud di Service Mesh:

    kubectl create namespace istio-ingress

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

  6. Esegui il deployment del gateway nel tuo cluster nello spazio dei nomi istio-ingress:

    kubectl apply -f gateway.yaml

  7. Verifica che vengano creati gli oggetti dell'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:

  • È stato eseguito il deployment e la configurazione di un bilanciatore del carico HTTP(S) esterno. Potrebbero essere necessari alcuni minuti venga visualizzato, ma quando appare, il Gateway indicherà l'indirizzo IP verranno annotate con i nomi del bilanciatore del carico di Compute Engine le risorse che sono state create.
  • Viene creato un deployment del gateway in entrata Cloud Service Mesh nel server Istio-ingress nello spazio dei nomi. 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 questo è il il deployment del gateway più semplice possibile. Nelle sezioni seguenti aggiungi funzionalità e criteri aggiuntivi che lo renderanno pronto per la produzione.

Deployment di app e routing

Per dimostrare appieno le funzionalità di cui eseguirai il deployment di un'applicazione Cloud Service Mesh e ricevi traffico internet, ad esempio attraverso il tuo gateway scopi.

  1. Etichetta lo spazio dei nomi default per attivare l'inserimento del file collaterale.

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

  2. 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.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 file manifest crea Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 e Deployment/whereami-v2 per dove, una semplice applicazione che restituisce un codice JSON per indicarne l'identità e la posizione. Ne eseguirai il deployment in due diverse versioni.

  3. Crea i servizi e i deployment:

    kubectl apply -f whereami.yaml

    Quando è attivo e in esecuzione, nel cluster saranno in esecuzione quattro pod in cui sono in esecuzione.

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

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

  6. 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 VirtualService di Istio, 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).

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

  8. 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 il servizio mesh. I passaggi seguenti si basano sul semplice esempio per mostrare una configurazione pronta per la produzione che dimostra i vantaggi di delegare parte del routing in entrata una funzionalità 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à conservato anche se modifiche all'infrastruttura sottostante.
  • Converti il gateway in modo che riceva traffico HTTPS con un certificato autofirmato.

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

  2. 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 siano generalmente utilizzati per pubblici, evidenzia più facilmente questi concetti.

    Per ulteriori informazioni sulla creazione di un certificato autofirmato tramite il secret Kubernetes, vedi Proteggi un gateway.

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

  4. Esegui nuovamente il deployment del gateway nel cluster:

    kubectl apply -f gateway.yaml

  5. Ottieni l'indirizzo IP dell'IP statico:

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

  6. Utilizza curl per accedere al dominio del gateway. Perché il DNS non è configurato per questo dominio, utilizza l'opzione --resolve per indicare a curl di risolvere il dominio all'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 client in modo sicuro.

Hai eseguito il deployment della seguente architettura:

Architettura ASM

servicemesh-cloud-gw e la relativa classe GatewayClass asm-l7-gxlb sono state estrapolate 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 di ingresso di Cloud Service Mesh. La Deployment di whereami-route eseguito in App e Il deployment del routing configura Proxy del gateway in entrata Cloud Service Mesh per instradare il traffico al server in un servizio ospitato su una rete mesh.

Nell'esempio seguente, prenderai servicemesh-cloud-gw dal precedente e aggiungerà le seguenti funzionalità per creare un ambiente e gestibile:

  • Esegui il deployment del gateway con un indirizzo IP statico che verrà conservato anche se modifiche all'infrastruttura sottostante.
  • Converti il gateway in modo che riceva traffico HTTPS con un certificato autofirmato.

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

  2. 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 effettuate manualmente generati con la riga di comando, Certificati gestiti da Google, oppure può essere generata internamente dall'infrastruttura a chiave pubblica dell'azienda encoder-decoder. In questo esempio, generi manualmente un certificato autofirmato. Sebbene i certificati autofirmati non siano generalmente utilizzati per pubblici, evidenzia più facilmente questi concetti.

    Per ulteriori informazioni sulla creazione di un certificato autofirmato tramite il secret Kubernetes, vedi Proteggi un gateway.

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

  4. Esegui nuovamente il deployment del gateway nel cluster:

    kubectl apply -f gateway.yaml

  5. Ottieni l'indirizzo IP dell'IP statico:

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

  6. Utilizza curl per accedere al dominio del gateway. Perché il DNS non è configurato per questo dominio, utilizza l'opzione --resolve per indicare a curl di risolvere il dominio all'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 client 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 sta terminando il traffico TLS utilizzando un certificato interno oltre al controllo di integrità del livello proxy gateway in entrata di Cloud Service Mesh. La Deployment di whereami-route eseguito in App e Il deployment del routing configura Proxy del gateway in entrata Cloud Service Mesh per instradare il traffico al server in un servizio ospitato su una rete mesh.

Passaggi successivi