Estas informações são úteis para os seguintes tipos de utilizadores:
- Utilizadores que estão a começar a usar o Knative Serving.
- Operadores com experiência na execução de clusters do GKE.
- Os programadores de aplicações que precisam de saber mais sobre como o Knative serving se integra com clusters do Kubernetes para criar melhores aplicações ou configurar a respetiva aplicação do Knative serving.
Componentes na instalação predefinida
Instale o Knative serving no seu cluster para ligar e gerir as suas cargas de trabalho sem estado. Os componentes do Knative são criados no espaço de nomes knative-serving.
O Knative serving usa o Cloud Service Mesh para encaminhar o tráfego. Por predefinição, o Cloud Service Mesh instala componentes no espaço de nomes istio-system.
Segue-se uma lista dos componentes instalados pelo Knative serving e pelo Cloud Service Mesh:
Componentes instalados pelo Knative serving no espaço de nomes
knative-serving:- Ativador: quando os pods são reduzidos para zero ou ficam sobrecarregados com pedidos enviados para a revisão, o ativador coloca temporariamente os pedidos em fila e envia métricas para o escalador automático para ativar mais pods. Assim que o redimensionador automático dimensiona a revisão com base nas métricas comunicadas e nos pods disponíveis, o ativador encaminha os pedidos em fila para a revisão. O ativador é um componente do plano de dados. Os componentes do plano de dados gerem todas as funções e processam o encaminhamento do tráfego do utilizador.
- Autoscaler: agrega e processa métricas do ativador e do contentor secundário do proxy de filas, um componente no plano de dados que aplica limites de concorrência de pedidos. Em seguida, o dimensionador automático calcula a concorrência observada para a revisão e ajusta o tamanho da implementação com base na quantidade de contentores desejada. Quando os pods estão disponíveis na revisão, o redimensionador automático é um componente do plano de controlo; caso contrário, quando os pods são reduzidos a zero, o redimensionador automático é um componente do plano de dados.
- Controlador: cria e atualiza os recursos subordinados do redimensionador automático e os objetos de serviço. O controlador é um componente do plano de controlo; os componentes do plano de controlo gerem todas as funções e processos que estabelecem o caminho do pedido do tráfego do utilizador.
- Coletor de métricas: recolhe métricas dos componentes de publicação do Knative e, em seguida, encaminha-as para o Cloud Monitoring.
- Webhook: define valores predefinidos, rejeita objetos inconsistentes e inválidos, e valida e altera as chamadas da API Kubernetes em relação aos recursos de publicação do Knative. O webhook é um componente do plano de controlo.
Componentes instalados pelo Cloud Service Mesh em execução no espaço de nomes
istio-system:- Cluster Local Gateway: equilibrador de carga no plano de dados responsável por processar o tráfego interno que chega de um serviço de fornecimento do Knative para outro. Só é possível aceder ao Cluster Local Gateway a partir do seu cluster do GKE e não regista um domínio externo para evitar a exposição acidental de informações privadas ou processos internos.
- Istio Ingress Gateway: equilibrador de carga no plano de dados responsável por receber e processar o tráfego recebido de fora do cluster, incluindo o tráfego de redes externas ou internas.
- Istiod: configura o Cluster Local Gateway e o Istio Ingress Gateway para processar pedidos HTTP nos pontos finais corretos. O Istiod é um componente do plano de controlo. Para mais informações, consulte o artigo Istiod.
Os componentes de serviço do Knative são atualizados automaticamente com quaisquer atualizações do cluster do plano de controlo do GKE. Para mais informações, consulte o artigo Versões do GKE disponíveis.
Utilização de recursos do cluster
A instalação inicial do Knative serving requer aproximadamente 1,5 CPUs virtuais e 1 GB de memória para o seu cluster. O número de nós no seu cluster não afeta os requisitos de espaço e memória para uma instalação do Knative Serving.
Um ativador pode consumir pedidos a um máximo de 1000 milliCPU e 600 MiB de RAM. Quando um ativador existente não consegue suportar o número de pedidos recebidos, é iniciado um ativador adicional, o que requer uma reserva de 300 miliCPU e 60 MiB de RAM.
Cada agrupamento criado pelo serviço Knative serving cria um sidecar do proxy de fila que aplica limites de simultaneidade de pedidos. O proxy de fila reserva 25 miliCPU e não tem reserva de memória. O consumo do proxy de filas depende do número de pedidos que estão a ser colocados em fila e do tamanho dos pedidos. Não existem limites para os recursos de CPU e memória que pode consumir.
Criar um serviço
O Knative Serving expande o Kubernetes definindo um conjunto de definições de recursos personalizados (CRDs): Service, Revision, Configuration e Route. Estes CRDs definem e controlam o comportamento das suas aplicações no cluster:
- O serviço Knative serving é o recurso personalizado de nível superior definido pelo Knative serving. É uma única aplicação que gere todo o ciclo de vida da sua carga de trabalho. O seu serviço garante que a app tem um trajeto, uma configuração e uma nova revisão para cada atualização do serviço.
- Uma revisão é um resumo imutável do código e da configuração num determinado momento.
- A configuração mantém as definições atuais da sua revisão mais recente e regista um histórico de todas as revisões anteriores. A modificação de uma configuração cria uma nova revisão.
- Route define um ponto final HTTP e associa o ponto final a uma ou mais revisões para as quais os pedidos são encaminhados.
Quando um utilizador cria um serviço de publicação do Knative, ocorrem os seguintes eventos:
O objeto de serviço de publicação do Knative define:
- Uma configuração sobre como publicar as suas revisões.
- Uma revisão imutável desta versão do seu serviço.
- Um caminho para gerir a atribuição de tráfego especificada à sua revisão.
O objeto de rota cria o VirtualService. O objeto VirtualService configura o gateway de entrada e o gateway local do cluster para encaminhar o tráfego do gateway para a revisão correta.
O objeto de revisão cria os seguintes componentes do plano de controlo: um objeto de serviço do Kubernetes e um objeto de implementação.
A configuração de rede liga o ativador, o dimensionamento automático e os equilibradores de carga para a sua app.
Processamento de pedidos
O diagrama seguinte mostra uma vista geral de nível elevado de um possível caminho de pedido para tráfego de utilizadores através dos componentes do plano de dados do Knative Serving num cluster de exemplo do Google Kubernetes Engine:
O diagrama seguinte expande o diagrama acima para dar uma vista detalhada do caminho do pedido do tráfego do utilizador, também descrito detalhadamente abaixo:
Para um caminho de pedido de publicação do Knative:
O tráfego chega através de:
- O gateway de entrada para tráfego de fora dos clusters
- O gateway local do cluster para tráfego dentro dos clusters
O componente VirtualService, que especifica as regras de encaminhamento de tráfego, configura os gateways para que o tráfego do utilizador seja encaminhado para a revisão correta.
O serviço Kubernetes, um componente do painel de controlo, determina o passo seguinte no caminho do pedido, dependendo da disponibilidade de pods para processar o tráfego:
Se não existirem pods na revisão:
- O ativador coloca temporariamente o pedido recebido em fila e envia uma métrica para o escalador automático para dimensionar mais pods.
- O redimensionador automático é dimensionado para o estado pretendido dos pods na implementação.
- A implementação cria mais pods para receber pedidos adicionais.
- O ativador tenta novamente os pedidos para o sidecar do proxy de filas.
Se o serviço for expandido (os pods estiverem disponíveis), o serviço do Kubernetes envia o pedido para o sidecar do proxy da fila.
O sidecar do proxy de fila aplica parâmetros de fila de pedidos, pedidos de thread única ou múltiplos, que o contentor pode processar de cada vez.
Se o sidecar do proxy de filas tiver mais pedidos do que consegue processar, o Autoscaler cria mais pods para processar pedidos adicionais.
O sidecar do proxy de fila envia tráfego para o contentor do utilizador.