Migrer de Kubernetes vers Cloud Run

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 d'API Knative Serving, mais vous n'avez pas besoin d'utiliser Knative dans votre cluster Kubernetes existant pour migrer certaines de vos charges de travail Kubernetes vers Cloud Run.

La ressource principale de Cloud↓Run est le service. Vous pouvez considérer un service Cloud Run comme une abstraction de haut niveau qui ressemble à un déploiement Kubernetes avec un autoscaler de pods intégré et un point de terminaison unique. Un "pod" dans Kubernetes correspond à une "instance" de Cloud Run. Nous vous recommandons de transformer vos déploiements Kubernetes en services Cloud Run, un service à la fois. Vous pourrez également fusionner une partie de la configuration de votre autoscaler horizontal de pods Kubernetes et des services Kubernetes dans le service Cloud Run.

Cloud Run n'utilise pas le concept d'espace de noms. Au lieu de cela, le projet Google Cloud est utilisé comme limite d'isolation entre les ressources. Lors de la migration vers Cloud Run à partir de Kubernetes, nous vous recommandons de créer un projet Google Cloud pour chaque espace de noms. Dans le fichier YAML d'un service Cloud Run, la valeur de l'espace de noms correspond au numéro du projet Google Cloud.

Cloud Run dispose d'une redondance zonale intégrée, ce qui signifie que vous n'avez pas besoin de provisionner l'instance dupliquée pour vous assurer que votre service est résilient aux pannes zonales de la région Google Cloud sélectionnée.

Guide de démarrage rapide

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

Comparaison simple des ressources

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

Les parties dans blue sont différentes et doivent être modifiées. Les parties dans red doivent être supprimées, car Cloud Run dispose d'un autoscaler intégré.

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

Déploiement Kubernetes

Service 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

Migrer un déploiement Kubernetes simple vers Cloud Run

Téléchargez le fichier YAML de votre déploiement dans le répertoire actuel en utilisant la commande suivante :
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
Modifiez le fichier YAML pour qu'il corresponde à un service Cloud Run. Mettez à jour le fichier my-app.yaml :
- Pour l'attribut "kind", remplacez la valeur "Deployment" par "Service".
- Pour l'attribut "apiVersion", remplacez la valeur "apps/v1" par "serving.knative.dev/v1".
- Supprimez l'attribut metadata.namespace ou modifiez sa valeur pour qu'elle corresponde au numéro de votre projet Google Cloud.
- Supprimer spec.replicas et spec.selector
Déployez le fichier my-app.yaml sur Cloud Run à l'aide de la commande suivante, en remplaçant REGION par la région Google Cloud souhaitée, par exemple us-central1 :
```
gcloud run services replace my-app.yaml --region REGION
```

L'appel d'un service Cloud Run est protégé par une autorisation IAM. Si vous souhaitez exposer publiquement le nouveau service Cloud Run à Internet et autoriser les appels non authentifiés, exécutez la commande suivante :

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

Fonctionnalités non compatibles avec Cloud Run

Seules les charges de travail adaptées à Cloud Run peuvent être migrées.

En particulier, les fonctionnalités Kubernetes suivantes ne sont pas compatibles avec Cloud Run :

Nombre fixe d'instances répliquées (replicas) (une solution de contournement consiste à utiliser le même nombre minimal et maximal d'instances)
Cartes de configuration (solution de contournement disponible)
Stratégies d'autoscaler horizontal de pods personnalisées
Service Discovery

Lors de la migration d'un fichier YAML d'un déploiement Kubernetes vers un service Cloud Run, la commande gcloud run services replace renvoie un message d'erreur clair pour tout attribut non compatible avec Cloud Run. Supprimez ou mettez à jour ces attributs, puis répétez la commande jusqu'à ce qu'elle aboutisse.

Vous pouvez consulter la documentation de référence YAML pour obtenir la liste exhaustive des attributs compatibles avec Cloud Run.

Migrer des ressources Kubernetes

Migrer des secrets Kubernetes

Comme Kubernetes, Cloud Run accepte l'installation de secrets en tant que variables d'environnement ou volumes, mais les secrets doivent être stockés dans Secret Manager.

Il existe plusieurs différences importantes 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>.

Consultez la documentation de Secret Manager pour créer un secret et ajouter une nouvelle version de secret pour chaque clé secrète dont dépend votre application Kubernetes.

Migrer les ConfigMaps de Kubernetes

Cloud Run n'a pas d'équivalent pour les ConfigMaps Kubernetes, mais comme les ConfigMaps peuvent être considérés comme des secrets non chiffrés, vous pouvez les transformer en secrets dans Secret Manager. Consultez les instructions figurant sous Migrer des secrets Kubernetes.

Migrer un déploiement Kubernetes

Le déploiement Kubernetes est la ressource dont le mappage est le plus proche du service Cloud Run. Nous vous recommandons de commencer à partir du fichier YAML de votre déploiement Kubernetes et de le modifier pour le transformer en service Cloud Run.

Les principales modifications à apporter sont les suivantes :

Le champ namespace doit être remplacé par le numéro du projet Google Cloud.
Les libellés (metadata.labels et spec.template.metadata.labels) doivent être des libellés Google Cloud valides.
Les conteneurs doivent être stockés dans un registre de conteneurs compatible.
Vous devrez peut-être ajuster les limites de processeur et de mémoire.
Lorsque vous référencez un secret, l'attribut "key" est utilisé pour capturer la version dans Secret Manager, "latest" référençant la dernière version du secret.
serviceAccountName doit référencer un compte de service dans le projet Google Cloud actuel.
Les références à des ConfigMaps (configMapKeyRef) doivent être remplacées par des références à des secrets (secretKeyRef).

Si votre déploiement Kubernetes accède à d'autres ressources de votre cluster Kubernetes ou à des ressources d'un VPC, vous devez connecter le service Cloud Run au VPC approprié.

Migrer un service Kubernetes

Les services Cloud Run exposent automatiquement un point de terminaison unique qui achemine le trafic vers le conteneur avec un containerPort. Après avoir migré votre déploiement Kubernetes vers un service Cloud Run, vous n'avez pas besoin de migrer les services Kubernetes qui acheminaient le trafic vers ce déploiement.

Migrer un objet HorizontalPodAutoscaler Kubernetes

Les services Cloud Run disposent d'un autoscaler horizontal intégré : Cloud Run applique un scaling automatique des pods (appelés "instances") en utilisant une combinaison de facteurs, dans la limite des nombres minimum et maximum d'instances définis pour lui.

Migrez les attributs minReplicas et maxReplicas du HorizontalPodAutoscaler vers les annotations autoscaling.knative.dev/minScale et autoscaling.knative.dev/maxScale du service Cloud Run. Reportez-vous à la documentation sur la configuration du nombre minimal d'instances et du nombre maximal d'instances.

Migrer un job Kubernetes

Étant donné qu'un job Kubernetes est semblable à une exécution de job Cloud Run, vous pouvez migrer vers un job Cloud Run et exécuter le job.

Les exemples suivants montrent la différence structurelle entre une tâche Kubernetes et une tâche Cloud Run :

Job Kubernetes	Job 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

Job Kubernetes

Job 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

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