Google Distributed Cloud (solo software) per problemi noti di VMware

In questa pagina sono elencati tutti i problemi noti di Google Distributed Cloud on VMware. Per filtrare noti in base a una versione o categoria di prodotto, seleziona i filtri desiderati i seguenti menu a discesa.

Seleziona la versione di Google Distributed Cloud:

Seleziona la categoria del problema:

In alternativa, cerca il problema:

Categoria Versioni identificate Problema e soluzione alternativa
Aggiornamenti 1.29.0

Dopo la migrazione di un cluster utente al piano di controllo V2, il cluster di amministrazione il PDB di Metrics-server potrebbe essere configurato in modo errato

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 ci sono nodi oggetti senza ruolo, esegui questo 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 La diagnostica del cluster di amministrazione 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 la mancata visualizzazione di uno dei pool di nodi

In condizioni di gara rare, una sequenza di installazione errata del webhook Autorizzazione binaria e del pod gke-connect potrebbe causare l'arresto della creazione del cluster utente perché un nodo non riesce a raggiungere lo stato Pronto. Negli scenari interessati, la creazione del cluster utente potrebbe bloccarsi perché un nodo non raggiunge lo stato di pronto. In questo caso, verrà visualizzato il seguente messaggio:

     Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready

Soluzione:

  1. Rimuovi la configurazione di Autorizzazione binaria dal file di configurazione. Per istruzioni sulla configurazione, consulta la Guida all'installazione del giorno 2 di Autorizzazione binaria per GKE su VMware.
  2. Per sbloccare un nodo non integro durante l'attuale processo di creazione del cluster, rimuovi temporaneamente la configurazione del webhook Autorizzazione binaria nel cluster utente utilizzando il comando seguente. 
            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 della macchina con mirroring con deletionTimestamp

Durante l'upgrade di un cluster utente, l'operazione di upgrade potrebbe bloccarsi se l'oggetto della macchina sottoposta 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 l'utente dal nodo del piano di controllo eseguendo gkectl delete machine con mirroring nel cluster utente.

Soluzione:

  1. Recupera l'oggetto della macchina sottoposta a mirroring e salvalo in un file locale per il backup scopi.
  2. 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
  3. 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.
  4. Esegui di nuovo gkectl upgrade cluster per riprendere l'upgrade
Configurazione, installazione 1,15; 1,16; 1,28; 1,29

Errore di creazione del cluster a causa del VIP del piano di controllo in una subnet diversa

Per il cluster di amministrazione ad alta disponibilità o per il cluster utente ControlPlane V2, il piano di controllo Il VIP 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 viene generato 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 applicare l'utilizzo di nomi utente di dominio completi.

Soluzione:

Utilizza un nome di dominio completo per il nome utente 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. La per i cluster creati con le versioni 1.10 e precedenti che è stato aggiornato completamente alla versione 1.16 e il certificato foglia non era ruotati prima dell'upgrade.

Per determinare se l'errore di upgrade del cluster di amministrazione è causato da questo errore, segui questi passaggi:

  1. Connettiti alla macchina master di amministrazione che non è riuscita utilizzando SSH.
  2. 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:

  1. Connettiti alla macchina master di amministrazione mediante SSH. Per maggiori dettagli, vedi Utilizzo di SSH per la connessione a un nodo del cluster di amministrazione.
  2. Modifica /etc/startup/pki-yaml.sh. Trova authorityKeyIdentifier=keyidset e modificala in authorityKeyIdentifier=keyid,issuer nelle sezioni per le seguenti estensioni: apiserver_ext client_ext etcd_server_ext e kubelet_server_ext. Per esempio: 
          [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names
  3. Salva le modifiche apportate a /etc/startup/pki-yaml.sh.
  4. Esegui /opt/bin/master.sh per generare il certificato e per completare l'avvio della macchina.
  5. Esegui di nuovo gkectl upgrade admin per eseguire l'upgrade dell'amministratore in un cluster Kubernetes.
  6. Al termine dell'upgrade, ruota il certificato foglia per entrambi gli amministratori e i cluster utente, come descritto in Avviare la rotazione.
  7. Al termine della rotazione dei certificati, apporta le stesse modifiche /etc/startup/pki-yaml.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 tranquillamente ignorare questo avviso.
Configurazione 1.28.0-1.28.400, 1.29.0

Il controllo preflight per l'installazione del cluster di amministrazione ad alta disponibilità 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 preflight errato in una release non corretta, aggiungi --skip-validation-net-config a gkectl .
Operazione 1.29.0-1.29.100

L'agente Connect perde la connessione a Google Cloud in seguito all'assenza di alta disponibilità ad alta disponibilità migrazione del cluster di amministrazione

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 dell'Arabia Saudita viene è stata modificata, pertanto è necessaria una nuova registrazione per aggiornare i 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 rieseguire sempre il deployment di gke-connect ed eseguire nuovamente la registrazione il cluster se non rileva alcun deployment gke-connect esistente disponibili.

Dopo la soluzione alternativa (potrebbero essere necessari alcuni minuti completare la riconciliazione), puoi verificare che il messaggio "Non è stato possibile verifica firma JWT" L'errore 400 non è 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 usa 172.17.0.1/16 per i nodi del piano di controllo del cluster COS

Google Distributed Cloud specifica una subnet dedicata, --bip=169.254.123.1/24, per l'IP del bridge Docker nella alla configurazione Docker per evitare di prenotare la configurazione predefinita 172.17.0.1/16 subnet. 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 il valore 172.17.0.1/16 predefinito come alla subnet dell'indirizzo IP del bridge. Ciò potrebbe causare un conflitto di indirizzi IP se un carico di lavoro è in esecuzione all'interno di quell'intervallo di indirizzi IP.

Soluzione:

Per aggirare il problema, devi riavviare il servizio docker:

sudo systemctl restart docker

Verifica che Docker scelga l'indirizzo IP del bridge corretto:

ip a | grep docker0

Questa soluzione non viene mantenuto durante le riproduzioni di 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 nella versions. Questi file binari CNI non sono utilizzati dal piano dati v2, ma possono essere usati per interfacce di rete aggiuntive nella funzione 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 utente.

Soluzione:

  • Disabilita multipathd
Aggiornamenti 1,15, 1,16

Il webhook del cluster di amministrazione potrebbe bloccare gli aggiornamenti quando aggiungi 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 è impostata su "ManualLB"), non occorre configurare loadBalancer.manualLB del file di configurazione per un amministratore ad alta disponibilità 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 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 dopo l'upgrade alla versione 1.28 il log contiene una voce simile alla seguente, hai riscontrato questo problema: 
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.

Quindi, applica il seguente DaemonSet al tuo 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. Consulta le istruzioni.
Logging e monitoraggio 1.28.0-1.28.100

L'API Metadata di Kubernetes non supporta VPC-SC

L'API aggiunta di recente kubernetesmetadata.googleapis.com non supporta VPC-SC. Questo impedisce all'agente di raccolta dei metadati di raggiungere questa API in VPC-SC. Dopodiché, le etichette dei metadati delle metriche non saranno più disponibili.

Soluzione:

Imposta nello spazio dei nomi "kube-system", la RP "stackdriver" per impostare il campo "featureGates.disableExperimentalMetadataAgent" su "true" eseguendo il comando

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

quindi 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 cluster di amministrazione, il controller 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:

  1. 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 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
  2. 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:

  1. Silenziare l'avviso dall'interfaccia utente di Gestore avvisi.
  2. Se non è possibile silenziare l'avviso, segui questi passaggi per sopprimere i falsi positivi:
    1. Fai lo scale down dell'operatore di monitoraggio a 0 replica in modo da che le modifiche possano persistere.
    2. Modifica la configmap prometheus-config e aggiungi grpc_method!="Watch" al Configurazione degli avvisi etcdHighNumberOfFailedGRPCRequests come mostrato nel seguente esempio:
      • Originale: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Modificato: 
        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.
    3. Riavvia Prometheus e Alertmanager Statefulset per recuperare una nuova configurazione.
  3. 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 di lunga durata NAT in uscita vengono eliminate

Le connessioni NAT in uscita potrebbero essere eliminate dopo 5-10 minuti di connessione in corso se non c'è traffico.

Poiché il collegamento è importante solo nella direzione in entrata (esterno al cluster), questo problema si verifica solo se la connessione per un po' di tempo non trasmette alcuna informazione 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 garbage collection anetd inavvertitamente rimuove le voci di connessione che il daemon ritiene non utilizzate. Una soluzione upstream è stato recentemente integrato in Google Ads per correggere questo comportamento.


Soluzione:

Non esiste una soluzione alternativa facile e non abbiamo riscontrato problemi nella versione 1.16 da 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 del CSR ignora spec.expirationSeconds durante la firma 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 se è presente un carico durante i controlli preflight. Anche se questo controllo non è necessario se disattivi il traffico in entrata in bundle, gkectl il controllo preflight non va a buon fine quando 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 disabilita il traffico in entrata 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 delle 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 hai riscontrato questo problema, puoi aggiornare il cluster di amministrazione utilizzando il flag --disable-update-from-checkpoint con 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 valore 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 del carico di lavoro CSI convalida che il driver CSI vSphere sia installato e possa eseguire volumi dinamici per eseguire il provisioning. 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 inserimento automatico del file collaterale Istio abilitato in default , il pod del carico di lavoro CSI non viene avviato.

Se il pod del carico di lavoro CSI non si avvia, viene visualizzato un errore di timeout come durante le convalide preflight:

- [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 del carico di lavoro CSI, lo stato del job contiene un messaggio di errore simile al 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 file collaterale Istio nella default. Controlla le etichette dello spazio dei nomi e utilizza questo 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 volume Il provisioning con il driver CSI vSphere funziona:

  1. Crea una PVC che utilizza il valore di StorageClass standard-rwo.
  2. Crea un pod che utilizza la PVC.
  3. Verifica che il pod possa leggere/scrivere dati nel volume.
  4. Rimuovi il pod e la PVC dopo aver verificato il corretto funzionamento.

Se il provisioning del volume dinamico con il driver CSI vSphere funziona, esegui gkectl diagnose o gkectl upgrade con il flag --skip-validation-csi-workload per saltare la funzione CSI Controllo del carico di lavoro.

Operazione 1.16.0-1.16.2

Timeout dell'aggiornamento del cluster utente 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. In questo caso, vedrai il seguente errore quando cerchi 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, 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:

  1. Esegui questo comando per rieseguire il deployment di validation-controller: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Al termine della preparazione, esegui di nuovo gkectl update cluster per aggiornare il cluster utente
Operazione 1.16.0-1.16.2

Timeout della creazione del cluster utente 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. In questo caso, vedrai il seguente errore quando provi a 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:

  1. Esegui questo comando per eseguire il deployment di validation-controller: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. 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 di amministrazione non va a buon fine se i progetti o le località i 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 nella di tipo cluster, il webhook del cluster di amministrazione non è in grado di distinguere se L'oggetto OnPremAdminCluster è destinato alla creazione di un cluster di amministrazione, o riprendere le operazioni per un aggiornamento o un upgrade. Alcuni asset 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:

  1. 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.
  2. Aggiungi il parametro onprem.cluster.gke.io/skip-project-location-sameness-validation: true e salvare la risorsa personalizzata.
  3. A seconda del tipo di cluster di amministrazione, completa una delle seguenti passaggi:
    • Per i cluster di amministrazione non ad alta disponibilità con un file di checkpoint: aggiungi parametro disable-update-from-checkpoint nel o aggiungere 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 va a buon fine quando si utilizza una workstation di amministrazione gestita dall'utente

Quando hai eseguito l'accesso a un workstation di amministrazione gestita dall'utente, 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. In questo caso, quando provi a eliminare il cluster viene visualizzato il seguente errore: 

      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. La l'eliminazione degli oggetti Validation (creati durante il processo aggiornamento o upgrade) sono bloccati nella fase di eliminazione. Ciò accade poiché un finalizzatore blocca l'eliminazione dell'oggetto, che l'eliminazione del cluster non vada a buon fine.

Soluzione:

  1. Ottieni i nomi di tutti gli oggetti Validation: 
             kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. Per ogni oggetto Validation, esegui questo comando per rimuovere finale 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 un'applicazione o un servizio esterno sia riuscito.

Questo problema è causato dall'eliminazione dei pacchetti VXLAN da parte di vSphere durante il tunnel e l'aggregazione sia abilitata. Esiste un problema noto con NSX e VMware che invia traffico aggregato solo sulle porte VXLAN note (4789).


Soluzione:

Cambia la porta VXLAN utilizzata da Cilium in 4789:

  1. Modifica il ConfigMap cilium-config: 
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Aggiungi quanto segue al ConfigMap cilium-config: 
    tunnel-port: 4789
  3. Riavvia il DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Questa soluzione alternativa ripristina 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 crittografia dei secret sempre attivi abilitata non riesce

L'upgrade del cluster di amministrazione dalla versione 1.14.x alla versione 1.15.x con sempre attiva la crittografia dei secret abilitata non riesce a causa di una mancata corrispondenza tra di crittografia generata dal controller con la chiave che persiste nella il disco 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 riesce e restituisce il 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 soluzione alternativa se l'upgrade non è riuscito:

  1. 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
  2. Una volta creata la nuova VM master di amministrazione, accedi tramite SSH alla VM master di amministrazione sostituisca la nuova chiave sul disco dati con quella precedente backup. La chiave si trova all'indirizzo /opt/data/gke-k8s-kms-plugin/generatedkeys nel master di amministrazione.
  3. 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.
  4. Riavvia il pod statico kms-plugin spostando il pulsante /etc/kubernetes/manifests/kms-plugin.yaml a un altro nella directory precedente, quindi la sposti nella nuova directory.
  5. Riprendi l'upgrade amministrativo eseguendo di nuovo gkectl upgrade admin.

Come 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, procedi nel seguente modo: Segui questi passaggi prima di eseguire l'upgrade del cluster di amministrazione:

  1. Esegui il backup del cluster di amministrazione.
  2. 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
  3. Esegui l'upgrade del cluster di amministrazione.
  4. Crittografia dei secret sempre attivi affidabili.
Archiviazione 1,11-1,16

Errori del disco e errori di collegamento quando si utilizza il monitoraggio del blocco modificato (CBT)

Google Distributed Cloud non supporta il monitoraggio del blocco modificato (CBT) su i dischi permanenti. Alcuni software di backup utilizzano la funzione CBT per tenere traccia dello stato del disco e eseguire backup, impedendo la connessione del disco 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 come software di backup di terze parti potrebbero causare l'abilitazione della CBT sui loro dischi. Non è necessario specificare per configurare queste VM.

Non abilitare CBT sul nodo, poiché questa modifica non verrà applicata aggiornamenti o upgrade.

Se disponi già di dischi con CBT abilitata, segui le Passaggi per la risoluzione dei problemi nella Knowledge base per VMware per disabilitare CBT sul disco di prima classe.
Archiviazione 1,14, 1,15 e 1,16

Danneggiamento dei dati su NFSv3 quando vengono aggiunte parallele a un file condiviso eseguito da più host

Se usi array di archiviazione Nutanix per fornire condivisioni NFSv3 ai tuoi host, potresti riscontrare il danneggiamento dei dati o l'incapacità dei pod di dell'esecuzione. Questo problema è causato da un problema di compatibilità noto tra alcune versioni di VMware e Nutanix. Per ulteriori informazioni informazioni, vedi le informazioni associate Knowledge base per VMware .


Soluzione:

L'articolo della knowledge base di VMware è obsoleto in quanto non esiste 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 sul tuo spazio di archiviazione. di grandi dimensioni.
Sistema operativo 1.13.10, 1.14.6, 1.15.3

Mancata corrispondenza delle versioni tra 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. C'è un perché il file binario kubelet precaricato sull'immagine del sistema operativo utilizza un un'altra versione.

La seguente tabella elenca le versioni non corrispondenti identificate:

Versione 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 va a buon fine a causa della convalida della versione della CA tramite 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. Questa operazione è necessaria perché è stato introdotto un nuovo campo nella risorsa personalizzata del cluster di amministrazione 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 un cluster V2 del piano di controllo non ad alta disponibilità viene eliminato, rimane bloccato sul nodo 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 vSphere oppure esegui il comando seguente: 
          govc vm.destroy
    .
  • Forza di nuovo l'eliminazione del 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

Ogni minuto vengono visualizzate attività di collegamento volume costante del CNS per le risorse PVC/PV in-albero dopo l'upgrade alla versione 1.15 o successive

Quando un cluster contiene volumi permanenti vSphere all'interno della struttura (ad esempio, PVC create con StorageClass standard), osserverai attività com.vmware.cns.tasks.attachvolume attivate ogni minuto da vCenter.


Soluzione:

Modifica la funzionalità 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 nei confronti delle PVC

Quando un cluster contiene volumi permanenti Intree vSphere, i comandi gkectl diagnose e gkectl upgrade potrebbero aumentare falsi avvisi relativi alle richieste di volumi permanenti (PVC) quando e convalidare le impostazioni di archiviazione del cluster. Il messaggio di avviso ha il seguente aspetto: quanto segue 

    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 questo comando per controllare le annotazioni di una PVC con il precedente:

    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

Rotazione della chiave dell'account di servizio non va a buon fine se più chiavi sono scadute

Se il cluster non utilizza un registro privato e il componente accesso alla chiave dell'account di servizio e monitoraggio di Logging (o Connect-register) le chiavi degli account di servizio siano scadute, quando ruota il chiavi dell'account di servizio, gkectl update credentials genera 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

1.15 La macchina master dell'utente subisce una ricreazione 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 ricreazione della macchina master per l'utente 1.15.

La soluzione alternativa che puoi adottare dipende da come riscontri questo 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:

  1. 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 per la ripetizione è:

    onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Monitora l'avanzamento dell'upgrade controllando il campo status dell'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:

  1. Aggiungi il file con le informazioni sulla build /etc/cloud/build.info con il seguente contenuto. 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
  2. Esegui di nuovo il comando di upgrade.
  3. Al termine dell'upgrade, elimina il file build.info.
Crea 1.16.0-1.16.5, 1.28.0-1.28.100

Il controllo preflight ha esito negativo quando il nome host non è nel file dei blocchi 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.`

Nel controllo preflight è presente un bug che presuppone che un nome host vuoto sia duplicato.

Soluzione:

Opzione 1: utilizza una versione con la correzione.

Opzione 2: evita questo controllo preflight aggiungendo il flag --skip-validation-net-config.

Opzione 3: specifica un nome host univoco per ciascun indirizzo IP nel file dei blocchi 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 v1 del piano di controllo, quando esegui l'upgrade o l'aggiornamento del cluster di amministrazione, la ricreazione della macchina master del cluster di amministrazione potrebbe avvenire in contemporanea al riavvio della macchina master del cluster utente, che può generare una race condition. Di conseguenza, i pod del piano di controllo del cluster utente non sono in grado di comunicare con il piano di controllo del cluster di amministrazione, causando problemi di collegamento del volume per kube-etcd e kube-apiserver sul piano di controllo del cluster utente.

Per verificare il problema, esegui questi 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:

  1. 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.
  2. 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, potrebbe essere una race condition il gestore di Cloud Controller vSphere elimina inaspettatamente un nuovo dal nodo del piano di controllo. Questo fa sì che il controller clusterapi-controller sia bloccato in attesa della creazione del nodo e persino l'upgrade/l'aggiornamento si verifica un timeout. 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 seguente per ottenere 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:

  1. Riavvia la macchina in errore per ricreare l'oggetto nodo eliminato.
  2. 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
  3. Esegui di nuovo il comando upgrade/update.
Operazione 1,16

Un nome host duplicato nello stesso data center causa errori di upgrade o creazione del cluster

L'upgrade di un cluster 1.15 o la creazione di un cluster 1.16 con IP statici non riesce se sono presenti duplicati più nomi host dello stesso data center. Questo errore si verifica perché Il gestore Cloud Controller di vSphere non riesce ad aggiungere un IP esterno e un provider nell'oggetto node. Questo causa il timeout dell'upgrade o della creazione del cluster.

Per identificare il problema, recupera i log dei pod di Cloud Controller Manager 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:

Esegui la soluzione alternativa per il tipo di cluster applicabile.

  • Cluster utente:
    1. 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
    2. Esegui nuovamente gkectl upgrade cluster
  • Cluster di amministrazione:
    1. 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
    2. Se si tratta di un cluster di amministrazione non ad alta disponibilità e noti che la VM master di amministrazione utilizza un nome host duplicato, devi anche:
      Ottieni nome macchina master amministratore 
                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 macchina master 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}'
    3. Esegui di nuovo l'upgrade del cluster di amministrazione con il checkpoint disabilitato:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Soluzione alternativa per le installazioni:

Esegui 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 Controlplane V2 abilitato
  • Creazione di un cluster di amministrazione ad alta disponibilità 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:

  1. Modifica il nome utente o la password vCenter sul lato vCenter per rimuovere $ e `.
  2. Aggiorna il nome utente o la password vCenter nel tuo credentials di configurazione del deployment.
  3. Attiva un aggiornamento forzato del cluster.
    • Cluster utente: 
              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:

  1. Modifica il nome utente o la password vCenter sul lato vCenter per rimuovere $ e `.
  2. Aggiorna il nome utente o la password vCenter nel tuo credentials di configurazione del deployment.
  3. Esegui la soluzione alternativa per il tipo di cluster applicabile.
Archiviazione 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

Errore di creazione PVC dopo la creazione di un 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

Ciò è causato da race condition, per cui il controller CSI vSphere 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 riparazioni admin-master restituisce un errore di unmarshall di 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 di VM della macchina:

  1. Vai alla pagina Host e cluster nel client vSphere.
  2. Fai clic su Modelli VM e filtra in base al nome del cluster di amministrazione.

    Dovresti vedere i tre modelli di VM per il cluster di amministrazione.

  3. 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 sulla VM è in esaurimento perché il bit fluente in esecuzione sulla VM Seesaw non è configurata 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. Pulisci il file di log con le dimensioni massime 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 ricollegalo alla VM originale di Seesaw.

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 nel 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 di amministrazione 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 viene registrato nell'API GKE On-Prem, l'upgrade del cluster alle versioni interessate potrebbe non riuscire perché l'appartenenza al parco risorse Impossibile aggiornare. 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 registrare esplicitamente il o quando esegui l'upgrade 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 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

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 registrare esplicitamente il o quando esegui l'upgrade 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 registrati nuovamente di nuovo nel cluster di amministrazione.
Networking 1.15.0-1.15.2

CoreDNS orderPolicy non riconosciuto

Il parametro OrderPolicy non viene riconosciuto come parametro non viene utilizzato. Google Distributed Cloud utilizza sempre Random.

Questo problema si verifica perché il modello CoreDNS non è stato aggiornato, fa sì che orderPolicy venga ignorato.


Soluzione:

Aggiorna il modello CoreDNS e applica la correzione. Questa correzione persiste fino al un upgrade.

  1. 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 tuo cluster di amministrazione, in particolare per i cluster della versione 1.15.

Se hai questo problema, potresti riscontrare problemi come seguenti:

  • I certificati non validi possono causare un timeout dei comandi seguenti e restituiscono errori:
    • gkectl create admin
    • gkectl upgrade amdin
    • gkectl update admin

    Questi comandi potrebbero restituire errori di autorizzazione come i seguenti:

    Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
  • I log kube-apiserver per il cluster di amministrazione potrebbero contenere errori ad esempio: 
    Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

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 del gateway di rete in kube-system potrebbero mostrare lo stato Pending o Evicted, come mostrato di seguito output di esempio ridotto:

$ 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 eliminazione o l'impossibilità di pianificare i pod a causa delle risorse del nodo. Poiché i pod del gateway di rete Anthos non hanno PriorityClass, hanno la stessa priorità predefinita degli altri carichi di lavoro. Quando i nodi sono vincolati alle risorse, i pod del gateway di rete potrebbero rimosso. 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 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 PriorityClass system-cluster-critical al Cluster ang-controller-manager e autoscaler deployment di controller.
  • Assegna il PriorityClass system-node-critical al DaemonSet di 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 di amministrazione con un campo non vuoto gkeConnect, potresti visualizzare il seguente errore quando provi a 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
Ottieni 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 Comandi journalctl in esecuzione sui nodi del cluster

Ciò non influisce sulla funzionalità di creazione di uno snapshot del poiché lo snapshot include ancora tutti i log raccolti per impostazione predefinita eseguendo journalctl sui nodi del cluster. Pertanto, informazioni di debug non perse.
Installazione, upgrade, aggiornamenti 1.9+, 1.10+, 1.11+, 1.12+

Errore di gkectl prepare windows

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 risolvere questo problema è l'upgrade a Google Distributed Cloud 1.13 e useremo 1.13 gkectl per creare un modello di VM Windows, quindi Pool di nodi Windows. Esistono due opzioni per accedere a Google Distributed Cloud 1.13 dal tuo alla versione attuale, 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: saranno necessarie risorse aggiuntive per eseguire il provisioning del nuovo cluster, ma di riduzione dei 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.

  1. Elimina i pool di nodi Windows esistenti rimuovendo i pool di nodi Windows dal file user-cluster.yaml, quindi esegui il comando: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. 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.
  3. (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
  4. Esegui l'upgrade dei cluster amministratore+utente solo Linux alla versione 1.13 seguendo le Guida dell'utente per l'upgrade.
  5. Prepara il modello di VM Windows utilizzando 1.13 gkectl: 
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. 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.
  7. 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 a ubuntu nodi

Il valore predefinito di 5 secondi per RootDistanceMaxSec sarà sui nodi, invece di 20 secondi, che dovrebbe essere il tempo configurazione. Se controlli il log di avvio del nodo accedendo tramite SSH alla VM, che si trova in "/var/log/startup.log", puoi trovare quanto segue: errore:

+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

L'utilizzo di un RootDistanceMaxSec di 5 secondi potrebbe causare il problema orologio non sia sincronizzato con il server NTP quando la deviazione dell'orologio è maggiore di 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 la versione 1.13 o 1.14 di cluster, nella risposta potrebbe essere visualizzato 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

SNI non funziona sui cluster utente con Controlplane V2

La possibilità di fornire un certificato di servizio aggiuntivo per il server API Kubernetes di un cluster utente authentication.sni non funziona quando il piano di controllo V2 è attivata ( 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 amministratore

La macchina del piano di controllo amministratore 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 falsi positivi sulle modifiche non supportate durante l'aggiornamento del cluster di amministrazione

Quando aggiorna i cluster di amministrazione, nel log vedrai i seguenti avvisi 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:
  1. 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
  2. Copia il secret della chiave di firma ksa e denomina il secret copiato come 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 -
  3. Elimina il precedente secret della chiave ksa-signing-key: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. 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
  5. Disabilita 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
'
  6. 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
  7. 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
  8. 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
'
  9. Evita la rotazione di un'altra chiave di firma Arabia Saudita finché il cluster non viene aggiornato alla versione con la correzione.
Operazione 1.13.1+, 1.14, 1., 1,16

La pulizia dei server virtuali BIG-IP di F5 non viene eseguita quando Terraform elimina i cluster utente

Quando usi Terraform per eliminare un cluster utente con un carico BIG-IP F5. , i server virtuali F5 BIG-IP non vengono rimossi dopo il cluster l'eliminazione dei dati.


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 della versione 1.13.8 o 1.14.4, oppure aggiornare un cluster di amministrazione alla versione 1.13.8 o 1.14.4, il cluster di tipo esegue il pull le seguenti immagini container 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 le seguenti:

    ...
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 nel container del cluster del tipo dell'immagine. 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 comandi seguenti 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 piano di controllo ad alta disponibilità quando la rete filtra le richieste GARP duplicate

    Se le VM del cluster sono connesse con uno switch che filtra le richieste GARP (ARP gratuito) duplicate, L'elezione dei leader mantenuti in vita potrebbe incontrare una race condition, che causa la presenza di voci errate nella tabella ARP 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 1.13 e versioni 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 riesce 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 "riuscire" senza essere registrati a un parco risorse.

    Per identificare il sintomo, puoi cercare i seguenti messaggi di errore nel log "gkectl create admin". 
    Failed to register admin cluster

    Puoi anche verificare se riesci a trovare il cluster tra i cluster registrati su Cloud Console.

    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 con versioni precedenti,

    1. Aggiungi una coppia chiave-valore falsa come "foo: bar" al file di chiave SA connect-register
    2. 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 si verifica il timeout dei nodi del piano di controllo utente durante l'upgrade, il cluster di amministrazione non verrà registrato nuovamente con la versione aggiornata dell'agente di connessione.


    Soluzione:

    Controlla se il cluster viene visualizzato 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 versioni successive, segui le istruzioni per ritentare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster di cui è stato eseguito l'upgrade a versioni precedenti,
    1. Aggiungi una coppia chiave-valore falsa come "foo: bar" al file di chiave SA connect-register
    2. 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 tranquillamente ignorare questo messaggio di errore.
    VMware 1.15.0

    La creazione del pool di nodi non riesce a causa di regole di affinità host VM-host ridondanti

    Durante la creazione di un pool di nodi che utilizza Affinità VM-host, una race condition può comportare più incidenti Regole di affinità host VM che viene creato 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 nuovamente in sicurezza fino a quando .
    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 predicato NodeAffinity errore. 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

    OnPremUserCluster non pronto a causa delle credenziali del registro private

    Se utilizzi credenziali preparate e un registro privato, ma non hai configurato le credenziali preparate il tuo registro privato, OnPremUserCluster potrebbe non essere pronto e è possibile che venga visualizzato 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

    gkectl upgrade admin non riesce con StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

    Durante il periodo gkectl upgrade admin, il controllo preflight dello spazio di archiviazione per la migrazione CSI verifica che le classi di archiviazione non abbiano parametri che vengono ignorati dopo la migrazione CSI. Ad esempio, se esiste un oggetto StorageClass con il parametro diskformat gkectl upgrade admin segnala l'oggetto StorageClass e segnala un errore nella convalida preflight. I cluster di amministrazione creati in Google Distributed Cloud 1.10 e precedenti hanno un oggetto StorageClass con diskformat: thin il che causerà l'esito negativo di questa convalida, tuttavia questo oggetto StorageClass funziona ancora dopo la migrazione CSI. Questi errori dovrebbero 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 migrati in-albero utilizzando il file system di Windows non possono essere utilizzati con il driver CSI vSphere

    In determinate condizioni i dischi possono essere collegati in sola lettura a Windows nodi. Ciò fa sì che il volume corrispondente sia di sola lettura all'interno di un pod. È più probabile che questo problema si verifichi quando un nuovo insieme di nodi sostituisce un vecchio set di nodi. un 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 insieme di nodi.


    Soluzione:

    1. 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"}'
    2. Usa l'oggetto PersistentVolumeClaim per trovare il nome del PersistentVolume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determina il nome del nodo in cui viene eseguito il pod: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Ottenere l'accesso tramite PowerShell al nodo tramite SSH o vSphere. a riga di comando.
    5. Imposta le variabili di ambiente: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. 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
    7. Verifica che il disco sia readonly: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Il risultato dovrebbe essere True.
    8. Imposta readonly su false. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Elimina il pod in modo che venga riavviato: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. 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: aggiornando le credenziali del cluster, potresti trovare vsphere-csi-secret nello spazio dei nomi kube-system nel cluster di amministrazione che utilizza ancora la vecchia credenziale.


    Soluzione:

    1. Ottieni il nome del secret vsphere-csi-secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. 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 \
    )\"}}"
    3. Riavvia vsphere-csi-controller: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. 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 aggiornato dovrebbe essere utilizzato.
    Upgrade, aggiornamenti 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    CrashLoop di audit-proxy durante l'abilitazione di Cloud Audit Logs 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 v2 del piano di controllo con enableControlplaneV2: true, connettiti alla macchina del piano di controllo utente tramite SSH e aggiorna /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME.

    Per un cluster utente v1 del piano di controllo, modifica il container audit-proxy in lo 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, potrebbe essere eseguito nuovamente il deployment dei pod del piano di controllo. Lo stato del cluster da gkectl list clusters è passato 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

    È stata rimossa la release non valida 1.12.7-gke.19

    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 registro 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.

    Il problema verrà risolto nelle release 1.13.8 di Google Distributed Cloud. 1.14.4 e versioni successive.


    Soluzione:

    Opzione 1: riesegui il deployment di gke-connect-agent manualmente:

    1. Elimina lo spazio dei nomi gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Esegui di nuovo il deployment di gke-connect-agent con il registro originale chiave dell'account di servizio (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 utente: 
      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 secret pull dell'immagine predefinito per il cluster in il deployment di gke-connect-agent:

    1. Copia il secret predefinito 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 -
    2. Ottieni il nome del deployment gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. 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 riuscirà e verrà visualizzato il seguente messaggio 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: è possibile utilizzare la versione patch 1.13.7 e 1.14.4 che includerà 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 osserva le modifiche ai pod

    Questi problemi possono rendere il cluster non funzionante.

    Questo problema è stato risolto nelle release 1.12.7, 1.13.6 di Google Distributed Cloud 1.14.3 e versioni 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 alternativa

    Se non puoi eseguire l'upgrade immediatamente, puoi ridurre il rischio degli errori del cluster riducendo il numero di nodi al suo interno. Rimuovi nodi fino a quando etcd_network_client_grpc_sent_bytes_total è inferiore a 300 Mbps.

    Per visualizzare questa metrica in Metrics Explorer:

    1. Vai a Metrics Explorer nella console Google Cloud:

      Vai a Esplora metriche

    2. Seleziona la scheda Configurazione.
    3. Espandi Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri e poi utilizza i sottomenu per selezionare la metrica:
      1. Nel menu Risorse attive, seleziona Container Kubernetes.
      2. Nel menu Categorie metriche attive, seleziona Anthos.
      3. Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total.
      4. 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ò ricevere sovraccaricato da traffico costituito da token JWT scaduti inoltrati da kube-apiserver al servizio di identità GKE tramite webhook di autenticazione. Sebbene GKE Identity Service non non risponde e smette di gestire ulteriori richieste. Questo problema porta a una latenza maggiore nel piano di controllo.

    Questo problema è stato risolto nelle seguenti release di Google Distributed Cloud:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Per determinare se il problema ti riguarda, procedi nel seguente modo:

    1. 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 la porta VIP e bilanciatore del carico del piano di controllo (ad esempio 172.16.20.50:443).

      Se hai riscontrato questo problema, il comando restituisce un 400 codice di stato. Se la richiesta scade, riavvia il pod ais e esegui nuovamente 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.

    2. Controlla i log di GKE Identity Service e kube-apiserver:
      1. 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 simile alla seguente, hai riscontrato questo problema:

        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:
      2. Controlla i log 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 puoi eseguire subito l'upgrade dei cluster per risolvere il problema, puoi come soluzione alternativa per identificare e riavviare i pod che causano problemi:

    1. Aumenta il livello di dettaglio del servizio di identità GKE 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
    2. Controlla nel log del servizio di identità GKE il contesto del token non valido: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. 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
    4. Per decodificare il token e vedere il nome e lo spazio dei nomi del pod di origine, copia il token al debugger all'indirizzo jwt.io.
    5. 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

    Sono interessati i pod di manutenzione etcd che utilizzano l'immagine etcddefrag:gke_master_etcddefrag_20210211.00_p0. Il container "etcddefrag" apre una nuova connessione al server etcd durante ogni ciclo di deframmentazione e le vecchie connessioni non vengono ripulite.


    Soluzione:

    Opzione 1: Eseguire l'aggiornamento alla versione più recente della patch dalla 1.8 alla 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 ignorare i pod del piano di controllo utente per errore. 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 verificare l'integrità dei pod del piano di controllo, puoi eseguire questi 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 workstation di amministrazione e il proxy non consente registry.k8s.io e l'immagine container k8s.gcr.io/pause:3.2 non viene memorizzata nella cache localmente, gli upgrade del cluster di amministrazione non riusciranno quando esegui il pull dell'immagine container.


    Soluzione:

    Aggiungi registry.k8s.io alla lista consentita del proxy per la 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 e restituisce 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

    Ciò è dovuto all'esistenza del file del gruppo di altalena altalena. Il controllo preflight per convalidare un bilanciatore del carico per altalena inesistente.

    Soluzione:

    Rimuovi il file del gruppo altalena 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. Gli errori di inserimento generano timeout dell'applicazione e possono verificarsi anche quando la tabella di connessione ha spazio per le nuove voci. Gli errori sono causati da modifiche in kernel 5.15 e successivi che limitano gli inserimenti di tabelle in base alla catena lunghezza.

    Per vedere se hai riscontrato questo problema, puoi controllare la visualizzazione delle statistiche del sistema di monitoraggio delle connessioni su ciascun nodo, con le :

    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 è diverso da zero numero di telefono, hai riscontrato questo problema.

    Soluzione alternativa

    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. La il valore predefinito per le dimensioni 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

    Calico-typha o anetd-operator Crash loop 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 deployment tollerano tutte le incompatibilità, inclusa quella dei nodi Windows.


    Soluzione:

    Esegui l'upgrade alla versione 1.13.3+ oppure esegui i comandi seguenti per modificare il deployment "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 il seguente spec.template.spec.tolerations:

        - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    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 registro privato del cluster utente

    Potresti non essere in grado di creare un cluster utente se specifichi la Sezione privateRegistry con credenziale fileRef. Potrebbe verificarsi un errore preflight 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.
    • Per utilizzare una credenziale di registro privata specifica cluster utente, puoi specificare temporaneamente privateRegistry sezione in questo 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à gratuita kube-proxy per perdita di connettività o instradamento del traffico non corretto per i servizi con Cloud Service Mesh, in quanto il file collaterale 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 con forza dopo 6 minuti

    kube-controller-manager potrebbe scadere durante lo scollegamento PV/PVC dopo 6 minuti e scollegali con forza. 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 è bloccato 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 --skip-validation-all .
    Operazione 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master crea la VM master di amministrazione senza eseguire l'upgrade della versione hardware della macchina virtuale

    Il nodo master di amministrazione 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 di amministrazione, segui https://kb.vmware.com/s/article/1003746 di eseguire l'upgrade del nodo alla versione prevista descritta nell'errore e quindi avviare il nodo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

    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 questo cambiamento, Le VM non hanno inviato un messaggio di rilascio del lease DHCP al server DHCP su arresta o riavvia. Dopo questa modifica, le VM inviano questo messaggio che 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.

    • La UI 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
    • I nuovi nodi non vengono avviati a causa di calico-node errore 
      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 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 interesserà solo i cluster di amministrazione di cui è stato eseguito l'upgrade dalla versione 1.11.x, e non influirà sui cluster di amministrazione appena creati 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 aver eliminato la chiave dell'account di servizio di accesso ai componenti, l'installazione di nuovi cluster utente o l'upgrade di cluster utente esistenti non riuscito. 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 esegui l'upgrade di un cluster utente 1.13 utilizzando o gcloud CLI, quando esegui gkectl update admin --enable-preview-user-cluster-central-upgrade per eseguire l'upgrade del controller della piattaforma, 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 in l'output di kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Soluzione:

    Aggiungi di nuovo la chiave dell'account di servizio di accesso ai componenti nel secret manualmente eseguendo questo 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 del gestore della scalabilità automatica del cluster mostra anche che sono in stato non integro. 

      > 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
    Per trovare il pod del gestore della scalabilità automatica dei cluster, esegui i comandi riportati di seguito. 
      > 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 dei blocchi IP

    Quando gli utenti utilizzano CIDR nel file a blocchi IP, la convalida della configurazione avrà esito negativo 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 es. In caso di aggiornamento da Ubuntu a COS, dovremmo 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 del pod dovuti al token di autenticazione dell'account di servizio CNI di Calico problema

    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 viene osservato solo 24 ore dopo che il cluster viene creato o aggiornato alla versione 1.14 utilizzando Calico.

    I cluster di amministrazione utilizzano sempre Calico, mentre per i cluster utente è disponibile un campo di configurazione "enableDataPlaneV2" in user-cluster.yaml, se questo campo è se impostato su "false" o non specificato, significa che stai utilizzando Calico nell'utente in un cluster Kubernetes.

    I nodi Il container install-cni crea un kubeconfig con un sia valido per 24 ore. Questo token deve essere periodicamente rinnovato dal pod calico-node. calico-node Il pod non è in grado di rinnovare il token perché non ha accesso alla directory che contiene 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 subito l'upgrade, applica la seguente patch al calico-node DaemonSet nel tuo cluster di amministrazione e nel tuo cluster 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 riesce nonostante la configurazione dell'utente sia corretta. L'utente vede la creazione non riuscita perché il cluster non ha un numero sufficiente di IP.


    Soluzione:

    Suddividi i CIDR in diversi 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 la configurazione e le chiavi di crittografia dei secret sempre attivi

    Quando la funzionalità di crittografia dei secret sempre attivi è abilitata insieme al backup del cluster, il backup del cluster di amministrazione non riesce a includere le chiavi di crittografia e la configurazione richieste dalla funzionalità di crittografia dei secret sempre attiva. Di conseguenza, la riparazione del master dell'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

    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 dalla versione 1.9 alla versione 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:
    Upgrade, aggiornamenti 1.10.0

    Docker si riavvia spesso dopo l'upgrade del cluster

    L'upgrade del cluster utente alla versione 1.10.0 potrebbe causare il riavvio frequente di Docker.

    Puoi rilevare questo problema eseguendo kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Una condizione del nodo mostrerà se il docker si riavvia frequentemente. Ecco un output di esempio:

    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 gestiti da Google (GMP) nel gmp-system per il tuo cluster, i componenti non vengono conservati aggiornalo alla versione 1.12.x.

    A partire dalla versione 1.12, i componenti di GMP nello spazio dei nomi gmp-system e i CRD sono gestiti da stackdriver , con il flag enableGMPForApplications impostato su false da predefinito. Se esegui manualmente il deployment dei componenti GMP nello spazio dei nomi prima dell'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 dell'API Cluster, che si trovano in questo spazio dei nomi contengono utili informazioni di 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 nei 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 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 viene definito nel campo vCenter.datastore nei file user-cluster.yaml o admin-cluster.yaml.
    Configurazione 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 e 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é gli stessi clusterrole e clusterrolebinding vengono utilizzati per tutti i pod del gestore della scalabilità automatica dei cluster all'interno dello stesso cluster di amministrazione.

    I sintomi sono i seguenti:

    • cluster-autoscaler log
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      dove ADMIN_CLUSTER_KUBECONFIG è il cluster di amministrazione kubeconfig. Ecco un esempio di messaggi di errore che potrebbero essere visualizzati: 
      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:

    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 il valore clusterrole corrispondente, il che comporta la riparazione automatica e l'esportazione delle metriche vSphere non funzionanti

    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 cluster di amministrazione kubeconfig. 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 potrebbero essere visualizzati: 
      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:

    Configurazione 1.12.1-1.12.3, 1.13.0-1.13.2

    gkectl check-config non riesce durante la convalida dell'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 riuscirà con il messaggio di errore seguente:

    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 riuscirà con il messaggio di errore seguente:

    Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Soluzione:
    Installazione, upgrade, aggiornamenti 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    La registrazione dei nodi non riesce se il nome host configurato contiene un punto

    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 Il file dei blocchi IP contiene uno o più cicli. In questo caso, le richieste di firma del certificato (CSR) per un non vengono approvati automaticamente.

    Per visualizzare i CSR in sospeso per un nodo, esegui questo comando:

    kubectl get csr -A -o wide

    Verifica la presenza di messaggi di errore nei log seguenti:

    • Visualizza i log nel cluster di amministrazione per clusterapi-controller-manager contenitore 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 questo comando: : 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      dove:
      • ADMIN_CLUSTER_KUBECONFIG è il cluster di amministrazione kubeconfig.
      • 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 come nome host bob-vm-1.bank.plc, la VM il nome host e il nome del nodo saranno 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 richiesta di firma del certificato e il nodo non riesce bootstrap.


    Soluzione:

    Cluster utente

    Disabilita la verifica dell'ID nodo completando i seguenti passaggi:

    1. Aggiungi i seguenti campi al file di configurazione del cluster utente: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. 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

    1. Apri la risorsa personalizzata OnPremAdminCluster per modifica: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Aggiungi la seguente annotazione alla risorsa personalizzata: 
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Modifica il manifest kube-controller-manager nella pagina di amministrazione di controllo del cluster:
      1. Accedi tramite SSH nodo del piano di controllo del cluster di amministrazione.
      2. Apri il manifest kube-controller-manager per modifica: 
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Trova l'elenco di controllers: 
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Aggiorna questa sezione come mostrato di seguito: 
        --controllers=*,bootstrapsigner,tokencleaner
    4. Apri il controller API Deployment Cluster per la modifica: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Modifica i valori di node-id-verification-enabled e node-id-verification-csr-signing-enabled per 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 è bloccato definitivamente al seguente log e alla fine si verifica il timeout:

    Waiting for Machine gke-admin-master-xxxx to become ready...

    Il controller API Cluster registra il log lo 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 aumento gravoso su altri nodi o mancanza di ridondanza per l'alta disponibilità.

    In caso contrario, l'attività Dataplane non ne è influenzata.

    La contesa sull'oggetto networkgatewaygroup causa alcune aggiornamenti dello stato non riusciti a causa di un errore durante la gestione dei nuovi tentativi. 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

    La condizione di gara blocca l'eliminazione degli oggetti macchina durante e durante l'aggiornamento esegui l'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 di aggiornamento in sequenza 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.

    In clusterapi-controller log dei pod, gli errori sono sotto:

    $ 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 anche senza questo problema, per la maggior parte delle volte rapidamente, ma in alcuni rari casi può rimanere bloccato a questa gara per diverse ore.

    Il problema è che la VM sottostante è già stata eliminata in vCenter, ma l'oggetto macchina corrispondente non può essere rimosso, che è bloccato la rimozione del finalizzatore a causa di aggiornamenti molto frequenti da altri controller. Ciò può causare il timeout del comando gkectl, ma continua a riconciliare il cluster, in modo che il processo di upgrade o aggiornamento alla fine è completata.


    Soluzione:

    Abbiamo preparato diverse opzioni di mitigazione per questo problema, che dipende dall'ambiente e dai 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ò terminare da sola senza alcun intervento manuale. La a questa opzione è che non è chiaro quanto tempo ci vorrà la rimozione del finalizzatore da eseguire per ogni oggetto macchina. Può andare se è abbastanza fortunato, oppure può durare diverse ore se la riconciliazione del controller del set di macchine è troppo veloce e la macchina il controller non ha mai la possibilità di rimuovere il finalizzatore tra 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 tutto il vecchio computer di oggetti strutturati.

      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 invece che rimossa, il che significa che non rispetterà la configurazione PDB, questo potrebbe causare tempi di inattività per i carichi di lavoro.

      Il comando per recuperare tutti i nomi di macchina: 
      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 si verifica questo problema e non è ancora possibile eseguire l'upgrade o l'aggiornamento non saranno completate dopo molto tempo, contatto al nostro team di assistenza per le misure correttive.
    Installazione, upgrade, aggiornamenti 1.10.2; 1.11; 1.12; 1.13

    Errore preflight gkectl per la preparazione delle immagini 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 un'istanza convalida errata.


    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 segreta, 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

    Panico gkectl prepare su util.CheckFileExists

    gkectl prepare può andare in panico per i seguenti problemi stacktrace:

    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 l'elemento privato del certificato del registry 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. perché potrebbe causare il successivo upgrade amministrativo tenta di non riuscire con problemi quali guasto all'alimentazione del master dell'amministratore o VM inaccessibile.


    Soluzione:

    Se hai già riscontrato questo errore, contatta l'assistenza.
    Upgrade, aggiornamenti 1,10, 1,11

    Il ripreso dell'upgrade del cluster di amministrazione può comportare la mancanza del piano di controllo amministrativo Modello VM

    Se la macchina del piano di controllo amministratore non viene ricreata dopo la ripresa tentativo di upgrade del cluster di amministrazione, il modello di VM del piano di controllo amministratore è eliminati. Il modello VM del piano di controllo amministratore è il modello dell'amministratore utilizzato per recuperare la macchina del piano di controllo 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 utilizzando i nodi COS, ti consigliamo di eseguire l'upgrade alla versione 1.12.1 il prima quando viene rilasciato.
    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 F5 Partizioni BIG-IP

    La convalida non va a buon fine perché non è possibile trovare le partizioni BIG-IP di F5, nemmeno anche se esistono.

    Un problema con l'API BIG-IP di F5 può causare la mancata riuscita della convalida.


    Soluzione:

    Prova a eseguire di nuovo gkectl check-config.
    Installazione 1,12

    Installazione del cluster utente non riuscita a causa di un errore di cert-manager/ca-injector problema elettorale leader

    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:
    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 VM da vCenter è non è corretto e la macchina si trova in un Unavailable stato. Questo porta alla riparazione automatica dei nodi per creare di nuovi.

    govmomi correlato .


    Soluzione:

    Questa soluzione alternativa è fornita dall'assistenza VMware:

    1. Il problema è stato risolto in vCenter 7.0U2 e versioni successive.
    2. Per le versioni precedenti, fai clic con il tasto destro del mouse sull'host, quindi seleziona Connessione > Disconnetti. Quindi, riconnettiti, 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, il sistema operativo Ubuntu le immagini vengono protette con Benchmark CIS L1 per i server.

    Per soddisfare la regola CIS "5.2.16 Assicurati che l'intervallo di timeout per inattività SSH sia configurato", /etc/ssh/sshd_config ha quanto segue impostazioni:

    ClientAliveInterval 300
ClientAliveCountMax 0

    Lo scopo di queste impostazioni è chiudere una sessione client dopo 5 minuti di inattività. Tuttavia, ClientAliveCountMax 0 causa comportamenti imprevisti. Quando utilizzi la sessione ssh sul 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'arresto del tuo comando su disconnessione SSH, 
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Aggiorna sshd_config in modo che utilizzi un valore diverso da zero Valore ClientAliveCountMax. 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 riconnettere 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 una sola volta per ogni cluster le modifiche verranno mantenute 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. Ciò è causato da monitoring-operator sta tentando di riconciliare cert-manager e il ripristino della versione durante il processo.

    Soluzione:

    <pEvita conflitti durante l'upgrade

    1. Disinstalla la tua versione di cert-manager. Se avevi definito le tue risorse, potresti voler backup le.
    2. Esegui l'upgrade.
    3. Segui queste istruzioni per ripristinare la tua cert-manager.

    Ripristinare cert-manager nei cluster utente

    • Scala il deployment monitoring-operator a 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 tue risorse personalizzate, se disponibili.
    • 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 gestore certificati nei cluster di amministrazione

    In generale, non dovrebbe essere necessario reinstallare cert-manager nella pagina di amministrazione di cluster perché i cluster di amministrazione eseguono solo il controllo Google Distributed Cloud e carichi di lavoro del piano di controllo. Nei rari casi in cui devi installare anche cert-manager nei cluster di amministrazione, segui queste istruzioni per evitare conflitti. Se sei un cliente Apigee e se serve solo cert-manager per Apigee, non è necessario eseguire dei cluster Kubernetes.

    • Scala il deployment monitoring-operator a 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Scala i deployment cert-manager gestiti da Da monitoring-operator a 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 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
}
'
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 ai CVE Ubuntu Tracker, utilizzato come feed di vulnerabilità da vari CVE strumenti di scansione. 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 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ò essere 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. Quindi, durante l'upgrade, è possibile che il vecchio kube-apiserver non è disponibile mentre il nuovo kube-apiserver non lo è ancora pronto.


    Soluzione:

    Il tempo di inattività si verifica solo durante il processo di upgrade. Se desideri tempi di inattività più brevi durante l'upgrade, HA cluster.
    Installazione, upgrade, aggiornamenti 1,10; 1,11; 1,12; 1,13

    Controllo di idoneità Konnectivity non riuscito nella diagnostica del cluster ad alta disponibilità dopo creazione o upgrade del cluster

    Se stai creando o eseguendo l'upgrade di un cluster ad alta disponibilità e noti la connettività controllo di idoneità non riuscito nella diagnostica del cluster. Nella maggior parte dei casi influisce 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 konnectivity si recupererà da sola. Attendi da 30 minuti a 1 ora ed eseguire nuovamente la diagnostica del cluster.
    Sistema operativo 1,7; 1,8; 1,9; 1,10; 1,11

    /etc/cron.daily/aide problema di picco 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 da pianificare un controllo aide per garantire che la regola del server CIS L1 "1.4.2 Garantire l'integrità del file system sia vengono controllati regolarmente". viene seguito.

    Il cron job viene eseguito ogni giorno alle 06:25 UTC. In base al numero di file system sul file system, potresti riscontrare picchi di utilizzo di CPU e memoria in quel periodo di tempo causati dal processo aide.


    Soluzione:

    Se i picchi interessano il carico di lavoro, puoi disabilitare la strategia cron job:

    sudo chmod -x /etc/cron.daily/aide
    Networking 1,10; 1,11; 1,12; 1,13

    Interazione tra bilanciatori del carico e regole firewall distribuite stateful di NSX-T 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. Tu potrebbero verificarsi problemi di connessione simili alle tue applicazioni quando e creare oggetti Kubernetes di grandi dimensioni superiori a 32.000.


    Soluzione:

    Segui queste istruzioni per disabilitare le regole firewall distribuite NSX-T oppure per utilizzare regole firewall stateless distribuite per le VM Seesaw.

    Se i cluster utilizzano un bilanciatore del carico manuale, segui queste istruzioni per configurare il bilanciatore del carico in modo da reimpostare il client quando rileva un errore del nodo di backend. Senza i client del server API Kubernetes potrebbero smettere di rispondere per diversi minuti quando un'istanza del server smette di funzionare.
    Logging e monitoraggio 1,10, 1,11, 1,12, 1,13, 1,14 e 1,15

    Fatturazione 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 quando si applicano 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, elencare 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 alternativa

    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 abbandonare la raccolta delle metriche basate sulle annotazioni, segui questi passaggi:

    1. 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"'
    2. Rimuovi l'annotazione prometheus.io/scrap=true dal di un pod o di un 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

    Il programma di installazione di Google Distributed Cloud può non riuscire se sono associati ruoli personalizzati a un livello di autorizzazione errato.

    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. A risolvi il problema, devi associare il ruolo personalizzato a vSphere vCenter livello (principale).


    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, vedi 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

    È possibile che il traffico di rete sia elevato monitoring.googleapis.com, anche in un nuovo cluster che non ha 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:
    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.

    1. 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 dell'utente kubeconfig del cluster.
    2. Apri il ConfigMap gke-metrics-agent-conf per la modifica: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. 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
    4. Chiudi la sessione di modifica.
    5. 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

    Sostituisci le metriche deprecate nella dashboard

    Se nelle dashboard OOTB vengono utilizzate metriche deprecate, vedrai alcuni grafici vuoti. Per trovare le metriche deprecate in Monitoring per le dashboard, esegui questi 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 deprecate nei relativi sostituzioni.

    RitiratoSostituzione
    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

    1. 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.
    2. Elimina "Utilizzo nodi GKE on-prem" nella piattaforma Google Cloud Monitoring Fitbit.com. Reinstalla "Utilizzo nodi GKE on-prem" persone che seguo queste istruzioni.
    3. Elimina "Integrità delle VM vSphere GKE on-prem" in Google Cloud dashboard di monitoraggio. Reinstalla "Integrità delle macchine virtuali vSphere di GKE on-prem" persone che seguo queste istruzioni.

      4. Questo ritiro è dovuto all'upgrade kube-state-metrics, dalla versione 1.9 alla versione 2.4, obbligatorio per gli Kubernetes 1.22. Puoi sostituire tutti i dati deprecati kube-state-metrics metriche, che hanno il prefisso kube_ nelle tue dashboard personalizzate o nei tuoi criteri di avviso.
    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 per i cluster in Cloud Monitoring potrebbero contenere metriche di riepilogo irrilevanti quali:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Altri tipi di metriche che potrebbero avere metriche di riepilogo non pertinenti includi

    • 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 la seguente procedura come soluzione alternativa. Per [versione 1.9.5+, 1.10.2+, 1.11.0]: aumento della CPU per gke-metrics-agent seguendo i passaggi 1 - 4

    1. Apri la risorsa stackdriver da modificare: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Per aumentare la richiesta di CPU per gke-metrics-agent da Da 10m a 50m, limite di CPU da 100m a 200m aggiungi i seguenti resourceAttrOverride al file 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
    3. Salva le modifiche e chiudi l'editor di testo.
    4. Per verificare che le modifiche siano state applicate, esegui questo 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 dello scheduler e del 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 mancante

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Soluzione:

    Esegui l'upgrade alle versioni 1.11.3+, 1.12.1+ o v1.13+.
    1.11.0-1.11.2, 1.12.0

    Mancano le metriche dello scheduler e del controller-manager nel cluster utente

    Se il tuo cluster utente è 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:

    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

    Errore durante la registrazione del cluster di amministrazione 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 gkeConnect fornito 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:
    Identità 1,10; 1,11; 1,12; 1,13

    L'utilizzo di GKE Identity Service può causare Connetti l'agente per riavviare in modo imprevedibile

    Se utilizzi Servizio di identità GKE funzionalità per gestire . ClientConfig del servizio di identità GKE, L'agente Connect 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 in un secondo momento, in modo da eseguire l'upgrade della versione dell'agente Connect.
    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 grazie all'apprendimento IP del piano dati.


    Soluzione:

    Una possibile soluzione alternativa consiste nel disabilitare l'apprendimento IP aggiungendo l'indirizzo IP di Seesaw come IP virtuale L4-L7 nei criteri delle applicazioni Cisco Infrastructure Controller (APIC).

    Puoi configurare l'opzione IP virtuale L4-L7 selezionando Tenant > Profili di applicazione > EPG delle applicazioni o EPG uSeg. Errore per disabilitare l'apprendimento IP comporterà il flapping degli endpoint IP tra da diverse località all'interno della struttura delle API di 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:

    • vSphere ESXi 7.0 Update 3 (build 18644231)
    • vSphere ESXi 7.0 Update 3a (build 18825058)
    • vSphere ESXi 7.0 Update 3b (build 18905247)
    • Aggiornamento vSphere vCenter 7.0 3b (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 noexec e riceverai il seguente errore: exec user process caused: permission denied. Ad esempio, vedrai questo 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:
    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 è è stata disabilitata sul pool di nodi

    Le repliche del pool di nodi non si aggiornano dopo l'abilitazione della scalabilità automatica disabilitato su un pool di nodi.


    Soluzione:

    La rimozione 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 della macchina del pool di nodi corrispondente.
    Logging e monitoraggio 1,11, 1,12, 1,13

    Le dashboard di monitoraggio di Windows mostrano dati provenienti da 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 e 1,12

    stackdriver-log-forwarder in CrashLoopBackOff costante

    Per Google Distributed Cloud versione 1.10, 1.11 e 1.12, stackdriver-log-forwarder DaemonSet potrebbe avere CrashLoopBackOff errori quando sono presenti di log con buffer non funzionanti sul disco.


    Soluzione:

    Per limitare il problema, dovremo pulire i log presenti nel buffer su nel nodo.

    1. 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 dell'utente kubeconfig del cluster.
    2. Esegui il deployment del DaemonSet di pulizia per rimuovere i blocchi rotti: 
      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
    3. Per assicurarti che il DaemonSet di pulizia abbia ripulito tutti i blocchi, puoi eseguire questi comandi. L'output dei due comandi dovrebbe essere uguale al numero di nodi 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
    4. Elimina il DaemonSet di pulizia: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. 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 in Cloud Logging non vedi i log dei tuoi cluster e noterai il seguente errore nei tuoi 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 limitare il problema, devi aumentare il limite di risorse l'agente Logging.

    1. Apri la risorsa stackdriver da modificare: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. 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 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:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Salva le modifiche e chiudi l'editor di testo.
    4. 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

    c'è un breve periodo in cui il nodo è pronto ma il server kubelet è pronto, non è pronto. kubectl exec e kubectl logs non sono disponibili durante queste decine di secondi. Questo perché il nuovo approvatore dei certificati del server impiega del tempo vedi gli IP validi aggiornati del nodo.

    Questo problema riguarda solo il certificato kubelet server, non Pianificazione dei pod.
    Upgrade, aggiornamenti 1,12

    L'upgrade parziale del cluster di amministrazione non blocca il cluster utente successivo esegui l'upgrade

    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 è completo e la versione dello stato è ancora 1.10. L'upgrade del cluster utente alla versione 1.12 non verrà bloccato da nessun preflight e non riesce con un problema di disallineamento delle versioni.


    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

    Datastore segnala erroneamente 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

    Impossibile aggiungere un nuovo cluster utente quando il cluster di amministrazione utilizza MetalLB bilanciatore del carico

    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, determina l'annullamento della convalida di MatalLB ConfigMap. Non sarà possibile per aggiungere un nuovo cluster utente in questo stato.


    Soluzione:

    Puoi forzare l'eliminazione del 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 utente

    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 riesce nei seguenti casi: 

    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. Deriva da una mancata corrispondenza dei certificati client pushprox nell'utente cluster e la lista consentita nel server pushprox nel cluster di amministrazione. Il sintomo è che il client pushprox-nei cluster utente stampa log degli errori come le seguenti:

    level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Soluzione:
    Altro 1.11.3

    gkectl repair admin-master non fornisce la VM modello da utilizzare per il recupero

    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 nuovamente il comando con --skip-validation.
    Logging e monitoraggio 1,11, 1,12, 1,13, 1,14, 1,15 e 1,16

    Errore di audit logging di Cloud a causa di un'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, nei casi in cui il cluster di amministrazione utilizzi un ID progetto o un ID progetto diverso diverso da quello di qualsiasi cluster utente, gli audit log non verrebbe inserito in Google Cloud. Il sintomo è un di Permission Denied errori nel audit-proxy pod nel cluster di amministrazione.

    Soluzione:
    Operazione, sicurezza 1,11

    Controllo dei certificati non riuscito per gkectl diagnose

    Se la tua postazione di lavoro non ha accesso ai nodi worker del cluster utente, riceverà i seguenti errori durante l'esecuzione gkectl diagnose:

    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/ sta riempiendo spazio su disco sulle 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 contribuisce allo spazio su disco all'utilizzo delle risorse.

    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:
    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 sono in grado di creare o aggiornare 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. I controlli del webhook di convalida NetworkGatewayGroup indirizzi IP mobili rispetto a tutti node.status.addresses nel cluster e lo vede come un in conflitto.


    Soluzione:

    Nello stesso cluster in cui crei o aggiorni NetworkGatewayGroup oggetti con errore, sono temporaneamente disattivati il webhook di convalida ANG e invia la modifica:

    1. 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
    2. Modifica la configurazione del webhook: 
      kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Rimuovi vnetworkgatewaygroup.kb.io dall'elemento di configurazione webhook e chiudi per applicare le modifiche.
    4. Crea o modifica l'oggetto NetworkGatewayGroup.
    5. 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 amministratore potrebbe bloccarsi durante la creazione. La VM del piano di controllo amministratore entra in un loop 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 perché quando Google Distributed Cloud tenta di ottenere l'IP del nodo nello script di avvio, usa grep -v ADMIN_CONTROL_PLANE_VIP per saltare il VIP del piano di controllo del cluster di amministrazione che può essere assegnato anche al NIC. Tuttavia, il comando salta anche qualsiasi indirizzo IP con un prefisso del VIP del piano di controllo, lo script di avvio.

    Ad esempio, supponiamo che il 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 broadcast ha lo stesso prefisso del VIP del piano di controllo, ad esempio 192.168.1.255.


    Soluzione:

    • Se il motivo del timeout per la creazione del cluster di amministrazione è dovuto al per trasmettere l'indirizzo IP, esegui questo comando sul cluster di amministrazione VM del piano di controllo: 
      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

    DataDisk non può essere montato correttamente sul nodo master del cluster di amministrazione quando utilizzando l'immagine COS e lo stato del cluster di amministrazione che utilizza l'immagine COS andranno persi al momento dell'upgrade del cluster di amministrazione o della riparazione del master. (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, risoluzioni dei nomi su Ubuntu vengono indirizzati all'ascolto delle soluzioni risolte dal sistema locale il giorno 127.0.0.53 per impostazione predefinita. Il motivo è che sull'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 127.0.0.53 stub DNS localhost.

    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, tutte le ricerche dei nomi di .local non vanno a buon fine. Per Ad esempio, durante l'avvio del nodo, kubelet non riesce a eseguire il pull delle immagini da un registro privato con un suffisso .local. Specificare un L'indirizzo vCenter con il suffisso .local non funzionerà su un la workstation di amministrazione.


    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, occorre utilizzare SSH per accedere ai nodi e bypassare lo stub systemd-resolved locale modifica del collegamento simbolico di /etc/resolv.conf da /run/systemd/resolve/stub-resolv.conf (che contiene il 127.0.0.53 stub locale) per /run/systemd/resolve/resolv.conf (che indica l'effettiva DNS upstream): 

    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 per non viene mantenuto tra le ricreazioni di VM. Devi riapplica questa soluzione alternativa ogni volta che le VM vengono ricreate.
    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 indirizzo IP del bridge che utilizza --bip=169.254.123.1/24, in modo che non prenoterà 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 con una subnet dell'indirizzo IP bridge. Ciò potrebbe causare un conflitto di indirizzi IP se hanno già un carico di lavoro in esecuzione all'interno di quell'intervallo di indirizzi IP.


    Soluzione:

    Per aggirare questo problema, devi rinominare la seguente configurazione di sistema per Docker, quindi riavvia 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 scelga l'indirizzo IP del bridge corretto:

    ip a | grep docker0

    Questa soluzione non viene mantenuto durante le riproduzioni di 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

    In Google Distributed Cloud versione 1.11.0, sono state apportate modifiche alla definizione di risorse personalizzate relative al logging e al 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 un tipo di stringa nei valori delle richieste e nei limiti relativi a CPU, memoria e 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 farvi riferimento con il 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 un tipo non supportato nella specifica CR di Stackdriver era già presente prima dell'upgrade. 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:

    1. Modificare le richieste e i limiti delle risorse nel tipo di stringa.
    2. Rimuovi tutte le annotazioni addons.gke.io/migrated-and-deprecated: true, se presenti.
    Quindi riprendi o riavvia il processo di upgrade.

    Sistema operativo 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15 e 1,16

    Le VM COS non mostrano IP quando le VM vengono spostate tramite un arresto non controllato dell'host

    Ogni volta che si verifica un errore in un server ESXi e la funzione vCenter HA è stata abilitata 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 perderanno gli IP.

    Soluzione:

    Riavvia la VM
    Networking per tutte le versioni precedenti alla 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. Questa operazione dovrebbe ripristinare il traffico.
    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".
    Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.