Pod

Nesta página, descrevemos o objeto pod do Kubernetes e o uso dele no 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 no 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 é criado e gerenciado por um controlador, como o de 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, ele permanece no node até que o processo seja concluído, o pod seja excluído, removido do node por falta de recursos ou pela falha do node. 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 PodStatus API, que é representado pelo campo status. Os pods publicam a própria fase no campo status: phase. A fase é um resumo detalhado do estado atual do pod.

Quando você executa kubectl get pod (em inglês) para inspecionar um pod em execução no cluster, esse 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, o PodStatus contém uma matriz chamada PodConditions, que é representada no manifesto do pod como conditions. Há um campo type e status. conditions indica mais especificamente as condições dentro do pod que estão causando o status atual.

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

Como criar 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 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 as práticas recomendadas do Kubernetes: limites e solicitações de recursos (em inglês) no blog do GCP.

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 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 as solicitações de pod.

Os limites não são levados em consideração 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: limites e solicitações de recursos (em inglês) no blog do GCP.

Modelos de pod

Nos objetos de controlador, como Deployments e StatefulSets, há um campo de modelo de pod (em inglês). Os modelos 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 ativarão.

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

Para ver 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 no 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 as solicitações de recursos para os contêineres 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: 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 veicula 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 concluídos. O Kubernetes impõe um período de encerramento normal padrão de 30 segundos. Ao excluir um pod (em inglês), é possível substituir esse período de carência, definindo a sinalização --grace-period como o número de segundos de espera que o pod pode levar para ser encerrado antes de forçar o encerramento.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine