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 Ingress di GKE.

Per scoprire di più sulle funzionalità supportate per Ingress per i bilanciatori del carico delle applicazioni interni, consulta Funzionalità di 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 attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti e limitazioni

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

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 l'ambiente di networking in modo che sia possibile eseguire il deployment dei proxy del bilanciatore del carico 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:

Per saperne di più, consulta 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 questa regola firewall manualmente. Tuttavia, il controller Ingress crea regole firewall per consentire il traffico in entrata 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

Crea un cluster nella stessa rete della subnet solo proxy:

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

Sostituisci quanto segue:

  • CLUSTER_NAME: un nome per il cluster.
  • COMPUTE_LOCATION: la località di Compute Engine per il cluster. Devi utilizzare la stessa località della subnet proxy che hai creato nella sezione precedente.

Console

  1. Nella console Google Cloud , vai alla pagina Crea un cluster Autopilot.

    Vai a Crea un cluster Autopilot

  2. Nella sezione Impostazioni di base del cluster, completa quanto segue:
    1. Inserisci il nome del cluster.
    2. Per Tipo di località, seleziona una regione di Compute Engine per il tuo cluster. Devi utilizzare la stessa regione della subnet proxy che hai creato nella sezione precedente.
  3. Nel riquadro di navigazione, fai clic su Networking.
  4. Nell'elenco Rete, seleziona la rete in cui vuoi creare il cluster. Questa rete deve trovarsi nella stessa rete VPC della subnet proxy.
  5. Nell'elenco Subnet nodo, seleziona la subnet proxy che hai creato.
  6. Fai clic su Crea.

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 tramite la 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 dell'applicazione come risposta. Il nome host predefinito di un pod è il nome del pod. Il container gestisce anche l'arresto controllato.

  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 relative 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é i backend NEG sono obbligatori, quando esegui il deployment dei servizi esposti tramite Ingress è necessaria la seguente annotazione NEG:

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

Il 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 la policy di rete GKE.

L'annotazione viene aggiunta automaticamente utilizzando un MutatingWebhookConfiguration con nome neg-annotation.config.common-webhooks.networking.gke.io. Puoi verificare 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 dei container. Il traffico viene bilanciato dal proxy Ingress direttamente all'IP del pod, anziché attraversare l'IP del nodo o il networking kube-proxy. Inoltre, vengono implementati i gate di idoneità dei pod 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à dei pod garantiscono che il traffico non venga interrotto durante eventi del ciclo di vita come l'avvio dei pod, la perdita dei pod o la perdita dei nodi.

Se non includi un'annotazione NEG, ricevi un avviso sull'oggetto Ingress che ti impedisce di configurare il bilanciatore del carico delle applicazioni interno. Se l'annotazione NEG non è inclusa, viene generato anche un evento Kubernetes sull'oggetto Ingress. 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'oggetto Ingress 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 di 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 Ingress GKE. Devi utilizzare l'annotazione kubernetes.io/ingress.class. Per saperne di più, consulta 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, verificherai 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'oggetto Ingress è pronto. L'utilizzo di un indirizzo RFC 1918 in questo campo indica un IP interno al VPC.

Poiché l'Application Load Balancer 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 inviare 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, esegui il deployment di una VM all'interno della stessa regione e della stessa 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:

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

  2. Per accedere al VIP interno dalla VM, utilizza curl:

    1. Accedi 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 positiva e il nome host di uno dei container di backend indicano che il percorso di bilanciamento del carico completo funziona correttamente.

Eliminazione delle risorse Ingress

La rimozione delle risorse Ingress e Service comporta anche la rimozione delle risorse del bilanciatore del carico di Compute Engine associate. Per evitare la perdita di risorse, assicurati che le risorse Ingress vengano eliminate quando non sono più necessarie. Devi anche eliminare le risorse Ingress e Service prima di eliminare i cluster, altrimenti le risorse di bilanciamento del carico di Compute Engine rimarranno isolate.

Per rimuovere un Ingress, completa i seguenti passaggi:

  1. Elimina la risorsa Ingress. Ad esempio, per eliminare la risorsa Ingress che hai creato in questa pagina, esegui questo comando:

    kubectl delete ingress ilb-demo-ingress

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

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

    kubectl delete service hostname

    L'eliminazione del servizio comporta la rimozione del NEG associato.

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

Indirizzi IP statici

Le risorse Ingress interne supportano l'indirizzamento IP statico e 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, poiché questa subnet viene utilizzata solo per il consumo del proxy interno. Questi indirizzi IP temporanei vengono allocati all'oggetto Ingress solo per il ciclo di vita della risorsa Ingress interna. Se elimini l'Ingress e ne crei uno nuovo dallo stesso file manifest, non hai la garanzia di ottenere 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 sulla risorsa Ingress.

L'esempio seguente 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 di Ingress. Un bilanciatore del carico non viene distribuito 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 per utilizzare un indirizzo IP statico anziché un indirizzo IP temporaneo, GKE potrebbe modificare l'indirizzo IP del bilanciatore del carico quando GKE ricrea la regola di forwarding del bilanciatore del carico.
  • L'IP statico è prenotato 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 utilizzando il nome, anziché l'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 fornire certificati TLS tramite i Secret di 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 e versioni successive. Per abilitare questa funzionalità, devi creare un indirizzo IP statico con PURPOSE=SHARED_LOADBALANCER_VIP e configurarlo sull'oggetto Ingress. Se non viene fornito un indirizzo IP statico, è consentito solo il traffico HTTPS e devi seguire la documentazione per disattivare HTTP.

I passaggi seguenti descrivono come creare un certificato in Google Cloud e poi fornirlo 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 per il certificato che scegli.
    • 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 di Compute Engine per il tuo certificato.

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

  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 creato nella sezione precedente.
    • SERVICE_NAME: il nome del 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 saperne di più, consulta HTTPS (TLS) tra il bilanciatore del carico e l'applicazione.

VPC condiviso

Aggiungi manualmente l'annotazione NEG

Se il GKE in cui esegui 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é MutatingWebhookConfiguration responsabile dell'inserimento dell'annotazione nei servizi non è installato.

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 esegui il deployment delle risorse Ingress si trova in un progetto di servizio VPC condiviso e vuoi che il control plane 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à diGoogle 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 manualmente il provisioning 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

Annotation Descrizione
kubernetes.io/ingress.class Puoi impostare "gce-internal" per Ingress interno. Se la classe non è specificata, una risorsa Ingress viene interpretata per impostazione predefinita come Ingress esterno. Per saperne di più, consulta Comportamento del controller Ingress di GKE.
kubernetes.io/ingress.allow-http Puoi consentire il traffico HTTP tra il client e il bilanciatore del carico HTTP(S). I valori possibili sono true e false. Il valore predefinito è true. Per saperne di più, consulta Disattivazione di HTTP.
ingress.gcp.kubernetes.io/pre-shared-cert Puoi caricare certificati e chiavi nel tuo progetto Google Cloud . Utilizza questa annotazione per fare riferimento ai certificati e alle chiavi. Per saperne di più, consulta Utilizzo di più certificati SSL con i bilanciatori del carico delle applicazioni esterni.
networking.gke.io/suppress-firewall-xpn-error

In GLBC 1.4 e versioni successive, puoi disattivare l'audio dell'evento firewallXPNError. Per i bilanciatori del carico in entrata, se Kubernetes non può modificare le regole firewall a causa di autorizzazioni insufficienti, viene creato un evento firewallXPNError ogni pochi minuti.

Aggiungi l'annotazione networking.gke.io/suppress-firewall-xpn-error: "true" alla risorsa Ingress. Il valore predefinito è false. Puoi rimuovere questa annotazione per riattivare l'audio.

kubernetes.io/ingress.regional-static-ip-name Puoi specificare un indirizzo IP statico per eseguire il provisioning della risorsa Ingress interna. Per saperne di più, consulta Indirizzi IP statici.
Annotation Descrizione
cloud.google.com/backend-config Utilizza questa annotazione per configurare il servizio di backend associato a un servicePort. Per saperne di più, consulta la sezione Configurazione di Ingress.
cloud.google.com/neg Utilizza questa annotazione per specificare che il bilanciatore del carico deve utilizzare i gruppi di endpoint di rete. Per saperne di più, consulta Utilizzo del bilanciamento del carico nativo del container.

Risoluzione dei problemi

Per comprendere e osservare lo stato di Ingress, in genere è necessario ispezionare le risorse associate. I tipi di problemi riscontrati spesso includono la mancata creazione corretta delle risorse di bilanciamento del carico, il traffico che non raggiunge i backend o i backend che non risultano integri.

Ecco alcuni passaggi comuni per la risoluzione dei problemi:

  • 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 della risorsa Ingress per verificare la presenza di errori.
  • Descrizione della risorsa Ingress per visualizzare la mappatura 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.

Filtro per 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

Nell'errore seguente, puoi vedere che il servizio a cui fa riferimento l'oggetto Ingress 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 di Compute Engine

Il comando seguente mostra l'output completo della risorsa Ingress in modo da poter visualizzare le mappature 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: ""

Le annotazioni ingress.kubernetes.io/backends elencano i backend e il loro stato. Assicurati che i tuoi backend siano elencati come HEALTHY.

Le risorse Compute Engine create da Ingress possono essere interrogate direttamente 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, elenca innanzitutto i servizi di backend e copia il nome del servizio di backend che vuoi ispezionare:

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