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 la sezione 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 operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente 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.
  • Nel cluster deve essere attivato il componente aggiuntivo HttpLoadBalancing. Questo componente aggiuntivo è attivo per impostazione predefinita. Non devi disattivarlo.
  • Devi utilizzare i gruppi di endpoint di rete (NEG) come backend per il tuo servizio.

Eseguire il deployment di Ingress per i bilanciatori del carico delle applicazioni interni

Gli esercizi che seguono 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 dispiacciati 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 ulteriori informazioni, consulta la sezione sulla 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 l'ingresso per i controlli di integrità di 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 crei 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 posizione Compute Engine per il cluster. Devi utilizzare la stessa posizione della subnet proxy che hai creato nella sezione precedente.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Nella sezione Autopilot, fai clic su Configura.

  4. Nella sezione Nozioni di base sul cluster, completa quanto segue:

    1. Inserisci il nome del cluster.
    2. Per Tipo di località, seleziona una regione Compute Engine per il tuo cluster. Devi utilizzare la stessa regione della subnet proxy che hai creato nella sezione precedente.

  5. Nel riquadro di navigazione, fai clic su Networking.

  6. Nell'elenco Rete, seleziona la rete in cui vuoi creare il cluster. Questa rete deve trovarsi nella stessa rete VPC della subnet proxy.

  7. Nell'elenco Subnet del nodo, seleziona la subnet proxy che hai creato

  8. 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 ascolta su un server HTTPS sulla porta 9376. Questo deployment gestisce anche i pod per la tua applicazione. Ogni pod esegue un contenitore 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 contenitore gestisce anche l'arresto controllato.

  2. Applica il manifest al cluster:

    kubectl apply -f web-deployment.yaml

Eseguire il deployment di un servizio come gruppo di endpoint di rete (NEG)

In questa sezione, crei una risorsa Service. Il servizio seleziona i container di backend in base alle relative etichette in modo che il controller di ingressi possa programmarlo 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, la seguente annotazione NEG è obbligatoria quando esegui il deployment di 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 VPC nativi.
  • Non utilizzi un VPC condiviso.
  • Non utilizzi Criteri 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 del container. Il traffico viene bilanciato dal proxy Ingress direttamente all'IP del pod anziché attraversare l'IP del nodo o la rete kube-proxy. Inoltre, vengono implementati cancelli 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 cancelli di idoneità dei pod assicurano che il traffico non venga interrotto durante gli eventi di 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 l'Application Load Balancer interno. Se l'annotazione NEG non è inclusa, viene generato anche un evento Kubernetes sull'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'Ingress sia il servizio a cui fa riferimento. I NEG sono una risorsa di zona e per i cluster multi-zona 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, crei 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 Ingress GKE. Devi utilizzare l'annotazione kubernetes.io/ingress.class. Per maggiori informazioni, consulta Comportamento del controller Ingress di GKE.

Per creare un 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 di Ingress riuscito

In questa sezione, convalidi 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 inoltro, servizi di backend, mappe URL e NEG.

Per recuperare lo stato della risorsa Ingress creata nella sezione precedente, esegui il seguente 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'Ingress è pronto. L'utilizzo di un indirizzo RFC 1918 in questo campo indica un IP interno all'interno della 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 della stessa VPC. Dopo aver recuperato il VIP del bilanciatore del carico, puoi utilizzare strumenti (ad esempio curl) per emettere chiamate HTTP GET al VIP dall'interno della VPC.

Per effettuare una chiamata HTTP GET:

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

    gcloud compute instances create l7-ilb-client \
    --image-family=debian-10 \
    --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 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 creata 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 contenitori 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 bilanciatore del carico di Compute Engine associate. Per evitare perdite di risorse, assicurati che le risorse Ingress vengano rimosse 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 orfane.

Per rimuovere un Ingress:

  1. Elimina l'Ingress. Ad esempio, per eliminare l'Ingress creato in questa pagina, esegui il seguente 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 il seguente comando:

    kubectl delete service hostname

    L'eliminazione del servizio rimuove il NEG associato al servizio.

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

Indirizzi IP statici

Le risorse di ingresso interne supportano gli indirizzi IP sia statici che temporanei. Se non viene specificato un indirizzo IP, viene allocato automaticamente un indirizzo IP disponibile dalla subnet del nodo GKE. Tuttavia, la risorsa Ingress non esegue il provisioning degli indirizzi IP della subnet solo per proxy poiché questa subnet viene utilizzata solo per il consumo del proxy interno. Questi indirizzi IP temporanei vengono assegnati all'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 è garantito che otterrai 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 a livello di regione. Puoi quindi specificare un indirizzo IP statico utilizzando l'annotazione kubernetes.io/ingress.regional-static-ip-name nella 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 di indirizzo 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 disegnato finché l'IP statico non esiste e il riferimento a una risorsa indirizzo IP inesistente non crea un IP statico. Se modifichi un Ingress esistente in modo da utilizzare un indirizzo IP statico anziché uno 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 tramite il nome anziché tramite l'indirizzo IP.
  • L'indirizzo IP deve provenire da una subnet della 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 pubblicazione di certificati TLS per i client. Puoi pubblicare certificati TLS tramite i segreti Kubernetes o tramite certificati SSL regionali precompartiti in Google Cloud. Puoi anche specificare più certificati per risorsa Ingress. L'utilizzo contemporaneamente di HTTPS e HTTP è supportato per GKE 1.25 e versioni successive. Per attivare questa funzionalità, devi creare un indirizzo IP statico con PURPOSE=SHARED_LOADBALANCER_VIP e configurarlo su Ingress. Se non viene fornito un indirizzo IP statico, è consentito solo il traffico HTTPS e devi seguire la documentazione relativa alla disattivazione di HTTP.

I passaggi che seguono descrivono in dettaglio come creare un certificato in Google Cloud e poi come pubblicarlo tramite Ingress per i client interni sia per il traffico HTTPS che per quello 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 scelto da te.
    • 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 della chiave privata locale. La chiave privata deve essere in formato PEM e deve utilizzare la crittografia RSA o ECDSA.
    • COMPUTE_REGION: un'area geografica 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 ulteriori informazioni, consulta HTTPS (TLS) tra il bilanciatore del carico e l'applicazione.

VPC condiviso

Aggiungere manualmente l'annotazione NEG

Se il cluster GKE in cui stai implementando le 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é il servizio cloud.google.com/neg: '{"ingress": true}' responsabile dell'inserimento dell'annotazione nei servizi non è installato.MutatingWebhookConfiguration

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 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 Gestire le 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à di Google Cloud.

Di seguito è riportato un esempio di evento che potrebbe essere presente nei log della risorsa 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à di 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 del 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 interne

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

Annotazione Descrizione
kubernetes.io/ingress.class Puoi impostare "gce-internal" per Ingress interno. Se la classe non è specificata, per impostazione predefinita una risorsa Ingress viene interpretata come Ingress esterno. Per ulteriori informazioni, 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 la sezione Disattivare 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 ulteriori informazioni, consulta Utilizzare più certificati SSL con 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 di carico in entrata, se Kubernetes non può modificare le regole del firewall a causa di un'autorizzazione insufficiente, viene creato un evento firewallXPNError ogni diversi minuti.

Aggiungi l'annotazione networking.gke.io/suppress-firewall-xpn-error: "true" alla risorsa di entrata. 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 ulteriori informazioni, vedi Indirizzi IP statici.
Annotazione Descrizione
cloud.google.com/backend-config Utilizza questa annotazione per configurare il servizio di backend associato a una porta di servizio. Per ulteriori informazioni, consulta la sezione Configurazione di Ingress.
cloud.google.com/neg Utilizza questa annotazione per specificare che il bilanciatore del carico deve utilizzare gruppi di endpoint di rete. Per ulteriori informazioni, consulta Utilizzare il bilanciamento del carico nativo del container.

Risoluzione dei problemi

Comprendere e osservare lo stato di Ingress in genere comporta l'ispezione delle 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 la mancata indicazione dell'integrità dei backend.

Ecco alcuni passaggi comuni per la risoluzione dei problemi:

  • Verificare che il traffico client provenga dalla stessa regione e dalla stessa VPC del bilanciatore del carico.
  • Verificare che i pod e i backend siano integri.
  • Convalida del percorso del traffico verso l'IP virtuale e per i controlli di integrità di Compute Engine per assicurarti che non sia bloccato dalle regole del firewall.
  • Controllo della presenza di errori negli eventi della risorsa Ingress.
  • Descrivere la risorsa Ingress per visualizzare la mappatura alle risorse di Compute Engine.
  • Verificare che le risorse di bilanciamento del carico di Compute Engine esistano, abbiano le configurazioni corrette e che non siano stati segnalati errori.

Filtri 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

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

Il seguente comando mostra l'output completo della risorsa Ingress in modo da poter vedere le mappature alle risorse Compute Engine create dal controller Ingress:

kubectl get ing INGRESS_FILENAME -o yaml

Sostituisci INGRESS_FILENAME con il nome del 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 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 inoltro 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 l'integrità di un servizio di backend, elenca prima i servizi di backend e fai una copia del 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 relativo stato di salute:

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

Sostituisci COMPUTE_REGION con la regione 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