Migrazione di un servizio Knative serving a Cloud Run

Utilizza questa guida per eseguire la migrazione dei tuoi carichi di lavoro in Cloud Run. In generale, per eseguire la migrazione dei carichi di lavoro richiede la portabilità di uno qualsiasi dei ed eseguire nuovamente il deployment di ciascuno dei tuoi servizi esistenti in Cloud Run.

Principali vantaggi della migrazione a Cloud Run:

  • Prodotto serverless completamente gestito che implementa Specifica dell'API Knative Serving e aderisce al contratto relativo ai container.

  • L'API Admin v1 di Cloud Run è progettata per massimizzare la portabilità con Knative serving.

  • L'esperienza utente è simile per Cloud Run e Knative serving:

    • Il gruppo di comandi gcloud run viene utilizzato in entrambi i prodotti.
    • Layout e comportamento dell'interfaccia utente simili nella console Google Cloud.

Prima di iniziare

Le seguenti funzionalità di Google Kubernetes Engine non sono supportate in Cloud Run. tra cui:

Considerazioni sulla migrazione

Devi esaminare e comprendere le seguenti differenze tra i prodotti per assicurati di poter trasferire tutte le dipendenze e i requisiti.

Secret

In Cloud Run, puoi scegliere di montare i secret come variabili di ambiente o volumi, ma i secret con informazioni sensibili dovrebbero essere archiviati Secret Manager.

Differenze importanti tra secret in Secret Manager e Secret di Kubernetes:

Funzionalità Secret di Secret Manager Secret Kubernetes
Caratteri consentiti nei nomi [a-zA-Z0-9_-]{1,255} [a-z0-9-.]{1,253}
Controllo delle versioni Controllo delle versioni dei secret Nessuna assistenza
Payload secret []byte singolo Mappa: <string, string>

Scopri come utilizzare Secret Manager per crea secret con controllo delle versioni le chiavi segrete dei tuoi servizi Knative serving.

Networking

Utilizza le seguenti informazioni per eseguire il trasferimento sulla tua rete esistente configurazione in Cloud Run.

Endpoint di servizio
Il Endpoint Kubernetes dei servizi Knative serving non siano supportati in Cloud Run. Scopri di più sugli endpoint univoci in Cloud Run.
Mappature dei domini
Cloud Run API DomainMapping è compatibile con Knative serving. Tuttavia, Cloud Run offre la mappatura di dominio in un sottoinsieme delle Località di Cloud Run. Un'alternativa consigliata è sfruttare Bilanciatore del carico HTTP(S) globale per il tuo personalizzati.
Connettività VPC
I servizi Cloud Run risiedono all'esterno del VPC. Per comunicare con all'interno di un VPC, devi utilizzare Connettore di accesso VPC serverless.
Controlli Ingress
Se il tuo servizio Knative serving è configurato per un ambiente privato interno e utilizza un bilanciatore del carico interno (ILB), puoi configurare dal servizio Cloud Run a Ingress = Internal. La configurazione dei tuoi servizi su internal limita l'accesso all'interno del tuo VPC e altri servizi Cloud Run. Scopri di più sulla comunicazione tra servizi.

Migrazione di un servizio

Per eseguire la migrazione di un servizio, devi esportare il servizio Knative serving, modificare il file YAML esportato, quindi esegui il deployment del servizio riconfigurato in Cloud Run.

  1. Esporta il tuo servizio Knative serving in un file YAML locale eseguendo il seguente comando:

    gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
    

    Sostituisci:

    • SERVICE con il nome del tuo servizio Knative serving.
    • NAMESPACE con lo spazio dei nomi in cui sia in esecuzione.
    • CLUSTER con il nome del cluster in cui se il servizio è in esecuzione.
    • FILENAME con un nome file univoco del tuo scelta.
  2. Modifica il file FILENAME.yaml esportato per Cloud Run:

    • Devi cercare e sostituire lo spazio dei nomi Kubernetes con l'ID del tuo progetto Google Cloud. Ad esempio, devi sostituire namespace:default con namespace:my-unique-id.
    • Devi aggiornare tutte le configurazioni per uno degli funzionalità non supportate.
    • Devi eliminare gli attributi seguenti e i relativi valori:

      • metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
      • metadata.managedFields
      • spec.template.spec.containers.readinessProbes
      • spec.template.spec.enableServiceLinks

      Ad esempio, potresti dover rimuovere la seguente configurazione da sotto spec: > template: > spec: > containers: attributi:

      ...
       readinessProbe:
         successThreshold: 1
         tcpSocket: {}
      ...
      
  3. Esegui il deployment del file .yaml modificato in Cloud Run utilizzando Flag --platform managed. Scopri di più sul deployment.

    Tieni presente che puoi utilizzare lo stesso progetto Google Cloud per Cloud Run.

    gcloud run services replace FILENAME.yaml --platform managed --region REGION
    

    Sostituisci:

    • FILENAME con il nome del file esportato di configurazione del deployment creato.
    • REGION con un supporto Percorso di Cloud Run. Ad esempio: us-central1.
  4. Configura l'accesso al tuo servizio Cloud Run:

  5. Nella pagina dei servizi della console Google Cloud, puoi fare clic sul il link dell'URL visualizzato per aprire l'endpoint univoco e stabile del deployment completamente gestito di Google Cloud.

    Vai a Cloud Run

Migrazione del traffico al servizio

Quando hai testato i servizi di cui hai appena eseguito il deployment e sei pronto per la migrazione di tutti del traffico di produzione, puoi configurare il dominio personalizzato e aggiornare Record DNS con il tuo registrar. Segui le istruzioni alla pagina Mappatura di domini personalizzati.