Scopri come configurare e configurare l'installazione di Knative serving.
Prima di iniziare
Devi avere installato Knative serving sul tuo cluster GKE. Consulta le guida all'installazione per maggiori dettagli su Prerequisiti dei cluster GKE e come installare Knative serving.
Configurazione dell'autenticazione con Workload Identity Federation for GKE
Puoi utilizzare la federazione delle identità per i carichi di lavoro per GKE al fine di autenticare i servizi Knative serving alle API e ai servizi Google Cloud. Devi configurare la federazione delle identità per i carichi di lavoro per GKE prima di eseguire il deployment dei servizi nel cluster, altrimenti è necessario eseguire la migrazione di ogni servizio esistente nel cluster prima di abilitare la federazione delle identità per i carichi di lavoro per GKE. Scopri di più sull'utilizzo di Workload Identity Federation per GKE.
Attivazione delle metriche con Workload Identity Federation for GKE
Per attivare le metriche, come il conteggio del conteggio delle richieste di reporting o la latenza delle richieste a Google Cloud Observability, devi impostare manualmente le autorizzazioni di scrittura per e configurazione in Cloud Monitoring. Per maggiori dettagli, vedi Abilitazione delle metriche con la federazione delle identità per i carichi di lavoro per GKE.
Configurazione di HTTPS e domini personalizzati
Per attivare HTTPS e impostare un dominio personalizzato, consulta le seguenti pagine:
Configurazione di Cloud Service Mesh
Per configurare le opzioni del piano di controllo in-cluster per il servizio Knative, consulta le opzioni del piano di controllo in-cluster, tra cui come configurare una rete interna privata.
Configurazione di una rete interna privata
Il deployment dei servizi su una rete interna è utile per le aziende che forniscono app interne al proprio personale e per i servizi utilizzati dai client in esecuzione al di fuori del cluster di servizi Knative. Questa configurazione consente alle altre risorse della rete di comunicare con il servizio utilizzando un indirizzo IP privato interno (RFC 1918) a cui non può accedere il pubblico.
Per creare la tua rete interna, configuri Cloud Service Mesh in modo da utilizzare il bilanciamento del carico TCP/UDP interno anziché un bilanciatore del carico di rete pubblico ed esterno. Puoi quindi eseguire il deployment dei servizi di pubblicazione Knative su un indirizzo IP interno all'interno della tua rete VPC.
Prima di iniziare
- Devi disporre delle autorizzazioni
admin
per il cluster. - Se hai configurato un dominio personalizzato, devi disabilitare la funzionalità TLS gestito perché il protocollo TLS gestito su Knative serving attualmente non è supportato con il bilanciatore del carico interno.
- Sono supportate solo le versioni 310.0 o successive di Google Cloud CLI. Per informazioni dettagliate sulla configurazione degli strumenti a riga di comando, consulta
Per configurare il bilanciatore del carico interno:
Attiva la funzionalità del bilanciatore del carico interno in Cloud Service Mesh.
Il bilanciatore del carico interno è una funzionalità facoltativa che puoi configurare durante l'installazione di Cloud Service Mesh o aggiornando l'installazione esistente.
Segui i passaggi in Abilitazione di funzionalità facoltative nel piano di controllo nel cluster e assicurati di includere l'opzione dello script
--option internal-load-balancer
.Se specifichi l'opzione
--option internal-load-balancer
, lo script recupera automaticamente Abilita un bilanciatore del carico interno risorsa personalizzata da GitHub. Se devi modificare la risorsa personalizzata, segui invece le istruzioni per utilizzare l'opzione--custom_overlay
.Esegui questo comando per osservare gli aggiornamenti a GKE cluster:
kubectl -n INGRESS_NAMESPACE get svc istio-ingressgateway --watch
Sostituisci INGRESS_NAMESPACE con lo spazio dei nomi del tuo Servizio in entrata di Cloud Service Mesh. Specifica
istio-system
se hai installato Cloud Service Mesh utilizzando la configurazione predefinita.- Osserva l'annotazione
cloud.google.com/load-balancer-type: Internal
. - Cerca il valore
IP
nel bilanciatore del carico in entrata da modificare in un indirizzo IP privato. - Premi
Ctrl+C
per interrompere gli aggiornamenti quando vedi un indirizzo IP privato in nel campoIP
.
- Osserva l'annotazione
Per cluster privati devi aprire le porte su Google Cloud. Per maggiori dettagli, vedi apre le porte sul tuo cluster privato nella documentazione di Cloud Service Mesh.
Per verificare la connettività interna dopo le modifiche:
Esegui il deployment di un servizio chiamato
sample
in Knative serving nella Spazio dei nomidefault
:gcloud run deploy sample \ --image gcr.io/knative-samples/helloworld \ --namespace default --platform gke
Crea una macchina virtuale Compute Engine (VM) nella stessa zona del cluster GKE:
VM=cloudrun-gke-ilb-tutorial-vm gcloud compute instances create $VM
Archivia l'indirizzo IP privato del gateway Istio Ingress in un ambiente denominata
EXTERNAL_IP
e un file denominatoexternal-ip.txt
:export EXTERNAL_IP=$(kubectl -n INGRESS_NAMESPACE get svc istio-ingressgateway \ -o jsonpath='{.status.loadBalancer.ingress[0].ip}' | tee external-ip.txt)
Sostituisci INGRESS_NAMESPACE con lo spazio dei nomi del tuo Servizio in entrata di Cloud Service Mesh. Specifica
istio-system
se hai installato Cloud Service Mesh utilizzando la configurazione predefinita.Copia il file contenente l'indirizzo IP sulla VM:
gcloud compute scp external-ip.txt $VM:~
Connettiti alla VM tramite SSH:
gcloud compute ssh $VM
Mentre sei nella sessione SSH, prova il servizio di esempio:
curl -s -w'\n' -H Host:sample.default.nip.io $(cat external-ip.txt)
L'output è il seguente:
Hello World!
Esci dalla sessione SSH:
exit
Configurazione di un ambiente multi-tenant
Nei casi d'uso multi-tenant, dovrai gestire ed eseguire il deployment dei servizi di pubblicazione Knative in un cluster Google Kubernetes Engine al di fuori del tuo progetto attuale. Per saperne di più sulla multitenancy di GKE, consulta Multitenancy dei cluster.
Per scoprire come configurare l'architettura multi-tenancy per Knative serving, consulta Multitenancy tra progetti.