Configurazione di Ingress per il bilanciamento del carico HTTP(S) interno

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina mostra come configurare e utilizzare Ingress per il bilanciamento del carico HTTP(S) interno in Google Kubernetes Engine (GKE). La risorsa Ingress per il bilanciamento del carico HTTP(S) interno fornisce un supporto integrato per il bilanciamento del carico interno tramite il controller Ingress di GKE.

Per scoprire di più sulle funzionalità supportate per Ingress per il bilanciamento del carico HTTP(S) interno, consulta le funzionalità di Ingress. Puoi anche scoprire di più su come funziona Ingress per il bilanciamento del carico HTTP(S) interno in Bilanciamento del carico HTTP(S) interno.

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
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza l'interfaccia a riga di comando gcloud.

Requisiti

La risorsa Ingress per il bilanciamento del carico HTTP(S) interno prevede i seguenti requisiti:

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

Deployment di Ingress per il bilanciamento del carico HTTP(S) interno

I seguenti esercizi mostrano come eseguire il deployment di Ingress per il bilanciamento del carico HTTP(S) interno:

  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 Ingress di Kubernetes, devi preparare l'ambiente di rete in modo che sia possibile eseguire il deployment dei proxy del bilanciatore del carico in una determinata area geografica.

Crea una subnet solo proxy seguendo le istruzioni nella configurazione della subnet solo proxy. Ad esempio, il seguente comando crea una subnet solo proxy nell'area geografica us-west1 utilizzando la rete lb-network:

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

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 del firewall per consentire 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 dei pod:

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

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

Creazione di un cluster

In questa sezione creerai un cluster che potrai utilizzare con Ingress per il bilanciamento del carico HTTP(S) interno. Puoi creare questo cluster utilizzando Google Cloud CLI o Google Cloud Console.

gcloud

Crea un cluster con i seguenti campi:

gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --zone=COMPUTE_REGION \
    --network=NETWORK

Sostituisci quanto segue:

  • CLUSTER_NAME: un nome per il cluster.
  • COMPUTE_ZONE: la zona di Compute Engine per il nuovo cluster. Devi scegliere una zona nella stessa regione della subnet proxy che hai creato nella sezione precedente.
  • NETWORK: il nome della rete in cui vuoi creare il cluster. Questa rete deve trovarsi nella stessa rete VPC della subnet proxy che hai creato nella sezione precedente.

Console

  1. Vai alla pagina Google Kubernetes Engine in Google Cloud Console.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

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

    1. Inserisci il nome del tuo cluster.
    2. In Tipo di località, seleziona una zona di Compute Engine per il tuo cluster. Devi scegliere una zona nella stessa regione della subnet proxy che hai creato nella sezione precedente.
  4. Nel riquadro di navigazione, in Cluster, fai clic su Networking.

    1. Dall'elenco a discesa Rete, seleziona la rete in cui vuoi creare il cluster. Questa rete deve trovarsi nella stessa rete VPC della subnet proxy.
    2. In Opzioni di networking avanzate, assicurati che le opzioni Abilita routing del traffico VPC nativo (mediante IP alias) e Abilita bilanciamento del carico HTTP siano selezionate.
  5. Fai clic su Crea.

Deployment di un'applicazione web

In questa sezione, creerai un deployment.

Per creare un deployment:

  1. Copia e salva la seguente risorsa di deployment in un file denominato web-deployment.yaml:

    # 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: k8s.gcr.io/serve_hostname:v1.4
            name: hostname-server
            ports:
            - containerPort: 9376
              protocol: TCP
          terminationGracePeriodSeconds: 90
    

    Questo file di deployment utilizza un'immagine container 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 dell'applicazione come risposta. Il nome host predefinito di un pod è il nome del pod. Il container gestisce anche la terminazione del periodo di tolleranza.

  2. Dopo aver creato il file di deployment, applica la risorsa 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 di servizio. Il Service seleziona i container di backend in base alle etichette, in modo che il controller Ingress possa programmarli come endpoint di backend. La risorsa Ingress per il bilanciamento del carico HTTP(S) interno 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 soddisfatte:

  • Stai utilizzando cluster nativi di VPC.
  • Non stai utilizzando un VPC condiviso.
  • Non utilizzi i criteri di rete di GKE.

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

kubectl get mutatingwebhookconfigurations

L'utilizzo di 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 il networking kube-proxy. Inoltre, i gateway di idoneità dei pod vengono implementati per determinare l'integrità dei pod dal punto di vista del bilanciatore del carico e non solo i 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 del pod, la perdita di pod o la perdita di nodi.

Se non includi un'annotazione NEG, riceverai un avviso sull'oggetto Ingress che ti impedisce di configurare il bilanciatore del carico HTTP(S) interno. Un evento Kubernetes viene generato anche su Ingress se l'annotazione NEG non è inclusa. Di seguito è riportato 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 il traffico in entrata che il servizio di riferimento. I NEG sono una risorsa a livello di zona e, per i cluster multizona, ne viene creata una per zona per ogni zona.

Per creare un Service:

  1. Copia e salva la seguente risorsa di servizio in un file denominato web-service.yaml:

    # 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. Dopo aver creato il file del servizio, applica la risorsa 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. Una risorsa Ingress per il bilanciamento del carico HTTP(S) interno 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 ulteriori informazioni, consulta il comportamento di controller Ingress Ingress.

Per creare una risorsa Ingress:

  1. Copia e salva la seguente risorsa Ingress in un file denominato internal-ingress.yaml:

    # 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. Dopo aver creato il file Ingress, applica la risorsa al cluster:

    kubectl apply -f internal-ingress.yaml
    

Convalida di un deployment 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 forwarding, servizi di backend, mappe URL e NEG.

Per recuperare lo stato della risorsa Ingress che hai creato 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 è completato, la risorsa Ingress è pronta. L'utilizzo di un indirizzo RFC 1918 in questo campo indica un IP interno all'interno del VPC.

Poiché il bilanciatore del carico HTTP(S) interno è un bilanciatore del carico a livello di area geografica, l'IP virtuale (VIP) è accessibile solo da un client all'interno della stessa regione e VPC. Dopo aver recuperato il VIP del bilanciatore del carico, puoi utilizzare gli strumenti (ad esempio curl) per emettere 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 nella stessa area geografica e nella stessa rete del cluster.

    Ad esempio, se hai seguito i passaggi precedenti per la creazione di deployment, servizio e Ingress e hai creato il cluster nella rete predefinita e nella zona us-central1-a, puoi utilizzare il seguente comando:

    gcloud compute instances create l7-ilb-client-us-central1-a \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --network=default \
        --subnet=default \
        --zone=us-central1-a \
        --tags=allow-ssh
    

    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 alla VM che hai creato nel passaggio precedente:

      gcloud compute ssh l7-ilb-client-us-central1-a \
         --zone=us-central1-a
      
    2. Usa curl per accedere al VIP interno dell'applicazione:

      curl 10.128.0.58
      hostname-server-6696cf5fc8-z4788
      

      La risposta HTTP e il nome host riusciti 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 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 o altrimenti le risorse di bilanciamento del carico di Compute Engine sono orfane.

Per rimuovere una risorsa Ingress:

  1. Elimina la risorsa Ingress. Ad esempio, per eliminare la risorsa Ingress creata in questa pagina, esegui il comando seguente:

    kubectl delete ingress ilb-demo-ingress
    

    L'eliminazione di Ingress rimuove le regole di forwarding, i servizi di backend e le mappe URL associate a questa risorsa Ingress.

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

    kubectl delete service hostname
    

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

Indirizzamento IP statico

Le risorse Ingress interne supportano sia gli indirizzi IP statici che temporanei. Se non viene specificato un indirizzo IP, un indirizzo IP disponibile viene allocato automaticamente dalla subnet del nodo GKE. Tuttavia, la risorsa Ingress non esegue il provisioning degli indirizzi IP dalla subnet solo proxy poiché la subnet viene utilizzata solo per il consumo da proxy interno. Questi indirizzi IP temporanei vengono allocati alla risorsa Ingress solo per il ciclo di vita della risorsa Ingress interna. Se elimini la tua risorsa Ingress e ne crei una nuova dallo stesso file manifest, non è garantito che tu abbia lo stesso indirizzo IP esterno.

Se vuoi un indirizzo IP permanente che sia 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 IP statico che soddisfi i seguenti criteri:

  • Crea l'indirizzo IP statico prima di eseguire il deployment della risorsa Ingress. Il deployment di un bilanciatore del carico non viene eseguito 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 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 viene 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 dell'indirizzo IP di Google Cloud in base al nome, anziché all'indirizzo IP.
  • L'indirizzo IP deve provenire da una subnet nella stessa area geografica del cluster GKE. Puoi utilizzare qualsiasi subnet privata disponibile all'interno della regione (ad eccezione della subnet solo proxy). Risorse diverse della risorsa Ingress possono anche avere indirizzi provenienti da subnet diverse.

HTTPS tra client e bilanciatore del carico

La risorsa Ingress per il bilanciamento del carico interno supporta la distribuzione di certificati TLS per i client. Puoi gestire i certificati TLS tramite secret di Kubernetes o mediante certificati SSL pre-condivisi in Google Cloud. Puoi anche specificare più certificati per risorsa Ingress.

I passaggi seguenti spiegano come creare un certificato in Google Cloud e quindi eseguirne la pubblicazione tramite Ingress per i client interni:

  1. Crea il certificato a livello di regione:

    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 tuo 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 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 di Compute Engine per il certificato.
  2. Creare una risorsa Ingress. Il seguente file YAML, denominato ingress-pre-shared-cert.yaml, è un esempio della risorsa Ingress che devi creare:

    # 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.class: "gce-internal"
        kubernetes.io/ingress.allow-http: "false"
    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 Servizio.
  3. Dopo aver creato la risorsa Ingress, applica la risorsa al cluster:

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

HTTPS tra bilanciatore del carico e 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 il 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é il MutatingWebhookConfiguration responsabile dell'inserimento dell'annotazione nei servizi non è installato.

Devi aggiungere l'annotazione NEG al manifest dei servizi esposti tramite Ingress per il bilanciamento del carico HTTP(S) interno.

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 tuo progetto host, all'account di servizio GKE del progetto di servizio devono essere concesse le autorizzazioni IAM appropriate nel progetto host in base alla Gestione delle risorse firewall per i cluster con VPC condiviso. Questo consente al controller Ingress di 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 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 Ingress interne

Le seguenti tabelle mostrano le annotazioni che puoi aggiungere quando crei risorse Ingress e di servizio per Ingress per il bilanciamento del carico HTTP(S) interno.

Annotazioni Ingress

Annotazione Descrizione
kubernetes.io/ingress.class Puoi impostare "gce-internal" per la risorsa Ingress interna. Se la classe non è specificata, una risorsa Ingress viene interpretata per impostazione predefinita come una risorsa Ingress esterna. Per maggiori informazioni, consulta Comportamento del controller GKE Ingress.
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, ma devi impostare questa annotazione su false se utilizzi HTTPS per il bilanciamento del carico interno. Per ulteriori informazioni, consulta la sezione 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 l'articolo sull'utilizzo di più certificati SSL nel bilanciamento del carico HTTP(S).
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 un'autorizzazione insufficiente, viene creato un evento firewallXPNError a intervalli di diversi 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 il provisioning della risorsa Ingress interna. Per ulteriori informazioni, consulta Indirizzi IP statici.
Annotazione Descrizione
cloud.google.com/backend-config Utilizza questa annotazione per configurare il servizio di backend associato a un servicePort. Per maggiori informazioni, consulta la pagina Funzionalità in entrata.
cloud.google.com/neg Utilizza questa annotazione per specificare che il bilanciatore del carico deve utilizzare i gruppi di endpoint di rete. Per maggiori informazioni, consulta la pagina Utilizzo del bilanciamento del carico nativo del container.

Risolvere i problemi

Comprendere e osservare lo 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 non visualizzati in stato integro.

Alcuni passaggi comuni per la risoluzione dei problemi includono:

  • Verifica che il traffico del client provenga dalla stessa regione e dal VPC del bilanciatore del carico.
  • Verifica che i pod e i backend siano in stato integro.
  • Convalida del percorso di traffico al VIP e ai controlli di integrità di Compute Engine per garantire che non sia bloccato dalle regole firewall.
  • Controllo degli errori delle risorse Ingress.
  • Descrivere la risorsa Ingress per visualizzare la mappatura alle risorse Compute Engine.
  • Conferma della presenza delle risorse di bilanciamento del carico di Compute Engine, della configurazione corretta e dell'assenza di errori.

Filtrare in base agli eventi Ingress

Le seguenti query filtrano gli errori in tutti gli eventi Ingress nel 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 si fa riferimento nella risorsa 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: ""

Nelle annotazioni ingress.kubernetes.io/backends sono elencati i backend e il relativo stato. Assicurati che i tuoi backend siano elencati come HEALTHY.

Puoi eseguire query direttamente sulle risorse di Compute Engine create dalla risorsa Ingress per comprendere il loro stato e la loro configurazione. L'esecuzione di queste query può essere utile anche durante 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  us-central1  10.128.15.225   TCP          us-central1/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

Per elencare lo stato di un servizio di backend, elenca prima i servizi di backend e crea una copia del nome del servizio di backend che vuoi controllare:

gcloud compute backend-services list

L'output è simile al seguente:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   us-central1-a/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

Ora puoi utilizzare il nome del servizio di backend per eseguire query sull'integrità:

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

L'output è simile al seguente:

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

Passaggi successivi