Contrato de tempo de execução de contentores

Esta página apresenta os principais requisitos e comportamentos dos contentores na publicação do Knative.

Idiomas e imagens compatíveis

A imagem do contentor pode executar código escrito na linguagem de programação da sua escolha e usar qualquer imagem base, desde que respeite as restrições indicadas nesta página.

Os ficheiros executáveis na imagem do contentor têm de ser compilados para Linux de 64 bits. O Knative Serving suporta especificamente o formato ABI Linux x86_64.

Ouvir pedidos na porta correta

O contentor tem de ouvir pedidos em 0.0.0.0 na porta para a qual os pedidos são enviados. Por predefinição, os pedidos são enviados para 8080, mas pode configurar o Knative Serving para enviar pedidos para a porta da sua escolha.

Nas instâncias de contentores de publicação do Knative, o valor da variável de ambiente PORT reflete sempre a porta para a qual os pedidos são enviados. A predefinição é 8080.

Encriptação da camada de transporte (TLS)

O contentor não deve implementar diretamente nenhuma segurança da camada de transporte. O TLS é terminado pelo Knative Serving para HTTPS e gRPC e, em seguida, os pedidos são enviados por proxy como HTTP ou gRPC para o contentor sem TLS.

Responses

A instância do contentor tem de enviar uma resposta no prazo especificado na definição de tempo limite do pedido após receber um pedido, incluindo o tempo de arranque da instância do contentor. Caso contrário, o pedido é terminado e é devolvido um erro 504.

Variáveis de ambiente

As seguintes variáveis de ambiente são adicionadas automaticamente aos contentores em execução:

Nome	Descrição	Exemplo
PORT	A porta que o seu servidor HTTP deve escutar.	8080
K_SERVICE	O nome do serviço de publicação do Knative em execução.	hello-world
K_REVISION	O nome da revisão de publicação do Knative que está a ser executada.	hello-world.1
K_CONFIGURATION	O nome da configuração do Knative serving que criou a revisão.	hello-world

Acesso ao sistema de ficheiros

O sistema de ficheiros do seu contentor é gravável e está sujeito ao seguinte comportamento:

• Este é um sistema de ficheiros na memória, pelo que a escrita no mesmo usa a memória da instância do contentor.
• Os dados escritos no sistema de ficheiros não persistem quando a instância do contentor é parada.

Ciclo de vida da instância do contentor

Em resposta aos pedidos recebidos, um serviço é dimensionado automaticamente para um determinado número de instâncias de contentores, cada uma das quais executa a imagem de contentor implementada.

Quando uma revisão não recebe tráfego, é reduzida até ao número mínimo de instâncias de contentores configurado (zero por predefinição).

Arranque

As instâncias do contentor têm de ouvir pedidos no prazo de 4 minutos após o início. Durante este tempo de arranque, as instâncias de contentores recebem CPU.

A computação tem âmbito de um pedido

Após o arranque, só deve esperar poder fazer cálculos no âmbito de um pedido: uma instância de contentor não tem nenhuma CPU atribuída se não estiver a processar um pedido.

Encerrar

Uma instância de contentor pode ser encerrada em qualquer altura.

Quando uma instância de contentor tem de ser encerrada, os novos pedidos recebidos são encaminhados para outras instâncias e os pedidos que estão a ser processados têm tempo para serem concluídos. A instância do contentor recebe então um sinal SIGTERM a indicar o início de um período de 10 segundos antes de ser encerrada (com um sinal SIGKILL). Durante este período, a instância do contentor recebe CPU e é faturada. Se a instância do contentor não receber o sinal SIGTERM, é encerrada imediatamente.

A menos que uma instância de contentor tenha de ser mantida inativa devido à definição de configuração do número mínimo de instâncias de contentores, não é mantida inativa durante mais de 15 minutos.

Recursos de instâncias de contentores

Os pedidos de recursos para as suas instâncias de contentores são agendados nos nós do seu cluster do GKE. Cada nó partilha a quantidade total de recursos de computação que está disponível para o seu cluster do GKE.

Por conseguinte, a quantidade de recursos de computação disponíveis para um serviço de publicação do Knative é limitada apenas pela quantidade de recursos disponíveis nesse nó. Saiba mais acerca dos recursos de computação para pedidos.

Por exemplo, se atribuir 512 MiB de memória a um contentor e esse contentor estiver a ser executado no único pod num nó com 8 GiB de memória, esse contentor pode tentar usar mais RAM.

CPU

Por predefinição, o queue proxy sidecar reserva 25 milliCPU e não existe limite para a quantidade de vCPU que os seus serviços Knative serving podem usar. O consumo de recursos do proxy de fila depende do número de pedidos que estão a ser colocados em fila e do tamanho dos pedidos.

Uma vCPU é implementada como uma abstração do hardware subjacente para fornecer o tempo de CPU aproximadamente equivalente de um único hiperthread de hardware em plataformas de CPU variáveis. A instância do contentor pode ser executada em vários núcleos em simultâneo. A vCPU só é atribuída durante o arranque da instância do contentor e o processamento de pedidos. Caso contrário, é limitada.

Para atribuir um valor de vCPU diferente, consulte a documentação sobre a atribuição de CPU.

Memória

Por predefinição, o proxy auxiliar de filas não reserva memória e não existe um limite para a quantidade de memória que os seus serviços Knative serving podem usar. Se quiser, pode configurar limites de memória para os seus serviços de publicação do Knative. Para mais informações sobre como o GKE processa a memória, consulte o artigo Recursos de CPU e memória alocáveis.

As utilizações típicas da memória incluem:

• Código carregado na memória para executar o serviço
• Escrever no sistema de ficheiros
• Processos adicionais em execução no contentor, como um servidor nginx
• Sistemas de colocação em cache na memória, como o PHP OpCache
• Utilização de memória por pedido

Simultaneidade

Por predefinição, cada instância do contentor de publicação do Knative está definida para ter várias concorrências, em que cada instância do contentor pode receber mais do que um pedido em simultâneo. Pode alterar esta opção definindo a simultaneidade.

Sandbox da instância do contentor

O Knative serving não usa uma sandbox de contentor.

Servidor de metadados da instância do contentor

As instâncias de contentores de publicação do Knative expõem um servidor de metadados que pode usar para obter detalhes sobre a instância de contentor, como o ID do projeto, a região, o ID da instância ou as contas de serviço.

Pode aceder a estes dados a partir do servidor de metadados através de pedidos HTTP simples para o ponto final http://metadata.google.internal/ com o cabeçalho Metadata-Flavor: Google. Não são necessárias bibliotecas cliente. Para mais informações, consulte o artigo Obter metadados.

A tabela seguinte apresenta algumas das informações do servidor de metadados disponíveis:

Caminho	Descrição
/computeMetadata/v1/project/project-id	ID do projeto deste serviço de publicação do Knative
/computeMetadata/v1/instance/region	Região deste serviço de publicação do Knative
/computeMetadata/v1/instance/id	Identificador exclusivo da instância do contentor (também disponível nos registos).
/computeMetadata/v1/instance/service-accounts/default/token	Gera uma chave de acesso para a conta de serviço de tempo de execução deste serviço de publicação do Knative