Essas informações são úteis para os seguintes tipos de usuários:
- Usuários que estão começando a usar o Knative serving.
- Operadores com experiência na execução de clusters do GKE.
- Desenvolvedores de aplicativos que precisam saber mais sobre como O Knative serving se integra aos clusters do Kubernetes para projetar aplicativos melhores ou configurar o Knative serving para o aplicativo.
Componentes na instalação padrão
Instale o Knative Serving no
seu cluster para conectar e gerenciar as cargas de trabalho sem estado. Knative
componentes são criados no namespace knative-serving.
O Knative serving usa o Cloud Service Mesh para rotear o tráfego. Por padrão,
O Cloud Service Mesh instala componentes no namespace istio-system.
Confira uma lista dos componentes instalados pelo Knative serving e pelo Cloud Service Mesh:
Componentes instalados pelo serviço Knative no namespace
knative-serving:- Activator: 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 de veiculação do Knative e as encaminha para o Cloud Monitoring.
- Webhook: define valores padrão e rejeita inconsistentes e inválidos. objetos e valida e mutates Chamadas da API Kubernetes em recursos do Knative serving. O webhook é um componente do plano de controle.
Componentes instalados pelo Cloud 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 o serviço do Knative serving para 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 Knative serving são atualizados automaticamente com 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 serviço do Knative 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 de exibição do Knative.
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 Knative serving cria um o arquivo secundário do proxy da 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.
Como criar um serviço
O serviço Knative estende o Kubernetes definindo um conjunto de definições de recursos personalizados (CRDs): serviço, revisão, configuração e rota. Estes CRDs definem e controlam como os aplicativos se comportam no cluster:
- O serviço do Knative serving é o recurso personalizado de nível superior definido pelo Knative serving. É 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 de exibição do Knative, o seguinte acontece:
O objeto de serviço do Knative serving 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 um possível caminho de solicitação para tráfego do usuário pelos componentes do plano de dados do Knative serving em uma exemplo de cluster 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 Knative serving:
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.