Aggiornamenti |
1,28+ |
Il controllo preflight non va a buon fine quando viene disattivato l'ingresso in bundle
Quando disattivi il traffico in entrata in bundle rimuovendo il tag
Campo loadBalancer.vips.ingressVIP nel cluster
di configurazione del deployment, un bug nel controllo preflight MetalLB causa la
l'aggiornamento non andrà a buon fine con il messaggio "vip in entrata utente non valido: IP non valido" errore
per creare un nuovo messaggio email.
Soluzione:
Ignora il messaggio di errore. Salta il controllo preliminare utilizzando uno dei seguenti metodi:
- Aggiungi il flag
--skip-validation-load-balancer al
comando gkectl update cluster .
- Aggiungi un'annotazione all'oggetto
onpremusercluster con onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer .
|
VMware, upgrade |
1,16 |
L'upgrade del cluster non riesce a causa della mancanza della regola del gruppo anti-affinità in vCenter
Durante un upgrade del cluster, gli oggetti macchina potrebbero bloccarsi nella fase "Creazione" e non riuscire a collegarsi agli oggetti nodo a causa di una regola del gruppo anti-affinità (AAG) mancante in vCenter.
Se descrivi gli oggetti macchina problematici, puoi vedere messaggi ricorrenti come "Riconfigura l'attività della regola DRS "task-xxxx" completa"
kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME
Soluzione:
Disabilita l'impostazione del gruppo di anti-affinità sia per la configurazione del cluster di amministrazione sia per la configurazione del cluster utente e attiva il comando di aggiornamento forzato per sbloccare l'upgrade del cluster:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
|
Migrazione |
1,29, 1,30 |
La migrazione di un cluster utente a Controlplane V2 non riesce se la crittografia dei secret è stata abilitata
Durante la migrazione di un cluster utente al piano di controllo V2, se
la crittografia dei secret sempre attiva, la migrazione
non riesce a gestire correttamente la chiave di crittografia del secret. A causa di questo
problema, il nuovo cluster Controlplane V2 non è in grado di decriptare i secret. Se
dell'output del comando seguente non è vuoto, quindi i secret sempre attivi
la crittografia è stata abilitata a un certo punto e il cluster è interessato
questo problema:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get onpremusercluster USER_CLUSTER_NAME \
-n USER_CLUSTER_NAME-gke-onprem-mgmt \
-o jsonpath={.spec.secretsEncryption}
Se hai già avviato la migrazione non va a buon fine,
contatta Google per ricevere assistenza. In caso contrario, prima della migrazione,
disattiva la crittografia dei secret sempre attiva e decripta i secret.
|
Migrazione |
1.29.0-1.29.600, 1.30.0-1.30.100 |
La migrazione di un cluster di amministrazione da non ad alta disponibilità ad alta disponibilità non riesce se è abilitata la crittografia dei secret
Se il cluster di amministrazione ha abilitato la crittografia dei secret sempre attivi a 1.14 o versioni precedenti e ha eseguito l'upgrade dalle versioni precedenti alle versioni 1.29 e 1.30 interessate, durante la migrazione del cluster di amministrazione da non ad alta disponibilità ad alta disponibilità, il processo di migrazione non riesce a gestire correttamente la chiave di crittografia del secret. A causa di questo problema, il nuovo cluster di amministrazione ad alta disponibilità non è in grado di decriptare i secret.
Per verificare se il cluster potrebbe utilizzare la vecchia chiave formattata:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'
Se l'output mostra la chiave vuota come segue, significa che il cluster sarà interessato da questo problema:
"GeneratedKeys":[{"KeyVersion":"1","Key":""}]
Se hai già avviato la migrazione non va a buon fine, contatta Google per ricevere assistenza.
In caso contrario, prima di avviare la migrazione,
rotate
la chiave di crittografia.
|
Upgrade |
1.16, 1.28, 1.29, 1.30 |
credential.yaml rigenerato in modo errato durante l'amministrazione
upgrade della workstation
Quando esegui l'upgrade della workstation di amministrazione utilizzando il comando gkeadm upgrade
admin-workstation , il file credential.yaml
viene rigenerato in modo errato. I campi nome utente e password sono vuoti.
Inoltre, la chiave privateRegistry contiene un errore ortografico.
Lo stesso errore di ortografia della chiave privateRegistry è presente
il file admin-cluster.yaml . Dal
credential.yaml file viene rigenerato durante il cluster di amministrazione
di upgrade, l'errore ortografico è presente anche se lo hai corretto in precedenza.
Soluzione:
- Aggiorna il nome della chiave privata del Registro di sistema in
credential.yaml in
corrisponde a privateRegistry.credentials.fileRef.entry nel
admin-cluster.yaml .
- Aggiorna il nome utente e la password del registry privato nel
credential.yaml .
|
Upgrade |
1.16, 1.28 |
L'upgrade del cluster utente non riesce a causa del timeout della riconciliazione pre-upgrade
Quando esegui l'upgrade di un cluster utente, l'operazione di riconciliazione pre-upgrade potrebbe
richiedono più tempo del timeout definito, causando un errore dell'upgrade.
Il messaggio di errore è simile al seguente:
Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.
Il timeout per l'operazione di riconciliazione precedente all'upgrade è di 5 minuti più 1 minuto per pool di nodi nel cluster utente.
Soluzione:
Assicurati che
gkectl diagnose cluster
senza errori. Salta l'operazione di riconciliazione prima dell'upgrade aggiungendo il flag --skip-reconcile-before-preflight al comando gkectl upgrade cluster . Ad esempio:
gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
|
Aggiornamenti |
1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0 |
L'aggiornamento di DataplaneV2 ForwardMode non attiva automaticamente il riavvio del DaemonSet anetd
Quando aggiorni il campo dataplaneV2.forwardMode del cluster utente utilizzando gkectl update cluster , la modifica viene aggiornata solo nel ConfigMap. Il DaemonSet anetd non rileva la modifica della configurazione finché non viene riavviato e le modifiche non vengono applicate.
Soluzione:
Al termine del comando gkectl update cluster , viene visualizzato
l'output di Done updating the user cluster . Dopo aver visualizzato questo messaggio, esegui il seguente comando per riavviare il DaemonSet anetd in modo da rilevare la modifica della configurazione:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd
Controlla l'idoneità del DaemonSet dopo il riavvio:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd
Nell'output del comando precedente, verifica che il numero nella colonna DESIRED corrisponda al numero nella colonna READY .
|
Upgrade |
1,16 |
Comando etcdctl non trovato durante l'upgrade del cluster nella fase di backup del cluster di amministrazione
Durante l'upgrade di un cluster utente da 1,16 a 1,28, viene supportato il cluster di amministrazione
verso l'alto. Il processo di backup del cluster di amministrazione mostra il messaggio di errore
"etcdctl: comando non trovato". L'upgrade del cluster utente ha esito positivo e
il cluster di amministrazione rimane in stato integro. L'unico problema è che il
file dei metadati nel cluster di amministrazione non è sottoposto a backup.
Il problema è dovuto al fatto che il file binario etcdctl
è stato aggiunto in 1.28 e non è disponibile sui nodi 1.16.
Il backup del cluster di amministrazione prevede diversi passaggi, tra cui l'acquisizione di un'istantanea di etcd e la scrittura del file dei metadati per il cluster di amministrazione.
Il backup di etcd riesce comunque perché etcdctl può essere attivato anche dopo un comando exec nel pod etcd. Tuttavia, la scrittura del file dei metadati
non va a buon fine perché si basa ancora sul file binario etcdctl da installare sul nodo. Tuttavia, il backup del file di metadati non costituisce un blocco
per eseguire un backup, quindi il processo di backup continua a funzionare, così come
dell'upgrade del cluster utente.
Soluzione:
Se vuoi eseguire il backup del file dei metadati, segui la procedura Eseguire il backup e il ripristino di un cluster di amministrazione con gkectl per attivare un backup distinto del cluster di amministrazione utilizzando la versione di gkectl corrispondente a quella del cluster di amministrazione.
|
Installazione |
1,16-1,29 |
Errore di creazione del cluster utente con bilanciamento del carico manuale
Quando viene creato un cluster di utenti configurato per il bilanciamento del carico manuale, si verifica un errore gkectl check-config che indica che il valore ingressHTTPNodePort deve essere almeno 30000, anche quando l'ingresso in bundle è disattivato.
Questo problema si verifica indipendentemente dal fatto che i campi ingressHTTPNodePort
e ingressHTTPSNodePort siano impostati o lasciati vuoti.
Soluzione:
Per aggirare il problema, ignora il risultato restituito dal
gkectl check-config . Per disattivare il traffico in entrata in bundle, consulta
Disattiva il traffico in entrata in bundle.
|
Aggiornamenti |
1.29.0 |
Il problema con PodDisruptionBudget (PDB) si verifica quando
utilizzando cluster di amministrazione ad alta disponibilità (HA) e sono presenti 0 o 1 amministratore
un nodo cluster senza un ruolo dopo la migrazione. Per verificare se sono presenti oggetti Node senza un ruolo, esegui il seguente comando:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide
Se sono presenti due o più oggetti node senza un ruolo dopo il
migrazione, significa che il PDB non è configurato in modo errato.
Sintomi:
L'output di
admin cluster diagnose include le seguenti informazioni
Checking all poddisruptionbudgets...FAILURE
Reason: 1 pod disruption budget error(s).
Unhealthy Resources:
PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).
Soluzione:
Esegui questo comando per eliminare il PDB:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
|
Installazione, upgrade e aggiornamenti |
1.28.0-1.28.600,1.29.0-1.29.100 |
Il webook di Autorizzazione binaria blocca l'avvio del plug-in CNI, causando il mancato avvio di uno dei pool di nodi
In rare condizioni di gara, una sequenza di installazione errata del webhook di autorizzazione binaria e del pod gke-connect potrebbe causare l'interruzione della creazione del cluster utente a causa del mancato raggiungimento dello stato di disponibilità da parte di un nodo. Negli scenari interessati, la creazione del cluster di utenti potrebbe bloccarsi a causa del mancato raggiungimento dello stato di disponibilità da parte di un nodo. In questo caso, viene visualizzato il seguente messaggio:
Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready
Soluzione:
- Rimuovi la configurazione di Autorizzazione binaria dal file di configurazione. Per le istruzioni di configurazione, consulta la guida all'installazione del secondo giorno di Autorizzazione binaria per GKE su VMware.
- Per sbloccare un nodo non funzionante durante la procedura di creazione del cluster corrente, rimuovi temporaneamente la configurazione dell'webhook di Autorizzazione binaria nel cluster utente utilizzando il seguente comando.
kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
Una volta completato il processo di bootstrap, puoi aggiungere nuovamente la seguente configurazione di webhook.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
namespaceSelector:
matchExpressions:
- key: control-plane
operator: DoesNotExist
objectSelector:
matchExpressions:
- key: "image-policy.k8s.io/break-glass"
operator: NotIn
values: ["true"]
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- pods
- pods/ephemeralcontainers
admissionReviewVersions:
- "v1beta1"
clientConfig:
service:
name: binauthz
namespace: binauthz-system
path: /binauthz
# CA Bundle will be updated by the cert rotator.
caBundle: Cg==
timeoutSeconds: 10
# Fail Open
failurePolicy: "Ignore"
sideEffects: None
|
Upgrade |
1.16, 1.28, 1.29 |
L'upgrade del cluster utente CPV2 è bloccato a causa di una macchina con mirroring con deletionTimestamp
Durante l'upgrade di un cluster utente, l'operazione di upgrade potrebbe bloccarsi se l'oggetto macchina sottoposto a mirroring nel cluster utente contiene un deletionTimestamp . Viene visualizzato il seguente messaggio di errore
Se l'upgrade è bloccato:
machine is still in the process of being drained and subsequently removed
Questo problema può verificarsi se in precedenza hai tentato di riparare il nodo del piano di controllo dell'utente eseguendo gkectl delete machine sulla macchina con mirroring nel cluster utente.
Soluzione:
- Recupera l'oggetto macchina sottoposto a mirroring e salvalo in un file locale per il backup.
- Esegui questo comando per eliminare il finalizzatore dal mirroring
e attendere che venga eliminata dal cluster utente.
kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
- Segui la procedura descritta in
Nodo del piano di controllo del cluster utente V2 del piano di controllo per attivare la riparazione del nodo
sui nodi del piano di controllo, in modo che la specifica corretta
di nuovo sincronizzati nel cluster utente.
- Esegui di nuovo
gkectl upgrade cluster per riprendere l'upgrade
|
Configurazione, installazione |
1.15, 1.16, 1.28, 1.29 |
Impossibile creare il cluster a causa del VIP del piano di controllo in una subnet diversa
Per il cluster di amministrazione HA o il cluster utente ControlPlane V2, il VIP del control plane deve trovarsi nella stessa subnet degli altri nodi del cluster. Altrimenti, cluster
la creazione non riesce perché kubelet non può comunicare con il server API utilizzando
il VIP del piano di controllo.
Soluzione:
Prima di creare il cluster, assicurati che sia configurato il VIP del piano di controllo
nella stessa subnet degli altri nodi del cluster.
|
Installazione, upgrade, aggiornamenti |
1.29.0 - 1.29.100 |
Errore di creazione/upgrade del cluster a causa di un nome utente vCenter non FQDN
La creazione o l'upgrade del cluster non riesce e genera un errore nei pod CSI vSphere che indica che il nome utente vCenter non è valido. Questo accade perché il nome utente utilizzato non è un nome di dominio completo. Messaggio di errore nel pod vSphere-csi-controller come segue:
GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username
Questo problema si verifica solo nella versione 1.29 e successive, poiché è stata aggiunta una convalida al driver CSI vSphere per imporre l'utilizzo di nomi utente di dominio completi.
Soluzione:
Utilizza un nome di dominio completo per il nome utente di vCenter nel file di configurazione delle credenziali. Ad esempio, anziché "nomeutente1", utilizza "nomeutente1@example.com".
|
Upgrade, aggiornamenti |
1,28,0 - 1,28.500 |
L'upgrade del cluster di amministrazione non riesce per i cluster creati nelle versioni 1.10 o
precedenti
Quando si aggiorna un cluster di amministrazione dalla versione 1.16 alla versione 1.28, il bootstrap
la nuova macchina master di amministrazione potrebbe non riuscire a generare il piano di controllo
certificato. Il problema è causato da modifiche al modo in cui i certificati vengono
generato per il server API Kubernetes nella versione 1.28 e successive. Il
problema si riproduce per i cluster creati nelle versioni 1.10 e precedenti per i quali è stato eseguito l'upgrade alla versione 1.16 e il certificato finale non è stato girato prima dell'upgrade.
Per determinare se l'errore di upgrade del cluster di amministrazione è causato da questo errore,
segui questi passaggi:
- Connettiti alla macchina principale dell'amministratore non riuscita tramite SSH.
- Apri
/var/log/startup.log e cerca un errore come il
seguenti:
Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>
Soluzione:
- Connettiti alla macchina master di amministrazione tramite SSH. Per maggiori dettagli, consulta
Utilizzare SSH per connettersi a un nodo del cluster amministrativo.
- Crea una copia
/etc/startup/pki-yaml.sh e assegnale il nome /etc/startup/pki-yaml-copy.sh
- Modifica
/etc/startup/pki-yaml-copy.sh . Trova
authorityKeyIdentifier=keyidset e sostituiscilo con
authorityKeyIdentifier=keyid,issuer nelle sezioni per
le seguenti estensioni:
apiserver_ext , client_ext ,
etcd_server_ext e kubelet_server_ext . Ad esempio:
[ apiserver_ext ]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth
basicConstraints = critical,CA:false
authorityKeyIdentifier = keyid,issuer
subjectAltName = @apiserver_alt_names
- Salva le modifiche apportate a
/etc/startup/pki-yaml-copy.sh .
- Utilizzando un editor di testo, apri
/opt/bin/master.sh , trova e sostituisci tutte le occorrenze di /etc/startup/pki-yaml.sh con /etc/startup/pki-yaml-copy.sh , quindi salva le modifiche.
- Esegui
/opt/bin/master.sh per generare il certificato e
per completare l'avvio della macchina.
- Esegui di nuovo
gkectl upgrade admin per eseguire l'upgrade del cluster di amministrazione.
- Al termine dell'upgrade, ruota il certificato foglia per entrambi gli amministratori
e cluster utente, come descritto in Avviare la rotazione.
- Al termine della rotazione dei certificati, apporta le stesse modifiche a
/etc/startup/pki-yaml-copy.sh come hai fatto in precedenza ed esegui
/opt/bin/master.sh .
|
Configurazione |
1.29.0 |
Messaggio di avviso errato per i cluster con Dataplane V2 abilitato
Quando esegui l'operazione, viene visualizzato il seguente messaggio di avviso non corretto
gkectl per creare, aggiornare o eseguire l'upgrade di un cluster che ha già
Dataplane V2 abilitato:
WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.
Esiste un bug in gkectl che mostra sempre questo avviso
purché dataplaneV2.forwardMode non venga usato, anche se
hai già impostato enableDataplaneV2: true nel tuo cluster
di configurazione del deployment.
Soluzione:
Puoi ignorare questo avviso.
|
Configurazione |
1.28.0-1.28.400, 1.29.0 |
Il controllo preliminare dell'installazione del cluster di amministrazione HA segnala un numero errato di IP statici richiesti
Quando crei un cluster di amministrazione ad alta disponibilità, il controllo preflight mostra
seguente messaggio di errore errato:
- Validation Category: Network Configuration
- [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
at least X+1 IP addresses for admin cluster with X nodes
Il requisito non è corretto per i cluster di amministrazione ad alta disponibilità 1.28 e versioni successive
perché non hanno più nodi aggiuntivi. Inoltre, poiché i 3
gli IP dei nodi del piano di controllo del cluster di amministrazione sono specificati in
Sezione network.controlPlaneIPBlock nel cluster di amministrazione
di configurazione, gli IP nel file di blocco IP sono necessari solo
Nodi del piano di controllo del cluster utente kubeception.
Soluzione:
Per saltare il controllo preliminare errato in una release non corretta, aggiungi --skip-validation-net-config al comando gkectl .
|
Operazione |
1.29.0-1.29.100 |
L'agente Connect perde la connessione a Google Cloud dopo la migrazione da un cluster di amministrazione non ad alta disponibilità a uno ad alta disponibilità
Se hai eseguito la migrazione di
da un cluster di amministrazione non ad alta disponibilità a un cluster di amministrazione ad alta disponibilità, l'agente Connect
nel cluster di amministrazione perde la connessione
gkeconnect.googleapis.com con l'errore "Impossibile verificare JWT
firma digitale". Questo perché durante la migrazione la chiave di firma KSA viene modificata, pertanto è necessaria una nuova registrazione per aggiornare le JWK OIDC.
Soluzione:
Per riconnettere il cluster di amministrazione a Google Cloud, segui questi passaggi
per attivare una nuova registrazione:
Innanzitutto, ottieni il nome del deployment gke-connect :
kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect
Elimina il deployment gke-connect :
kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect
Attivare una riconciliazione forzata per onprem-admin-cluster-controller
aggiungendo una "forza-riconciliazione" annotazione alla tua RP onpremadmincluster :
kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
annotations:
onprem.cluster.gke.io/force-reconcile: "true"
'
L'idea è che onprem-admin-cluster-controller riapplicherà sempre il deployment di gke-connect e registrerà di nuovo il cluster se non trova un deployment di gke-connect esistente.
Dopo la soluzione alternativa (potrebbe essere necessario qualche minuto per il completamento della riconciliazione da parte del controller), puoi verificare che l'errore 400 "Impossibile verificare la firma JWT" non sia più presente nei log gke-connect-agent :
kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
|
Installazione, Sistema operativo |
1.28.0-1.28.500, 1.29.0 |
L'IP del bridge Docker utilizza 172.17.0.1/16 per i nodi del control plane del cluster COS
Google Distributed Cloud specifica una subnet dedicata,
--bip=169.254.123.1/24 , per l'IP del bridge Docker nella
configurazione di Docker per impedire la prenotazione della subnet predefinita
--bip=169.254.123.1/24 . Tuttavia, nelle versioni 1.28.0-1.28.500 e
1.29.0, il servizio Docker non è stato riavviato dopo Google Distributed Cloud
ha personalizzato la configurazione Docker a causa di una regressione nel sistema operativo COS
dell'immagine. Di conseguenza, Docker sceglie 172.17.0.1/16 predefinito come
la subnet dell'indirizzo IP del bridge. Ciò potrebbe causare un conflitto di indirizzi IP se hai già un carico di lavoro in esecuzione nell'intervallo di indirizzi IP.
Soluzione:
Per aggirare il problema, devi riavviare il servizio docker:
sudo systemctl restart docker
Verifica che Docker selezioni l'indirizzo IP del bridge corretto:
ip a | grep docker0
Questa soluzione non viene mantenuta nelle ricreazioni delle VM. Devi presentare di nuovo la domanda
questa soluzione alternativa ogni volta che le VM vengono ricreate.
|
update |
1.28.0-1.28.400, 1.29.0-1.29.100 |
L'utilizzo di più interfacce di rete con la CNI standard non funziona
I file binari CNI standard bridge, ipvlan, vlan, macvlan, dhcp, tuning,
host-local, ptp, portmap non sono inclusi nelle immagini del sistema operativo nell'
e versioni successive. Questi file binari CNI non vengono utilizzati da Dataplane V2, ma possono essere utilizzati per interfacce di rete aggiuntive nella funzionalità di più interfacce di rete.
Più interfacce di rete con questi plug-in CNI non funzioneranno.
Soluzione:
Se utilizzi questa funzionalità, esegui l'upgrade alla versione con la correzione.
|
update |
1.15, 1.16, 1.28 |
Le dipendenze trident Netapp interferiscono con il driver CSI vSphere
L'installazione di multipathd sui nodi del cluster interferisce con il driver CSI vSphere, impedendo l'avvio dei carichi di lavoro degli utenti.
Soluzione:
|
Aggiornamenti |
1.15, 1.16 |
L'webhook del cluster di amministrazione potrebbe bloccare gli aggiornamenti quando aggiunti le configurazioni richieste
Se alcune configurazioni obbligatorie sono vuote nel cluster di amministrazione
perché le convalide sono state ignorate, la loro aggiunta potrebbe essere bloccata dall'amministratore
webhook per il cluster. Ad esempio, se il campo gkeConnect non è
configurato in un cluster di amministrazione esistente, aggiungendolo
Il comando gkectl update admin potrebbe generare il seguente errore
messaggio:
admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters
Soluzione:
-
Per i cluster di amministrazione 1.15, esegui il comando
gkectl update admin con il flag --disable-admin-cluster-webhook . Ad esempio:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
-
Per i cluster di amministrazione 1.16, esegui comandi
gkectl update admin con il flag --force . Ad esempio:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
|
Configurazione |
1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200 |
Il valore predefinito del campo controlPlaneNodePort è 30968 quando la specifica manualLB è vuota
Se utilizzerai un bilanciatore del carico manuale
(loadBalancer.kind è impostato su "ManualLB" ),
non dovresti dover configurare la sezione loadBalancer.manualLB
nel file di configurazione per un cluster di amministrazione ad alta disponibilità (HA) nelle versioni 1.16 e successive. Ma quando questa sezione è vuota,
Google Distributed Cloud assegna valori predefiniti a tutte le NodePort, tra cui
manualLB.controlPlaneNodePort , che causa la visualizzazione del cluster
che la creazione abbia esito negativo con il seguente messaggio di errore:
- Validation Category: Manual LB
- [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
not be set when using HA admin cluster, got: 30968
Soluzione:
Specifica manualLB.controlPlaneNodePort: 0 nella configurazione del cluster di amministrazione
per il cluster di amministrazione ad alta disponibilità:
loadBalancer:
...
kind: ManualLB
manualLB:
controlPlaneNodePort: 0
...
|
Archiviazione |
1.28.0-1.28.100 |
nfs-common non è presente nell'immagine del sistema operativo Ubuntu
Nell'immagine del sistema operativo Ubuntu manca nfs-common , il che potrebbe causare
per i clienti che usano driver che dipendono da NFS, come NetApp.
Se il log contiene una voce come la seguente dopo l'upgrade alla versione 1.28, il problema ti riguarda:
Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".
Soluzione:
Assicurati che i nodi possano scaricare pacchetti da Canonical.
Dopodiché, applica il seguente DaemonSet al cluster per installare nfs-common :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: install-nfs-common
labels:
name: install-nfs-common
namespace: kube-system
spec:
selector:
matchLabels:
name: install-nfs-common
minReadySeconds: 0
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 100%
template:
metadata:
labels:
name: install-nfs-common
spec:
hostPID: true
hostIPC: true
hostNetwork: true
initContainers:
- name: install-nfs-common
image: ubuntu
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
command:
- chroot
- /host
- bash
- -c
args:
- |
apt install -y nfs-common
volumeMounts:
- name: host
mountPath: /host
containers:
- name: pause
image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
imagePullPolicy: IfNotPresent
volumes:
- name: host
hostPath:
path: /
|
Archiviazione |
1.28.0-1.28.100 |
Il campo del criterio di archiviazione non è presente nel modello di configurazione del cluster di amministrazione
SPBM nei cluster di amministrazione è supportato nella versione 1.28.0 e successive. Ma il campo
vCenter.storagePolicyName non presente nel modello del file di configurazione.
Soluzione:
Aggiungi il campo "vCenter.storagePolicyName" nel file di configurazione del cluster di amministrazione se
vuoi configurare il criterio di archiviazione per il cluster di amministrazione. Fai riferimento alle istruzioni.
|
Logging e monitoraggio |
1.28.0-1.28.100 |
L'API kubernetesmetadata.googleapis.com aggiunta di recente non supporta VPC-SC.
Di conseguenza, l'agente di raccolta dei metadati non riuscirà a raggiungere questa API in VPC-SC. Di conseguenza, le etichette dei metadati delle metriche non saranno presenti.
Soluzione:
Imposta nello spazio dei nomi `kube-system` il campo CR `stackdriver` `featureGates.disableExperimentalMetadataAgent` su `true` eseguendo il comando
`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`
poi esegui
`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`
|
Upgrade, aggiornamenti |
1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0 |
Il controller clusterapi-controller potrebbe arrestarsi in modo anomalo quando il cluster di amministrazione e qualsiasi cluster utente con ControlPlane V2 abilitato utilizzano credenziali vSphere diverse.
Quando un cluster di amministrazione e qualsiasi cluster utente con ControlPlane V2 abilitato utilizzano credenziali vSphere diverse, ad esempio dopo l'aggiornamento delle credenziali vSphere per il cluster di amministrazione, clusterapi-controller potrebbe non riuscire a connettersi a vCenter dopo il riavvio. Visualizza il log del clusterapi-controller in esecuzione nel cluster di amministrazione
spazio dei nomi "kube-system",
kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
-n kube-system --kubeconfig KUBECONFIG
Se il log contiene una voce simile alla seguente, hai riscontrato questo problema:
E1214 00:02:54.095668 1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found
Soluzione:
Aggiorna le credenziali vSphere in modo che il cluster di amministrazione e tutti i cluster utente con Controlplane V2 abilitato utilizzino le stesse credenziali vSphere.
|
Logging e monitoraggio |
1,14 |
etcd elevato numero di richieste GRPC non riuscite in Prometheus Alert Manager
Prometheus potrebbe segnalare avvisi simili all'esempio seguente:
Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.
Per verificare se questo avviso è un falso positivo che può essere ignorato,
completa i seguenti passaggi:
- Confronta la metrica
grpc_server_handled_total non elaborata con
grpc_method indicato nel messaggio di avviso. In questo
esempio, controlla l'etichetta grpc_code per
Watch .
Puoi verificare questa metrica utilizzando Cloud Monitoring con le seguenti risorse:
Query MQL:
fetch
k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
- Puoi inviare in sicurezza un avviso per tutti i codici diversi da
OK
ignorato se il codice non è uno dei seguenti:
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded
Soluzione:
Per configurare Prometheus in modo che ignori questi avvisi falsi positivi, rivedi
le seguenti opzioni:
- Silenzia l'avviso
dall'interfaccia utente di Alert Manager.
- Se non puoi disattivare l'avviso, segui i passaggi riportati di seguito per eliminare i falsi positivi:
- Riduci l'operatore di monitoraggio a
0 repliche in modo che le modifiche possano essere permanenti.
- Modifica il ConfigMap
prometheus-config e aggiungi
grpc_method!="Watch" alla configurazione dell'avviso etcdHighNumberOfFailedGRPCRequests come mostrato
nell'esempio seguente:
- Originale:
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
- Modificata:
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
Sostituisci CLUSTER_NAME seguente con
il nome del cluster.
- Riavvia lo stato set di Prometheus e Alertmanager per acquisire la nuova configurazione.
- Se il codice rientra in uno dei casi problematici, controlla etcd
e
kube-apiserver per eseguire altri debug.
|
Networking |
1.16.0-1.16.2, 1.28.0 |
Le connessioni a lungo termine con NAT in uscita vengono interrotte
Le connessioni NAT in uscita potrebbero
essere eliminate dopo 5-10 minuti di
connessione in corso se non c'è traffico.
Poiché conntrack è importante solo nella direzione in entrata (connessioni esterne al cluster), questo problema si verifica solo se la connessione non trasmette informazioni per un po' di tempo e poi il lato di destinazione trasmette qualcosa. Se il pod NAT in uscita crea sempre un'istanza
questo messaggio non verrà rilevato.
Questo problema si verifica perché la raccolta dei rifiuti di anetd rimuove inavvertitamente le voci conntrack che il daemon ritiene inutilizzate.
Di recente è stata integrata in anetd una correzione a monte per correggere il comportamento.
Soluzione:
Non esiste una soluzione semplice e non abbiamo riscontrato problemi nella versione 1.16
a causa di questo comportamento. Se noti connessioni di lunga durata interrotte a causa di
per questo problema, una soluzione alternativa consiste nell'utilizzare un carico di lavoro sullo stesso nodo
dagli indirizzi IP in uscita o inviare regolarmente i messaggi
connessione.
|
Operazione |
1,14, 1,15 e 1,16 |
Il firmatario della CSR ignora spec.expirationSeconds durante la firma
dei certificati
Se crei una richiesta di firma del certificato (CSR) con
expirationSeconds impostato, expirationSeconds
viene ignorato.
Soluzione:
Se hai riscontrato questo problema, puoi aggiornare il cluster utente
aggiunta di disableNodeIDVerificationCSRSigning: true nell'utente
di configurazione del cluster ed esegui gkectl update cluster
per aggiornare il cluster con questa configurazione.
|
Networking, upgrade, aggiornamenti |
1.16.0-1.16.3 |
La convalida del bilanciatore del carico del cluster utente non riesce per
disable_bundled_ingress
Se provi a
disabilita il traffico in entrata in bundle per un cluster esistente, il comando gkectl update cluster non riesce e restituisce un errore
simile all'esempio seguente:
[FAILURE] Config: ingress IP is required in user cluster spec
Questo errore si verifica perché gkectl controlla un indirizzo IP di ingresso del bilanciatore del carico durante i controlli preliminari. Anche se questo controllo
non è necessario per disattivare l'ingresso in bundle, il controllo preflight di gkectl
non va a buon fine se disableBundledIngress è impostato su
true .
Soluzione:
Usa il parametro --skip-validation-load-balancer quando
aggiorna il cluster, come mostrato nell'esempio seguente:
gkectl update cluster \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
--skip-validation-load-balancer
Per ulteriori informazioni, scopri come disattivare l'ingresso in bundle per un cluster esistente.
|
Upgrade, aggiornamenti |
1.13, 1.14, 1.15.0-1.15.6 |
Gli aggiornamenti del cluster di amministrazione non riescono dopo la rotazione della CA
Se ruoti i certificati dell'autorità di certificazione (CA) del cluster di amministrazione,
i tentativi successivi di eseguire il comando gkectl update admin non vanno a buon fine.
L'errore restituito è simile al seguente:
failed to get last CARotationStage: configmaps "ca-rotation-stage" not found
Soluzione:
Se il problema ti riguarda, puoi aggiornare il cluster di amministrazione utilizzando il flag --disable-update-from-checkpoint con il comando gkectl update admin :
gkectl update admin --config ADMIN_CONFIG_file \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-update-from-checkpoint
Quando utilizzi il flag --disable-update-from-checkpoint ,
il comando update non usa il file del punto di controllo come fonte attendibile durante
dell'aggiornamento del cluster. Il file del checkpoint è ancora aggiornato per uso futuro.
|
Archiviazione |
1.15.0-1.15.6, 1.16.0-1.16.2 |
Il controllo preflight del carico di lavoro CSI non riesce a causa di un errore di avvio del pod
Durante i controlli preflight, il controllo di convalida del carico di lavoro CSI installa un
pod nello spazio dei nomi default . Il pod di lavoro CSI convalida
che il driver CSI vSphere sia installato e possa eseguire il provisioning dinamico dei volumi. Se questo pod non si avvia, il controllo di convalida del carico di lavoro CSI
non riesce.
Esistono alcuni problemi noti che possono impedire l'avvio di questo pod:
- Se per il pod non sono specificati limiti di risorse, come avviene
per alcuni cluster con webhook di ammissione installati, il pod non viene avviato.
- Se Cloud Service Mesh è installato nel cluster con
l'iniezione automatica di sidecar Istio abilitata nello spazio dei nomi
default
, il pod di lavoro CSI non si avvia.
Se il pod di lavoro CSI non si avvia, viene visualizzato un errore di timeout come il seguente durante le verifiche preliminari:
- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition
Per vedere se l'errore è causato dalla mancanza di risorse pod impostate, esegui
seguente comando per verificare anthos-csi-workload-writer-<run-id>
stato lavoro:
kubectl describe job anthos-csi-workload-writer-<run-id>
Se i limiti delle risorse non sono impostati correttamente per il pod di lavoro CSI,
lo stato del job contiene un messaggio di errore come il seguente:
CPU and memory resource limits is invalid, as it are not defined for container: volume-tester
Se il pod del carico di lavoro CSI non si avvia a causa dell'inserimento del sidecar Istio,
puoi disattivare temporaneamente l'inserimento automatico del sidecar Istio nello
spazio dei nomi default . Controlla le etichette dello spazio dei nomi e utilizza
il seguente comando per eliminare l'etichetta che inizia con istio.io/rev :
kubectl label namespace default istio.io/rev-
Se il pod non è configurato correttamente, verifica manualmente che il provisioning dei volumi dinamici con il driver CSI vSphere funzioni:
- Crea un PVC che utilizzi la classe di archiviazione
standard-rwo .
- Crea un pod che utilizza il PVC.
- Verifica che il pod possa leggere/scrivere dati nel volume.
- Rimuovi il pod e il PVC dopo aver verificato il corretto funzionamento.
Se il provisioning dei volumi dinamici con il driver CSI vSphere funziona, esegui
gkectl diagnose o gkectl upgrade
con il flag --skip-validation-csi-workload per saltare il controllo del carico di lavoro CSI.
|
Operazione |
1.16.0-1.16.2 |
I timeout dell'aggiornamento del cluster utente si verificano quando la versione del cluster di amministrazione è 1.15
Quando hai eseguito l'accesso a un
workstation di amministrazione gestita dall'utente, gkectl update cluster
potrebbe scadere e non aggiornare il cluster utente. Ciò si verifica se
la versione del cluster di amministrazione è 1.15 ed esegui gkectl update admin
prima di eseguire gkectl update cluster .
Quando si verifica questo errore, viene visualizzato il seguente messaggio quando si tenta di aggiornare il cluster:
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Durante l'aggiornamento di un cluster di amministrazione 1.15, il validation-controller
che attiva i controlli preflight viene rimosso dal cluster. Se
per provare ad aggiornare il cluster utente, il controllo preflight si interrompe finché
è stato raggiunto il timeout.
Soluzione:
- Esegui questo comando per rieseguire il deployment di
validation-controller :
gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
-
Al termine della preparazione, esegui di nuovo
gkectl update cluster per aggiornare il cluster utente
|
Operazione |
1.16.0-1.16.2 |
I timeout della creazione del cluster utente si verificano quando la versione del cluster di amministrazione è 1.15
Quando hai eseguito l'accesso a un
workstation di amministrazione gestita dall'utente, gkectl create cluster
potrebbe scadere e non riuscire a creare il cluster utente. Ciò si verifica se
la versione del cluster di amministrazione è 1.15.
Quando si verifica questo errore, viene visualizzato il seguente messaggio quando si tenta di creare il cluster:
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Poiché validation-controller è stato aggiunto nella versione 1.16, quando si utilizza
Manca il cluster di amministrazione 1.15 validation-controller responsabile dell'attivazione dei controlli preflight. Pertanto, quando provi a creare un cluster utente,
i controlli preflight
Blocco fino a quando non viene raggiunto il timeout.
Soluzione:
- Esegui il seguente comando per eseguire il deployment di
validation-controller :
gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
-
Al termine della preparazione, esegui di nuovo
gkectl create cluster per creare il cluster utente
|
Upgrade, aggiornamenti |
1.16.0-1.16.2 |
L'aggiornamento o l'upgrade del cluster amministrativo non riesce se i progetti o le località dei servizi aggiuntivi non corrispondono
Quando esegui l'upgrade di un cluster di amministrazione dalla versione 1.15.x alla 1.16.x,
aggiungi connect , stackdriver ,
Configurazione cloudAuditLogging o gkeOnPremAPI
quando aggiorni un cluster di amministrazione, l'operazione potrebbe essere rifiutata dall'amministratore.
webhook per il cluster. Potrebbe essere visualizzato uno dei seguenti messaggi di errore:
"projects for connect, stackdriver and cloudAuditLogging must be the
same when specified during cluster creation."
"locations for connect, gkeOnPremAPI, stackdriver and
cloudAuditLogging must be in the same region when specified during
cluster creation."
"locations for stackdriver and cloudAuditLogging must be the same
when specified during cluster creation."
L'aggiornamento o l'upgrade del cluster di amministrazione richiede
onprem-admin-cluster-controller per riconciliare l'amministratore
in un cluster di tipo tipo. Quando lo stato del cluster di amministrazione viene ripristinato nel
cluster di tipo, il webhook del cluster di amministrazione non può distinguere se
l'oggetto OnPremAdminCluster è destinato alla creazione di un cluster di amministrazione
o per riprendere le operazioni per un aggiornamento o un upgrade. Alcune funzionalità di sola creazione
le convalide vengono richiamate in caso di aggiornamento e upgrade inaspettato.
Soluzione:
Aggiungi il parametro
onprem.cluster.gke.io/skip-project-location-sameness-validation: true
all'oggetto OnPremAdminCluster :
- Modifica la risorsa del cluster
onpremadminclusters :
kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
Sostituisci quanto segue:
ADMIN_CLUSTER_NAME : il nome di
il cluster di amministrazione.
ADMIN_CLUSTER_KUBECONFIG : il percorso
del file kubeconfig del cluster di amministrazione.
- Aggiungi il parametro
onprem.cluster.gke.io/skip-project-location-sameness-validation: true
e salvare la risorsa personalizzata.
- A seconda del tipo di cluster di amministrazione, completa uno dei seguenti passaggi:
- Per i cluster amministrativi non HA con un file checkpoint: aggiungi il parametro
disable-update-from-checkpoint nel comando di aggiornamento o il parametro "disable-upgrade-from-checkpoint" nel comando di upgrade. Questi
sono necessari solo per la prossima volta che esegui
Comando update o upgrade :
-
gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-update-from-checkpoint
-
gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
- Per i cluster di amministrazione ad alta disponibilità o il file del punto di controllo è disabilitato:
aggiornare o eseguire l'upgrade del cluster di amministrazione come di consueto. Nessun parametro aggiuntivo
sono necessari
nei comandi di aggiornamento o upgrade.
|
Operazione |
1.16.0-1.16.2 |
L'eliminazione del cluster utente non riesce quando si utilizza una workstation di amministrazione gestita dall'utente
Quando hai eseguito l'accesso a una
workstation di amministrazione gestita dall'utente, il comando gkectl delete cluster
potrebbe scadere e non riuscire a eliminare il cluster utente. Ciò si verifica se
hai eseguito per la prima volta gkectl sulla workstation gestita dall'utente
creare, aggiornare o eseguire l'upgrade del cluster utente. Quando si verifica questo errore,
viene visualizzato il seguente errore durante il tentativo di eliminazione del cluster:
failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
to be deleted: timed out waiting for the condition
Durante l'eliminazione, un cluster elimina prima tutti i suoi oggetti. L'eliminazione degli oggetti di convalida (creati durante la creazione, l'aggiornamento o l'upgrade) è bloccata nella fase di eliminazione. Questo accade
perché un finalizer blocca l'eliminazione dell'oggetto, provocando
il fallimento dell'eliminazione del cluster.
Soluzione:
- Ottieni i nomi di tutti gli oggetti Validation:
kubectl --kubeconfig ADMIN_KUBECONFIG get validations \
-n USER_CLUSTER_NAME-gke-onprem-mgmt
-
Per ogni oggetto Validation, esegui il seguente comando per rimuovere il finalizer dall'oggetto Validation:
kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
-n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
Dopo aver rimosso il finalizzatore da tutti gli oggetti Validation, gli oggetti
vengono rimossi e l'operazione di eliminazione del cluster utente viene completata
automaticamente. Non sono necessarie ulteriori azioni da parte tua.
|
Networking |
1.15, 1.16 |
Il traffico del gateway NAT in uscita verso il server esterno non riesce
Se il pod di origine e il pod gateway NAT in uscita si trovano su due
nodi worker, il traffico proveniente dal pod di origine non può raggiungere
i servizi di machine learning. Se i pod si trovano sullo stesso host, la connessione al servizio o all'applicazione esterno è andata a buon fine.
Questo problema è causato dall'eliminazione dei pacchetti VXLAN da parte di vSphere durante il tunnel
e l'aggregazione sia abilitata. Si è verificato un problema noto con NSX e VMware che
invia traffico aggregato solo sulle porte VXLAN note (4789).
Soluzione:
Modifica la porta VXLAN utilizzata da Cilium in 4789 :
- Modifica il ConfigMap
cilium-config :
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
- Aggiungi quanto segue al ConfigMap
cilium-config :
tunnel-port: 4789
- Riavvia il DaemonSet anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
Questa soluzione alternativa viene ripristinata ogni volta che viene eseguito l'upgrade del cluster. Devi
riconfigurarla dopo ogni upgrade. VMware deve risolvere il proprio problema in vSphere
per risolvere il problema in modo permanente.
|
Upgrade |
1.15.0-1.15.4 |
L'upgrade di un cluster di amministrazione con la crittografia dei secret sempre attiva non va a buon fine
L'upgrade del cluster di amministrazione da 1.14.x a 1.15.x con la crittografia dei segreti sempre attiva non riesce a causa di una mancata corrispondenza tra la chiave di crittografia generata dal controller e la chiave persistente sul disco dei dati master dell'amministratore. L'output di gkectl upgrade
admin contiene il seguente messaggio di errore:
E0926 14:42:21.796444 40110 console.go:93] Exit with error:
E0926 14:42:21.796491 40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane
L'esecuzione di kubectl get secrets -A --kubeconfig KUBECONFIG` non va a buon fine a causa del seguente errore:
Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk
Soluzione alternativa
Se hai un backup del cluster di amministrazione, segui questi passaggi per risolvere il problema di upgrade:
-
Disabilita
secretsEncryption nel cluster di amministrazione
di configurazione del deployment e aggiornare il cluster utilizzando
seguente comando:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
-
Quando viene creata la nuova VM principale amministrativa, accedi tramite SSH alla VM principale amministrativa,
sostituisci la nuova chiave sul disco di dati con quella vecchia del
backup. La chiave si trova in
/opt/data/gke-k8s-kms-plugin/generatedkeys
nell'account amministratore principale.
-
Aggiorna il manifest statico dei pod kms-plugin.yaml in
/etc/kubernetes/manifests
per aggiornare --kek-id in modo che corrisponda a kid
nella chiave di crittografia originale.
-
Riavvia il pod statico kms-plugin spostando
/etc/kubernetes/manifests/kms-plugin.yaml a un altro
nella directory precedente, quindi la sposti nella nuova directory.
-
Riprendi l'upgrade dell'amministratore eseguendo di nuovo
gkectl upgrade admin .
Evitare l'errore di upgrade
Se non lo hai già fatto, ti consigliamo di non eseguirlo
a 1.15.0-1.15.4. Se devi eseguire l'upgrade a una versione interessata, segui
i passaggi riportati di seguito prima di eseguire l'upgrade del cluster di amministrazione:
-
Esegui il backup del cluster di amministrazione.
-
Disabilita
secretsEncryption nel cluster di amministrazione
di configurazione del deployment e aggiornare il cluster utilizzando
seguente comando:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
- Esegui l'upgrade del cluster di amministrazione.
-
Riattiva la crittografia dei secret sempre attiva.
|
Archiviazione |
1.11-1.16 |
Errori del disco e errori di collegamento quando si utilizza il monitoraggio dei blocchi modificati
(CBT)
Google Distributed Cloud non supporta il monitoraggio dei blocchi modificati (CBT) sui dischi. Alcuni software di backup utilizzano la funzionalità CBT per monitorare lo stato del disco e eseguire i backup, impedendo al disco di connettersi a una VM che esegue Google Distributed Cloud. Per ulteriori informazioni, consulta
Knowledge base per VMware
.
Soluzione:
Non eseguire il backup delle VM Google Distributed Cloud, in quanto il software di backup di terze parti potrebbe attivare la CBT sui relativi dischi. Non è necessario eseguire il backup di queste VM.
Non abilitare CBT sul nodo, poiché questa modifica non verrà applicata
aggiornamenti o upgrade.
Se hai già dischi con la CBT abilitata, segui i passaggi per la risoluzione descritti nell'articolo della knowledge base VMware per disattivare la CBT sul disco di prima classe.
|
Archiviazione |
1,14, 1,15 e 1,16 |
Corruzione dei dati su NFSv3 quando gli aggiunte in parallelo a un file condiviso vengono eseguite da più host
Se utilizzi gli array di archiviazione Nutanix per fornire condivisioni NFSv3 ai tuoi
host, potresti riscontrare la corruzione dei dati o l'impossibilità per i pod di eseguire correttamente. Questo problema è causato da un noto problema di compatibilità tra alcune versioni di VMware e Nutanix. Per maggiori informazioni
informazioni, vedi le informazioni associate
Knowledge base per VMware
.
Soluzione:
L'articolo della knowledge base di VMware è obsoleto in quanto afferma che non esiste
una risoluzione attuale. Per risolvere il problema, esegui l'aggiornamento alla versione più recente di ESXi sui tuoi host e alla versione più recente di Nutanix sugli array di archiviazione.
|
Sistema operativo |
1.13.10, 1.14.6, 1.15.3 |
Mancata corrispondenza della versione tra il kubelet e il piano di controllo Kubernetes
Per alcune release di Google Distributed Cloud, il kubelet in esecuzione sul
e nodi utilizzano una versione diversa da quella del piano di controllo Kubernetes. Esiste una mancata corrispondenza perché il codice binario di kubelet precaricato nell'immagine del sistema operativo utilizza una versione diversa.
La tabella seguente elenca le mancate corrispondenze delle versioni identificate:
Versione di Google Distributed Cloud |
Versione kubelet |
Versione di Kubernetes |
1.13.10 |
v1.24.11-gke.1200 |
v1.24.14-gke.2100 |
1.14.6 |
v1.25.8-gke.1500 |
v1.25.10-gke.1200 |
1.15.3 |
v1.26.2-gke.1001 |
v1.26.5-gke.2100 |
Soluzione:
Non è richiesto alcun intervento. L'incoerenza è solo tra patch Kubernetes
e non sono stati causati problemi da questo disallineamento delle versioni.
|
Upgrade, aggiornamenti |
1.15.0-1.15.4 |
L'upgrade o l'aggiornamento di un cluster di amministrazione con una versione della CA superiore a 1 non riesce
Quando un cluster di amministrazione ha una versione dell'autorità di certificazione (CA) superiore a 1, un aggiornamento o un upgrade non riesce a causa della convalida della versione della CA nel webhook. L'output di
L'upgrade/aggiornamento di gkectl contiene il seguente messaggio di errore:
CAVersion must start from 1
Soluzione:
-
Fai lo scale down del deployment
auto-resize-controller nell'app
di amministrazione di rete per disabilitare il ridimensionamento automatico dei nodi. Questo è necessario
perché un nuovo campo introdotto nella risorsa personalizzata del cluster di amministrazione in
1.15 può causare un errore di puntatore nullo in auto-resize-controller .
kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
-
Esegui i comandi
gkectl con il flag --disable-admin-cluster-webhook .Ad esempio: gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
|
Operazione |
1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1 |
Eliminazione del cluster del piano di controllo V2 non ad alta disponibilità bloccata fino al timeout
Quando viene eliminato un cluster Control Plane V2 non ad alta disponibilità, l'eliminazione dei nodi rimane bloccata fino al timeout.
Soluzione:
Se il cluster contiene uno StatefulSet con dati critici, contatta
contatta l'assistenza clienti Google Cloud per
risolvere il problema.
In caso contrario, svolgi i seguenti passaggi:
- Elimina tutte le VM del cluster da vSphere. Puoi eliminare
VM tramite l'interfaccia utente di vSphere oppure esegui il comando seguente:
govc vm.destroy .
- Elimina di nuovo il cluster:
gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
|
Archiviazione |
1.15.0 e versioni successive, 1.16.0 e versioni successive |
Le attività di attachvolume CNS costanti vengono visualizzate ogni minuto per PVC/PV in-tree
dopo l'upgrade alla versione 1.15 e successive
Quando un cluster contiene volumi permanenti vSphere in-tree (ad esempio PVC creati con StorageClass standard ), vengono attivate attività com.vmware.cns.tasks.attachvolume ogni minuto da vCenter.
Soluzione:
Modifica il ConfigMap della funzionalità CSI di vSphere e imposta list-volumes su false:
kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG
Riavvia i pod del controller CSI vSphere:
kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
|
Archiviazione |
1.16.0 |
Falsi avvisi relativi ai PVC
Quando un cluster contiene volumi permanenti vSphere in-tree, i comandi gkectl diagnose e gkectl upgrade potrebbero generare falsi avvisi relativi alle relative richieste di volume permanente (PVC) durante la convalida delle impostazioni di archiviazione del cluster. Il messaggio di avviso è simile al seguente:
CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled
Soluzione:
Esegui il seguente comando per controllare le annotazioni di una PVC con l'avviso riportato sopra:
kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG
Se il campo annotations nel
contiene quanto segue, puoi tranquillamente ignorare l'avviso:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
|
Upgrade, aggiornamenti |
1.15.0 e versioni successive, 1.16.0 e versioni successive |
La rotazione delle chiavi dell'account di servizio non riesce quando più chiavi sono scadute
Se il cluster non utilizza un registry privato e le chiavi dell'account di servizio di accesso del componente e le chiavi dell'account di servizio di monitoraggio dei log (o di registrazione di Connect) sono scadute, quando ruoti le chiavi dell'account di servizio, gkectl update credentials
non riesce con un errore simile al seguente:
Error: reconciliation failed: failed to update platform: ...
Soluzione:
Innanzitutto, ruota la chiave dell'account di servizio di accesso ai componenti. Sebbene
appare lo stesso messaggio di errore, dovresti riuscire a ruotare
dopo la rotazione della chiave dell'account di servizio per l'accesso al componente.
Se l'aggiornamento continua a non riuscire, contatta l'assistenza clienti Google Cloud.
per risolvere il problema.
|
Upgrade |
1.16.0-1.16.5 |
La macchina principale dell'utente 1.15 riscontra una ricostituzione imprevista quando viene eseguito l'upgrade del controller del cluster utente alla versione 1.16
Durante l'upgrade di un cluster utente, dopo l'upgrade del controller del cluster utente alla versione 1.16, se hai altri cluster utente 1.15 gestiti dallo stesso cluster di amministrazione, la macchina master dell'utente potrebbe essere ricreata in modo imprevisto.
Esiste un bug nel controller del cluster utente 1.16 che può attivare la ricostituzione della macchina principale utente 1.15.
La soluzione alternativa che scegli dipende da come riscontri il problema.
Soluzione alternativa durante l'upgrade del cluster utente utilizzando la console Google Cloud:
Opzione 1: utilizza una versione 1.16.6 o successive di GKE on VMware con la correzione.
Opzione 2. Procedi nel seguente modo:
- Aggiungi manualmente l'annotazione di ripetizione con il seguente comando:
kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG
L'annotazione della nuova esecuzione è:
onprem.cluster.gke.io/server-side-preflight-rerun: true
- Monitora l'avanzamento dell'upgrade controllando il campo
status di OnPremUserCluster.
Soluzione alternativa per l'upgrade del cluster utente utilizzando la tua workstation di amministrazione:
Opzione 1: utilizza una versione 1.16.6 o successive di GKE on VMware con la correzione.
Opzione 2. Procedi nel seguente modo:
- Aggiungi il file di informazioni di compilazione
/etc/cloud/build.info con i seguenti contenuti. In questo modo, i controlli preflight vengono eseguiti localmente sulla workstation di amministrazione anziché sul server.
gke_on_prem_version: GKE_ON_PREM_VERSION
Ad esempio:
gke_on_prem_version: 1.16.0-gke.669
- Esegui di nuovo il comando di upgrade.
- Al termine dell'upgrade, elimina il file build.info.
|
Crea |
1.16.0-1.16.5, 1.28.0-1.28.100 |
Il controllo preliminare non va a buon fine se il nome host non è presente nel file di blocco IP.
Durante la creazione del cluster, se non specifichi un nome host per ogni IP
nel file del blocco IP, il controllo preflight ha esito negativo
messaggio di errore seguente:
multiple VMs found by DNS name in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`
Esiste un bug nel controllo preliminare che presuppone che il nome host vuoto sia un duplicato.
Soluzione:
Opzione 1: utilizza una versione con la correzione.
Opzione 2: aggira questo controllo preliminare aggiungendo il flag --skip-validation-net-config .
Opzione 3: specifica un nome host univoco per ogni indirizzo IP nel file del blocco IP.
|
Upgrade, aggiornamenti |
1,16 |
Errore di montaggio del volume durante l'upgrade/l'aggiornamento del cluster di amministrazione se utilizzi il cluster di amministrazione non ad alta disponibilità e il cluster utente v1 del piano di controllo
Per un cluster di amministrazione non ad alta disponibilità e un cluster utente del control plane 1, quando esegui l'upgrade o l'aggiornamento del cluster di amministrazione, la ricreazione della macchina principale del cluster di amministrazione potrebbe avvenire contemporaneamente al riavvio della macchina principale del cluster utente, il che può causare una condizione di gara.
Di conseguenza, i pod del piano di controllo del cluster utente non riescono a comunicare con il piano di controllo del cluster di amministrazione, causando problemi di attacco dei volumi per kube-etcd e kube-apiserver sul piano di controllo del cluster utente.
Per verificare il problema, esegui i seguenti comandi per il pod interessato:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
Vedrai eventi come:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 101s kubelet Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
Warning FailedMount 86s (x2 over 3m28s) kubelet MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"
Soluzione:
-
Accedi tramite SSH al nodo del piano di controllo utente, poiché si tratta di un cluster utente v1 del piano di controllo, il nodo del piano di controllo utente si trova nel cluster di amministrazione.
-
Riavvia il kubelet utilizzando il comando seguente:
sudo systemctl restart kubelet
Dopo il riavvio, il kubelet può ricostruire correttamente il montaggio globale dello stage.
|
Upgrade, aggiornamenti |
1.16.0 |
Impossibile creare il nodo del piano di controllo
Durante un upgrade o un aggiornamento di un cluster di amministrazione, una condizione di gara potrebbe causare l'eliminazione imprevista di un nuovo nodo del piano di controllo da parte del gestore del controller cloud vSphere. Di conseguenza, clusterapi-controller rimane bloccato in attesa della creazione del nodo e, eventualmente, l'upgrade/l'aggiornamento scade. In questo caso, l'output del gkectl
Il comando upgrade/update è simile al seguente:
controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...
Per identificare il sintomo, esegui il comando riportato di seguito per recuperare il log in vSphere Cloud Controller Manager nel cluster di amministrazione:
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
Ecco un esempio di messaggio di errore del comando precedente:
node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.
Soluzione:
-
Riavvia la macchina con errore per ricreare l'oggetto del nodo eliminato.
-
Accedi tramite SSH a ciascun nodo del piano di controllo e riavvia il pod statico di Cloud Controller Manager vSphere:
sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
sudo crictl stop PREVIOUS_COMMAND_OUTPUT
-
Esegui di nuovo il comando di upgrade/aggiornamento.
|
Operazione |
1,16 |
Un nome host duplicato nello stesso data center causa errori di creazione o upgrade del cluster
L'upgrade di un cluster 1.15 o la creazione di un cluster 1.16 con IP statici non riesce se esistono nomi host duplicati nello stesso data center. Questo errore si verifica perché il gestore del controller cloud vSphere non riesce ad aggiungere un ID provider e un indirizzo IP esterno nell'oggetto del nodo. Di conseguenza, l'upgrade/la creazione del cluster scade.
Per identificare il problema, recupera i log del pod del gestore del controller cloud vSphere per il cluster. Il comando da utilizzare dipende dal tipo di cluster,
come segue:
- Cluster di amministrazione:
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
- Cluster utente (kubeception):
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
- Cluster utente: (Controlplane V2):
kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system
Ecco un esempio di messaggio di errore:
I1003 17:17:46.769676 1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
E1003 17:17:46.771717 1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2
Controlla se il nome host è duplicato nel data center:
Puoi utilizzare il seguente approccio per verificare se il nome host è duplicato:
e, se necessario, adottare una soluzione alternativa.
export GOVC_DATACENTER=GOVC_DATACENTER
export GOVC_URL=GOVC_URL
export GOVC_USERNAME=GOVC_USERNAME
export GOVC_PASSWORD=GOVC_PASSWORD
export GOVC_INSECURE=true
govc find . -type m -guest.hostName HOSTNAME
Comandi e output di esempio:
export GOVC_DATACENTER=mtv-lifecycle-vc01
export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
export GOVC_USERNAME=xxx
export GOVC_PASSWORD=yyy
export GOVC_INSECURE=true
govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
./vm/gke-admin-node-6b7788cd76-wkt8g
./vm/gke-admin-node-6b7788cd76-99sg2
./vm/gke-admin-master-5m2jb
La soluzione alternativa da eseguire dipende dall'operazione non riuscita.
Soluzione alternativa per gli upgrade:
Applica la soluzione alternativa per il tipo di cluster applicabile.
- Cluster di utenti:
-
Aggiorna il nome host della macchina interessata in user-ip-block.yaml con un nome univoco e attiva un aggiornamento forzato:
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
-
Esegui di nuovo
gkectl upgrade cluster
- Cluster di amministrazione:
- Aggiorna il nome host della macchina interessata in admin-ip-block.yaml con un nome univoco e attiva un aggiornamento forzato:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
- Se si tratta di un cluster amministrativo non HA e scopri che la VM principale amministrativa utilizza un nome host duplicato, devi anche:
Ottenere il nome della macchina principale amministrativa
kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
Aggiorna oggetto macchina master amministratore
Nota: il valore di NEW_ADMIN_MASTER_HOSTNAME deve corrispondere a quello impostato in admin-ip-block.yaml nel passaggio 1.
kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
Verifica che il nome host sia aggiornato nell'oggetto della macchina principale dell'amministratore:
kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
- Esegui di nuovo l'upgrade del cluster di amministrazione con il checkpoint disattivato:
gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint
Soluzione alternativa per le installazioni:
Applica la soluzione alternativa per il tipo di cluster applicabile.
|
Operazione |
1.16.0, 1.16.1, 1.16.2, 1.16.3 |
$ e ` non sono supportati nel nome utente o nella password vSphere
Le seguenti operazioni non riescono quando il nome utente o la password vSphere
contiene $ o ` :
- Aggiornamento di un cluster utente 1.15 con Controlplane V2 abilitato a 1.16
- Upgrade di un cluster di amministrazione ad alta disponibilità (HA) 1.15 a 1.16
- Creazione di un cluster utente 1.16 con Control Plane v2 abilitato
- Creazione di un cluster di amministrazione HA 1.16
Usa una versione 1.16.4 o versioni successive di Google Distributed Cloud con la correzione oppure esegui la soluzione alternativa riportata di seguito. La soluzione alternativa da eseguire dipende dall'operazione non riuscita.
Soluzione alternativa per gli upgrade:
- Modifica il nome utente o la password di vCenter lato vCenter per rimuovere
$ e ` .
- Aggiorna il nome utente o la password vCenter nel tuo
credenziali
di configurazione del deployment.
- Attivare un aggiornamento forzato del cluster.
- Cluster di utenti:
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
- Cluster di amministrazione:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
Soluzione alternativa per le installazioni:
- Modifica il nome utente o la password di vCenter lato vCenter per rimuovere
$ e ` .
- Aggiorna il nome utente o la password di vCenter nel
file di configurazione
delle credenziali.
- Esegui la soluzione alternativa per il tipo di cluster applicabile.
|
Archiviazione |
1.11 e versioni successive, 1.12 e versioni successive, 1.13 e versioni successive, 1.14 e versioni successive, 1.15 e versioni successive, 1.16 |
Errore di creazione del PVC dopo la ricreazione del nodo con lo stesso nome
Dopo che un nodo è stato eliminato e poi ricreato con lo stesso nome,
c'è una leggera probabilità che un PersistentVolumeClaim (PVC)
la creazione non va a buon fine e restituisce un errore come il seguente:
The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created
Questo problema è causato da una condizione di gara in cui il controller vSphere CSI non elimina una macchina rimossa dalla cache.
Soluzione:
Riavvia i pod del controller CSI vSphere:
kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
|
Operazione |
1.16.0 |
gkectl repair admin-master restituisce un errore di unmarshalling del file kubeconfig
Quando esegui il comando gkectl repair admin-master su un'alta disponibilità
cluster di amministrazione, gkectl restituisce il seguente messaggio di errore:
Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
line 3: cannot unmarshal !!seq into map[string]*api.Cluster
line 8: cannot unmarshal !!seq into map[string]*api.Context
Soluzione:
Aggiungi il flag --admin-master-vm-template= al comando e
fornisci il modello di VM della macchina da riparare:
gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--config ADMIN_CLUSTER_CONFIG_FILE \
--admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME
Per trovare il modello VM della macchina:
- Vai alla pagina Host e cluster nel client vSphere.
- Fai clic su Modelli VM e filtra in base al nome del cluster di amministrazione.
Dovresti vedere i tre modelli VM per il cluster amministrativo.
- Copia il nome del modello di VM che corrisponde al nome della macchina
che stai riparando e utilizza il nome del modello nel comando di riparazione.
gkectl repair admin-master \
--config=/home/ubuntu/admin-cluster.yaml \
--kubeconfig=/home/ubuntu/kubeconfig \
--admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
|
Networking |
1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0 |
VM Seesaw interrotta a causa dello spazio su disco insufficiente
Se utilizzi Seesaw come tipo di bilanciatore del carico per il tuo cluster e noti che
una VM Seesaw non è attiva o continua a non avviarsi, potresti visualizzare il seguente errore
nella console vSphere:
GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
Questo errore indica che lo spazio su disco della VM è insufficiente perché fluent-bit
in esecuzione sulla VM Seesaw non è configurato con la rotazione dei log corretta.
Soluzione:
Individua i file di log che consumano la maggior parte dello spazio su disco utilizzando du -sh -- /var/lib/docker/containers/* | sort -rh . Ripulisci il file di log di dimensioni maggiori e riavvia la VM.
Nota: se la VM è completamente inaccessibile, collega il disco a una VM funzionante (ad es. una workstation di amministrazione), rimuovi il file dal disco collegato e ricollega il disco alla VM Seesaw originale.
Per evitare che il problema si ripresenti, connettiti alla VM e modifica il file /etc/systemd/system/docker.fluent-bit.service . Aggiungi --log-opt max-size=10m --log-opt max-file=5 al comando Docker, quindi esegui systemctl restart docker.fluent-bit.service
|
Operazione |
1.13, 1.14.0-1.14.6, 1.15 |
Errore della chiave pubblica SSH dell'amministratore dopo l'upgrade o l'aggiornamento del cluster di amministrazione
Quando provi a eseguire l'upgrade (gkectl upgrade admin ) o l'aggiornamento
(gkectl update admin ) un cluster di amministrazione non ad alta disponibilità
con il checkpoint abilitato, l'upgrade o l'aggiornamento potrebbe non riuscire e potrebbero verificarsi errori
seguenti:
Checking admin cluster certificates...FAILURE
Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
ubuntu@AdminMasterIP: Permission denied (publickey).
failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
ubuntu@AdminMasterIP: Permission denied (publickey)
error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...
Soluzione:
Se non riesci a eseguire l'upgrade a una versione patch di Google Distributed Cloud con la correzione,
Contatta l'Assistenza Google per ricevere aiuto.
|
Upgrade |
1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2 |
L'upgrade di un cluster di amministrazione registrato nell'API GKE On-Prem potrebbe non riuscire
Quando un cluster di amministrazione è registrato nell'API GKE On-Prem, l'upgrade del
cluster di amministrazione alle versioni interessate potrebbe non riuscire perché l'appartenenza al parco risorse
non è stata aggiornata. In questo caso, vedrai
questo errore durante il tentativo di eseguire l'upgrade del cluster:
failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated
Un cluster di amministrazione viene registrato nell'API quando lo registri esplicitamente o quando esegui l'upgrade di un cluster utente utilizzando un client API GKE On-Prem.
Soluzione:
Annullare la registrazione del cluster di amministrazione:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
e riprendi
eseguendo l'upgrade del cluster di amministrazione. Potresti vedere che l'errore "non è riuscito"
"registra cluster". Dopo un po' di tempo, dovrebbe essere aggiornato
automaticamente.
|
Upgrade, aggiornamenti |
1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0 |
L'annotazione del link alle risorse del cluster di amministrazione registrato non viene conservata
Quando un cluster di amministrazione viene registrato nell'API GKE On-Prem, la relativa risorsa
L'annotazione del link viene applicata all'elemento OnPremAdminCluster personalizzato
che non viene conservata durante i successivi aggiornamenti del cluster di amministrazione a causa
è in uso la chiave di annotazione errata. Questo può far sì che il cluster di amministrazione
registrato di nuovo per errore nell'API GKE On-Prem.
Un cluster di amministrazione viene registrato nell'API quando lo registri esplicitamente o quando esegui l'upgrade di un cluster utente utilizzando un client API GKE On-Prem.
Soluzione:
Annulla la registrazione del cluster di amministrazione:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
e registra di nuovo
il cluster di amministrazione.
|
Networking |
1.15.0-1.15.2 |
CoreDNS orderPolicy non riconosciuto
OrderPolicy non viene riconosciuto come parametro e
non viene utilizzato. Google Distributed Cloud utilizza sempre Random .
Questo problema si verifica perché il modello CoreDNS non è stato aggiornato, il che comporta l'ignoramento di orderPolicy .
Soluzione:
Aggiorna il modello CoreDNS e applica la correzione. Questa correzione persiste fino al
un upgrade.
- Modifica il modello esistente:
kubectl edit cm -n kube-system coredns-template
Sostituisci i contenuti del modello con i seguenti:
coredns-template: |-
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
{{- if .PrivateGoogleAccess }}
import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
import zones/restricted.Corefile
{{- end }}
prometheus :9153
forward . {{ .UpstreamNameservers }} {
max_concurrent 1000
{{- if ne .OrderPolicy "" }}
policy {{ .OrderPolicy }}
{{- end }}
}
cache 30
{{- if .DefaultDomainQueryLogging }}
log
{{- end }}
loop
reload
loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
errors
{{- if $stubdomain.QueryLogging }}
log
{{- end }}
cache 30
forward . {{ $stubdomain.Nameservers }} {
max_concurrent 1000
{{- if ne $.OrderPolicy "" }}
policy {{ $.OrderPolicy }}
{{- end }}
}
}
{{- end }}
|
Upgrade, aggiornamenti |
1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3 |
Stato OnPremAdminCluster incoerente tra checkpoint e RP effettiva
Alcune condizioni di gara potrebbero causare un'incoerenza dello stato OnPremAdminCluster tra il checkpoint e la RP effettiva. Quando si verifica il problema, potresti riscontrare il seguente errore quando aggiorni il cluster di amministrazione dopo l'upgrade:
Exit with error:
E0321 10:20:53.515562 961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Per aggirare questo problema, dovrai modificare il checkpoint o disattivarlo per l'upgrade/l'aggiornamento. Contatta il nostro team di assistenza per procedere con la soluzione alternativa.
|
Operazione |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Il processo di riconciliazione modifica i certificati amministrativi sui cluster di amministrazione
Google Distributed Cloud cambia i certificati amministrativi sui piani di controllo del cluster di amministrazione
a ogni processo di riconciliazione, ad esempio durante l'upgrade di un cluster. Questo comportamento
aumenta la possibilità di ottenere certificati non validi per il cluster di amministrazione,
in particolare per i cluster della versione 1.15.
Se hai questo problema, potresti riscontrare problemi come
seguenti:
Soluzione:
Esegui l'upgrade a una versione di Google Distributed Cloud con la correzione:
1.13.10 e versioni successive, 1.14.6 e versioni successive, 1.15.2 e versioni successive.
Se non riesci a eseguire l'upgrade, contatta l'assistenza clienti Google Cloud per risolvere il problema.
|
Networking, operazione |
1,10; 1,11; 1,12; 1,13; 1,14 |
Componenti del gateway di rete Anthos rimossi o in attesa perché mancanti
classe di priorità
I pod di gateway di rete in kube-system potrebbero mostrare lo stato Pending o Evicted , come mostrato nell'esempio di output condensato riportato di seguito:
$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc 2/2 Running 0 5d2h
ang-node-mw8cq 0/2 Evicted 0 6m5s
ang-node-zsmq7 0/2 Pending 0 7h
Questi errori indicano eventi di espulsione o l'impossibilità di pianificare i pod
a causa delle risorse del nodo. Poiché i pod Anthos Network Gateway non hanno PriorityClass, hanno la stessa priorità predefinita degli altri carichi di lavoro.
Quando i nodi sono soggetti a limitazioni di risorse, i pod del gateway di rete potrebbero essere
eliminati. Questo comportamento è particolarmente negativo per ang-node
DaemonSet, poiché i pod devono essere pianificati su un nodo specifico
eseguire la migrazione.
Soluzione:
Esegui l'upgrade alla versione 1.15 o successiva.
Come soluzione a breve termine, puoi assegnare manualmente
PriorityClass
ai componenti del gateway di rete Anthos. Controller Google Distributed Cloud
sovrascrive queste modifiche manuali durante un processo di riconciliazione, come
durante l'upgrade di un cluster.
- Assegna il valore PriorityClass
system-cluster-critical al
Cluster ang-controller-manager e autoscaler
deployment di controller.
- Assegna
system-node-critical PriorityClass al DaemonSet del nodo ang-daemon .
|
Upgrade, aggiornamenti |
1,12, 1,13, 1,14, 1.15.0-1.15.2 |
L'upgrade del cluster di amministrazione non va a buon fine dopo la registrazione del cluster con gcloud
Dopo aver utilizzato gcloud per registrare un cluster amministrativo con una sezione gkeConnect non vuota, potresti visualizzare il seguente errore durante il tentativo di eseguire l'upgrade del cluster:
failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated
Elimina lo spazio dei nomi gke-connect :
kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Recupera il nome del cluster di amministrazione:
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Elimina l'appartenenza al parco risorse:
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
e riprendi l'upgrade del cluster di amministrazione.
|
Operazione |
1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1 |
gkectl diagnose snapshot --log-since non riesce a limitare la finestra temporale per i comandi journalctl in esecuzione sui nodi del cluster
Ciò non influisce sulla funzionalità di acquisizione di uno snapshot del
cluster, in quanto lo snapshot include comunque tutti i log raccolti per impostazione predefinita con l'esecuzione di journalctl sui nodi del cluster. Pertanto,
informazioni di debug non perse.
|
Installazione, upgrade, aggiornamenti |
1.9 e versioni successive, 1.10 e versioni successive, 1.11 e versioni successive, 1.12 e versioni successive |
gkectl prepare windows non riesce
gkectl prepare windows non riesce a installare Docker su
le versioni di Google Distributed Cloud precedenti alla 1.13 perché
MicrosoftDockerProvider
è deprecato.
Soluzione:
L'idea generale per aggirare il problema è eseguire l'upgrade a Google Distributed Cloud 1.13
e utilizzare la versione 1.13 gkectl per creare un modello VM Windows e poi creare
pool di nodi Windows. Esistono due opzioni per passare a Google Distributed Cloud 1.13 dalla versione corrente, come mostrato di seguito.
Nota: sono disponibili opzioni per aggirare questo problema nella tua versione attuale.
senza dover eseguire l'upgrade alla versione 1.13, ma necessita di una maggiore quantità
passaggi, contatta il nostro team di assistenza se vuoi valutare
questa opzione.
Opzione 1: upgrade blu/verde
Puoi creare un nuovo cluster utilizzando Google Distributed Cloud 1.13 o versioni successive con pool di nodi Windows.
eseguire la migrazione dei carichi di lavoro nel nuovo cluster, quindi eliminare
in un cluster Kubernetes. Ti consigliamo di utilizzare l'ultima versione secondaria di Google Distributed Cloud.
Nota: questa operazione richiederà risorse aggiuntive per il provisioning del nuovo cluster, ma meno tempi di inattività e interruzioni per i carichi di lavoro esistenti.
Opzione 2: elimina i pool di nodi Windows e aggiungili di nuovo quando
upgrade a Google Distributed Cloud 1.13
Nota: per questa opzione, i carichi di lavoro Windows non potranno essere eseguiti fino a quando
viene eseguito l'upgrade del cluster alla versione 1.13 e vengono aggiunti di nuovo i pool di nodi Windows.
- Elimina i pool di nodi Windows esistenti rimuovendo la configurazione dei pool di nodi Windows dal file user-cluster.yaml, quindi esegui il comando:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Esegui l'upgrade dei cluster amministratore+utente solo Linux alla versione 1.12 seguendo le
Esegui l'upgrade della guida dell'utente per la versione secondaria di destinazione corrispondente.
- (Assicurati di eseguire questo passaggio prima di eseguire l'upgrade alla versione 1.13) Assicurati che
enableWindowsDataplaneV2: true sia configurato nella RP di OnPremUserCluster , altrimenti il cluster continuerà a utilizzare Docker per i pool di nodi Windows, che non saranno compatibili con il modello di VM Windows 1.13 appena creato in cui non è installato Docker. Se non viene configurato o se viene impostato su false, aggiorna il cluster in modo da impostarlo su true in user-cluster.yaml, quindi esegui:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Esegui l'upgrade dei cluster amministratore+utente solo Linux alla versione 1.13 seguendo le
Guida dell'utente per l'upgrade.
- Prepara il modello VM Windows utilizzando gkectl 1.13:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
- Aggiungi di nuovo la configurazione del pool di nodi Windows a user-cluster.yaml con il campo
OSImage impostato sul modello di VM Windows appena creato.
- Aggiorna il cluster per aggiungere pool di nodi Windows
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
|
Installazione, upgrade, aggiornamenti |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
La configurazione di RootDistanceMaxSec non viene applicata ai nodi ubuntu
Sui nodi verrà utilizzato il valore predefinito di 5 secondi per RootDistanceMaxSec , anziché 20 secondi, che dovrebbe essere la configurazione prevista. Se controlli il log di avvio del nodo tramite SSH nella VM,
che si trova in "/var/log/startup.log", puoi trovare il seguente
errore:
+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found
L'utilizzo di un valore RootDistanceMaxSec di 5 secondi potrebbe causare la mancata sincronizzazione dell'orologio di sistema con il server NTP quando lo scostamento dell'orologio è superiore a 5 secondi.
Soluzione:
Applica il seguente DaemonSet al cluster per configurare RootDistanceMaxSec :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-root-distance
namespace: kube-system
spec:
selector:
matchLabels:
app: change-root-distance
template:
metadata:
labels:
app: change-root-distance
spec:
hostIPC: true
hostPID: true
tolerations:
# Make sure pods gets scheduled on all nodes.
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
containers:
- name: change-root-distance
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
echo "timesyncd has the expected RootDistanceMaxSec, skip update"
else
echo "updating timesyncd config to RootDistanceMaxSec=20"
mkdir -p /etc/systemd/timesyncd.conf.d
cat > $conf_file << EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Upgrade, aggiornamenti |
1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
gkectl update admin non riesce a causa di un campo osImageType vuoto
Quando utilizzi la versione 1.13 gkectl per aggiornare una versione 1.12
cluster di amministrazione, potresti visualizzare il seguente errore:
Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"
Quando utilizzi gkectl update admin per i cluster della versione 1.13 o 1.14, nella risposta potresti visualizzare il seguente messaggio:
Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time
Se controlli il log gkectl , potresti notare che più
le modifiche includono l'impostazione osImageType da una stringa vuota a
ubuntu_containerd .
Questi errori di aggiornamento sono dovuti a un backfill non corretto dei
Campo osImageType nella configurazione del cluster di amministrazione, dato che era
introdotta nella versione 1.9.
Soluzione:
Esegui l'upgrade a una versione di Google Distributed Cloud con la correzione. Se esegui l'upgrade
non è un'opzione possibile, contatta l'assistenza clienti Google Cloud per risolvere il problema.
|
Installazione, sicurezza |
1,13; 1,14; 1,15; 1,16 |
L'SNI non funziona nei cluster utente con Control Plane V2
La possibilità di fornire un certificato di pubblicazione aggiuntivo per il
server API Kubernetes di un cluster utente con
authentication.sni non funziona quando è attivo il Controlplane V2 (
enableControlplaneV2: true ).
Soluzione:
Fino a quando non sarà disponibile una patch Google Distributed Cloud con la correzione,
è necessario utilizzare SNI, disabilita il piano di controllo V2 (enableControlplaneV2: false ).
|
Installazione |
1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
$ nel nome utente del registry privato causa un errore di avvio della macchina del piano di controllo amministrativo
La macchina del piano di controllo amministrativo non si avvia quando il nome utente del registry privato contiene $ .
Quando controlli il /var/log/startup.log sulla macchina del piano di controllo amministratore, vedrai
il seguente errore:
++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable
Soluzione:
Utilizza un nome utente di registro privato senza $ oppure una versione di Google Distributed Cloud con
la correzione.
|
Upgrade, aggiornamenti |
1.12.0-1.12.4 |
Avvisi di falsi positivi relativi a modifiche non supportate durante l'aggiornamento del cluster di amministrazione
Quando
aggiorni i cluster di amministrazione, nel log vengono visualizzati i seguenti avvisi di falsi positivi, che puoi ignorare.
console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
...
- CARotation: &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
+ CARotation: nil,
...
}
|
Upgrade, aggiornamenti |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Aggiornamento del cluster utente non riuscito dopo la rotazione della chiave di firma dell'Arabia Saudita
Dopo aver ruotato
Chiavi di firma Arabia Saudita e successivamente
aggiorna un cluster utente, gkectl update potrebbe non riuscire con
messaggio di errore seguente:
Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"
Soluzione:
Ripristina la versione della chiave di firma Arabia Saudita a 1, ma conserva i dati della chiave più recenti:
- Controlla il secret nel cluster di amministrazione nello spazio dei nomi
USER_CLUSTER_NAME e recupera il nome del secret ksa-signing-key:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
- Copia lo secret ksa-signing-key e assegnalo al nome service-account-cert:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
- Elimina il precedente secret della chiave ksa-signing-key:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
- Aggiorna il campo
data.data in ksa-signing-key-rotation-stage configmap a '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
- Disattiva il webhook di convalida per modificare le informazioni sulla versione nella risorsa personalizzata OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremuserclusters
'
- Aggiorna il campo
spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation a 1 nella risorsa personalizzata OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
- Attendi che il cluster utente di destinazione sia pronto. Puoi controllare lo stato in base a:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
- Ripristina il webhook di convalida per il cluster utente:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremuserclusters
'
- Evita un'altra rotazione della chiave di firma KSA finché non viene eseguito
l'upgrade del cluster alla versione con la correzione.
|
Operazione |
1.13.1 e versioni successive, 1.14, 1., 1,16 |
Quando utilizzi Terraform per eliminare un cluster di utenti con un bilanciatore del carico F5 BIG-IP, i server virtuali F5 BIG-IP non vengono rimossi dopo l'eliminazione del cluster.
Soluzione:
Per rimuovere le risorse F5, segui i passaggi per
ripulisci una partizione F5 del cluster utente
|
Installazione, upgrade, aggiornamenti |
1.13.8, 1.14.4 |
il cluster di tipo estrae le immagini container da docker.io
Se crei un cluster di amministrazione versione 1.13.8 o 1.14.4 o se esegui l'upgrade di un cluster di amministrazione alla versione 1.13.8 o 1.14.4, il cluster di tipo estrae le seguenti immagini contenitore da docker.io :
docker.io/kindest/kindnetd
docker.io/kindest/local-path-provisioner
docker.io/kindest/local-path-helper
Se docker.io non è accessibile dalla workstation di amministrazione,
la creazione o l'upgrade del cluster di amministrazione non riesce a visualizzare il cluster di tipo.
L'esecuzione del comando seguente sulla workstation di amministrazione mostra
container corrispondenti in attesa con ErrImagePull :
docker exec gkectl-control-plane kubectl get pods -A
La risposta contiene voci come la seguente:
...
kube-system kindnet-xlhmr 0/1
ErrImagePull 0 3m12s
...
local-path-storage local-path-provisioner-86666ffff6-zzqtp 0/1
Pending 0 3m12s
...
Queste immagini container devono essere precaricate nell'immagine container del cluster di tipo. Tuttavia, il tipo v0.18.0 ha
un problema con le immagini container precaricate,
il che li fa estrarli da internet per errore.
Soluzione:
Esegui i seguenti comandi sulla workstation di amministrazione mentre il cluster di amministrazione è in attesa di creazione o upgrade:
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
|
Operazione |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
Failover non riuscito nel cluster utente e nel cluster di amministrazione del Control Plane V2 ad alta disponibilità quando la rete filtra le richieste GARP duplicate
Se le VM del cluster sono connesse a uno switch che filtra le richieste GARP (ARP gratuitous) duplicate, l'elezione del leader keepalived potrebbe incontrare una condizione di gara, che causa voci della tabella ARP errate in alcuni nodi.
I nodi interessati possono ping il VIP del piano di controllo, ma una connessione TCP al VIP del piano di controllo
scadrà.
Soluzione:
Esegui questo comando su ciascun nodo del piano di controllo del cluster interessato:
iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
|
Upgrade, aggiornamenti |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
vsphere-csi-controller deve essere riavviato dopo la rotazione del certificato vCenter
vsphere-csi-controller deve aggiornare il proprio secret vCenter dopo la rotazione del certificato vCenter. Tuttavia, il sistema attuale non riavvia correttamente i pod di vsphere-csi-controller , causando l'arresto anomalo di vsphere-csi-controller dopo la rotazione.
Soluzione:
Per i cluster creati con la versione 1.13 e successive, segui le istruzioni riportate di seguito per riavviare vsphere-csi-controller
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
|
Installazione |
1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1 |
La creazione del cluster di amministrazione non fallisce in caso di errori di registrazione del cluster
Anche quando
La registrazione del cluster non va a buon fine durante la creazione del cluster di amministrazione, il comando gkectl create admin non riesce a generare l'errore e potrebbe andare a buon fine. In altre parole, la creazione del cluster di amministrazione potrebbe "riuscita" senza essere registrati a un parco risorse.
Per identificare il sintomo, puoi cercare i seguenti messaggi di errore nel log di "gkectl create admin",
Failed to register admin cluster
Puoi anche verificare se riesci a trovare il cluster tra i cluster registrati nella console Cloud.
Soluzione:
Per i cluster creati alla versione 1.12 e successive, segui le istruzioni per ritentare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster creati in versioni precedenti,
-
Aggiungi una coppia chiave-valore falsa come "foo: bar" al file della chiave SA di connect-register
-
Esegui
gkectl update admin per registrare di nuovo il cluster di amministrazione.
|
Upgrade, aggiornamenti |
1,10, 1,11, 1,12, 1.13.0-1.13.1 |
La nuova registrazione del cluster di amministrazione potrebbe essere saltata durante l'upgrade del cluster di amministrazione
Durante l'upgrade del cluster di amministrazione, se il timeout dell'upgrade dei nodi del piano di controllo utente si verifica, il cluster di amministrazione non verrà registrato di nuovo con la versione aggiornata dell'agente di connessione.
Soluzione:
Controlla se il cluster è presente tra i cluster registrati.
Come passaggio facoltativo, accedi al cluster dopo aver configurato l'autenticazione. Se il cluster è ancora registrato, potresti saltare le istruzioni seguenti per ritentare la registrazione.
Per i cluster di cui è stato eseguito l'upgrade alla versione 1.12 e successive, segui le istruzioni per riprovare a registrare il cluster di amministrazione dopo la creazione del cluster. Per i cluster di cui è stato eseguito l'upgrade a versioni precedenti,
-
Aggiungi una coppia chiave-valore falsa come "foo: bar" al file di chiave SA Connect-register
-
Esegui
gkectl update admin per registrare di nuovo il cluster di amministrazione.
|
Configurazione |
1.15.0 |
Messaggio di errore falso relativo a vCenter.dataDisk
Per un cluster di amministrazione ad alta disponibilità, gkectl prepare mostra questo falso messaggio di errore:
vCenter.dataDisk must be present in the AdminCluster spec
Soluzione:
Puoi ignorare questo messaggio di errore.
|
VMware |
1.15.0 |
La creazione del pool di nodi non riesce a causa di regole di affinità VM-host ridondanti
Durante la creazione di un pool di nodi che utilizza la affinità VM-host, una condizione di gara potrebbe comportare la creazione di più regole di affinità VM-host con lo stesso nome. Ciò può causare la mancata creazione del pool di nodi.
Soluzione:
Rimuovi le precedenti regole ridondanti per consentire l'esecuzione della creazione del pool di nodi.
Queste regole sono denominate [USER_CLUSTER_NAME]-[HASH].
|
Operazione |
1.15.0 |
gkectl repair admin-master potrebbe non riuscire a causa di failed
to delete the admin master node object and reboot the admin master VM
Il comando gkectl repair admin-master potrebbe non riuscire a causa di un
con il seguente errore.
Failed to repair: failed to delete the admin master node object and reboot the admin master VM
Soluzione:
Questo comando è idempotente. Può essere eseguito di nuovo in sicurezza finché il comando
non va a buon fine.
|
Upgrade, aggiornamenti |
1.15.0 |
I pod rimangono in stato Non riuscito dopo la riproduzione o l'aggiornamento di un
nodo del piano di controllo
Dopo aver ricreato o aggiornato un nodo del piano di controllo, alcuni pod potrebbero rimanere nello stato Failed a causa del fallimento del predicato NodeAffinity. Questi pod con errori non influiscono sulle normali operazioni o sull'integrità del cluster.
Soluzione:
Puoi ignorare tranquillamente i pod non riusciti o eliminarli manualmente.
|
Sicurezza, configurazione |
1.15.0-1.15.1 |
Il cluster di utenti on-premise non è pronto a causa delle credenziali del registry privato
Se utilizzi
credenziali preparate
e un registry privato, ma non hai configurato le credenziali preparate per
il tuo registry privato, il cluster di utenti OnPrem potrebbe non essere pronto e
potresti visualizzare il seguente messaggio di errore:
failed to check secret reference for private registry …
Soluzione:
Prepara le credenziali del registro private per il cluster utente in base
alle istruzioni in
Configura le credenziali preparate.
|
Upgrade, aggiornamenti |
1.15.0 |
Durante gkectl upgrade admin , il controllo preliminare dello spazio di archiviazione per la migrazione CSI verifica
che le classi di archiviazione non abbiano parametri ignorati dopo la migrazione CSI.
Ad esempio, se esiste un StorageClass con il parametro diskformat , then
gkectl upgrade admin segnala il StorageClass e segnala un errore nella convalida di preflight.
I cluster di amministrazione creati in Google Distributed Cloud 1.10 e versioni precedenti hanno un valore StorageClass con diskformat: thin
che non supererà questa convalida, ma questo valore StorageClass continuerà a funzionare correttamente
dopo la migrazione CSI. Questi errori devono essere interpretati come avvisi.
Per ulteriori informazioni, consulta la sezione relativa ai parametri StorageClass in Migrazione di volumi vSphere In-Tree al plug-in vSphere Container Storage.
Soluzione:
Dopo aver confermato che il cluster ha un oggetto StorageClass con parametri ignorati dopo la migrazione CSI
esegui gkectl upgrade admin con il flag --skip-validation-cluster-health .
|
Archiviazione |
1,15, 1,16 |
I volumi vSphere in-tree di cui è stata eseguita la migrazione utilizzando il file system Windows non possono essere utilizzati con il driver CSI vSphere
In determinate condizioni, i dischi possono essere collegati in modalità di sola lettura ai nodi Windows. Di conseguenza, il volume corrispondente sarà di sola lettura all'interno di un pod.
Questo problema si verifica più facilmente quando un nuovo insieme di nodi sostituisce un vecchio insieme di nodi (ad esempio, upgrade del cluster o aggiornamento del pool di nodi). stateful
carichi di lavoro che in precedenza funzionavano correttamente potrebbero non essere in grado di scrivere
volumi sul nuovo set di nodi.
Soluzione:
-
Ottieni l'UID del pod che non è in grado di scrivere nel suo volume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
POD_NAME --namespace POD_NAMESPACE \
-o=jsonpath='{.metadata.uid}{"\n"}'
-
Utilizza il PersistentVolumeClaim per ottenere il nome del PersistentVolume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
PVC_NAME --namespace POD_NAMESPACE \
-o jsonpath='{.spec.volumeName}{"\n"}'
-
Determina il nome del nodo su cui è in esecuzione il pod:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
--namespace POD_NAMESPACE \
-o jsonpath='{.spec.nodeName}{"\n"}'
-
Ottieni l'accesso PowerShell al nodo tramite SSH o l'interfaccia web vSphere.
-
Imposta le variabili di ambiente:
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- Identifica il numero del disco associato alla
PersistentVolume:
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
-
Verifica che il disco sia
readonly :
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
Il risultato dovrebbe essere True .
- Imposta
readonly su false .
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
-
Elimina il pod in modo che venga riavviato:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
--namespace POD_NAMESPACE
-
Il pod deve essere pianificato sullo stesso nodo. Ma nel caso in cui il pod riceva
pianificato su un nuovo nodo, potresti dover ripetere i passaggi precedenti
il nuovo nodo.
|
Upgrade, aggiornamenti |
1.12, 1.13.0-1.13.7, 1.14.0-1.14.4 |
vsphere-csi-secret non viene aggiornato dopo il giorno gkectl update credentials vsphere --admin-cluster
Se aggiorni le credenziali vSphere per un cluster di amministrazione dopo aver aggiornato le credenziali del cluster, potresti scoprire che vsphere-csi-secret nel namespace kube-system del cluster di amministrazione utilizza ancora la vecchia credenziale.
Soluzione:
- Recupera il nome del secret
vsphere-csi-secret :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
- Aggiorna i dati del secret
vsphere-csi-secret che hai ricevuto nel passaggio precedente:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
"{\"data\":{\"config\":\"$( \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
| base64 -d \
| sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
| sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
| base64 -w 0 \
)\"}}"
- Riavvia
vsphere-csi-controller :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
- Puoi monitorare lo stato dell'implementazione con:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
Una volta implementato correttamente il deployment, il controller vsphere-csi-secret dovrebbe utilizzare il vsphere-csi-secret aggiornato.
|
Upgrade, aggiornamenti |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
audit-proxy crashloop quando si attivano gli audit log di Cloud con gkectl update cluster
audit-proxy potrebbe arrestarsi in modo anomalo a causa di --cluster-name vuoto.
Questo comportamento è causato da un bug nella logica di aggiornamento, in cui il nome del cluster non viene propagato
il manifest del pod / del container audit-proxy.
Soluzione:
Per un cluster utente del control plane v2 con enableControlplaneV2: true , connettiti alla macchina del control plane utente tramite SSH
e aggiorna /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME .
Per un cluster utente del control plane v1, modifica il contenitore audit-proxy nel statefulset kube-apiserver per aggiungere --cluster_name=USER_CLUSTER_NAME :
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
|
Upgrade, aggiornamenti |
1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Un ulteriore deployment del piano di controllo subito dopo gkectl upgrade cluster
Subito dopo gkectl upgrade cluster , i pod del piano di controllo potrebbero essere di nuovo dispiazzati.
Lo stato del cluster da gkectl list clusters cambia da RUNNING a RECONCILING .
Le richieste al cluster utente potrebbero scadere.
Questo comportamento è dovuto alla rotazione dei certificati del piano di controllo che avviene automaticamente dopo
gkectl upgrade cluster .
Questo problema si verifica solo ai cluster utente che NON utilizzano il piano di controllo v2.
Soluzione:
Attendi che lo stato del cluster torni a RUNNING in gkectl list clusters oppure
esegui l'upgrade alle versioni con la correzione: 1.13.6+, 1.14.2+ o 1.15+.
|
Upgrade, aggiornamenti |
1.12.7 |
La release non valida 1.12.7-gke.19 è stata rimossa
Google Distributed Cloud 1.12.7-gke.19 è una versione non valida
e non dovresti utilizzarlo. Gli elementi sono stati rimossi
dal bucket Cloud Storage.
Soluzione:
Usa invece la release 1.12.7-gke.20.
|
Upgrade, aggiornamenti |
1.12.0 e versioni successive, 1.13.0-1.13.7, 1.14.0-1.14.3 |
gke-connect-agent
continua a utilizzare l'immagine precedente dopo l'aggiornamento delle credenziali del registro
Se aggiorni la credenziale del registry utilizzando uno dei seguenti metodi:
gkectl update credentials componentaccess se non utilizzi il registry privato
gkectl update credentials privateregistry se utilizzi il registro privato
potresti notare che gke-connect-agent continua a utilizzare la versione precedente
o non è possibile eseguire il pull dei pod gke-connect-agent a causa
a ImagePullBackOff .
Questo problema verrà risolto nelle release di Google Distributed Cloud 1.13.8,
1.14.4 e nelle release successive.
Soluzione:
Opzione 1: riesegui il deployment di gke-connect-agent manualmente:
- Elimina lo spazio dei nomi
gke-connect :
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- Esegui nuovamente il deployment di
gke-connect-agent con la chiave dell'account di servizio del registry originale (non è necessario aggiornare la chiave):
Per il cluster di amministrazione:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
Per il cluster di utenti:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Opzione 2: puoi modificare manualmente i dati del secret di pull dell'immagine
regcred utilizzato da gke-connect-agent
deployment:
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"
Opzione 3: puoi aggiungere il segreto di estrazione dell'immagine predefinito per il tuo cluster nel deployment gke-connect-agent :
- Copia la chiave segreta predefinita nello spazio dei nomi
gke-connect :
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
- Recupera il nome del deployment
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
- Aggiungi il secret predefinito al deployment
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
|
Installazione |
1.13, 1.14 |
Errore del controllo della configurazione manuale del bilanciatore del carico
Quando convalidi la configurazione prima di creare un cluster con bilanciatore del carico manuale eseguendo gkectl check-config , il comando non andrà a buon fine con i seguenti messaggi di errore.
- Validation Category: Manual LB Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference
Soluzione:
Opzione 1: puoi utilizzare le versioni della patch 1.13.7 e 1.14.4 che includeranno la correzione.
Opzione 2: puoi anche eseguire lo stesso comando per convalidare la configurazione, ma saltare la convalida del bilanciatore del carico.
gkectl check-config --skip-validation-load-balancer
|
Operazione |
1,0, 1,1, 1,2, 1,3, 1,4, 1,5, 1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 e 1,14 |
fame smartwatch etcd
I cluster che eseguono etcd versione 3.4.13 o precedenti potrebbero essere soggetti
inadempienza e smartwatch di risorse non operative, il che può portare
i seguenti problemi:
- La pianificazione dei pod è interrotta
- Impossibile registrare i nodi
- kubelet non rileva le modifiche ai pod
Questi problemi possono rendere il cluster non funzionante.
Questo problema è stato risolto nelle release di Google Distributed Cloud 1.12.7, 1.13.6,
1.14.3 e nelle release successive. Queste release più recenti utilizzano la versione etcd
3.4.21. Tutte le versioni precedenti di Google Distributed Cloud sono interessate dai
questo problema.
Soluzione
Se non puoi eseguire l'upgrade immediatamente, puoi ridurre il rischio di un guasto del cluster riducendo il numero di nodi nel cluster. Rimuovi
i nodi finché la metrica etcd_network_client_grpc_sent_bytes_total
non è inferiore a 300 MB/s.
Per visualizzare questa metrica in Metrics Explorer:
- Vai a Metrics Explorer nella console Google Cloud:
Vai a Esplora metriche
- Seleziona la scheda Configurazione.
- Espandi Seleziona una metrica, inserisci
Kubernetes Container
nella barra dei filtri e utilizza i sottomenu per selezionare la metrica:
- Nel menu Risorse attive, seleziona Container Kubernetes.
- Nel menu Categorie metriche attive, seleziona Anthos.
- Nel menu Metriche attive, seleziona
etcd_network_client_grpc_sent_bytes_total .
- Fai clic su Applica.
|
Upgrade, aggiornamenti |
1.10, 1.11, 1.12, 1.13 e 1.14 |
GKE Identity Service può causare latenze del piano di controllo
Durante i riavvii o gli upgrade del cluster, GKE Identity Service può
sovraccaricato da traffico costituito da token JWT scaduti inoltrati da
kube-apiserver al servizio di identità GKE tramite
webhook di autenticazione. Anche se GKE Identity Service non rientra in un loop di arresto anomalo, non risponde e smette di gestire ulteriori richieste.
Questo problema porta a una latenza maggiore del piano di controllo.
Questo problema è stato risolto nelle seguenti release di Google Distributed Cloud:
- 1.12.6 e versioni successive
- 1.13.6+
- 1.14.2 e versioni successive
Per determinare se il problema ti riguarda, procedi nel seguente modo:
- Controlla se l'endpoint di GKE Identity Service è raggiungibile esternamente:
curl -s -o /dev/null -w "%{http_code}" \
-X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
Sostituisci CLUSTER_ENDPOINT
con il VIP e la porta del bilanciatore del carico del piano di controllo per il tuo
cluster (ad esempio 172.16.20.50:443 ).
Se il problema riguarda il tuo account, il comando restituisce un 400
codice di stato. Se la richiesta scade, riavvia il pod ais e
esegui di nuovo il comando curl per vedere se il problema si risolve. Se
ricevi il codice di stato 000 , il problema è stato risolto e
hai finito. Se ricevi ancora un codice di stato 400 ,
Il server HTTP di GKE Identity Service non viene avviato. In questo caso, continua.
- Controlla i log di GKE Identity Service e kube-apiserver:
- Controlla il log di GKE Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
Se il log contiene una voce come la seguente, il problema ti riguarda:
I0811 22:32:03.583448 32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
- Controlla i log di
kube-apiserver per i tuoi cluster:
Nei comandi seguenti, KUBE_APISERVER_POD è il nome del pod kube-apiserver nel cluster specificato.
Cluster di amministrazione:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n kube-system KUBE_APISERVER_POD kube-apiserver
Cluster utente:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver
Se i log kube-apiserver contengono voci come le seguenti,
hai questo problema:
E0811 22:30:22.656085 1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"
Soluzione alternativa
Se non riesci ad aggiornare immediatamente i cluster per applicare la correzione, puoi identificare e riavviare i pod in questione come soluzione alternativa:
- Aumenta il livello di dettaglio di GKE Identity Service a 9:
kubectl patch deployment ais -n anthos-identity-service --type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
"value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
--kubeconfig KUBECONFIG
- Verifica se nel log del servizio di identità GKE è presente il contesto del token non valido:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
- Per ottenere il payload associato al contesto di ciascun token non valido,
analizza ogni secret dell'account di servizio correlato con il seguente comando:
kubectl -n kube-system get secret SA_SECRET \
--kubeconfig KUBECONFIG \
-o jsonpath='{.data.token}' | base64 --decode
- Per decodificare il token e visualizzare il nome e lo spazio dei nomi del pod di origine, copia
il token nel debugger all'indirizzo jwt.io.
- Riavvia i pod identificati dai token.
|
Operazione |
1.8, 1.9, 1.10 |
Il problema dell'aumento della memoria utilizzata dai pod di manutenzione etcd
I pod di manutenzione etcd che utilizzano l'immagine etcddefrag:gke_master_etcddefrag_20210211.00_p0 sono interessati. Il contenitore "etcddefrag" apre una nuova connessione al server etcd durante ogni ciclo di deframmentazione e le vecchie connessioni non vengono ripulite.
Soluzione:
Opzione 1: esegui l'upgrade alla versione più recente della patch dalla versione 1.8 alla versione 1.11 che contiene la correzione.
Opzione 2: se utilizzi una versione patch precedente alla 1.9.6 e alla 1.10.3, devi fare lo scale down del pod etcd-maintenance per l'amministratore e il cluster utente:
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Operazione |
1,9, 1,10, 1,11, 1,12 e 1,13 |
Non perdere i controlli di integrità dei pod del piano di controllo del cluster utente
Sia il controller di integrità del cluster sia il comando gkectl diagnose cluster eseguono una serie di controlli di integrità, inclusi quelli dei pod negli spazi dei nomi. Tuttavia, iniziano a saltare per errore i pod del piano di controllo utente. Se utilizzi la modalità v2 del piano di controllo, questa operazione non influirà sul cluster.
Soluzione:
Questa operazione non influirà sulla gestione dei carichi di lavoro o dei cluster. Se vuoi controllare lo stato dei pod del piano di controllo, puoi eseguire i seguenti comandi:
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Upgrade, aggiornamenti |
1.6+, 1.7+ |
Gli upgrade dei cluster di amministrazione 1.6 e 1.7 potrebbero essere interessati da k8s.gcr.io -> Reindirizzamento registry.k8s.io
Kubernetes ha reindirizzato il traffico da k8s.gcr.io a registry.k8s.io il 20/03/2023. In Google Distributed Cloud 1.6.x e 1.7.x, gli upgrade del cluster di amministrazione utilizzano l'immagine container k8s.gcr.io/pause:3.2 . Se utilizzi un proxy per la tua workstation di amministrazione e il proxy non consente registry.k8s.io e l'immagine del contenitore k8s.gcr.io/pause:3.2 non viene memorizzata nella cache localmente, gli upgrade del cluster di amministrazione non andranno a buon fine durante il recupero dell'immagine del contenitore.
Soluzione:
Aggiungi registry.k8s.io alla lista consentita del proxy per la tua workstation di amministrazione.
|
Networking |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Errore di convalida di Seesaw durante la creazione del bilanciatore del carico
gkectl create loadbalancer non riesce con il seguente messaggio di errore:
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host
Questo accade perché il file del gruppo Seesaw esiste già. Inoltre, il controllo preliminare
tenta di convalidare un bilanciatore del carico seesaw inesistente.
Soluzione:
Rimuovi il file del gruppo Seesaw esistente per questo cluster. Il nome del file
è seesaw-for-gke-admin.yaml per il cluster di amministrazione e
seesaw-for-{CLUSTER_NAME}.yaml per un cluster utente.
|
Networking |
1,14 |
Timeout dell'applicazione causati da errori di inserimento della tabella di connessione
La versione 1.14 di Google Distributed Cloud è soggetta a netfilter
errori di inserimento nella tabella di monitoraggio delle connessioni (conntrack) durante l'utilizzo
Immagini del sistema operativo Ubuntu o COS. I fallimenti di inserimento comportano timeout randomizzati
dell'applicazione e possono verificarsi anche quando la tabella conntrack ha spazio
per nuove voci. Gli errori sono causati da modifiche nel
kernel 5.15 e versioni successive che limitano le inserzioni di tabelle in base alla lunghezza
della catena.
Per verificare se il problema riguarda il tuo sistema, puoi controllare le statistiche del sistema di monitoraggio delle connessioni in-kernel su ogni nodo con il seguente comando:
sudo conntrack -S
La risposta ha questo aspetto:
cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...
Se un valore chaintoolong nella risposta è un numero diverso da zero, il problema ti riguarda.
Soluzione
La mitigazione a breve termine è quella di aumentare le dimensioni di entrambi
tabella hash (nf_conntrack_buckets ) e netfilter
tabella di monitoraggio della connessione (nf_conntrack_max ). Utilizza la
su ciascun nodo del cluster per aumentare le dimensioni
tabelle:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Sostituisci TABLE_SIZE con la nuova dimensione in byte. Il valore predefinito della dimensione della tabella è 262144 . Ti consigliamo di impostare
pari a 65.536 volte il numero di core sul nodo. Ad esempio:
se il tuo nodo ha otto core, imposta la dimensione della tabella su 524288 .
|
Networking |
1.13.0-1.13.2 |
Ciclo di arresti anomali di calico-typha o anetd-operator sui nodi Windows con Controlplane v2
Con la versione 2 del piano di controllo o con un nuovo modello di installazione, è possibile che calico-typha o anetd-operator vengano pianificati sui nodi Windows e riscontrino un ciclo di arresto anomalo.
Il motivo è che i due implementazioni tollerano tutti gli elementi dannosi, incluso l'elemento dannoso del nodo Windows.
Soluzione:
Esegui l'upgrade alla versione 1.13.3 o successiva oppure esegui i seguenti comandi per modificare il deployment di "calico-typha" o "anetd-operator":
# If dataplane v2 is not used.
kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
# If dataplane v2 is used.
kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
Rimuovi quanto segue spec.template.spec.tolerations :
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
E aggiungi la seguente tolleranza:
- key: node-role.kubernetes.io/master
operator: Exists
|
Configurazione |
1.14.0-1.14.2 |
Impossibile caricare il file delle credenziali del registry privato del cluster utente
Potresti non essere in grado di creare un cluster utente se specifichi la
Sezione privateRegistry con credenziale fileRef .
Il preflight potrebbe non riuscire con il seguente messaggio:
[FAILURE] Docker registry access: Failed to login.
Soluzione:
- Se non intendevi specificare il campo o se vuoi utilizzare lo stesso
credenziale di registro privata come cluster di amministrazione, puoi semplicemente rimuovere
commenta la sezione
privateRegistry nel tuo cluster utente
di configurazione del deployment.
- Se vuoi utilizzare una credenziale del registry privato specifica per il tuo
cluster di utenti, puoi specificare temporaneamente la sezione
privateRegistry
nel seguente modo:
privateRegistry:
address: PRIVATE_REGISTRY_ADDRESS
credentials:
username: PRIVATE_REGISTRY_USERNAME
password: PRIVATE_REGISTRY_PASSWORD
caCertPath: PRIVATE_REGISTRY_CACERT_PATH
(NOTA: si tratta solo di una correzione temporanea e questi campi sono già
è deprecato, ti consigliamo di utilizzare il file delle credenziali quando esegui l'upgrade alla versione 1.14.3 e successive).
|
Operazioni |
1,10 e oltre |
Cloud Service Mesh e altri mesh di servizi non compatibili con Dataplane v2
Dataplane V2 prende il controllo del bilanciamento del carico e crea un socket del kernel invece di un DNAT basato su pacchetto. Ciò significa che Cloud Service Mesh
non può eseguire l'ispezione dei pacchetti poiché il pod è ignorato e non utilizza mai IPTables.
Questo si manifesta in modalità libera di kube-proxy con perdita di connettività o routing errato del traffico per i servizi con Cloud Service Mesh, poiché il sidecar non può eseguire l'ispezione dei pacchetti.
Questo problema è presente in tutte le versioni di Google Distributed Cloud 1.10, tuttavia alcune versioni più recenti della 1.10 (1.10.2+) hanno una soluzione alternativa.
Soluzione:
Esegui l'upgrade alla versione 1.11 per una compatibilità completa oppure, se esegui 1.10.2 o versioni successive, esegui:
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
Aggiungi bpf-lb-sock-hostns-only: true alla configmap e riavvia il daemonset anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
|
Archiviazione |
1.12 e versioni successive, 1.13.3 |
kube-controller-manager potrebbe scollegare i volumi permanenti
forzatamente dopo 6 minuti
kube-controller-manager potrebbe scadere durante il distacco
dei PV/PVC dopo 6 minuti e scollegarli forzatamente. Log dettagliati
da kube-controller-manager mostra eventi simili a
seguenti:
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
Per verificare il problema, accedi al nodo ed esegui questi comandi:
# See all the mounting points with disks
lsblk -f
# See some ext4 errors
sudo dmesg -T
Nel log kubelet vengono visualizzati errori come i seguenti:
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
Soluzione:
Connettiti al nodo interessato tramite SSH e riavvialo.
|
Upgrade, aggiornamenti |
1,12 e versioni successive, 1,13 e versioni successive, 1,14 e versioni successive |
L'upgrade del cluster si blocca se viene utilizzato un driver CSI di terze parti
Potresti non essere in grado di eseguire l'upgrade di un cluster se utilizzi una CSI di terze parti
conducente. Il comando gkectl cluster diagnose potrebbe restituire i valori
il seguente errore:
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
Soluzione:
Esegui l'upgrade utilizzando l'opzione --skip-validation-all .
|
Operazione |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+ |
gkectl repair admin-master crea la VM principale di amministrazione
senza eseguire l'upgrade della versione hardware della VM
Il nodo principale amministrativo creato tramite gkectl repair admin-master
potrebbe utilizzare una versione hardware della VM inferiore a quella prevista. Quando si verifica questo problema,
visualizzerai l'errore dall'gkectl diagnose cluster
report.
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.
Soluzione:
Arresta il nodo master amministrativo, segui
https://kb.vmware.com/s/article/1003746
per eseguire l'upgrade del nodo alla versione prevista descritta nel messaggio
di errore e poi avvia il nodo.
|
Sistema operativo |
1.10 e versioni successive, 1.11 e versioni successive, 1.12 e versioni successive, 1.13 e versioni successive, 1.14 e versioni successive, 1.15 e versioni successive, 1.16 e versioni successive |
La VM rilascia il lease DHCP all'arresto/al riavvio inaspettatamente,
comportano modifiche IP
In systemd v244, systemd-networkd ha un
modifica del comportamento predefinito
configurazione KeepConfiguration . Prima di questa modifica,
le VM non inviavano un messaggio di rilascio del lease DHCP al server DHCP al
riavvio o allo spegnimento. Dopo questa modifica, le VM inviano un messaggio di questo tipo e
restituiscono gli IP al server DHCP. Di conseguenza, l'IP rilasciato potrebbe
riassegnato a una VM diversa e/o potrebbe essere assegnato
VM, con conseguente conflitto di IP (a livello di Kubernetes, non a livello di vSphere)
e/o alla modifica IP sulle VM, che possono interrompere i cluster in vari modi.
Ad esempio, potresti notare i seguenti sintomi.
- L'interfaccia utente di vCenter mostra che nessuna VM utilizza lo stesso IP, ma
kubectl get
nodes -o wide restituisce nodi con IP duplicati.
NAME STATUS AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node1 Ready 28h v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
node2 NotReady 71d v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
- Impossibile avviare i nuovi nodi a causa di un errore
calico-node
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
Soluzione:
Esegui il deployment del seguente DaemonSet sul cluster per ripristinare la
modifica del comportamento predefinito di systemd-networkd . Le VM che eseguono
questo DaemonSet non rilascerà gli IP per il server DHCP
arresta/riavvia. Gli IP verranno liberati automaticamente dal server DHCP
alla scadenza dei leasing.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-dhcp-on-stop
spec:
selector:
matchLabels:
name: set-dhcp-on-stop
template:
metadata:
labels:
name: set-dhcp-on-stop
spec:
hostIPC: true
hostPID: true
hostNetwork: true
containers:
- name: set-dhcp-on-stop
image: ubuntu
tty: true
command:
- /bin/bash
- -c
- |
set -x
date
while true; do
export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
if (( $? != 0 )) ; then
echo "Setting KeepConfiguration=dhcp-on-stop"
sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
cat "${CONFIG}"
chroot /host systemctl restart systemd-networkd
else
echo "KeepConfiguration=dhcp-on-stop has already been set"
fi;
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "5m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
tolerations:
- operator: Exists
effect: NoExecute
- operator: Exists
effect: NoSchedule
|
Operazione, upgrade, aggiornamenti |
1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Chiave dell'account di servizio di accesso ai componenti cancellata dopo il cluster di amministrazione
Upgrade eseguito dalla versione 1.11.x
Questo problema interessa solo i cluster di amministrazione di cui è stato eseguito l'upgrade
da 1.11.x e non influisce sui cluster di amministrazione appena creati dopo
1.12.
Dopo l'upgrade di un cluster da 1.11.x a 1.12.x,
Campo component-access-sa-key in
admin-cluster-creds secret verrà cancellato e sarà vuoto.
Per verificarlo, esegui questo comando:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
Se trovi che l'output è vuoto significa che la chiave è stata cancellata.
Dopo l'eliminazione della chiave dell'account di servizio di accesso ai componenti,
l'installazione di nuovi cluster utente o l'upgrade di quelli esistenti non andrà a buon fine. Di seguito sono elencati alcuni messaggi di errore che potresti ricevere:
- Errore preflight lento con convalida con messaggio di errore:
"Failed
to create the test VMs: failed to get service account key: service
account is not configured."
- Preparazione entro il giorno
gkectl prepare non riuscita. Messaggio di errore:
"Failed to prepare OS images: dialing: unexpected end of JSON
input"
- Se stai eseguendo l'upgrade di un cluster utente 1.13 utilizzando la console Google Cloud o l'interfaccia a riga di comando gcloud, quando esegui
gkectl update admin --enable-preview-user-cluster-central-upgrade per eseguire il deployment del controller della piattaforma di upgrade, il comando non va a buon fine con il messaggio "failed to download bundle to disk: dialing:
unexpected end of JSON input" (puoi visualizzare questo messaggio nel campo status nell'output di kubectl --kubeconfig
ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml ).
Soluzione:
Aggiungi nuovamente la chiave dell'account di servizio di accesso al componente al segreto
eseguendo manualmente il seguente comando:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
|
Operazione |
1.13.0 e versioni successive, 1.14.0 e versioni successive |
Il gestore della scalabilità automatica dei cluster non funziona quando è abilitato Controlplane V2
Per i cluster utente creati con Controlplane V2 o con un nuovo modello di installazione, i pool di nodi con la scalabilità automatica abilitata utilizzano sempre il rispettivo autoscaling.minReplicas nel cluster user-cluster.yaml. Il log del pod cluster-autoscaler mostra anche che non sono in stato corretto.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
TIMESTAMP 1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
Puoi trovare il pod del gestore della scalabilità automatica del cluster eseguendo i seguenti comandi.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c 4648017n 48076Ki 30s
Soluzione:
Disabilita la scalabilità automatica in tutti i pool di nodi con "gkectl update cluster" fino all'upgrade a una versione con la correzione
|
Installazione |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
Il CIDR non è consentito nel file del blocco IP
Quando gli utenti utilizzano CIDR nel file del blocco IP, la convalida della configurazione non va a buon fine con il seguente errore:
- Validation Category: Config Check
- [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
Soluzione:
Includi singoli IP nel file dei blocchi IP fino all'aggiornamento a una versione con la correzione: 1.12.5, 1.13.4, 1.14.1+.
|
Upgrade, aggiornamenti |
1.14.0-1.14.1 |
L'aggiornamento del tipo di immagine del sistema operativo in admin-cluster.yaml non attende la nuova creazione delle macchine del piano di controllo dell'utente
Quando aggiorna il tipo di immagine del sistema operativo del piano di controllo in admin-cluster.yaml e se il cluster utente corrispondente è stato creato tramite Controlplane V2, le macchine del piano di controllo utente potrebbero non terminare la riproduzione al termine del comando gkectl.
Soluzione:
Al termine dell'aggiornamento, continua ad attendere che anche le macchine del piano di controllo utente terminino la loro creazione monitorando i tipi di immagini del sistema operativo dei nodi utilizzando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide . Ad esempio, se esegui l'aggiornamento da Ubuntu a COS, dobbiamo attendere che tutte le macchine del piano di controllo passino completamente da Ubuntu a COS anche dopo il completamento del comando di aggiornamento.
|
Operazione |
1,10, 1,11, 1,12, 1,13 e 1.14.0 |
Errori di creazione o eliminazione dei pod a causa di un problema con il token di autenticazione dell'account di servizio Calico CNI
Un problema con Calico in Google Distributed Cloud 1.14.0
determina la mancata riuscita della creazione e dell'eliminazione del pod con il seguente messaggio di errore in
l'output di kubectl describe pods :
error getting ClusterInformation: connection is unauthorized: Unauthorized
Questo problema si verifica solo 24 ore dopo la creazione o l'upgrade del cluster a 1.14 utilizzando Calico.
I cluster di amministrazione utilizzano sempre Calico, mentre per il cluster utente è presente un campo di configurazione "enableDataPlaneV2" in user-cluster.yaml. Se questo campo è impostato su "false" o non è specificato, significa che utilizzi Calico nel cluster utente.
Il contenitore install-cni dei nodi crea un file kubeconfig con un
token valido per 24 ore. Questo token deve essere rinnovato periodicamente dal pod calico-node . Il pod calico-node
non è in grado di rinnovare il token perché non ha accesso alla directory
contenente il file kubeconfig sul nodo.
Soluzione:
Questo problema è stato risolto in Google Distributed Cloud versione 1.14.1. Aggiorna a
questa o una versione successiva.
Se non puoi eseguire l'upgrade immediatamente, applica la seguente patch al calico-node DaemonSet nel cluster di amministrazione e utente:
kubectl -n kube-system get daemonset calico-node \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -
kubectl -n kube-system get daemonset calico-node \
--kubeconfig USER_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
Sostituisci quanto segue:
ADMIN_CLUSTER_KUBECONFIG : il percorso
del file kubeconfig del cluster di amministrazione.
USER_CLUSTER_CONFIG_FILE : il percorso
del file di configurazione del cluster utente.
|
Installazione |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
La convalida dei blocchi IP non va a buon fine quando si utilizza CIDR
La creazione del cluster non va a buon fine nonostante l'utente disponga della configurazione corretta. L'utente vede la creazione non riuscita perché il cluster non ha un numero sufficiente di IP.
Soluzione:
Suddividi i CIDR in più blocchi CIDR più piccoli, ad esempio 10.0.0.0/30 diventa 10.0.0.0/31, 10.0.0.2/31 . Se ci sono CIDR N+1, dove N è il numero di nodi nel cluster, questo dovrebbe essere sufficiente.
|
Operazione, upgrade, aggiornamenti |
1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6 |
Il backup del cluster di amministrazione non include le chiavi e la configurazione della crittografia dei secret sempre attiva
Quando la funzionalità di crittografia dei secret sempre attiva è abilitata insieme al backup del cluster, il backup del cluster amministrativo non include le chiavi di crittografia e la configurazione richieste dalla funzionalità di crittografia dei secret sempre attiva. Di conseguenza, la riparazione del master amministratore con questo backup utilizzando gkectl repair admin-master --restore-from-backup causa il seguente errore:
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Soluzione alternativa:
- Utilizza il programma binario gkectl dell'ultima versione della patch disponibile per la versione secondaria corrispondente per eseguire il backup del cluster di amministrazione dopo le operazioni critiche del cluster. Ad esempio, se il cluster esegue una versione 1.10.2, utilizza il programma binario gkectl 1.10.5 per eseguire un backup manuale del cluster di amministrazione come descritto in Eseguire il backup e ripristinare un cluster di amministrazione con gkectl.
|
Operazione, upgrade, aggiornamenti |
1,10 e oltre |
Ricreare la VM master di amministrazione con un nuovo disco di avvio (ad es. gkectl repair admin-master ) non riuscirà se la funzionalità di crittografia dei secret sempre attivi è abilitata utilizzando il comando "gkectl update".
Se la funzionalità di crittografia dei secret sempre attivi non viene abilitata al momento della creazione del cluster, ma viene abilitata in un secondo momento utilizzando l'operazione gkectl update , gkectl repair admin-master non riesce a riparare il nodo del piano di controllo del cluster di amministrazione. Ti consigliamo di abilitare la funzionalità di crittografia dei secret sempre attivi al momento della creazione del cluster. Al momento non è prevista alcuna mitigazione.
|
Upgrade, aggiornamenti |
1,10 |
L'upgrade del primo cluster utente da 1.9 a 1.10 ricrea i nodi in altri cluster utente
L'upgrade del primo cluster utente dalla versione 1.9 alla versione 1.10 potrebbe ricreare nodi in altri cluster utente all'interno dello stesso cluster di amministrazione. La ricreazione viene eseguita in modo graduale.
disk_label è stato rimosso da MachineTemplate.spec.template.spec.providerSpec.machineVariables e questo ha attivato inaspettatamente un aggiornamento per tutti i MachineDeployment .
Soluzione:
Visualizza i passaggi per la soluzione alternativa
|
Upgrade, aggiornamenti |
1.10.0 |
Docker si riavvia di frequente dopo l'upgrade del cluster
L'upgrade del cluster utente alla versione 1.10.0 potrebbe causare frequenti riavvii di Docker.
Puoi rilevare questo problema eseguendo kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG
Una condizione del nodo indica se Docker si riavvia di frequente. Ecco un esempio di output:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Per comprendere la causa principale, devi accedere tramite SSH al nodo che presenta il sintomo ed eseguire comandi come sudo journalctl --utc -u docker o sudo journalctl -x
Soluzione:
|
Upgrade, aggiornamenti |
1.11, 1.12 |
I componenti di GMP di cui è stato eseguito il deployment autonomo non vengono conservati dopo l'upgrade alla versione 1.12
Se utilizzi una versione di Google Distributed Cloud precedente alla 1.12 e hai configurato manualmente i componenti Prometheus gestito da Google (GMP) nello spazio dei nomi gmp-system
per il tuo cluster, i componenti non vengono conservati quando
esegui l'upgrade alla versione 1.12.x.
A partire dalla versione 1.12, i componenti GMP nello spazio dei nomi gmp-system e nei CRD sono gestiti dall'oggetto stackdriver , con il flag enableGMPForApplications impostato su false per impostazione predefinita. Se esegui il deployment manuale dei componenti GMP nello spazio dei nomi prima di eseguire l'upgrade alla versione 1.12, le risorse verranno eliminate entro il giorno stackdriver .
Soluzione:
|
Operazione |
1.11, 1.12, 1.13.0 - 1.13.1 |
Oggetti ClusterAPI mancanti nello scenario system del cluster snapshot
Nello scenario system , lo snapshot del cluster non include risorse nello spazio dei nomi default .
Tuttavia, alcune risorse Kubernetes, come gli oggetti API Cluster che si trovano in questo spazio dei nomi, contengono informazioni utili per il debug. Lo snapshot del cluster dovrebbe includerle.
Soluzione:
Puoi eseguire manualmente i seguenti comandi per raccogliere le informazioni di debug.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
dove:
USER_CLUSTER_KUBECONFIG è la classe di archiviazione
kubeconfig.
|
Upgrade, aggiornamenti |
1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1 |
Eliminazione del cluster utente bloccata allo svuotamento dei nodi per la configurazione vSAN
Durante l'eliminazione, l'aggiornamento o l'upgrade di un cluster utente, lo svuotamento dei nodi potrebbe bloccarsi nei seguenti scenari:
- Il cluster di amministrazione utilizza il driver CSI vSphere su vSAN dalla versione 1.12.x e
- Non sono presenti oggetti PVC/PV creati da plug-in vSphere in-tree nel cluster di amministrazione e utente.
Per identificare il sintomo, esegui il comando seguente:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Ecco un esempio di messaggio di errore del comando precedente:
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols è la directory predefinita per il driver in-tree di vSphere. Quando non vengono creati oggetti PVC/PV, potresti riscontrare un bug che indica che lo svuotamento dei nodi sarà bloccato a trovare kubevols , poiché l'implementazione corrente presuppone che kubevols esista sempre.
Soluzione:
Crea la directory kubevols nel datastore in cui viene creato il nodo. Questo valore è definito nel campo vCenter.datastore dei file user-cluster.yaml o admin-cluster.yaml .
|
Configurazione |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14 |
Cluster Autoscaler clusterrolebinding e clusterrole vengono eliminati dopo l'eliminazione di un cluster utente.
All'eliminazione del cluster utente, vengono eliminati anche i valori clusterrole e clusterrolebinding corrispondenti per il gestore della scalabilità automatica del cluster. Questo interessa tutti gli altri cluster utente sullo stesso cluster di amministrazione con il gestore della scalabilità automatica dei cluster abilitato. Questo perché lo stesso clusterrole e clusterrolebinding vengono utilizzati per tutti i pod del gestore della scalabilità automatica del cluster nello stesso cluster di amministrazione.
I sintomi sono i seguenti:
- Log di
cluster-autoscaler
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del
cluster di amministrazione.
Ecco un esempio di messaggi di errore che potresti visualizzare:
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463 1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494 1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
Soluzione:
Visualizza i passaggi per la soluzione alternativa
Verifica se clusterrole e clusterrolebinding sono mancanti nel cluster di amministrazione
-
kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
-
kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
Applica i seguenti clusterrole e clusterrolebinding al cluster di amministrazione se mancanti. Aggiungi i soggetti dell'account di servizio al clusterrolebinding per ogni cluster utente.
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
resources: ["clusters"]
verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
resources: ["onpremuserclusters"]
verbs: ["get", "list", "watch"]
- apiGroups:
- coordination.k8s.io
resources:
- leases
resourceNames: ["cluster-autoscaler"]
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
- ""
resources:
- pods
verbs: ["get", "list", "watch"]
- apiGroups:
- ""
resources:
- pods/eviction
verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["daemonsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
resources: ["poddisruptionbudgets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cluster-autoscaler-status"]
verbs: ["get", "update", "patch", "delete"]
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: cluster-autoscaler
name: cluster-autoscaler
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-autoscaler
subjects:
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_1
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_2
...
|
Configurazione |
1,7; 1,8; 1,9; 1,10; 1,11; 1,12; 1,13 |
il cluster di amministrazione cluster-health-controller e vsphere-metrics-exporter non funzionano dopo l'eliminazione del cluster utente
All'eliminazione del cluster utente viene eliminato anche clusterrole , con il risultato che la riparazione automatica e l'esportatore delle metriche vSphere non funzionano
I sintomi sono i seguenti:
cluster-health-controller log
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del
cluster di amministrazione.
Ecco un esempio di messaggi di errore che potrebbero essere visualizzati:
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
vsphere-metrics-exporter log
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
dove ADMIN_CLUSTER_KUBECONFIG è il cluster di amministrazione
kubeconfig.
Ecco un esempio di messaggi di errore che potresti visualizzare:
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
Soluzione:
Visualizza i passaggi della soluzione alternativa
Applica il seguente YAML al cluster di amministrazione
- Per vsphere-metrics-exporter
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: vsphere-metrics-exporter
rules:
- apiGroups:
- cluster.k8s.io
resources:
- clusters
verbs: [get, list, watch]
- apiGroups:
- ""
resources:
- nodes
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: vsphere-metrics-exporter
name: vsphere-metrics-exporter
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vsphere-metrics-exporter
subjects:
- kind: ServiceAccount
name: vsphere-metrics-exporter
namespace: kube-system
- Per cluster-health-controller
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-health-controller-role
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
|
Configurazione |
1.12.1-1.12.3, 1.13.0-1.13.2 |
gkectl check-config non riesce a convalidare l'immagine del sistema operativo
Un problema noto che potrebbe causare l'errore gkectl check-config senza eseguire gkectl prepare . Questo non è chiaro perché ti suggeriamo di eseguire il comando prima di eseguire gkectl prepare
Il sintomo è che il comando gkectl check-config non andrà a buon fine con il
seguente messaggio di errore:
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}
Soluzione:
Opzione 1: esegui gkectl prepare per caricare le immagini del sistema operativo mancanti.
Opzione 2: utilizza gkectl check-config --skip-validation-os-images per saltare la convalida delle immagini del sistema operativo.
|
Upgrade, aggiornamenti |
1.11, 1.12, 1.13 |
gkectl update admin/cluster non riesce ad aggiornare i gruppi anti-affinità
Un problema noto che potrebbe causare l'errore gkectl update admin/cluster durante l'aggiornamento di anti affinity groups .
Il sintomo è che il comando gkectl update non andrà a buon fine con il
seguente messaggio di errore:
Waiting for machines to be re-deployed... ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition
Soluzione:
Visualizza i passaggi per la soluzione alternativa
Affinché l'aggiornamento venga applicato, le macchine devono essere ricreate after l'aggiornamento non riuscito.
Per l'aggiornamento del cluster di amministrazione, è necessario ricreare i nodi master utente e dei componenti aggiuntivi di amministrazione
Per l'aggiornamento del cluster utente, è necessario ricreare i nodi worker utente
Per ricreare i nodi worker dell'utente
Opzione 1 Segui la procedura per aggiornare un pool di nodi e modifica la CPU o la memoria per attivare una ricostituzione graduale dei nodi.
Opzione 2 Usa kubectl delete per ricreare le macchine una alla volta
kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG
Per ricreare i nodi master utente
Opzione 1 Segui il piano di controllo di ridimensionamento e modifica la CPU o la memoria per attivare una ricreazione in sequenza dei nodi.
Opzione 2 Usa kubectl delete per ricreare le macchine una alla volta
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
Per ricreare i nodi dei componenti aggiuntivi di amministrazione
Utilizza kubectl delete per ricreare le macchine una alla volta
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
Installazione, upgrade, aggiornamenti |
1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0 |
La registrazione dei nodi non riesce durante la creazione, l'upgrade, l'aggiornamento
riparazione automatica dei nodi, quando ipMode.type è static e
il nome host configurato nel
Il file dei blocchi IP contiene uno
o più cicli. In questo caso, le richieste di firma del certificato (CSR) per un
nodo non vengono approvate automaticamente.
Per visualizzare le CSR in attesa per un nodo, esegui il seguente comando:
kubectl get csr -A -o wide
Controlla se nei seguenti log sono presenti messaggi di errore:
- Visualizza i log nel cluster di amministrazione per il
contenitore
clusterapi-controller-manager nel
pod clusterapi-controllers :
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n kube-system \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
- Per visualizzare gli stessi log nel cluster utente, esegui il seguente
comando:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
where:
- ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del
cluster di amministrazione.
- USER_CLUSTER_NAME è il nome del cluster utente.
Ecco un esempio di messaggi di errore che potresti visualizzare: "msg"="failed
to validate token id" "error"="failed to find machine for node
node-worker-vm-1" "validate"="csr-5jpx9"
- Visualizza i log
kubelet sul nodo problematico:
journalctl --u kubelet
Ecco un esempio di messaggi di errore che potrebbero essere visualizzati: "Error getting
node" err="node \"node-worker-vm-1\" not found"
Se specifichi un nome di dominio nel campo del nome host di un file di blocchi IP,
tutti i caratteri successivi al primo punto verranno ignorati. Ad esempio, se
specifichi il nome host come bob-vm-1.bank.plc , il nome host e il nome del nodo della VM verranno impostati su bob-vm-1 .
Quando la verifica dell'ID nodo è abilitata, l'approvatore CSR confronta
nodo con il nome host nella specifica Macchina e la riconciliazione non riesce
il nome. L'approvatore rifiuta la CSR e il bootstrap del nodo non riesce.
Soluzione:
Cluster di utenti
Per disattivare la verifica dell'ID nodo, segui questi passaggi:
- Aggiungi i seguenti campi al file di configurazione del cluster utente:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- Salva il file e aggiorna il cluster utente eseguendo questo comando
:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Sostituisci quanto segue:
ADMIN_CLUSTER_KUBECONFIG : il percorso
del file kubeconfig del cluster di amministrazione.
USER_CLUSTER_CONFIG_FILE : il percorso
del file di configurazione del cluster utente.
Cluster di amministrazione
- Apri la risorsa personalizzata
OnPremAdminCluster per
modifica:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit onpremadmincluster -n kube-system
- Aggiungi la seguente annotazione alla risorsa personalizzata:
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
- Modifica il manifest
kube-controller-manager nel piano di controllo del
cluster di amministrazione:
- Esegui SSH sul
nodo del control plane del cluster di amministrazione.
- Apri il manifest
kube-controller-manager per
modifica:
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
- Trova l'elenco di
controllers :
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Aggiorna questa sezione come mostrato di seguito:
--controllers=*,bootstrapsigner,tokencleaner
- Apri il controller dell'API Deployment Cluster per la modifica:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit deployment clusterapi-controllers -n kube-system
- Modifica i valori di
node-id-verification-enabled e
node-id-verification-csr-signing-enabled in
false :
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
|
Installazione, upgrade, aggiornamenti |
1.11.0-1.11.4 |
Errore di avvio della macchina del piano di controllo amministratore causato da un registro privato
bundle di certificati
La creazione/l'upgrade del cluster di amministrazione rimane bloccata nel seguente log per sempre
e alla fine scade il tempo di attesa:
Waiting for Machine gke-admin-master-xxxx to become ready...
Il log del controller dell'API Cluster nello
snapshot del cluster esterno include il seguente log:
Invalid value 'XXXX' specified for property startup-data
Ecco un esempio di percorso file per il log del controller API Cluster:
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
VMware has a 64k vApp property size limit. In the identified versions,
the data passed via vApp property is close to the limit. When the private
registry certificate contains a certificate bundle, it may cause the final
data to exceed the 64k limit.
Workaround:
Only include the required certificates in the private registry
certificate file configured in privateRegistry.caCertPath in
the admin cluster config file.
Or upgrade to a version with the fix when available.
|
Networking |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayNodes marked unhealthy from concurrent
status update conflict
In networkgatewaygroups.status.nodes , some nodes switch
between NotHealthy and Up .
Logs for the ang-daemon Pod running on that node reveal
repeated errors:
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}
Lo stato NotHealthy impedisce al controller di
e assegnare IP mobili aggiuntivi al nodo. Ciò può comportare un maggiore carico su altri nodi o una mancanza di ridondanza per l'alta disponibilità.
In caso contrario, l'attività Dataplane non ne è influenzata.
La contesa sull'oggetto networkgatewaygroup causa il fallimento di alcuni aggiornamenti dello stato a causa di un errore nella gestione del nuovo tentativo. Se sono troppe
aggiornamenti dello stato non riusciti, ang-controller-manager vede il nodo come
oltre il limite di tempo di heartbeat e contrassegna il nodo NotHealthy .
L'errore relativo alla gestione dei nuovi tentativi è stato risolto nelle versioni successive.
Soluzione:
Esegui l'upgrade a una versione fissa, se disponibile.
|
Upgrade, aggiornamenti |
1.12.0-1.12.2, 1.13.0 |
Una condizione di gara blocca l'eliminazione di oggetti macchina durante un aggiornamento o un upgrade
Un problema noto che potrebbe causare l'upgrade o l'upgrade del cluster
è bloccato in attesa dell'eliminazione dell'oggetto della vecchia macchina. Questo perché
impossibile rimuovere il finalizzatore dall'oggetto machine. Ciò influisce su qualsiasi operazione di aggiornamento graduale per i pool di nodi.
Il sintomo è che il comando gkectl scade con
messaggio di errore seguente:
E0821 18:28:02.546121 61942 console.go:87] Exit with error:
E0821 18:28:02.546184 61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Nei log del pod clusterapi-controller , gli errori sono simili ai seguenti:
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
-c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
| grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993 1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
L'errore si ripete per la stessa macchina per diversi minuti per le esecuzioni riuscite anche senza questo problema. Nella maggior parte dei casi può essere completato rapidamente, ma in alcuni rari casi può rimanere bloccato in questa condizione di gara per diverse ore.
Il problema è che la VM di base è già stata eliminata in vCenter, ma
non è possibile rimuovere l'oggetto macchina corrispondente, che è bloccato alla
rimozione del finalizer a causa di aggiornamenti molto frequenti da altri controller.
Ciò può causare il timeout del comando gkectl , ma il controllore continua a riconciliare il cluster in modo che il processo di upgrade o aggiornamento venga completato.
Soluzione:
Abbiamo preparato diverse opzioni di mitigazione per questo problema,
che dipendono dal tuo ambiente e dai tuoi requisiti.
- Opzione 1: attendi il completamento dell'upgrade entro il giorno
per trovare le regole.
In base all'analisi e alla riproduzione nel tuo ambiente, l'upgrade
può essere completato automaticamente senza alcun intervento manuale. Il
vantaggio di questa opzione è che non è certo il tempo necessario per
completare la rimozione del finalizzatore per ogni oggetto macchina. Può essere completata immediatamente se hai fortuna o può durare diverse ore se la riconciliazione del controller del set di macchine è troppo veloce e il controller del set di macchine non ha mai la possibilità di rimuovere il finalizzatore tra le riconciliazioni.
La buona notizia è che questa opzione non richiede alcuna azione da parte tua
e i carichi di lavoro non subiranno
interruzioni. Serve solo più tempo
per completare l'upgrade.
- Opzione 2: applica l'annotazione di riparazione automatica a tutti gli oggetti
della vecchia macchina.
Il controller Machineset filtrerà le macchine con
il timestamp di eliminazione ed annotazione della riparazione automatica non deve essere zero e non
continuano a effettuare chiamate di eliminazione su queste macchine, il che può aiutare a evitare
race condition.
Lo svantaggio è che i pod sulle macchine verranno eliminati direttamente
anziché espulsi, il che significa che non rispetterà la configurazione del PDB,
il che potrebbe causare potenziali tempi di riposo per i carichi di lavoro.
Il comando per ottenere tutti i nomi delle macchine:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
Il comando per applicare l'annotazione di riparazione automatica per ogni macchina:
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
machine MACHINE_NAME \
onprem.cluster.gke.io/repair-machine=true
Se riscontri questo problema e l'upgrade o l'aggiornamento non riesce ancora a completarsi dopo molto tempo, contatta il nostro team di assistenza per conoscere le misure di mitigazione.
|
Installazione, upgrade, aggiornamenti |
1.10.2, 1.11, 1.12, 1.13 |
gkectl Errore di preflight durante la convalida dell'immagine del sistema operativo
Comando gkectl prepare non riuscito con:
- Validation Category: OS Images
- [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
I controlli preflight di gkectl prepare includevano una convalida scorretta.
Soluzione:
Esegui lo stesso comando con un flag aggiuntivo
--skip-validation-os-images .
|
Installazione |
1,7; 1,8; 1,9; 1,10; 1,11; 1,12; 1,13 |
URL vCenter con prefisso https:// o http://
potrebbe causare un errore di avvio del cluster
Creazione del cluster di amministrazione non riuscita con:
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
L'URL viene utilizzato come parte di una chiave secret, che non supporta "/" o ":".
Soluzione:
Rimuovi il prefisso https:// o http:// dal
Campo vCenter.Address nel cluster di amministrazione o nel cluster utente
di configurazione YAML.
|
Installazione, upgrade, aggiornamenti |
1.10, 1.11, 1.12, 1.13 |
gkectl prepare panico su util.CheckFileExists
gkectl prepare può generare un panico con il seguente
trace di stack:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]
goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...
Il problema è che gkectl prepare ha creato la directory dei certificati del registry privato con un'autorizzazione errata.
Soluzione:
Per risolvere il problema, esegui i seguenti comandi nella console
workstation:
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
|
Upgrade, aggiornamenti |
1,10; 1,11; 1,12; 1,13 |
gkectl repair admin-master ed è possibile eseguire l'upgrade amministrativo ripristinabile
non funzionano insieme
Dopo un tentativo non riuscito di upgrade del cluster di amministrazione, non eseguire gkectl
repair admin-master . In questo modo, i tentativi di upgrade dell'amministratore successivi potrebbero non riuscire a causa di problemi come l'accensione dell'amministratore principale o l'inaccessibilità della VM.
Soluzione:
Se hai già riscontrato questo errore,
contatta l'assistenza.
|
Upgrade, aggiornamenti |
1,10, 1,11 |
La ripresa dell'upgrade del cluster di amministrazione può comportare la mancata presenza del modello VM del piano di controllo dell'amministratore
Se la macchina del piano di controllo dell'amministratore non viene ricreata dopo un tentativo di upgrade del cluster di amministrazione ripreso, il modello VM del piano di controllo dell'amministratore viene eliminato. Il modello VM del piano di controllo dell'amministratore è il modello del master amministrativo utilizzato per recuperare la macchina del piano di controllo con gkectl
repair admin-master .
Soluzione:
Il modello di VM del piano di controllo amministratore verrà rigenerato durante il prossimo
dell'upgrade del cluster di amministrazione.
|
Sistema operativo |
1.12, 1.13 |
cgroup v2 potrebbe influire sui carichi di lavoro
Nella versione 1.12.0, cgroup v2 (unificato) è abilitato per impostazione predefinita per
Nodi di Container Optimized OS (COS). Questo potrebbe causare
instabilità per i carichi di lavoro in un cluster COS.
Soluzione:
Siamo tornati a cgroup v1 (ibrido) nella versione 1.12.1. Se
utilizzi i nodi COS, ti consigliamo di eseguire l'upgrade alla versione 1.12.1 non appena
viene rilasciata.
|
Identità |
1.10, 1.11, 1.12, 1.13 |
Risorsa personalizzata ClientConfig
gkectl update ripristina tutte le modifiche manuali presenti
creato per la risorsa personalizzata ClientConfig.
Soluzione:
Ti consigliamo vivamente di eseguire il backup della risorsa ClientConfig dopo
ogni modifica manuale.
|
Installazione |
1,10; 1,11; 1,12; 1,13 |
Convalida di gkectl check-config non riuscita: impossibile trovare le partizioni F5
BIG-IP
La convalida non va a buon fine perché non è possibile trovare le partizioni F5 BIG-IP, anche se esistono.
Un problema con l'API F5 BIG-IP può causare il fallimento della convalida.
Soluzione:
Prova a eseguire di nuovo gkectl check-config .
|
Installazione |
1,12 |
L'installazione del cluster utente non è riuscita a causa di un problema di elezione del leader di cert-manager/ca-injector
Potresti notare un errore di installazione a causa di
cert-manager-cainjector è in loop degli arresti anomali quando apiserver/etcd
è lento:
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
cert-manager-cainjector-xxx`
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
Soluzione:
Visualizza i passaggi della soluzione alternativa
Esegui questi comandi per mitigare il problema.
Innanzitutto fai fare lo scale down di monitoring-operator in modo che
ripristina le modifiche al deployment cert-manager :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Modifica il deployment cert-manager-cainjector da disabilitare
delle elezioni presidenziali, perché abbiamo una sola replica in funzione. Non è obbligatoria per una singola replica:
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
-n kube-system deployment cert-manager-cainjector
Lo snippet YAML pertinente per il deployment di cert-manager-cainjector dovrebbe avere il seguente aspetto:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --leader-elect=false
...
Mantieni monitoring-operator replica su 0 come mitigazione
fino al termine dell'installazione. In caso contrario, la modifica verrà annullata.
Al termine dell'installazione e dopo che il cluster è attivo e funzionante, attiva monitoring-operator per le operazioni del secondo giorno:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Dopo ogni upgrade, le modifiche vengono annullate. Esegui lo stesso
i passaggi da seguire per mitigare il problema finché il problema non verrà risolto in futuro.
.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Riavvio o upgrade di vCenter per versioni precedenti alla 7.0U2
Se vCenter, per le versioni precedenti alla 7.0U2, viene riavviato dopo un upgrade o in altro modo, il nome della rete nelle informazioni della VM di vCenter è errato e la macchina si trova in uno stato Unavailable . Ciò porta alla riparazione automatica dei nodi per crearne di nuovi.
Bug govmomi correlato.
Soluzione:
Questa soluzione alternativa è fornita dall'assistenza VMware:
- Il problema è stato risolto nelle versioni vCenter 7.0U2 e successive.
- Per le versioni precedenti, fai clic con il tasto destro del mouse sull'host, quindi seleziona
Connessione > Disconnetti. Quindi, ricollega, il che forza un aggiornamento
del gruppo di porte della VM.
|
Sistema operativo |
1.10, 1.11, 1.12, 1.13 |
Connessione SSH chiusa dall'host remoto
Per Google Distributed Cloud versione 1.7.2 e successive, le immagini del sistema operativo Ubuntu
sono rese più sicure con il
benchmark del server CIS L1.
Per soddisfare la regola CIS "5.2.16 Assicurati che l'intervallo di tempo di spegnimento inattivo SSH sia configurato", /etc/ssh/sshd_config ha le seguenti impostazioni:
ClientAliveInterval 300
ClientAliveCountMax 0
Lo scopo di queste impostazioni è terminare una sessione client dopo 5
minuti di inattività. Tuttavia, ClientAliveCountMax 0
causa comportamenti imprevisti. Quando utilizzi la sessione ssh
alla workstation di amministrazione o a un nodo cluster,
anche se il client SSH non è inattivo, ad esempio durante l'esecuzione
che richiede molto tempo e il tuo comando potrebbe essere terminato
messaggio seguente:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Soluzione:
Puoi:
- Utilizza
nohup per impedire l'interruzione del comando al termine della connessione SSH.
nohup gkectl upgrade admin --config admin-cluster.yaml \
--kubeconfig kubeconfig
- Aggiorna
sshd_config in modo da utilizzare un valore ClientAliveCountMax distinto da zero. La regola CIS consiglia di utilizzare
un valore inferiore a 3:
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
/etc/ssh/sshd_config
sudo systemctl restart sshd
Assicurati di ricollegare la sessione SSH.
|
Installazione |
1,10; 1,11; 1,12; 1,13 |
Installazione di cert-manager in conflitto
Nelle release 1.13, monitoring-operator installerà
cert-manager nello spazio dei nomi cert-manager . Se per certi
è necessario installare un proprio certificato-manager, seguire
istruzioni per evitare conflitti:
Devi applicare questa soluzione alternativa una sola volta per ogni cluster e le modifiche verranno conservate durante l'upgrade del cluster.
Nota: un sintomo comune dell'installazione di un gestore certificati
è che la versione o l'immagine cert-manager (ad esempio
v1.7.2) può tornare alla versione precedente. Questo accade perché
monitoring-operator tenta di riconciliare
cert-manager e ripristina la versione durante la procedura.
Soluzione:
<pEvita conflitti durante l'upgrade
- Disinstalla la tua versione di
cert-manager . Se hai definito
le tue risorse, ti consigliamo di eseguire il
backup
.
- Esegui l'upgrade.
- Segui le istruzioni riportate di seguito per ripristinare il tuo
cert-manager .
Ripristinare cert-manager nei cluster utente
- Scala il deployment
monitoring-operator su 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Scala i deployment
cert-manager gestiti da
Da monitoring-operator a 0:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector\
--replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook --replicas=0
- Reinstalla la tua versione di
cert-manager .
Ripristina
le risorse personalizzate, se presenti.
- Puoi saltare questo passaggio se utilizzi
l'installazione predefinita di cert-manager a livello di upstream oppure
cert-manager è installato nello spazio dei nomi
cert-manager .
In caso contrario, copia il file cert-manager.io/v1 di metrics-ca .
Certificato e emittente metrics-pki.cluster.local
da cert-manager alla risorsa del cluster
del tuo cert-manager installato.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
Ripristinare il proprio cert-manager nei cluster di amministrazione
In genere, non è necessario reinstallare cert-manager nei cluster di amministrazione perché i cluster di amministrazione eseguono solo i carichi di lavoro del control plane di Google Distributed Cloud. Nei rari casi in cui devi installare anche il tuo
cert-manager nei cluster di amministrazione, segui le istruzioni riportate di seguito
per evitare conflitti. Tieni presente che se sei un cliente Apigee e hai bisogno solo di cert-manager per Apigee, non devi eseguire i comandi del cluster di amministrazione.
- Scala il deployment
monitoring-operator a 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n kube-system scale deployment monitoring-operator --replicas=0
- Scala i deployment di
cert-manager gestiti da
monitoring-operator su 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook \
--replicas=0
- Reinstalla la tua versione di
cert-manager .
Ripristina
le tue risorse personalizzate, se disponibili.
- Puoi saltare questo passaggio se utilizzi
l'installazione predefinita di cert-manager upstream o se hai la certezza che
cert-manager sia installato nello spazio dei nomi
cert-manager .
In caso contrario, copia le risorse metrics-ca cert-manager.io/v1
Certificate e metrics-pki.cluster.local Issuer
da cert-manager allo spazio dei nomi delle risorse
del cluster del tuo cert-manager installato.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
</p |
Sistema operativo |
1,10; 1,11; 1,12; 1,13 |
Falsi positivi nell'analisi delle vulnerabilità Docker, containerd e runc
Docker, containerd e runc nelle immagini del sistema operativo Ubuntu fornite con
Google Distributed Cloud è bloccata su versioni speciali usando
PPA di Ubuntu. Ciò garantisce
che qualsiasi modifica al runtime del container verrà
Google Distributed Cloud prima di ogni release.
Tuttavia, le versioni speciali sono sconosciute al
tracker CVE di Ubuntu, che viene utilizzato come feed di vulnerabilità da vari strumenti di scansione CVE. Pertanto, vedrai falsi positivi in Docker,
risultati dell'analisi delle vulnerabilità containerd e runc.
Ad esempio, potresti vedere i seguenti falsi positivi relativi al tuo CVE
la scansione dei risultati. Queste CVE sono già state corrette nell'ultima patch
di Google Distributed Cloud.
Consulta le note di rilascio per eventuali correzioni delle CVE.
Soluzione:
Canonical è a conoscenza del problema e la correzione viene monitorata in
https://github.com/canonical/sec-cvescan/issues/73.
|
Upgrade, aggiornamenti |
1,10; 1,11; 1,12; 1,13 |
La connessione di rete tra l'amministratore e il cluster utente potrebbe non essere disponibile
per un breve periodo di tempo durante l'upgrade dei cluster non ad alta disponibilità
Se esegui l'upgrade di cluster non ad alta disponibilità dalla versione 1.9 alla versione 1.10, potresti notare che
che kubectl exec , kubectl log e il webhook
rispetto ai cluster utente potrebbero non essere disponibili per un breve periodo. Questo tempo di riposo
può durare fino a un minuto. Questo accade perché la richiesta in entrata
(kubectl exec, kubectl log e webhook) è gestito da kube-apiserver per
per il cluster utente. L'utente kube-apiserver è un
Statefulset. In un cluster non ad alta disponibilità, esiste una sola replica per
StatefulSet. Pertanto, durante l'upgrade, è possibile che il vecchio
kube-apiserver non sia disponibile mentre il nuovo kube-apiserver non sia ancora
pronto.
Soluzione:
Questo tempo di inattività si verifica solo durante il processo di upgrade. Se vuoi un tempo di riposo più breve durante l'upgrade, ti consigliamo di passare ai cluster HA.
|
Installazione, upgrade, aggiornamenti |
1.10, 1.11, 1.12, 1.13 |
Il controllo di idoneità alla connettività non è riuscito nella diagnosi del cluster HA dopo
la creazione o l'upgrade del cluster
Se stai creando o eseguendo l'upgrade di un cluster HA e noti che il controllo di idoneità della connettività
non è riuscito nella diagnosi del cluster, nella maggior parte dei casi non influirà sulla funzionalità di Google Distributed Cloud (kubectl exec, kubectl
log e webhook). Questo accade perché a volte uno o due dei
le repliche della konnectivity potrebbero non essere pronte per un periodo di tempo a causa
instabilità della rete o altri problemi.
Soluzione:
La connettività verrà ripristinata automaticamente. Attendi da 30 minuti a 1 ora
ed esegui di nuovo la diagnostica del cluster.
|
Sistema operativo |
1,7; 1,8; 1,9; 1,10; 1,11 |
/etc/cron.daily/aide Problema relativo a picchi di CPU e memoria
A partire da Google Distributed Cloud versione 1.7.2, il sistema operativo Ubuntu
le immagini vengono protette con
Server CIS L1
Benchmark.
Di conseguenza, lo script cron /etc/cron.daily/aide è stato
installato in modo che venga pianificato un controllo aide per garantire
che venga rispettata la regola del server CIS L1 "1.4.2 Verifica che l'integrità del filesystem sia
controllata regolarmente".
Il job cron viene eseguito ogni giorno alle ore 06:25 UTC. A seconda del numero di
file nel file system, in questo periodo di tempo potresti riscontrare picchi di utilizzo della CPU e della memoria causati da questo processo aide .
Soluzione:
Se i picchi influiscono sul tuo carico di lavoro, puoi disattivare il job cron giornaliero:
sudo chmod -x /etc/cron.daily/aide
|
Networking |
1,10; 1,11; 1,12; 1,13 |
I bilanciatori del carico e le regole del firewall distribuito stateful di NSX-T interagiscono
in modo imprevedibile
Quando esegui il deployment di Google Distributed Cloud versione 1.9 o successive,
il deployment ha il bilanciatore del carico in bundle Seesaw in un ambiente
utilizza le regole firewall distribuite stateful di NSX-T,
La creazione di stackdriver-operator potrebbe non riuscire
gke-metrics-agent-conf ConfigMap e causa
gke-connect-agent pod in un loop di arresto anomalo.
Il problema di base è che il firewall stateful distribuito NSX-T
le regole terminano la connessione da un client all'API del cluster utente
server tramite il bilanciatore del carico Seesaw, poiché Seesaw utilizza un sistema
di connessione tra i vari flussi. I problemi di integrazione con il firewall distribuito NSX-T
interessano tutte le release di Google Distributed Cloud che utilizzano Seesaw. Puoi
riscontrare problemi di connessione simili nelle tue applicazioni quando
creano oggetti Kubernetes di grandi dimensioni, le cui dimensioni sono superiori a 32 K.
Soluzione:
Segui
queste istruzioni per disattivare le regole firewall distribuite di NSX-T o per
utilizzare regole firewall distribuite stateless per le VM Seesaw.
Se i tuoi cluster utilizzano un bilanciatore del carico manuale, segui
queste istruzioni per configurare il bilanciatore del carico in modo da reimpostare le connessioni
dei client quando rileva un errore del nodo di backend. Senza questa configurazione, i client del server API Kubernetes potrebbero smettere di rispondere per diversi minuti quando un'istanza del server si arresta in modo anomalo.
|
Logging e monitoraggio |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
Fatturazione del monitoraggio imprevista
Per le versioni di Google Distributed Cloud dalla 1.10 alla 1.15, alcuni clienti hanno
ha rilevato una fatturazione inaspettatamente elevata per Metrics volume il
pagina Fatturazione. Questo problema ti riguarda solo se si verificano tutte le seguenti circostanze:
- Il logging e il monitoraggio delle applicazioni sono abilitati (
enableStackdriverForApplications=true )
- I pod dell'applicazione hanno lo
prometheus.io/scrap=true
annotazione. Questa annotazione può essere aggiunta anche all'installazione di Cloud Service Mesh.
Per verificare se il problema ti riguarda,
elenca le tue
metriche definite dall'utente. Se vedi la fatturazione per metriche indesiderate con il prefisso nome external.googleapis.com/prometheus e vedi anche enableStackdriverForApplications impostato su true nella risposta di kubectl -n kube-system get stackdriver stackdriver -o yaml ,
questo problema ti riguarda.
Soluzione
Se hai riscontrato questo problema, ti consigliamo di eseguire l'upgrade del tuo
alla versione 1.12 o successive, smetti di utilizzare il flag enableStackdriverForApplications e passa alla nuova soluzione di monitoraggio delle applicazioni managed-service-for-prometheus che non si basa più sull'annotazione prometheus.io/scrap=true . Con la nuova soluzione, puoi anche controllare la raccolta di log e metriche separatamente per le tue applicazioni, con il flag enableCloudLoggingForApplications e enableGMPForApplications , rispettivamente.
Per interrompere l'uso del flag enableStackdriverForApplications , apri l'oggetto "stackdriver" per modificarlo:
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver
Rimuovi la riga enableStackdriverForApplications: true , salva e chiudi l'editor.
Se non riesci a passare dalla raccolta delle metriche basate sulle annotazioni, segui questi passaggi:
- Trova i pod e i servizi di origine con le metriche fatturate indesiderate.
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
- Rimuovi l'annotazione
prometheus.io/scrap=true dal
pod o dal servizio. Se l'annotazione viene aggiunta da Cloud Service Mesh, prendi in considerazione
configurazione di Cloud Service Mesh senza l'opzione Prometheus,
o la disattivazione della funzionalità di unione delle metriche Istio.
|
Installazione |
1.11, 1.12, 1.13 |
Il programma di installazione non riesce durante la creazione del disco dati vSphere
L'installer di Google Distributed Cloud può non riuscire se i ruoli personalizzati sono associati
al livello di autorizzazione sbagliato.
Quando l'associazione dei ruoli non è corretta, viene creato un disco dati vSphere con
govc si blocca e il disco viene creato con una dimensione pari a 0. Per risolvere il problema, devi associare il ruolo personalizzato a livello di vCenter vSphere (root).
Soluzione:
Se vuoi associare il ruolo personalizzato a livello di controller (o a un livello inferiore a
root), devi anche associare il ruolo di sola lettura all'utente nella directory radice
A livello di vCenter.
Per ulteriori informazioni sulla creazione dei ruoli, consulta
Privilegi dell'account utente vCenter.
|
Logging e monitoraggio |
1.9.0-1.9.4, 1.10.0-1.10.1 |
Traffico di rete elevato verso monitoring.googleapis.com
Potresti notare un traffico di rete elevato su
monitoring.googleapis.com , anche in un nuovo cluster senza
carichi di lavoro utente.
Questo problema riguarda le versioni 1.10.0-1.10.1 e 1.9.0-1.9.4. Questo
è stato risolto nelle versioni 1.10.2 e 1.9.5.
Soluzione:
Visualizza i passaggi per la soluzione alternativa
Esegui l'upgrade alla versione 1.10.2/1.9.5 o successiva.
Per risolvere il problema per una versione precedente:
- Fai lo scale down di "stackdriver-operator":
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
scale deployment stackdriver-operator --replicas=0
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso dell'utente
kubeconfig del cluster.
- Apri il ConfigMap
gke-metrics-agent-conf per la modifica:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
edit configmap gke-metrics-agent-conf
- Aumenta l'intervallo di misurazione da 0,1 secondi a 13 secondi:
processors:
disk_buffer/metrics:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-metrics
probe_interval: 13s
retention_size_mib: 6144
disk_buffer/self:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-self
probe_interval: 13s
retention_size_mib: 200
disk_buffer/uptime:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-uptime
probe_interval: 13s
retention_size_mib: 200
- Chiudi la sessione di modifica.
- Cambia la versione di
gke-metrics-agent DaemonSet in
1.1.0-anthos.8:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
Logging e monitoraggio |
1.10, 1.11 |
gke-metrics-agent presenta frequenti errori CrashLoopBackOff
Per Google Distributed Cloud versione 1.10 e successive, "gke-metrics-agent"
DaemonSet presenta frequenti errori CrashLoopBackOff quando
"enableStackdriverForApplications" è impostato su "true" in "stackdriver"
.
Soluzione:
Per limitare il problema, disabilita la raccolta delle metriche dell'applicazione
eseguendo questi comandi. Questi comandi non disabiliteranno
raccolta dei log delle applicazioni.
- Per evitare il ripristino delle modifiche seguenti, fare lo scale down
stackdriver-operator :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy stackdriver-operator \
--replicas=0
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster
degli utenti.
- Apri il ConfigMap
gke-metrics-agent-conf per modificarlo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- Sotto
services.pipelines , commenta l'intero contenuto
Sezione metrics/app-metrics :
services:
pipelines:
#metrics/app-metrics:
# exporters:
# - googlecloud/app-metrics
# processors:
# - resource
# - metric_to_resource
# - infer_resource
# - disk_buffer/app-metrics
# receivers:
# - prometheus/app-metrics
metrics/metrics:
exporters:
- googlecloud/metrics
processors:
- resource
- metric_to_resource
- infer_resource
- disk_buffer/metrics
receivers:
- prometheus/metrics
- Chiudi la sessione di modifica.
- Riavvia il DaemonSet
gke-metrics-agent :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system rollout restart daemonset gke-metrics-agent
|
Logging e monitoraggio |
1,11, 1,12, 1,13 |
Sostituire le metriche ritirate nella dashboard
Se nelle dashboard OOTB vengono utilizzate metriche deprecate, vedrai
alcuni grafici vuoti. Per trovare le metriche ritirate nelle dashboard monitoring, esegui i seguenti comandi:
gcloud monitoring dashboards list > all-dashboard.json
# find deprecated metrics
cat all-dashboard.json | grep -E \
'kube_daemonset_updated_number_scheduled\
|kube_node_status_allocatable_cpu_cores\
|kube_node_status_allocatable_pods\
|kube_node_status_capacity_cpu_cores'
È necessario eseguire la migrazione delle seguenti metriche ritirate alle relative
sostituzioni.
Ritirato | Sostituzione |
kube_daemonset_updated_number_scheduled |
kube_daemonset_status_updated_number_scheduled |
kube_node_status_allocatable_cpu_cores
kube_node_status_allocatable_memory_bytes
kube_node_status_allocatable_pods |
kube_node_status_allocatable |
kube_node_status_capacity_cpu_cores
kube_node_status_capacity_memory_bytes
kube_node_status_capacity_pods |
kube_node_status_capacity |
kube_hpa_status_current_replicas |
kube_horizontalpodautoscaler_status_current_replicas |
Soluzione:
Sostituire le metriche deprecate
- Elimina "Stato del nodo GKE on-prem" nella piattaforma Google Cloud Monitoring
Fitbit.com. Reinstalla lo "stato del nodo GKE on-prem" persone che seguo
queste istruzioni.
- Elimina "Utilizzo nodi GKE on-prem" nella piattaforma Google Cloud Monitoring
Fitbit.com. Reinstalla "Utilizzo dei nodi GKE on-prem" seguendo
queste istruzioni.
- Elimina "Stato VM vSphere GKE on-prem" nella dashboard di monitoraggio di Google Cloud. Reinstalla "Integrità delle macchine virtuali vSphere di GKE on-prem"
persone che seguo
queste istruzioni.
Questo ritiro è dovuto all'upgrade
kube-state-metrics, dalla versione 1.9 alla versione 2.4, obbligatorio per gli
Kubernetes 1.22. Puoi sostituire tutte le metriche kube-state-metrics ritirate, che hanno il prefisso kube_ , nelle dashboard o nei criteri di avviso personalizzati.
|
Logging e monitoraggio |
1,10; 1,11; 1,12; 1,13 |
Dati delle metriche sconosciuti in Cloud Monitoring
Per Google Distributed Cloud versione 1.10 e successive, i dati relativi ai cluster in Cloud Monitoring potrebbero contenere voci di metriche di riepilogo irrilevanti, ad esempio:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Altri tipi di metriche che potrebbero avere metriche di riepilogo irrilevanti includeono: :
apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary
Anche se queste metriche di riepilogo sono nell'elenco delle metriche, non sono
attualmente supportati da gke-metrics-agent .
|
Logging e monitoraggio |
1,10; 1,11; 1,12; 1,13 |
Metriche mancanti su alcuni nodi
Potresti notare che, in alcuni casi, mancano le seguenti metriche, ma non
tutti, nodi:
kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total
Soluzione:
Per risolvere il problema, esegui i passaggi che seguono come soluzione alternativa. Per
[versione 1.9.5 e successive, 1.10.2 e successive, 1.11.0]: aumenta la CPU per gke-metrics-agent
seguendo i passaggi 1-4
- Apri la risorsa
stackdriver da modificare:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Per aumentare la richiesta di CPU per
gke-metrics-agent da
10m a 50m , il limite di CPU da 100m
a 200m aggiungi la seguente sezione resourceAttrOverride
al manifest stackdriver :
spec:
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 100m
memory: 4608Mi
requests:
cpu: 10m
memory: 200Mi
La risorsa modificata dovrebbe essere simile alla seguente:
spec:
anthosDistribution: on-prem
clusterLocation: us-west1-a
clusterName: my-cluster
enableStackdriverForApplications: true
gcpServiceAccountSecretName: ...
optimizedMetrics: true
portable: true
projectID: my-project-191923
proxyConfigSecretName: ...
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 200m
memory: 4608Mi
requests:
cpu: 50m
memory: 200Mi
- Salva le modifiche e chiudi l'editor di testo.
- Per verificare che le modifiche siano state applicate, esegui il seguente comando:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset gke-metrics-agent -o yaml \
| grep "cpu: 50m"
Il comando trova cpu: 50m se le modifiche sono state applicate.
|
Logging e monitoraggio |
1.11.0-1.11.2, 1.12.0 |
Mancano le metriche di pianificatore e controller-manager nel cluster di amministrazione
Se il tuo cluster di amministrazione è interessato da questo problema, scheduler e
Mancano metriche controller-manager. Ad esempio, queste due metriche sono
mancanti
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Soluzione:
Esegui l'upgrade alla versione 1.11.3 o successiva, 1.12.1 o successiva o 1.13 o successiva.
|
|
1.11.0-1.11.2, 1.12.0 |
Mancano le metriche di pianificatore e controller-manager nel cluster utente
Se il tuo cluster utente è interessato da questo problema, le metriche di schedulatore e
controller-manager non sono presenti. Ad esempio, mancano queste due metriche:
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Soluzione:
Questo problema è stato risolto in Google Distributed Cloud versione 1.13.0 e successive.
Esegui l'upgrade del cluster a una versione con la correzione.
|
Installazione, upgrade, aggiornamenti |
1,10; 1,11; 1,12; 1,13 |
Impossibile registrare il cluster amministratore durante la creazione
Se crei un cluster di amministrazione per la versione 1.9.x o 1.10.0 e se
la registrazione del cluster di amministrazione con il valore gkeConnect fornito non riesce
durante la sua creazione, riceverai il seguente errore.
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH
Potrai ancora utilizzare questo cluster di amministrazione, ma riceverai il
questo errore se tenti in un secondo momento di eseguire l'upgrade del cluster di amministrazione a
versione 1.10.y.
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""
Soluzione:
Visualizza i passaggi per la soluzione alternativa
Se si verifica questo errore, segui questi passaggi per correggere il cluster
problema di registrazione. Una volta completata questa correzione, puoi eseguire l'upgrade dell'amministratore
in un cluster Kubernetes.
- Esegui
gkectl update admin per registrare il cluster amministrativo con la chiave dell'account di servizio corretta.
- Crea un account di servizio dedicato per l'applicazione di patch
OnPremAdminCluster risorsa personalizzata.
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso dell'amministratore
kubeconfig del cluster.
- Esegui questi comandi per aggiornare
OnPremAdminCluster
risorsa personalizzata.
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
--no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
-n kube-system $ADMIN_CLUSTER_NAME \
-o=jsonpath='{.spec.gkeOnPremVersion}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Prova a eseguire nuovamente l'upgrade del cluster di amministrazione con il
flag
--disable-upgrade-from-checkpoint .
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Sostituisci ADMIN_CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione.
|
Identità |
1,10; 1,11; 1,12; 1,13 |
L'utilizzo di GKE Identity Service può causare il riavvio imprevedibile dell'agente Connect.
Se utilizzi la funzionalità
GKE Identity Service
per gestire
ClientConfig di GKE Identity Service, il
Connect Agent potrebbe riavviarsi in modo imprevisto.
Soluzione:
Se hai riscontrato questo problema con un cluster esistente, puoi farlo
uno dei seguenti:
- Disabilita GKE Identity Service. Se disattivi
GKE Identity Service, che non rimuoverà l'oggetto
File binario di GKE Identity Service o rimuovilo
ClientConfig del servizio di identità GKE. Per disattivare
GKE Identity Service, esegui questo comando:
gcloud container fleet identity-service disable \
--project PROJECT_ID
Sostituisci PROJECT_ID con l'ID del cluster
progetto host del parco risorse.
- Aggiorna il cluster alla versione 1.9.3 o successiva o alla versione 1.10.1 o
successiva per eseguire l'upgrade della versione di Connect Agent.
|
Networking |
1.10, 1.11, 1.12, 1.13 |
Cisco ACI non funziona con Direct Server Return (DSR)
Seesaw viene eseguito in modalità DSR e per impostazione predefinita non funziona in Cisco ACI
a causa dell'apprendimento IP del piano dati.
Soluzione:
Una possibile soluzione alternativa è disattivare l'apprendimento IP aggiungendo l'indirizzo IP di Seesaw come IP virtuale L4-L7 nell'APIC (Application Policy Infrastructure Controller) di Cisco.
Puoi configurare l'opzione IP virtuale L4-L7 in Tenant >
Profili delle applicazioni > EPG delle applicazioni o EPG uSeg. Se non disattivi l'apprendimento IP, l'endpoint IP verrà spostato tra posizioni diverse nel fabric dell'API Cisco.
|
VMware |
1,10; 1,11; 1,12; 1,13 |
Problemi di vSphere 7.0 Update 3
VMWare ha recentemente identificato problemi critici relativi a:
Rilascio di vSphere 7.0 Update 3:
- Aggiornamento 3 di vSphere ESXi 7.0 (build 18644231)
- Aggiornamento 3a di vSphere ESXi 7.0 (build 18825058)
- vSphere ESXi 7.0 Update 3b (build 18905247)
- Aggiornamento 3b di vSphere vCenter 7.0 (build 18901211)
Soluzione:
Da allora VMWare ha rimosso queste release. Dovresti eseguire l'upgrade
ESXi e
vCenter
Server a una versione più recente.
|
Sistema operativo |
1.10, 1.11, 1.12, 1.13 |
Impossibile montare il volume emptyDir come exec nel pod in esecuzione
sui nodi COS
Per i pod in esecuzione su nodi che utilizzano immagini Container-Optimized OS (COS),
non puoi montare il volume emptyDir come exec . Si monta come
noexec e viene visualizzato il seguente errore: exec user
process caused: permission denied . Ad esempio, visualizzerai questo
messaggio di errore se esegui il deployment del seguente pod di test:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: test
name: test
spec:
containers:
- args:
- sleep
- "5000"
image: gcr.io/google-containers/busybox:latest
name: test
volumeMounts:
- name: test-volume
mountPath: /test-volume
resources:
limits:
cpu: 200m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
volumes:
- emptyDir: {}
name: test-volume
E nel pod di test, se esegui mount | grep test-volume ,
viene mostrata l'opzione noexec:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Soluzione:
Visualizza i passaggi della soluzione alternativa
Applica una risorsa DaemonSet, ad esempio:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fix-cos-noexec
namespace: kube-system
spec:
selector:
matchLabels:
app: fix-cos-noexec
template:
metadata:
labels:
app: fix-cos-noexec
spec:
hostIPC: true
hostPID: true
containers:
- name: fix-cos-noexec
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
set -ex
while true; do
if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
echo "remounting /var/lib/kubelet with exec"
nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
fi
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Upgrade, aggiornamenti |
1,10; 1,11; 1,12; 1,13 |
L'aggiornamento della replica del pool di nodi del cluster non funziona dopo che la scalabilità automatica è
è stato disabilitato sul pool di nodi
Le repliche del pool di nodi non vengono aggiornate dopo l'attivazione e la disattivazione della scalabilità automatica in un pool di nodi.
Soluzione:
Rimozione delle annotazioni cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size e cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size dal deployment delle macchine del pool di nodi corrispondente.
|
Logging e monitoraggio |
1.11, 1.12, 1.13 |
Le dashboard di monitoraggio di Windows mostrano i dati dei cluster Linux
A partire dalla versione 1.11, nelle dashboard di monitoraggio pronte all'uso,
Vengono mostrate anche la dashboard dello stato dei pod Windows e la dashboard dello stato dei nodi Windows
da cluster Linux. Questo perché le metriche dei nodi e dei pod Windows
sono esposti anche sui cluster Linux.
|
Logging e monitoraggio |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder in CrashLoopBackOff costante
Per le versioni 1.10, 1.11 e 1.12 di Google Distributed Cloud, stackdriver-log-forwarder
DaemonSet potrebbe avere errori CrashLoopBackOff se sul disco sono presenti log con buffer danneggiati.
Soluzione:
Per risolvere il problema, dovremo ripulire i log in buffer sul
nodo.
- Per evitare comportamenti imprevisti, fare lo scale down
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster
degli utenti.
- Esegui il deployment del DaemonSet di pulizia per ripulire i chunk danneggiati:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit-cleanup
namespace: kube-system
spec:
selector:
matchLabels:
app: fluent-bit-cleanup
template:
metadata:
labels:
app: fluent-bit-cleanup
spec:
containers:
- name: fluent-bit-cleanup
image: debian:10-slim
command: ["bash", "-c"]
args:
- |
rm -rf /var/log/fluent-bit-buffers/
echo "Fluent Bit local buffer is cleaned up."
sleep 3600
volumeMounts:
- name: varlog
mountPath: /var/log
securityContext:
privileged: true
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
- key: node-role.kubernetes.io/master
effect: NoSchedule
- key: node-role.gke.io/observability
effect: NoSchedule
volumes:
- name: varlog
hostPath:
path: /var/log
EOF
- Per assicurarti che il DaemonSet di pulizia abbia ripulito tutti i chunk,
puoi eseguire i seguenti comandi. L'output dei due comandi
deve essere uguale al numero del tuo nodo nel cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
- Elimina il DaemonSet di pulizia:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
- Riprendi
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
|
Logging e monitoraggio |
1,10, 1,11, 1,12, 1,13, 1,14, 1,15 e 1,16 |
stackdriver-log-forwarder non invia log a Cloud Logging
Se non visualizzi i log in Cloud Logging dai tuoi cluster e
noti il seguente errore nei log:
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
È probabile che la frequenza di input dei log superi il limite dell'agente Logging,
impedendo a stackdriver-log-forwarder di inviare i log.
Questo problema si verifica in tutte le versioni di Google Distributed Cloud.
Soluzione alternativa:
Per risolvere il problema, devi aumentare il limite di risorse sull'agente di registrazione.
- Apri la risorsa
stackdriver per la modifica:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Per aumentare la richiesta di CPU per
stackdriver-log-forwarder
, aggiungi il seguente resourceAttrOverride
al file manifest stackdriver :
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
La risorsa modificata dovrebbe avere il seguente aspetto:
spec:
anthosDistribution: on-prem
clusterLocation: us-west1-a
clusterName: my-cluster
enableStackdriverForApplications: true
gcpServiceAccountSecretName: ...
optimizedMetrics: true
portable: true
projectID: my-project-191923
proxyConfigSecretName: ...
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
- Salva le modifiche e chiudi l'editor di testo.
- Per verificare che le modifiche siano state applicate, esegui questo comando:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
| grep "cpu: 1200m"
Il comando trova cpu: 1200m se le modifiche sono state applicate.
|
Sicurezza |
1,13 |
Il servizio kubelet sarà temporaneamente non disponibile dopo NodeReady
esiste un breve periodo in cui il nodo è pronto, ma il certificato del server kubelet non è pronto. kubectl exec e
kubectl logs non sono disponibili durante queste decine di secondi.
Questo perché è necessario del tempo per consentire all'approvatore del nuovo certificato del server di vedere gli IP validi aggiornati del nodo.
Questo problema riguarda solo il certificato del server kubelet e non influisce sulla pianificazione dei pod.
|
Upgrade, aggiornamenti |
1,12 |
L'upgrade parziale del cluster di amministrazione non blocca l'upgrade successivo del cluster utente
L'upgrade del cluster utente non è riuscito con:
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
L'upgrade del cluster di amministrazione non è stato completato e la versione dello stato è ancora 1.10. L'upgrade del cluster utente alla versione 1.12 non verrà bloccato da alcun controllo preflight e non andrà a buon fine a causa di un problema di sfasamento della versione.
Soluzione:
Completa prima l'upgrade del cluster di amministrazione alla versione 1.11, quindi esegui l'upgrade
il cluster utente a 1.12.
|
Archiviazione |
1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0 |
Il data store segnala erroneamente uno spazio libero insufficiente
Comando gkectl diagnose cluster non riuscito con:
Checking VSphere Datastore FreeSpace...FAILURE
Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB
La convalida dello spazio libero del datastore non deve essere utilizzata per
pool di nodi del cluster ed è stato aggiunto in gkectl diagnose cluster
per errore.
Soluzione:
Puoi ignorare il messaggio di errore o saltare la convalida utilizzando
--skip-validation-infra .
|
Operazione, Networking |
1.11, 1.12.0-1.12.1 |
Potresti non essere in grado di aggiungere un nuovo cluster utente se il cluster di amministrazione è
con una configurazione
del bilanciatore del carico MetalLB.
Il processo di eliminazione del cluster utente potrebbe bloccarsi per qualche motivo, con conseguente invalidazione del ConfigMap MatalLB. In questo stato non sarà possibile
aggiungere un nuovo cluster di utenti.
Soluzione:
Puoi
eliminare forzatamente il cluster utente.
|
Installazione, Sistema operativo |
1.10, 1.11, 1.12, 1.13 |
Errore durante l'utilizzo di Container-Optimized OS (COS) per il cluster di utenti
Se osImageType utilizza cos per l'amministratore
cluster e quando gkectl check-config viene eseguito dopo l'amministrazione
durante la creazione del cluster. Prima della creazione del cluster utente, l'operazione non andrebbe a buon fine:
Failed to create the test VMs: VM failed to get IP addresses on the network.
La VM di test creata per il cluster utente check-config da
per impostazione predefinita utilizza lo stesso osImageType del cluster di amministrazione e
la VM attualmente testata non è ancora compatibile con COS.
Soluzione:
Per evitare il lento controllo preflight che crea la VM di test, utilizza
gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config
USER_CLUSTER_CONFIG --fast .
|
Logging e monitoraggio |
1.12.0-1.12.1 |
Grafana nel cluster di amministrazione non è in grado di raggiungere i cluster utente
Questo problema riguarda i clienti che utilizzano Grafana nel cluster di amministrazione per
consente di monitorare i cluster utente in Google Distributed Cloud versioni 1.12.0 e
1.12.1. Il problema è causato da una mancata corrispondenza dei certificati pushprox-client nei cluster di utenti e dalla lista consentita in pushprox-server nel cluster di amministrazione.
Il sintomo è che pushprox-client nei cluster utente stampa log di errore come
il seguente:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Soluzione:
Visualizza i passaggi per la soluzione alternativa
segui questi passaggi:
- Fai lo scale down del deployment dell'operatore di monitoraggio nel cluster di amministrazione
kube-system.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Modifica il ConfigMap
pushprox-server-rbac-proxy-config
nello spazio dei nomi kube-system del cluster di amministrazione.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Individua la riga principals per il
Listener external-pushprox-server-auth-proxy e correggi
il principal_name per tutti i cluster di utenti rimuovendo la
sottostringa kube-system da
pushprox-client.metrics-consumers.kube-system.cluster.
La nuova configurazione dovrebbe avere il seguente aspetto:
permissions:
- or_rules:
rules:
- header: { name: ":path", exact_match: "/poll" }
- header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
- Riavvia il deployment
pushprox-server nell'amministratore
cluster e il deployment pushprox-client interessati
cluster utente:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
- I passaggi precedenti dovrebbero risolvere il problema. Una volta eseguito l'upgrade del cluster alla versione 1.12.2 e versioni successive in cui il problema è stato risolto, esegui lo scale up del monitoraggio-operatore kube-system del cluster di amministrazione in modo che possa gestire di nuovo la pipeline.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
Altro |
1.11.3 |
gkectl repair admin-master non fornisce il
modello VM da utilizzare per il recupero
Il comando gkectl repair admin-master non è riuscito con:
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support
gkectl repair admin-master non è in grado di recuperare la VM
modello da utilizzare per riparare la VM del piano di controllo amministratore se il nome
della VM del piano di controllo amministratore termina con i caratteri t ,
m , p o l .
Soluzione:
Esegui di nuovo il comando con --skip-validation .
|
Logging e monitoraggio |
1.11, 1.12, 1.13, 1.14, 1.15, 1.16 |
Errore dell'audit logging di Cloud a causa di autorizzazione negata
Cloud Audit Logs richiede una configurazione di autorizzazioni speciale che
eseguita automaticamente per i cluster utente tramite GKE Hub.
Ti consigliamo di avere almeno un cluster utente che utilizza lo stesso
l'ID progetto e l'account di servizio con il cluster di amministrazione
Cloud Audit Logs in modo che il cluster di amministrazione abbia il necessario
autorizzazione.
Tuttavia, se il cluster di amministrazione utilizza un ID progetto o un account di servizio diverso da qualsiasi cluster utente, i log di controllo del cluster di amministrazione non verranno inseriti in Google Cloud. Il sintomo è una serie di errori Permission Denied nel pod audit-proxy nel cluster di amministrazione.
Soluzione:
Visualizza i passaggi della soluzione alternativa
Per risolvere il problema, l'autorizzazione può essere impostata interagendo con
la funzionalità dell'hub di cloudauditlogging :
- Controlla innanzitutto gli account di servizio esistenti inclusi nella lista consentita
Cloud Audit Logs nel tuo progetto:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- A seconda della risposta, procedi in uno dei seguenti modi:
- Se hai ricevuto un errore
404 Not_found , significa che
Nessun account di servizio incluso nella lista consentita per questo ID progetto. Puoi inserire un account di servizio nella lista consentita attivando la funzionalità dell'cloudauditlogging hub:
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Se hai ricevuto una specifica della funzione che contiene
"lifecycleState": "ENABLED" con "code":
"OK" e un elenco di account di servizio in
allowlistedServiceAccounts , significa che esistono
account di servizio consentiti per questo progetto, puoi utilizzare
account di servizio da questo elenco nel tuo cluster oppure aggiungi un nuovo servizio
alla lista consentita:
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Se hai ricevuto una specifica della funzionalità che contiene
"lifecycleState": "ENABLED" con "code":
"FAILED" , significa che la configurazione delle autorizzazioni non è andata a buon fine.
Prova a risolvere i problemi nel campo description di
la risposta o eseguire il backup della lista consentita attuale,
funzionalità hub cloudauditlogging e riattivarla dopo il passaggio 1 di
di nuovo questa sezione. Per eliminare la funzionalità cloudauditlogging
Hub:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
Nei comandi precedenti:
|
Operazione, sicurezza |
1,11 |
gkectl diagnose controllo dei certificati non riuscito
Se la tua workstation non ha accesso ai nodi di lavoro del cluster di utenti,
durante l'esecuzione di
gkectl diagnose verranno visualizzati i seguenti errori:
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Se la tua postazione di lavoro non ha accesso ai nodi worker del cluster di amministrazione
o nodi worker del cluster di amministrazione, riceverà gli errori seguenti quando
con gkectl diagnose in esecuzione:
Checking admin cluster certificates...FAILURE
Reason: 3 admin cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Soluzione:
Se puoi ignorare questo messaggio,
|
Sistema operativo |
1,8; 1,9; 1,10; 1,11; 1,12; 1,13 |
/var/log/audit/ esaurimento dello spazio su disco delle VM
/var/log/audit/ contiene audit log. Puoi controllare
l'utilizzo del disco eseguendo sudo du -h -d 1 /var/log/audit .
Alcuni comandi gkectl sulla workstation di amministrazione, ad esempio gkectl diagnose snapshot , contribuiscono all'utilizzo dello spazio su disco.
Da Google Distributed Cloud v1.8, l'immagine Ubuntu è protetta con livello CIS 2
Benchmark. E una delle regole di conformità, "4.1.2.2 Garantire che gli audit log siano
non automaticamente", garantisce che l'impostazione verificata
max_log_file_action = keep_logs . Ciò porta a tutte le
e regole di audit conservate sul disco.
Soluzione:
Visualizza i passaggi della soluzione alternativa
Postazione di lavoro di amministrazione
Per la workstation di amministrazione, puoi modificare manualmente il codice
per ruotare automaticamente i log e riavviare i log
servizio:
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
Con l'impostazione precedente, i log sottoposti a audit vengono ruotati automaticamente
una volta generati più di 250 file (ognuno di 8 milioni di dimensioni).
Nodi del cluster
Per i nodi del cluster, esegui l'upgrade a 1.11.5 o versioni successive, 1.12.4 o versioni successive, 1.13.2 o versioni successive o 1.14 o versioni successive. Se
non riesci ancora a eseguire l'upgrade a queste versioni, applica il seguente DaemonSet al tuo cluster:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
Tieni presente che apportare questa modifica alla configurazione controllata violerebbe il livello CIS 2
regola "4.1.2.2 Assicurati che gli audit log non vengano eliminati automaticamente".
|
Networking |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayGroup conflitti di IP mobile con il nodo
indirizzo
Gli utenti non riescono a creare o aggiornare gli oggetti NetworkGatewayGroup
a causa del seguente errore di convalida del webhook:
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"
Nelle versioni interessate, il kubelet può associarsi erroneamente a un IP mobile
indirizzo assegnato al nodo e lo riportiamo come indirizzo del nodo
node.status.addresses . Il webhook di convalida controlla
NetworkGatewayGroup indirizzi IP variabili rispetto a tutti
node.status.addresses nel cluster e lo considera un
conflitto.
Soluzione:
Nello stesso cluster in cui la creazione o l'aggiornamento degli oggetti NetworkGatewayGroup non va a buon fine, disattiva temporaneamente il webhook di convalida ANG e invia la modifica:
- Salva la configurazione del webhook in modo che possa essere ripristinata alla fine:
kubectl -n kube-system get validatingwebhookconfiguration \
ang-validating-webhook-configuration -o yaml > webhook-config.yaml
- Modifica la configurazione del webhook:
kubectl -n kube-system edit validatingwebhookconfiguration \
ang-validating-webhook-configuration
- Rimuovi
vnetworkgatewaygroup.kb.io dall'elemento
di configurazione webhook e chiudi per applicare le modifiche.
- Crea o modifica l'oggetto
NetworkGatewayGroup .
- Riapplica la configurazione del webhook originale:
kubectl -n kube-system apply -f webhook-config.yaml
|
Installazione, upgrade, aggiornamenti |
1.10.0-1.10.2 |
Creazione o upgrade del timeout del cluster di amministrazione
Durante un tentativo di upgrade del cluster di amministrazione, la VM del piano di controllo dell'amministratore potrebbe bloccarsi durante la creazione. La VM del piano di controllo amministratore entra in
ciclo di attesa infinito durante l'avvio. Vedrai quanto segue:
errore di loop infinito in /var/log/cloud-init-output.log
file:
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1
Questo accade perché quando Google Distributed Cloud tenta di recuperare l'indirizzo IP del nodo
nello script di avvio, utilizza grep -v
ADMIN_CONTROL_PLANE_VIP per saltare il VIP del piano di controllo del cluster amministrativo
che può essere assegnato anche alla NIC. Tuttavia, il comando salta anche
qualsiasi indirizzo IP che abbia un prefisso del VIP del piano di controllo, il che causa
l'arresto anomalo dello script di avvio.
Ad esempio, supponiamo che l'indirizzo VIP del piano di controllo del cluster di amministrazione sia
192.168.1.25. Se l'indirizzo IP della VM del piano di controllo del cluster di amministrazione ha
con lo stesso prefisso, ad esempio 192.168.1.254, la VM del piano di controllo
rimangono bloccati durante la creazione. Questo problema può verificarsi anche se
l'indirizzo di trasmissione ha lo stesso prefisso del VIP del piano di controllo, ad
esempio 192.168.1.255 .
Soluzione:
- Se il motivo del timeout della creazione del cluster di amministrazione è dovuto all'indirizzo IP di trasmissione, esegui il seguente comando sulla VM del piano di controllo del cluster di amministrazione:
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
Verrà creata una riga senza indirizzo di broadcast e verrà sbloccata la
di avvio rapido. Dopo aver sbloccato lo script di avvio, rimuovi questo
aggiunta alla riga di comando eseguendo questo comando:
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
- Tuttavia, se il motivo del timeout per la creazione del cluster di amministrazione è dovuto
all'indirizzo IP della VM del piano di controllo, non puoi sbloccare
script di avvio. Passa a un indirizzo IP diverso e ricrea
aggiornalo alla versione 1.10.3 o successiva.
|
Sistema operativo, Upgrade, Aggiornamenti |
1.10.0-1.10.2 |
Lo stato del cluster di amministrazione che utilizza l'immagine COS andrà perso
upgrade del cluster di amministrazione o riparazione del master dell'amministratore
Il disco dati non può essere montato correttamente sul nodo principale del cluster di amministrazione quando si utilizza l'immagine COS e lo stato del cluster di amministrazione che utilizza l'immagine COS andrà perso durante l'upgrade del cluster di amministrazione o la riparazione del master di amministrazione. (cluster di amministrazione
utilizzando l'immagine COS è una funzionalità di anteprima)
Soluzione:
Ricrea il cluster di amministrazione con osImageType impostato su ubuntu_containerd
Dopo aver creato il cluster di amministrazione con osImageType impostato su cos, recupera
chiave SSH del cluster di amministrazione e SSH nel nodo master di amministrazione.
df -h risultato contiene /dev/sdb1 98G 209M 93G
1% /opt/data . lsblk risultato contiene -sdb1
8:17 0 100G 0 part /opt/data
|
Sistema operativo |
1,10 |
ricerca DNS non riuscita con risoluzione systemd-resolved su .local domini
In Google Distributed Cloud versione 1.10.0, le risoluzioni dei nomi su Ubuntu
vengono instradate all'ascolto locale di systemd-resolved su 127.0.0.53
per impostazione predefinita. Il motivo è che nell'immagine Ubuntu 20.04 utilizzata nella versione
1.10.0, /etc/resolv.conf è collegato simbolicamente a
/run/systemd/resolve/stub-resolv.conf , che rimanda allo stub DNS localhost
127.0.0.53 .
Di conseguenza, la risoluzione del nome DNS localhost si rifiuta di controllare
server DNS upstream (specificati in
/run/systemd/resolve/resolv.conf ) per i nomi con un
.local , a meno che i nomi non siano specificati come ricerca
domini.
Di conseguenza, le ricerche dei nomi .local non vanno a buon fine. Ad esempio, durante l'avvio del nodo, kubelet non riesce a estrarre le immagini da un registry privato con un suffisso .local . La specifica di un
indirizzo vCenter con un suffisso .local non funzionerà su una
postazione di lavoro dell'amministratore.
Soluzione:
Puoi evitare questo problema per i nodi del cluster se specifichi
Campo searchDomainsForDNS nella configurazione del cluster di amministrazione
e il file di configurazione del cluster utente per includere i domini.
Attualmente gkectl update non supporta l'aggiornamento del
searchDomainsForDNS .
Pertanto, se non hai configurato questo campo prima della creazione del cluster,
devi accedere tramite SSH ai nodi e bypassare lo stub systemd-resolved locale modificando
il link simbolico di /etc/resolv.conf da
/run/systemd/resolve/stub-resolv.conf (che contiene lo stub locale 127.0.0.53 ) a
/run/systemd/resolve/resolv.conf (che punta al DNS upstream effettivo):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Per quanto riguarda la workstation di amministrazione, gkeadm non supporta
specificare i domini di ricerca, quindi occorre risolvere il problema con questo manuale
passaggio.
Questa soluzione non viene mantenuta nelle ricreazioni delle VM. Devi
applicare nuovamente questa soluzione alternativa ogni volta che le VM vengono ric create.
|
Installazione, Sistema operativo |
1,10 |
L'IP del bridge Docker utilizza 172.17.0.1/16 anziché
169.254.123.1/24
Google Distributed Cloud specifica una subnet dedicata per l'indirizzo IP del bridge Docker che utilizza --bip=169.254.123.1/24 , in modo da non prenotare la subnet 172.17.0.1/16 predefinita. Tuttavia,
nella versione 1.10.0, c'è un bug nell'immagine del sistema operativo Ubuntu che ha causato
configurazione Docker personalizzata
da ignorare.
Di conseguenza, Docker sceglie il valore 172.17.0.1/16 predefinito come
la subnet dell'indirizzo IP del bridge. Ciò potrebbe causare un conflitto di indirizzi IP se
hai già un carico di lavoro in esecuzione nell'intervallo di indirizzi IP.
Soluzione:
Per risolvere il problema, devi rinominare il seguente file di configurazione systemd
per dockerd e riavviare il servizio:
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
/etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
sudo systemctl daemon-reload
sudo systemctl restart docker
Verifica che Docker selezioni l'indirizzo IP del bridge corretto:
ip a | grep docker0
Questa soluzione non viene mantenuta nelle ricreazioni delle VM. Devi presentare di nuovo la domanda
questa soluzione alternativa ogni volta che le VM vengono ricreate.
|
Upgrade, aggiornamenti |
1,11 |
Upgrade alla versione 1.11 bloccato dall'idoneità di Stackdriver
Nella versione 1.11.0 di Google Distributed Cloud sono presenti modifiche alla definizione delle risorse personalizzate relative a logging e monitoraggio:
- Il nome del gruppo della risorsa personalizzata
stackdriver è stato modificato da addons.sigs.k8s.io a addons.gke.io ;
- Il nome del gruppo delle risorse personalizzate
monitoring e metricsserver è stato modificato da addons.k8s.io a addons.gke.io ;
- Le specifiche delle risorse riportate sopra iniziano a essere valutate in base al relativo schema. In particolare, le specifiche resourceAttrOverride e storageSizeOverride nella risorsa personalizzata
stackdriver devono avere il tipo di stringa nei valori delle richieste e dei limiti di CPU, memoria e dimensioni dello spazio di archiviazione.
Le modifiche al nome del gruppo vengono apportate per rispettare gli aggiornamenti di CustomResourceDefinition in Kubernetes 1.22.
Non è richiesta alcuna azione se non hai una logica aggiuntiva che applica o modifica le risorse personalizzate interessate. Il processo di upgrade di Google Distributed Cloud si occuperà della migrazione delle risorse interessate e manterrà le specifiche esistenti dopo la modifica del nome del gruppo.
Tuttavia, se esegui una logica che applica o modifica le risorse interessate, è necessaria un'attenzione particolare. Innanzitutto, devi fare riferimento al nuovo nome del gruppo nel file manifest. Ad esempio:
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
In secondo luogo, assicurati che i valori delle specifiche resourceAttrOverride e storageSizeOverride siano di tipo stringa. Ad esempio:
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder
limits:
cpu: 1000m # or "1"
# cpu: 1 # integer value like this would not work
memory: 3000Mi
In caso contrario, le modifiche applicate e le modifiche non avranno effetto e potrebbero determinare uno stato imprevisto nei componenti di logging e monitoraggio. I potenziali sintomi possono includere:
- Log degli errori di riconciliazione in
onprem-user-cluster-controller , ad esempio: potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
- Errore in
kubectl edit stackdriver stackdriver , ad esempio: Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found
Se si verificano gli errori riportati sopra, significa che prima dell'upgrade era già presente un tipo non supportato nella specifica della richiesta di aggiornamento di Stackdriver. Come soluzione alternativa, puoi modificare manualmente la RP di Stackdriver con il nome precedente del gruppo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver e procedere nel seguente modo:
- Modifica le richieste e i limiti delle risorse in tipo di stringa.
- Rimuovi eventuali annotazioni
addons.gke.io/migrated-and-deprecated: true , se presenti.
Quindi riprendi o riavvia il processo di upgrade.
|
Sistema operativo |
1.7 e versioni successive |
Le VM COS non mostrano IP quando le VM vengono spostate tramite un arresto non controllato dell'host
Ogni volta che si verifica un guasto in un server ESXi e la funzione vCenter HA è stata attivata per il server, tutte le VM nel server ESXi guasto attivano il meccanismo vMotion e vengono spostate su un altro server ESXi normale. Le VM COS migrate perderebbero i propri IP.
Soluzione:
Riavvia la VM
|
Networking |
tutte le versioni precedenti a 1.14.7, 1.15.0-1.15.3, 1.16.0 |
La risposta GARP inviata da Seesaw non imposta un IP di destinazione
Il GARP (ARP gratuito) periodico inviato da Seesaw ogni 20 secondi non viene impostato
l'IP di destinazione nell'intestazione ARP. Alcune reti potrebbero non accettare questi pacchetti (come Cisco ACI). Ciò può causare un tempo di inattività del servizio più lungo dopo il recupero di un cervello diviso (a causa della perdita di pacchetti VRRP).
Soluzione:
Attiva un failover di Seeaw eseguendo sudo seesaw -c failover su una delle VM di Seesaw. In questo modo, il traffico dovrebbe essere ripristinato.
|
Sistema operativo |
1.16, 1.28.0-1.28.200 |
Il kubelet è inondato di log che indicano che "/etc/kubernetes/manifests" non esiste sui nodi worker
"staticPodPath" è stato impostato per errore per i nodi worker
Soluzione:
Creare manualmente la cartella "/etc/kubernetes/manifests".
|