Informazioni sul routing e sulla sicurezza di GKE Ingress

Autopilot Standard

Questa pagina descrive le funzionalità principali e l'architettura di rete di GKE Ingress, in particolare la protezione delle connessioni dal client al bilanciatore del carico e ai pod dell'applicazione, la gestione del routing complesso su più servizi di backend e la comprensione di come vengono orchestrati i controlli di integrità del bilanciatore del carico all'interno di un cluster.

Questa pagina si basa sui concetti fondamentali descritti nella panoramica di GKE Ingress. Per istruzioni passo passo ed esempi di implementazione che utilizzano risorse personalizzate come FrontendConfig e BackendConfig, consulta Configurare le funzionalità Ingress per le applicazioni GKE.

Questa pagina è dedicata agli specialisti di networking che progettano e realizzano l'architettura di rete per la loro organizzazione e installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Protezione di Ingress con HTTPS

GKE Ingress protegge il traffico tra il client e il bilanciatore del carico delle applicazioni e dal bilanciatore del carico ai pod dell'applicazione.

Configurazione di TLS tra il client e il bilanciatore del carico

Un bilanciatore del carico HTTP(S) funge da proxy tra i client e l'applicazione. Se vuoi accettare richieste HTTPS dai tuoi client, il bilanciatore del carico deve avere un certificato per poter dimostrare la propria identità ai tuoi client. Il bilanciatore del carico deve avere anche una chiave privata per completare l'handshake HTTPS.

Quando il bilanciatore del carico accetta una richiesta HTTPS da un client, il traffico tra il client e il bilanciatore del carico viene criptato utilizzando TLS. Tuttavia, il bilanciatore del carico termina la crittografia TLS e inoltra la richiesta senza crittografia all'applicazione. Per ulteriori informazioni, vedi Configurazione della crittografia tra il bilanciatore del carico e l'applicazione.

Metodi per fornire certificati SSL

Nota: per utilizzare i certificati gestiti da Certificate Manager, ti consigliamo di utilizzare l'API Gateway. GKE Ingress non supporta i certificati gestiti da Gestore certificati.

Puoi fornire certificati SSL a un bilanciatore del carico HTTP(S) utilizzando i seguenti metodi:

• Certificati gestiti da Google: si tratta di certificati di convalida del dominio (DV) che Google esegue il provisioning, il rinnovo e la gestione per i tuoi nomi di dominio. Questi certificati non dimostrano la tua identità personale o quella della tua organizzazione. I certificati gestiti da Google supportano fino a 100 domini non con caratteri jolly. Per saperne di più, consulta Utilizzare i certificati gestiti da Google.

• Certificati autogestiti condivisi con Google Cloud: puoi eseguire il provisioning del tuo certificato SSL e creare una risorsa del certificato nel tuo progetto Google Cloud . Quindi, elenca la risorsa del certificato in un'annotazione su un Ingress per creare un bilanciatore del carico HTTP(S) che utilizzi il certificato. Per saperne di più, vedi Utilizzare i certificati precondivisi.

• Certificati autogestiti che utilizzano i secret di Kubernetes: puoi eseguire il provisioning del tuo certificato SSL e creare un secret per contenerlo. Puoi fare riferimento al secret nel campo tls di un manifest Ingress per creare un bilanciatore del carico HTTP(S). Per maggiori informazioni, consulta Utilizzare i secret di Kubernetes.

Gestire il traffico HTTPS con più certificati

Puoi configurare il bilanciatore del carico delle applicazioni in modo che presenti fino a 15 certificati TLS a un client. L'utilizzo di più certificati è essenziale quando devi pubblicare contenuti da più nomi host, ognuno dei quali richiede un certificato diverso (ad esempio, certificati separati per il tuo-negozio.example e il tuo-negozio-sperimentale.example). Specifichi questi più certificati nel manifest Ingress.

Selezione e priorità dei certificati

Per determinare quale certificato presentare al client, il bilanciatore del carico utilizza l'indicazione del nome del server (SNI).

• Se il client utilizza SNI o un nome di dominio che corrisponde al nome comune (CN) in uno dei certificati disponibili, il bilanciatore del carico utilizza il certificato il cui CN corrisponde più da vicino al nome host richiesto dal client.

• Se il client non supporta SNI o il nome di dominio richiesto non corrisponde al CN di alcun certificato disponibile, il bilanciatore del carico utilizza come predefinito il primo certificato elencato nel manifest Ingress. Il bilanciatore del carico sceglie questo certificato in base alle seguenti regole:

  • Per i secret elencati nel blocco tls: il certificato principale è il primo secret nel blocco tls.
  • Per i certificati precondivisi nell'annotazione pre-shared-cert: il certificato principale è il primo certificato elencato nell'annotazione.
  • per i certificati gestiti da Google nell'annotazione managed-certificates: tutti i certificati gestiti sono ordinati alfabeticamente per nome. Il certificato principale è il primo di questo elenco in ordine alfabetico. Per impostare un certificato specifico come principale, devi denominare gli oggetti ManagedCertificate in modo appropriato per controllare l'ordine di ordinamento. Ad esempio, per impostare my-default-cert come principale rispetto a another-cert, puoi chiamarli 0-my-default-cert e 1-another-cert.

Quando il bilanciatore del carico presenta più certificati tramite diversi metodi GKE, i certificati pre-condivisi hanno la priorità rispetto ai secret elencati nel blocco Ingress tls.

Il seguente diagramma mostra il bilanciatore del carico che invia il traffico a backend diversi, a seconda del nome di dominio utilizzato nella richiesta:

Best practice per la rotazione dei certificati

Se vuoi ruotare i contenuti del tuo secret o del certificato pre-condiviso, ecco alcune best practice:

• Crea un nuovo secret o un nuovo certificato precondiviso con un nome diverso che contenga i nuovi dati del certificato. Aggiorna l'ingresso in modo che utilizzi la nuova risorsa certificato.
• Se non ti preoccupa interrompere il traffico, puoi rimuovere la vecchia risorsa dall'ingresso, eseguire il provisioning di una nuova risorsa con lo stesso nome ma contenuti diversi e poi ricollegarla all'ingresso.

Per evitare di gestire autonomamente la rotazione dei certificati, utilizza i certificati SSL gestiti da Google.

Applicazione del traffico solo HTTPS

Se vuoi che tutto il traffico tra il client e il bilanciatore del carico HTTP(S) utilizzi HTTPS, puoi disattivare HTTP includendo l'annotazione kubernetes.io/ingress.allow-http nel manifest Ingress e impostando il valore su "false". Per saperne di più, consulta Disattivazione di HTTP.

Attenzione: la disattivazione di HTTP non è supportata per Ingress multi-cluster.

Configurazione della crittografia tra il bilanciatore del carico e l'applicazione

Questa sezione spiega come proteggere la connessione dal bilanciatore del carico ai pod dell'applicazione.

Abilitazione del protocollo di backend HTTPS o HTTP/2

Il bilanciatore del carico delle applicazioni esterno funge da proxy tra i client e l'applicazione GKE. Sebbene i client possano connettersi al bilanciatore del carico utilizzando HTTPS (per la crittografia) e vari protocolli (HTTP/1.1 o HTTP/2), la connessione dal bilanciatore del carico ai pod di backend è impostata per impostazione predefinita su HTTP/1.1 non criptato.

Se la tua applicazione è in grado di gestire configurazioni più avanzate, puoi aggiornare manualmente il bilanciatore del carico delle applicazioni esterno in modo che utilizzi:

• HTTP/2: per ottimizzare il rendimento se i tuoi pod lo supportano.
• HTTPS (TLS): per applicare la crittografia end-to-end per il traffico tra il proxy del bilanciatore del carico e i tuoi pod.

Controlli sia il protocollo (HTTP o HTTPS) sia la versione HTTP (HTTP/1.1 o HTTP/2) utilizzati per la connessione di backend utilizzando l'annotazione cloud.google.com/app-protocols nel manifest del servizio Kubernetes. Questo manifest del servizio deve includere type: NodePort, a meno che tu non stia utilizzando il bilanciamento del carico nativo del container. Se utilizzi il bilanciamento del carico nativo del container, utilizza type: ClusterIP.

Indirizzi IP statici per i bilanciatori del carico HTTPS

Quando crei un oggetto Ingress per un bilanciatore del carico delle applicazioni esterno, ottieni un indirizzo IP esterno stabile che i client possono utilizzare per accedere ai tuoi servizi e, a loro volta, ai tuoi container in esecuzione. L'indirizzo IP è stabile nel senso che dura per tutta la durata dell'oggetto Ingress. Se elimini l'oggetto Ingress e ne crei uno nuovo dallo stesso file manifest, non è garantito che tu ottenga lo stesso indirizzo IP esterno.

Se vuoi un indirizzo IP permanente che rimanga invariato anche dopo l'eliminazione dell'ingresso e la creazione di uno nuovo, devi prenotare un indirizzo IP esterno statico globale. Poi, nel manifest Ingress, includi un'annotazione che fornisca il nome dell'indirizzo IP statico riservato. Se modifichi un Ingress esistente in modo che utilizzi un indirizzo IP statico anziché un indirizzo IP temporaneo, GKE potrebbe modificare l'indirizzo IP del bilanciatore del carico quando ricrea la regola di forwarding del bilanciatore del carico.

Routing del traffico

GKE Ingress utilizza le mappe URL per definire come le richieste in entrata vengono instradate a servizi di backend specifici. Puoi configurare regole di routing basate su nomi host, percorsi URL o una combinazione di entrambi per gestire il traffico per più applicazioni tramite un unico bilanciatore del carico.

Più servizi di backend

Ogni bilanciatore del carico delle applicazioni esterno o interno utilizza una singola mappa URL, che fa riferimento a uno o più servizi di backend. Un servizio di backend corrisponde a ogni servizio a cui fa riferimento l'ingresso.

Ad esempio, puoi configurare il bilanciatore del carico per instradare le richieste a servizi di backend diversi a seconda del percorso URL. Le richieste inviate a your-store.example potrebbero essere indirizzate a un servizio di backend che mostra gli articoli a prezzo pieno, mentre le richieste inviate a your-store.example/discounted potrebbero essere indirizzate a un servizio di backend che mostra gli articoli scontati.

Puoi anche configurare il bilanciatore del carico per instradare le richieste in base al nome host. Le richieste inviate a your-store.example potrebbero andare a un servizio di backend, mentre quelle inviate a your-experimental-store.example potrebbero andare a un altro servizio di backend.

In un cluster GKE, crei e configuri un bilanciatore del carico HTTP(S) creando un oggetto Kubernetes Ingress. Un oggetto Ingress deve essere associato a uno o più oggetti Service, ognuno dei quali è associato a un insieme di pod.

Se vuoi configurare GKE Ingress con più backend per lo stesso host, devi avere una singola regola con un singolo host e più percorsi. In caso contrario, il controller Ingress GKE esegue il provisioning di un solo servizio di backend

Ecco un manifest per un Ingress chiamato my-ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
 rules:
  - host: your-store.example
    http:
      paths:
      - path: /products
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Nota: per utilizzare Ingress, devi aver attivato il componente aggiuntivo del bilanciatore del carico delle applicazioni esterno. I cluster GKE hanno i bilanciatori del carico delle applicazioni esterni abilitati per impostazione predefinita; non devi disabilitarli.

Quando crei Ingress, il controller Ingress di GKE crea e configura un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico delle applicazioni interno in base alle informazioni in Ingress e nei servizi associati. Inoltre, al bilanciatore del carico viene assegnato un indirizzo IP stabile che puoi associare a un nome di dominio.

Nell'esempio precedente, supponiamo che tu abbia associato l'indirizzo IP del bilanciatore del carico al nome di dominio your-store.example. Quando un client invia una richiesta a your-store.example/products, la richiesta viene indirizzata a un servizio Kubernetes denominato my-products sulla porta 60000. Quando un client invia una richiesta a your-store.example/discounted, la richiesta viene instradata a un servizio Kubernetes denominato my-discounted-products sulla porta 80.

L'unico carattere jolly supportato per il campo path di un Ingress è il carattere *. Il carattere * deve seguire una barra (/) e deve essere l'ultimo carattere nel pattern. Ad esempio, /*, /foo/* e /foo/bar/* sono pattern validi, mentre *, /foo/bar* e /foo/*/bar non lo sono.

Un pattern più specifico ha la precedenza su un pattern meno specifico. Se hai sia /foo/* che /foo/bar/*, /foo/bar/bat viene preso in considerazione per corrispondere a /foo/bar/*.

Per ulteriori informazioni sulle limitazioni del percorso e sulla corrispondenza dei pattern, consulta la documentazione sulle mappe URL.

Il manifest per il servizio my-products potrebbe avere il seguente aspetto:

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

Tieni presente quanto segue nel manifest precedente:

• Il campo spec.type dipende dal metodo di bilanciamento del carico utilizzato:

  • Se utilizzi il bilanciamento del carico nativo del container, utilizza type: ClusterIP.
  • Se utilizzi gruppi di istanze, utilizza type: NodePort.

• Il campo selector indica che qualsiasi pod con l'etichetta app: products e l'etichetta department: sales è membro di questo servizio.

• Quando una richiesta arriva al servizio sulla porta 60000, viene indirizzata a uno dei pod membri sulla porta TCP 50000.

• Ogni pod membro deve avere un container in ascolto sulla porta TCP 50000.

Il manifest per il servizio my-discounted-products potrebbe avere il seguente aspetto:

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Tieni presente quanto segue nel manifest precedente:

• Il campo selector indica che qualsiasi pod con l'etichetta app: discounted-products e l'etichetta department: sales è membro di questo servizio.

• Quando una richiesta arriva al servizio sulla porta 80, viene instradata a uno dei pod membri sulla porta TCP 8080.

• Ogni pod membro deve avere un container in ascolto sulla porta TCP 8080.

Backend predefinito

Puoi specificare un backend predefinito per Ingress fornendo un campo spec.defaultBackend nel manifest Ingress. In questo modo, verranno gestite tutte le richieste che non corrispondono ai percorsi definiti nel campo rules. Ad esempio, nel seguente Ingress, tutte le richieste che non corrispondono a /discounted vengono inviate a un servizio denominato my-products sulla porta 60001.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  defaultBackend:
    service:
      name: my-products
      port:
        number: 60001
  rules:
  - http:
      paths:
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Se non specifichi un backend predefinito, GKE ne fornisce uno che restituisce 404. Viene creato come servizio NodePort default-http-backend sul cluster nello spazio dei nomi kube-system.

La risposta HTTP 404 è simile alla seguente:

response 404 (backend NotFound), service rules for the path non-existent

Per configurare GKE Ingress con un backend predefinito personalizzato, consulta la sezione GKE Ingress con backend predefinito personalizzato.

Controlli di integrità

Quando esponi uno o più servizi tramite un Ingress utilizzando il controller Ingress predefinito, GKE crea un bilanciatore del carico delle applicazioni classico o un bilanciatore del carico delle applicazioni interno. Entrambi questi bilanciatori del carico supportano più servizi di backend in una singola mappa URL. Ciascuno dei servizi di backend corrisponde a un servizio Kubernetes e ogni servizio di backend deve fare riferimento a un Google Cloud controllo di integrità. Questo controllo di integrità è diverso da un probe di attività o di idoneità di Kubernetes perché viene implementato al di fuori del cluster.

I controlli di integrità del bilanciatore del carico vengono specificati per servizio di backend. Sebbene sia possibile utilizzare lo stesso controllo di integrità per tutti i servizi di backend del bilanciatore del carico, il riferimento al controllo di integrità non è specificato per l'intero bilanciatore del carico (nell'oggetto Ingress stesso).

GKE crea controlli di integrità in base a uno dei seguenti metodi:

• BackendConfig CRD: una definizione di risorsa personalizzata (CRD) che ti offre un controllo preciso sul modo in cui i tuoi servizi interagiscono con il bilanciatore del carico. Le CRD BackendConfig ti consentono di specificare impostazioni personalizzate per il controllo di integrità associato al servizio di backend corrispondente. Queste impostazioni personalizzate offrono maggiore flessibilità e controllo sui controlli di integrità sia per il bilanciatore del carico delle applicazioni classico sia per il bilanciatore del carico delle applicazioni interno creato da un Ingress.
• Probe di idoneità: un controllo diagnostico che determina se un container all'interno di un pod è pronto a gestire il traffico. Il controller Ingress GKE crea il controllo di integrità per il servizio di backend del servizio in base al probe di disponibilità utilizzato dai pod di pubblicazione del servizio. Puoi derivare i parametri del controllo di integrità, come percorso, porta e protocollo, dalla definizione del probe di preparazione.
• Valori predefiniti: i parametri utilizzati quando non configuri un BackendConfig CRD o non definisci gli attributi per il probe di disponibilità.

Best practice:

Utilizza un CRD BackendConfig per avere il massimo controllo sulle impostazioni del controllo di integrità del bilanciatore del carico.

GKE utilizza la seguente procedura per creare un controllo di integrità per ogni servizio di backend corrispondente a un servizio Kubernetes:

• Se il servizio fa riferimento a una CRD BackendConfig con informazioni healthCheck, GKE le utilizza per creare il controllo di integrità. Sia il controller GKE Enterprise Ingress sia il controller GKE Ingress supportano la creazione di controlli di integrità in questo modo.

• Se il servizio non fa riferimento a una CRD BackendConfig:

  • GKE può dedurre alcuni o tutti i parametri per un controllo di integrità se i pod di servizio utilizzano un modello di pod con un container la cui sonda di idoneità ha attributi che possono essere interpretati come parametri di controllo di integrità. Consulta Parametri di un probe di preparazione per i dettagli di implementazione e Parametri predefiniti e dedotti per un elenco degli attributi che possono essere utilizzati per creare parametri di controllo di integrità. Solo il controller GKE Ingress supporta l'inferenza dei parametri da un probe di preparazione.

  • Se il modello di pod per i pod di pubblicazione del servizio non ha un container con un probe di idoneità i cui attributi possono essere interpretati come parametri di controllo di integrità, i valori predefiniti vengono utilizzati per creare il controllo di integrità. Sia il controller Ingress di GKE Enterprise sia il controller Ingress di GKE possono creare un controllo di integrità utilizzando solo i valori predefiniti.

Nota: il campo containerPort deve essere definito nella specifica del pod e il campo targetPort deve essere definito nella specifica del servizio affinché il controllo di integrità possa dedurre i parametri definiti nel probe di preparazione. Se non sono definiti, il controllo di integrità per il servizio di backend utilizza il percorso "/" per impostazione predefinita, anche se i parametri sono definiti nel probe di preparazione.

Parametri predefiniti e dedotti

I seguenti parametri vengono utilizzati quando non specifichi i parametri di controllo di integrità per il servizio corrispondente utilizzando un BackendConfigCRD.

Parametro del controllo di integrità	Valore predefinito	Valore deducibile
Protocollo	HTTP	se presente nell'annotazione del servizio cloud.google.com/app-protocols
Percorso richiesta	/	se presente nel spec del pod in uso: containers[].readinessProbe.httpGet.path
Intestazione Host della richiesta	Host: backend-ip-address	se presente nel spec del pod in uso: containers[].readinessProbe.httpGet.httpHeaders
Risposta prevista	HTTP 200 (OK)	HTTP 200 (OK) non può essere modificato
Intervallo di controllo	Per il bilanciamento del carico nativo del container: 15 secondi per i gruppi di istanze: 60 secondi	se presente nel pod in uso spec: per il bilanciamento del carico nativo del container: containers[].readinessProbe.periodSeconds per i gruppi di istanze: containers[].readinessProbe.periodSeconds + 60 seconds
Controlla il timeout	5 secondi	se presente nel spec del pod in uso: containers[].readinessProbe.timeoutSeconds
Soglia stato integro	1	1 cannot be changed
Soglia stato non integro	per il bilanciamento del carico nativo del container: 2 per i gruppi di istanze: 10	uguale al valore predefinito: per il bilanciamento del carico nativo del container: 2 per i gruppi di istanze: 10
Specifica della porta	per il bilanciamento del carico nativo del container: port del servizio per i gruppi di istanze: nodePort del servizio	I probe di controllo di integrità vengono inviati al numero di porta specificato da spec.containers[].readinessProbe.httpGet.port, a condizione che siano vere anche tutte le seguenti condizioni: Il numero di porta del probe di preparazione deve corrispondere a quello del pod di pubblicazione containers[].spec.ports.containerPort Il containerPort del pod di pubblicazione corrisponde al targetPort del servizio La specifica della porta del backend del servizio di Ingress fa riferimento a una porta valida di spec.ports[] del servizio. Questa operazione può essere eseguita in due modi: spec.rules[].http.paths[].backend.service.port.name in Ingress corrisponde a spec.ports[].name definito nel servizio corrispondente spec.rules[].http.paths[].backend.service.port.number in Ingress corrisponde a spec.ports[].port definito nel servizio corrispondente
Indirizzo IP di destinazione	Per il bilanciamento del carico nativo del container: l'indirizzo IP del pod per i gruppi di istanze: l'indirizzo IP del nodo	uguale al valore predefinito: Per il bilanciamento del carico nativo del container: l'indirizzo IP del pod per i gruppi di istanze: l'indirizzo IP del nodo

Nota :un probe di disponibilità Kubernetes valido supporta l'impostazione di più intestazioni HTTP in readinessProbe.httpGet. Se readinessProbe.httpGet.httpHeaders specifica più dell'intestazione Host, i parametri del controllo di integrità del bilanciatore del carico vengono impostati sui valori predefiniti anziché sui valori dedotti dal probe di disponibilità. Questa limitazione esiste perché i controlli di integrità supportano solo l'impostazione dell'intestazione Host.

Parametri di un probe di idoneità

Quando GKE crea il controllo di integrità per il servizio di backend del servizio, può copiare determinati parametri dal probe di preparazione di un container utilizzato dai pod di pubblicazione del servizio. Questa opzione è supportata solo dal controller Ingress GKE.

Gli attributi di sonda di preparazione supportati che possono essere interpretati come parametri di controllo di integrità dell'integrità sono elencati insieme ai valori predefiniti in Parametri predefiniti e dedotti. I valori predefiniti vengono utilizzati per tutti gli attributi non specificati nel probe di idoneità o se non specifichi alcun probe di idoneità.

Se i pod di servizio contengono più container o se utilizzi il controller Ingress di GKE Enterprise, devi utilizzare una CRD BackendConfig per definire i parametri del controllo di integrità. Per saperne di più, consulta Quando utilizzare una BackendConfig CRD.

Avviso: quando i parametri del controllo di integrità di un servizio di backend vengono dedotti da un probe di preparazione di un pod di pubblicazione, GKE non mantiene sincronizzati il probe di preparazione e il controllo di integrità:

• Se modifichi il probe di preparazione per i pod di servizio di un servizio a cui fa riferimento un ingresso dopo che GKE ha creato il bilanciatore del carico delle applicazioni esterno o interno per quell'ingresso, le modifiche apportate al probe di preparazione non verranno copiate nel controllo di integrità per il servizio di backend corrispondente sul bilanciatore del carico.
• Al contrario, se apporti modifiche al controllo di integrità utilizzato da un servizio di backend di un bilanciatore del carico creato per conto di un Ingress, GKE non aggiornerà alcun probe di idoneità né ripristinerà le modifiche apportate al controllo di integrità.

Quando utilizzare le CRD BackendConfig

Anziché fare affidamento sui parametri dei probe di preparazione dei pod, devi definire esplicitamente i parametri del controllo di integrità per un servizio di backend creando una CRD BackendConfig per il servizio in queste situazioni:

• Se utilizzi GKE Enterprise:il controller Ingress di GKE Enterprise non supporta l'ottenimento dei parametri di controllo di integrità dell'integrità dalle sonde di prontezza dei pod di servizio. Può creare solo controlli di integrità utilizzando parametri impliciti o come definito in una CRD BackendConfig.

• Se hai più di un container nei pod di pubblicazione:GKE non consente di selezionare il probe di preparazione di un container specifico da cui dedurre i parametri del controllo di integrità. Poiché ogni container può avere il proprio probe di disponibilità e poiché un probe di disponibilità non è un parametro obbligatorio per un container, devi definire il controllo di integrità per il servizio di backend corrispondente facendo riferimento a un CRD BackendConfig sul servizio corrispondente.

• Se hai bisogno di controllare la porta utilizzata per i controlli di integrità del bilanciatore del carico: GKE utilizza solo containers[].readinessProbe.httpGet.port del probe di idoneità per il controllo di integrità del servizio di backend quando la porta corrisponde alla porta di servizio per il servizio a cui viene fatto riferimento nell'ingresso spec.rules[].http.paths[].backend.servicePort.

Parametri di un CRD BackendConfig

Puoi specificare i parametri di controllo di integrità del servizio di backend utilizzando il parametro healthCheck di un CRD BackendConfig a cui fa riferimento il servizio corrispondente. In questo modo, hai maggiore flessibilità e controllo sui controlli di integrità per un bilanciatore del carico delle applicazioni classico o un bilanciatore del carico delle applicazioni interno creato da un Ingress. Consulta la sezione Configurazione ingress per la compatibilità delle versioni di GKE.

Questo esempio di CRD BackendConfig definisce il protocollo (tipo) del controllo di integrità, un percorso della richiesta, una porta e un intervallo di controllo nel relativo attributo spec.healthCheck:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

Per configurare tutti i campi disponibili quando configuri un controllo di integrità BackendConfig, utilizza l'esempio di configurazione del controllo di integrità personalizzato.

Per configurare GKE Ingress con un controllo di integrità HTTP personalizzato, consulta GKE Ingress con controllo di integrità HTTP personalizzato.

Pod readiness

Dopo aver configurato i controlli di integrità del bilanciatore del carico utilizzando uno dei metodi precedenti, il controller Ingress di GKE utilizza lo stato di integrità degli endpoint di backend per determinare la prontezza dei pod, che è fondamentale per la gestione degli aggiornamenti in sequenza e della stabilità complessiva del traffico.

Per i pod pertinenti, il controller Ingress corrispondente gestisce un gate di idoneità di tipo cloud.google.com/load-balancer-neg-ready. Il controller Ingress esegue il polling dello stato del controllo di integrità del bilanciatore del carico, che include l'integrità di tutti gli endpoint nel NEG. Quando lo stato del controllo di integrità del bilanciatore del carico indica che l'endpoint corrispondente a un determinato pod è integro, il controller Ingress imposta il valore del gate di idoneità del pod su True. Il kubelet in esecuzione su ogni nodo calcola l'effettiva prontezza del pod, tenendo conto sia del valore di questo gate di prontezza sia, se definita, della sonda di prontezza del pod.

I gate di preparazione dei pod vengono attivati automaticamente quando si utilizza il bilanciamento del carico nativo del container tramite Ingress.

I gate di preparazione controllano la velocità di un aggiornamento in sequenza. Quando avvii un aggiornamento in sequenza, GKE crea nuovi pod e un endpoint per ogni nuovo pod viene aggiunto a un NEG. Quando l'endpoint è integro dal punto di vista del bilanciatore del carico, il controller Ingress imposta il gate di idoneità su True. Un pod appena creato deve superare almeno il gate di preparazione prima che GKE rimuova un vecchio pod. In questo modo, l'endpoint corrispondente del pod ha già superato il controllo di integrità del bilanciatore del carico e la capacità del backend viene mantenuta.

Se l'indicatore di disponibilità di un pod non indica mai che il pod è pronto, a causa di un'immagine container errata o di un controllo di integrità del bilanciatore del carico configurato in modo errato, il bilanciatore del carico non indirizzerà il traffico al nuovo pod. Se si verifica un errore di questo tipo durante l'implementazione di un deployment aggiornato, l'implementazione si blocca dopo aver tentato di creare un nuovo pod perché il readiness gate del pod non è mai True. Per informazioni su come rilevare e risolvere questo problema, consulta la sezione relativa alla risoluzione dei problemi.

Senza il bilanciamento del carico nativo dei container e i readiness gate, GKE non può rilevare se gli endpoint di un bilanciatore del carico sono integri prima di contrassegnare i pod come pronti. Nelle versioni precedenti di Kubernetes, controlli la velocità con cui i pod vengono rimossi e sostituiti specificando un periodo di ritardo (minReadySeconds nella specifica del deployment).

GKE imposta il valore di cloud.google.com/load-balancer-neg-ready per un pod su True se viene soddisfatta una delle seguenti condizioni:

• Nessuno degli indirizzi IP del pod è un endpoint in un NEG GCE_VM_IP_PORT gestito dal control plane GKE.
• Uno o più indirizzi IP del pod sono endpoint in un GCE_VM_IP_PORT NEG gestito dal control plane GKE. Il NEG è collegato a un servizio di backend. Il servizio di backend ha un controllo di integrità del bilanciatore del carico riuscito.
• Uno o più indirizzi IP del pod sono endpoint in un NEG GCE_VM_IP_PORT gestito dal control plane GKE. Il NEG è collegato a un servizio di backend. Il controllo di integrità del bilanciatore del carico per il servizio di backend scade.
• Uno o più indirizzi IP del pod sono endpoint in uno o più NEG GCE_VM_IP_PORT. Nessun NEG è collegato a un servizio di backend. Non sono disponibili dati controllo di integrità del bilanciatore del carico.

Supporto di WebSocket

Con i bilanciatori del carico delle applicazioni esterni, il protocollo WebSocket funziona senza alcuna configurazione.

Se intendi utilizzare il protocollo WebSocket, ti consigliamo di utilizzare un valore di timeout superiore a 30 secondi, il valore predefinito. Per il traffico WebSocket inviato tramite un bilanciatore del carico delle applicazioni esternoGoogle Cloud , il timeout del servizio di backend viene interpretato come il tempo massimo durante il quale una connessione WebSocket può rimanere aperta, inattiva o meno.

Per impostare il valore di timeout per un servizio di backend, consulta Timeout di risposta del backend.

Scenari di networking avanzato

GKE Ingress supporta configurazioni di rete avanzate, come la condivisione di risorse di rete tra progetti e l'utilizzo di controller Ingress personalizzati.

VPC condiviso

Le risorse Ingress e MultiClusterIngress sono supportate in VPC condiviso, ma richiedono una preparazione aggiuntiva.

Il controller in entrata viene eseguito sul control plane GKE ed effettua chiamate API a Google Cloud utilizzando l'account di servizio GKE del progetto del cluster. Per impostazione predefinita, quando un cluster che si trova in un progetto di servizio VPC condiviso utilizza una rete VPC condivisa, il controller Ingress non può utilizzare l'account di servizio GKE del progetto di servizio per creare e aggiornare le regole firewall di autorizzazione in entrata nel progetto host.

Puoi concedere al service account GKE del progetto di servizio le autorizzazioni per creare e gestire le regole firewall VPC nel progetto host. Concedendo queste autorizzazioni, GKE crea regole firewall di autorizzazione in entrata per quanto segue:

• Proxy Google Front End (GFE) e sistemi di controllo di integrità utilizzati dai bilanciatori del carico delle applicazioni esterni per Ingress esterno. Per saperne di più, consulta la panoramica del bilanciatore del carico delle applicazioni esterno.

• Sistemi di controllo di integrità per i bilanciatori del carico delle applicazioni interni utilizzati da Ingress interno.

  Nota: indipendentemente dal fatto che utilizzi o meno il VPC condiviso, se il cluster utilizza un Ingress interno, devi creare manualmente regole firewall di autorizzazione Ingress per consentire il traffico dalla subnet solo proxy nella rete VPC e nella regione del cluster. La creazione manuale di queste regole è necessaria perché il controller GKE Ingress non può creare regole firewall di autorizzazione in entrata per consentire il traffico per la subnet solo proxy di un bilanciatore del carico delle applicazioni interno. Per saperne di più, consulta Ambiente di rete richiesto in Ingress per i bilanciatori del carico delle applicazioni interni.

  Esegui il provisioning manuale delle regole firewall dal progetto host

Se le tue norme di sicurezza consentono la gestione del firewall solo dal progetto host, puoi eseguire il provisioning manuale di queste regole firewall. Quando esegui il deployment di Ingress in un VPC condiviso, l'evento della risorsa Ingress fornisce la regola firewall specifica necessaria per fornire l'accesso.

Per eseguire il provisioning manuale di una regola:

1. Visualizza l'evento della risorsa Ingress:

   kubectl describe ingress INGRESS_NAME
   

   Sostituisci INGRESS_NAME con il nome del tuo Ingress.

   Dovresti vedere un output simile al seguente esempio:

   Events:
   Type    Reason  Age                    From                     Message
   ----    ------  ----                   ----                     -------
   Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`
   

   La regola firewall obbligatoria suggerita viene visualizzata nella colonna Message.

2. Copia e applica le regole firewall suggerite dal progetto host. L'applicazione della regola fornisce l'accesso ai pod dal bilanciatore del carico e dai controlli di integritàGoogle Cloud .

   Nota: i diversi tipi di ingresso richiedono regole diverse. GKE potrebbe mostrare un avviso relativo alle regole firewall anche se hai regole firewall in entrata personalizzate per consentire il traffico. In questo caso, puoi ignorare l'avviso.

Nota: per Multi Cluster Ingress, questo passaggio di provisioning manuale è l'unico modo supportato per installare regole firewall in un progetto host. La modifica delle autorizzazioni del account di servizio per il provisioning automatico non è supportata.

Concessione al controller Ingress dell'autorizzazione per gestire le regole firewall del progetto host

Se vuoi che un cluster GKE in un progetto di servizio crei e gestisca le risorse firewall nel progetto host, al service account GKE del progetto di servizio devono essere concesse le autorizzazioni IAM appropriate utilizzando una delle seguenti strategie:

• Concedi al service account GKE del progetto di servizio il ruolo Amministratore della sicurezza Compute al progetto host. Il seguente esempio mostra questa strategia.

• Per un approccio più granulare, crea un ruolo IAM personalizzato che includa solo le seguenti autorizzazioni: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete e compute.subnetworks.list. Concedi al progetto di servizio il ruolo personalizzato del account di servizio GKE al progetto host.

Se hai cluster in più di un progetto di servizio, devi scegliere una delle strategie e ripeterla per ogni service account GKE del progetto di servizio.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:[e-mail] \
  --role=roles/compute.securityAdmin

Sostituisci quanto segue:

• HOST_PROJECT_ID: l'ID progetto del progetto host VPC condiviso.
• SERVICE_PROJECT_NUMBER: il numero di progetto del progetto di servizio che contiene il cluster.

Utilizzo di un controller Ingress personalizzato

Puoi eseguire un controller Ingress personalizzato disattivando il componente aggiuntivo HttpLoadBalancing. In questo modo, il controller Ingress GKE non elabora le risorse Ingress.

Se vuoi eseguire un controller Ingress personalizzato con il componente aggiuntivo HttpLoadBalancing attivato, ad esempio per utilizzare funzionalità come il sottoinsieme e Private Service Connect, puoi utilizzare uno dei seguenti approcci:

• Nel manifest Ingress, imposta l'annotazione kubernetes.io/ingress.class. Questa configurazione è supportata per i cluster che eseguono tutte le versioni di GKE.
• Configura il campo ingressClassName.
• Configura una classe Ingress predefinita.

Devi assicurarti che spec.ingressClassName non venga sovrascritto accidentalmente da nessun processo. Un'operazione di aggiornamento che modifica spec.IngressClassName da un valore valido a una stringa vuota ("") fa sì che il controller GKE Ingress elabori l'oggetto Ingress.

Configura il campo ingressClassName

Puoi utilizzare un controller Ingress personalizzato impostando il campo ingressClassName nel manifest Ingress. Il seguente manifest descrive un Ingress che specifica il controller Ingress cilium:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: cafe-ingress
spec:
 ingressClassName: cilium
 tls:
 - hosts:
   - cafe.example.com
   secretName: cafe-secret
 rules:
 - host: cafe.example.com

Nota: se un Ingress ha un spec.ingressClassName vuoto o spec.ingressClassName non è presente e l'Ingress non ha l'annotazione kubernetes.io/ingress.class, il controller GKE Ingress elabora l'Ingress.

Configura una classe Ingress predefinita

Puoi configurare una classe Ingress predefinita per tutte le risorse Ingress in un cluster creando una risorsa IngressClass con l'annotazione ingressclass.kubernetes.io/is-default-class impostata su true:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: gce
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-gce

Nota: il controller di ammissione compila il campo spec.ingressClassName per le nuove risorse Ingress nel cluster, ma non modifica le risorse Ingress esistenti.

Riepilogo del comportamento del controller Ingress GKE

Per i cluster che eseguono GKE 1.18 e versioni successive, se il controller Ingress GKE elabora un Ingress dipende dal valore dell'annotazione kubernetes.io/ingress.class e dal campo ingressClassName nel manifest Ingress. Per saperne di più, consulta Comportamento del controller Ingress GKE.

Modelli per la configurazione Ingress

• In GKE Networking Recipes, puoi trovare modelli forniti da GKE su molti utilizzi comuni di Ingress nella sezione Ingress.