Contrato de ambiente de execução de contêiner

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