Seguindo apresentamos seu irmão mais velho — . É um projeto Open Source usado para instalar componentes de sistema em clusters Kubernetes, que podem ser chamados genericamente de complementos.
Por que precisamos de complementos?
Não é segredo que o Kubernetes não é um produto tudo-em-um, e para construir um cluster 'maduro' serão necessários vários complementos. O addon-operator ajuda a instalar, configurar e manter esses complementos atualizados.
A necessidade de componentes adicionais em um cluster é abordada em colegas . Resumindo, a situação com Kubernetes atualmente é que para uma instalação simples 'para brincar', podemos nos contentar com os componentes padrão, para os desenvolvedores e testes podemos adicionar Ingress, mas para uma instalação completa, que podemos considerar 'seu ambiente de produção está pronto', é necessário adicionar uma dezena de complementos: algo para monitoramento, algo para logs, não esquecer do ingress e do cert-manager, alocar grupos de nós, adicionar políticas de rede, temperar com configurações de sysctl e pod autoscaler...
Qual é a especificidade ao trabalhar com eles?
Como a prática mostra, uma simples instalação não é suficiente. Para um funcionamento confortável do cluster, os complementos precisarão ser atualizados, desativados (removidos do cluster), e algo pode precisar ser testado antes da instalação no cluster de produção.
Então, talvez só o Ansible seja suficiente aqui? Talvez. Mas complementos completos geralmente não funcionam 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 definidas antecipadamente — elas precisam ser obtidas do cluster. E o cluster não é estático: para algumas configurações, será necessário acompanhar as mudanças. E aqui o Ansible já não é suficiente: é necessário um programa que viva no cluster, ou seja, um Kubernetes Operator.
Aqueles que tentaram na prática , dirão que as tarefas de instalação e atualização de complementos e a supervisão das configurações podem ser perfeitamente resolvidas com para shell-operator. É possível escrever um script que fará um suposto kubectl apply e monitorar, por exemplo, o ConfigMap, onde as configurações serão armazenadas. Isso é basicamente o que foi implementado no addon-operator.
Como isso é organizado no addon-operator?
Ao criar uma nova solução, partimos dos seguintes princípios:
- O instalador de complementos deve suportar a template e a configuração declarativa. Não fazemos scripts mágicos que instalam complementos. O Addon-operator utiliza Helm para a instalação de complementos. Para a instalação, é necessário criar um chart e destacar os values que serão utilizados para a configuração.
- As configurações podem ser geradas durante a instalação, elas podem ser obtidas do cluster, ou receber atualizações, monitorando os recursos do cluster. Essas operações podem ser implementadas com o uso de hooks.
- As configurações podem armazenar no cluster. Para armazenar as configurações no cluster, cria-se um ConfigMap/addon-operator e o Addon-operator monitora as alterações desse ConfigMap. O Addon-operator fornece aos hooks acesso às configurações por meio de acordos simples.
- O complemento depende das configurações. Se as configurações mudarem, o Addon-operator publica o chart do Helm com novos values. A combinação do chart do Helm, dos values para ele e dos hooks chamamos de módulo (mais detalhes abaixo).
- Stageamento. Não há scripts mágicos de release. O mecanismo de atualizações é análogo ao de um aplicativo comum — agrupar complementos e o addon-operator em uma imagem, taguear e implantar.
- Controle de resultado. O Addon-operator é capaz de fornecer métricas para o Prometheus.
O que é um complemento no addon-operator?
Um complemento pode ser considerado qualquer coisa que adicione novas funcionalidades ao cluster. Por exemplo, a instalação do Ingress é um excelente exemplo de complemento. Isso pode ser qualquer operador ou controlador com seu próprio CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. Ou algo pequeno, mas que simplifica a operação — por exemplo, um copiados de secrets, que copia secrets de registry para novos namespaces, ou um afinador de sysctl, que ajusta parâmetros sysctl em novos nós.
Para implementar complementos, o Addon-operator oferece várias conceitos:
- Chart Helm é utilizado para instalar diferentes softwares no cluster — por exemplo, Prometheus, Grafana, nginx-ingress. Se o componente necessário possui um Helm-chart, será muito simples instalá-lo com o Addon-operator.
- Armazenamento de values. Os Helm-charts geralmente têm muitas configurações diferentes, que podem mudar ao longo do tempo. O Addon-operator suporta o armazenamento dessas configurações e é capaz de monitorar suas alterações para reinstalar o Helm-chart com novos valores.
- Hooks — são arquivos executáveis que o Addon-operator inicia em resposta a eventos e que têm acesso ao armazenamento de valores. O hook pode monitorar mudanças no cluster e atualizar os valores no armazenamento de valores. Ou seja, com os hooks é possível realizar a descoberta, coletando valores do cluster na inicialização ou de acordo com um cronograma, ou fazer uma descoberta contínua, coletando valores do cluster em resposta a mudanças no cluster.
- Módulo — é a combinação de um gráfico Helm, um armazenamento de valores e hooks. Módulos podem ser habilitados ou desabilitados. Desabilitar um módulo significa remover todas as versões do gráfico Helm. Os módulos podem se incluir dinamicamente, por exemplo, se todos os módulos necessários estiverem habilitados ou se a descoberta nos hooks encontrar os parâmetros necessários — isso é feito com um script auxiliar denominado enabled.
- Hooks Globais. Estes são hooks "por conta própria", não estão incluídos em módulos e têm acesso ao armazenamento global de valores, cujos valores estão disponíveis para todos os hooks nos módulos.
Como essas partes funcionam juntas? Vamos considerar a imagem da documentação:
Existem dois cenários de funcionamento:
- Um hook global é acionado por um evento — por exemplo, ao alterar um recurso no cluster. Este hook processa as alterações e grava novos valores no armazenamento global de valores. O Addon-operator detecta que o armazenamento global foi alterado e inicia todos os módulos. Cada módulo, por meio de seus hooks, determina se deve ser habilitado e atualiza seu próprio armazenamento de valores. Se o módulo estiver habilitado, o Addon-operator inicia a instalação do gráfico Helm. O gráfico Helm tem acesso aos valores do armazenamento do módulo e do armazenamento global.
- O segundo cenário é mais simples: um hook de módulo é acionado por um evento, altera os valores no armazenamento de valores do módulo. O Addon-operator percebe isso e inicia o gráfico Helm com os valores atualizados.
Um complemento pode ser implementado como um único hook ou como um gráfico Helm, ou até mesmo como vários módulos dependentes — isso depende da complexidade do componente a ser instalado no cluster e do nível necessário de flexibilidade nas configurações. Por exemplo, no repositório () há um complemento sysctl-tuner, que é implementado tanto como um simples módulo com hook e gráfico Helm, quanto com o uso de armazenamento de valores, o que permite adicionar configurações através da edição do ConfigMap.
Entrega de atualizações
Algumas palavras sobre a organização das atualizações dos componentes que o Addon-operator instala.
Para rodar o Addon-operator em um cluster, é necessário compilar uma imagem com as extensões na forma de arquivos de gancho e gráficos Helm, adicionar o arquivo binário addon-operator e tudo que for necessário para os ganchos: bash, kubectl, jq, python e assim por diante. Depois, essa imagem pode ser implantada no cluster como um aplicativo normal e provavelmente você vai querer organizar algum tipo de esquema de versionamento. Se houver poucos clusters, o mesmo método usado para aplicativos pode funcionar: nova versão, nova tag, ir por todos os clusters e corrigir a imagem nos Pod’s. No entanto, ao implantar em um número significativo de clusters, a ideia de autoatualização através do canal se torna mais apropriada.
Nós configuramos assim:
- O canal é essencialmente um identificador que pode ser definido de qualquer forma (por exemplo, dev/stage/ea/stable).
- O nome do canal é a tag da imagem. Quando é necessário implantar atualizações no canal, uma nova imagem é compilada e tagueada com o nome do canal.
- Quando uma nova imagem aparece no registro, o Addon-operator é reiniciado e iniciado com a nova imagem.
Isso não é uma boa prática, como mencionado em . Isso não é recomendado, mas estamos falando sobre um aplicativo normal que vive em um único cluster. No caso do Addon-operator, o aplicativo é um conjunto de Deployments espalhados pelos clusters, e a autoatualização ajuda bastante e simplifica a vida.
Os canais ajudam também nos testes: se houver um cluster auxiliar, ele pode ser configurado para o canal stage e implantar atualizações nele antes de lançar nos canais ea e stable. Se ocorrer um erro com o cluster no canal ea , ele pode ser alternado para stable, enquanto a investigação do problema com esse cluster está em andamento. Se o cluster estiver fora de suporte ativo, ele é alternado para seu canal "congelado" — por exemplo, freeze-2019-03-20.
Além das atualizações de ganchos e gráficos Helm, pode ser necessário atualizar também um componente de terceiros. Por exemplo, se você notar um erro no node-exporter e até mesmo pensar em como corrigí-lo. Em seguida, você abre um PR e aguarda a nova versão para passar por todos os clusters e aumentar a versão da imagem. Para não esperar um tempo indeterminado, você pode compilar seu próprio node-exporter e alternar para ele até que o PR seja aceito.
Na verdade, 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 único repositório, o Dockerfile para construir sua própria imagem pode ser mantido aqui, e todos os participantes do processo ficam mais fáceis de entender o que está acontecendo... E se houver vários clusters, torna-se mais fácil tanto testar seu PR quanto aplicar uma nova versão!
Esta organização de atualização de componentes funciona com sucesso para nós, mas é possível implementar qualquer outro esquema adequado — afinal, neste caso, o Addon-operator é um simples arquivo binário..
Conclusão
Os princípios implementados no Addon-operator permitem estabelecer um processo transparente de criação, teste, instalação e atualização de complementos no cluster, semelhante aos processos de desenvolvimento de aplicativos normais.
Complementos para o Addon-operator no formato de módulos (Helm-chart + hooks) podem ser disponibilizados ao público. Nós, da empresa Flant, planejamos disponibilizar durante o verão nossas criações na forma desses complementos. Junte-se ao desenvolvimento no GitHub (, ), tente criar seu próprio complemento com base em e , aguarde novidades no Habr e no nosso !
P.S.
Confira também em nosso blog:
- «»;
- «».
Fonte: habr.com
