Pod

Esta página descreve o objeto pod do Kubernetes e seu uso no Google Kubernetes Engine.

O que é um pod?

Pods são os menores e mais básicos objetos implantáveis no Kubernetes. Um pod representa uma única instância de um processo em execução no seu cluster.

Os pods contêm um ou mais contêineres, como os Docker. Quando um pod executa vários contêineres, eles são gerenciados como uma única entidade e compartilham os recursos do pod. Geralmente, executar vários contêineres em um único pod é um caso de uso avançado.

Os pods também contêm recursos compartilhados de rede e armazenamento para os contêineres:

  • Rede: endereços IP exclusivos são atribuídos automaticamente aos pods. Os contêineres do pod compartilham o mesmo namespace da rede, incluindo o endereço IP e as portas de rede. Os contêineres em um pod se comunicam entre si dentro do pod em localhost.
  • Armazenamento: os pods podem especificar um conjunto de volumes de armazenamento compartilhado que pode ser compartilhado entre os contêineres.

Pense em um pod como um "host lógico" autônomo e isolado que contém as necessidades sistêmicas do aplicativo que ele veicula.

Um pod destina-se a executar uma única instância do seu aplicativo em seu cluster. No entanto, não é recomendado criar pods individuais diretamente. Em vez disso, geralmente cria-se um conjunto de pods idênticos, chamado réplicas, para executar o aplicativo. Esse conjunto de pods replicados é criado e gerenciado por um controlador, como uma Implantação. Os controladores gerenciam o ciclo de vida dos pods constituintes e também podem executar escalonamento horizontal, alterando o número de pods conforme necessário.

De vez em quanto, você pode interagir com pods de maneira direta para depurar, solucionar problemas ou inspecioná-los, mas é altamente recomendável usar um controlador para gerenciá-los.

Os pods são executados em nodes no cluster. Depois de criado, o pod permanece no nó até que o processo seja concluído, o pod seja excluído, removido do nó por falta de recursos ou pela falha do nó. Se um node falhar, os pods nele serão programados para exclusão automaticamente.

Ciclo de vida do pod

Os pods são efêmeros. Eles não são projetados para permanecer em execução para sempre e, depois de encerrados, não podem ser recuperados. Em geral, os pods não desaparecem até serem excluídos por um usuário ou por um controlador.

Os pods não se corrigem ou se reparam sozinhos. Por exemplo, se um pod for programado em um node e esse node falhar posteriormente, o pod será excluído. Da mesma forma, se um pod for removido de um node por qualquer motivo, ele não será substituído.

Cada pod tem um objeto de API PodStatus, que é representado pelo campo status de um pod. Os pods publicam a fase no campo status: phase. A fase é um resumo detalhado do estado atual do pod.

Ao executar kubectl get pod para inspecionar um pod em execução no cluster, o pod pode estar em uma das seguintes fases:

  • Pendente: o pod foi criado e aceito pelo cluster, mas um ou mais contêineres ainda não estão em execução. Essa fase inclui o tempo gasto para a programação em um nó e o download de imagens.
  • Em execução: o pod foi vinculado a um nó, e todos os contêineres foram criados. Pelo menos um contêiner está em execução, no processo de iniciar ou está reiniciando.
  • Bem-sucedido: todos os contêineres no pod foram encerrados com sucesso. Os pods encerrados não são reiniciados.
  • Falha: todos os contêineres no pod foram encerrados e pelo menos um foi encerrado com falha. Um contêiner "falha" se ele é encerrado com um status diferente de zero.
  • Desconhecido: o estado do pod não pode ser determinado.

Além disso, PodStatus contém uma matriz chamada PodConditions, que é representada no manifesto do pod como conditions. O campo tem um campo type e status. conditions indica mais especificamente as condições no pod que estão causando o status atual.

O campo type pode conter PodScheduled, Ready, Initialized e Unschedulable. O campo status corresponde ao campo type e pode conter True, False ou Unknown.

Crie pods

Como os pods são efêmeros, não é necessário criá-los diretamente. Da mesma forma, como os pods não podem reparar nem substituir a eles mesmos, não é recomendável criar pods diretamente.

Em vez disso, você pode usar um controlador, como o de implantação, para criar e gerenciar pods. Os controladores também são úteis para implementar atualizações, como a alteração da versão de um aplicativo executado em um contêiner, já que o controlador gerencia todo o processo de atualização para você.

Solicitações de pod

Quando um Pod começa a ser executado, ele solicita (em inglês) uma quantidade de CPU e memória. Isso ajuda o Kubernetes a programá-lo em um nó apropriado para executar a carga de trabalho. Um pod não será programado em um nó que não tenha os recursos para honrar a solicitação do pod. Uma solicitação é a quantidade mínima de CPU ou memória que o Kubernetes garante a um pod.

É possível configurar as solicitações de CPU e memória para um pod com base nos recursos que seus aplicativos precisam, além de especificar solicitações para contêineres individuais em execução no pod. Lembre-se do seguinte:

  • A solicitação padrão de CPU é 100 m. Isso é muito pouco para muitos aplicativos e provavelmente é muito menor do que a quantidade de CPU disponível no nó.
  • Não há solicitação padrão de memória. Um pod sem solicitação padrão de memória pode ser programado em um nó sem memória suficiente para executar as cargas de trabalho do pod.
  • Definir um valor muito pequeno para solicitações de CPU ou de memória pode fazer com que muitos pods ou uma combinação abaixo do ideal de pods sejam programados em um determinado nó, além de reduzir o desempenho.
  • Definir um valor muito grande para solicitações de CPU ou memória pode fazer com que o pod não seja programado, além de aumentar o custo dos recursos do cluster.
  • É possível especificar os recursos para contêineres individuais em execução no pod além, ou em vez, de definir os recursos do pod. Se você especificar apenas recursos para os contêineres, as solicitações do pod serão a soma das solicitações especificadas para os contêineres. Se você especificar ambos, a soma das solicitações de todos os contêineres não poderá exceder as solicitações de pod.

É altamente recomendável que você configure as solicitações dos pods com base nos requisitos das cargas de trabalho reais. Para mais informações, consulte Práticas recomendadas do Kubernetes: limites e solicitações de recursos (em inglês) no blog do Google Cloud.

Limites de pod

Por padrão, um pod não tem limite superior na quantidade máxima de CPU ou memória que pode ser usada em um nó. Defina limites (em inglês) para controlar a quantidade de CPU ou memória que o pod pode usar em um nó. Um limite é a quantidade máxima de CPU ou de memória que o Kubernetes garante a um pod.

É possível especificar os limites para contêineres individuais em execução no pod além, ou em vez, de definir os limites do pod. Se você especificar limites apenas para os contêineres, os limites do pod serão a soma dos limites especificados para os contêineres. No entanto, cada contêiner só pode acessar recursos até o limite próprio. Portanto, se você optar por especificar os limites apenas em contêineres, será preciso especificar limites para cada um deles. Se você especificar ambos, a soma dos limites de todos os contêineres não poderá exceder o limite do pod.

Os limites não são considerados ao programar pods, mas podem impedir a contenção de recursos entre pods no mesmo nó e podem impedir que um pod cause instabilidade do sistema no nó ao privar o sistema operacional subjacente de recursos.

É altamente recomendável que você configure limites para seus pods com base nos requisitos das cargas de trabalho reais. Para mais informações, consulte as práticas recomendadas do Kubernetes: solicitações de recursos e limites no blog do Google Cloud.

Modelos de pod

Nos objetos do controlador, como implantações e StatefulSets, há um campo Modelo de pod. Os modelos de pod têm uma especificação de pod que determina como cada um é executado. Isso inclui quais contêineres serão executados nos pods e quais volumes os pods precisam ativar.

Os objetos de controlador usam os modelos de pod para criar pods e gerenciar o "estado pretendido" dele dentro do cluster. Quando um modelo é alterado, todos os pods futuros refletem essa alteração, mas os pods existentes não.

Para mais informações sobre como os modelos de pod funcionam, consulte Como criar uma Implantação na documentação do Kubernetes.

Como controlar em quais nós um pod é executado

Por padrão, os pods são executados nos nós do pool de nós padrão do cluster. É possível configurar o pool de nós que um pod seleciona de forma explícita ou implícita:

  • É possível forçar explicitamente um pod a implantar em um pool de nós específico configurando um nodeSelector no manifesto do pod. Isso força um pod a ser executado apenas nos nós desse pool.

  • É possível especificar solicitações de recursos nos contêineres (em inglês) que você executa. O pod será executado apenas em nós que satisfaçam as solicitações de recursos. Por exemplo, se a definição do pod incluir um contêiner que requer quatro CPUs, o Serviço não selecionará pods em execução nos Nós com dois CPUs.

Padrões de uso de pod

Os pods podem ser usados de duas maneiras principais:

  • Pods que executam um único contêiner: o padrão mais simples e comum é um único contêiner por pod, em que esse contêiner representa um aplicativo completo. Nesse caso, pense em um pod como um invólucro.
  • Pods que executam vários contêineres que precisam trabalhar juntos: Os pods com vários contêineres são usados principalmente para dar suporte a programas colocalizados e cogerenciados que precisam compartilhar recursos. Esses contêineres colocalizados podem formar uma única unidade de serviço coesa: um contêiner que exibe arquivos de um volume compartilhado enquanto outro contêiner atualiza esses arquivos. O pod envolve contêineres e recursos de armazenamento juntos como uma única entidade gerenciável.

Cada pod executa uma única instância de um determinado aplicativo. Se quiser executar múltiplas instâncias, você deve usar um pod para cada instância do aplicativo. Isso geralmente é chamado de replicação. Os pods replicados são criados e gerenciados em grupo por um controlador, como o de implantação.

Encerramento de pods

Os pods são encerrados de maneira prática quando os processos são completos. O Kubernetes impõe um período de encerramento normal padrão de 30 segundos. Ao excluir um pod, é possível modificar esse período de carência definindo a sinalização --grace-period como o número de segundos a aguardar até que o pod termine antes de ser forçado a encerrá-lo.

A seguir