Submissão de cargas de trabalho no Kubernetes

No contexto do Kubernetes, uma instância pode ser representada por um pod. Um pod é a menor abstração gerenciável no sistema e é capaz de encapsular um ou mais contêineres de uma aplicação, recursos de armazenamento, um IP único na rede e opções que direcio- nam como o(s) contêiner(es) da aplicação deve(m) executar. Em outras palavras, um pod representa uma instância de uma aplicação no sistema Kubernetes.

7.2 Viabilidade de implementação 101 que o pod execute múltiplos contêineres que precisem trabalhar em conjunto na aplicação a ser executada. Quando o usuário cria um pod diretamente no sistema, ele é adicionado em uma fila de espera que é processada pelo escalonador. Para cada pod na lista de espera, o escalonador seleciona o servidor mais adequado para prover recursos de acordo com sua política de escalonamento. Caso o escalonador não consiga selecionar um servidor para um dado pod, este continuará na fila até que o escalonador consiga alocar recursos para o mesmo no futuro. Após um pod ser alocado em um servidor, ele permanece executando no mesmo até que sua tarefa computacional seja concluída, o servidor falhe ou o pod seja deletado ou preemptado. Após um desses eventos, o pod é finalizado, e, caso não seja gerenciado por outras abstrações, não será reescalonado.

Existem duas formas básicas de criar instâncias para aplicações no sistema Kubernetes. Na primeira, os usuários podem criar objetos pods diretamente. Neste caso, os pods são chamados de bare pods e funcionam como descrito no parágrafo anterior. Uma instância de uma aplicação estará no sistema (pendente ou em execução) enquanto o pod desta instância não for finalizado.

No entanto, espera-se que um usuário raramente crie pods individuais diretamente no Kubernetes. Este sistema oferece um conjunto de abstrações de mais alto nível, denomina- das de controladores. Um controlador tem como objetivo gerenciar um conjunto de pods, manipular replicações e atualizações de um pod e fornecer recursos de tolerância a falhas no escopo do sistema. Por exemplo, se um servidor falhar ou um pod for preemptado, o contro- lador pode substituir automaticamente o pod finalizado por meio da criação de um outro pod idêntico, a ser escalonado em um servidor diferente. Neste cenário, apesar de serem dois ob- jetos diferentes, ambos os pods estão relacionados com uma mesma instância da aplicação. O segundo pod é idêntico ao primeiro e foi criado apenas porque o primeiro foi finalizado, i.e. foi criado para que a instância da aplicação possa continuar sua execução.

No geral, os controladores usam um modelo especificado pelo usuário para criar os pods pelos quais eles são responsáveis. Os principais controladores oferecidos pelo Kubernetes são:

• Deployment: o propósito deste controlador é assegurar que um número específico de réplicas de um pod esteja em execução ao longo do tempo. Em outras palavras, este controlador visa assegurar que um número específico de instâncias da aplicação

7.2 Viabilidade de implementação 102 esteja em execução ao longo do tempo. Um deployment gerencia pods que executam por tempo indeterminado, sem a expectativa de serem finalizados — por exemplo, serviços interativos na Web. Quando um pod é finalizado (por exemplo, por causa de preempção ou falha do servidor) e um outro pod é criado com o intuito de manter o número de réplicas (instâncias) da aplicação no sistema, o estado da aplicação não é mantido entre os diferentes pods. Portanto, este controlador é destinado a aplicações stateless.

• StatefulSet: este controlador tem objetivo semelhante ao Deployment. Ele também visa assegurar que um número específico de réplicas de um pod (i.e. instância) esteja em execução ao longo do tempo. No entanto, este controlador mantém o estado entre dois pods criados em sequência para a mesma réplica, mantendo um identificador e armazenamento persistente entre esses pods. Além disso, o StatefulSet também garante a ordem de implantação das réplicas por ele gerenciadas. Por exemplo, considerando que um controlador StatefulSet é responsável por manter três réplicas em execução, a réplica 1 sempre será a primeira a ser alocada, e, em seguida, as réplicas 2 e 3 nesta ordem.

• DaemonSet: este controlador tem como meta assegurar que uma réplica de um pod execute em todos ou em um conjunto específico dos servidores da infraestrutura. Quando um DaemonSet é criado, é possível que o usuário especifique restrições de alocação para as réplicas por ele gerenciadas, tais como vCP U > 2 e RAM < 2GB. Neste caso, uma réplica será alocada em cada servidor que satisfaça suas restrições. Caso nenhuma restrição seja definida pelo usuário, uma réplica deve ser alocada em cada servidor da infraestrutura. Assim sendo, quando um novo servidor é adicionado à infraestrutura, uma nova réplica é criada para cada DaemonSet no sistema que tenha suas restrições de alocação atendidas pelo novo servidor. Quando servidores são re- movidos, as réplicas de um DaemonSet que estavam executando nos mesmos não são criadas em outros servidores.

• Job: este controlador cria uma ou mais cópias de um pod e assegura que um número específico dessas cópias sejam finalizadas com sucesso. Diferentemente dos contro- ladores apresentados até então, um Job gerencia pods que têm a expectativa de serem

7.2 Viabilidade de implementação 103 finalizados após a execução de uma tarefa computacional — por exemplo, aplicações do tipo “saco-de-tarefas” (BoT, do inglês Bag-of-Tasks). Quando um número especí- fico de cópias finalizadas é alcançado, o Job está completo. Além disso, um Job pode executar mais de uma cópia do pod em paralelo, este limite é configurado no momento de criação do Job. Nesse sentido, quando uma das cópias (instâncias) é finalizada com sucesso, uma nova cópia é criada caso ainda seja necessário.

• CronJob: este controlador é responsável por criar um Job específico periodicamente. Um objeto CronJob é como uma linha de um arquivo crontab3_{, que tem o objetivo de} executar um Job periodicamente em um dado escalonador. Como exemplo de caso de uso deste controlador, suponha um Job responsável pela realização de um backup que precisa ser realizado todos os dias em um horário específico. Ao invés de criar um Job para essa atividade todos os dias individualmente, um CronJob pode ser criado para escalonar esse Job todos os dias no mesmo horário específico.

Nesse contexto, a submissão de um controlador à um cluster Kubernetes pode ser inter- pretada como a submissão de uma requisição que pode estar associada com mais de uma instância. Por exemplo, suponha que um usuário submete um Deployment que deve criar e manter 3 réplicas de uma aplicação específica, então considera-se este Deployment como uma requisição que está associada a 3 instâncias no cluster.