Migrar um serviço de fornecimento do Knative para o Cloud Run

Use este guia para migrar as suas cargas de trabalho para o Cloud Run. Em geral, a migração das suas cargas de trabalho requer a transferência de quaisquer funcionalidades baseadas no Kubernetes e, em seguida, a reimplementação de cada um dos seus serviços existentes no Cloud Run.

Principais vantagens da migração para o Cloud Run:

  • Produto sem servidor totalmente gerido que implementa a especificação da API Knative Serving e cumpre o contrato de contentor.

  • A API Admin v1 do Cloud Run foi concebida para maximizar a portabilidade com o serviço Knative.

  • A experiência do utilizador é semelhante no Cloud Run e no Knative Serving:

    • O grupo de comandos gcloud run é usado em ambos os produtos.
    • Layout e comportamento da interface do utilizador semelhantes na Google Cloud consola.

Antes de começar

As seguintes funcionalidades do Google Kubernetes Engine não são suportadas no Cloud Run, incluindo:

Considerações sobre a migração

Tem de rever e compreender as seguintes diferenças entre os produtos para garantir que pode transferir todas as suas dependências e requisitos.

Secrets

No Cloud Run, pode optar por montar segredos como variáveis de ambiente ou volumes, mas os segredos com informações confidenciais devem ser armazenados no Secret Manager.

Diferenças importantes entre os segredos no Secret Manager e os segredos do Kubernetes:

Funcionalidade Secrets do Secret Manager Segredos do Kubernetes
Carateres permitidos nos nomes [a-zA-Z0-9_-]{1,255} [a-z0-9-.]{1,253}
Controlo de versões Os Secrets têm versões Sem suporte
Payload secreto Single []byte Mapa: <string, string>

Saiba como usar o Secret Manager para criar segredos com versões para as chaves secretas dos seus serviços Knative Serving.

Trabalhar em rede

Use as informações seguintes para ajudar a migrar a configuração de rede existente para o Cloud Run.

Pontos finais de serviço
Os pontos finais do Kubernetes dos seus serviços de publicação do Knative não são suportados no Cloud Run. Saiba mais sobre os endpoints únicos no Cloud Run.
Mapeamentos de domínios
A API DomainMapping do Cloud Run é compatível com o serviço Knative. No entanto, o Cloud Run oferece mapeamento de domínios num subconjunto das localizações do Cloud Run disponíveis. Uma alternativa recomendada é tirar partido do balanceador de carga HTTP(S) global para os seus domínios personalizados.
Conetividade da VPC
Os serviços do
Cloud Run residem fora da sua VPC. Para comunicar com recursos numa VPC, tem de usar o conetor do Acesso a VPC sem servidor.
Controlos de entrada
Se o seu serviço Knative Serving estiver configurado para uma rede interna privada e usar um balanceador de carga interno (ILB), pode configurar o seu serviço Cloud Run para Ingress = Internal. Configurar os seus serviços para internal restringe o acesso à sua VPC ou a outros serviços do Cloud Run. Saiba mais sobre a comunicação entre serviços.

Migrar um serviço

Para migrar um serviço, tem de exportar o seu serviço Knative Serving, editar o ficheiro YAML exportado e, em seguida, implementar o serviço reconfigurado no Cloud Run.

  1. Exporte o seu serviço Knative serving para um ficheiro YAML local executando o seguinte comando:

    gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
    

    Substituição:

    • SERVICE com o nome do seu serviço de fornecimento do Knative.
    • NAMESPACE com o espaço de nomes onde o seu serviço está a ser executado.
    • CLUSTER com o nome do cluster onde o seu serviço está a ser executado.
    • FILENAME com um nome de ficheiro único à sua escolha.
  2. Modifique o ficheiro FILENAME.yaml exportado para o Cloud Run:

    • Tem de pesquisar e substituir o espaço de nomes do Kubernetes pelo ID do seu Google Cloud projeto. Por exemplo, tem de substituir namespace:default por namespace:my-unique-id.
    • Tem de atualizar todas as configurações para qualquer uma das funcionalidades não suportadas.
    • Tem de eliminar qualquer um dos seguintes atributos e os respetivos valores:

      • metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
      • metadata.managedFields
      • spec.template.spec.containers.readinessProbes
      • spec.template.spec.enableServiceLinks

      Por exemplo, pode ter de remover a seguinte configuração dos atributos spec: > template: > spec: > containers::

      ...
       readinessProbe:
         successThreshold: 1
         tcpSocket: {}
      ...
      
  3. Implemente o ficheiro .yaml modificado no Cloud Run através da flag --platform managed. Saiba mais sobre a implementação.

    Tenha em atenção que pode usar o mesmo Google Cloud projeto para o Cloud Run.

    gcloud run services replace FILENAME.yaml --platform managed --region REGION
    

    Substituição:

  4. Configure o acesso ao seu serviço do Cloud Run:

  5. Na Google Cloud consola, na página de serviços, pode clicar no link do URL apresentado para abrir o ponto final único e estável do serviço implementado.

    Aceda ao Cloud Run

Migrar tráfego para o seu serviço

Depois de testar os serviços implementados recentemente e quando tiver tudo preparado para migrar todo o tráfego de produção, pode configurar o domínio personalizado e atualizar os registos DNS com a sua entidade de registo. Siga as instruções em Mapear domínios personalizados.