Visão geral

Visão geral do pod

Um pod é a unidade menor e mais simples no modelo de objeto do Kubernetes que você cria ou implementa. Um pod é um grupo de um ou mais contêineres, com recursos de rede e armazenamento compartilhados, e uma especificação de como executar os contêineres. Cada pod tem um endereço IP separado.

Os pods podem ser usados de uma das seguintes maneiras:

• Um pod executa apenas um contêiner. Esse é o uso mais comum de pods no Kubernetes. Você pode considerar um pod como um contêiner, mas o Kubernetes gerencia diretamente pods em vez de contêineres.
• Um pod executa vários contêineres que precisam ser fortemente acoplados. Nesse cenário, um pod contém um contêiner principal e vários contêineres de sidecar, conforme mostrado em Figura 1. Por exemplo, o contêiner principal é um servidor da Web que fornece serviços de arquivos a partir de um diretório fixo, e contêineres de sidecar baixam arquivos periodicamente para esse diretório fixo.
  Figura 1 Pod executando vários contêineres
  

No Kubernetes, os pods são raramente criados diretamente. Em vez disso, o controlador do Kubernetes gerencia pods por meio de instâncias de pods, como Deployments e jobs. Um controlador normalmente usa um modelo de pod para criar pods. O controlador também pode gerenciar vários pods e fornecer funções como gerenciamento de réplicas, atualização contínua e autocorreção.

Visão geral de Deployment

Um pod é a unidade menor e mais simples que você cria ou implementa em Kubernetes. Ele foi projetado para ser uma entidade efêmera e única. Um pod pode ser removido quando os recursos do nó são insuficientes e desaparece junto com uma falha no nó do cluster. O Kubernetes fornece controladores para gerenciar pods. Os controladores podem criar e gerenciar pods e fornecer recursos de gerenciamento de réplicas, atualização contínua e autocorreção. O controlador mais comumente usado é o Deployment.

Figura 2 Relacionamento entre um Deployment e pods

Um Deployment pode conter um ou mais pods. Esses pods têm a mesma função. Portanto, o sistema distribui solicitações automaticamente para vários pods de um Deployment.

Um Deployment integra muitas funções, incluindo implementação on-line, atualização contínua, criação de réplicas e restauração de tarefas on-line. Até certo ponto, os Deployments podem ser usados para realizar a implementação autônoma, o que reduz bastante as dificuldades e os riscos de operação no processo de implementação.

Visão geral de StatefulSet

Todos os pods em um Deployment têm as mesmas características, exceto o nome e o endereço IP. Se necessário, um Deployment pode usar um modelo de pod para criar novos pods. Se não for necessário, o Deployment pode excluir qualquer um dos pods.

No entanto, os Deployments não podem atender aos requisitos em alguns cenários distribuídos quando cada pod requer seu próprio status ou em um banco de dados distribuído onde cada pod requer armazenamento independente.

As aplicações distribuídas com estado envolvem diferentes funções para diferentes responsabilidades. Por exemplo, os bancos de dados funcionam no modo ativo/em espera, e os pods dependem uns dos outros. Para implementar aplicações com estado no Kubernetes, certifique-se de que os pods atendam aos seguintes requisitos:

• Cada pod deve ter um identificador fixo para que possa ser reconhecido por outros pods.
• Recursos de armazenamento separados devem ser configurados para cada pod. Dessa forma, os dados originais podem ser recuperados depois que um pod é excluído e restaurado. Caso contrário, o status do pod será alterado depois que o pod for reconstruído.

Para atender aos requisitos anteriores, o Kubernetes fornece StatefulSets.

1. Os StatefulSets fornecem um nome fixo para cada pod seguindo um número fixo que varia de 0 a N. Depois que um pod é reprogramado, o nome do pod e o nome do host permanecem inalterados.
2. Os StatefulSets usam um Serviço sem periféricos para alocar um nome de domínio fixo para cada pod.
3. Os StatefulSets criam PersistentVolumeClaims (PVCs) com identificadores fixos para garantir que os pods acessem os mesmos dados persistentes após serem reprogramados.

   

Visão geral do DaemonSet

Um DaemonSet executa um pod em cada nó em um cluster e garante que haja apenas um pod. Isso funciona bem para determinadas configurações no nível do sistema, como coleta de logs e monitoramento de recursos, pois elas devem ser executadas em cada nó e precisam apenas de alguns pods. Um bom exemplo é o kube-proxy.

Os DaemonSets estão intimamente relacionados aos nós. Se um nó se tornar defeituoso, o DaemonSet não criará os mesmos pods em outros nós.

Figura 3 DaemonSet

Visão geral do job e do CronJob

Jobs e CronJobs permitem que você execute tarefas únicas e de curta duração em lote. Eles garantem que os pods de tarefas sejam executados até a conclusão.

• Um job é um objeto de recurso usado pelo Kubernetes para controlar tarefas em lote. Jobs são diferentes das tarefas servo de longo prazo (como Deployments e StatefulSets). O primeiro é iniciado e encerrado em horários específicos, enquanto o segundo é executado ininterruptamente, a menos que seja encerrado. Os pods gerenciados por um job serão removidos automaticamente após a conclusão bem-sucedida das tarefas com base nas configurações do usuário.
• Um CronJob executa um job periodicamente em uma programação especificada. Um objeto CronJob é semelhante a uma linha de um arquivo crontab no Linux.

Esse recurso de execução até a conclusão dos jobs é especialmente adequado para tarefas pontuais, como integração contínua (CI).

Ciclo de vida da carga de trabalho