Configurazione di Ingress per i bilanciatori del carico delle applicazioni interni

Questa pagina mostra come configurare e utilizzare Ingress per gli Application Load Balancer 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 in Ingress per sugli Application Load Balancer interni, vedi Funzionalità in entrata. 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à:

  • 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, scarica la versione più recente eseguendo gcloud components update.

Requisiti

Ingress per i bilanciatori del carico delle applicazioni interni ha 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 abilitato 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.

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 Kubernetes Ingress all'API, devi preparare ambiente di networking per poter 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 ulteriori informazioni, consulta la pagina sulla configurazione della subnet solo proxy.

Crea una regola firewall

Il controller Ingress non crea una regola firewall per consentire 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à 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 creerai un cluster nativo di VPC che puoi da usare 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 località della subnet proxy 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 nel tuo cluster. Devi utilizzare la stessa regione della subnet proxy creato nella sezione precedente.

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

  6. Nell'elenco Rete, seleziona la rete a cui vuoi collegare il cluster in cui eseguire la creazione. 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 container di applicazioni 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

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 automaticamente annotato con cloud.google.com/neg: '{"ingress": true}' quando tutti i seguenti requisiti sono vere:

  • Stai utilizzando cluster VPC nativi.
  • Non utilizzi un VPC condiviso.
  • Non stai utilizzando Criterio di rete di 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 al pod anziché attraversare l'IP del nodo o il networking 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 di attività di Kubernetes. I controlli di idoneità dei pod assicurano che il traffico non venga eliminato durante degli eventi del ciclo di vita, come l'avvio dei pod, la perdita di pod o la perdita di nodi.

Se non includi un'annotazione NEG, riceverai un avviso sull'oggetto Ingress che impedisce la configurazione del bilanciatore del carico delle applicazioni interno. Se l'annotazione NEG non è inclusa, viene generato anche un evento Kubernetes sull'Ingress. La Ecco un esempio del 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 vengono visualizzati in Compute Engine finché non sia Ingress che il servizio di riferimento esistono. I NEG sono una risorsa di zona e, per i cluster multi-zona, sono vengono create per servizio e 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. In entrata per i bilanciatori del carico delle applicazioni interni richiedono 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 verificherai se il deployment è stato eseguito correttamente.

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 viene compilato, il traffico in entrata è pronto. L'utilizzo di una specifica RFC L'indirizzo 1918 in questo campo indica un IP interno nel in un VPC.

Poiché il bilanciatore del carico delle applicazioni interno è un bilanciatore del carico regionale, l'IP virtuale (VIP) è accessibile solo da un client che si trova nella stessa regione in un 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, 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 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 saperne di più sulla creazione delle istanze, consulta Creazione e avvio di un'istanza VM.

  2. Per accedere al VIP interno dall'interno della 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 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 fughe di risorse, assicura 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 di Compute Engine rimarranno orfane.

Per rimuovere un Ingress:

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

    kubectl delete ingress ilb-demo-ingress

    L'eliminazione della risorsa Ingress rimuove le regole di forwarding, i servizi di backend e l'URL mappe 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 se non viene specificato un indirizzo IP, viene automaticamente eseguito un indirizzo IP disponibile e allocati 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 la tua risorsa Ingress e ne crei una nuova dalla stessa manifest, non è garantito che tu riceva 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 il metodo Annotazione kubernetes.io/ingress.regional-static-ip-name sul tuo Ingress risorsa.

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 modello esistente Ingress per utilizzare un indirizzo IP statico invece di 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 una risorsa 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 nella stessa regione della 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

Il traffico in entrata per il bilanciamento del carico interno supporta la gestione di certificati TLS per clienti. 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, viene usato solo il protocollo HTTPS è consentito il traffico, inoltre 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 che scegliere.
    • CERT_FILE_PATH: il percorso del file del certificato locale per creare un certificato autogestito. Il certificato deve essere in formato PEM formato.
    • KEY_FILE_PATH: il percorso di un file della chiave privata locale. La chiave privata deve essere in formato PEM e 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 in base agli 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 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, vedi HTTPS (TLS) tra il bilanciatore del carico e l'applicazione.

VPC condiviso

Aggiungere manualmente l'annotazione NEG

Se il GKE in cui esegui il deployment delle risorse Ingress si trova in una Progetto di servizio del VPC condiviso, i servizi non vengono annotati automaticamente con l'annotazione cloud.google.com/neg: '{"ingress": true}' perché MutatingWebhookConfiguration responsabile dell'inserimento dell'annotazione nella non sia 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 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 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à 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 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 interne

Le seguenti tabelle mostrano le annotazioni che puoi aggiungere quando creando risorse Ingress e di servizio 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 ulteriori informazioni, 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 maggiori informazioni le informazioni, vedi Utilizzo di più certificati SSL con bilanciatori del carico delle applicazioni esterni.
networking.gke.io/suppress-firewall-xpn-error

In GLBC 1.4 In seguito, puoi disattivare l'evento firewallXPNError. Per gli ingress load balancer, 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" a in 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 il provisioning della risorsa Ingress interna. Per maggiori informazioni, vedi Indirizzi IP statici.
Annotazione Descrizione
cloud.google.com/backend-config Utilizza questa annotazione per configurare il servizio di backend associato a un servicePort. 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: di non creare correttamente le risorse, il traffico non raggiunge i backend, o backend non integri.

Ecco alcune procedure di risoluzione dei problemi comuni:

  • Verificare che il traffico client provenga dalla stessa regione e dalla stessa VPC del bilanciatore del carico.
  • È in corso la verifica dell'integrità di pod e backend.
  • 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.
  • Descrizione della risorsa Ingress per visualizzare la mappatura a Compute Engine Google Cloud.
  • Per confermare l'esistenza delle risorse di bilanciamento del carico di Compute Engine, configurazioni corrette e non vengono 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 di Compute Engine

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

kubectl get ing INGRESS_FILENAME -o yaml

Sostituisci INGRESS_FILENAME con il codice della risorsa Ingress nome file.

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