Seguindo o
operador de shell, apresentamos seu irmão mais velho -
addon-operator . Este é um projeto de código aberto usado para instalar componentes do sistema no cluster Kubernetes, que pode ser chamado de uma palavra comum - complementos.
Por que alguma adição?
Não é segredo que o Kubernetes não é um produto final completo, e serão necessárias várias adições para criar um cluster "adulto". O operador addon ajudará a instalar, configurar e manter esses complementos atualizados.
A necessidade de componentes adicionais no cluster é divulgada em um
relatório dos colegas
driusha . Resumindo, a situação com o Kubernetes no momento é que, para uma instalação simples, você pode "brincar" com os componentes prontos para uso, para desenvolvedores e testes você pode adicionar o Ingress, mas para uma instalação completa, que você pode dizer "sua produção está pronta", você precisa adicionar uma dúzia de complementos diferentes: algo para monitoramento, algo para logs, não se esqueça de ingresso e gerente de certificação, selecione grupos de hosts, adicione políticas de rede, tempere com as configurações sysctl e pod autoscaler ...
Quais são as especificidades de trabalhar com eles?
Como mostra a prática, o caso não se limita a uma instalação. Para um trabalho confortável com o cluster, os complementos precisarão ser atualizados, desativados (excluídos do cluster) e você desejará testar algo antes de instalá-lo no cluster de produção.
Então, talvez Ansible seja suficiente aqui? Possivelmente. Mas
adições completas no caso geral não vivem sem configurações . Essas configurações podem variar dependendo da opção de cluster (aws, gce, azure, bare-metal, do, ...). Algumas configurações não podem ser definidas com antecedência - elas devem ser obtidas no cluster. E o cluster não é estático: para algumas configurações, você precisará seguir as alterações. E aqui o Ansible já está ausente: precisamos de um programa que viva em um cluster, ou seja, Operador Kubernetes.
Aqueles que experimentaram o
operador de shell em operação dirão que as tarefas de instalação e atualização de complementos e configurações de rastreamento podem ser completamente resolvidas com a ajuda de
ganchos para o operador de shell. Você pode escrever um script que faça com que o
kubectl apply e monitore condicionalmente, por exemplo, ConfigMap, onde as configurações serão armazenadas. Isso é aproximadamente o que é implementado no addon-operator.
Como isso é organizado no addon-operator?
Criando uma nova solução, partimos dos seguintes princípios:
- O instalador do complemento deve suportar modelos e configuração declarativa . Não fazemos scripts mágicos que instalam complementos. O operador de complemento usa o Helm para instalar complementos. Para instalar, você precisa criar um gráfico e destacar os valores que serão usados para configurar.
- As configurações podem ser geradas durante a instalação , podem ser obtidas no cluster ou receber atualizações monitorando os recursos do cluster. Essas operações podem ser implementadas usando ganchos.
- As configurações podem ser armazenadas em um cluster . Para armazenar as configurações no cluster, um operador ConfigMap / addon é criado e o operador Addon monitora as alterações deste 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 lança o Helm-chart com novos valores. A união do gráfico Helm, os valores para ele e os ganchos que chamamos de módulo (veja abaixo para mais detalhes).
- Estadiamento . Nenhum script de lançamento mágico. O mecanismo de atualização é semelhante a um aplicativo comum - colete complementos e operador de complemento em uma imagem, teste e implante.
- Controle do resultado . O operador addon pode fornecer métricas para o Prometheus.
Qual é o addon no addon-operator?
Uma adição pode ser considerada tudo o que adiciona novas funções ao cluster. Por exemplo, a instalação do 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 simplificando a operação - por exemplo, copiadora secreta, copiando segredos do registro para novos espaços para nome ou sintonizador sysctl, configurando parâmetros sysctl em novos nós.
O operador Addon fornece vários conceitos para implementar complementos:
- O gráfico Helm é usado para instalar vários softwares no cluster - por exemplo, Prometheus, Grafana, nginx-ingress. Se o componente necessário tiver um gráfico Helm, a instalação usando o operador Addon será muito simples.
- Armazenamento de valores . Os gráficos de capacete geralmente têm muitas configurações diferentes que podem mudar com o tempo. O operador addon suporta o armazenamento dessas configurações e é capaz de monitorar suas alterações para redefinir o Helm-chart com novos valores.
- Hooks 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 valores no armazenamento de valores. I.e. com a ajuda de ganchos, você pode fazer a descoberta para coletar valores do cluster na inicialização ou de acordo com um planejamento ou descoberta contínua, coletando valores do cluster por alterações no cluster.
- Um módulo é uma união de um gráfico Helm, valoriza armazenamento e ganchos. Os módulos podem ser ligados e desligados. Desabilitar um módulo é a remoção de todas as liberações do gráfico Helm. Os módulos podem se ativar dinamicamente, por exemplo, se todos os módulos de que ele precisa estão incluídos ou se a descoberta encontrou os parâmetros necessários em ganchos - isso é feito usando um script auxiliar ativado.
- Ganchos globais Estes são ganchos "por conta própria", não estão incluídos nos módulos e têm acesso ao armazenamento de valores globais, cujos valores estão disponíveis para todos os ganchos nos módulos.
Como essas peças funcionam juntas? Considere a figura da documentação:
Dois cenários de trabalho:
- Um gancho global é acionado por um evento - por exemplo, quando um recurso em um cluster é alterado. Esse gancho processa as alterações e grava os novos valores no armazenamento de valores globais. O operador de complemento percebe que o armazenamento global foi alterado e inicia todos os módulos. Cada módulo, usando seus ganchos, determina se precisa ser ativado e atualiza seu armazenamento de valores. Se o módulo estiver ativado, o operador Addon inicia a instalação do Helm-chart. Nesse caso, os valores do armazenamento do módulo e do armazenamento global estão acessíveis no Helm-chart.
- O segundo cenário é mais simples: um gancho do módulo é acionado por um evento, altera os valores no armazenamento de valores do módulo. O operador addon percebe isso e inicia o gráfico Helm com valores atualizados.
O complemento pode ser implementado como um único gancho ou como um Helm-chart, ou
mesmo como vários módulos dependentes - isso depende da complexidade do componente instalado no cluster e do nível desejado de flexibilidade de configuração. Por exemplo, no repositório (
/ examples ), há um complemento sysctl-tuner, que é implementado como um módulo simples com um gancho e um gráfico Helm, e usando o armazenamento de valores, o que possibilita adicionar configurações através da edição do ConfigMap.
Atualizar entrega
Algumas palavras sobre a organização das atualizações de componentes instaladas pelo operador de complemento.
Para executar o Addon-operator em um cluster, você precisa
coletar uma imagem com adições na forma de arquivos de gráfico de gancho e de leme, adicionar o arquivo binário de
addon-operator e tudo o que é necessário para ganchos:
bash ,
kubectl ,
jq ,
python , etc. Além disso, essa imagem pode ser lançada no cluster como um aplicativo regular e, provavelmente, você desejará organizar esse ou aquele esquema de marcação. Se houver poucos clusters, a mesma abordagem usada nos aplicativos pode ser adequada: uma nova versão, uma nova versão, atravessa todos os clusters e corrige a imagem dos Pods. No entanto, no caso de um lançamento para um número notável de clusters, o conceito de auto-renovação do canal era mais adequado para nós.
Organizamos assim:
- Um canal é essencialmente um identificador que pode ser definido por qualquer pessoa (por exemplo, dev / stage / ea / stable).
- O nome do canal é a tag da imagem. Quando você precisa implantar atualizações no canal, uma nova imagem é coletada e marcada com o nome do canal.
- Quando uma nova imagem aparece no registro, o operador Addon é reiniciado e inicia com a nova imagem.
Esta não é uma prática recomendada, conforme descrito na
documentação do
Kubernetes . Isso não é recomendado, mas estamos falando de um
aplicativo comum que vive em um cluster . No caso do operador Addon, um aplicativo é um monte de implantações espalhadas por clusters, e a atualização automática é muito útil e simplifica a vida útil.
Os canais ajudam
nos testes : se houver um cluster auxiliar, você poderá configurá-lo no canal do
stage e fazer as atualizações antes de implantar nos canais
ea e
stable . Se ocorrer um erro com o cluster no canal
ea , você poderá alterná-lo para
stable enquanto uma investigação do problema com esse cluster estiver em andamento. Se o cluster for retirado do suporte ativo, ele alterna para o canal "congelado" - por exemplo,
freeze-2019-03-20 .
Além de atualizar ganchos e gráficos de leme, pode ser necessário
atualizar um componente de terceiros . Por exemplo, você notou um erro no exportador de nó condicional e até descobriu como corrigi-lo. Em seguida, abrimos o PR e aguardamos um novo lançamento passar por todos os clusters e aumentar a versão da imagem. Para não esperar indefinidamente, você pode coletar seu nó-exportador e alternar para ele antes de aceitar o PR.
Em geral, isso pode ser feito sem o operador Addon, mas com o operador Addon, o módulo para a instalação do exportador de nó ficará visível em um repositório. Você pode manter o Dockerfile para criar sua imagem ali, fica mais fácil para todos os participantes do processo entender que acontece ... E se houver vários clusters, fica mais fácil testar seu PR e lançar uma nova versão!
Essa organização de atualizações de componentes funciona com êxito conosco, mas você pode implementar qualquer outro esquema adequado, pois
, neste caso, o operador Addon é um arquivo binário simples .
Conclusão
Os princípios implementados no operador Addon permitem criar um processo transparente de criação, teste, instalação e atualização de complementos em um cluster, semelhante aos processos de desenvolvimento de aplicativos comuns.
Os complementos para o operador Addon no formato de módulos (Helm-chart + hooks) podem ser carregados ao público. Nós, a empresa Flant, planejamos apresentar nossas realizações durante o verão na forma de tais adições. Participe do desenvolvimento no GitHub (
operador de shell, operador de addon ), tente fazer sua adição com base em
exemplos e
documentação , aguarde as notícias no Habré e em nosso
canal do YouTube !
ATUALIZADO (14 de junho) : Se você tiver colegas de língua inglesa que possam estar interessados no operador adicional, o anúncio correspondente estará disponível para eles em nosso blog no Medium .PS
Leia também em nosso blog: