Configurazione di Ingress per i bilanciatori del carico delle applicazioni interni

Questa pagina mostra come configurare e utilizzare Ingress per i bilanciatori del carico delle applicazioni interni in Google Kubernetes Engine (GKE). Ingress fornisce il supporto integrato per il bilanciamento del carico interno tramite il controller GKE Ingress.

Per scoprire di più sulle funzionalità supportate per Ingress per i bilanciatori del carico delle applicazioni interni, consulta Funzionalità Ingress. Puoi anche scoprire di più su come funziona Ingress per i bilanciatori del carico delle applicazioni interni in Ingress per i bilanciatori del carico delle applicazioni interni.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Requisiti

Ingress per i bilanciatori del carico delle applicazioni interni presenta i seguenti requisiti:

• Il cluster deve utilizzare una versione di GKE successiva alla 1.16.5-gke.10.
• Il cluster deve essere nativo di VPC.
• Il cluster deve avere il componente aggiuntivo HttpLoadBalancing abilitato. Questo componente aggiuntivo è attivato per impostazione predefinita. Non devi disattivarlo.
• Devi utilizzare i gruppi di endpoint di rete (NEG) come backend per il tuo servizio.

Deployment di Ingress per i bilanciatori del carico delle applicazioni interni

I seguenti esercizi mostrano come eseguire il deployment di Ingress per i bilanciatori del carico delle applicazioni interni:

1. Prepara l'ambiente.
2. Crea un cluster.
3. Esegui il deployment di un'applicazione.
4. Esegui il deployment di un servizio.
5. Esegui il deployment di Ingress.
6. Convalida il deployment.
7. Elimina le risorse Ingress.

prepara l'ambiente

Prima di poter eseguire il deployment delle risorse del bilanciatore del carico tramite l'API Kubernetes Ingress, devi preparare il tuo ambiente di rete in modo che i proxy del bilanciatore del carico possano essere sottoposti a deployment in una determinata regione.

Crea una subnet solo proxy:

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23

Sostituisci quanto segue:

• COMPUTE_REGION: una regione Compute Engine.
• NETWORK_NAME: il nome della rete per la subnet.

Per ulteriori informazioni, consulta la pagina relativa alla configurazione della subnet solo proxy.

Crea una regola firewall

Il controller Ingress non crea una regola firewall per consentire le connessioni dai proxy del bilanciatore del carico nella subnet proxy. Devi creare manualmente questa regola firewall. Tuttavia, il controller Ingress crea regole firewall per consentire l'ingresso per i controlli di integrità. Google Cloud

Crea una regola firewall per consentire le connessioni dai proxy del bilanciatore del carico nella subnet solo proxy alla porta di ascolto del pod:

gcloud compute firewall-rules create allow-proxy-connection \
    --allow=TCP:CONTAINER_PORT \
    --source-ranges=10.129.0.0/23 \
    --network=NETWORK_NAME

Sostituisci CONTAINER_PORT con il valore della porta su cui il pod è in ascolto, ad esempio 9376.

Creazione di un cluster

In questa sezione, creerai un cluster nativo di VPC che puoi utilizzare con Ingress per i bilanciatori del carico delle applicazioni interni. Puoi creare questo cluster utilizzando Google Cloud CLI o la console Google Cloud .

gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME

Deployment di un'applicazione web

In questa sezione, creerai un deployment.

Per creare un deployment:

1. Salva il seguente manifest di esempio come web-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: hostname
     name: hostname-server
   spec:
     selector:
       matchLabels:
         app: hostname
     minReadySeconds: 60
     replicas: 3
     template:
       metadata:
         labels:
           app: hostname
       spec:
         containers:
         - image: registry.k8s.io/serve_hostname:v1.4
           name: hostname-server
           ports:
           - containerPort: 9376
             protocol: TCP
         terminationGracePeriodSeconds: 90
   

   Questo manifest descrive un deployment che rimane in ascolto su un server HTTPS sulla porta 9376. Questo deployment gestisce anche i pod per la tua applicazione. Ogni pod esegue un container dell'applicazione con un server HTTPS che restituisce il nome host del server delle applicazioni come risposta. Il nome host predefinito di un pod è il nome del pod. Il container gestisce anche la terminazione controllata.

2. Applica il manifest al cluster:

   kubectl apply -f web-deployment.yaml
   

Deployment di un servizio come gruppo di endpoint di rete (NEG)

In questa sezione creerai una risorsa Service. Il servizio seleziona i container di backend in base alle etichette in modo che il controller Ingress possa programmarli come endpoint di backend. Ingress per i bilanciatori del carico delle applicazioni interni richiede l'utilizzo di NEG come backend. La funzionalità non supporta i gruppi di istanze come backend. Poiché sono necessari i backend NEG, la seguente annotazione NEG è obbligatoria quando esegui il deployment dei servizi esposti tramite Ingress:

annotations:
  cloud.google.com/neg: '{"ingress": true}'

Il tuo servizio viene annotato automaticamente con cloud.google.com/neg: '{"ingress": true}' quando tutte le seguenti condizioni sono vere:

• Stai utilizzando cluster nativi di VPC.
• Non utilizzi un VPC condiviso.
• Non utilizzi GKE Network Policy.

L'annotazione viene aggiunta automaticamente utilizzando un MutatingWebhookConfiguration con il nome neg-annotation.config.common-webhooks.networking.gke.io. Puoi controllare se MutatingWebhookConfiguration è presente con il seguente comando:

kubectl get mutatingwebhookconfigurations

L'utilizzo dei NEG consente al controller Ingress di eseguire il bilanciamento del carico nativo del container. Il traffico viene bilanciato dal carico dal proxy Ingress direttamente all'IP del pod anziché attraversare l'IP del nodo o la rete kube-proxy. Inoltre, i gate di idoneità dei pod vengono implementati per determinare l'integrità dei pod dal punto di vista del bilanciatore del carico e non solo dei controlli di idoneità e attività di Kubernetes. I gate di idoneità del pod assicurano che il traffico non venga eliminato durante gli eventi del ciclo di vita, come l'avvio del pod, la perdita del pod o la perdita del nodo.

Se non includi un'annotazione NEG, ricevi un avviso sull'oggetto Ingress che ti impedisce di configurare il bilanciatore del carico delle applicazioni interno. Un evento Kubernetes viene generato anche sull'ingresso se l'annotazione NEG non è inclusa. Il seguente messaggio è un esempio di messaggio di evento:

Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"

Un NEG non viene creato finché un Ingress non fa riferimento al servizio. Il NEG non viene visualizzato in Compute Engine finché non esistono sia l'ingresso sia il servizio a cui fa riferimento. I NEG sono una risorsa di zona e per i cluster multizona ne viene creato uno per servizio per zona.

Per creare un servizio:

1. Salva il seguente manifest di esempio come web-service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: hostname
     namespace: default
     annotations:
       cloud.google.com/neg: '{"ingress": true}'
   spec:
     ports:
     - name: host1
       port: 80
       protocol: TCP
       targetPort: 9376
     selector:
       app: hostname
     type: ClusterIP
   

2. Applica il manifest al cluster:

   kubectl apply -f web-service.yaml
   

Deployment di Ingress

In questa sezione, creerai una risorsa Ingress che attiva il deployment di un bilanciatore del carico Compute Engine tramite il controller Ingress. Ingress per i bilanciatori del carico delle applicazioni interni richiede la seguente annotazione:

annotations:
    kubernetes.io/ingress.class: "gce-internal"

Non puoi utilizzare il campo ingressClassName per specificare un ingresso GKE. Devi utilizzare l'annotazione kubernetes.io/ingress.class. Per maggiori informazioni, vedi Comportamento del controller Ingress di GKE.

Per creare una risorsa Ingress:

1. Salva il seguente manifest di esempio come internal-ingress.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: ilb-demo-ingress
     namespace: default
     annotations:
       kubernetes.io/ingress.class: "gce-internal"
   spec:
     defaultBackend:
       service:
         name: hostname
         port:
           number: 80
   

2. Applica il manifest al cluster:

   kubectl apply -f internal-ingress.yaml
   

Convalida di un deployment Ingress riuscito

In questa sezione, puoi verificare se il deployment è andato a buon fine.

Il provisioning completo della risorsa Ingress può richiedere diversi minuti. Durante questo periodo, il controller Ingress crea elementi come regole di forwarding, servizi di backend, mappe URL e NEG.

Per recuperare lo stato della risorsa Ingress creata nella sezione precedente, esegui questo comando:

kubectl get ingress ilb-demo-ingress

L'output è simile al seguente:

NAME               HOSTS    ADDRESS            PORTS     AGE
ilb-demo-ingress   *        10.128.0.58        80        59s

Quando il campo ADDRESS è compilato, l'ingresso è pronto. L'utilizzo di un indirizzo RFC 1918 in questo campo indica un IP interno all'interno del VPC.

Poiché il bilanciatore del carico delle applicazioni interno è un bilanciatore del carico regionale, l'IP virtuale (VIP) è accessibile solo da un client all'interno della stessa regione e dello stesso VPC. Dopo aver recuperato il VIP del bilanciatore del carico, puoi utilizzare strumenti (ad esempio curl) per effettuare chiamate HTTP GET al VIP dall'interno del VPC.

Per effettuare una chiamata HTTP GET, completa i seguenti passaggi:

1. Per raggiungere il VIP Ingress dall'interno del VPC, implementa una VM nella stessa regione e rete del cluster:

   gcloud compute instances create l7-ilb-client \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=NETWORK_NAME \
       --subnet=SUBNET_NAME \
       --zone=COMPUTE_ZONE \
       --tags=allow-ssh
   

   Sostituisci quanto segue:

   • SUBNET_NAME: il nome di una subnet nella rete.
   • COMPUTE_ZONE: una zona di Compute Engine nella regione.

   Per scoprire di più sulla creazione di istanze, consulta Creazione e avvio di un'istanza VM.

2. Per accedere al VIP interno dall'interno della VM, utilizza curl:

   1. Connettiti tramite SSH alla VM che hai creato nel passaggio precedente:

      gcloud compute ssh l7-ilb-client \
          --zone=COMPUTE_ZONE
      

   2. Utilizza curl per accedere al VIP dell'applicazione interna:

      curl 10.128.0.58
      hostname-server-6696cf5fc8-z4788
      

      La risposta HTTP riuscita e il nome host di uno dei container di backend indicano che il percorso completo del bilanciamento del carico funziona correttamente.

Eliminazione delle risorse Ingress

La rimozione delle risorse Ingress e Service comporta anche la rimozione delle risorse bilanciatore del carico Compute Engine associate. Per evitare perdite di risorse, assicurati che le risorse Ingress vengano eliminate quando non ti servono più. Devi anche eliminare le risorse Ingress e Service prima di eliminare i cluster, altrimenti le risorse di bilanciamento del carico Compute Engine vengono orfanizzate.

Per rimuovere un Ingress, completa i seguenti passaggi:

1. Elimina l'oggetto Ingress. Ad esempio, per eliminare l'oggetto Ingress creato in questa pagina, esegui questo comando:

   kubectl delete ingress ilb-demo-ingress
   

   L'eliminazione di Ingress comporta la rimozione delle regole di forwarding, dei servizi di backend e delle mappe URL associate a questa risorsa Ingress.

2. Elimina il servizio. Ad esempio, per eliminare il servizio creato in questa pagina, esegui questo comando:

   kubectl delete service hostname
   

   L'eliminazione del servizio rimuove il NEG associato.

Per eseguire il deployment di un'applicazione su GKE ed esporla con un indirizzo IP privato bilanciato del carico, consulta Ingress interno di base.

Indirizzamento IP statico

Le risorse Ingress interne supportano l'indirizzamento IP sia statico sia temporaneo. Se non viene specificato un indirizzo IP, ne viene allocato automaticamente uno disponibile dalla subnet dei nodi GKE. Tuttavia, la risorsa Ingress non esegue il provisioning degli indirizzi IP dalla subnet solo proxy in quanto questa subnet viene utilizzata solo per il consumo del proxy interno. Questi indirizzi IP temporanei vengono allocati all'Ingress solo per il ciclo di vita della risorsa Ingress interna. Se elimini l'oggetto Ingress e ne crei uno nuovo dallo stesso file manifest, non è garantito che tu ottenga lo stesso indirizzo IP esterno.

Se vuoi un indirizzo IP permanente indipendente dal ciclo di vita della risorsa Ingress interna, devi prenotare un indirizzo IP interno statico regionale. Puoi quindi specificare un indirizzo IP statico utilizzando l'annotazione kubernetes.io/ingress.regional-static-ip-name nella risorsa Ingress.

Il seguente esempio mostra come aggiungere questa annotazione:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"

Sostituisci STATIC_IP_NAME con un nome IP statico che soddisfi i seguenti criteri:

• Crea l'indirizzo IP statico prima di eseguire il deployment dell'ingresso. Un bilanciatore del carico non viene implementato finché non esiste l'IP statico e il riferimento a una risorsa di indirizzo IP inesistente non crea un IP statico. Se modifichi un Ingress esistente in modo che utilizzi un indirizzo IP statico anziché un indirizzo IP temporaneo, GKE potrebbe modificare l'indirizzo IP del bilanciatore del carico quando ricrea la regola di forwarding del bilanciatore del carico.
• L'IP statico è riservato nel progetto di servizio per un Ingress di cui è stato eseguito il deployment nel progetto di servizio di un VPC condiviso.
• Fai riferimento alla risorsa indirizzo IP Google Cloud in base al nome, anziché all'indirizzo IP.
• L'indirizzo IP deve provenire da una subnet nella stessa regione del cluster GKE. Puoi utilizzare qualsiasi subnet privata disponibile all'interno della regione (ad eccezione della subnet solo proxy). Risorse Ingress diverse possono anche avere indirizzi di subnet diverse.

HTTPS tra client e bilanciatore del carico

Ingress per il bilanciamento del carico interno supporta la distribuzione di certificati TLS ai client. Puoi pubblicare certificati TLS tramite i secret Kubernetes o tramite certificati SSL regionali precondivisi in Google Cloud. Puoi anche specificare più certificati per risorsa Ingress. L'utilizzo simultaneo di HTTPS e HTTP è supportato per GKE 1.25+. Per abilitare questa funzionalità, devi creare un indirizzo IP statico con PURPOSE=SHARED_LOADBALANCER_VIP e configurarlo in Ingress. Se non viene fornito un indirizzo IP statico, è consentito solo il traffico HTTPS e devi seguire la documentazione per disattivare HTTP.

I seguenti passaggi descrivono in dettaglio come creare un certificato in Google Cloud e poi pubblicarlo tramite Ingress ai client interni per il traffico HTTPS e HTTP:

1. Crea il certificato regionale:

   gcloud compute ssl-certificates create CERT_NAME \
       --certificate CERT_FILE_PATH \
       --private-key KEY_FILE_PATH \
       --region COMPUTE_REGION
   

   Sostituisci quanto segue:

   • CERT_NAME: un nome a tua scelta per il certificato.
   • CERT_FILE_PATH: il percorso del file del certificato locale per creare un certificato autogestito. Il certificato deve essere in formato PEM.
   • KEY_FILE_PATH: il percorso di un file di chiave privata locale. La chiave privata deve essere in formato PEM e deve utilizzare la crittografia RSA o ECDSA.
   • COMPUTE_REGION: una regione Compute Engine per il tuo certificato.

2. Prenota e applica un indirizzo IP statico seguendo le istruzioni riportate in Indirizzamento IP statico.

3. Salva il seguente manifest di esempio come ingress-pre-shared-cert.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: ilb-demo-ing
     namespace: default
     annotations:
       ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME"
       kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
       kubernetes.io/ingress.class: "gce-internal"
   spec:
     rules:
     - host: DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: SERVICE_NAME
               port:
                 number: 80
   

   Sostituisci quanto segue:

   • DOMAIN: il tuo dominio.
   • CERT_NAME: il nome del certificato che hai creato nella sezione precedente.
   • SERVICE_NAME: il nome del tuo servizio.

4. Applica il manifest al cluster:

   kubectl apply -f ingress-pre-shared-cert.yaml
   

HTTPS tra il bilanciatore del carico e l'applicazione

Se la tua applicazione viene eseguita in un pod GKE e può ricevere richieste HTTPS, puoi configurare il bilanciatore del carico in modo che utilizzi HTTPS quando inoltra le richieste alla tua applicazione. Per ulteriori informazioni, consulta HTTPS (TLS) tra il bilanciatore del carico e la tua applicazione.

VPC condiviso

Aggiungere manualmente l'annotazione NEG

Se GKE in cui stai eseguendo il deployment delle risorse Ingress si trova in un progetto di servizio VPC condiviso, i servizi non vengono annotati automaticamente con l'annotazione cloud.google.com/neg: '{"ingress": true}' perché non è installato MutatingWebhookConfiguration responsabile dell'inserimento dell'annotazione nei servizi.

Devi aggiungere l'annotazione NEG al manifest dei servizi esposti tramite Ingress per i bilanciatori del carico delle applicazioni interni.

Regole firewall VPC

Se il cluster GKE in cui stai eseguendo il deployment delle risorse Ingress si trova in un progetto di servizio VPC condiviso e vuoi che il piano di controllo GKE gestisca le risorse firewall nel progetto host, al service account GKE del progetto di servizio devono essere concesse le autorizzazioni IAM appropriate nel progetto host, come descritto in Gestione delle risorse firewall per i cluster con VPC condiviso. In questo modo, il controller Ingress può creare regole firewall per consentire il traffico in entrata per i controlli di integritàGoogle Cloud .

Di seguito è riportato un esempio di evento che potrebbe essere presente nei log delle risorse Ingress. Questo errore si verifica quando il controller Ingress non è in grado di creare una regola firewall per consentire il traffico in entrata per i controlli di integrità Google Cloud se le autorizzazioni non sono configurate correttamente.

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

Se preferisci eseguire il provisioning manuale delle regole firewall dal progetto host, puoi disattivare gli eventi firewallXPNError aggiungendo l'annotazione networking.gke.io/suppress-firewall-xpn-error: "true" alla risorsa Ingress.

Riepilogo delle annotazioni di Ingress interno

Le tabelle seguenti mostrano le annotazioni che puoi aggiungere quando crei risorse Ingress e Service per Ingress per i bilanciatori del carico delle applicazioni interni.

Annotazioni Ingress

Annotazioni di servizio relative a Ingress

Risoluzione dei problemi

La comprensione e l'osservazione dello stato di Ingress in genere comporta l'ispezione delle risorse associate. I tipi di problemi riscontrati spesso includono risorse di bilanciamento del carico non create correttamente, traffico che non raggiunge i backend o backend che non appaiono integri.

Alcuni passaggi comuni per la risoluzione dei problemi includono:

• Verifica che il traffico client provenga dalla stessa regione e dallo stesso VPC del bilanciatore del carico.
• Verifica che i pod e i backend siano integri.
• Convalida del percorso del traffico verso il VIP e per i controlli di integrità di Compute Engine per assicurarsi che non sia bloccato dalle regole firewall.
• Controllo degli eventi delle risorse Ingress per rilevare errori.
• Descrizione della risorsa Ingress per visualizzare il mapping alle risorse Compute Engine.
• Verifica che le risorse di bilanciamento del carico di Compute Engine esistano, abbiano le configurazioni corrette e non presentino errori segnalati.

Filtrare gli eventi Ingress

La seguente query filtra gli errori in tutti gli eventi Ingress nel tuo cluster:

kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress

Puoi anche filtrare per oggetti o nomi di oggetti:

kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress

Nel seguente errore, puoi notare che il servizio a cui fa riferimento l'ingresso non esiste:

LAST SEEN   TYPE      REASON      OBJECT                              MESSAGE
0s          Warning   Translate   ingress/hostname-internal-ingress   error while evaluating the ingress spec: could not find service "default/hostname-invalid"

Ispezione delle risorse del bilanciatore del carico Compute Engine

Il seguente comando mostra l'output completo della risorsa Ingress in modo che tu possa visualizzare i mapping alle risorse Compute Engine create dal controller Ingress:

kubectl get ing INGRESS_FILENAME -o yaml

Sostituisci INGRESS_FILENAME con il nome file della risorsa Ingress.

L'output è simile al seguente:

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
      ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
      kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
      kubernetes.io/ingress.class: gce-internal
    creationTimestamp: "2019-10-15T02:16:18Z"
    finalizers:
    - networking.gke.io/ingress-finalizer
    generation: 1
    name: ilb-demo-ingress
    namespace: default
    resourceVersion: "1538072"
    selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    defaultBackend:
      service:
        name: hostname
        port:
          number: 80
  status:
    loadBalancer:
      ingress:
      - ip: 10.128.0.127
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

L'elenco delle annotazioni ingress.kubernetes.io/backends mostra i backend e il relativo stato. Assicurati che i tuoi backend siano elencati come HEALTHY.

È possibile eseguire query direttamente sulle risorse Compute Engine create da Ingress per comprenderne lo stato e la configurazione. L'esecuzione di queste query può essere utile anche per la risoluzione dei problemi.

Per elencare tutte le regole di forwarding di Compute Engine:

gcloud compute forwarding-rules list

L'output è simile al seguente:

NAME                                                        REGION       IP_ADDRESS      IP_PROTOCOL  TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b  REGION_NAME  10.128.15.225   TCP          REGION_NAME/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

Per elencare lo stato di un servizio di backend, innanzitutto elenca i servizi di backend e copia il nome del servizio di backend che vuoi esaminare:

gcloud compute backend-services list

L'output è simile al seguente:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   REGION_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

Ora puoi utilizzare il nome del servizio di backend per eseguire query sul suo stato:

gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
    --region COMPUTE_REGION

Sostituisci COMPUTE_REGION con la regione di Compute Engine del servizio di backend.

L'output è simile al seguente:

backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/ZONE_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
  healthStatus:
  - healthState: HEALTHY

Passaggi successivi

• Scopri di più su GKE Ingress per i bilanciatori del carico delle applicazioni esterni.

• Leggi una panoramica concettuale dei servizi in GKE.

• Scopri come creare un bilanciatore del carico di rete passthrough interno su GKE.

• Implementa un ingress interno di base.