Migrer depuis Cloud Run vers Google Kubernetes Engine

Cloud Run et Kubernetes utilisent tous deux des images de conteneur standards comme artefacts de déploiement et un modèle d'API déclaratif dont les ressources peuvent être représentées dans des fichiers YAML utilisant la même structure standard.

Introduction

L'API Admin Cloud Run v1 est conçue pour optimiser la portabilité avec Kubernetes. Par exemple, les ressources de l'API Admin Cloud Run partagent les mêmes conventions de structure et les mêmes noms d'attributs que les ressources Kubernetes. Consultez la documentation de référence YAML sur le service Cloud Run.

L'API Cloud Run Admin v1 met en œuvre la spécification de l'API Knative Serving. Toutefois, vous n'avez pas besoin de migrer vers Knative pour déplacer vos charges de travail Cloud Run vers un cluster Kubernetes, tel que GKE.

Guide de démarrage rapide

Ce guide de démarrage rapide est un exemple de migration simple.

Comparaison simple des ressources

Comparez le service Cloud Run simple suivant, nommé my-app, avec le déploiement Kubernetes équivalent. Notez que les fichiers YAML sont presque identiques.

Cependant, les parties en blue sont différentes et doivent être modifiées. Les parties en green doivent être ajoutées.

Service Cloud Run	Déploiement 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

Service Cloud Run

Déploiement 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

Migrer un service Cloud Run simple vers GKE

Téléchargez le fichier YAML du service dans le répertoire actuel :

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

Modifiez le fichier YAML pour qu'il corresponde à un déploiement Kubernetes :
- Pour l'attribut "kind", remplacez la valeur "Service" par "Deployment".
- Pour l'attribut "apiVersion", remplacez la valeur "serving.knative.dev/v1" par "apps/v1".
- Remplacez metadata.namespace par l'espace de noms du cluster GKE que vous souhaitez déployer, par exemple default.
- Ajoutez une étiquette à metadata et spec.template.metadata.
- Définissez un nombre fixe d'instances ("instances répliquées") à l'aide de spec.template.spec.replicas et définissez un sélecteur d'étiquettes dans spec.template.spec.selector.
Installez et utilisez l'outil de ligne de commande kubectl pour déployer le fichier my-app.yaml sur votre cluster GKE :
```
kubectl apply -f ./my-app.yaml
```

Exposez le déploiement en tant que service :

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

Éléments à prendre en compte lors de la migration de Cloud Run vers GKE

Cluster :

Cloud Run est une plate-forme entièrement gérée, tandis que GKE nécessite davantage de gestion de plate-forme. Si vous n'avez pas encore créé de cluster GKE, utilisez GKE Autopilot.
L'évolutivité des charges de travail GKE est limitée par la taille du cluster. Si vous n'utilisez pas de cluster Autopilot, envisagez d'utiliser le provisionnement automatique des nœuds et un autoscaler de cluster pour redimensionner votre cluster.
Cloud Run dispose d'une redondance zonale intégrée. Vous devez donc migrer vers un cluster régional et provisionner suffisamment d'instances répliquées pour vous assurer que votre service est résilient aux pannes zonales dans la région Google Cloud sélectionnée.

Tarifs

Cloud Run vous facture les ressources utilisées, tandis que GKE vous facture les ressources provisionnées.

Sécurité :

Contrairement à Cloud Run, l'appel d'un service GKE n'est pas soumis à une autorisation de demandeur IAM.
Étant donné que GKE n'offre pas une forte isolation entre les conteneurs, envisagez d'utiliser GKE Sandbox si vous devez exécuter du code inconnu ou non approuvé.

Mise en réseau

Cloud Run nécessite un connecteur d'accès au VPC sans serveur pour accéder aux autres ressources d'un VPC. Les charges de travail GKE se trouvent directement dans un VPC et n'ont pas besoin de connecteur.

Fonctionnalités non compatibles avec Google Kubernetes Engine

Les fonctionnalités Cloud Run suivantes ne sont pas disponibles dans GKE :

Gestion des versions de configuration via des révisions
Répartition du trafic pour les déploiements progressifs et les rollbacks des révisions
Processeur alloué uniquement lors du traitement des requêtes
Optimisation du processeur
Affinité de session
Étiquettes sur les charges de travail GKE différentes de celles de Google Cloud
Tags sur les charges de travail

Migrer des ressources Cloud Run

Les sections suivantes décrivent la migration des ressources utilisées dans Cloud Run, telles que les services, les jobs et les secrets Cloud Run.

Migrer des services Cloud Run

Vous pouvez migrer un service Cloud Run vers les ressources suivantes dans GKE :

Déploiement Kubernetes pour créer des instances (appelées "pods" dans Kubernetes).
Services Kubernetes pour exposer le déploiement sur un point de terminaison spécifique.
Autoscaler horizontal de pods Kubernetes : permet d'effectuer le scaling automatique du déploiement.

Les attributs d'un déploiement Kubernetes correspondent à un sur-ensemble des attributs d'un service Cloud Run. Comme indiqué dans le guide de démarrage rapide, après avoir remplacé les attributs apiVersion et kind par apps/v1 et Deployment, vous devez également modifier les éléments suivants :

Remplacez namespace par l'espace de noms du cluster GKE sur lequel effectuer le déploiement, par exemple default.
serviceAccountName doit référencer un compte de service Kubernetes, qui peut éventuellement agir en tant que compte de service IAM avec Workload Identity Federation for GKE.
Ajoutez une étiquette (LABEL) à metadata.labels et spec.template.metadata.labels. Elles permettront de sélectionner le déploiement et les pods. Exemple : app: NAME
Sous spec.template :
- Ajoutez un attribut replicas pour spécifier un certain nombre d'instances.
- Ajoutez un attribut selector.matchLabels qui sélectionne l'étiquette LABEL.
Si votre service Cloud Run installe des secrets, consultez la section Migrer des secrets.
Si le service Cloud Run migré accède aux ressources sur un cloud privé virtuel, vous n'avez pas besoin d'utiliser un connecteur d'accès au VPC sans serveur.

Après avoir créé le déploiement Kubernetes, créez des services Kubernetes pour l'exposer :

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

Remplacez :

NAME par le nom de votre service ;
LABEL par l'étiquette définie dans votre déploiement (par exemple, app: NAME) ;
PORT par le containerPort du conteneur qui reçoit les requêtes dans le service Cloud Run, dont la valeur par défaut est 8080.

Vous pouvez éventuellement créer un autoscaler horizontal de pods Kubernetes afin de procéder au scaling automatique du nombre de pods. Suivez la documentation sur l'autoscaling horizontal de pods de Kubernetes pour créer un HorizontalPodAutoscaler. Utilisez les valeurs du nombre minimal d'instances (autoscaling.knative.dev/minScale) et du nombre maximal d'instances (autoscaling.knative.dev/maxScale) de votre service Cloud Run en tant que valeurs pour les attributs minReplicas et maxReplicas HorizontalPodAutoscaler.

Migrer des jobs Cloud Run

Vous pouvez migrer un job Cloud Run vers un job Kubernetes sur GKE.

Contrairement aux jobs Cloud Run, les jobs Kubernetes sont exécutés au moment de leur création. Si vous souhaitez exécuter à nouveau le job, vous devez en créer un nouveau.

Les exemples suivants montrent la différence structurelle entre un job Cloud Run et un job Kubernetes :

Job Cloud Run	Job 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

Job Cloud Run

Job 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

Migrer des secrets

Vous pouvez conserver les secrets existants dans Secret Manager ou les migrer vers les secrets Kubernetes.

Si vous choisissez de conserver les secrets dans Secret Manager, vous devez mettre à jour la manière dont vous les utilisez dans GKE.

Si vous choisissez d'effectuer la migration depuis Secret Manager vers des secrets Kubernetes, tenez compte de ces différences entre les secrets Secret Manager et les secrets Kubernetes :

Caractères autorisés dans les noms :
- Secrets Kubernetes : [a-z0-9-.]{1,253}
- Secrets Secret Manager : [a-zA-Z0-9_-]{1,255}
Gestion des versions : les secrets de Secret Manager bénéficient d'une gestion des versions, contrairement aux secrets Kubernetes.
Charge utile : les secrets de Secret Manager contiennent un seul objet []byte, tandis que les secrets Kubernetes contiennent un objet map<string, string>.

Stratégie de migration

Après avoir créé les ressources équivalentes, l'exposition de points de terminaison externes derrière un équilibreur de charge d'application externe global vous permet de migrer progressivement le trafic entre Cloud Run et Google Kubernetes Engine (GKE).