Pianificare la configurazione del cluster Google Kubernetes Engine (GKE) prima di installare Config Sync aiuta a garantire una sincronizzazione affidabile di policy e configurazioni nei tuoi ambienti. I cluster devono soddisfare requisiti specifici per la modalità operativa del cluster, la registrazione del parco risorse, le autorizzazioni di Identity and Access Management (IAM), le versioni della piattaforma, l'autenticazione, il networking e l'architettura dei nodi.
Per le best practice generali per la pianificazione dei cluster GKE, consulta Informazioni sulle scelte di configurazione dei cluster.
Scegli una modalità operativa GKE
Config Sync supporta i cluster GKE Autopilot e Standard.
Per fare una scelta consapevole sulla modalità operativa da utilizzare, leggi Modalità operative di GKE.
Registra i cluster in un parco risorse
Config Sync richiede che i cluster siano registrati in un parco risorse.
Se prevedi di installare e configurare Config Sync con la console Google Cloud , puoi registrare il cluster contemporaneamente all'installazione di Config Sync.
In caso contrario, devi registrare il cluster in un parco risorse prima di abilitare Config Sync.
Concedi le autorizzazioni richieste
Poiché Config Sync richiede che i cluster siano registrati in un parco risorse, potresti aver bisogno di autorizzazioni aggiuntive durante l'installazione di Config Sync.
Per ottenere le autorizzazioni necessarie per registrare i cluster in un parco risorse, chiedi all'amministratore di concederti il ruolo IAM Fleet Admin (in precedenza GKE Hub Admin) (roles/gkehub.admin) nel progetto.
Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.
Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.
Requisiti delle risorse con la modalità Autopilot
La modalità GKE Autopilot modifica automaticamente le richieste di risorse per mantenere la stabilità dei workload. Per capire come pianificare queste richieste, consulta la documentazione di GKE sulle richieste di risorse Autopilot.
A causa del modo in cui Autopilot modifica le richieste di risorse, Config Sync apporta le seguenti modifiche:
- Regola i limiti di override delle risorse specificati dall'utente in modo che corrispondano alle richieste.
- Applica gli override solo quando sono presenti una o più richieste di risorse superiori all'output modificato corrispondente dichiarato nell'annotazione o quando sono presenti richieste di risorse inferiori all'input corrispondente dichiarato nell'annotazione.
Piattaforme e versioni GKE supportate
Per utilizzare Config Sync, il cluster deve essere su una versione supportata di GKE.
Workload Identity Federation for GKE
Workload Identity Federation for GKE è il metodo consigliato per connettersi in modo sicuro ai servizi Google Cloud. La federazione delle identità per i workload per GKE è abilitata per impostazione predefinita sui cluster Autopilot.
Se vuoi utilizzare i pacchetti del parco risorse con Config Sync, è necessario Workload Identity Federation for GKE.
Se hai installato Config Sync su cluster collegati a GKE, non puoi utilizzare Active Directory con la federazione delle identità per i workload. Questa limitazione esiste perché Config Sync utilizza il gateway di connessione per connettersi ai cluster collegati a GKE e il gateway di connessione non supporta questa funzionalità.
Networking
La sezione seguente elenca alcune delle modifiche che potresti dover apportare al tuo cluster GKE, a seconda delle impostazioni della rete.
Per saperne di più sulle opzioni di networking di GKE, consulta Panoramica della rete.
Cluster privati
Se utilizzi cluster GKE con nodi privati, devi configurare i cluster in uno dei seguenti modi per assicurarti che Config Sync abbia accesso e possa autenticarsi alla tua fonte di verità:
Configura Cloud NAT per consentire il traffico in uscita dai nodi GKE privati. Per maggiori dettagli, vedi Esempio di configurazione di GKE.
Abilita l'accesso privato Google per connetterti all'insieme di indirizzi IP esterni utilizzati dalle API di Google e dai servizi.
Cluster pubblici
Se utilizzi cluster pubblici, ma hai requisiti rigorosi per il firewall VPC che bloccano qualsiasi traffico non necessario, devi creare regole firewall per consentire il seguente traffico:
- TCP: consenti il traffico in entrata e in uscita sulle porte 53 e 443
- UDP: consenti il traffico in uscita sulla porta 53
Se non includi queste regole, Config Sync non esegue la sincronizzazione correttamente e nomos status segnala il seguente errore:
Error: KNV2004: unable to sync repo Error in the git-sync container
Cloud Source Repositories con autenticazione del account di servizio predefinito di Compute Engine
Se utilizzi Config Sync per connetterti a Cloud Source Repositories e Workload Identity Federation for GKE non è abilitato, puoi utilizzare il account di servizio predefinito di Compute Engine per l'autenticazione. Devi utilizzare gli ambiti di accesso con ambiti di sola lettura per i nodi del cluster.
Puoi aggiungere l'ambito di sola lettura per Cloud Source Repositories includendo cloud-source-repos-ro nell'elenco --scopes specificato al momento della creazione del cluster o utilizzando l'ambito cloud-platform al momento della creazione del cluster. Ad esempio:
gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
Sostituisci CLUSTER_NAME con il nome del tuo cluster.
Non puoi modificare gli ambiti di accesso dopo aver creato un pool di nodi.
Tuttavia, puoi creare un nuovo pool di nodi con l'ambito di accesso appropriato utilizzando lo stesso cluster. L'ambito gke-default predefinito non include
cloud-source-repos-ro.
Nodi Arm
Config Sync può essere eseguito solo su nodi basati su x86, non su nodi Arm. Tuttavia, se devi eseguire Config Sync su un cluster con più architetture, esegui la seguente azione, a seconda del tipo di cluster:
- GKE su AWS o GKE su Azure: aggiungi un taint ai tuoi nodi Arm per evitare di pianificare i pod sui nodi Arm senza una tolleranza corrispondente.
- GKE: GKE aggiunge un taint predefinito per garantire che i workload senza la tolleranza corrispondente non vengano pianificati lì. Non sono necessarie ulteriori azioni.