Problemi noti nell'ambiente flessibile di App Engine

ID regione

Il REGION_ID è un codice abbreviato che Google assegna in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

Per un elenco completo dei problemi noti o per segnalarne uno nuovo, consulta lo strumento di monitoraggio dei problemi.

  • Dopo aver eseguito il deployment dell'applicazione con gcloud app deploy, potresti dover attendere 1-2 minuti prima che l'applicazione inizi a essere pubblicata all'indirizzo https://PROJECT_ID.REGION_ID.r.appspot.com. Fino ad allora, potresti visualizzare errori HTTP 503.

    App Engine spesso registra questi errori come backend_timeout o failed_to_pick_backend nei log del bilanciatore del carico delle applicazioni esterno globale. Il bilanciatore del carico delle applicazioni esterno globale invia richieste a un servizio nell'ambiente flessibile di App Engine indipendentemente dallo stato delle singole istanze. Dopo aver eseguito il deployment di una nuova versione, il bilanciatore del carico delle applicazioni esterno globale impiega del tempo per aggiornare la configurazione con le nuove istanze di backend. Durante questa transizione, la disponibilità dei servizi di backend è incoerente. Durante la migrazione del traffico alla nuova versione, il bilanciatore del carico delle applicazioni esterno globale potrebbe tentare di inviare traffico a istanze non completamente pronte a ricevere richieste, con conseguenti errori 503. Ciò potrebbe anche causare errori 502, in particolare quando si utilizza un bilanciatore del carico delle applicazioni classico.

  • Se nel tuo progetto è presente un criterio dell'organizzazione che limita l'accesso agli IP esterni, non potrai eseguire il deployment di un'app dell'ambiente flessibile di App Engine con indirizzi IP esterni. Ad esempio, la policy dell'organizzazione potrebbe avere il seguente aspetto:

    • Il criterio vigente per constraints/compute.vmExternalIpAccess è impostato su DENY_ALL.
    • Il criterio effettivo per constraints/compute.vmExternalIpAccess è impostato per consentire solo istanze VM specifiche.
    • Il criterio effettivo per constraints/compute.requireOsConfig è disattivato per il progetto per impedire gli aggiornamenti dei metadati.

    Questi vincoli non vengono rilevati automaticamente e i deployment potrebbero scadere e non riuscire. Puoi controllare il criterio dell'organizzazione per il tuo progetto eseguendo il comando gcloud beta resource-manager org-policies describe compute.vmExternalIpAccess --project=my-project --effective. Puoi anche ignorare la policy dell'organizzazione per un progetto specifico.

    Tuttavia, anche con queste policy dell'organizzazione impostate, puoi eseguire il deployment di un'app dell'ambiente flessibile di App Engine privato che utilizza solo il proprio indirizzo IP interno.

  • Dopo aver eseguito il deployment di una nuova versione di un servizio esistente nell'ambiente flessibile di App Engine con gcloud app deploy, la metrica "Conteggio/sec" mostrata nel grafico "Riepilogo" della dashboard di App Engine potrebbe diminuire in modo significativo. La metrica tornerà gradualmente al conteggio delle richieste previsto nei prossimi 5-10 minuti.

    Ciò non significa che la tua applicazione gestisca meno richieste. Quando esegui il deployment di una nuova versione dell'applicazione, si verifica un ritardo tra il momento in cui la nuova versione è pronta a gestire le richieste e il momento in cui le metriche per le nuove istanze diventano disponibili.

    Per assicurarti che questa metrica non sia interessata dal deployment di una nuova versione:

    1. Esegui il deployment della nuova versione con gcloud app deploy --no-promote.
    2. Attendi 15 minuti dopo il completamento del deployment.
    3. Esegui la migrazione del traffico alla nuova versione.

    Se esegui il deployment con --no-promote, ma allochi una quantità di traffico alla nuova versione prima della finestra di 15 minuti dopo il completamento del deployment, questa metrica potrebbe essere interessata.

  • Nell'ambiente flessibile di App Engine non è possibile configurare app.yaml in modo che la tua app reindirizzi automaticamente le richieste per utilizzare sempre HTTPS. Ciò è diverso dall'ambiente standard di App Engine, in cui puoi utilizzare l'impostazione secure.

    In alternativa, puoi gestire il reindirizzamento all'interno del codice dell'applicazione analizzando il valore dell'intestazione X-Forwarded-Proto. Puoi anche incoraggiare i clienti a utilizzare l'intestazione Strict-Transport-Security.

  • Se assegni un service account gestito dall'utente a una versione dell'ambiente flessibile di App Engine, al tuo progetto potrebbero essere addebitate metriche con il prefisso agent.googleapis.com. In genere, queste metriche dell'agente non vengono addebitate al tuo progetto. Ti consigliamo di continuare a utilizzare il account di servizio predefinito di App Engine finché questo problema non viene risolto.

  • Non puoi stabilire una connessione SSH a un'istanza VM utilizzando IAP.

  • L'ambiente flessibile di App Engine ha un timeout massimo della richiesta di 60 minuti. Tuttavia, se la tua applicazione è configurata per utilizzare una rete VPC con regole firewall in uscita rigorose (ad esempio, negando il traffico in uscita a 0.0.0.0), potresti riscontrare interruzioni della connessione per le richieste che richiedono più di 10 minuti.

    Ciò si verifica perché la voce di monitoraggio della connessione del firewall VPC sottostante scade dopo 10 minuti di inattività. Quando l'istanza dell'ambiente flessibile App Engine tenta di inviare una risposta dopo 10 minuti di inattività sulla connessione, il firewall elimina i pacchetti in uscita.

    Per ovviare a questo limite, segui questi passaggi:

    • Per utilizzare regole di negazione in uscita rigide, configura regole di autorizzazione in uscita specifiche per consentire il traffico agli intervalli IP di Google Front End (GFE) utilizzati dal bilanciatore del carico delle applicazioni classico, ad esempio 130.211.0.0/22 e 35.191.0.0/16. Per saperne di più, consulta Regole firewall.
    • Esegui la migrazione al bilanciatore del carico delle applicazioni basato su Envoy. In questo modo puoi configurare regole di autorizzazione in uscita che hanno come target il tuo intervallo di subnet solo proxy, spesso consigliato dai team di sicurezza anziché gli intervalli IP GFE esterni.

Riduzione imprevista del numero di istanze

  • In rari casi, l'applicazione potrebbe subire una riduzione imprevista del numero di istanze a causa di errori di zona o se un intero gruppo di istanze smette di rispondere. Per evitare questo problema, Google consiglia di eseguire l'overprovisioning dell'applicazione per evitare che il sistema scenda al di sotto del numero minimo di istanze. Puoi impostare le dimensioni di min_num_instances dell'applicazione dell'ambiente flessibile App Engine durante il deployment. Alcuni eventi che possono influire sul numero minimo di istanze dell'ambiente flessibile di App Engine sono:

    1. Implementazione degli aggiornamenti alle istanze dell'ambiente flessibile
    2. Errore zonale (problemi di esaurimento delle scorte, ad esempio quando la regione ha raggiunto la capacità per la CPU selezionata e così via)

    L'ambiente flessibile App Engine utilizza tre zone per distribuire le istanze e in questa configurazione consigliamo di eseguire il provisioning del 50% di istanze in più rispetto a quelle richieste.

Metriche di Cloud Load Balancing incoerenti

La dashboard dell'ambiente flessibile di App Engine mostra tutte le metriche solo per le richieste instradate tramite un backend gestito dall'ambiente flessibile. Se utilizzi l'ambiente flessibile di App Engine con Cloud Load Balancing, alcune metriche nella tabella delle metriche di App Engine vengono segnalate come metriche della tabella loadbalancing. Per saperne di più, consulta Logging e monitoraggio del bilanciamento del carico HTTP(S).

InterruptedException nei runtime che utilizzano la JVM in caso di errore del controllo di integrità

Quando un controllo di integrità non riesce, la VM viene arrestata. Come sintomo del contenitore dell'app che non è più integro, la JVM risponde con errori InterruptedException e NullPointerException. Un gestore può rispondere al segnale SIGTERM inviato dal contenitore durante l'arresto per eseguire qualsiasi azione di pulizia o debug necessaria per evitare eccezioni.