Nesta página, listamos os principais requisitos e comportamentos de contêineres na serviço Knative.
Linguagens e imagens compatíveis
Sua imagem de contêiner pode executar o código escrito na linguagem de programação de sua escolha e usar qualquer imagem de base, desde que respeite as restrições listadas nesta página.
Os executáveis na imagem do contêiner precisam ser compilados para Linux de 64 bits. O Knative serving é compatível especificamente com o formato ABI Linux x86_64.
Como detectar solicitações na porta correta
O contêiner precisa detectar solicitações em 0.0.0.0 na porta para a qual
as solicitações são enviadas. Por padrão, as solicitações são enviadas para 8080, mas é possível
configurar o Knative serving
para enviar solicitações à porta de sua escolha.
Dentro das instâncias de contêiner do Knative serving, o valor da variável de ambiente
PORT sempre reflete a porta para a qual as solicitações são enviadas.
O padrão é 8080.
Criptografia da camada de transporte (TLS)
O contêiner não deve implementar nenhuma segurança de camada de transporte (TLS, na sigla em inglês) diretamente. O TLS é encerrado pelo Knative serving para HTTPS e gRPC e, em seguida, solicita são encaminhados como HTTP ou gRPC para o contêiner sem TLS.
Respostas
A instância de contêiner precisa enviar uma resposta dentro do tempo especificado na configuração de tempo limite da solicitação após receber uma solicitação, incluindo o tempo de inicialização da instância. Caso contrário, a solicitação é finalizada e um erro 504 é retornado.
Variáveis de ambiente
As variáveis de ambiente a seguir são adicionadas automaticamente aos contêineres em execução:
| Nome | Descrição | Exemplo |
|---|---|---|
PORT |
A porta que o servidor HTTP deve detectar. | 8080 |
K_SERVICE |
O nome do serviço de veiculação do Knative em execução. | hello-world |
K_REVISION |
O nome da revisão do Knative serving em execução. | hello-world.1 |
K_CONFIGURATION |
O nome da configuração do Knative serving que criou a revisão. | hello-world |
Acesso ao sistema de arquivos
O sistema de arquivos do seu contêiner é gravável e está sujeito ao seguinte comportamento:
- Esse é um sistema de arquivos na memória. Portanto, gravar nele usa a memória da instância do contêiner.
- Os dados gravados no sistema de arquivos não permanecem quando a instância do contêiner é interrompida.
Ciclo de vida da instância de contêiner
Em resposta a solicitações recebidas, um serviço é escalonado automaticamente para um determinado número de instâncias de contêiner, cada uma executando a imagem do contêiner implantada.
Quando uma revisão não recebe tráfego, ela é escalonada para o número mínimo de instâncias de contêiner configuradas (zero por padrão).
Inicialização
As instâncias de contêiner precisam detectar solicitações em até quatro minutos depois de serem iniciadas. Durante esse tempo de inicialização, as instâncias de contêiner são alocadas na CPU.
A computação tem um escopo delimitado a uma solicitação
Após a inicialização, a computação só poderá ser feita dentro do escopo de uma solicitação: uma instância de contêiner não terá nenhuma CPU alocada se não estiver processando uma solicitação.
Encerrar
É possível encerrar uma instância de contêiner a qualquer momento.
Quando uma instância de contêiner precisa ser encerrada, as novas solicitações recebidas são
encaminhadas para outras instâncias, e as solicitações que estão sendo processadas podem terminar no seu
devido tempo.
A instância de contêiner recebe um sinal SIGTERM
indicando o início de um período de 10 segundos
antes de ser encerrado (com um sinal SIGKILL).
Durante esse período, a instância de contêiner recebe uma CPU alocada e é faturada.
Se a instância de contêiner não capturar o sinal SIGTERM, ela será
encerrada imediatamente.
A menos que precise ficar inativa devido à configuração do número mínimo de instâncias de contêiner, uma instância de contêiner não ficará inativa por mais de 15 minutos.
Recursos da instância do contêiner
As solicitações de recursos para suas instâncias de contêiner são programadas nos nós do cluster do GKE. Cada nó compartilha a quantidade total de recursos computacionais disponíveis para o cluster do GKE.
Portanto, a quantidade de recursos de computação O serviço do Knative serving é limitado apenas pela quantidade de recursos nesse nó. Saiba mais sobre recursos de computação para solicitações.
Por exemplo, se você alocar 512MiB de memória para um contêiner que está sendo executado no único pod em um nó com 8 GiB de memória, esse contêiner poderá tentar usar mais RAM.
CPU
Por padrão, o arquivo secundário do proxy da fila reserva 25 miliCPU e não há limite para a quantidade de vCPUs que os serviços do Knative serving podem usar. O consumo de recursos do proxy da fila depende de quantas solicitações estão sendo enfileiradas e do tamanho das solicitações.
Uma vCPU é implementada como uma abstração do hardware subjacente para fornecer o tempo de CPU equivalente aproximado de um único hyper-thread de hardware em plataformas de CPU variáveis. A instância do contêiner pode ser executada em vários núcleos simultaneamente. A vCPU só é alocada durante a inicialização da instância do contêiner e o processamento da solicitação, mas ela é limitada.
Para alocar outro valor de vCPU, consulte a documentação para alocação de CPU.
Memória
Por padrão, o arquivo secundário do proxy da fila não reserva memória e não há limite para a quantidade de memória que os serviços de veiculação do Knative podem usar. Se quiser, é possível configurar limites de memória para os serviços de exibição do Knative. Para saber mais sobre como o GKE processa a memória, consulte Recursos de CPU e CPU alocáveis.
Os usos típicos da memória incluem:
- Código carregado na memória para executar o serviço
- Gravação no sistema de arquivos
- Processos extras em execução no contêiner, como um servidor nginx
- Sistemas de armazenamento em cache na memória, como o OpCache do PHP
- Uso da memória por solicitação
Simultaneidade
Por padrão, cada instância de contêiner do Knative serving é definida como várias simultaneidades, em que cada instância de contêiner pode receber mais de uma solicitação ao mesmo tempo. Para alterar isso, defina a simultaneidade.
Sandbox de instâncias de contêiner
O Knative serving não usa um sandbox de contêiner.
Servidor de metadados da instância do contêiner
As instâncias de contêiner do Knative serving expõem um servidor de metadados que pode ser usado para recuperar detalhes sobre sua instância de contêiner, como o ID do projeto, região, código da instância ou contas de serviço.
É possível acessar esses dados a partir do servidor de metadados usando simples solicitações HTTP para o
endpoint http://metadata.google.internal/ com o cabeçalho Metadata-Flavor: Google:
nenhuma biblioteca de cliente é necessária. Para mais informações, consulte
Como conseguir metadados.
A tabela a seguir lista algumas das informações disponíveis do servidor de metadados:
| Caminho | Descrição |
|---|---|
/computeMetadata/v1/project/project-id |
ID do projeto deste serviço de fornecimento do Knative |
/computeMetadata/v1/instance/region |
Região deste serviço de veiculação do Knative |
/computeMetadata/v1/instance/id |
Identificador exclusivo da instância do contêiner (também disponível em logs). |
/computeMetadata/v1/instance/service-accounts/default/token |
Gera um token para a conta de serviço do ambiente de execução deste serviço de veiculação do Knative |