De alguma forma, nos comentários, eles fizeram a pergunta de como a participação no Slurm difere da leitura de manuais no Kubernetes. Pedi a Pavel Selivanov, palestrante do Slurm-2 e MegaSlurm, para dar um pequeno exemplo do que ele vai contar sobre o Slurm. Eu dou a palavra a ele.
Estou administrando o cluster Kubernetes. Recentemente, eu precisava atualizar a versão do k8s e, inclusive, reiniciar todas as máquinas no cluster. Comecei o processo às 12:00 e, no final do dia útil, tudo estava pronto. E pela primeira vez, eu ainda acompanhei o andamento da atualização, e na segunda vez saí para almoçar por 1,5 horas (para ser justo, pegando um laptop). O cluster foi atualizado automaticamente, sem a minha participação e invisivelmente para os clientes, o desenvolvimento não percebeu nada, as implantações continuaram, o serviço funcionou normalmente.
Como era.
Problemas prováveis
Ao reiniciar máquinas, há dois cenários ruins.
- O desenvolvedor lançou o aplicativo / redis em uma instância. Não importa o quão cuidadosamente você tire o carro de serviço, o tempo de inatividade ocorrerá.
- Existem 2 réplicas do aplicativo e uma é implantada. Ela saiu, havia apenas uma réplica e, em seguida, o administrador aparece e apaga a última réplica. Novamente, até a réplica aumentar após a implantação, haverá um tempo de inatividade.
Eu poderia coordenar a reinicialização com o desenvolvimento, dizem eles, interromper a implantação, verificar as instâncias, reiniciaremos as máquinas, mas gosto da ideia do DevOps de que a comunicação humana deve ser minimizada. É melhor configurar a automação uma vez do que coordenar suas ações a cada vez.
Condições da tarefa
Eu uso a Amazon com sua conveniência e estabilidade. Tudo é automatizado, você pode criar e extinguir máquinas virtuais, verificar sua disponibilidade, etc.
O cluster Kubernetes é implantado, gerenciado e atualizado por meio do utilitário kops, que eu realmente amo.
Ao atualizar o kops, ele drena automaticamente um nó (nó de drenagem kubectl), aguarda até que tudo tenha sido evacuado desse nó, o remove, cria um novo nó no Amazon com a versão correta dos componentes do Kubernetes, o anexa ao cluster, verifica se o nó entrou bem no cluster, e assim com todos os nós em um círculo até que a versão desejada do Kubernetes esteja em todo lugar.
Solução
No CI, eu uso o kube-lint para verificar todos os manifestos que serão lançados no Kubernetes. O Helm Template lança tudo o que será lançado, eu defino um linter para descarregar, que avalia tudo de acordo com as regras especificadas.
Por exemplo, uma das regras diz que, para qualquer aplicativo no cluster Kubernetes, o número de réplicas deve ser pelo menos 2.
Se não houver réplicas (o padrão é 1), existem 0 ou 1, o kube-lint proíbe a implantação no cluster para evitar problemas futuros.
Digamos que a implantação por design foi projetada para que haja apenas uma réplica. Nesse caso, há um orçamento de interrupção do pod, em que max_unavailable e min_available são definidos para um aplicativo em execução no Kubernetes. Se você quiser sempre ter pelo menos 1 réplica, defina min_available = 1.
Havia duas réplicas, a implantação começou, uma réplica morreu, e uma permaneceu 1. Na máquina em que a réplica vive, o administrador inicia o nó de drenagem kubectl. Em teoria, o Kubernetes deve começar a remover essa réplica ativa e transportá-la para outro nó. Mas o orçamento de interrupção do pod funciona. O Kubernetes diz ao administrador: desculpe, a réplica mora aqui. Se a excluirmos, violaremos o orçamento de interrupção do pod. O nó de drenagem inteligente trava antes que o tempo limite expire e tenta desviar o nó. Se a implantação estiver concluída e as duas réplicas estiverem disponíveis, a réplica neste nó será exibida.
No MegaSlerme, mostrarei um conjunto completo de regras que me permitem tomar café em um café enquanto o cluster Kubernetes é atualizado com uma reinicialização de todos os nós.
Meus tópicos sobre Slurm :
- Apresentando o Kubernetes, principais componentes
- Dispositivo de cluster, componentes principais, tolerância a falhas, rede k8s
- Abstrações avançadas do Kubernetes
- Registro e Monitoramento
Meus tópicos no MegaSlerme :
- Processo interno do cluster de failover
- Autorização de cluster usando um provedor externo
- Aplicativos seguros e altamente disponíveis no cluster
- Implementando estratégias de implantação diferentes de RollingUpdate
- Solução de problemas em Kubernetes