Migre do Cloud Run para o Google Kubernetes Engine

O Cloud Run e o Kubernetes usam imagens de contentores padrão como artefactos de implementação. Ambos usam um modelo de API declarativo com recursos que podem ser representados em ficheiros YAML com a mesma estrutura padrão.

Introdução

A API Cloud Run Admin v1 foi concebida para maximizar a portabilidade com o Kubernetes. Por exemplo, os recursos da API Cloud Run Admin partilham as mesmas convenções de estrutura e nomes de atributos que os recursos do Kubernetes. Consulte a referência YAML do serviço do Cloud Run.

A API Cloud Run Admin v1 implementa a especificação da API Knative Serving, mas não precisa de migrar para o Knative para mover as suas cargas de trabalho do Cloud Run para um cluster do Kubernetes, como o GKE.

Início rápido

Este início rápido é um exemplo de uma migração simples.

Comparação simples de recursos

Compare o seguinte serviço simples do Cloud Run denominado my-app com a implementação equivalente do Kubernetes. Repare como os ficheiros YAML são quase idênticos.

No entanto, as partes em blue são diferentes e têm de ser alteradas. As partes em green devem ser adicionadas.

Serviço do Cloud RunImplementação do 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

Migre um serviço simples do Cloud Run para o GKE

  1. Transfira o ficheiro YAML do serviço para o diretório atual:

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

  2. Modifique o YAML para corresponder a uma implementação do Kubernetes:

    • Para o atributo "kind": substitua o valor "Service" por "Deployment"
    • Para o atributo "apiVersion": substitua o valor "serving.knative.dev/v1" por "apps/v1"
    • Substitua metadata.namespace pelo espaço de nomes do cluster do GKE no qual quer fazer a implementação, por exemplo, default.
    • Adicione uma nova etiqueta em metadata e spec.template.metadata.
    • Defina um número fixo de instâncias ("réplicas") através de spec.template.spec.replicas e defina um seletor de etiquetas em spec.template.spec.selector.

  3. Instale e use a ferramenta de linha de comandos kubectl para implementar o ficheiro my-app.yaml no seu cluster do GKE:

    kubectl apply -f ./my-app.yaml

  4. Exponha a implementação como um serviço:

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

Considerações ao migrar do Cloud Run para o GKE

Cluster:

  • O Cloud Run é uma plataforma totalmente gerida, enquanto o GKE requer mais gestão da plataforma. Se ainda não criou um cluster do GKE, use o GKE Autopilot.

  • A escalabilidade das cargas de trabalho do GKE é restrita pelo tamanho do cluster. Se não estiver a usar um cluster do Autopilot, considere usar o aprovisionamento automático de nós e um autoscaler de clusters para redimensionar o cluster.

  • O Cloud Run tem uma redundância zonal incorporada. Por isso, migre para um cluster regional e aprovisione réplicas suficientes para garantir que o seu serviço é resiliente a uma interrupção zonal na Google Cloud região selecionada.

Preços

O Cloud Run cobra pelos recursos usados, enquanto o GKE cobra pelos recursos aprovisionados.

Segurança:

  • Ao contrário do Cloud Run, a invocação de um serviço do GKE não está sujeita a uma autorização de invocador do IAM.

  • Uma vez que o GKE não oferece um isolamento forte entre contentores, considere usar o GKE Sandbox se precisar de executar código desconhecido ou não fidedigno.

Redes

O Cloud Run requer um conetor de acesso a VPC sem servidor para aceder a outros recursos numa VPC. As cargas de trabalho do GKE estão diretamente numa VPC e não precisam de um conetor.

Funcionalidades não suportadas pelo Google Kubernetes Engine

As seguintes funcionalidades do Cloud Run não estão disponíveis no GKE:

Migre recursos do Cloud Run

As secções seguintes descrevem a migração de recursos usados no Cloud Run, como serviços, tarefas e segredos do Cloud Run.

Migre serviços do Cloud Run

Pode migrar um serviço do Cloud Run para os seguintes recursos no GKE:

  1. Implementação do Kubernetes para criar instâncias (denominadas "pods" no Kubernetes).
  2. Serviços do Kubernetes para expor a implementação num ponto final específico.
  3. Redimensionador automático horizontal de pods do Kubernetes: para dimensionar automaticamente a implementação.

Os atributos de uma implementação do Kubernetes são um superconjunto dos atributos de um serviço do Cloud Run. Conforme mostrado no início rápido, depois de alterar os atributos apiVersion e kind para apps/v1 e Deployment, também tem de alterar o seguinte:

  • Substitua namespace pelo espaço de nomes do cluster do GKE para implementar, por exemplo, default.
  • serviceAccountName deve fazer referência a uma conta de serviço do Kubernetes, que pode, opcionalmente, atuar como uma conta de serviço do IAM com a federação de identidades da carga de trabalho para o GKE.
  • Adicione um LABEL em metadata.labels e spec.template.metadata.labels que vai ser usado para selecionar a implementação e os pods. Por exemplo: app: NAME
  • Em spec.template:
    • Adicione um atributo replicas para especificar um número de "instâncias".
    • Adicione um atributo selector.matchLabels que selecione a etiqueta LABEL.
  • Se o seu serviço do Cloud Run montar segredos, consulte o artigo Migre segredos.
  • Se o serviço do Cloud Run migrado estava a aceder a recursos numa nuvem virtual privada, não precisa de usar um conetor de acesso a VPC sem servidor.

Depois de criar a implementação do Kubernetes, crie um serviço do Kubernetes para a expor:

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

Substituir:

  • NAME: com o nome do seu serviço.
  • LABEL: com a etiqueta definida na sua implementação. Por exemplo, app: NAME.
  • PORT: com a containerPort do contentor que recebe pedidos no serviço do Cloud Run, que tem como predefinição 8080.

Em seguida, pode criar opcionalmente um redimensionador automático horizontal de pods do Kubernetes para dimensionar automaticamente o número de pods. Siga a documentação de escala automática horizontal de pods do Kubernetes para criar um HorizontalPodAutoscaler. Use os valores de instâncias mínimas (autoscaling.knative.dev/minScale) e instâncias máximas (autoscaling.knative.dev/maxScale) do seu serviço do Cloud Run como valores para os atributos minReplicas e maxReplicas HorizontalPodAutoscaler.

Migre tarefas do Cloud Run

Pode migrar uma tarefa do Cloud Run para uma tarefa do Kubernetes no GKE.

Ao contrário das tarefas do Cloud Run, as tarefas do Kubernetes são executadas quando são criadas. Se quiser executar a tarefa novamente, tem de criar uma nova tarefa.

Os exemplos seguintes mostram a diferença estrutural entre uma tarefa do Cloud Run e uma tarefa do Kubernetes:

Tarefa do Cloud RunTarefa do 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

Migre segredos

Pode manter os segredos existentes no Secret Manager ou migrá-los para segredos do Kubernetes.

Se optar por manter os segredos no Secret Manager, tem de atualizar a forma como os usa no GKE

Se optar por migrar do Secret Manager para os segredos do Kubernetes, considere estas diferenças entre os segredos do Secret Manager e os segredos do Kubernetes:

  • Carateres permitidos nos nomes:
  • Controlo de versões: os Secrets do Secret Manager têm controlo de versões, ao passo que os Secrets do Kubernetes não têm.
  • Payload: os Secrets do Secret Manager contêm um único []byte, enquanto os Secrets do Kubernetes contêm um map<string, string>.

Estratégia de migração

Depois de criar os recursos equivalentes, a exposição de pontos finais externos atrás de um Application Load Balancer externo global permite-lhe migrar gradualmente o tráfego entre o Cloud Run e o Google Kubernetes Engine (GKE).