Esta página foi traduzida pela API Cloud Translation.

Migre do Kubernetes para o Cloud Run

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 usar o Knative no seu cluster Kubernetes existente para migrar algumas das suas cargas de trabalho do Kubernetes para o Cloud Run.

O recurso principal do Cloud Run é o serviço. Pode pensar num serviço do Cloud Run como uma abstração de alto nível que se assemelha a uma implementação do Kubernetes com um escalador automático de pods incorporado e um ponto final único. Um "Pod" no Kubernetes corresponde a uma "instância" no Cloud Run. Recomendamos que transforme as suas implementações do Kubernetes em serviços do Cloud Run, um serviço de cada vez. Também pode unir alguma configuração do Horizontal Pod Autoscaler do Kubernetes e dos serviços do Kubernetes no serviço do Cloud Run.

O Cloud Run não tem o conceito de espaço de nomes. Em alternativa, o Google Cloud projeto é usado como um limite de isolamento entre recursos. Quando migrar do Kubernetes para o Cloud Run, recomendamos que crie um Google Cloud projeto para cada espaço de nomes. No YAML de um serviço do Cloud Run, o valor do espaço de nomes é o Google Cloud número do projeto.

O Cloud Run tem uma redundância zonal incorporada. Isto significa que não tem de aprovisionar réplicas para garantir que o seu serviço é resiliente a uma indisponibilidade zonal na Google Cloud região selecionada.

Início rápido

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

Comparação simples de recursos

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

As partes em blue são diferentes e têm de ser alteradas. As partes em red devem ser eliminadas porque o Cloud Run tem um redimensionador automático incorporado.

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

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

Migre uma implementação simples do Kubernetes para o Cloud Run

Transfira o ficheiro YAML da sua implementação no diretório atual com:
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
Modifique o YAML para corresponder a um serviço do Cloud Run. Atualize o ficheiro 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"
- Elimine o atributo metadata.namespace ou altere o respetivo valor para corresponder ao número do projeto. Google Cloud
- Elimine spec.replicas e spec.selector
Implemente o ficheiro my-app.yaml no Cloud Run através do seguinte comando, substituindo REGION pela região Google Cloud desejada, por exemplo, europe-west1:
```
gcloud run services replace my-app.yaml --region REGION
```

A invocação de um serviço do Cloud Run está protegida por uma autorização do IAM. Se quiser expor publicamente o novo serviço do Cloud Run à Internet e permitir o acesso público, execute o seguinte comando:

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

Funcionalidades não suportadas pelo Cloud Run

Só é possível migrar cargas de trabalho que sejam adequadas para o Cloud Run.

Em particular, as seguintes funcionalidades do Kubernetes não são suportadas 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)
Mapas de configuração (solução alternativa disponível)
Estratégias de redimensionador automático horizontal de pods personalizadas
Deteção de serviços
Disco local (efémero e persistente)

Quando migra um ficheiro YAML de uma implementação do Kubernetes para um serviço do Cloud Run, o comando gcloud run services replace devolve uma mensagem de erro clara para qualquer atributo que não seja suportado pelo Cloud Run. Elimine ou atualize estes atributos e, em seguida, repita o comando até ter êxito.

Pode consultar a referência YAML para ver uma lista exaustiva dos atributos suportados pelo Cloud Run.

Migre recursos do Kubernetes

Migre segredos do Kubernetes

Tal como o Kubernetes, o Cloud Run suporta a montagem de segredos como variáveis de ambiente ou volumes, mas os segredos devem ser armazenados no Secret Manager.

Existem várias diferenças importantes entre os segredos do Secret Manager e os segredos do Kubernetes:

Carateres permitidos nos nomes:
- Segredos do Kubernetes: [a-z0-9-.]{1,253}
- Segredos do Secret Manager: [a-zA-Z0-9_-]{1,255}
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>.

Siga a documentação do Secret Manager para criar um segredo e adicionar uma nova versão secreta para cada chave secreta da qual a sua app Kubernetes depende.

Migre ConfigMaps do Kubernetes

O Cloud Run não tem um equivalente dos ConfigMaps do Kubernetes, mas, como os ConfigMaps podem ser vistos como segredos não encriptados, pode transformar os seus ConfigMaps em segredos no Secret Manager. Consulte as instruções em Migre segredos do Kubernetes.

Migre uma implementação do Kubernetes

A implementação do Kubernetes é o recurso que se mapeia mais próximo do serviço do Cloud Run. Recomendamos que comece pelo YAML da sua implementação do Kubernetes e o edite para o transformar num serviço do Cloud Run.

As principais alterações necessárias são:

O namespace tem de ser substituído pelo número do projeto Google Cloud .
As etiquetas (metadata.labels e spec.template.metadata.labels) têm de ser etiquetas Google Cloud válidas.
Os contentores têm de ser armazenados num registo de contentores suportado.
Pode ser necessário ajustar os limites de CPU e memória.
Quando faz referência a um segredo, o atributo "key" é usado para capturar a versão no Secret Manager, com "latest" a fazer referência à versão mais recente do segredo.
serviceAccountName deve fazer referência a uma conta de serviço no projeto Google Cloud atual
As referências a ConfigMaps (configMapKeyRef) devem ser substituídas por referências a segredos (secretKeyRef)

Se a sua implementação do Kubernetes estiver a aceder a outros recursos no cluster do Kubernetes ou a recursos numa VPC, tem de associar o serviço do Cloud Run à VPC adequada

Migre um serviço do Kubernetes

Os serviços do Cloud Run expõem automaticamente um ponto final exclusivo que encaminha o tráfego para o contentor com um containerPort. Depois de migrar a implementação do Kubernetes para um serviço do Cloud Run, não precisa de migrar os serviços do Kubernetes que estavam a encaminhar tráfego para esta implementação.

Migre um HorizontalPodAutoscaler do Kubernetes

Os serviços do Cloud Run têm um escalador automático horizontal incorporado: o Cloud Run dimensiona automaticamente os pods (denominados "instâncias") através de uma combinação de fatores dentro dos limites do número mínimo e máximo de instâncias definidos.

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 a configuração de instâncias mínimas e instâncias máximas.

Migre uma tarefa do Kubernetes

Porque uma tarefa do Kubernetes é semelhante a uma execução de tarefas do Cloud Run. Pode migrar para uma tarefa do Cloud Run e executar a tarefa.

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

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

Tarefa do Kubernetes

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

Migre do Kubernetes para o Cloud Run Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.