Configurazione di Ingress per bilanciatori del carico delle applicazioni interni

Autopilot Standard

Questa pagina mostra come configurare e utilizzare Ingress per gli Application Load Balancer interni in Google Kubernetes Engine (GKE). Ingress offre supporto integrato per il bilanciamento del carico interno tramite il controller GKE Ingress.

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

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Requisiti

La risorsa 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 abilitato il componente aggiuntivo HttpLoadBalancing. Questo componente aggiuntivo è abilitato per impostazione predefinita. Non devi disabilitarla.
Devi utilizzare i gruppi di endpoint di rete (NEG) come backend per il tuo servizio.

Deployment di Ingress per bilanciatori del carico delle applicazioni interni

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

Prepara l'ambiente.
Crea un cluster.
Eseguire il deployment di un'applicazione.
Esegui il deployment di un servizio.
Esegui il deployment di Ingress.
Convalida il deployment.
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 rete 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:

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

Per maggiori informazioni, consulta la pagina relativa alla configurazione di una 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à 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 che il pod è in ascolto, ad esempio 9376.

Creazione di un cluster

In questa sezione creerai un cluster nativo di VPC da 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 posizione della subnet proxy creata nella sezione precedente.

Console

Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

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

Deployment di un'applicazione web

In questa sezione creerai un deployment.

Per creare un deployment:

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 in ascolto 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 come risposta il nome host del server delle applicazioni. Il nome host predefinito di un pod è il nome del pod. Il container gestisce anche la terminazione controllata.

Applica il manifest al cluster:
```
kubectl apply -f web-deployment.yaml
```

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

In questa sezione creerai una risorsa Service. Il servizio seleziona i container di backend in base alle etichette in modo che il controller Ingress possa programmarli come endpoint di backend. La risorsa Ingress per i bilanciatori del carico delle applicazioni interni richiede l'uso di NEG come backend. La funzionalità non supporta i gruppi di istanze come backend. Poiché i backend di 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 servizio viene automaticamente annotato con cloud.google.com/neg: '{"ingress": true}' quando tutte le seguenti condizioni sono vere:

Stai utilizzando cluster nativi di VPC.
Non stai utilizzando un VPC condiviso.
Non stai utilizzando il Criterio di rete di GKE.

L'annotazione viene aggiunta automaticamente utilizzando un elemento 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 di NEG consente al controller Ingress di eseguire il bilanciamento del carico nativo del container. Il carico del traffico viene bilanciato dal proxy Ingress direttamente all'IP del pod, anziché attraversare l'IP del nodo o il networking kube-proxy. Inoltre, vengono implementate le gate di idoneità dei pod per determinare l'integrità dei pod dal punto di vista del bilanciatore del carico e non solo dai controlli di idoneità e attività di Kubernetes. I limiti di idoneità dei pod assicurano che il traffico non venga perso durante 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 ti impedisce di configurare il bilanciatore del carico delle applicazioni interno. Se l'annotazione NEG non è inclusa, viene generato anche un evento Kubernetes sulla risorsa Ingress. Di seguito è riportato un esempio di questo messaggio:

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 traffico in entrata non fa riferimento al servizio. Il NEG non viene visualizzato in Compute Engine finché non esistono sia l'oggetto Ingress che il servizio di riferimento. I NEG sono una risorsa di zona e, per i cluster multi-zona, ne viene creato uno per servizio per zona.

Per creare un servizio:

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

Applica il manifest al cluster:
```
kubectl apply -f web-service.yaml
```

Deployment di Ingress

In questa sezione creerai una risorsa Ingress che attiva il deployment di un bilanciatore del carico Compute Engine tramite il controller Ingress. La risorsa 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 valore GKE in entrata. Devi utilizzare l'annotazione kubernetes.io/ingress.class. Per saperne di più, consulta Comportamento del controller Ingress di GKE.

Per creare una risorsa Ingress:

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

Applica il manifest al cluster:
```
kubectl apply -f internal-ingress.yaml
```

Convalida di un deployment Ingress riuscito

In questa sezione verificherai l'esito positivo del deployment.

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

Poiché l'Application Load Balancer interno è un bilanciatore del carico a livello di regione, l'IP virtuale (VIP) è accessibile solo da un client nella stessa regione e nella stessa rete VPC. Dopo aver recuperato il VIP del bilanciatore del carico, puoi utilizzare alcuni strumenti (ad esempio curl) per emettere chiamate HTTP GET al VIP dall'interno del VPC.

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

Per raggiungere il VIP Ingress dall'interno del VPC, esegui il deployment di una VM nella 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 di Compute Engine nella regione.
Per scoprire di più sulla creazione delle istanze, consulta Creazione e avvio di un'istanza VM.
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. Usa curl per accedere al VIP dell'applicazione interna:
```
curl 10.128.0.58
hostname-server-6696cf5fc8-z4788
```
  La risposta HTTP corretta e il nome host di uno dei container di backend indicano che l'intero percorso di bilanciamento del carico funziona correttamente.

Eliminazione delle risorse in entrata

La rimozione delle risorse Ingress e di servizio comporta anche la rimozione delle risorse del bilanciatore del carico di Compute Engine associate. Per impedire fughe di risorse, assicurati che le risorse Ingress vengano eliminate quando non ne hai più bisogno. Devi anche eliminare le risorse Ingress e di servizio prima di eliminare i cluster oppure le risorse di bilanciamento del carico di Compute Engine rimangono orfane.

Per rimuovere un Ingress, completa i seguenti passaggi:

Elimina il traffico in entrata. Ad esempio, per eliminare il traffico in entrata creato in questa pagina, esegui questo comando:
```
kubectl delete ingress ilb-demo-ingress
```
L'eliminazione della risorsa Ingress rimuove le regole di forwarding, i servizi di backend e le mappe URL associati a questa risorsa Ingress.
Elimina il servizio. Ad esempio, per eliminare il servizio creato in questa pagina, esegui questo comando:
```
kubectl delete service hostname
```
L'eliminazione del servizio rimuove il NEG associato al servizio.

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

Indirizzamento IP statico

Le risorse Ingress 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 proxy poiché questa viene utilizzata solo per l'utilizzo interno di proxy. Questi indirizzi IP temporanei vengono allocati all'oggetto Ingress solo per il ciclo di vita della risorsa Ingress interna. Se elimini il tuo 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 a livello di regione. Puoi quindi specificare un indirizzo IP statico utilizzando l'annotazione kubernetes.io/ingress.regional-static-ip-name sulla tua 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. Il deployment di un bilanciatore del carico non viene eseguito finché non esiste un IP statico e il riferimento a una risorsa di indirizzo IP inesistente non comporta la creazione di un IP statico. Se modifichi un Ingress esistente in modo da 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 una risorsa Ingress di cui è stato eseguito il deployment nel progetto di servizio di un VPC condiviso.
Fai riferimento alla risorsa indirizzo IP di Google Cloud in base al nome, anziché all'indirizzo IP.
L'indirizzo IP deve provenire da una subnet nella stessa regione del cluster GKE. Puoi utilizzare qualsiasi subnet privata disponibile all'interno della regione (ad eccezione di una subnet solo proxy). Diverse risorse Ingress 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 dei certificati TLS verso i client. Puoi gestire i certificati TLS tramite secret di Kubernetes o tramite certificati SSL a livello di regione precondivise in Google Cloud. Puoi anche specificare più certificati per risorsa Ingress. L'utilizzo simultaneo di HTTPS e di 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 in entrata. Se non viene fornito un indirizzo IP statico, è consentito solo il traffico HTTPS e devi seguire la documentazione per la disattivazione di HTTP.

I passaggi seguenti illustrano come creare un certificato in Google Cloud e quindi gestirlo tramite Ingress nei client interni per il traffico sia HTTPS che HTTP:

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 a tua scelta per il certificato.
- CERT_FILE_PATH: il percorso del file del certificato locale per creare un certificato autogestito. Il certificato deve essere in formato PEM.
- KEY_FILE_PATH: il percorso di un file di chiave privata locale. La chiave privata deve essere in formato PEM e utilizzare la crittografia RSA o ECDSA.
- COMPUTE_REGION: una regione di Compute Engine per il tuo certificato.
Prenota e applica un indirizzo IP statico seguendo gli indirizzi IP statici.

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.

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 maggiori 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 esegui il deployment delle risorse Ingress si trova in un progetto di servizio VPC condiviso, i servizi non vengono automaticamente annotati con l'annotazione cloud.google.com/neg: '{"ingress": true}' perché l'MutatingWebhookConfiguration responsabile dell'inserimento dell'annotazione nei servizi non è installato.

Devi aggiungere l'annotazione NEG al manifest dei servizi esposti tramite Ingress per gli Application Load Balancer 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, all'account di servizio GKE del progetto di servizio devono essere concesse le autorizzazioni IAM appropriate nel progetto host, in base a quanto indicato nella gestione delle risorse firewall per i cluster con VPC condiviso. Ciò 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 interne in entrata

Le seguenti tabelle mostrano le annotazioni che puoi aggiungere durante la creazione di risorse Ingress e di servizio per Ingress per bilanciatori del carico delle applicazioni interni.

Annotazioni in entrata

Annotazione	Description
`kubernetes.io/ingress.class`	Puoi impostare come `"gce-internal"` per Ingress interno. 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`. Per ulteriori informazioni, consulta la sezione Disabilitazione 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 maggiori informazioni, consulta la pagina relativa all'utilizzo di 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'evento `firewallXPNError`. Per i bilanciatori del carico Ingress, se Kubernetes non può modificare le regole firewall a causa di autorizzazioni insufficienti, viene creato un evento `firewallXPNError` ogni alcuni minuti. Aggiungi l'annotazione `networking.gke.io/suppress-firewall-xpn-error: "true"` alla risorsa in entrata. Il valore predefinito è `false`. Per riattivare l'audio puoi rimuovere questa annotazione.
`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 la sezione Indirizzi IP statici.

Annotazioni di servizio relative a Ingress

Annotazione	Description
`cloud.google.com/backend-config`	Utilizza questa annotazione per configurare il servizio di backend associato a una servicePort. Per maggiori informazioni, consulta la pagina relativa alla configurazione 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 Utilizzo del 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 backend che non appaiono integri.

Alcune procedure comuni per la risoluzione dei problemi includono:

Verificare che il traffico client provenga dalla stessa regione e dalla stessa rete VPC del bilanciatore del carico.
Verifica che i pod e i backend siano integri.
Convalida del percorso del traffico al VIP e ai controlli di integrità di Compute Engine per garantire che non sia bloccato dalle regole firewall.
Controllo della presenza di errori negli eventi delle risorse Ingress.
Descrizione della risorsa Ingress per visualizzare il mapping alle risorse di Compute Engine.
Convalida dell'esistenza delle risorse di bilanciamento del carico di Compute Engine, che hanno le configurazioni corrette e non sono stati segnalati errori.

Filtro per eventi Ingress

I seguenti filtri di query per rilevare gli errori in tutti gli eventi Ingress nel cluster:

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

Puoi anche filtrare in base agli oggetti o ai nomi degli 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 visualizza l'output completo della risorsa Ingress, in modo che tu possa vedere 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 relativo stato. Assicurati che i backend siano elencati come HEALTHY.

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

Per elencare tutte le regole di forwarding di Compute Engine:

gcloud compute forwarding-rules list

L'output è simile al seguente:

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

Per elencare 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 sull'integrità:

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

Scopri di più su GKE Ingress per bilanciatori del carico delle applicazioni esterni.
Leggi una panoramica concettuale dei servizi in GKE.
Scopri come creare un bilanciatore del carico di rete passthrough interno su GKE.
Implementa un Ingress interno di base.