Migrar do Cloud Run para o Google Kubernetes Engine

O Cloud Run e o Kubernetes usam imagens de contêiner padrão como artefatos de implantação, ambos usam um modelo de API declarativa com recursos que podem ser representados em arquivos YAML com a mesma estrutura padrão.

Introdução

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

A API Cloud Run Admin v1 implementa a especificação da API Knative Serving, mas não é necessário migrar para o Knative para mover suas cargas de trabalho do Cloud Run para um Cluster do Kubernetes, como o GKE.

Guia de início rápido

Este guia de 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 chamado my-app com a implantação do Kubernetes equivalente. Observe como os arquivos YAML são quase idênticos.

As partes em blue são diferentes e precisam ser alteradas. As partes em green precisam ser adicionadas.

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

Serviço do Cloud Run

Implantaçã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

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

Faça o download do arquivo YAML do serviço no diretório atual:

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

Modifique o YAML para corresponder a uma implantaçã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 namespace do cluster do GKE em que você quer implantar, por exemplo, default.
- Adicione um novo marcador a menos de metadata e spec.template.metadata.
- Defina um número fixo de instâncias ("réplicas") usando spec.template.spec.replicas e um seletor de rótulo em spec.template.spec.selector.
Instale e use a ferramenta de linha de comando kubectl para implantar o arquivo my-app.yaml no cluster do GKE:
```
kubectl apply -f ./my-app.yaml
```

Exponha a implantaçã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 gerenciada, enquanto o GKE requer mais gerenciamento de plataforma. Se você ainda não criou um cluster do GKE, use o Autopilot do GKE.
A escalonabilidade das cargas de trabalho do GKE é restrita pelo tamanho do cluster. Se você não estiver usando um cluster do Autopilot, utilize o provisionamento automático de nós e um escalonador automático de clusters para redimensionar o cluster.
O Cloud Run tem umaredundância zonal integrada , então migre para umacluster regional e provisionar réplicas suficientes para garantir que o serviço seja resiliente a uma falha temporária zonal na região selecionada do Google Cloud.

Preços

O Cloud Run cobra por recursos usados, enquanto o GKE cobra por recursos provisionados.

Segurança :

Ao contrário do que acontece no Cloud Run, invocar um serviço do GKE não está sujeito a uma permissão do invocador do IAM.
Como o GKE não fornece um isolamento forte entre contêineres, use o GKE Sandbox se precisar executar um código desconhecido ou não confiável.

Rede

O Cloud Run requer um conector de acesso VPC sem servidor para acessar outros recursos em uma VPC. As cargas de trabalho do GKE estão diretamente em uma VPC e não precisam de um conector.

Recursos não compatíveis com o Google Kubernetes Engine

Os seguintes recursos do Cloud Run não estão disponíveis no GKE:

Controle de versões de configuração com revisões
Divisão de tráfego para lançamentos graduais e reversões de revisões
CPU alocada apenas durante o processamento da solicitação
Otimização de CPU
Afinidade da sessão
Os identificadores nas cargas de trabalho do GKE não são do Google Cloud
Tags em cargas de trabalho

Migrar recursos do Cloud Run

As seções a seguir descrevem a migração de recursos usados no Cloud Run, como serviços, jobs e secrets do Cloud Run.

Migrar os serviços do Cloud Run

É possível migrar um serviço do Cloud Run para os seguintes recursos no GKE:

Implantação do Kubernetes para criar instâncias (chamadas de "pods" no Kubernetes).
Serviços do Kubernetes, para expor a implantação em um endpoint específico.
Escalonador automático horizontal de pods do Kubernetes: para escalonar automaticamente a implantação

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

Substitua namespace pelo namespace do cluster do GKE em que a implantação será feita, por exemplo, default.
serviceAccountName deve referenciar uma conta de serviço do Kubernetes, que pode opcionalmente atuar como uma conta de serviço do IAM com a Identidade da carga de trabalho.
Adicione um LABEL em metadata.labels e spec.template.metadata.labels que serão usados para selecionar a implantação e os pods. Exemplo:app: NAME
Sob spec.template
- Adicione um atributo replicas para especificar várias "instâncias".
- Adicione um atributo selector.matchLabels que selecione o rótulo LABEL.
Se o serviço do Cloud Run montar secrets, consulte Migrar secrets.
Se o serviço do Cloud Run migrado estiver acessando recursos em uma nuvem privada virtual, não será necessário usar um conector de acesso VPC sem servidor.

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

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

Substitua:

NAME pelo nome do serviço;
LABEL: pelo rótulo definido na implantação. Por exemplo, app: NAME.
PORT: com o containerPort do contêiner que recebe as solicitações no serviço do Cloud Run, que tem como padrão 8080.

Como opção, é possível criar um escalonador automático horizontal de pods do Kubernetes para escalonar automaticamente o número de pods. Siga a documentação do Escalonamento automático horizontal de pods do Kubernetes para criar um HorizontalPodAutoscaler. Use os valores de instâncias mínimas (autoscaling.knative.dev/minScale) e de instâncias máximas (autoscaling.knative.dev/maxScale) do seu Cloud Run. serviço como valores para os atributos minReplicas e maxReplicas HorizontalPodAutoscaler.

Migrar jobs do Cloud Run

É possível migrar um job do Cloud Run para um job do Kubernetes no GKE.

Ao contrário dos jobs do Cloud Run, os jobs do Kubernetes são executados na criação. Se você quiser executar o job novamente, será preciso criar um novo.

Os exemplos a seguir mostram a diferença estrutural entre um job do Cloud Run e do Kubernetes:

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

Job do Cloud Run

Job 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

Migrar secrets

É possível manter os secrets atuais no Secret Manager ou migrá-los para os secrets do Kubernetes.

Se você optar por manter os secrets no Secret Manager, será necessário atualizar a forma como eles são usados no GKE

Se você decidir migrar do Secret Manager para os secrets do Kubernetes, considere estas diferenças entre os secrets do Secret Manager e os do Kubernetes:

Caracteres permitidos nos nomes:
- Secrets do Kubernetes: [a-z0-9-.]{1,253}
- Secrets do Secret Manager: [a-zA-Z0-9_-]{1,255}
Controle de versões: os secrets do Secret Manager são controlados, mas os do Kubernetes não.
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 endpoints externos por trás de um balanceador de carga de aplicativo externo global permite que você migre gradualmente o tráfego entre o Cloud Run e o Google Kubernetes Engine (GKE).