Migrer un service de diffusion Knative vers Cloud Run

Migrez vos charges de travail vers Cloud Run à l'aide de ce guide. En général, la migration de vos charges de travail nécessite le transfert de l'une des fonctionnalités basées sur Kubernetes, puis le redéploiement de chacun de vos services existants vers Cloud Run.

Principaux avantages de la migration vers Cloud Run :

  • Produit sans serveur entièrement géré qui implémente la spécification de l'API Knative Serving et respecte le contrat du conteneur.

  • L'API Admin v1 de Cloud Run est conçue pour maximiser la portabilité avec la diffusion Knative.

  • L'expérience utilisateur est similaire sur Cloud Run et sur la diffusion Knative:

    • Le groupe de commandes gcloud run est utilisé dans les deux produits.
    • La structure et le comportement de l'interface utilisateur sont similaires dans Google Cloud Console.

Avant de commencer

Les fonctionnalités Google Kubernetes Engine suivantes ne sont pas compatibles avec Cloud Run, y compris :

Considérations sur la migration

Vous devez examiner et comprendre les différences suivantes entre les produits afin de vous assurer que vous pouvez transférer toutes vos dépendances et exigences.

Secrets

Dans Cloud Run, vous pouvez choisir d'installer des secrets en tant que variables d'environnement ou volumes, mais les secrets contenant des informations sensibles doivent être stockés dans Secret Manager.

Différences importantes entre les secrets dans Secret Manager et les secrets Kubernetes :

Sélection Secrets Secret Manager Secrets Kubernetes
Caractères autorisés dans les noms [a-zA-Z0-9_-]{1,255} [a-z0-9-.]{1,253}
Gestion des versions Gestion des versions des secrets Assistance indisponible
Charge utile de secrets Unique []byte Map : <string, string>

Découvrez comment utiliser Secret Manager pour créer des secrets avec gestion des versions pour les clés secrètes de vos services de diffusion Knative.

Mise en réseau

Les informations suivantes vous aideront à transférer votre configuration réseau existante vers Cloud Run.

Points de terminaison du service
Les points de terminaison Kubernetes de vos services de diffusion Knative ne sont pas compatibles avec Cloud Run. En savoir plus sur les points de terminaison uniques dans Cloud Run.
Mappages de domaines
L'API DomainMapping de Cloud Run est compatible avec l'inférence Knative. Toutefois, Cloud Run propose un mappage de domaine dans un sous-ensemble des emplacements Cloud Run disponibles. Une alternative recommandée consiste à utiliser l'équilibreur de charge HTTP(S) global pour vos domaines personnalisés.
Connectivité VPC
Les services Cloud Run résident en dehors de votre VPC. Pour communiquer avec les ressources d'un VPC, vous devez utiliser le connecteur d'accès au VPC sans serveur.
Contrôles d'entrée
Si votre service de diffusion Knative est configuré pour un réseau interne privé et utilise un équilibreur de charge interne (ILB), vous pouvez configurer votre service Cloud Run sur Ingress = Internal. La configuration de vos services sur internal limite l'accès à votre VPC ou à d'autres services Cloud Run. En savoir plus sur la communication de service à service

Migrer un service

Pour migrer un service, vous devez exporter votre service de diffusion Knative, modifier le fichier YAML exporté, puis déployer votre service reconfiguré sur Cloud Run.

  1. Exportez votre service de diffusion Knative vers un fichier YAML local en exécutant la commande suivante:

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

    Remplacez :

    • SERVICE par le nom de votre service de diffusion Knative.
    • NAMESPACE par l'espace de noms dans lequel votre service s'exécute ;
    • CLUSTER par le nom du cluster sur lequel votre service s'exécute ;
    • FILENAME par un nom de fichier unique de votre choix.

  2. Modifiez le fichier FILENAME.yaml exporté pour Cloud Run :

    • Vous devez rechercher et remplacer l'espace de noms Kubernetes par l'ID de votre projet Google Cloud. Par exemple, vous devez remplacer namespace:default par namespace:my-unique-id.
    • Vous devez mettre à jour toutes les configurations pour toutes les fonctionnalités non compatibles.

    • Vous devez supprimer les attributs suivants et leurs valeurs :

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

      Par exemple, vous devrez peut-être supprimer la configuration suivante dans les attributs spec: > template: > spec: > containers: :

      ...
 readinessProbe:
   successThreshold: 1
   tcpSocket: {}
...

  3. Déployez le fichier .yaml modifié dans Cloud Run à l'aide de l'option --platform managed. En savoir plus sur le déploiement

    Notez que vous pouvez utiliser le même projet Google Cloud pour Cloud Run.

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

    Remplacez :

  4. Configurez l'accès à votre service Cloud Run :

  5. Dans Google Cloud Console, sur la page de vos services, vous pouvez cliquer sur le lien URL affiché pour ouvrir le point de terminaison unique et stable de votre service déployé.

    Accédez à Cloud Run

Migrer le trafic vers votre service

Une fois que vous avez testé vos nouveaux services et que vous êtes prêt à migrer tout votre trafic de production, vous pouvez configurer votre domaine personnalisé et mettre à jour vos enregistrements DNS avec votre service d'enregistrement. Suivez les instructions de la section Mapper des domaines personnalisés.