Questa pagina descrive come configurare una connessione da un'applicazione in esecuzione in Google Kubernetes Engine (GKE) a un'istanza Cloud SQL.
Per istruzioni dettagliate sull'esecuzione di un'applicazione web di esempio Google Kubernetes Engine connessa a Cloud SQL, consulta la guida rapida per la connessione da Google Kubernetes Engine.
Cloud SQL è un servizio di database completamente gestito che semplifica la configurazione, la manutenzione, la gestione e l'amministrazione dei database relazionali nel cloud.
Google Kubernetes Engine è un modo semplice per automatizzare il deployment, la scalabilità e la gestione di Kubernetes.
Informazioni sulla connessione di Google Kubernetes Engine a Cloud SQL
Per accedere a un'istanza Cloud SQL da un'applicazione in esecuzione in Google Kubernetes Engine, puoi utilizzare il proxy di autenticazione Cloud SQL (con IP pubblico o privato) o connetterti direttamente utilizzando un indirizzo IP privato.
Il proxy di autenticazione Cloud SQL è il metodo consigliato per connettersi a Cloud SQL, anche quando utilizzi un IP privato. Questo perché il proxy di autenticazione Cloud SQL fornisce crittografia e autenticazione efficaci tramite IAM, che possono contribuire a proteggere il database.
Le connessioni al database consumano risorse sul server e sull'applicazione di connessione. Adotta sempre buone prassi di gestione delle connessioni per ridurre al minimo l'ingombro dell'applicazione e ridurre la probabilità di superare i limiti di connessione di Cloud SQL. Per ulteriori informazioni, consulta Gestione delle connessioni ai database.
Prima di iniziare
Per connetterti a Cloud SQL, devi avere:
Un cluster GKE, con lo strumento a riga di comando
kubectl
installato e configurato per comunicare con il cluster.Per assistenza su come iniziare a utilizzare GKE, consulta Eseguire il deployment di un'app in un cluster GKE.
Per la connessione tramite IP privato, il cluster GKE deve essere nativo di VPC ed essere connesso in peering con la stessa rete Virtual Private Cloud (VPC) dell'istanza Cloud SQL.
Un'istanza creata.
Per informazioni sulla creazione di un'istanza Cloud SQL, consulta Creazione di istanze.
Un account utente PostgreSQL configurato nell'istanza.
L'applicazione utilizzerà questo account per connettersi al database. Per informazioni sulla creazione di un account utente, consulta Creazione di un utente.
Informazioni sui secret di Kubernetes
In Kubernetes, i Secret sono un modo sicuro per passare i dettagli di configurazione alla tua applicazione. Puoi creare un secret con dettagli come il nome del database, l'utente e la password che possono essere inseriti nella tua applicazione come variabili env.
Esistono molti modi diversi per utilizzare i secret, a seconda del tipo di connessione:
- Un secret delle credenziali del database include il nome dell'utente del database che ti stai connettendo e la password del database dell'utente.
- Se ti connetti con il proxy di autenticazione Cloud SQL, è possibile utilizzare un secret per contenere il file delle credenziali dell'account di servizio.
- Se ti connetti con un IP privato, è possibile utilizzare un secret per specificare l'indirizzo IP privato dell'istanza Cloud SQL.
Per esempi completi su come utilizzare i secret, consulta i repository GitHub a cui viene fatto riferimento più avanti in questa pagina.
crea un oggetto Secret
Puoi creare gli oggetti Secret utilizzando il comando
kubectl create secret
.Per creare un secret con credenziali del database:
kubectl create secret generic <YOUR-DB-SECRET> \ --from-literal=username=<YOUR-DATABASE-USER> \ --from-literal=password=<YOUR-DATABASE-PASSWORD> \ --from-literal=database=<YOUR-DATABASE-NAME>
Una volta creati, puoi visualizzare gli oggetti nella sezione Configurazione della pagina di Google Kubernetes Engine nella console Google Cloud.
Connettersi a Cloud SQL utilizzando il proxy di autenticazione Cloud SQL
Quando ti connetti utilizzando il proxy di autenticazione Cloud SQL, il proxy di autenticazione Cloud SQL viene aggiunto al pod utilizzando il pattern di container sidecar
. Il container del proxy di autenticazione Cloud SQL si trova nello stesso pod della tua applicazione, il che consente all'applicazione di connettersi al proxy di autenticazione Cloud SQL utilizzando localhost
, migliorando la sicurezza e le prestazioni.
Per saperne di più sul proxy di autenticazione Cloud SQL, vedi Informazioni sul proxy di autenticazione Cloud SQL. Per ulteriori informazioni sull'uso dei pod, consulta la panoramica dei pod nella documentazione di Kubernetes.
Per la connessione mediante il proxy di autenticazione Cloud SQL, devi avere quanto segue:
Il nome di connessione dell'istanza Cloud SQL.
Il nome della connessione all'istanza è disponibile nella pagina Dettagli istanza Cloud SQL della console Google Cloud o nel comando
gcloud sql instances describe INSTANCE_ID
.La posizione del file della chiave associato a un account di servizio con i privilegi appropriati per l'istanza Cloud SQL.
Per ulteriori informazioni, vedi Creazione di un account di servizio.
L'API Cloud SQL Admin è abilitata.
Fornisci l'account di servizio al proxy di autenticazione Cloud SQL
Il primo passaggio per eseguire il proxy di autenticazione Cloud SQL in Google Kubernetes Engine è creare un account di servizio Google (GSA) per rappresentare l'applicazione. Ti consigliamo di creare un account di servizio univoco per ogni applicazione, invece di utilizzare ovunque lo stesso account di servizio. Questo modello è più sicuro poiché consente di limitare le autorizzazioni in base alla singola applicazione.
L'account di servizio per la tua applicazione deve soddisfare i seguenti criteri:
- Appartiene a un progetto con l'API Cloud SQL Admin abilitata
- È stato concesso il ruolo IAM del client Cloud SQL (o equivalente) per il progetto che contiene l'istanza a cui vuoi connetterti
- Se ti connetti utilizzando un IP privato, devi utilizzare un cluster GKE nativo di VPC, nello stesso VPC della tua istanza Cloud SQL
Devi configurare GKE in modo da fornire l'account di servizio al proxy di autenticazione Cloud SQL. Per farlo, puoi consigliarti in due modi: con l' identità del carico di lavoro o con un file delle chiavi dell'account di servizio.
Workload Identity
Se utilizzi Google Kubernetes Engine, il metodo preferito consiste nell'utilizzare la funzionalità Workload Identity di GKE. Questo metodo ti consente di associare un account di servizio Kubernetes (KSA) a un account di servizio Google (GSA). Sarà quindi accessibile alle applicazioni l'unità di controllo Google Workspace che utilizza l'Arabia Saudita corrispondente.
Un account di servizio Google (GSA) è un'identità IAM che rappresenta la tua applicazione in Google Cloud. In modo simile, un account di servizio Kubernetes (KSA) è un'identità che rappresenta la tua applicazione in un cluster Google Kubernetes Engine.
Workload Identity associa un arsenale di istruzione primaria e secondaria a una risorsa, di conseguenza tutti i deployment con l'Arabia Saudita si autenticano come RSA nelle interazioni con Google Cloud.
- Abilitare Workload Identity per il cluster
In genere, ogni applicazione ha la propria identità, rappresentata da una coppia di Arabia Saudita e GSA. Crea un Arabia Saudita per la tua applicazione eseguendo
kubectl apply -f service-account.yaml
:Abilita l'associazione IAM tra YOUR-GSA-NAME e YOUR-KSA-NAME:
gcloud iam service-accounts add-iam-policy-binding \ --role="roles/iam.workloadIdentityUser" \ --member="serviceAccount:YOUR-GOOGLE-CLOUD-PROJECT.svc.id.goog[YOUR-K8S-NAMESPACE/YOUR-KSA-NAME]" \ YOUR-GSA-NAME@YOUR-GOOGLE-CLOUD-PROJECT.iam.gserviceaccount.com
Aggiungi un'annotazione a YOUR-KSA-NAME per completare l'associazione:
kubectl annotate serviceaccount \ YOUR-KSA-NAME \ iam.gke.io/gcp-service-account=YOUR-GSA-NAME@YOUR-GOOGLE-CLOUD-PROJECT.iam.gserviceaccount.com
Infine, assicurati di specificare l'account di servizio per l'oggetto k8s.
File di chiavi dell'account di servizio
In alternativa, se non puoi utilizzare Workload Identity, il pattern consigliato è montare un file delle chiavi dell'account di servizio nel pod del proxy di autenticazione Cloud SQL e utilizzare il flag --credentials-file
.
Crea un file delle credenziali per la chiave dell'account di servizio:
gcloud iam service-accounts keys create ~/key.json \ --iam-account=YOUR-SA-NAME@project-id.iam.gserviceaccount.com
Trasforma la chiave dell'account di servizio in un segreto k8s:
kubectl create secret generic YOUR-SA-SECRET \ --from-file=service_account.json=~/key.json
Monta il secret come volume sotto
spec:
per il tuo oggetto k8s:Segui le istruzioni nella sezione successiva per accedere al volume dal pod del proxy di autenticazione Cloud SQL.
esegui il proxy di autenticazione Cloud SQL in un pattern collaterale
Ti consigliamo di eseguire il proxy di autenticazione Cloud SQL in un pattern sidecar
(come container aggiuntivo che condivide un pod con la tua applicazione). Ti consigliamo di eseguire questa operazione come servizio separato per diversi motivi:
- Impedisce che il traffico SQL venga esposto localmente. Il proxy di autenticazione Cloud SQL fornisce la crittografia sulle connessioni in uscita, ma è necessario limitare l'esposizione per le connessioni in entrata.
- Impedisce la presenza di un single point of failure, che rende il database più resiliente in quanto l'accesso di ogni applicazione al database è indipendente dalle altre.
- Limita l'accesso al proxy di autenticazione Cloud SQL, consentendo di utilizzare le autorizzazioni IAM per applicazione anziché esporre il database all'intero cluster.
Consente di definire l'ambito delle richieste di risorse in modo più preciso. Poiché il proxy di autenticazione Cloud SQL consuma le risorse in modo lineare fino all'utilizzo, questo pattern consente di definire l'ambito e richiedere risorse in modo più accurato in modo che corrispondano alle applicazioni in base alla scalabilità.
Aggiungi il proxy di autenticazione Cloud SQL alla configurazione del pod in
containers
:Se utilizzi una chiave dell'account di servizio, specifica il volume del secret e aggiungi il flag
--credentials-file
al comando:
- Se utilizzi l'autenticazione del database IAM, avvia il proxy di autenticazione Cloud SQL con il flag
--auto-iam-authn
.
- Infine, configura l'applicazione in modo che si connetta utilizzando
127.0.0.1
su qualsiasi DB_PORT specificato nella sezione del comando.
Completa i file di configurazione di esempio:
Workload Identity
Chiave account di servizio
Connettersi a Cloud SQL senza il proxy di autenticazione Cloud SQL
Anche se non è così sicuro, è possibile connettersi da un cluster GKE nativo di VPC a un'istanza Cloud SQL sullo stesso VPC utilizzando l'IP privato senza il proxy di autenticazione Cloud SQL.
Crea un secret con l'indirizzo IP privato dell'istanza:
kubectl create secret generic <YOUR-PRIVATE-IP-SECRET> \ --from-literal=db_host=<YOUR-PRIVATE-IP-ADDRESS>
A questo punto, assicurati di aggiungere il secret al container dell'applicazione:
Infine, configura l'applicazione in modo che si connetta utilizzando l'indirizzo IP della variazione env
DB_HOST
. Dovrai utilizzare la porta corretta per PostgreSQL: 5432
File di configurazione di esempio completo:
IP privato
Risoluzione dei problemi
Serve aiuto? Per assistenza nella risoluzione dei problemi relativi al proxy, consulta la pagina relativa alla risoluzione dei problemi relativi alle connessioni al proxy di autenticazione di Cloud SQL o la pagina dell'assistenza di Cloud SQL.
Passaggi successivi
Scopri di più sull'IP privato.
Scopri di più sul proxy di autenticazione Cloud SQL e sull'immagine Docker proxy.
Consulta l'articolo per la risoluzione dei problemi relativi alle connessioni al proxy di autenticazione di Cloud SQL.
Scopri di più su Google Kubernetes Engine.
Scopri le opzioni di assistenza.