Despois presentamos o seu irmán maior - . Este é un proxecto de código aberto que se usa para instalar compoñentes do sistema nun clúster de Kubernetes, que se poden chamar complementos.
Por que algunha adición?
Non é ningún segredo que Kubernetes non é un produto todo-en-un preparado e que serán necesarias varias adicións para construír un clúster "adulto". Addon-operator axudarache a instalar, configurar e manter estes complementos actualizados.
A necesidade de compoñentes adicionais no clúster descríbese en compañeiros . En resumo, a situación de Kubernetes neste momento é tal que para unha instalación simple de "xogar" podes saír cos compoñentes fóra da caixa, para desenvolvedores e probas podes engadir Ingress, pero para unha instalación completa, sobre o que podes dicir "a túa produción está lista", debes engadir cunha ducia de complementos diferentes: algo para supervisar, algo para rexistrar, non esquezas a entrada e o xestor de certificados, selecciona grupos de nodos, engade políticas de rede, tempada con axustes de escalado automático sysctl e pod...
Cales son as particularidades de traballar con eles?
Como mostra a práctica, o asunto non se limita a unha instalación. Para traballar comodamente co clúster, os complementos terán que actualizarse, desactivarse (eliminarse do clúster) e quererá probar algúns antes de instalalos no clúster de produción.
Entón, quizais Ansible sexa suficiente aquí? Pode ser. Pero En xeral, os complementos completos non viven sen configuración. Estas configuracións poden diferir dependendo da variante do clúster (aws, gce, azure, bare-metal, do, ...). Algunhas opcións de configuración non se poden especificar de antemán; deben obterse do clúster. E o clúster non é estático: para algunhas configuracións terás que supervisar os cambios. E aquí xa falta Ansible: necesitas un programa que viva nun clúster, é dicir. Operador Kubernetes.
Os que o probaron no traballo , dirán que as tarefas de instalación e actualización de complementos e configuracións de seguimento poden resolverse completamente usando para o operador de shell. Podes escribir un guión que fará un condicional kubectl apply e supervisar, por exemplo, ConfigMap, onde se almacenarán os axustes. Isto é aproximadamente o que se implementa no addon-operator.
Como está organizado isto no add-operator?
Ao crear unha nova solución, partimos dos seguintes principios:
- O instalador do complemento debe ser compatible configuración de modelos e declaración. Non creamos scripts máxicos que instalen complementos. O operador de complementos usa Helm para instalar complementos. Para instalar, cómpre crear un gráfico e seleccionar os valores que se usarán para a configuración.
- As configuracións poden ser xerar na instalación, eles poden obter do clústerOu recibir actualizacións, seguimento dos recursos do clúster. Estas operacións pódense implementar mediante ganchos.
- As configuracións poden ser almacenar nun clúster. Para almacenar a configuración no clúster, créase un ConfigMap/addon-operator e o Addon-operator supervisa os cambios neste ConfigMap. O operador de complementos dá aos ganchos acceso á configuración mediante convencións sinxelas.
- A adición depende da configuración. Se a configuración cambiou, o operador do complemento lanza o gráfico Helm con novos valores. Chamamos a combinación do gráfico Helm, os valores para el e os ganchos dun módulo (consulta a continuación para obter máis detalles).
- Escenificación. Non hai scripts de lanzamento máxico. O mecanismo de actualización é semellante a unha aplicación normal: recolle complementos e operadores de complementos nunha imaxe, etiquetaos e desenrola.
- Control de resultados. O operador de complementos pode proporcionar métricas para Prometheus.
Que é o recheo no addon-operator?
Unha adición pódese considerar calquera cousa que engade novas funcións ao clúster. Por exemplo, instalar Ingress é un excelente exemplo de complemento. Este pode ser calquera operador ou controlador co seu propio CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. Ou algo pequeno, pero máis fácil de usar, por exemplo, a copiadora secreta, que copia os segredos do rexistro a novos espazos de nomes, ou o sintonizador sysctl, que configura os parámetros sysctl en novos nodos.
Para implementar complementos, Addon-operator proporciona varios conceptos:
- Gráfico de timón usado para instalar varios programas no clúster, por exemplo, Prometheus, Grafana, nginx-ingress. Se o compoñente necesario ten un gráfico Helm, instalalo usando Addon-operator será moi sinxelo.
- Almacenamento de valores. Os gráficos Helm adoitan ter moitas opcións diferentes que poden cambiar co paso do tempo. O operador de complementos admite o almacenamento destas configuracións e pode supervisar os seus cambios para reinstalar o gráfico Helm con novos valores.
- Ganchos son ficheiros executables que o operador de complementos executa en eventos e que acceden á tenda de valores. O gancho pode supervisar os cambios no clúster e actualizar os valores na tenda de valores. Eses. Usando ganchos, pode facer descubrimento para recoller valores do clúster ao inicio ou segundo unha programación, ou pode facer descubrimento continuo, recollendo valores do clúster en función dos cambios no clúster.
- Módulo é unha combinación dun gráfico Helm, unha tenda de valores e ganchos. Os módulos pódense activar ou desactivar. Desactivar un módulo significa eliminar todas as versións de gráficos Helm. Os módulos poden activarse de forma dinámica, por exemplo, se todos os módulos que necesita están habilitados ou se o descubrimento atopou os parámetros necesarios nos ganchos; isto faise mediante un script auxiliar habilitado.
- Ganchos globais. Estes son ganchos "por si mesmos", non están incluídos nos módulos e teñen acceso a unha tenda de valores global, cuxos valores están dispoñibles para todos os ganchos dos módulos.
Como funcionan estas pezas xuntas? Vexamos a imaxe da documentación:
Hai dous escenarios de traballo:
- O gancho global desenvólvese por un evento, por exemplo, cando cambia un recurso do clúster. Este gancho procesa os cambios e escribe os novos valores na tenda de valores globais. O operador de complementos observa que o almacenamento global cambiou e inicia todos os módulos. Cada módulo, usando os seus ganchos, determina se é necesario activalo e actualiza a súa tenda de valores. Se o módulo está activado, o operador de complementos inicia a instalación do gráfico Helm. Neste caso, o gráfico Helm ten acceso aos valores do almacenamento do módulo e do almacenamento global.
- O segundo escenario é máis sinxelo: un enganche de módulo é desencadeado por un evento e cambia os valores na tenda de valores do módulo. O operador de complementos nota isto e inicia o gráfico Helm con valores actualizados.
A adición pódese implementar como un único gancho, ou como un gráfico Helm ou mesmo como varios módulos dependentes - isto depende da complexidade do compoñente que se instala no clúster e do nivel desexado de flexibilidade de configuración. Por exemplo, no repositorio () hai un complemento sysctl-tuner, que se implementa tanto como un módulo sinxelo cun gancho e un gráfico Helm, como mediante a tenda de valores, o que permite engadir configuracións editando ConfigMap.
Entrega de actualizacións
Algunhas palabras sobre a organización das actualizacións de compoñentes que instala o Addon-operator.
Para executar Addon-operator nun clúster, necesitas construír unha imaxe con engadidos en forma de ficheiros de gráficos de gancho e Helm, engade un ficheiro binario addon-operator e todo o que necesitas para ganchos: bash, kubectl, jq, python etc. A continuación, esta imaxe pódese lanzar ao clúster como unha aplicación normal, e moi probablemente quererá organizar un ou outro esquema de etiquetado. Se hai poucos clústeres, pode ser axeitado o mesmo enfoque que coas aplicacións: nova versión, nova versión, vai a todos os clústeres e corrixe a imaxe dos Pods. Non obstante, no caso dun lanzamento a un número importante de clústeres, o concepto de autoactualización desde unha canle era máis axeitado para nós.
Así é como o facemos:
- Unha canle é esencialmente un identificador que se pode configurar en calquera cousa (por exemplo, dev/stage/ea/stable).
- O nome da canle é a etiqueta da imaxe. Cando necesites lanzar actualizacións a unha canle, recoméndase unha nova imaxe e etiquetárase co nome da canle.
- Cando aparece unha nova imaxe no rexistro, o Addon-operator reinicia e lánzase coa nova imaxe.
Esta non é unha boa práctica, como está escrito . Non se recomenda facelo, pero estamos a falar unha aplicación normal que vive no mesmo clúster. No caso de Addon-operator, unha aplicación é unha gran cantidade de Implementos espallados por clústeres, e a autoactualización axuda moito e facilita a vida.
As canles axudan e en probas: se hai un clúster auxiliar, podes configuralo na canle stage e incorporar actualizacións nel antes de lanzalo ás canles ea и stable. Se cun clúster na canle ea produciuse un erro, podes cambialo a stable, mentres se investiga o problema con este clúster. Se o clúster se retira do soporte activo, cambia á súa canle "conxelada", por exemplo, freeze-2019-03-20.
Ademais de actualizar os ganchos e os gráficos Helm, é posible que necesites actualización e compoñente de terceiros. Por exemplo, notaches un erro no exportador de nodos condicionais e mesmo descubriches como parchealo. A continuación, abriches o PR e estás á espera de que a nova versión pase por todos os clústeres e aumente a versión da imaxe. Para non esperar indefinidamente, podes crear o teu exportador de nodos e cambiar a el antes de aceptar o PR.
En xeral, isto pódese facer sen Addon-operator, pero con Addon-operator o módulo para instalar node-exporter estará visible nun repositorio, o Dockerfile para construír a súa imaxe pódese manter alí mesmo, faise máis doado para todos os participantes en o proceso para comprender o que sucede... E se hai varios clústeres, faise máis fácil probar o teu PR e lanzar unha nova versión!
Esta organización de actualización de compoñentes funciona con éxito para nós, pero pódese implementar calquera outro esquema axeitado, despois de todo neste caso Addon-operator é un ficheiro binario simple.
Conclusión
Os principios implementados en Addon-operator permítenche construír un proceso transparente para crear, probar, instalar e actualizar complementos nun clúster, semellante aos procesos de desenvolvemento das aplicacións habituais.
Os complementos para Addon-operator en formato de módulo (Helm chart + hooks) pódense poñer a disposición do público. Nós, a empresa Flant, pensamos publicar os nosos desenvolvementos en forma de incorporacións deste tipo durante o verán. Únete ao desenvolvemento en GitHub (, ), tenta facer a túa propia adición baseada en и , agarda novidades en Habré e no noso !
PS
Lea tamén no noso blog:
- «»;
- «».
Fonte: www.habr.com