Em dic Dmitry Sugrobov, sóc desenvolupador de Leroy Merlin. A l'article us explicaré per què cal Helm, com simplifica el treball amb Kubernetes, què ha canviat a la tercera versió i com utilitzar-lo per actualitzar aplicacions en producció sense temps d'inactivitat.
Aquest és un resum basat en un discurs en una conferència by Si no voleu llegir, mireu el vídeo.
Per què utilitzem Kubernetes en producció
Leroy Merlin és el líder en el mercat minorista de bricolatge a Rússia i Europa. La nostra empresa compta amb més d'un centenar de desenvolupadors, 33 empleats interns i un gran nombre de persones que visiten hipermercats i el lloc. Per tal de fer-los feliços a tots, vam decidir seguir els estàndards de la indústria. Desenvolupar noves aplicacions mitjançant l'arquitectura de microserveis; utilitzar contenidors per aïllar els ambients i lliurar correctament; i per a l'orquestració utilitzeu Kubernetes. El preu de l'ús d'orquestradors és cada cop més barat: el nombre d'enginyers propietaris de la tecnologia està creixent al mercat i apareixen proveïdors que ofereixen Kubernetes com a servei.
Tot el que fa Kubernetes, és clar, es pot fer d'altres maneres, per exemple, untant alguns Jenkins i docker-compose amb scripts, però per què complicar-se la vida si hi ha una solució ja feta i fiable? Per tant, vam venir a Kubernetes i fa un any que l'utilitzem en producció. Ara tenim vint-i-quatre clústers de Kubernetes, el més antic dels quals té més d'un any amb unes dues-centes beines.
La maledicció d'un gran nombre de fitxers YAML a Kubernetes
Per executar un microservei a Kubernetes, crearem almenys cinc fitxers YAML: per a Deployment, Service, Ingress, ConfigMap, Secrets, i l'enviarem al clúster. Per a la següent aplicació, escriurem el mateix paquet de yamliki, amb el tercer - un altre, i així successivament. Multiplicant el nombre de documents pel nombre d'entorns, ja obtenim centenars de fitxers, i això ni tan sols es té en compte els entorns dinàmics.
Adam Reese, el responsable principal de Helm, va introduir el concepte de "", que té aquest aspecte:
- Copia YAML: copieu un fitxer YAML.
- Enganxeu YAML: enganxeu-lo.
- Fixa les sagnies: corregeix les sagnies.
- Repetir - repetir de nou.
L'opció funciona, però heu de copiar fitxers YAML moltes vegades. Per canviar aquest cicle, van inventar Helm.
Què és el timó
Primer, Helm gestor de paquets, que us ajuda a trobar i instal·lar els programes que necessiteu. Per instal·lar, per exemple, MongoDB, no cal que aneu al lloc web oficial i descarregueu binaris, només heu d'executar l'ordre helm install stable/mongodb.
En segon lloc, Helm - motor de plantilles, ajuda a parametritzar fitxers. Tornem a la situació dels fitxers YAML a Kubernetes. És més fàcil escriure el mateix fitxer YAML, afegir-hi alguns marcadors de posició, en els quals Helm substituirà els valors. És a dir, en lloc d'un gran conjunt de yamliks, hi haurà un conjunt de plantilles (plantilles) en les quals es substituiran els valors necessaris en el moment adequat.
En tercer lloc, Helm - assistent de desplegament. Amb ell, podeu instal·lar, revertir i actualitzar aplicacions. Vegem com fer-ho.
Com utilitzar Helm per desplegar les vostres pròpies aplicacions
Instal·leu el client Helm a l'ordinador, seguint l'oficial . A continuació, crearem un conjunt de fitxers YAML. En lloc d'especificar valors específics, deixem marcadors de posició que Helm omplirà amb informació en el futur. Un conjunt d'aquests fitxers s'anomena gràfic Helm. Es pot enviar al client de la consola Helm de tres maneres:
- especificar una carpeta amb plantilles;
- empaquetar en un arxiu .tar i apuntar-hi;
- col·loqueu la plantilla en un dipòsit remot i afegiu un enllaç al dipòsit al client Helm.
També necessiteu un fitxer amb els valors - values.yaml. Les dades d'allà es substituiran a la plantilla. Creem-lo també.
La segona versió de Helm té una aplicació de servidor addicional anomenada Tiller. Es penja fora de Kubernetes i espera les sol·licituds del client Helm i, quan es truca, substitueix els valors necessaris a la plantilla i l'envia a Kubernetes.
Helm 3 és més senzill: en lloc de processar plantilles al servidor, la informació ara es processa completament al costat del client Helm i s'envia directament a l'API de Kubernetes. Aquesta simplificació millora la seguretat del clúster i facilita l'esquema de desplegament.
Com funciona tot
Executeu l'ordre helm install. Especifiqueu el nom de la versió de l'aplicació, doneu el camí a values.yaml. Al final, especificarem el repositori que conté el gràfic i el nom del gràfic. A l'exemple, aquests són "lmru" i "bestchart" respectivament.
helm install --name bestapp --values values.yaml lmru/bestchart
L'execució de l'ordre només és possible una vegada, quan es torna a executar en lloc de install cal utilitzar upgrade. Per simplificar, en lloc de dues ordres, podeu executar l'ordre upgrade amb clau addicional --install. A la primera execució, Helm enviarà una ordre per instal·lar la versió i, en el futur, l'actualitzarà.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Els inconvenients de desplegar noves versions d'aplicacions amb Helm
En aquest moment de la història, estic jugant a Who Wants to Be a Millionaire amb el públic i estem buscant com aconseguir que Helm actualitzi la versió de l'aplicació. .
Quan vaig estudiar el treball de Helm, em va sorprendre el comportament estrany quan intentava actualitzar versions d'aplicacions en execució. Vaig actualitzar el codi de l'aplicació, vaig penjar una imatge nova al registre de Docker, vaig enviar l'ordre per desplegar i no va passar res. A continuació es mostren algunes maneres no tan bones d'actualitzar aplicacions. En estudiar cadascun d'ells amb més detall, es comença a entendre l'estructura interna de l'instrument i les raons d'aquest comportament no evident.
Mètode 1. No canvieu la informació des de l'última execució
Com diu la dita Helm, "Els gràfics de Kubernetes poden ser grans i complexos, de manera que Helm intenta que les coses siguin tan senzilles com sigui possible". Per tant, si actualitzeu la darrera versió de la imatge de l'aplicació al registre docker i executeu l'ordre helm upgrade, aleshores no passarà res. Helm pensarà que no ha canviat res i no cal enviar una ordre a Kubernetes per actualitzar l'aplicació.
A partir d'ara, l'etiqueta més recent es mostra únicament com a exemple. Quan s'especifica aquesta etiqueta, Kubernetes baixarà la imatge del registre docker cada vegada, independentment del paràmetre imagePullPolicy. L'ús de l'últim en producció no és desitjable i provoca efectes secundaris.
Mètode 2. Actualitza LABEL a la imatge
Tal com està escrit al mateix , "Helm només actualitzarà una aplicació si ha canviat des de la darrera versió". L'opció lògica per a això seria actualitzar l'etiqueta a la pròpia imatge de Docker. Tanmateix, Helm no examina les imatges de l'aplicació i no és conscient de cap canvi en elles. En conseqüència, quan actualitzeu les etiquetes de la imatge, Helm no en sabrà i l'ordre d'actualització de l'aplicació no es rebrà a Kubernetes.
Mètode 3. Utilitzeu la clau --force
Anem als manuals i busquem la clau correcta. La clau que té més sentit --force. Malgrat el nom revelador, el comportament és diferent del que s'espera. En lloc d'una actualització forçada de l'aplicació, el seu propòsit real és restaurar una versió que es troba en l'estat FALLADA. Si no feu servir aquesta clau, haureu d'executar ordres seqüencialment helm delete && helm install --replace. En lloc d'això, es recomana utilitzar la clau --force, que automatitza l'execució seqüencial d'aquestes ordres. Més informació en aquest . Per dir-li a Helm que actualitzi la versió de l'aplicació, malauradament, aquesta clau no funcionarà.
Mètode 4. Canvia les etiquetes directament a Kubernetes
Actualització de l'etiqueta directament al clúster mitjançant l'ordre kubectl edit - mala idea. Aquesta acció provocarà una incoherència d'informació entre l'aplicació en execució i la que es va enviar originalment per al desplegament. El comportament de Helm durant el desplegament en aquest cas és diferent de la seva versió: Helm 2 no farà res i Helm 3 desplegarà una nova versió de l'aplicació. Per entendre el motiu, cal entendre com funciona Helm.
Com funciona Helm
Per determinar si una aplicació ha canviat des de l'última versió, Helm pot utilitzar:
- una aplicació en execució a Kubernetes;
- valors nous.yaml i gràfic actual;
- Informació de llançament interna de Helm.
Per als més curiosos: on emmagatzema Helm la informació interna del llançament?En executar l'ordre helm history, obtindrem tota la informació sobre les versions instal·lades amb Helm.
També hi ha informació detallada sobre els patrons i els valors enviats. Ho podem demanar:
A la segona versió d'Helm, aquesta informació es troba al mateix espai de noms on s'executa Tiller (per defecte, kube-system), al ConfigMap, marcat amb l'etiqueta "OWNER=TILLER":
En el moment de l'aparició de la tercera versió d'Helm, la informació es va traslladar a secrets, a més, al mateix espai de noms on s'executa l'aplicació. Gràcies a això, va ser possible executar diverses aplicacions simultàniament en diferents espais de noms amb el mateix nom de llançament. A la segona versió, va ser un maldecap sever quan els espais de noms estan aïllats, però poden influir-se mútuament.
El segon Helm, quan intenta esbrinar si cal una actualització, només utilitza dues fonts d'informació: la que se li va proporcionar ara i la informació interna sobre les versions, que es troba al ConfigMap.
El tercer Helm utilitza una estratègia de combinació de tres vies: a més d'aquesta informació, també té en compte l'aplicació que s'està executant ara mateix a Kubernetes.
Per aquest motiu, la versió antiga d'Helm no farà res, ja que no té en compte la informació de l'aplicació al clúster, però Helm 3 rebrà els canvis i enviarà la nova aplicació per al desplegament.
Mètode 5: utilitzeu la clau --recreate-pods
Amb una clau --recreate-pods podeu aconseguir el que s'havia previst originalment mitjançant la clau --force. Els contenidors es reiniciaran i, d'acord amb la política imagePullPolicy: sempre per a l'etiqueta més recent (més informació sobre això a la nota al peu de dalt), Kubernetes baixarà i executarà la nova versió de la imatge. Això no es farà de la millor manera: sense tenir en compte el StrategyType del desplegament, desactivarà bruscament totes les instàncies d'aplicació antigues i anirà a llançar-ne de noves. Durant el reinici, el sistema no funcionarà, els usuaris patiran.
Al mateix Kubernetes, un problema similar també existeix des de fa molt de temps. I ara, 4 anys després de l'obertura , el problema s'ha solucionat i, a partir de la versió 1.15 de Kubernetes, apareix la possibilitat de reiniciar pods.
Helm simplement desactiva totes les aplicacions i llança nous contenidors a prop. En producció, no podeu fer això, per no provocar una aplicació senzilla. Això només és necessari per a necessitats de desenvolupament, només es pot fer en entorns escènics.
Com actualitzar la versió de l'aplicació amb Helm?
Canviarem els valors enviats a Helm. Normalment, aquests són valors que se substitueixen per l'etiqueta d'imatge. En el cas de l'últim, que s'utilitza sovint per a entorns no productius, l'anotació actua com a informació mutable, que és inútil per a Kubernetes, i per a Helm actuarà com a senyal per actualitzar l'aplicació. Opcions d'ompliment del valor d'anotació:
- valor aleatori utilitzant la funció estàndard
{{ randAlphaNum 6 }}.
Hi ha una advertència: després de cada desplegament utilitzant un gràfic amb aquesta variable, el valor de l'anotació serà únic i Helm suposarà que hi ha canvis. Resulta que sempre reiniciarem l'aplicació, encara que no n'haguem canviat la versió. Això no és crític, ja que no hi haurà temps d'inactivitat, però encara desagradable. - Inseriu corrent data i hora -
{{ .Release.Date }}.
Una variant és com un valor aleatori amb una variable única permanentment. - Una millor manera és utilitzar sumes de control. Aquest és el SHA de la imatge o el SHA de l'últim commit al git -
{{ .Values.sha }}.
S'hauran de comptar i enviar al client Helm del costat de la trucada, per exemple a Jenkins. Si l'aplicació ha canviat, la suma de control també canviarà. Per tant, Helm només actualitzarà l'aplicació quan sigui necessari.
Resumim els nostres esforços
- Helm fa canvis de la manera menys invasiva, de manera que qualsevol canvi a nivell d'imatge de l'aplicació al registre Docker no donarà lloc a una actualització: no passarà res després d'executar l'ordre.
- Clau
--forces'utilitza per reparar versions problemàtiques i no està associat amb una actualització forçada. - Clau
--recreate-podsactualitzarà a la força les aplicacions, però ho farà de manera vandàlica: apagarà bruscament tots els contenidors. Els usuaris ho patiran, no val la pena fer-ho a la venda. - Feu canvis directament al clúster de Kubernetes mitjançant l'ordre
kubectl editno ho facis: trencarem la consistència i el comportament variarà segons la versió d'Helm. - Amb el llançament de la nova versió de Helm, han aparegut molts matisos. Els problemes del repositori Helm es descriuen amb un llenguatge clar, us ajudaran a entendre els detalls.
- Afegir una anotació mutable a un gràfic el farà més flexible. Això permetrà que l'aplicació es desplega correctament, sense temps d'inactivitat.
Pensat des de la categoria de "pau al món", treballant en tots els àmbits de la vida: llegiu les instruccions abans d'utilitzar, no després. Només disposant d'informació completa serà possible construir sistemes fiables i fer feliços als usuaris.
Altres enllaços relacionats:
Aquest informe es va presentar per primera vegada a per Mail.ru Cloud Solutions. Mireu altres actuacions i subscriu-te als anuncis d'esdeveniments a Telegram .
Font: www.habr.com