Questa pagina mostra come risolvere i problemi che si verificano quando Config Sync non riesce a stabilire una connessione con la tua fonte attendibile.
Problemi di autenticazione
Se l'autenticazione non va a buon fine, Config Sync non può connettersi all'origine attendibile. Le sezioni seguenti mostrano come risolvere alcuni problemi di autenticazione.
Verifica del certificato del server non riuscita per i server Git
Le connessioni ai server Git privati utilizzano TLS per verificare l'autenticità del server. Per eseguire questa convalida, devi fornire un certificato che identifichi l'autorità di certificazione radice e qualsiasi autorità di certificazione intermedia che certifichi l'identità del server Git. Se la verifica del certificato del server Git non è riuscita, significa che non è possibile stabilire la catena di attendibilità.
Se ricevi un errore che indica che la verifica del certificato del server non è riuscita, uno dei seguenti problemi potrebbe essere la causa:
- Il certificato dell'autorità di certificazione (CACert) non è specificato. Per risolvere
questo problema, aggiungi CACert come secret e fai riferimento al secret nel
campo
spec.git.caCertSecretRef
degli oggettiRootSync
oRepoSync
. - Il certificato CA è incompleto. Per risolvere il problema, correggi il secret CACert in modo che contenga la catena di attendibilità completa, inclusi i certificati radice e intermedi.
- Il certificato CA non è valido. Per risolvere il problema, scarica la catena di certificati dal link specificato dal certificato presentato dal server e poi aggiorna il segreto CACert.
Impossibile montare il secret Git
Se ricevi il seguente errore quando il container git-sync
tenta di sincronizzare
un repository con un secret, significa che il secret Git non è stato montato correttamente nel
container git-sync
:
KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory
L'errore potrebbe essere causato dal passaggio del tipo di autenticazione del repository Git da none
, gcenode
o gcpserviceaccount
ad altri tipi che richiedono un secret.
Per risolvere il problema, esegui i seguenti comandi per riavviare Reconciler Manager e i riconciliatori:
# Stop the reconciler-manager Pod. The reconciler-manager Deployment spins
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system
# Delete the reconciler Deployments. The reconciler-manager recreates the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system
Problemi di configurazione
Spesso, i problemi con la configurazione possono impedire a Config Sync di connettersi all'origine attendibile. Le sezioni seguenti spiegano come identificare e risolvere i problemi di configurazione più comuni.
Nome grafico non valido
Quando esegui la sincronizzazione da un repository Helm, assicurati di impostare il valore corretto per
spec.helm.chart
. Il nome del grafico non contiene il nome del repository, la versione del grafico o .tgz
. Puoi verificare il nome del grafico con il comando helm
template
.
Directory di configurazione non valida
Controlla le configurazioni per individuare errori come un valore errato per policyDir
nell'oggetto ConfigManagement
o spec.git.dir
o spec.oci.dir
nell'oggetto RootSync
o RepoSync
. Il valore della directory è incluso in tutti i
messaggi di errore KNV2004
che ricevi; verifica il valore rispetto al repository Git
o all'immagine OCI.
Branch Git non valido
Controlla i log del container git-sync
per un errore come Remote branch
BRANCH_NAME not found in upstream origin
o warning: Could
not find remote branch BRANCH_NAME to clone.
Se non specificata, la filiale predefinita è impostata su master
.
Credenziali Git, Helm o OCI non valide
Controlla i log di Config Sync per il container git-sync
, helm-sync
o oci-sync
per uno dei seguenti errori:
Could not read from remote repository. Ensure you have the correct access rights and the repository exists.
Invalid username or password. Authentication failed for ...
401 Unauthorized
Per un repository Git, verifica che le credenziali Git e il secret git-creds
siano
configurati correttamente.
Per un repository Helm, verifica che le credenziali Helm siano configurate correttamente.
Per le immagini OCI, verifica che le credenziali OCI siano configurate correttamente.
URL repository Git non valido
Controlla i log del container git-sync
per verificare la presenza di errori come Repository not
found
.
Verifica di utilizzare il formato di URL corretto. Ad esempio, se utilizzi una coppia di chiavi SSH per autenticarti al repository Git, assicurati che l'URL che inserisci per il repository Git quando configuri Config Sync utilizzi il protocollo SSH.
URL del repository Helm non valido
Controlla i log del container helm-sync
per verificare la presenza di errori come ...not a
valid chart repository
. Puoi verificare l'URL del repository Helm con il comando helm
template
.
URL del registro OCI non valido
Un valore non valido nel campo spec.oci.image
o spec.oci.dir
di un oggetto RootSync
o RepoSync
può causare problemi di connessione. Verifica che questi
valori siano corretti. Ad esempio, se esegui la sincronizzazione da un registro OCI, l'URL deve iniziare con oci://
.
Per ulteriori informazioni, puoi anche controllare i log del container oci-sync
.
Problemi di rete
Se sospetti che il problema sia correlato alla rete del cluster, inizia con questi passaggi per la risoluzione dei problemi.
Impossibile risolvere l'host: github.com
Quando Config Sync tenta di connettersi al repository Git, utilizza il DNS per risolvere l'IP del nome host specificato. Se l'host non può essere risolto, in genere indica un problema con il DNS o con il networking del cluster.
Per diagnosticare il problema, consulta Risoluzione dei problemi di Cloud DNS in GKE o Risoluzione dei problemi di kube-dns in GKE, a seconda del servizio che utilizzi come provider DNS.
Il repository Git non è raggiungibile dall'interno del cluster
A volte, il container git-sync
genera un errore nei log che indica
che non riesce a raggiungere il repository. Ad esempio, ssh: connect to host
source.developers.google.com port 2022: Network is unreachable
. Per risolvere il problema, modifica la configurazione del firewall o della rete del cluster.
Numero elevato di richieste API di origine
Config Sync utilizza una strategia multi-istanza per scalare e isolare i tenant
e i domini di errore. Per questo motivo, ogni oggetto RootSync
e RepoSync
ha la propria
istanza di riconciliazione. Ogni istanza di riconciliazione ha il proprio sidecar specifico per l'origine, git-sync
, oci-sync
o helm-sync
. Questi sidecar eseguono il polling della fonte
di riferimento. Quando aggiungi altri oggetti RootSync
o RepoSync
, il numero di richieste API effettuate dai riconciliatori che eseguono il polling dell'origine attendibile aumenta in modo lineare. Pertanto, se hai molti oggetti RootSync
e RepoSync
che eseguono il polling della stessa fonte di dati, a volte ciò può causare un carico di traffico significativo sul server di origine.
Valuta una delle seguenti strategie per mitigare il problema:
- Combina più oggetti
RootSyncs
oRepoSync
per ridurre il numero di riconciliatori che effettuano richieste API di origine. - Modifica il tipo di origine da Git a OCI. I repository OCI, come Artifact Registry, tendono a scalare meglio della maggior parte dei server Git, perché possono scalare orizzontalmente senza dover sincronizzare le repliche del server.
Passaggi successivi
Se i problemi persistono, verifica se il tuo problema è un problema noto.
Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedi assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:
- Apertura di una richiesta di assistenza contattando Cloud Customer Care.
- Ricevere assistenza dalla community
ponendo domande su
Stack Overflow.
Se utilizzi kpt o Kustomize, usa il tag
kpt
okustomize
per cercare problemi simili. - Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico su GitHub.