Migra de Kubernetes a Cloud Run

Cloud Run y Kubernetes usan imágenes de contenedor estándar como artefactos de implementación, ambos usan un modelo de API declarativo con recursos que se pueden representar en archivos YAML con la misma estructura estándar.

Introducción

La API de Cloud Run Admin v1 está diseñada para maximizar la portabilidad con Kubernetes. Por ejemplo, los recursos de la API de Cloud Run Admin comparten las mismas convenciones de estructura y nombres de atributos que los recursos de Kubernetes. Consulta la referencia de YAML del servicio de Cloud Run.

La API de Cloud Run Admin v1 implementa la especificación de la API de Knative Serving, pero no necesitas usar Knative en tu clúster de Kubernetes existente para migrar algunas de tus cargas de trabajo de Kubernetes a Cloud Run.

El recurso principal de Cloud Run es el servicio. Puedes pensar en un servicio de Cloud Run como una abstracción de alto nivel que se parece a una implementación de Kubernetes con un escalador automático de Pods integrado y un extremo único. Un “Pod” en Kubernetes corresponde a una “instancia” en Cloud Run. Recomendamos transformar tus implementaciones de Kubernetes en servicios de Cloud Run, un servicio a la vez. También podrás combinar cierta configuración de tu Horizontal Pod Autoscaler de Kubernetes y los servicios de Kubernetes en el servicio de Cloud Run.

Cloud Run no tiene el concepto de espacio de nombres, sino que el proyecto de Google Cloud se usa como límite de aislamiento entre los recursos. Cuando migres a Cloud Run desde Kubernetes, te recomendamos crear un proyecto de Google Cloud para cada espacio de nombres. En el YAML de un servicio de Cloud Run, el valor del espacio de nombres es el número del proyecto de Google Cloud.

Cloud Run tiene una redundancia zonal integrada, lo que significa que no necesitas aprovisionar una réplica para garantizar que tu servicio sea resistente a una interrupción zonal en la región seleccionada de Google Cloud.

Nota: Las regiones de México, Montreal y Osaka tienen tres zonas dentro de uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a, al menos, tres centros de datos físicos. Para obtener más información, consulta Ubicaciones de Cloud y ANS de Google Cloud Platform. Para mejorar la confiabilidad de tus cargas de trabajo, considera una implementación multirregional.

Guía de inicio rápido

Esta guía de inicio rápido es un ejemplo de una migración simple.

Comparación de recursos simples

Compara la siguiente implementación simple de Kubernetes llamada my-app con el servicio de Cloud Run equivalente. Observa cómo los archivos YAML son casi idénticos.

Las partes en blue son diferentes y deben modificarse. Las partes en red deben borrarse porque Cloud Run tiene un escalador automático integrado.

Implementación de Kubernetes	Servicio de Cloud Run
apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: default labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world replicas: 3 selector: matchLabels: app: my-app	apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world

Migra una implementación simple de Kubernetes a Cloud Run

1. Descarga el archivo YAML de tu implementación en el directorio actual con el siguiente comando:

   kubectl get deployment  my-app -o yaml > my-app.yaml

2. Modifica el YAML para que coincida con un servicio de Cloud Run. Actualiza el archivo my-app.yaml:

   • Para el atributo “kind”, reemplaza el valor “Deployment” por “Service”.
   • Para el atributo “apiVersion”, reemplaza el valor “apps/v1” por “serving.knative.dev/v1”.
   • Borra el atributo metadata.namespace o cambia su valor para que coincida con el número de tu proyecto de Google Cloud.
   • Borra spec.replicas y spec.selector

3. Implementa el archivo my-app.yaml en Cloud Run mediante el siguiente comando y reemplaza REGION por la región de Google Cloud deseada, por ejemplo us-central1:

   gcloud run services replace my-app.yaml --region REGION

La invocación de un servicio de Cloud Run está protegida por un permiso de IAM. Si deseas exponer el nuevo servicio de Cloud Run públicamente a Internet y permitir invocaciones no autenticadas, ejecuta el siguiente comando:

gcloud run services add-iam-policy-binding my-app --member="allUsers" --role="roles/run.invoker" --region REGION

Funciones no compatibles con Cloud Run

Solo se pueden migrar las cargas de trabajo que se ajustan a Cloud Run.

En particular, Cloud Run no admite las siguientes funciones de Kubernetes:

• Números fijos de replicas (una solución alternativa es usar la misma cantidad de instancias mínimas y máximas)
• Config Maps (solución alternativa disponible)
• Estrategias personalizadas del Horizontal Pod Autoscaler
• Service Discovery

Cuando migras un archivo YAML de una implementación de Kubernetes a un servicio de Cloud Run, el comando gcloud run services replace mostrará un mensaje de error claro para cualquier atributo que no sea compatible con Cloud Run. Borra o actualiza estos atributos y, luego, repite el comando hasta que tenga éxito.

Puedes consultar la Referencia de YAML para obtener una lista exhaustiva de los atributos admitidos por Cloud Run.

Migra recursos de Kubernetes

Migra secretos de Kubernetes

Al igual que Kubernetes, Cloud Run admite la activación de secretos como variables o volúmenes de entorno, pero los secretos deben almacenarse en Secret Manager.

Existen varias diferencias importantes entre los secretos de Secret Manager y los de Kubernetes:

• Caracteres permitidos en los nombres:
  • Secretos de Kubernetes: [a-z0-9-.]{1,253}
  • Secretos de Secret Manager: [a-zA-Z0-9_-]{1,255}
• Control de versiones: Los secretos de Secret Manager tienen versiones, mientras que los secretos de Kubernetes no las tienen.
• Carga útil: Los secretos de Secret Manager contienen un solo []byte, mientras que los de Kubernetes contienen un map<string, string>.

Sigue la documentación de Secret Manager a fin de crear un secreto y agregar una versión nueva del secreto para cada clave secreta de la que dependa tu app de Kubernetes.

Migra ConfigMaps de Kubernetes

Cloud Run no tiene un equivalente de ConfigMaps de Kubernetes, pero como ConfigMaps se puede ver como Secrets sin encriptar, puedes transformar tus ConfigMaps en secretos en Secret Manager. Consulta las instrucciones que aparecen en Migra secretos de Kubernetes.

Migra una implementación de Kubernetes

La implementación de Kubernetes es el recurso que se asigna más cerca del servicio de Cloud Run. Recomendamos comenzar desde el YAML de tu implementación de Kubernetes y editarlo para transformarlo en un servicio de Cloud Run.

Los principales cambios obligatorios son los siguientes:

• El namespace debe reemplazarse por el número de proyecto de Google Cloud.
• Las etiquetas (metadata.labels y spec.template.metadata.labels) deben ser etiquetas de Google Cloud válidas.
• Los contenedores deben almacenarse en un registro de contenedores compatible.
• Es posible que debas ajustar los límites de CPU y memoria.
• Cuando se hace referencia a un secreto, el atributo “key” se usa para capturar la versión en Secret Manager, y “latest” hace referencia a la versión más reciente del secreto.
• serviceAccountName debe hacer referencia a una cuenta de servicio en el proyecto actual de Google Cloud.
• Las referencias a ConfigMaps (configMapKeyRef) deben reemplazarse por referencias a secretos (secretKeyRef).

Si tu implementación de Kubernetes accede a otros recursos de tu clúster de Kubernetes o a los recursos en una VPC, debes conectar el servicio de Cloud Run a la VPC adecuada.

Migra un servicio de Kubernetes

Los servicios de Cloud Run exponen automáticamente un extremo único que enruta el tráfico al contenedor con un containerPort. Después de migrar tu implementación de Kubernetes a un servicio de Cloud Run, no necesitas migrar los servicios de Kubernetes que enrutan el tráfico a esta implementación.

Migra un HorizontalPodAutoscaler de Kubernetes

Los servicios de Cloud Run tienen un escalador automático horizontal integrado: Cloud Run escala de forma automática los pods (llamados “instancias”) mediante una combinación de factores dentro de los límites del mínimo definido y la cantidad máxima de instancias.

Migra los atributos minReplicas y maxReplicas de HorizontalPodAutoscaler a las anotaciones autoscaling.knative.dev/minScale y autoscaling.knative.dev/maxScale del servicio de Cloud Run. Consulta la documentación sobre la configuración de cantidad mínima de instancias y de cantidad máxima de instancias.

Migra un trabajo de Kubernetes

Debido a que un trabajo de Kubernetes es similar a una ejecución de trabajo de Cloud Run, puedes migrar a un trabajo de Cloud Run y ejecutar el trabajo.

En los siguientes ejemplos, se muestra la diferencia estructural entre un trabajo de Kubernetes y uno de Cloud Run:

Trabajo de Kubernetes	Trabajo de Cloud Run
apiVersion: batch/v1 kind: Job metadata: name: my-job spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job	apiVersion: run.googleapis.com/v1 kind: Job metadata: name: my-job spec: template: spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job

Estrategia de migración

Después de crear los recursos equivalentes, la exposición de extremos externos detrás de un balanceador de cargas de aplicaciones externo global te permite migrar el tráfico de forma gradual entre Cloud Run y Google Kubernetes Engine (GKE).