Questa pagina è stata tradotta dall'API Cloud Translation.

Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi mediante GKE Ingress

Last reviewed 2022-09-29 UTC

Questo tutorial mostra come combinare Anthos Service Mesh con Cloud Load Balancing per esporre le applicazioni in un mesh di servizi ai client Internet.

Anthos Service Mesh è un mesh di servizi gestiti, basato su Istio, che fornisce un livello di comunicazione standardizzato, osservabile e ottimizzato per la sicurezza per le applicazioni. Sia che utilizzi Anthos Service Mesh, Traffic Director o Istio, un mesh di servizi offre una piattaforma di comunicazione olistica per i client che comunicano nel mesh. Tuttavia, rimane una sfida su come connettere i client che si trovano al di fuori del mesh alle applicazioni ospitate nel mesh.

Puoi esporre un'applicazione ai client in molti modi, a seconda di dove si trova il client. Questo tutorial mostra come esporre un'applicazione ai client combinando Cloud Load Balancing con Anthos Service Mesh per integrare i bilanciatori del carico con un mesh di servizi. Questo tutorial è destinato ai professionisti avanzati che eseguono Anthos Service Mesh ma funziona anche per Istio su Google Kubernetes Engine.

Gateway in entrata mesh

Istio 0.8 ha introdotto il gateway in entrata della rete mesh che fornisce un set dedicato di proxy le cui porte sono esposte al traffico proveniente dall'esterno del mesh di servizi. Questi proxy in entrata mesh consentono di controllare il comportamento dell'esposizione L4 separatamente dal comportamento del routing dell'applicazione. I proxy ti consentono anche di applicare routing e criterio al traffico mesh-esterno prima di arrivare a un sidecar dell'applicazione. Il mesh in entrata definisce il trattamento del traffico quando raggiunge un nodo nel mesh, ma i componenti esterni devono definire il modo in cui il traffico arriva prima al mesh.

Per gestire questo traffico esterno, devi avere un bilanciatore del carico esterno al mesh. Questo tutorial utilizza Google Cloud Load Balancing di cui è stato eseguito il provisioning tramite le risorse GKE Ingress per l'automazione del deployment. L'esempio canonico di questa configurazione è un servizio di bilanciamento del carico esterno che (nel caso di Google Cloud) esegue il deployment di un bilanciatore del carico TCP/UDP pubblico. Il bilanciatore del carico punta alle NodePort di un cluster GKE. Queste Node Node espongono i pod del gateway Istio in entrata, che instradano il traffico ai proxy sidecar mesh a valle. Il seguente diagramma illustra questa topologia. Il bilanciamento del carico per il traffico privato interno è simile a questa architettura, ad eccezione del deployment di un bilanciatore del carico TCP/UDP interno.

Un bilanciatore del carico esterno instrada i client esterni al mesh attraverso i proxy del gateway in entrata.

L'utilizzo del bilanciamento del carico trasparente L4 con un gateway in entrata della rete offre i seguenti vantaggi:

Questa configurazione semplifica il deployment del bilanciatore del carico.
Il bilanciatore del carico fornisce un IP virtuale stabile, il controllo di integrità e una distribuzione affidabile del traffico quando si verificano modifiche al cluster, interruzioni dei nodi o interruzioni del processo.
Tutte le regole di routing, la terminazione TLS e il criterio del traffico vengono gestiti in un'unica posizione sul gateway in entrata del mesh.

Ingress e servizi GKE

Puoi fornire accesso alle applicazioni ai client esterni al cluster in molti modi. La tabella seguente elenca le primitive Kubernetes disponibili per il deployment dei bilanciatori del carico su Google Cloud. Il tipo di bilanciatore del carico che utilizzi per esporre le applicazioni ai client dipende in gran parte dal fatto che i client siano esterni o interni, il tipo di supporto di protocollo richiesto e se il mesh di servizi si estende su più cluster GKE o è contenuto in un unico cluster.

Tutti i tipi di bilanciatore del carico nella tabella seguente possono esporre applicazioni ospitate su rete mesh, a seconda del caso d'uso.

Risorsa GKE	Bilanciatore del carico basato su cloud	Caratteristiche
In entrata per bilanciatori del carico HTTP(S) esterni	Bilanciatore del carico HTTP(S) esterno	Proxy L7 nei punti di presenza (POP) perimetrali di Google VIP pubblico Ambito globale Cluster singolo
In entrata per bilanciatori del carico HTTP(S) interni	Bilanciatore del carico HTTP(S) interno	Proxy L7 all'interno della rete VPC (Virtual Private Cloud) VIP privato Ambito a livello di regione Cluster singolo
Servizio `LoadBalancer` esterno	Bilanciatore del carico di rete	Passthrough L4 presso i PoP di Edge Google VIP pubblico Ambito a livello di regione Cluster singolo
Servizio `LoadBalancer` interno	Bilanciatore del carico TCP/UDP interno	Passthrough L4 nella rete di routing VPC VIP privato Ambito a livello di regione Cluster singolo
Ingress multi-cluster (multi-cluster, ingresso esterno)	Bilanciatore del carico HTTP(S) esterno	Proxy L7 nei POP di Google perimetrali VIP pubblico Ambito globale Cluster multipli

Sebbene il bilanciatore del carico predefinito per Anthos Service Mesh sia il bilanciatore del carico TCP/UDP esterno, questo tutorial è incentrato sul bilanciatore del carico HTTP(S) esterno. Il bilanciatore del carico HTTP(S) esterno offre integrazione con servizi perimetrali come Identity-Aware Proxy (IAP), Google Cloud Armor e Cloud CDN, nonché una rete di proxy perimetrali distribuita a livello globale. La sezione successiva descrive l'architettura e i vantaggi dell'utilizzo di due livelli di bilanciamento del carico HTTP.

Cloud in entrata e mesh in entrata

Il deployment del bilanciamento del carico L7 esterno al mesh insieme a un livello di mesh mesh offre vantaggi significativi, soprattutto per il traffico Internet. Anche se i gateway in entrata di Anthos Service Mesh e Istio forniscono routing avanzato e gestione del traffico nel mesh, alcune funzioni sono servite meglio a livello della rete. Sfruttare il networking periferico a Internet tramite il bilanciatore del carico HTTP(S) esterno di Google Cloud può fornire vantaggi significativi, affidabilità o sicurezza relativi alla rete rispetto al traffico in entrata basato su mesh. Questi vantaggi includono:

Questo livello esterno di bilanciamento del carico L7 è denominato cloud in entrata perché è basato su bilanciatori del carico gestiti nel cloud anziché sui proxy self-hosted utilizzati da mesh ingress. La combinazione di Ingress Cloud e Mesh Ingress utilizza funzionalità complementari dell'infrastruttura Google Cloud e del mesh. Il seguente diagramma illustra come combinare le risorse cloud in entrata e mesh in entrata come due livelli di bilanciamento del carico per il traffico Internet.

Cloud ingress funge da gateway per il traffico esterno al mesh attraverso la rete VPC.

In questa topologia, il livello cloud in entrata il traffico proviene dall'esterno del mesh di servizi e lo indirizza al livello mesh in entrata. Il livello mesh in entrata indirizza quindi il traffico ai backend dell'applicazione mesh.

Topologia cloud e mesh in entrata

Questa sezione descrive i ruoli complementari che ogni livello in entrata assume quando li utilizzi insieme. Non si tratta di regole concrete, ma di linee guida che utilizzano i vantaggi di ogni livello. È probabile che le varianti di questo pattern siano basate sul tuo caso d'uso.

In entrata nel cloud. Se accoppiato con Ingress mesh, il livello Cloud Ingress è ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello in entrata di cloud è integrato con i prodotti di protezione DDoS, firewall cloud, autenticazione e crittografia a livello perimetrale, questo livello eccelle nell'esecuzione di questi servizi al di fuori del mesh. In genere la logica di routing è semplice per questo livello, ma può essere più complessa per gli ambienti multi-cluster e a più aree geografiche. A causa della funzione critica dei bilanciatori del carico rivolti a Internet, è probabile che il livello di traffico in entrata nel cloud sia gestito da un team di infrastruttura che ha il controllo esclusivo su come le applicazioni sono esposte e protette su Internet. Questo controllo rende inoltre questo livello meno flessibile e dinamico rispetto a un'infrastruttura gestita da sviluppatori, una considerazione che potrebbe influire su chi e come fornisci accesso amministrativo a questo livello.
Rete mesh in entrata. Se abbinato al cloud ingress, il livello mesh in entrata offre un routing flessibile vicino all'applicazione. Grazie a questa flessibilità, il traffico in entrata nel mesh è migliore rispetto al traffico in entrata nel cloud per una logica di routing complessa e la visibilità a livello di applicazione. La separazione tra i livelli in entrata semplifica inoltre il controllo di questo livello da parte dei proprietari delle applicazioni senza influire sugli altri team. Quando esponi le applicazioni mesh di servizi tramite un bilanciatore del carico L4 anziché un bilanciatore del carico L7, devi terminare il client TLS a livello di mesh mesh all'interno del mesh per proteggere le applicazioni.

Controllo di integrità

Una complessità dell'utilizzo di due livelli di bilanciamento del carico L7 è il controllo di integrità. Devi configurare ogni bilanciatore del carico per controllare l'integrità del livello successivo e assicurarti che possa ricevere traffico. La topologia nel seguente diagramma mostra come il traffico in entrata nel cloud controlla l'integrità dei proxy in entrata nel mesh, mentre il mesh controlla in cambio l'integrità dei backend dell'applicazione.

Cloud ingress controlla l'integrità del traffico mesh in entrata e quest'ultimo controlla l'integrità dei backend dell'applicazione.

Questa topologia prevede le seguenti considerazioni:

In entrata nel cloud. In questo tutorial, configurerai il bilanciatore del carico Google Cloud attraverso il traffico in entrata per verificare l'integrità dei proxy in entrata del mesh sulle porte di controllo di integrità esposte. Se un proxy mesh non è attivo o se il cluster, il mesh o l'area geografica non sono disponibili, il bilanciatore del carico di Google Cloud rileva questa condizione e non invia traffico al proxy mesh.
Rete mesh in entrata. Nell'applicazione mesh, esegui controlli di integrità direttamente sui backend per poter eseguire il bilanciamento del carico e la gestione del traffico in locale.

Sicurezza

La precedente topologia prevede diversi elementi di sicurezza. Uno degli elementi più critici riguarda la configurazione della crittografia e il deployment dei certificati. Il traffico in entrata per bilanciatori del carico HTTP(S) esterni ha un'integrazione completa con i certificati gestiti da Google. Questa integrazione esegue automaticamente il provisioning dei certificati pubblici, li collega a un bilanciatore del carico e rinnova e ruota i certificati tramite l'interfaccia dichiarativa di GKE Ingress. I client Internet eseguono l'autenticazione sui certificati pubblici e si connettono al bilanciatore del carico esterno come primo hop nel Virtual Private Cloud (VPC).

L'hop successivo, che è tra il Google Front End (GFE) e il proxy in entrata del mesh, viene criptato per impostazione predefinita. La crittografia a livello di rete tra GFE e i relativi backend viene applicata automaticamente. Tuttavia, se i requisiti di sicurezza richiedono che il proprietario della piattaforma mantenga la proprietà delle chiavi di crittografia, puoi attivare HTTP/2 con la crittografia TLS tra il cluster in entrata (GFE) e il mesh in entrata (l'istanza proxy envoy). Quando abiliti HTTP/2 con crittografia TLS per questo percorso, puoi utilizzare un certificato autofirmato o pubblico per criptare il traffico perché GFE non lo autentica. Questo livello aggiuntivo di crittografia è illustrato in questa guida. Per evitare problemi di gestione dei certificati, non utilizzare altrove il certificato pubblico per il bilanciatore del carico pubblico. Ti consigliamo invece di utilizzare certificati separati nel mesh di servizi.

Se il mesh di servizi impone TLS, tutto il traffico viene criptato tra i proxy sidecar e nel mesh in entrata. Il seguente diagramma illustra la crittografia HTTPS dal client al bilanciatore del carico di Google Cloud, dal bilanciatore del carico al proxy in entrata del mesh e dal proxy in entrata al proxy sidecar.

La sicurezza viene implementata utilizzando certificati gestiti all'esterno del mesh e certificati interni all'interno del mesh.

Obiettivi

Eseguire il deployment di un cluster Google Kubernetes Engine (GKE) su Google Cloud.
Esegui il deployment di un Anthos Service Mesh basato su Istio sul tuo cluster GKE.
Configurare Ingress Ingress di GKE per terminare il traffico HTTPS pubblico e indirizzarlo alle applicazioni ospitate dal mesh di servizi.
Esegui il deployment dell'applicazione Boutique online sul cluster GKE che mostri ai client su Internet.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

Vai al selettore progetti
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
Nella console Google Cloud, attiva Cloud Shell.

Attiva Cloud Shell

Esegui tutti i comandi del terminale per questo tutorial da Cloud Shell.
Esegui l'upgrade all'ultima versione di Google Cloud CLI:
```
gcloud components update
```

Imposta il tuo progetto Google Cloud predefinito:

export PROJECT=PROJECT
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
gcloud config set project ${PROJECT}

Sostituisci PROJECT con l'ID progetto che vuoi utilizzare per questo tutorial.

Crea una directory di lavoro:
```
mkdir -p ${HOME}/edge-to-mesh
cd ${HOME}/edge-to-mesh
export WORKDIR=`pwd`
```
Una volta terminato il tutorial, puoi eliminare la directory di lavoro.

Creazione di cluster GKE

Le funzionalità descritte in questo tutorial richiedono un cluster GKE versione 1.16 o successiva.

In Cloud Shell, crea un nuovo file kubeconfig. Questo passaggio garantisce che non venga creato un conflitto con il file kubeconfig (predefinito) esistente.
```
touch edge2mesh_kubeconfig
export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
```

Definisci le variabili di ambiente per il cluster GKE:

export CLUSTER_NAME=edge-to-mesh
export CLUSTER_LOCATION=us-west1-a

Abilitare l'API Google Kubernetes Engine.

gcloud

gcloud services enable container.googleapis.com

Config Connector

Questo tutorial include le risorse di Config Connector. Puoi utilizzare queste risorse per svolgere le stesse attività che completi nella scheda gcloud. Per utilizzare queste risorse, installa Config Connector e applicale nel modo più adatto per il tuo ambiente.

Utilizza il seguente manifest Services:

apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: container.googleapis.com
spec:
  resourceID: container.googleapis.com
  projectRef:
    external: PROJECT

Creare un cluster GKE.

gcloud

gcloud container clusters create ${CLUSTER_NAME} \
    --machine-type=e2-standard-4 \
    --num-nodes=4 \
    --zone ${CLUSTER_LOCATION} \
    --enable-ip-alias \
    --workload-pool=${PROJECT}.svc.id.goog \
    --release-channel rapid \
    --addons HttpLoadBalancing \
    --labels mesh_id=proj-${PROJECT_NUMBER}

Config Connector

Utilizza i seguenti manifest ContainerCluster e ContainerNodePool:

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerNodePool
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
  name: edge-to-mesh
spec:
  clusterRef:
    name: edge-to-mesh
  location: us-west1-a
  nodeConfig:
    machineType: e2-standard-4
  nodeCount: 4
---
apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
    cnrm.cloud.google.com/remove-default-node-pool: "true"
  labels:
    mesh_id: proj-PROJECT_NUMBER
  name: edge-to-mesh
spec:
  addonsConfig:
    httpLoadBalancing:
      disabled: false
  location: us-west1-a
  initialNodeCount: 1
  releaseChannel:
    channel: RAPID
  workloadIdentityConfig:
    workloadPool: PROJECT.svc.id.goog

Sostituisci PROJECT_NUMBER con il valore della variabile di ambiente PROJECT_NUMBER recuperata in precedenza.

Per utilizzare un traffico in entrata nel cloud, devi avere abilitato il componente aggiuntivo di bilanciamento del carico HTTP. Nei cluster GKE è abilitato il bilanciamento del carico HTTP per impostazione predefinita, ma non devi disabilitarlo.

Per utilizzare Anthos Service Mesh gestito, devi applicare l'etichetta mesh_id nel cluster.

Assicurati che il cluster sia in esecuzione:

gcloud container clusters list

L'output è simile al seguente:

NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
edge-to-mesh  us-west1-a  v1.22.6-gke.300   35.233.195.59  e2-standard-4  v1.22.6-gke.300   4          RUNNING

Connettiti al cluster:

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION} \
    --project ${PROJECT}

Installazione di un mesh di servizi

In questa sezione configurerai l'API Anthos Service Mesh gestita con parco risorse.

Abilita le API richieste:

gcloud

gcloud services enable mesh.googleapis.com

Config Connector

Utilizza il seguente manifest Services:

apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: mesh.googleapis.com
spec:
  resourceID: mesh.googleapis.com
  projectRef:
    external: PROJECT

Abilita Anthos Service Mesh nel parco risorse:

gcloud

gcloud container fleet mesh enable

Config Connector

Utilizza il seguente manifest GKEHubFeature:

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeature
metadata:
  name: servicemesh
spec:
  projectRef:
    external: PROJECT
  location: global
  resourceID: servicemesh

Registra il cluster nel parco risorse:

gcloud

gcloud container fleet memberships register ${CLUSTER_NAME} \
    --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME} \
    --enable-workload-identity

Config Connector

Utilizza il seguente manifest GKEHubMembership:

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubMembership
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
  name: edge-to-mesh
spec:
  location: global
  authority:
    issuer: https://container.googleapis.com/v1/projects/PROJECT/locations/us-west1-a/clusters/edge-to-mesh
  endpoint:
    gkeCluster:
      resourceRef:
        name: edge-to-mesh

Abilita la gestione automatica del piano di controllo e il piano dati gestito:

gcloud

gcloud container fleet mesh update \
    --management automatic \
    --memberships ${CLUSTER_NAME}

Config Connector

Utilizza il seguente manifest GKEHubFeatureMembership:

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeatureMembership
metadata:
  name: servicemesh-membership
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  membershipRef:
    name: edge-to-mesh
  featureRef:
    name: servicemesh
  mesh:
    management: MANAGEMENT_AUTOMATIC

Dopo qualche minuto, verifica che lo stato del piano di controllo sia ACTIVE:

gcloud container fleet mesh describe

L'output è simile al seguente:

...
membershipSpecs:
  projects/841956571429/locations/global/memberships/edge-to-mesh:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/841956571429/locations/global/memberships/edge-to-mesh:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-rapid'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'
      updateTime: '2022-09-29T05:30:28.320896186Z'
name: projects/your-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
...

Deployment di GKE Ingress

Nei passaggi seguenti, eseguirai il deployment del bilanciatore del carico HTTP(S) esterno tramite il controller Ingress di GKE. La risorsa Ingress automatizza il provisioning del bilanciatore del carico, i relativi certificati TLS e il controllo di integrità del backend. Inoltre, utilizzi Cloud Endpoints per eseguire automaticamente il provisioning di un nome DNS pubblico per l'applicazione.

Installare un gateway in entrata

Come best practice per la sicurezza, ti consigliamo di eseguire il deployment del gateway in entrata in uno spazio dei nomi diverso dal piano di controllo.

In Cloud Shell, crea uno spazio dei nomi asm-ingress dedicato:
```
kubectl create namespace asm-ingress
```
Aggiungi un'etichetta dello spazio dei nomi allo spazio dei nomi asm-ingress:
```
kubectl label namespace asm-ingress istio-injection=enabled
```
L'output è simile al seguente:
```
namespace/asm-ingress labeled
```
L'etichettatura dello spazio dei nomi asm-ingress con istio-injection=enabled indica a Anthos Service Mesh di inserire automaticamente i proxy sidecar Envoy quando viene eseguito il deployment di un'applicazione.

Esegui il comando seguente per creare il manifest Deployment come ingress-deployment.yaml:

cat <<EOF > ingress-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        asm: ingressgateway
    spec:
      securityContext:
        fsGroup: 1337
        runAsGroup: 1337
        runAsNonRoot: true
        runAsUser: 1337
      containers:
      - name: istio-proxy
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - all
          privileged: false
          readOnlyRootFilesystem: true
        image: auto # The image will automatically update each time the pod starts.
        resources:
          limits:
            cpu: 2000m
            memory: 1024Mi
          requests:
            cpu: 100m
            memory: 128Mi
      serviceAccountName: asm-ingressgateway
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  maxReplicas: 5
  minReplicas: 3
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: asm-ingressgateway
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: asm-ingressgateway
subjects:
  - kind: ServiceAccount
    name: asm-ingressgateway
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
EOF

Deployment ha un proprio ServiceAccount con Role e RoleBinding associati, che consentono al gateway di accedere ai certificati.

Esegui il deployment di ingress-deployment.yaml nel cluster per creare la risorsa Deployment:

kubectl apply -f ingress-deployment.yaml

L'output è simile al seguente:

deployment.apps/asm-ingressgateway configured
role.rbac.authorization.k8s.io/asm-ingressgateway configured
rolebinding.rbac.authorization.k8s.io/asm-ingressgateway configured
serviceaccount/asm-ingressgateway created

Assicurati che tutti i deployment siano in esecuzione:

kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress

L'output è simile al seguente:

deployment.apps/asm-ingressgateway condition met

Esegui il comando seguente per creare il manifest Service come ingress-service.yaml:
```
cat <<EOF > ingress-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
    cloud.google.com/app-protocols: '{"https":"HTTP2"}' # HTTP/2 with TLS encryption
  labels:
    asm: ingressgateway
spec:
  ports:
  # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks
  - name: status-port
    port: 15021
    protocol: TCP
    targetPort: 15021
  # Any ports exposed in Gateway resources should be exposed here.
  - name: http2
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8443
  selector:
    asm: ingressgateway
  type: ClusterIP
EOF
```
Questo elemento Service ha le seguenti annotazioni che impostano i parametri per il bilanciatore del carico in entrata al momento del deployment:
- cloud.google.com/backend-config si riferisce al nome della risorsa personalizzata BackendConfig. Il controller Ingress utilizza BackendConfig per impostare i parametri nella risorsa BackendServiceGoogle Cloud. Utilizza questa risorsa nel passaggio successivo per definire i parametri personalizzati del controllo di integrità di Google Cloud.
- cloud.google.com/neg: '{"ingress": true}' abilita i backend di Ingress (i proxy in entrata della rete in questo caso) per il bilanciamento del carico nativo del container. Per un bilanciamento del carico più efficiente e stabile, questi backend utilizzano gruppi di endpoint di rete (NEG) anziché gruppi di istanze.
- cloud.google.com/app-protocols: '{"https":"HTTP2"}' indica al GFE di connettersi al gateway in entrata del mesh di servizi utilizzando HTTP2 con TLS, come descritto in Ingresso per il bilanciamento del carico HTTP(S) esterno e Panoramica del bilanciamento del carico HTTP(S) esterno, per un ulteriore livello di crittografia.
Esegui il deployment di ingress-service.yaml nel cluster per creare la risorsa Service:
```
kubectl apply -f ingress-service.yaml
```
L'output è simile al seguente:
```
service/asm-ingressgateway created
```

Applica impostazioni del servizio di backend

In Cloud Shell, esegui il comando seguente per creare il manifest BackendConfig come ingress-backendconfig.yaml:
```
cat <<EOF > ingress-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: ingress-backendconfig
  namespace: asm-ingress
spec:
  healthCheck:
    requestPath: /healthz/ready
    port: 15021
    type: HTTP
  securityPolicy:
    name: edge-fw-policy
EOF
```
BackendConfig è una definizione di risorsa personalizzata (CRD) che definisce i parametri di backend per il bilanciamento del carico Ingress. Per un elenco completo dei parametri di backend e frontend che puoi configurare tramite GKE Ingress, consulta Funzionalità di Ingress.

In questo tutorial, il manifest BackendConfig specifica i controlli di integrità personalizzati per i proxy in entrata del mesh. Anthos Service Mesh e Istio espongono i loro controlli di integrità del proxy sidecar sulla porta 15021 nel percorso /healthz/ready. I parametri del controllo di integrità personalizzati sono obbligatori perché la porta di gestione (443) dei proxy di rete mesh in entrata è diversa dalla porta di controllo di integrità (15021). GKE Ingress utilizza i seguenti parametri di controllo di integrità in BackendConfig per configurare i controlli di integrità del bilanciatore del carico di Google Cloud. Viene inoltre fatto riferimento a un criterio di sicurezza che contribuisce a proteggere il bilanciamento del carico del traffico da diversi tipi di attacchi di rete.
- healthCheck.port definisce la porta che riceve un controllo di integrità dal bilanciatore del carico di Google Cloud sull'indirizzo IP di ciascun pod.
- healthCheck.requestPath definisce il percorso HTTP che riceve un controllo di integrità sulla porta specificata.
- type definisce il protocollo del controllo di integrità (in questo caso, HTTP).
- securityPolicy.name si riferisce al nome del criterio di sicurezza di Cloud Armor.
Esegui il deployment di ingress-backendconfig.yaml nel cluster per creare la risorsa BackendConfig:
```
kubectl apply -f ingress-backendconfig.yaml
```
L'output è simile al seguente:
```
backendconfig.cloud.google.com/ingress-backendconfig created
```
I parametri BackendConfig e le annotazioni di servizio asm-ingressgateway non vengono applicati a un bilanciatore del carico Google Cloud fino al deployment della risorsa Ingress. Il deployment Ingress collega tutte queste risorse.

Definire i criteri di sicurezza

Google Cloud Armor fornisce funzionalità di difesa DDoS e criteri di sicurezza personalizzabili da collegare a un bilanciatore del carico tramite risorse Ingress. Nei passaggi seguenti crei un criterio di sicurezza che utilizza regole preconfigurate per bloccare gli attacchi cross-site scripting (XSS). Questa regola consente di bloccare il traffico che corrisponde alle firme di attacco note ma consente tutto il resto del traffico. Il tuo ambiente potrebbe utilizzare regole diverse a seconda del carico di lavoro.

gcloud

In Cloud Shell, crea un criterio di sicurezza denominato edge-fw-policy:

gcloud compute security-policies create edge-fw-policy \
    --description "Block XSS attacks"

Crea una regola del criterio di sicurezza che utilizzi i filtri XSS preconfigurati:

gcloud compute security-policies rules create 1000 \
    --security-policy edge-fw-policy \
    --expression "evaluatePreconfiguredExpr('xss-stable')" \
    --action "deny-403" \
    --description "XSS attack filtering"

Config Connector

Utilizza il seguente manifest ComputeSecurityPolicy:

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSecurityPolicy
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: edge-fw-policy
spec:
  rule:
  - action: allow
    description: "Default rule"
    match:
      versionedExpr: SRC_IPS_V1
      config:
        srcIpRanges:
        - "*"
    priority: 2147483647
  - action: deny-403
    description: "XSS attack filtering"
    match:
      expr:
        expression: "evaluatePreconfiguredExpr('xss-stable')"
    priority: 1000

ingress-backendconfig ha fatto riferimento a edge-fw-policy nella sezione precedente. Quando viene eseguito il deployment della risorsa Ingress, questo criterio di sicurezza viene associato al bilanciatore del carico per proteggere qualsiasi backend del servizio asm-ingressgateway.

Configura indirizzi IP e DNS

In Cloud Shell, crea un IP statico globale per il bilanciatore del carico Google Cloud:
gcloud
```
gcloud compute addresses create ingress-ip --global
```
Config Connector
Utilizza il seguente manifest ComputeAddress:
```
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeAddress
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: ingress-ip
spec:
  location: global
```
Questo IP statico viene utilizzato dalla risorsa Ingress e consente all'IP di rimanere invariato, anche se il bilanciatore del carico esterno cambia.
Recupera l'indirizzo IP statico:
```
export GCLB_IP=$(gcloud compute addresses describe ingress-ip --global --format "value(address)")
echo ${GCLB_IP}
```
Per creare una mappatura stabile e facilmente leggibile sull'IP Ingress, devi avere un record DNS pubblico. Puoi utilizzare qualsiasi provider DNS e automazione di tuo interesse. Questo tutorial utilizza gli endpoint invece di creare una zona DNS gestita. Endpoints offre un record DNS gestito da Google gratuito per un IP pubblico.

Esegui questo comando per creare il file della specifica YAML denominato dns-spec.yaml:

cat <<EOF > dns-spec.yaml
swagger: "2.0"
info:
  description: "Cloud Endpoints DNS"
  title: "Cloud Endpoints DNS"
  version: "1.0.0"
paths: {}
host: "frontend.endpoints.${PROJECT}.cloud.goog"
x-google-endpoints:
- name: "frontend.endpoints.${PROJECT}.cloud.goog"
  target: "${GCLB_IP}"
EOF

La specifica YAML definisce il record DNS pubblico nel formato frontend.endpoints.${PROJECT}.cloud.goog, dove ${PROJECT} è il tuo numero di progetto univoco.

Esegui il deployment del file dns-spec.yaml nel tuo progetto Google Cloud:

gcloud endpoints services deploy dns-spec.yaml

L'output è simile al seguente:

Operation finished successfully. The following command can describe the Operation details:
 gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08

Service Configuration [2021-11-14r0] uploaded for service [frontend.endpoints.edge2mesh.cloud.goog]

Ora che IP e DNS sono configurati, puoi generare un certificato pubblico per proteggere il frontend Ingress. GKE Ingress supporta i certificati gestiti da Google come risorse Kubernetes, che ti permettono di eseguirne il provisioning tramite metodi dichiarativi.

Esegui il provisioning di un certificato TLS

In Cloud Shell, esegui il comando seguente per creare il manifest ManagedCertificate come managed-cert.yaml:
```
cat <<EOF > managed-cert.yaml
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: gke-ingress-cert
  namespace: asm-ingress
spec:
  domains:
    - "frontend.endpoints.${PROJECT}.cloud.goog"
EOF
```
Questo file YAML specifica che il nome DNS creato tramite endpoint viene utilizzato per eseguire il provisioning di un certificato pubblico. Poiché Google gestisce completamente il ciclo di vita di questi certificati pubblici, questi vengono generati e ruotati automaticamente su base regolare senza intervento diretto da parte dell'utente.

Esegui il deployment del file managed-cert.yaml nel cluster GKE:

kubectl apply -f managed-cert.yaml

L'output è simile al seguente:

managedcertificate.networking.gke.io/gke-ingress-cert created

Ispeziona la risorsa ManagedCertificate per verificare l'avanzamento della generazione del certificato:

kubectl describe managedcertificate gke-ingress-cert -n asm-ingress

L'output è simile al seguente:

Name:         gke-ingress-cert
Namespace:    asm-ingress
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"networking.gke.io/v1","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"...
API Version:  networking.gke.io/v1
Kind:         ManagedCertificate
Metadata:
  Creation Timestamp:  2020-08-05T20:44:49Z
  Generation:          2
  Resource Version:    1389781
  Self Link:           /apis/networking.gke.io/v1/namespaces/asm-ingress/managedcertificates/gke-ingress-cert
  UID:                 d74ec346-ced9-47a8-988a-6e6e9ddc4019
Spec:
  Domains:
    frontend.endpoints.edge2mesh.cloud.goog
Status:
  Certificate Name:    mcrt-306c779e-8439-408a-9634-163664ca6ced
  Certificate Status:  Provisioning
  Domain Status:
    Domain:  frontend.endpoints.edge2mesh.cloud.goog
    Status:  Provisioning
Events:
  Type    Reason  Age   From                            Message
  ----    ------  ----  ----                            -------
  Normal  Create  44s   managed-certificate-controller  Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced

Quando il certificato è pronto, Certificate Status è Active.

Esegui il deployment della risorsa Ingress

In Cloud Shell, esegui il comando seguente per creare il manifest Ingress come ingress.yaml:
```
cat <<EOF > ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gke-ingress
  namespace: asm-ingress
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
    networking.gke.io/managed-certificates: "gke-ingress-cert"
    kubernetes.io/ingress.class: "gce"
spec:
  defaultBackend:
    service:
      name: asm-ingressgateway
      port:
        number: 443
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: asm-ingressgateway
            port:
              number: 443
EOF
```
Questo manifest definisce una risorsa Ingress che associa tutte le risorse precedenti. Il manifest specifica i seguenti campi:
- kubernetes.io/ingress.allow-http: "false" disabilita il traffico HTTP sulla porta 80 del bilanciatore del carico Google Cloud. In questo modo, impedisci ai client di connettersi con traffico non criptato perché la porta 443 ascolta solo HTTPS e la porta 80 è disabilitata.
- kubernetes.io/ingress.global-static-ip-name: "ingress-ip" collega l'indirizzo IP creato in precedenza con il bilanciatore del carico. Questo link consente di creare l'indirizzo IP separatamente dal bilanciatore del carico, in modo da poter essere riutilizzato separatamente dal ciclo di vita del bilanciatore del carico.
- networking.gke.io/managed-certificates: "gke-ingress-cert" collega questo bilanciatore del carico alla risorsa del certificato SSL gestita da Google creata in precedenza.
Esegui il deployment di ingress.yaml nel cluster:
```
kubectl apply -f ingress.yaml
```

Ispeziona la risorsa Ingress per verificare l'avanzamento del deployment del bilanciatore del carico:

kubectl describe ingress gke-ingress -n asm-ingress

L'output è simile al seguente:

...
Annotations:
  ingress.kubernetes.io/https-forwarding-rule:       k8s2-fs-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/ssl-cert:                    mcrt-306c779e-8439-408a-9634-163664ca6ced
  networking.gke.io/managed-certificates:            gke-ingress-cert
  kubernetes.io/ingress.global-static-ip-name:  ingress-ip
  ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-306c779e-8439-408a-9634-163664ca6ced
  ingress.kubernetes.io/backends:               {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-asm-ingress-asm-ingressgateway-443-228c1881":"HEALTHY"}
  ingress.kubernetes.io/forwarding-rule:        k8s2-fr-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/https-target-proxy:     k8s2-ts-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/target-proxy:           k8s2-tp-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/url-map:                k8s2-um-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
...

La risorsa Ingress è pronta quando le annotazioni ingress.kubernetes.io/backends indicano che i backend sono HEALTHY. Le annotazioni mostrano anche i nomi di diverse risorse Google Cloud di cui è stato eseguito il provisioning, inclusi servizi di backend, certificati SSL e proxy di destinazione HTTPS.

Installare il certificato del gateway in entrata autofirmato

Nei passaggi seguenti, generi e installi un certificato (come risorsa secret di Kubernetes) che consente al GFE di stabilire una connessione TLS al gateway in entrata del mesh di servizi. Per ulteriori dettagli sui requisiti del certificato del gateway in entrata, consulta la guida alle considerazioni sul protocollo di backend sicuro.

In Cloud Shell, crea la chiave e il certificato privati utilizzando openssl:

openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
 -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
 -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
 -out frontend.endpoints.${PROJECT}.cloud.goog.crt

Crea Secret nello spazio dei nomi asm-ingress:

kubectl -n asm-ingress create secret tls edge2mesh-credential \
 --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
 --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt

Configura il gateway in entrata per il bilanciamento del carico esterno

Nei passaggi seguenti crei una risorsa condivisa Gateway nello spazio dei nomi asm-ingress. In genere i gateway sono di proprietà degli amministratori di rete o degli amministratori della piattaforma. Di conseguenza, la risorsa Gateway viene creata nello spazio dei nomi asm-ingress di proprietà dell'amministratore della piattaforma e potrebbe essere utilizzato in altri spazi dei nomi con le proprie voci VirtualService.

In Cloud Shell, esegui il comando seguente per creare il manifest Gateway come ingress-gateway.yaml:
```
cat <<EOF > ingress-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
    name: asm-ingressgateway
    namespace: asm-ingress
spec:
  selector:
    asm: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below
    tls:
      mode: SIMPLE
      credentialName: edge2mesh-credential
EOF
```
Tieni presente che devi utilizzare la voce con carattere jolly * nel campo hosts in Gateway. GCLB non utilizza l'estensione SNI nei backend. L'utilizzo della voce con carattere jolly invia il pacchetto criptato (da GCLB) al gateway in entrata ASM. Il gateway Ingress ASM decripta il pacchetto e utilizza l'intestazione host HTTP (nel pacchetto decriptato) per prendere decisioni di routing (in base alle voci VirtualService).

Esegui il deployment di ingress-gateway.yaml nel cluster:

kubectl apply -f ingress-gateway.yaml

L'output è simile al seguente:

gateway.networking.istio.io/asm-ingressgateway created

Installazione dell'app Online Boutique di esempio

In Cloud Shell, crea uno spazio dei nomi onlineboutique dedicato:
```
kubectl create namespace onlineboutique
```
Aggiungi un'etichetta dello spazio dei nomi allo spazio dei nomi onlineboutique:
```
kubectl label namespace onlineboutique istio-injection=enabled
```
L'output è simile al seguente:
```
namespace/onlineboutique labeled
```
L'etichettatura dello spazio dei nomi onlineboutique con istio-injection=enabled indica a Anthos Service Mesh di inserire automaticamente i proxy sidecar Envoy quando viene eseguito il deployment di un'applicazione.

Scarica i file YAML di Kubernetes per l'app di esempio Online Boutique:

curl -LO \
    https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml

Esegui il deployment dell'app Boutique online:

kubectl apply -f kubernetes-manifests.yaml -n onlineboutique

L'output è simile al seguente:

deployment.apps/frontend created
service/frontend created
service/frontend-external created
...

Assicurati che tutti i deployment siano in esecuzione:

kubectl get pods -n onlineboutique

L'output è simile al seguente:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-d854d8786-fjb7q                2/2     Running   0          3m
cartservice-85b5d5b4ff-8qn7g             2/2     Running   0          2m59s
checkoutservice-5f9bf659b8-sxhsq         2/2     Running   0          3m1s
...

Esegui il comando seguente per creare il manifest VirtualService come frontend-virtualservice.yaml:
```
cat <<EOF > frontend-virtualservice.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend-ingress
  namespace: onlineboutique
spec:
  hosts:
  - "frontend.endpoints.${PROJECT}.cloud.goog"
  gateways:
  - asm-ingress/asm-ingressgateway
  http:
  - route:
    - destination:
        host: frontend
        port:
          number: 80
EOF
```
Tieni presente che VirtualService viene creato nello spazio dei nomi dell'applicazione (onlineboutique). In genere, il proprietario dell'applicazione decide e configura come e quale traffico viene indirizzato all'applicazione frontend in modo che VirtualService venga eseguito dal proprietario dell'applicazione.

Esegui il deployment di frontend-virtualservice.yaml nel cluster:

kubectl apply -f frontend-virtualservice.yaml

L'output è simile al seguente:

virtualservice.networking.istio.io/frontend-virtualservice created

Accedi al seguente link:
```
echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
```
Viene visualizzato il frontend della tua boutique online.

Nota: potresti ricevere un errore ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Questo errore si verifica quando i certificati non sono ancora stati propagati a tutti i front-end (GFE) di Google a livello globale. Attendi qualche minuto e riprova a eseguire il link.
Per visualizzare i dettagli del certificato, fai clic su Visualizza informazioni sul sito nella barra degli indirizzi del browser, quindi fai clic su Certificato (valido).

Il visualizzatore certificati mostra i dettagli del certificato gestito, tra cui la data di scadenza e l'autore del certificato.

Ora hai un bilanciatore del carico HTTPS globale che funge da frontend per la tua applicazione ospitata dal mesh di servizi.

Esegui la pulizia

Una volta completato il tutorial, puoi eseguire la pulizia delle risorse che hai creato su Google Cloud per non ricevere addebiti in futuro. Puoi eliminare completamente il progetto o eliminare le risorse del cluster, quindi eliminare il cluster.

Elimina il progetto

Nella console Google Cloud, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Eliminare le singole risorse

Se vuoi mantenere il progetto Google Cloud che hai utilizzato in questo tutorial, elimina le singole risorse:

Elimina la risorsa Ingress:
```
kubectl delete -f ingress.yaml
```
Elimina il certificato gestito:
```
kubectl delete -f managed-cert.yaml
```

Elimina la voce DNS Endpoints:

gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"

L'output è simile al seguente:

Are you sure? This will set the service configuration to be deleted, along
with all of the associated consumer information. Note: This does not
immediately delete the service configuration or data and can be undone using
the undelete command for 30 days. Only after 30 days will the service be
purged from the system.

Quando ti viene chiesto di continuare, inserisci Y.

L'output è simile al seguente:

Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
Operation finished successfully. The following command can describe the Operation details:
 gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5

Elimina l'indirizzo IP statico:

gcloud compute addresses delete ingress-ip --global

L'output è simile al seguente:

The following global addresses will be deleted:

 - [ingress-ip]

Quando ti viene chiesto di continuare, inserisci Y.

L'output è simile al seguente:

Deleted
[https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].

Elimina il cluster GKE:

gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION

Passaggi successivi

Scopri altre funzionalità offerte da GKE Ingress che puoi utilizzare con il tuo mesh di servizi.
Scopri di più sui diversi tipi di bilanciamento del carico del cloud disponibili per GKE.
Scopri le funzionalità e funzionalità offerte da Anthos Service Mesh.
Scopri come eseguire il deployment della risorsa Ingress su più cluster GKE per il bilanciamento del carico a livello di più aree geografiche.
Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Centro di architettura cloud.