Després presentem el seu germà gran - . Aquest és un projecte de codi obert que s'utilitza per instal·lar components del sistema en un clúster de Kubernetes, que es poden anomenar complements.
Per què cap addició?
No és cap secret que Kubernetes no és un producte tot en un preparat, i per crear un clúster "adult" necessitareu diverses addicions. Addon-operator us ajudarà a instal·lar, configurar i mantenir aquests complements actualitzats.
La necessitat de components addicionals al clúster s'informa a companys . En resum, la situació de Kubernetes en aquests moments és tal que per a una instal·lació senzilla de "jugar" et pots sortir amb els components fora de la caixa, per als desenvolupadors i proves pots afegir Ingress, però per a una instal·lació completa, sobre la qual podeu dir "la vostra producció està preparada", heu d'afegir amb una dotzena de complements diferents: alguna cosa per al seguiment, alguna cosa per al registre, no us oblideu d'entrada i certificat-manager, seleccioneu grups de nodes, afegiu polítiques de xarxa, temporada amb la configuració de l'autoscaler sysctl i pod...
Quines són les especificitats de treballar amb ells?
Com mostra la pràctica, la qüestió no es limita a una instal·lació. Per treballar còmodament amb el clúster, els complements s'hauran d'actualitzar, desactivar (eliminar del clúster) i voldreu provar-ne alguns abans d'instal·lar-los al clúster de producció.
Aleshores, potser Ansible serà suficient aquí? Pot ser. Però En general, els complements complets no viuen sense configuració. Aquests paràmetres poden variar segons la variant del clúster (aws, gce, azure, bare-metal, do, ...). Alguns paràmetres no es poden especificar per endavant; s'han d'obtenir del clúster. I el clúster no és estàtic: per a alguns paràmetres haureu de supervisar els canvis. I aquí ja falta Ansible: cal un programa que visqui en un clúster, és a dir. Operador Kubernetes.
Els que ho van provar a la feina , diran que les tasques d'instal·lació i actualització de complements i configuració de monitorització es poden resoldre completament mitjançant per a l'operador de shell. Podeu escriure un script que faci un condicional kubectl apply i supervisar, per exemple, ConfigMap, on s'emmagatzemarà la configuració. Això és aproximadament el que s'implementa a addon-operator.
Com s'organitza això en l'operador addon?
A l'hora de crear una nova solució, vam procedir dels següents principis:
- L'instal·lador del complement ha de ser compatible plantilla i configuració declarativa. No fem scripts màgics que instal·lin complements. L'operador de complements utilitza Helm per instal·lar complements. Per instal·lar-lo, heu de crear un gràfic i seleccionar els valors que s'utilitzaran per a la configuració.
- La configuració pot ser generar en la instal·lació, Ells poden sortir del clústerO rebre actualitzacions, seguiment dels recursos del clúster. Aquestes operacions es poden implementar mitjançant ganxos.
- La configuració pot ser emmagatzemar en un clúster. Per emmagatzemar la configuració al clúster, es crea un ConfigMap/operador de complements i l'operador de complements supervisa els canvis en aquest mapa de configuració. L'operador de complements ofereix als ganxos accés a la configuració mitjançant convencions senzilles.
- L'addició depèn de la configuració. Si la configuració ha canviat, l'operador de complements desplega el gràfic Helm amb valors nous. Vam cridar la combinació del gràfic Helm, els seus valors i enganxa un mòdul (vegeu a continuació per obtenir més detalls).
- Escenificació. No hi ha scripts de llançament màgic. El mecanisme d'actualització és similar a una aplicació normal: recull complements i operadors de complements en una imatge, etiqueta'ls i desplega'ls.
- Control de resultats. L'operador de complements pot proporcionar mètriques per a Prometheus.
Què és el farciment a l'operador de complements?
Una addició es pot considerar qualsevol cosa que afegeix noves funcions al clúster. Per exemple, instal·lar Ingress és un bon exemple de complement. Pot ser qualsevol operador o controlador amb el seu propi CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. O alguna cosa petita, però més fàcil d'utilitzar, per exemple, la copiadora secreta, que copia els secrets del registre a nous espais de noms, o el sintonitzador sysctl, que configura els paràmetres sysctl als nous nodes.
Per implementar complements, Addon-operator proporciona diversos conceptes:
- Quadre de timó s'utilitza per instal·lar diversos programaris al clúster, per exemple, Prometheus, Grafana, nginx-ingress. Si el component necessari té un gràfic Helm, instal·lar-lo amb Addon-operator serà molt senzill.
- Emmagatzematge de valors. Els gràfics Helm solen tenir molts paràmetres diferents que poden canviar amb el temps. L'operador de complements admet l'emmagatzematge d'aquestes configuracions i pot supervisar els seus canvis per tal de reinstal·lar el gràfic Helm amb nous valors.
- Ganxos són fitxers executables que l'operador de complements executa en esdeveniments i que accedeixen a la botiga de valors. El ganxo pot controlar els canvis al clúster i actualitzar els valors a la botiga de valors. Aquells. Mitjançant ganxos, podeu fer descobriment per recollir valors del clúster a l'inici o d'acord amb una programació, o podeu fer un descobriment continu, recopilant valors del clúster en funció dels canvis del clúster.
- Mòdul és una combinació d'un gràfic Helm, una botiga de valors i ganxos. Els mòduls es poden activar o desactivar. Desactivar un mòdul significa suprimir totes les versions de gràfics Helm. Els mòduls es poden habilitar de manera dinàmica, per exemple, si tots els mòduls que necessita estan habilitats o si el descobriment ha trobat els paràmetres necessaris als ganxos; això es fa mitjançant un script auxiliar habilitat.
- Ganxos globals. Són ganxos “per si mateixos”, no estan inclosos en mòduls i tenen accés a una botiga de valors global, els valors dels quals estan disponibles per a tots els ganxos en mòduls.
Com funcionen juntes aquestes parts? Mirem la imatge de la documentació:
Hi ha dos escenaris de treball:
- El ganxo global s'activa per un esdeveniment, per exemple, quan canvia un recurs del clúster. Aquest ganxo processa els canvis i escriu els nous valors a la botiga de valors globals. L'operador de complements observa que l'emmagatzematge global ha canviat i inicia tots els mòduls. Cada mòdul, mitjançant els seus ganxos, determina si cal habilitar-lo i actualitza la seva botiga de valors. Si el mòdul està habilitat, l'operador de complements inicia la instal·lació del gràfic Helm. En aquest cas, el gràfic Helm té accés als valors des de l'emmagatzematge del mòdul i des de l'emmagatzematge global.
- El segon escenari és més senzill: un enllaç de mòdul s'activa per un esdeveniment i canvia els valors a la botiga de valors del mòdul. L'operador de complements ho nota i llança el gràfic Helm amb valors actualitzats.
L'addició es pot implementar com un únic ganxo, o com un gràfic Helm, o fins i tot com a diversos mòduls dependents - això depèn de la complexitat del component que s'instal·la al clúster i del nivell de flexibilitat de configuració desitjat. Per exemple, al repositori () hi ha un complement sysctl-tuner, que s'implementa tant com un mòdul senzill amb un ganxo i un gràfic Helm, com mitjançant la botiga de valors, que permet afegir paràmetres editant ConfigMap.
Lliurament d'actualitzacions
Unes quantes paraules sobre l'organització de les actualitzacions de components que instal·la l'operador de complements.
Per executar Addon-operator en un clúster, necessiteu construir una imatge amb addicions en forma de fitxers de gràfics de ganxo i Helm, afegiu un fitxer binari addon-operator i tot el que necessiteu per a ganxos: bash, kubectl, jq, python etc. Aleshores, aquesta imatge es pot desplegar al clúster com una aplicació normal i, molt probablement, voldreu organitzar un o un altre esquema d'etiquetatge. Si hi ha pocs clústers, pot ser adequat el mateix enfocament que amb les aplicacions: nova versió, nova versió, aneu a tots els clústers i corregiu la imatge dels Pods. Tanmateix, en el cas d'un desplegament a un nombre important de clústers, el concepte d'autoactualització des d'un canal ens era més adequat.
Així és com ho fem:
- Un canal és essencialment un identificador que es pot configurar amb qualsevol cosa (per exemple, dev/stage/ea/stable).
- El nom del canal és l'etiqueta de la imatge. Quan necessiteu llançar actualitzacions a un canal, s'agrupa una imatge nova i s'etiqueta amb el nom del canal.
- Quan apareix una imatge nova al registre, l'operador de complements es reinicia i s'inicia amb la nova imatge.
Aquesta no és la millor pràctica, tal com està escrit . No es recomana fer això, però estem parlant una aplicació normal que viu al mateix clúster. En el cas de Addon-operator, una aplicació és un munt de desplegaments repartits entre clústers, i l'actualització automàtica ajuda molt i facilita la vida.
Els canals ajuden i en proves: si hi ha un clúster auxiliar, podeu configurar-lo al canal stage i incorporar-hi actualitzacions abans de llançar-la als canals ea и stable. Si amb un clúster al canal ea s'ha produït un error, podeu canviar-lo stable, mentre s'està investigant el problema amb aquest clúster. Si el clúster es treu del suport actiu, canvia al seu canal "congelat", per exemple, freeze-2019-03-20.
A més d'actualitzar els ganxos i els gràfics de Helm, potser ho necessiteu actualització i component de tercers. Per exemple, heu observat un error a l'exportador de nodes condicional i fins i tot heu descobert com aplicar-lo. A continuació, heu obert el PR i esteu esperant que la nova versió passi per tots els clústers i augmenti la versió de la imatge. Per no esperar indefinidament, podeu crear el vostre node-exportador i canviar-lo abans d'acceptar el PR.
En general, això es pot fer sense Addon-operator, però amb Addon-operator el mòdul per instal·lar node-exporter serà visible en un dipòsit, el Dockerfile per crear la vostra imatge es pot mantenir allà mateix, és més fàcil per a tots els participants en el procés per entendre què passa... I si hi ha diversos clústers, serà més fàcil provar el vostre PR i llançar una versió nova!
Aquesta organització d'actualització de components funciona amb èxit per a nosaltres, però es pot implementar qualsevol altre esquema adequat, després de tot en aquest cas Addon-operator és un fitxer binari simple.
Conclusió
Els principis implementats a Addon-operator us permeten crear un procés transparent per crear, provar, instal·lar i actualitzar complements en un clúster, similar als processos de desenvolupament d'aplicacions habituals.
Els complements per a Addon-operator en format de mòdul (Helm chart + hooks) es poden posar a disposició del públic. Nosaltres, l'empresa Flant, tenim previst publicar els nostres desenvolupaments en forma d'addicions d'aquest tipus durant l'estiu. Uneix-te al desenvolupament a GitHub (, ), prova de fer la teva pròpia addició basada en и , espereu notícies a Habré i al nostre !
PS
Llegeix també al nostre blog:
- «»;
- «».
Font: www.habr.com