Migrar de Kubernetes a Cloud Run

Tanto Cloud Run como Kubernetes usan imágenes de contenedor estándar como artefactos de implementación y 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 Admin v1 de Cloud Run se ha diseñado para maximizar la portabilidad con Kubernetes. Por ejemplo, los recursos de la API Admin de Cloud Run comparten las mismas convenciones de estructura y nombres de atributos que los recursos de Kubernetes. Consulta la referencia de YAML de servicios de Cloud Run.

La versión 1 de la API Admin de Cloud Run implementa la especificación de la API Serving de Knative, pero no es necesario que uses Knative en tu clúster de Kubernetes para migrar algunas de tus cargas de trabajo de Kubernetes a Cloud Run.

El recurso principal de Cloud Run es el servicio. Puedes considerar un servicio de Cloud Run como una abstracción de alto nivel que se parece a un despliegue de Kubernetes con un autoescalador de pods integrado y un endpoint único. Un "pod" en Kubernetes corresponde a una "instancia" en Cloud Run. Te recomendamos que transformes tus implementaciones de Kubernetes en servicios de Cloud Run, un servicio cada vez. También podrás combinar parte de la configuración de tu autoescalador de pods horizontal de Kubernetes y de los servicios de Kubernetes en el servicio de Cloud Run.

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

Cloud Run tiene una redundancia zonal integrada, lo que significa que no tienes que aprovisionar réplicas para asegurarte de que tu servicio sea resistente a las interrupciones zonales en la región Google Cloud seleccionada.

Guía de inicio rápido

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

Comparación de recursos sencilla

Compara el siguiente despliegue sencillo de Kubernetes llamado my-app con el servicio de Cloud Run equivalente. Observa que los archivos YAML son casi idénticos.

Las partes de blue son diferentes y deben cambiarse. Las partes en red se deben eliminar porque Cloud Run tiene un escalador automático integrado.

Despliegue de KubernetesServicio 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

Migrar un despliegue sencillo 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 archivo YAML para que coincida con un servicio de Cloud Run. Actualiza el archivo de my-app.yaml:

    • En el atributo "kind", sustituye el valor "Deployment" por "Service".
    • En el atributo "apiVersion", sustituye el valor "apps/v1" por "serving.knative.dev/v1".
    • Elimine el atributo metadata.namespace o cambie su valor para que coincida con su número de proyecto Google Cloud .
    • Eliminar spec.replicas y spec.selector

  3. Despliega el archivo my-app.yaml en Cloud Run con el siguiente comando. Sustituye REGION por la región Google Cloud que quieras, por ejemplo, europe-west1:

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

La invocación de un servicio de Cloud Run está protegida por un permiso de gestión de identidades y accesos. Si quieres exponer públicamente el nuevo servicio de Cloud Run en Internet y permitir el acceso público, ejecuta el siguiente comando:

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

Funciones no admitidas por Cloud Run

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

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

  • Número fijo de replicas (para solucionar este problema, usa el mismo número de instancias mínimas y máximas
  • ConfigMaps (solución alternativa disponible)
  • Estrategias de autoescalado horizontal de pods personalizadas
  • Descubrimiento de servicios
  • Disco local (efímero y persistente)

Al migrar un archivo YAML de un despliegue de Kubernetes a un servicio de Cloud Run, el comando gcloud run services replace devolverá un mensaje de error claro para cualquier atributo que no sea compatible con Cloud Run. Elimina o actualiza estos atributos y, a continuación, repite el comando hasta que se complete correctamente.

Puedes consultar la referencia de YAML para ver una lista exhaustiva de los atributos compatibles con Cloud Run.

Migrar recursos de Kubernetes

Migrar secretos de Kubernetes

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

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

  • Caracteres admitidos en los nombres:
  • Control de versiones: los secretos de Secret Manager tienen versiones, mientras que los secretos de Kubernetes no.
  • Carga útil: los secretos de Secret Manager contienen un solo []byte, mientras que los secretos de Kubernetes contienen un map<string, string>.

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

Migrar ConfigMaps de Kubernetes

Cloud Run no tiene un equivalente de los ConfigMaps de Kubernetes, pero, como los ConfigMaps se pueden considerar secretos sin cifrar, puedes transformar tus ConfigMaps en secretos en Secret Manager. Consulta las instrucciones en la sección Migrar secretos de Kubernetes.

Migrar un despliegue de Kubernetes

El despliegue de Kubernetes es el recurso que se corresponde más con el servicio de Cloud Run. Te recomendamos que empieces con el archivo YAML de tu despliegue de Kubernetes y lo edites para transformarlo en un servicio de Cloud Run.

Estos son los principales cambios obligatorios:

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

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

Migrar un servicio de Kubernetes

Los servicios de Cloud Run exponen automáticamente un punto final único que dirige el tráfico al contenedor con un containerPort. Una vez que hayas migrado tu despliegue de Kubernetes a un servicio de Cloud Run, no será necesario que migres los servicios de Kubernetes que dirigían el tráfico a este despliegue.

Migrar un HorizontalPodAutoscaler de Kubernetes

Los servicios de Cloud Run tienen un autoescalador horizontal integrado: Cloud Run escala automáticamente los pods (llamados "instancias") mediante una combinación de factores dentro de los límites de su número mínimo y máximo de instancias definido.

Migra los atributos minReplicas y maxReplicas del HorizontalPodAutoscaler a las anotaciones autoscaling.knative.dev/minScale y autoscaling.knative.dev/maxScale del servicio de Cloud Run. Consulta la documentación sobre cómo configurar las instancias mínimas y las instancias máximas.

Migrar una tarea de Kubernetes

Porque un trabajo de Kubernetes es similar a una ejecución de trabajo de Cloud Run. Puedes migrar a una tarea de Cloud Run y ejecutarla.

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

Tarea de KubernetesTarea 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, puedes exponer los endpoints externos detrás de un balanceador de carga de aplicaciones externo global para migrar gradualmente el tráfico entre Cloud Run y Google Kubernetes Engine (GKE).