Entenda mais do Kubepit

Definições

A terminologia utilizada no âmbito do Kubepit é:

  • Mudança: Refere-se uma atualização de versão de aplicação. Por exemplo: Atualizar a aplicação “chat-service” da versão 2.0 para 2.1 seria uma mudança.

  • Aplicação: Refere-se a um programa de computador, representado por um recurso Deployment no cluster Kubernetes.

  • Deployment: No contexto do Kubernetes, o Deployment é a configuração de implantação de determinado programa, conteinerizado. No Deployment constam informações como a imagem Docker da aplicação, a quantidade de réplicas de escalabilidade horizontal, variáveis de ambiente, dentre outras.

Visão Geral

O Kubepit faz a comunicação com o Kubernetes, atualizando os Deployments conforme as mudanças aprovadas. Em termos práticos, o Kubepit altera a versão da imagem do container no respectivo Deployment conforme a versão solicitada na Requisição de Mudança.

O Kubepit mantém o histórico de todas as mudanças requisitadas, aprovadas, canceladas e aplicadas (no cluster), incluindo informações de usuário e data responsável por cada ação.

As mudanças podem ser aplicadas imediatamente ou conforme o calendário configurado no Kubepit.

Após aplicação da mudança - atualização do Deployment - o Kubepit inicia um pós processamento para monitorar se o Kubernetes atualizou todos os Pods com sucesso, ou seja, se o progresso do rollout atingiu a disponibilidade de 100%.

Flow

Ciclo de Vida

Da Requisição de Mudança:

A Requisição de Mudança no Kubepit tem o seguinte ciclo de vida:

  1. Nova (New): Situação inicial, quando criada pelo solicitante.

  2. Aprovada (Approved): Indica que a mudança foi aprovada pelo responsável. Se a segregação de papéis estiver ativa, o usuário aprovador deve ser diferente do solicitante.

  3. Cancelada (Canceled): A Requisição pode ser cancelada enquanto Nova ou Aprovada.

  4. Em processamento (Processing): Situação transitória, enquanto o Kubepit realiza a comunicação com o Kubernetes para atualização do Deployment.

  5. Falhou (Failed): Situação final, caso o Kubepit não tenha conseguido atualizar o Deployment. Situações mais comuns:

    • O Kubepit perdeu a comunicação com o cluster.

    • O Deployment encontra-se no estado pausado no Kubernetes.

    • O Deployment não possui a imagem esperada, conforme consta na Requisição. O Kubepit não altera o Deployment por motivo de segurança.

  6. Implantada (Deployed): Situação final, após o Kubepit atualizar com sucesso o Deployment no Kubernetes.

Do Monitoramento:

A aplicação da mudança no Deployment dispara o rollout do Kubernetes, em que os Pods serão recriados com a nova versão da aplicação.

O Kubepit monitora rollout durante um tempo, a fim de verificar se o Deployment foi efetivado com sucesso pelo cluster. Este processo de monitoramento atualizará o Rollout Status da Requisição, podendo valer:

  1. (sem valor): O Kubepit está iniciando a rotina de monitoramento do rollout.

  2. Não Iniciado (Awaiting start): Indica que o Kubernetes não teria iniciado o rollout ainda.

  3. Atualizando pods (Upgrading pods): O Kubernetes iniciou o rollout.

    • O Kubepit identifica este cenário quando há incremento do revision e atualização do status.observedGeneration no Deployment, com a respectiva ativação do ReplicaSet correspondente à revision.

  4. Concluído (Completed): Situação final, se o Deployment atingir disponibilidade plena dentro da janela de rollout (*1).

  5. Falhou (Failed): Situação final, quando ocorre falha nos novos Pods ou findou a janela de rollout (*1).

    • O Kubepit identifica falha no Pod caso seu status apresente algum dos casos elencados na propriedade app.rollout.fail-fast.reasons (vide parâmetros). A análise é feita nos Pods novos, aqueles sob propriedade do ReplicaSet vinculado à revision corrente do Deployment, nos campos status.reason, status.conditions[*].reason, status.containerStatuses[*].state.waiting.reason e status.initContainerStatuses[*].state.waiting.reason.

  6. Indisponível (Unavailable): Situação final, em que o Kubepit não consegue mais monitorar o rollout. Ocorre caso:

    • A geração do Deployment tenha mudado durante a janela de monitoramento (*2). Indica que alguém ou outro processo atualizou o Deployment fora do escopo da Requisição de Mudança.

    • Ultrapassou a janela de monitoramento, ou seja, o Kubepit estaria atrasado em tentar aferir a situação do rollout. Ocorre se kubepit-service ficar indisponível ou erro inesperado perdurar acima da janela de monitoramento (*2).

  7. Desconhecido (Unknown): Transitório, caso esteja ocorrendo erro inesperado, como falha de comunicação com o cluster.

Nota *1: A janela de rollout é o tempo limite para que a implantação atinga a situação Completo (disponibilidade 100%). O Kubernetes pode levar de 2 a 3 minutos adicionais além de minReadySeconds (se definido) para atualizar o status do Deployment como Available. Como minReadySeconds pode estar muito próximo de spec.progressDeadlineSeconds, o prazo real seguro para o rollout, adotado pelo Kubepit, é aproximadamente 2 ou 3 minutos após o prazo do progresso do Deployment.

Nota *2: A janela de monitoramento é ligeiramente maior (~1min) que a janela de rollout.

Resumo das situações da Requisição de Mudança e do monitoramento:

Life Cycle

Fluxo de decisão da rotina de monitoramento:

Tracking decision flow

Agendamentos

Quando da aprovação da Requisição de Mudança, o Kubepit fará o agendamento da implantação de acordo com a expressão cron configurada. A mudança será agendada para a próxima data da cron, contada da data de aprovação + 5 minutos.

Se a cron não estiver definida nas configurações do Kubepit, a Requisição de Mudança não será agendada. Nesse caso, o usuário deverá definir manualmente a data do agendamento por meio da funcionalidade de agendamento.

Auditoria

O Kubepit registra a data e o usuário (e-mail e ID) executor das ações de solicitação, cancelamento, aprovação e último agendamento manual nas Requisições de Mudança. O e-mail e ID são obtidos, respectivamente, dos claims email e user_id do JWT.

Adicionalmente, o Kubepit faz uma cópia do Deployment do Kubernetes (formato YAML) imediatamente antes e depois da aplicação da Requisição de Mudança. Os ConfigMaps vinculados (montados no Deployment) também são salvos. Essas cópias podem ser recuperadas via funcionalidade de inspeção na página ou API de gerenciamento das mudanças.

Todas as alterações de configuração (Settings) são auditáveis: O Kubepit versiona, com identicação da data e usuário, a mudança de cada atributo de configuração.

Instalação

Clique aqui para acessar o manual de instalação e configuração.