Migra un servicio de Knative serving a Cloud Run

Usa esta guía para migrar tus cargas de trabajo a Cloud Run. En general, para migrar tus cargas de trabajo, debes transferir cualquiera de las funciones basadas en Kubernetes y, luego, volver a implementar cada uno de los servicios existentes en Cloud Run.

Beneficios clave de migrar a Cloud Run:

  • Producto sin servidores completamente administrado que implementa la especificación de la API de Knative serving y que cumple con el contrato del contenedor.

  • La API de Admin v1 de Cloud Run está diseñada para maximizar la portabilidad con Knative serving.

  • La experiencia del usuario es similar en Cloud Run y Knative serving:

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

Antes de comenzar

Las siguientes funciones de Google Kubernetes Engine no son compatibles con Cloud Run:

Consideraciones sobre la migración

Debes revisar y comprender las siguientes diferencias entre los productos para asegurarte de que puedas transferir todas las dependencias y requisitos.

Secrets

En Cloud Run, puedes elegir activar Secrets como variables de entorno o volúmenes, pero los Secrets con información sensible se deben almacenar en Secret Manager.

Diferencias importantes entre los Secrets en Secret Manager y los Secrets 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}
Control de versiones Los Secrets tienen control de versiones No hay asistencia disponible
Carga útil de Secret []byte único Mapa: <string, string>

Obtén más información sobre cómo usar Secret Manager para crear Secrets con versiones para las claves secretas de tus servicios de Knative serving.

Redes

Usa la siguiente información para ayudarte a transferir la configuración de red existente a Cloud Run.

Extremos del servicio
Los extremos de Kubernetes de tus servicios de Knative serving no son compatibles con Cloud Run. Obtén más información sobre los extremos únicos en Cloud Run.
Asignaciones de dominios
La API de 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 aprovechar el balanceador de cargas HTTP(S) global para tus dominios personalizados.
Conectividad VPC
Los servicios de Cloud Run residen fuera de tu VPC. Para comunicarte con recursos dentro de una VPC, debes usar el conector de Acceso a VPC sin servidores.
Controles de entrada
Si tu Knative serving está configurado para una red interna privada y usa un balanceador de cargas interno (ILB), puedes configurar el servicio de Cloud Run como Ingress = Internal. Configurar tus servicios como internal restringe el acceso a tu VPC o a otros servicios de Cloud Run. Obtén más información sobre la comunicación de servicio a servicio.

Migra un servicio

Para migrar un servicio, debes exportar tu servicio de Knative serving, editar el archivo YAML exportado y, luego, implementar el servicio reconfigurado en Cloud Run.

  1. Exporta tu servicio de Knative serving a un archivo YAML local mediante la ejecución del siguiente comando:

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

    Reemplaza lo siguiente:

    • SERVICE por el nombre de tu servicio de Knative serving.
    • NAMESPACE por el espacio de nombres en el que se ejecuta el servicio.
    • CLUSTER por el nombre del clúster en el que se ejecuta el servicio.
    • FILENAME por un nombre de archivo único de tu elección.

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

    • Debes buscar y reemplazar el espacio de nombres de Kubernetes con el ID de tu proyecto de Google Cloud. Por ejemplo, debes reemplazar namespace:default por namespace:my-unique-id.
    • Debes actualizar todas las configuraciones para cualquiera de las funciones no compatibles.

    • Debes borrar 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, es posible que debas quitar la siguiente configuración de los atributos spec: > template: > spec: > containers::

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

  3. Implementa el archivo .yaml modificado en Cloud Run mediante la marca --platform managed. Obtén más información sobre la implementación.

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

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

    Reemplaza lo siguiente:

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

    • Según la configuración predeterminada, un servicio de Cloud Run no es accesible de forma externa. Para exponer tu servicio de forma pública a Internet y permitir las solicitudes no autenticadas, debes permitir el acceso público (no autenticado).

    • Si deseas configurar este servicio para el acceso privado solo interno, como entre tus servicios de Cloud Run, consulta Autenticación de servicio a servicio.

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

    Ir a Cloud Run

Migra el tráfico a tu servicio

Después de probar los servicios recién implementados y estar listo para migrar todo el tráfico de producción, puedes configurar el dominio personalizado y actualizar los registros DNS con el registrador. Sigue las instrucciones de Asigna dominios personalizados.