Migrar do Kubernetes para o Cloud Run

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 você não precisa estar usando o Knative no cluster atual do Kubernetes para migrar algumas das suas cargas de trabalho do Kubernetes para o Cloud Run.

O recurso principal do Cloud Run é o serviço. Pense no serviço do Cloud Run como um serviço que se parece com uma implantação do Kubernetes com um escalonador automático de pods integrado e um endpoint exclusivo. Um "pod" no Kubernetes corresponde a uma "instância" no Cloud Run. Recomendamos transformar as implantações do Kubernetes em serviços do Cloud Run, um serviço por vez. Você também poderá mesclar algumas configurações do seu escalonador automático horizontal de pods e dos serviços do Kubernetes ao serviço do Cloud Run.

O Cloud Run não tem o conceito de namespace. Em vez disso, o projeto do Google Cloud é usado como um limite de isolamento entre os recursos. Ao migrar para o Cloud Run do Kubernetes, recomendamos criar um projeto do Google Cloud para cada namespace. No YAML de um serviço do Cloud Run, o valor do namespace é o número do projeto do Google Cloud.

O Cloud Run tem redundância zonal integrada, Isso significa que você não precisa provisionar réplica para garantir que seu serviço seja resiliente a uma interrupção de serviço zonal na região selecionada do Google Cloud.

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 a seguinte implantação simples do Kubernetes chamada my-app com o serviço equivalente do Cloud Run. Observe como os arquivos YAML são quase idênticos.

As partes em blue são diferentes e precisam ser alteradas. As partes em red devem ser excluídas porque o Cloud Run tem um escalonador automático integrado.

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

Implantação do Kubernetes

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

Migrar uma implantação simples do Kubernetes para o Cloud Run

Faça o download do arquivo YAML da implantação no diretório atual com:
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
Modificar o YAML para corresponder a um serviço do Cloud Run. Atualize o arquivo my-app.yaml:
- Para o atributo "kind": substitua o valor "Deployment" por "Service".
- Para o atributo "apiVersion": substitua o valor "apps/v1" por "serving.knative.dev/v1"
- Exclua o atributo metadata.namespace ou mude o valor dele para corresponder o número do projeto do Google Cloud.
- Excluir spec.replicas e spec.selector
Implante o arquivo my-app.yaml no Cloud Run usando o seguinte: substituindo REGION pela região desejada do Google Cloud. Por exemplo, us-central1:
```
gcloud run services replace my-app.yaml --region REGION
```

A invocação de um serviço do Cloud Run é protegida por uma permissão do IAM. Se você quiser expor o novo serviço do Cloud Run publicamente para na Internet e permitir invocações não autenticadas, execute o seguinte comando:

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

Recursos não compatíveis com o Cloud Run

Apenas cargas de trabalho adequadas para o Cloud Run podem ser migradas.

Os seguintes recursos do Kubernetes não são suportados pelo Cloud Run:

Números fixos de replicas: uma solução alternativa é usar o mesmo número de instâncias mínimas e máximas.
Config Maps (solução alternativa disponível)
Estratégias personalizadas do escalonador automático horizontal de pods
Service Discovery

Ao migrar um arquivo YAML de uma implantação do Kubernetes para um serviço do Cloud Run, o comando gcloud run services replace retornará uma mensagem de erro clara para qualquer atributo não compatível com o Cloud Run. Exclua ou atualize esses atributos e repita o comando até conseguir.

Consulte a Referência YAML para uma lista completa de atributos compatíveis com o Cloud Run.

Migrar recursos do Kubernetes

Migrar secrets do Kubernetes

Assim como o Kubernetes, o Cloud Run oferece suporte à montagem de secrets como variáveis ou volumes de ambiente, mas eles precisam ser armazenados no Secret Manager.

Tem várias diferenças importantes entre os secrets do Secret Manager e os secrets 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>.

Siga a documentação do Secret Manager para criar um secret e adicionar uma nova versão do secret para cada chave secreta de que seu app Kubernetes depende.

Migrar ConfigMaps do Kubernetes

O Cloud Run não tem um equivalente de ConfigMaps do Kubernetes, mas como os ConfigMaps podem ser vistos como Secrets não criptografados, é possível transformar seus ConfigMaps em secrets no Secret Manager. Consulte as instruções em Migrar secrets do Kubernetes.

Migrar uma implantação do Kubernetes

A implantação do Kubernetes é o recurso que mapeia o serviço mais próximo ao do Cloud Run. Recomendamos começar pelo YAML da sua implantação do Kubernetes e editá-lo para transformá-lo em um serviço do Cloud Run.

As principais mudanças necessárias são:

O namespace precisa ser substituído pelo número do projeto do Google Cloud.
Os identificadores (metadata.labels e spec.template.metadata.labels) precisam ser identificadores válidos do Google Cloud.
Os contêineres precisam ser armazenados em um registro de contêineres compatível.
Os limites de CPU e memória precisam ser ajustados.
Ao referenciar um secret, o atributo "key" é usado para capturar a versão no Secret Manager, com "latest" fazendo referência à versão mais recente do secret.
serviceAccountName precisa se referir a uma conta de serviço no projeto atual do Google Cloud
As referências a ConfigMaps (configMapKeyRef) precisam ser substituídas por referências a secrets (secretKeyRef)

Se a implantação do Kubernetes estiver acessando outros recursos no cluster ou recursos em uma VPC, conecte o serviço do Cloud Run à VPC apropriada.

Migrar um serviço do Kubernetes

Os serviços do Cloud Run expõem automaticamente um endpoint exclusivo que encaminha o tráfego para o contêiner com um containerPort. Depois de migrar a implantação do Kubernetes para um serviço do Cloud Run, não é necessário migrar os serviços do Kubernetes que estavam roteando o tráfego para essa implantação.

Migrar um HorizontalPodAutoscaler do Kubernetes

Os serviços do Cloud Run têm um escalonador automático horizontal integrado: o Cloud Run escalona automaticamente os pods (chamados de "instâncias") usando uma combinação de fatores dentro dos limites do mínimo definido e o número máximo de instâncias.

Migre os atributos minReplicas e maxReplicas do HorizontalPodAutoscaler para as anotações autoscaling.knative.dev/minScale e autoscaling.knative.dev/maxScale do serviço do Cloud Run. Consulte a documentação sobre como configurar instâncias mínimas e máximas.

Migrar um job do Kubernetes

Devido à semelhança entre um job do Kubernetes e uma execução de job do Cloud Run, é possível migrar para um job do Cloud Run e executar o job.

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

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

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

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