Seguindo o apresentamos seu irmão mais velho - . Este é um projeto de código aberto usado para instalar componentes do sistema em um cluster Kubernetes, que podem ser chamados de complementos.
Por que quaisquer acréscimos?
Não é nenhum segredo que o Kubernetes não é um produto multifuncional pronto e, para construir um cluster “adulto”, você precisará de vários acréscimos. O operador de complementos ajudará você a instalar, configurar e manter esses complementos atualizados.
A necessidade de componentes adicionais no cluster é divulgada em colegas . Resumindo, a situação com o Kubernetes no momento é tal que para uma instalação simples de “brincadeira” você pode conviver com os componentes prontos para uso, para desenvolvedores e testes você pode adicionar o Ingress, mas para uma instalação completa, sobre a qual você pode dizer “sua produção está pronta”, você precisa adicionar uma dúzia de complementos diferentes: algo para monitoramento, algo para registro, não se esqueça do ingresso e do gerenciador de certificados, selecione grupos de nós, adicione políticas de rede, temporada com configurações de sysctl e pod autoscaler ...
Quais são as especificidades de trabalhar com eles?
Como mostra a prática, o assunto não se limita a uma instalação. Para trabalhar confortavelmente com o cluster, os complementos precisarão ser atualizados, desabilitados (removidos do cluster) e você desejará testar alguns antes de instalá-los no cluster de produção.
Então, talvez Ansible seja suficiente aqui? Talvez. Mas Em geral, complementos completos não vivem sem configurações. Essas configurações podem diferir dependendo da variante do cluster (aws, gce, azure, bare-metal, do, ...). Algumas configurações não podem ser especificadas antecipadamente; elas devem ser obtidas no cluster. E o cluster não é estático: para algumas configurações você terá que monitorar as alterações. E aqui já falta o Ansible: você precisa de um programa que viva em um cluster, ou seja, Operador Kubernetes.
Aqueles que tentaram no trabalho , eles dirão que as tarefas de instalação e atualização de complementos e configurações de monitoramento podem ser completamente resolvidas usando para operador shell. Você pode escrever um script que fará uma condicional kubectl apply e monitorar, por exemplo, o ConfigMap, onde as configurações serão armazenadas. Isso é aproximadamente o que é implementado no operador addon.
Como isso é organizado no operador addon?
Ao criar uma nova solução, partimos dos seguintes princípios:
- O instalador do complemento deve oferecer suporte modelagem e configuração declarativa. Não criamos scripts mágicos que instalam complementos. O operador de complementos usa Helm para instalar complementos. Para instalar, é necessário criar um gráfico e selecionar os valores que serão utilizados para configuração.
- As configurações podem ser gerar na instalação, eles podem obter do clusterOu receber atualizações, monitorando os recursos do cluster. Essas operações podem ser implementadas usando ganchos.
- As configurações podem ser armazenar em um cluster. Para armazenar configurações no cluster, um ConfigMap/addon-operator é criado e o Addon-operator monitora as alterações neste ConfigMap. O operador Addon dá aos ganchos acesso às configurações usando convenções simples.
- A adição depende das configurações. Se as configurações foram alteradas, o operador Addon implementa o gráfico Helm com novos valores. Chamamos a combinação do gráfico Helm, valores para ele e conectamos um módulo (veja abaixo para mais detalhes).
- Encenação. Não existem scripts mágicos de lançamento. O mecanismo de atualização é semelhante a um aplicativo normal: colete complementos e operadores de complementos em uma imagem, marque-os e implemente-os.
- Controle de resultado. O operador Addon pode fornecer métricas para o Prometheus.
O que é preenchimento no operador addon?
Uma adição pode ser considerada qualquer coisa que adicione novas funções ao cluster. Por exemplo, instalar o Ingress é um ótimo exemplo de complemento. Pode ser qualquer operador ou controlador com seu próprio CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. Ou algo pequeno, mas mais fácil de usar - por exemplo, copiadora secreta, que copia segredos de registro para novos namespaces, ou sintonizador sysctl, que configura parâmetros sysctl em novos nós.
Para implementar complementos, o operador Addon fornece vários conceitos:
- Gráfico do leme usado para instalar vários softwares no cluster - por exemplo, Prometheus, Grafana, nginx-ingress. Se o componente necessário tiver um gráfico Helm, instalá-lo usando o operador Addon será muito simples.
- Armazenamento de valores. Os gráficos do Helm geralmente têm muitas configurações diferentes que podem mudar com o tempo. O operador addon suporta o armazenamento dessas configurações e pode monitorar suas alterações para reinstalar o gráfico Helm com novos valores.
- Ganchos são arquivos executáveis que o operador Addon executa em eventos e que acessam o armazenamento de valores. O gancho pode monitorar alterações no cluster e atualizar os valores no armazenamento de valores. Aqueles. Usando ganchos, você pode fazer descobertas para coletar valores do cluster na inicialização ou de acordo com um cronograma, ou pode fazer descobertas contínuas, coletando valores do cluster com base nas alterações no cluster.
- Módulo é uma combinação de um gráfico Helm, um armazenamento de valores e ganchos. Os módulos podem ser habilitados ou desabilitados. Desabilitar um módulo significa excluir todas as versões do gráfico Helm. Os módulos podem ser habilitados dinamicamente, por exemplo, se todos os módulos necessários estiverem habilitados ou se a descoberta tiver encontrado os parâmetros necessários nos ganchos - isso é feito usando um script auxiliar habilitado.
- Ganchos globais. Estes são ganchos “por conta própria”, não estão incluídos nos módulos e têm acesso a um armazenamento de valores globais, cujos valores estão disponíveis para todos os ganchos nos módulos.
Como essas partes funcionam juntas? Vejamos a imagem da documentação:
Existem dois cenários de trabalho:
- O gancho global é acionado por um evento – por exemplo, quando um recurso no cluster é alterado. Este gancho processa as alterações e grava os novos valores no armazenamento de valores globais. O operador addon percebe que o armazenamento global mudou e inicia todos os módulos. Cada módulo, usando seus ganchos, determina se precisa ser habilitado e atualiza seu armazenamento de valores. Se o módulo estiver habilitado, o operador Addon inicia a instalação do gráfico Helm. Neste caso, o gráfico Helm tem acesso aos valores do armazenamento do módulo e do armazenamento global.
- O segundo cenário é mais simples: um gancho de módulo é acionado por um evento e altera valores no armazenamento de valores do módulo. O operador Addon percebe isso e inicia o gráfico Helm com valores atualizados.
A adição pode ser implementada como um único gancho, ou como um gráfico Helm, ou mesmo que vários módulos dependentes - isto depende da complexidade do componente que está sendo instalado no cluster e do nível desejado de flexibilidade de configuração. Por exemplo, no repositório () existe um complemento sysctl-tuner, que é implementado tanto como um módulo simples com um gancho e um gráfico Helm, quanto usando o armazenamento de valores, que permite adicionar configurações editando o ConfigMap.
Entrega de atualizações
Algumas palavras sobre como organizar atualizações de componentes instaladas pelo operador Addon.
Para executar o operador Addon em um cluster, você precisa construir uma imagem com acréscimos na forma de arquivos de gráfico hook e Helm, adicione um arquivo binário addon-operator e tudo que você precisa para ganchos: bash, kubectl, jq, python etc. Em seguida, essa imagem pode ser implementada no cluster como um aplicativo normal e, provavelmente, você desejará organizar um ou outro esquema de marcação. Se houver poucos clusters, a mesma abordagem dos aplicativos pode ser adequada: novo lançamento, nova versão, vá para todos os clusters e corrija a imagem dos Pods. Porém, no caso de uma implementação para um número significativo de clusters, o conceito de autoatualização a partir de um canal foi mais adequado para nós.
Veja como fazemos isso:
- Um canal é essencialmente um identificador que pode ser definido como qualquer coisa (por exemplo, dev/stage/ea/stable).
- O nome do canal é a tag da imagem. Quando você precisa lançar atualizações em um canal, uma nova imagem é montada e marcada com o nome do canal.
- Quando uma nova imagem aparece no registro, o operador Addon é reiniciado e iniciado com a nova imagem.
Esta não é a melhor prática, conforme escrito em . Não é recomendado fazer isso, mas estamos falando de um aplicativo normal que reside no mesmo cluster. No caso do operador Addon, uma aplicação é composta por vários Deployments espalhados por clusters, e a autoatualização ajuda muito e facilita a vida.
Canais ajudam e em testes: se houver um cluster auxiliar, você pode configurá-lo para o canal stage e lançar atualizações nele antes de implementá-lo nos canais ea и stable. Se estiver com um cluster no canal ea ocorreu um erro, você pode alterá-lo para stable, enquanto o problema com este cluster está sendo investigado. Se o cluster for retirado do suporte ativo, ele mudará para seu canal "congelado" - por exemplo, freeze-2019-03-20.
Além de atualizar ganchos e gráficos do Helm, você pode precisar atualização e componente de terceiros. Por exemplo, você notou um bug no exportador de nó condicional e até descobriu como corrigi-lo. A seguir, você abriu o PR e está aguardando o novo lançamento para passar por todos os clusters e aumentar a versão da imagem. Para não esperar indefinidamente, você pode construir seu exportador de nós e mudar para ele antes de aceitar o PR.
Em geral, isso pode ser feito sem o Addon-operator, mas com o Addon-operator o módulo para instalação do node-exporter ficará visível em um repositório, o Dockerfile para construir sua imagem pode ser mantido ali mesmo, fica mais fácil para todos os participantes em o processo para entender o que acontece... E se houver vários clusters, fica mais fácil testar seu PR e lançar uma nova versão!
Esta organização de atualização de componentes funciona com sucesso para nós, mas qualquer outro esquema adequado pode ser implementado - afinal neste caso, o operador Addon é um arquivo binário simples.
Conclusão
Os princípios implementados no Addon-operator permitem construir um processo transparente para criar, testar, instalar e atualizar add-ons em um cluster, semelhante aos processos de desenvolvimento de aplicativos regulares.
Complementos para o operador Addon em formato de módulo (gráfico Helm + ganchos) podem ser disponibilizados publicamente. Nós, a empresa Flant, planejamos publicar nossos desenvolvimentos na forma de tais acréscimos durante o verão. Participe do desenvolvimento no GitHub (, ), tente fazer sua própria adição com base em и , aguarde novidades no Habré e no nosso !
PS
Leia também em nosso blog:
- «";
- «".
Fonte: habr.com