Migrar de Cloud Run a Google Kubernetes Engine

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 API Admin de Cloud Run v1 implementa la especificación de la API Serving de Knative, pero no es necesario que migres a Knative para trasladar tus cargas de trabajo de Cloud Run a un clúster de Kubernetes, como GKE.

Guía de inicio rápido

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

Comparación de recursos sencilla

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

Sin embargo, las partes de blue son diferentes y deben cambiarse. Se deben añadir las partes de green.

Servicio de Cloud RunDespliegue de Kubernetes
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
  namespace: 'PROJECT_NUMBER'
spec:
  template:
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world

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

Migrar un servicio sencillo de Cloud Run a GKE

  1. Descarga el archivo YAML de servicio en el directorio actual:

    gcloud run services describe my-app --format export > my-app.yaml

  2. Modifica el archivo YAML para que coincida con un despliegue de Kubernetes:

    • En el atributo "kind", sustituye el valor "Service" por "Deployment".
    • En el atributo "apiVersion", sustituye el valor "serving.knative.dev/v1" por "apps/v1".
    • Sustituye metadata.namespace por el espacio de nombres del clúster de GKE en el que quieras hacer el despliegue. Por ejemplo, default.
    • Añade una etiqueta nueva en metadata y spec.template.metadata.
    • Define un número fijo de instancias ("réplicas") mediante spec.template.spec.replicas y define un selector de etiquetas en spec.template.spec.selector.

  3. Instala y usa la herramienta de línea de comandos kubectl para desplegar el archivo my-app.yaml en tu clúster de GKE:

    kubectl apply -f ./my-app.yaml

  4. Expón el despliegue como un servicio:

    kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080

Consideraciones al migrar de Cloud Run a GKE

Clúster:

Precios

Cloud Run cobra por los recursos utilizados, mientras que GKE cobra por los recursos aprovisionados.

Seguridad:

Redes

Cloud Run requiere un conector de acceso a VPC sin servidor para acceder a otros recursos de una VPC. Las cargas de trabajo de GKE están directamente en una VPC y no necesitan un conector.

Funciones no compatibles con Google Kubernetes Engine

Las siguientes funciones de Cloud Run no están disponibles en GKE:

Migrar recursos de Cloud Run

En las siguientes secciones se describe cómo migrar los recursos que se usan en Cloud Run, como los servicios, los trabajos y los secretos de Cloud Run.

Migrar servicios de Cloud Run

Puedes migrar un servicio de Cloud Run a los siguientes recursos de GKE:

  1. Despliegue de Kubernetes para crear instancias (llamadas "pods" en Kubernetes).
  2. Servicios de Kubernetes para exponer el despliegue en un endpoint específico.
  3. Herramienta de adaptación dinámica horizontal de pods de Kubernetes: para escalar el despliegue automáticamente.

Los atributos de una implementación de Kubernetes son un superconjunto de los atributos de los servicios de Cloud Run. Como se muestra en la guía de inicio rápido, después de cambiar los atributos apiVersion y kind a apps/v1 y Deployment, también debe cambiar lo siguiente:

  • Sustituye namespace por el espacio de nombres del clúster de GKE en el que quieras desplegar el servicio; por ejemplo, default.
  • serviceAccountName debe hacer referencia a una cuenta de servicio de Kubernetes, que puede actuar opcionalmente como una cuenta de servicio de gestión de identidades y accesos con la federación de identidades de cargas de trabajo para GKE.
  • Añade un LABEL en metadata.labels y spec.template.metadata.labels que se usará para seleccionar la implementación y los pods. Por ejemplo: app: NAME
  • En spec.template:
    • Añade un atributo replicas para especificar un número de "instancias".
    • Añade un atributo selector.matchLabels que seleccione la etiqueta LABEL.
  • Si tu servicio de Cloud Run monta secretos, consulta Migrar secretos.
  • Si el servicio de Cloud Run migrado accedía a recursos de una nube privada virtual, no es necesario que uses un conector de acceso a VPC sin servidor.

Después de crear el despliegue de Kubernetes, crea un servicio de Kubernetes para exponerlo:

apiVersion: v1
kind: Service
metadata:
  name: NAME
spec:
  selector:
    LABEL
  ports:
    - protocol: TCP
      port: 80
      targetPort: PORT

Sustituye:

  • NAME: con el nombre de tu servicio.
  • LABEL: con la etiqueta definida en tu implementación. Por ejemplo, app: NAME.
  • PORT: con el containerPort del contenedor que recibe solicitudes en el servicio Cloud Run, que tiene el valor predeterminado 8080.

Después, puedes crear un autoescalador horizontal de pods de Kubernetes para escalar automáticamente el número de pods. Sigue la documentación sobre autoescalado horizontal de pods de Kubernetes para crear un HorizontalPodAutoscaler. Usa los valores de instancias mínimas (autoscaling.knative.dev/minScale) e instancias máximas (autoscaling.knative.dev/maxScale) de tu servicio de Cloud Run como valores de los atributos minReplicas y maxReplicas HorizontalPodAutoscaler.

Migrar tareas de Cloud Run

Puedes migrar un trabajo de Cloud Run a un trabajo de Kubernetes en GKE.

A diferencia de las tareas de Cloud Run, las tareas de Kubernetes se ejecutan cuando se crean. Si quieres volver a ejecutar el trabajo, debes crear uno nuevo.

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

Tarea de Cloud RunTarea de Kubernetes
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

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - image: us-docker.pkg.dev/cloudrun/container/job

Migrar secretos

Puedes mantener los secretos en Secret Manager o migrarlos a secretos de Kubernetes.

Si decides conservar los secretos en Secret Manager, tendrás que actualizar la forma en que los usas en GKE.

Si decides migrar de Secret Manager a los secretos de Kubernetes, ten en cuenta estas diferencias 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>.

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).