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
Quando você instala o Cloud Run para Anthos como um complemento do cluster do Google Kubernetes Engine, os namespaces knative-serving e gke-system são criados automaticamente. Os seguintes componentes são implantados em um desses namespaces:
Componentes em execução 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.
- 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 em execução no namespace
gke-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: um balanceador de carga no plano de dados que é responsável por receber e processar o tráfego de entrada vindo de fora do cluster, incluindo tráfego de redes externas ou internas.
- Istio Pilot: configura o gateway local do cluster e o gateway de entrada do Istio para processar solicitações HTTP nos endpoints corretos. O Istio Pilot é um componente do plano de controle. Para mais informações, consulte Istio Pilot.
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
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:
O objeto do serviço do Cloud Run para Anthos define:
- Uma configuração de como exibir suas revisões.
- Uma revisão imutável para esta versão do serviço.
- Uma rota para gerenciar a alocação de tráfego especificada para a revisão.
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.
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.
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:
O próximo diagrama se expande a partir 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:
Para um caminho de solicitação do Cloud Run for Anthos:
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
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.
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:
- O Ativador enfileira temporariamente a solicitação recebida e envia uma métrica para o escalonador automático para escalonar mais pods.
- O escalonador automático é escalonado para o estado desejado dos pods na implantação.
- A implantação cria mais pods para receber solicitações adicionais.
- 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.
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.
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.
O arquivo secundário do proxy da fila envia tráfego para o contêiner do usuário.