Migrer un service Knative serving 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 optimiser la portabilité avec Knative serving.

  • L'expérience utilisateur est semblable dans Cloud Run et Knative serving :

    • 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 :

Caractéristique 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 Non prise en charge
Charge utile de secrets Unique []byte Map : <string, string>

Découvrez comment créer des secrets avec des versions gérées pour les clés secrètes de vos services Knative serving.

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 Knative serving 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 Knative serving. 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 Knative serving 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 Knative serving, modifier le fichier YAML exporté, puis déployer votre service reconfiguré vers Cloud Run.

  1. Exportez votre service Knative serving 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 Knative serving ;
    • 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.