Clever Geek Handbook

Fácil criação de operadores Kubernetes com shell-operator: progresso do projeto em um ano





Os operadores Kubernetes são um mecanismo conveniente para estender os recursos desta plataforma de contêineres, que conquistou, com razão, amplo reconhecimento entre o ambiente dos engenheiros de operações e seus simpatizantes. Conversamos sobre como eles estão organizados e funcionam no já distante 2017. E em abril do ano passado, apresentamos o projeto de operador de shell de código aberto , que simplificou bastante o processo de criação de operadores do Kubernetes.



Para isso, foi desenvolvida uma estrutura que permite executar scripts arbitrários (em Bash, Python, etc.) no caso de certos eventos ocorrerem no cluster K8s.



Nos últimos tempos, o operador de shell adquiriu sua base de usuários (veja detalhes no final do artigo) e, é claro, novos recursos. Por ocasião do recente lançamentov1.0.0-beta.11 (sobre o status beta, veja abaixo) , decidimos conversar sobre o que o projeto chegou durante a sua existência, desde o anúncio da primeira versão pública.



Sobre o dispositivo e a finalidade



Mas vamos começar com uma breve explicação de como o operador de shell funciona e por que, em princípio, pode ser necessário.



O operador de shell é executado no pod do cluster Kubernetes. É apresentado lá como:



  • Torne-se binário que assina eventos na API do K8s e lança ganchos (fornecendo detalhes sobre o que aconteceu);
  • um conjunto de ganchos, cada um dos quais é um script Bash, script Python ou qualquer outro arquivo executável.


Ganchos:



  • eles mesmos determinam quais eventos e para quais objetos precisam;
  • execute as ações necessárias no evento desses eventos que ocorrem nos K8s.


Portanto, o operador de shell é uma camada entre eventos na API Kubernetes e scripts para processá-los.



imagem



Por que o operador de shell foi criado? Os operadores são o padrão para "fazer a coisa certa" no Kubernetes, mas desenvolvê-los completamente (no Go usando o SDK apropriado ) não é fácil. A presença de uma estrutura tão simples como o operador de shell reduz significativamente o limite de entrada nessa área, permitindo a solução rápida e eficiente de pequenos problemas operacionais * dentro do cluster. E, igualmente importante, faça da maneira certa.



De que tarefas estamos falando? Exemplos prontos de uso do operador de shell podem ser encontrados no repositório do projeto . Em nós, na Flant, usamos como uma biblioteca(sim, isso também foi possível!) . Tornou-se a base para o addon-operator , que gerencia componentes adicionais no Kubernetes.



Nota : O anúncio deste projeto de código aberto (operador adicional) pode ser encontrado aqui . E no relatório " Expandindo e complementando Kubernetes ", falamos detalhadamente sobre as razões de sua aparência, o relacionamento com o operador de shell e os princípios de operação.



Agora, sobre as principais alterações introduzidas no operador de shell no ano passado.



Principais inovações



Nas primeiras versões do operador de shell, apenas um objeto estava disponível para o gancho - o associado ao evento do cluster. A evolução dos ganchos usados ​​no operador addon resultou na inscrição de um gancho em uma mudança de objeto, mas na chamada kubectlpara obter uma lista atualizada de outros objetos. Para remover chamadas desnecessárias kubectle, assim, acelerar o trabalho de ganchos, várias possibilidades foram implementadas para acessar as listas atuais de objetos:



  • Sincronização + modo Evento, quando o gancho no início recebe uma lista de objetos reais e, em seguida, trabalha com apenas um objeto. Este modo é ativado por padrão - podemos dizer que o resultado é um análogo do loop de reconciliação do operator-sdk.
  • snapshot', . (Snapshot’ Kubernetes, .)
  • snapshot'. , , , .
  • Também se tornou possível monitorar o recurso , mas não reagir a suas alterações, ou seja, "Acumular instantâneo". Por exemplo, um gancho pode reagir a alterações no CustomResource e ainda receber o objeto ConfigMap real sem chamada adicional kubectl. (Veja sinalizadores executeHookOnSynchronizatione para detalhes executeHookOnEvent.)


Outras inovações significativas:



  • Graças à transição para o uso do cliente Kubernetes dinâmico no operador de shell, tornou-se possível inscrever-se em qualquer kindtipo de recurso existente na API Kubernetes, incluindo Recursos Personalizados.
  • (. queue). endpoints.
  • .
  • « », namespace’ .
  • scraping' Prometheus'. .
  • , shell.




  • YAML- ( JSON).
  • JSON logrus (. LOG_TYPE ).
  • listen-address hostNetwork: true.
  • rate limit (qps, burst) Kubernetes API.
  • kube-server Kubernetes API.
  • .
  • jqFilter libjq-go, jq.
  • zombie reaper, SIGCHLD -, Bash-. — tini.
  • Várias simplificações foram implementadas para conectar o operador de shell como uma biblioteca.
  • Versão atualizada kubectl(de 1.13 a 1.17.4) e fez uma montagem baseada no alpine-3.11.


Status e planos



O projeto do operador de shell ainda está oficialmente em beta . Apesar disso, como observado acima, nós o usamos intensivamente como base para o addon-operator - uma ferramenta que é constantemente usada em muitos (100+) clusters K8s.



Para uma versão estável do operador de shell como um projeto público, planejamos (pelo menos):



  • adicione teste e2e ( # 63 ),
  • implementar a construção multi-arquitetural ( # 184 ),
  • atualize client-go para 0.18.0, implemente contexte, finalmente, lide com o cache de objetos no client-go ( # 188 ).


Reconhecimento comunitário



Ao longo dos anos, vimos um claro interesse da comunidade no operador de shell:





Também temos o prazer de anunciar que, na próxima conferência virtual KubeCon + CloudNativeCon Europe 2020 , que será realizada em agosto, haverá nosso relatório sobre o operador de shell. Os detalhes estão no site do evento .



Obrigado pelo seu interesse no operador de shell! Se você tiver alguma dúvida, faça-a aqui nos comentários ou no @kubeoperator do canal tg-channel .



PS



Leia também no nosso blog:





More articles:


All Articles