O Knative tem como objetivo disponibilizar implementações reutilizáveis de padrões e melhores práticas de codificação, com os seguintes componentes:
O componente de build do Knative é uma extensão do Kubernetes e utiliza primitivas existentes para permitir a execução de builds de container no cluster, a partir do código fonte (baseado no Kaniko, lançado anteriormente). O objetivo é utilizar os recursos nativos do Kubernetes para obter código fonte de um repositório, fazer o build dentro de uma imagem de container, e então rodar esta imagem. Porém, a documentação diz que o usuário final do framework ainda é responsável por desenvolver os componentes correspondentes que executam a maioria destas funções.
Até o momento, um build de Knative não possui uma solução CI/CD completa, mas por outro lado possui um building block de baixo nível que foi desenhado para permitir integração e utilização em sistemas maiores.
O sistema de eventos foi desenhado para resolver uma série de necessidades comuns do desenvolvimento de software cloud native: os serviços são fracamente pareados durante o desenvolvimento e seus deploys são feitos de forma independente; um produtor pode gerar eventos antes que haja um consumidor ouvindo, e um consumidor pode expressar interesse em um evento ou classe de eventos que ainda não está sendo produzida; e serviços podem ser conectados para criar novas aplicações sem modificar o produtor ou o consumidor, com a habilidade de selecionar um subconjunto específico de eventos de um produtor específico.
A documentação mostra que estes objetivos de design são consistentes com os objetivos de design do CloudEvents, uma especificação comum para interoperabilidade cross-service que está sendo desenvolvida pelo CNCF Serverless WG. A documentação dentro do repositório de Eventing deixa claro que ainda é um trabalho em andamento, e que existe uma lista de problemas conhecidos.
A documentação do Knative Serving mostra que esta parte do framework foi feita sobre o Kubernetes e Istio para suportar deploy e disponibilização de aplicações e funções serverless. O objetivo é prover primitivas middleware que permitem: o deploy rápido de containers serverless; scaling automático "up and down to zero"; roteamento e programação de redes para componentes Istio; e snapshots point-in-time de código e configurações que foram utilizadas durante o deploy.
Joe Beda, Pai do Kubernetes, Fundador e CTO na Heptio, escreveu no twitter os potenciais beneficios do componente de serving:
Uma das partes mais interessantes do KNative é o "scale to zero". Isto é feito roteando as requisições para um "atuador" que guarda requests, escala o backend e então prossegue.Eu estava esperando que alguém construísse isto.
O Knative fornece dimensionamento automático para os pods K8s gerenciados pelo Knative Services (CRD).
O Knative implementa uma solução de dimensionamento automático chamada Knative Pod Autoscaler (KPA) que você pode usar com seus aplicativos, fornecendo os recursos abaixo:
Scale-To-Zero:
O Knative usa o Knative Pod Autoscaler (KPA) por padrão. Com o KPA, você pode dimensionar seu aplicativo para zero pods, se o aplicativo não estiver recebendo nenhum tráfego.
Concurrency:
Você pode usar a configuração de concorrência para determinar quantas conexões simultâneas seus pods podem processar a qualquer momento. Se o número de solicitações exceder o limite para cada pod, o Knative aumentará o número de pods.
Requests Per Second (RPS):
Também é possível usar o Knative para definir quantas solicitações por segundo cada pod pode manipular. Se o número de solicitações por segundo exceder o limite, o Knative aumentará o número de pods.