Visão geral da arquitetura do Cloud Run for Anthos (veiculação do Knative)

Nesta página, você encontra uma visão geral da arquitetura do Cloud Run for Anthos (serviço Knative) e aborda as alterações que ocorrem quando você ativa o Cloud Run for Anthos no cluster do Google Kubernetes Engine.

Essas informações são úteis para os seguintes tipos de usuários:

  • Usuários que estão começando a usar o Cloud Run for Anthos.
  • Operadores com experiência na execução de clusters do GKE.
  • Desenvolvedores de aplicativos que precisam saber mais sobre como o Cloud Run para Anthos se integra aos clusters do Kubernetes para projetar aplicativos melhores ou configurar o aplicativo do Cloud Run para Anthos.

Componentes na instalação padrão

O Cloud Run for Anthos instala o Knative Serving no cluster para conectar e gerenciar as cargas de trabalho sem estado. Os componentes do Knative são criados no namespace knative-serving.

O Cloud Run for Anthos usa o Anthos Service Mesh para rotear o tráfego. Por padrão, o Anthos Service Mesh instala componentes no namespace istio-system.

Confira uma lista dos componentes instalados pelo Cloud Run for Anthos e Anthos Service Mesh:

  • Componentes instalados pelo Cloud Run for Anthos no namespace knative-serving:

    • Ativador: quando os pods têm o escalonamento horizontal reduzido para zero ou ficam sobrecarregados com solicitações enviadas à revisão, o ativador enfileira temporariamente as solicitações e envia métricas ao escalonador automático para ativar mais pods. Depois que o escalonador automático escalona a revisão com base nas métricas informadas e nos pods disponíveis, o ativador encaminha solicitações enfileiradas para a revisão. O Ativador é um componente de plano de dados. Os componentes do plano de dados gerenciam todas as funções e processos que encaminham o tráfego do usuário.
    • Escalonador automático: agrega e processa métricas do Ativador e do contêiner de arquivo secundário do proxy da fila, um componente no plano de dados que impõe limites de simultaneidade de solicitação. Em seguida, o escalonador automático calcula a simultaneidade observada para a revisão e ajusta o tamanho da implantação com base na contagem de pods desejada. Quando os pods estão disponíveis na revisão, o escalonador automático é um componente do plano de controle. Caso contrário, quando o escalonamento horizontal dos pods for reduzido para zero, o escalonador automático será um componente do plano de dados.
    • Controlador: cria e atualiza os recursos filhos do escalonador automático e dos objetos de serviço. O controlador é um componente do plano de controle. Os componentes do plano de controle gerenciam todas as funções e processos que estabelecem o caminho da solicitação do tráfego do usuário.
    • Coletor de métricas: coleta métricas dos componentes do Cloud Run for Anthos e as encaminha para o Cloud Monitoring.
    • Webhook: define valores padrão, rejeita objetos inconsistentes e inválidos, valida e modifica as chamadas da API Kubernetes nos recursos do Cloud Run for Anthos. O webhook é um componente do plano de controle.
  • Componentes instalados pelo Anthos Service Mesh em execução no namespace istio-system:

    • Gateway local do cluster: balanceador de carga no plano de dados responsável por lidar com o tráfego interno que chega de um Cloud Run para Anthos a outro. O gateway local do cluster só pode ser acessado no cluster do GKE e não registra um domínio externo para evitar a exposição acidental de informações particulares ou processos internos.
    • Gateway de entrada do Istio: balanceador de carga no plano de dados que é responsável por receber e lidar com o tráfego de entrada de fora do cluster, incluindo tráfego de redes externas ou internas.
    • Istiod: configura o gateway local do cluster e o gateway de entrada do Istio para processar solicitações HTTP nos endpoints corretos. O Istiod é um componente do plano de controle. Para mais informações, consulte Istiod.

Os componentes do Cloud Run for Anthos são atualizados automaticamente com todas as atualizações de cluster do plano de controle do GKE. Para mais informações, consulte Versões disponíveis do GKE.

Uso de recursos do cluster

A instalação inicial do Cloud Run for Anthos requer aproximadamente 1,5 de CPU virtual e 1 GB de memória para o cluster. O número de nós no cluster não afeta os requisitos de espaço e memória de uma instalação do Cloud Run for Anthos.

Um ativador pode consumir solicitações com no máximo 1.000 miliCPU e 600 MiB de RAM. Quando um Ativador existente não é compatível com o número de solicitações recebidas, um Ativador adicional é ativado e requer uma reserva de 300 miliCPU e 60 MiB de RAM.

Cada pod criado pelo serviço Cloud Run para Anthos cria um arquivo secundário de proxy de fila que aplica limites de simultaneidade de solicitação. O proxy de fila reserva 25 miliCPU e não tem reserva de memória. O consumo do proxy da fila depende de quantas solicitações estiverem sendo enfileiradas e do tamanho das solicitações. Não há limites para o consumo dos recursos de CPU e memória.

Crie um serviço

Diagrama mostrando a arquitetura de serviço do Cloud Run for Anthos
Arquitetura do serviço do Cloud Run for Anthos (clique para ampliar)

O Cloud Run for Anthos estende o Kubernetes definindo um conjunto de definições de recursos personalizados (CRDs, na sigla em inglês): (em inglês) serviço, revisão, configuração e rota. Estes CRDs definem e controlam como os aplicativos se comportam no cluster:

  • O serviço do Cloud Run para Anthos é o recurso personalizado de nível superior definido pelo Cloud Run para Anthos. É um único aplicativo que gerencia todo o ciclo de vida da carga de trabalho. O serviço garante que o app tenha uma rota, uma configuração e uma nova revisão para cada atualização do serviço.
  • Revisão é um snapshot pontual e imutável do código e da configuração.
  • A Configuração mantém as definições atuais da sua revisão mais recente e registra um histórico de todas as revisões anteriores. Modificar uma configuração cria uma nova revisão.
  • Rota define um endpoint HTTP e associa o endpoint a uma ou mais revisões para as quais as solicitações são encaminhadas.

Quando um usuário cria um serviço do Cloud Run para Anthos, acontece o seguinte:

  1. O objeto do serviço do Cloud Run para Anthos define:

    1. Uma configuração de como exibir suas revisões.
    2. Uma revisão imutável para esta versão do serviço.
    3. Uma rota para gerenciar a alocação de tráfego especificada para a revisão.
  2. O objeto de rota cria o VirtualService. O objeto VirtualService configura o gateway de entrada e o gateway local do cluster para rotear o tráfego do gateway para a revisão correta.

  3. O objeto de revisão cria os seguintes componentes do plano de controle: um objeto de serviço do Kubernetes e um objeto de implantação.

  4. A configuração de rede conecta o Ativador, o escalonador automático e os balanceadores de carga do app.

Processamento de solicitações

O diagrama a seguir mostra uma visão geral de alto nível de um possível caminho de solicitação do tráfego de usuário ao longo Cloud Run for Anthos nos componentes do plano de dados em um cluster de amostra do Google Kubernetes Engine:

Diagrama mostrando a arquitetura de cluster do Cloud Run for Anthos
Arquitetura do cluster do Cloud Run for Anthos (clique para ampliar)

O próximo diagrama é expandido do diagrama acima para fornecer uma visão detalhada do caminho da solicitação do tráfego do usuário, também descrito em detalhes abaixo:

Diagrama mostrando o caminho da solicitação do Cloud Run for Anthos
Caminho da solicitação do Cloud Run para Anthos (clique para ampliar)

Para um caminho de solicitação do Cloud Run for Anthos:

  1. O tráfego chega por meio do:

    • Gateway de entrada para o tráfego de fora dos clusters
    • Gateway local do cluster para tráfego dentro dos clusters
  2. O componente VirtualService, que especifica regras de roteamento de tráfego, configura os gateways para que o tráfego do usuário seja roteado para a revisão correta.

  3. O serviço do Kubernetes, um componente do plano de controle, determina a próxima etapa no caminho da solicitação, dependendo da disponibilidade de pods para lidar com o tráfego:

    • Se não houver pods na revisão:

      1. O Ativador enfileira temporariamente a solicitação recebida e envia uma métrica para o escalonador automático para escalonar mais pods.
      2. O escalonador automático é escalonado para o estado desejado dos pods na implantação.
      3. A implantação cria mais pods para receber solicitações adicionais.
      4. O ativador tenta novamente as solicitações para o arquivo secundário do proxy da fila.
    • Se o serviço for escalonado verticalmente (os pods estão disponíveis), o serviço do Kubernetes enviará a solicitação para o arquivo secundário do proxy da fila.

  4. O arquivo secundário do proxy da fila aplica parâmetros de fila de solicitação, solicitações únicas ou com várias linhas de execução, que o contêiner pode processar por vez.

  5. Se o arquivo secundário do proxy da fila tiver mais solicitações, o escalonador automático criará mais pods para processar solicitações adicionais.

  6. O arquivo secundário do proxy da fila envia tráfego para o contêiner do usuário.