Migrar un servicio de Knative Serving a Cloud Run

Sigue esta guía para migrar tus cargas de trabajo a Cloud Run. Por lo general, para migrar tus cargas de trabajo, debes transferir cualquiera de las funciones basadas en Kubernetes y, a continuación, volver a desplegar cada uno de tus servicios en Cloud Run.

Ventajas principales de migrar a Cloud Run:

  • Producto sin servidor totalmente gestionado que implementa la especificación de la API Knative Serving y cumple el contrato de contenedor.

  • La API Admin v1 de Cloud Run se ha diseñado para maximizar la portabilidad con Knative Serving.

  • La experiencia de usuario es similar en Cloud Run y Knative Serving:

    • El grupo de comandos gcloud run se usa en ambos productos.
    • Diseño y comportamiento de la interfaz de usuario similares en la consola de Google Cloud .

Antes de empezar

Las siguientes funciones de Google Kubernetes Engine no se admiten en Cloud Run:

Consideraciones sobre la migración

Debe revisar y comprender las siguientes diferencias entre los productos para asegurarse de que puede transferir todas sus dependencias y requisitos.

Secretos

En Cloud Run, puedes montar secretos como variables de entorno o volúmenes, pero los secretos con información sensible deben almacenarse en Secret Manager.

Diferencias importantes entre los secretos de Secret Manager y los secretos de Kubernetes:

Función Secretos de Secret Manager Secretos de Kubernetes
Caracteres permitidos en los nombres [a-zA-Z0-9_-]{1,255} [a-z0-9-.]{1,253}
Gestión de versiones Los secretos tienen versiones Sin asistencia
Secret Payload Sencillo []byte Mapa: <string, string>

Consulta cómo usar Secret Manager para crear secretos con versiones para las claves secretas de tus servicios de Knative Serving.

Redes

Usa la siguiente información para migrar tu configuración de red a Cloud Run.

Puntos finales del servicio
Los endpoints de Kubernetes de tus servicios de Knative Serving no son compatibles con Cloud Run. Consulta más información sobre los endpoints únicos de Cloud Run.
Asignaciones de dominios
La API DomainMapping de Cloud Run es compatible con Knative Serving. Sin embargo, Cloud Run ofrece la asignación de dominios en un subconjunto de las ubicaciones de Cloud Run disponibles. Una alternativa recomendada es usar el balanceador de carga HTTP(S) global para tus dominios personalizados.
Conectividad de VPC
Los servicios de Cloud Run se encuentran fuera de tu VPC. Para comunicarte con recursos de una VPC, debes usar el conector de acceso a VPC sin servidor.
Controles de entrada
Si tu servicio de Knative Serving está configurado para una red interna privada y usa un balanceador de carga interno (ILB), puedes configurar tu servicio de Cloud Run para que Ingress = Internal. Configurar tus servicios para internal restringe el acceso a tu VPC u otros servicios de Cloud Run. Más información sobre la comunicación entre servicios

Migrar un servicio

Para migrar un servicio, debes exportar tu servicio de Knative Serving, editar el archivo YAML exportado y, a continuación, desplegar el servicio reconfigurado en Cloud Run.

  1. Exporta tu servicio de Knative Serving a un archivo YAML local ejecutando el siguiente comando:

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

    Sustituye:

    • SERVICE con el nombre de tu servicio de Knative.
    • NAMESPACE con el espacio de nombres en el que se ejecuta tu servicio.
    • CLUSTER con el nombre del clúster en el que se ejecuta tu servicio.
    • FILENAME con el nombre de archivo único que elijas.

  2. Modifica el archivo FILENAME.yaml exportado para Cloud Run:

    • Debes buscar y sustituir el espacio de nombres de Kubernetes por el ID de tuGoogle Cloud proyecto. Por ejemplo, debes sustituir namespace:default por namespace:my-unique-id.
    • Debe actualizar todas las configuraciones de las funciones no admitidas.

    • Debe eliminar cualquiera de los siguientes atributos y sus valores:

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

      Por ejemplo, puede que tengas que quitar la siguiente configuración de los atributos spec: > template: > spec: > containers::

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

  3. Despliega el archivo .yaml modificado en Cloud Run con la marca --platform managed. Más información sobre el despliegue

    Ten en cuenta que puedes usar el mismo Google Cloud proyecto para Cloud Run.

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

    Sustituye:

  4. Configura el acceso a tu servicio de Cloud Run:

    • De forma predeterminada, no se puede acceder externamente a un servicio de Cloud Run. Para exponer públicamente tu servicio en Internet y permitir solicitudes no autenticadas, debes permitir el acceso público (no autenticado).

    • Para configurar este servicio para que solo se pueda acceder a él de forma interna y privada, como entre tus servicios de Cloud Run, consulta Autenticar de servicio a servicio.

  5. En la Google Cloud consola, en la página de servicios, puedes hacer clic en el enlace de la URL que se muestra para abrir el endpoint único y estable del servicio implementado.

    Ir a Cloud Run

Migrar tráfico a tu servicio

Una vez que hayas probado los servicios que acabas de implementar y estés listo para migrar todo el tráfico de producción, podrás configurar tu dominio personalizado y actualizar los registros DNS con tu registrador. Sigue las instrucciones de Asignar dominios personalizados.