Migra de Cloud Run a Google Kubernetes Engine

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 migrar a Knative para mover 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 una migración simple.

Comparación de recursos simples

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

Sin embargo, las partes en blue son diferentes y deben modificarse. Se deben agregar las partes en green.

Servicio de Cloud Run	Implementación 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

Servicio de Cloud Run

Implementación 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

Migra un servicio simple de Cloud Run a GKE

Descarga el archivo YAML del servicio en el directorio actual:

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

Modifica el YAML para que coincida con una implementación de Kubernetes:
- Para el atributo “kind”, reemplaza el valor “Service” por “Deployment”.
- Para el atributo “apiVersion”, reemplaza el valor “serving.knative.dev/v1” por “apps/v1”.
- Reemplaza metadata.namespace por el espacio de nombres del clúster de GKE en el que deseas implementar, por ejemplo, default.
- Agrega una etiqueta nueva a metadata y spec.template.metadata.
- Establece una cantidad fija de instancias (“réplicas”) mediante spec.template.spec.replicas y establece un selector de etiquetas en spec.template.spec.selector.
Instala y usa la herramienta de línea de comandos de kubectl para implementar el archivo my-app.yaml en el clúster de GKE:
```
kubectl apply -f ./my-app.yaml
```

Expón la implementación como un servicio:

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

Consideraciones para migrar de Cloud Run a GKE

Clúster:

Cloud Run es una plataforma completamente administrada, mientras que GKE requiere más administración de plataformas. Si aún no creaste un clúster de GKE, usa Autopilot de GKE.
La escalabilidad de las cargas de trabajo de GKE está restringida por el tamaño del clúster. Si no usas un clúster de Autopilot, considera usar elaprovisionamiento automático de nodos y un escalador automático del clúster para cambiar el tamaño del clúster.
Cloud Run tiene una redundancia zonal integrada, por lo tanto, migra a un clúster regional y aprovisiona suficientes réplicas para garantizar que tu servicio sea resistente a una interrupción zonal en la región seleccionada de Google Cloud.

Precios

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

Seguridad:

Al contrario de Cloud Run, invocar un servicio de GKE no está sujeto a un permiso de invocador de IAM.
Debido a que GKE no proporciona un gran aislamiento entre contenedores, considera usar GKE Sandbox si necesitas ejecutar un código desconocido o no confiable.

Redes

Cloud Run requiere un conector de Acceso a VPC sin servidores para acceder a otros recursos de la 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:

Control de versiones de configuración a través de revisiones
División del tráfico para lanzamientos y reversiones graduales de las revisiones
CPU solamente asignada durante el procesamiento de solicitudes
Aumento de CPU
Afinidad de sesión
Las etiquetas en las cargas de trabajo de GKE no son etiquetas de Google Cloud
Etiquetas en cargas de trabajo

Migra recursos de Cloud Run

En las siguientes secciones, se describen los recursos de migración que se usan en Cloud Run, como los servicios, los trabajos y los objetos Secret de Cloud Run.

Migra servicios de Cloud Run

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

Implementación de Kubernetes para crear instancias de contenedor (llamadas “Pods” en Kubernetes)
Servicios de Kubernetes para exponer la implementación en un extremo específico
Horizontal Pod Autoscaler de Kubernetes para escalar la implementación de forma automática.

Los atributos de una implementación de Kubernetes son un superconjunto de los atributos de un servicio 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 debes cambiar lo siguiente:

Reemplaza namespace por el espacio de nombres del clúster de GKE en el que se implementará, por ejemplo, default.
serviceAccountName debe hacer referencia a una cuenta de servicio de Kubernetes, que puede actuar de forma opcional como una cuenta de servicio de IAM con Workload Identity Federation for GKE.
Agrega una LABEL en metadata.labels y spec.template.metadata.labels que se usarán para seleccionar la implementación y los Pods. Por ejemplo: app: NAME
En spec.template:
- Agrega un atributo replicas para especificar una cantidad de “instancias”.
- Agrega un atributo selector.matchLabels que se seleccione en la etiqueta LABEL.
Si tu servicio de Cloud Run activa objetos Secret, consulta Migra objetos Secret.
Si el servicio de Cloud Run migrado accede a los recursos en una nube privada virtual, no necesitas usar un conector de Acceso a VPC sin servidores.

Después de crear la implementación 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

Reemplaza lo siguiente:

NAME: por el nombre de tu servicio.
LABEL: por la etiqueta definida en tu implementación. Por ejemplo, app: NAME.
PORT: por el containerPort del contenedor que recibe las solicitudes en el servicio de Cloud Run, que se establece de forma predeterminada en 8080.

Luego, puedes crear de forma opcional un Horizontal Pod Autoscaler de Kubernetes para escalar automáticamente la cantidad de Pods. Sigue la documentación del ajuste de escala automático horizontal de Pods de Kubernetes para crear un HorizontalPodAutoscaler. Usa los valores de cantidad mínima de instancias (autoscaling.knative.dev/minScale) y cantidad máxima de instancias (autoscaling.knative.dev/maxScale) de tu servicio de Cloud Run como valores para los atributos minReplicas y maxReplicas HorizontalPodAutoscaler.

Migra trabajos de Cloud Run

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

Al contrario de los trabajos de Cloud Run, los trabajos de Kubernetes se ejecutan cuando se crean. Si deseas volver a ejecutar el trabajo, debes crear un trabajo nuevo.

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

Trabajo de Cloud Run	Trabajo 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

Trabajo de Cloud Run

Trabajo 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

Migra objetos Secret

Puedes conservar los objetos Secret existentes en Secret Manager o puedes migrarlos a los objetos Secret de Kubernetes.

Si eliges mantener los objetos Secret en Secret Manager, deberás actualizar la forma en que los usas en GKE.

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

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