Ingress per bilanciamento del carico HTTP(S) esterno

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

Questa pagina spiega come funziona Ingress per il bilanciamento del carico HTTP(S) esterno in Google Kubernetes Engine (GKE). Puoi anche scoprire come configurare e utilizzare Ingress per il bilanciamento del carico esterno.

Per informazioni generali sull'utilizzo del bilanciamento del carico in GKE, consulta Ingress per il bilanciamento del carico HTTP(S).

Panoramica

Il bilanciatore del carico HTTP(S) esterno di Google Cloud è un bilanciatore del carico distribuito a livello globale per l'esposizione pubblica di applicazioni su Internet. Viene implementato in tutti i punti di presenza Google (PoP) di tutto il mondo, fornendo connessioni HTTP(S) a bassa latenza agli utenti. Il routing anycast viene utilizzato per gli IP del bilanciatore del carico, che consente il routing di Internet per determinare il percorso di costo più basso al bilanciatore del carico Google più vicino.

GKE Ingress esegue il deployment del bilanciatore del carico HTTP(S) esterno per fornire il bilanciamento del carico nativo per i pod come backend.

Assistenza per le funzionalità di Google Cloud

Puoi utilizzare un backend per configurare un bilanciatore del carico HTTP(S) esterno in modo da utilizzare funzionalità come:

BackendConfig è una risorsa personalizzata che contiene informazioni sulla configurazione per le funzionalità di Google Cloud. Per ulteriori informazioni sulle funzionalità supportate, consulta Funzionalità in entrata.

Supporto per WebSocket

Con il bilanciamento del carico HTTP(S) esterno, il protocollo WebSocket funziona senza alcuna configurazione.

Se intendi utilizzare il protocollo WebSocket, ti consigliamo di utilizzare un valore di timeout maggiore del valore predefinito di 30 secondi. Per il traffico WebSocket inviato tramite un bilanciatore del carico HTTP(S) esterno di Google Cloud, il timeout del servizio di backend viene interpretato come la quantità massima di tempo durante il quale una connessione WebSocket può rimanere aperta, inattiva o meno.

Per impostare il valore di timeout per un servizio di backend configurato tramite Ingress, crea un oggetto BackendConfig e utilizza l'annotazione beta.cloud.google.com/backend-config nel manifest del servizio.

Per informazioni sulla configurazione, vedi Timeout della risposta di backend.

Indirizzi IP statici per i bilanciatori del carico HTTP(S)

Quando crei un oggetto Ingress, 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 la risorsa Ingress e ne crei una nuova dallo stesso file manifest, non è garantito di ottenere lo stesso indirizzo IP esterno.

Se vuoi che un indirizzo IP permanente rimanga invariato sia per l'eliminazione della risorsa Ingress sia per la creazione di uno nuovo, devi prenotare un indirizzo IP esterno statico globale. Quindi, nel manifest Ingress, includi un'annotazione che dia il nome del tuo indirizzo IP statico prenotato. Se modifichi una risorsa 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.

Ad esempio, supponi di aver prenotato un indirizzo IP esterno statico e globale denominato my-static-address. Nel manifest Ingress, includi un'annotazione kubernetes.io/ingress.global-static-ip-name come mostrato qui:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: my-static-address

Configurazione di HTTPS (TLS) tra client e bilanciatore del carico

Un bilanciatore del carico HTTP(S) funge da proxy tra i client e la tua applicazione. Se vuoi accettare richieste HTTPS dai tuoi client, il bilanciatore del carico deve disporre di un certificato in modo che possa dimostrare la sua identità ai client. Il bilanciatore del carico deve anche avere 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 tramite TLS. Tuttavia, il bilanciatore del carico termina la crittografia TLS e inoltra la richiesta senza crittografia all'applicazione. Per informazioni su come criptare il traffico tra il bilanciatore del carico e l'applicazione, consulta HTTPS tra il bilanciatore del carico e l'applicazione.

Puoi utilizzare i certificati SSL gestiti da Google o i certificati che gestisci tu. Per scoprire di più sulla creazione di una risorsa Ingress che utilizza certificati gestiti da Google, consulta Utilizzo dei certificati SSL gestiti da Google.

Per fornire un bilanciatore del carico HTTP(S) con un certificato e una chiave creati da te, crea un oggetto Secret Kubernetes. Il Secret contiene il certificato e la chiave. Aggiungi il secret al campo tls del manifest Ingress, come nell'esempio seguente:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
spec:
  tls:
  - secretName: SECRET_NAME
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 60000

Il file manifest include i seguenti valori:

  • SECRET_NAME: il nome del secret che hai creato.
  • SERVICE_NAME: il nome del servizio di backend.

Le modifiche ai secret vengono prese periodicamente, quindi se modifichi i dati all'interno del secret, ci vorranno un massimo di 10 minuti per applicarle al bilanciatore del carico.

Per ulteriori informazioni, consulta Utilizzare più certificati SSL nel bilanciamento del carico HTTPS con Ingress.

Disattivazione di HTTP

Se vuoi che tutto il traffico tra il client e il bilanciatore del carico HTTP(S) utilizzi HTTPS, puoi disabilitare HTTP includendo l'annotazione kubernetes.io/ingress.allow-http nel manifest Ingress. Imposta il valore dell'annotazione su "false".

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

I file manifest includono SECRET_NAME, ovvero il nome del Secret che hai creato.

Certificati precondivisi per i bilanciatori del carico

In alternativa all'utilizzo dei secret di Kubernetes per fornire certificati al bilanciatore del carico per la chiusura HTTP(S), puoi utilizzare i certificati caricati in precedenza nel tuo progetto Google Cloud. Per ulteriori informazioni, consulta Utilizzo dei certificati precondivisi e Utilizzo di più certificati SSL nel bilanciamento del carico HTTPS con Ingress.

HTTPS (TLS) tra il bilanciatore del carico e l'applicazione

Un bilanciatore del carico HTTP(S) funge da proxy tra i client e la tua applicazione. I client possono utilizzare HTTP o HTTPS per comunicare con il proxy del bilanciatore del carico. La connessione dal proxy del bilanciatore del carico alla tua applicazione utilizza HTTP per impostazione predefinita. Tuttavia, se la tua applicazione, in esecuzione in un pod GKE, è in grado di ricevere richieste HTTPS, puoi configurare il bilanciatore del carico in modo che utilizzi HTTPS quando inoltra le richieste all'applicazione.

Per configurare il protocollo utilizzato tra il bilanciatore del carico e l'applicazione, utilizza l'annotazione cloud.google.com/app-protocols nel manifest del servizio. Il 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.

Il manifest del servizio seguente specifica due porte. L'annotazione indica che quando un bilanciatore del carico HTTP(S) ha come target la porta 80 del servizio, deve utilizzare HTTP. Quando il bilanciatore del carico ha come target la porta 443 del servizio, deve utilizzare HTTPS.

Il manifest del servizio deve includere un valore name nell'annotazione relativa alla porta. Puoi modificare la porta del servizio solo facendo riferimento al valore name assegnato, non al suo valore targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

Passaggi successivi