Caracterização dos controladores do Kubernetes

Como discutido na seção anterior, os controladores são abstrações oferecidas pelo Kuber- netes com o objetivo de facilitar o gerenciamento de aplicações por parte de seus usuários. Cada um dos controladores disponíveis no sistema foi projetado e implementado com base em um tipo diferente de aplicação. De acordo com suas descrições e propósitos, é possí- vel categorizar os controladores suportados pelo Kubernetes em duas classes: de Serviço e Batch. Segue uma breve descrição para cada uma dessas classes.

3_{O crontab é um programa que edita o arquivo onde são especificados os comandos a serem executados e a}

hora e dia de execução pelo cron, que é um serviço que executa comandos agendados nos sistemas operacionais do tipo Unix.

7.2 Viabilidade de implementação 104 Controlador de Serviço

Um controlador de serviço tem como meta assegurar que um número específico de réplicas de um pod esteja em execução ao longo do tempo. O pod a ser replicado é definido pelo usuário no momento da criação do controlador por meio de um template. Além disso, as réplicas gerenciadas por um controlador de serviço não têm a expectativa de serem finaliza- das, i.e. elas executam réplicas de um serviço. A partir deste ponto, uma réplica gerenciada por um controlador desta classe será referenciada como uma instância. Portanto, se um con- trolador é responsável por manter em execução, por exemplo, duas réplicas de um template definido pelo usuário, significa que duas instâncias do template devem estar em execução ao longo do tempo.

Esta classe de controlador gerencia um conjunto finito de réplicas (instâncias) Cs = {p1, ..., pr}, onde r é o número máximo de instâncias do template. Cada instância pi, pi ∈ Cs, tem uma ou mais encarnações. Sempre que um pod é criado pelo controlador Cs, este pod é considerado como uma nova encarnação de uma das instâncias deste controlador. Portanto, quando uma instância pi falha (por exemplo, por causa de preempção ou falha do servidor), uma nova encarnação de pi (i.e. um novo pod) é criada e adicionada à fila de espera para escalonamento. Considere pi = {p1i, ..., pmi } como o conjunto de encarnações da instância pi e m como o número de encarnações de pi, então pei representa a e-ésima encarnação da instância pi.

Em qualquer instante no tempo t, uma encarnação pe

i de uma instância pi de um contro- lador de serviço Csestá associada a um único estado. Considere que s(pei, t)indica o estado de pe

i no tempo t, então s(pei, t)∈ {Esperando, Executando, F alha}. Uma encarnação de instância qualquer inicia no estado Esperando e seguirá para o estado Executando quando o escalonador conseguir alocar recursos para a mesma. Do estado Executando, a encarnação pode seguir para o estado Falha, no caso dela ser finalizada por causa de falha do servidor ou devido a atuação da política de escalonamento (que pode decidir preemptá-la). Destaca-se que uma encarnação de instância falha não mais será considerada para escalonamento. Este é o estado final para a encarnação em questão.

Considere que WCs(t), RCs(t), e FCs(t)são os conjuntos das encarnações das instâncias do controlador de serviço Csque, no tempo t, estão, respectivamente, nos estados Esperando, Executando e Falha. O conjunto ICs(t) = WCs(t)∪RCs(t)∪FCs(t)representa o conjunto de

7.2 Viabilidade de implementação 105 todas as encarnações das instâncias de Csno tempo t. Note que uma mesma encarnação não poderá estar em dois desses conjuntos no instante t, no entanto, uma mesma instância pode ter encarnações em mais de um conjunto no instante t. Por exemplo, quando uma terceira encarnação de uma instância pi é criada no tempo t, significa que duas outras encarnações desta instância já falharam até t, portanto, essas encarnações que já falharam estarão no conjunto Fpi(t), enquanto a nova encarnação estará no conjunto Wpi(t).

No contexto dos controladores do Kubernetes (discutidos na Seção 7.2.1), é possível classificar o Deployment, o StatefulSet e o DaemonSet como controladores de serviço. Todos esses controladores são semelhantes no sentido que eles atuam para manter instâncias de um template em execução ao longo do tempo. O objetivo tanto do Deployment como do StatefulSet é assegurar que um número específico de instâncias estejam em execução ao longo do tempo. O primeiro é projetado para aplicações stateless enquanto que o segundo para aplicações stateful. O DaemonSet também visa manter um conjunto de instâncias em execução, no entanto, há restrições envolvidas na alocação dessas instâncias (cada instância deve executar em um servidor diferente).

Controlador Batch

Diferentemente de um controlador de serviço, um controlador Batch é responsável por ge- renciar instâncias que têm a expectativa de serem finalizadas com sucesso. Uma instância é finalizada com sucesso quando sua tarefa computacional é concluída sem interrupções ao longo de sua execução. Nesse sentido, o usuário especifica um template para a instância, definindo também a tarefa de computação a ser executada na mesma. Um controlador desta classe é responsável por criar uma ou mais cópias do template e assegurar que um número específico dessas cópias sejam finalizadas com sucesso. A partir deste ponto, uma cópia ge- renciada por um controlador Batch será referenciada como uma instância. Portanto, se um controlador é responsável por concluir com sucesso, por exemplo, três cópias de um template definido pelo usuário, significa que três instâncias desse template devem ser finalizadas com sucesso.

Um controlador Batch gerencia um conjunto finito de cópias (instâncias) Cb = {p1, ..., pn}, onde n é o número total de instâncias do template que precisam ser finaliza- das com sucesso. É possível que o controlador crie mais de uma instância para executar

7.2 Viabilidade de implementação 106 paralelamente. Considere Cr

b como o número máximo de instâncias de um controlador Cb que pode executar em paralelo. Caso falte menos instâncias que Cr

b para que o controla- dor tenha as n instâncias concluídas com sucesso, o controlador criará apenas a quantidade necessária de instâncias para que o número n de instâncias concluídas seja alcançado.

De forma semelhante ao controlador de serviço, cada instância pi, pi ∈ Cb, tem uma ou mais encarnações. Sempre que um pod é criado pelo controlador Cb, este pod é considerado como uma nova encarnação de uma das instâncias deste controlador. Portanto, quanto a ins- tância pifalha, uma nova encarnação da instância pi(i.e. um novo pod) é criada e adicionada à fila de espera para escalonamento. Considere pi ={p1i, ..., pmi } como o conjunto de encar- nações da instância pi e m como o número de encarnações de pi, então pei indica a e-ésima encarnação da instância pi.

Em qualquer instante no tempo t, uma encarnação de uma instância pe

i de um controla- dor Batch Cb está associada a um estado. Considere que s(pei, t)representa o estado de pei no tempo t, s(pe

i, t) ∈ {Esperando, Executando, F alha, Completa}. Além dos estados pos- síveis para uma encarnação de instância de serviço (Esperando, Executando e Falha), uma encarnação de uma instância batch também pode estar no estado Completa. Este estado re- presenta quando uma encarnação conseguiu concluir sua computação com sucesso. Portanto, uma encarnação inicia no estado Esperando e seguirá para o estado Executando quando o escalonador conseguir alocar recursos para a mesma. Do estado Executando, a encarnação pode seguir para um dos dois estados: Completa (se a execução for concluída com sucesso) ou Falha (se a encarnação for finalizada sem sucesso, por exemplo, por causa da atuação do escalonador ou falha do servidor). Novamente, é importante destacar que uma vez que uma encarnação de um instância falhar, esta encarnação não mais será considerada para escalo- namento. Como discutido anteriormente, uma nova encarnação para a mesma instância é criada, e, esta sim será considerada para ser preemptada. Uma encarnação que é completada também não mais será completada para escalonamento. Esses (Falha e Completa) são os estados finais para as encarnações em questão.

Considere que WCb(t), RCb(t), FCb(t)e CCb(t)são os conjuntos de encarnações das ins- tâncias de um controlador Batch Cb que, no tempo t, estão, respectivamente, nos estados Esperando, Executando, Falha e Completa. O conjunto ICb(t) = WCb(t)∪RCb(t)∪FCb(t)∪ CCb(t)indica o conjunto de todas as encarnações de todas as instâncias de Cbno tempo t. De

7.2 Viabilidade de implementação 107 forma equivalente, Wpi(t), Rpi(t), Fpi(t)e Cpi(t)são os conjuntos das encarnações de uma instância pi que, no tempo t, estão, respectivamente, nos estados Esperando, Executando, Falha e Completa. Assim, Ipi(t) = Wpi(t)∪ Rpi(t)∪ Fpi(t)∪ Cpi(t)é o conjunto de todas as encarnações da instância pino tempo t.

Analisando os controladores oferecidos pelo Kubernetes (discutidos na Seção 7.2.1), é possível classificar o Job e CronJob como controladores Batch. Esses controladores têm características semelhantes, ambos gerenciam instâncias que têm a expectativa de serem finalizadas com sucesso. O Job é usado pelo usuário quando a tarefa computacional a ser executada deve ser concluída e não se repetirá de forma previamente conhecida, enquanto que o CronJob cria Jobs a serem executados periodicamente no sistema.