Numele meu este Dmitry Sugrobov, sunt dezvoltator la Leroy Merlin. În acest articol, vă voi spune de ce este nevoie de Helm, cum simplifică lucrul cu Kubernetes, ce s-a schimbat în cea de-a treia versiune și cum să îl utilizați pentru a actualiza aplicațiile în producție fără timpi de nefuncționare.
Acesta este un rezumat bazat pe un discurs la o conferință by - dacă nu doriți să citiți, vizionați videoclipul.
De ce folosim Kubernetes în producție
Leroy Merlin este lider pe piața de bricolaj cu amănuntul din Rusia și Europa. Compania noastră are peste o sută de dezvoltatori, 33 de angajați interni și un număr mare de persoane care vizitează hipermarketurile și site-ul web. Pentru a le face pe toți fericiți, am decis să urmăm abordările standard din industrie. Dezvoltați noi aplicații folosind arhitectura microservicii; utilizați containere pentru a izola mediile și a asigura livrarea corespunzătoare; și utilizați Kubernetes pentru orchestrare. Prețul utilizării orchestratoarelor devine rapid mai ieftin: numărul de ingineri pricepuți în tehnologie este în creștere pe piață și apar furnizori care oferă Kubernetes ca serviciu.
Tot ceea ce face Kubernetes, desigur, poate fi făcut în alte moduri, de exemplu, acoperind unele Jenkins și docker-compose cu scripturi, dar de ce să complici viața dacă există o soluție gata făcută și de încredere? De aceea am venit la Kubernetes și îl folosim în producție de un an. În prezent avem douăzeci și patru de clustere Kubernetes, dintre care cel mai vechi are mai mult de un an, cu aproximativ două sute de poduri.
Blestemul fișierelor mari YAML din Kubernetes
Pentru a lansa un microserviciu în Kubernetes, vom crea cel puțin cinci fișiere YAML: pentru Deployment, Service, Ingress, ConfigMap, Secrets - și le vom trimite către cluster. Pentru următoarea aplicație vom scrie același pachet de stâlpi, cu al treilea vom scrie altul și așa mai departe. Dacă înmulțim numărul de documente cu numărul de medii, vom obține deja sute de fișiere, iar acest lucru încă nu ține cont de mediile dinamice.
Adam Reese, menținătorul principal al Helm, a introdus conceptul de „", care arată astfel:
- Copiați YAML - copiați un fișier YAML.
- Paste YAML - lipiți-l.
- Fix Indents - reparați indentări.
- Repetă - repetă din nou.
Opțiunea funcționează, dar trebuie să copiați fișierele YAML de multe ori. Pentru a schimba acest ciclu, Helm a fost inventat.
Ce este Helm
În primul rând, Helm - manager de pachete, care vă ajută să găsiți și să instalați programele de care aveți nevoie. Pentru a instala, de exemplu, MongoDB, nu trebuie să accesați site-ul oficial și să descărcați fișiere binare, doar rulați comanda helm install stable/mongodb.
În al doilea rând, Helm - motor de șablon, ajută la parametrizarea fișierelor. Să revenim la situația cu fișierele YAML din Kubernetes. Este mai ușor să scrieți același fișier YAML, să adăugați niște substituenți la el, în care Helm va înlocui valorile. Adică, în loc de un set mare de schele, va exista un set de șabloane în care valorile necesare vor fi înlocuite la momentul potrivit.
În al treilea rând, Helm - maestru de desfășurare. Cu acesta puteți instala, derula și actualiza aplicațiile. Să ne dăm seama cum să facem asta.
Cum să utilizați Helm pentru a vă implementa propriile aplicații
Să instalăm clientul Helm pe computer, urmând oficialul . În continuare, vom crea un set de fișiere YAML. În loc să specificăm valori specifice, vom lăsa substituenți, pe care Helm le va completa cu informații în viitor. Un set de astfel de fișiere se numește diagramă Helm. Poate fi trimis către clientul consolei Helm în trei moduri:
- indicați un folder cu șabloane;
- împachetați arhiva într-un .tar și indicați spre ea;
- puneți șablonul într-un depozit de la distanță și adăugați un link către depozitul din clientul Helm.
De asemenea, aveți nevoie de un fișier cu valori - values.yaml. Datele de acolo vor fi inserate în șablon. Să-l creăm și noi.
A doua versiune a Helm are o aplicație server suplimentară - Tiller. Se blochează în afara Kubernetes și așteaptă cereri de la clientul Helm și, atunci când este apelat, înlocuiește valorile necesare în șablon și îl trimite către Kubernetes.
Helm 3 este mai simplu: în loc să proceseze șabloane pe server, informațiile sunt acum procesate în întregime pe partea clientului Helm și trimise direct către API-ul Kubernetes. Această simplificare îmbunătățește securitatea clusterului și facilitează schema de lansare.
Cum funcționează totul
Rulați comanda helm install. Să indicăm numele ediției aplicației și să dăm calea către values.yaml. La final vom indica depozitul în care se află diagrama și numele diagramei. În exemplu, acestea sunt „lmru” și, respectiv, „bestchart”.
helm install --name bestapp --values values.yaml lmru/bestchart
Comanda poate fi executată o singură dată, atunci când este executată din nou install nevoie de utilizare upgrade. Pentru simplitate, în loc de două comenzi, puteți rula comanda upgrade cu cheie suplimentară --install. Când este executat pentru prima dată, Helm va trimite o comandă pentru a instala versiunea și o va actualiza în viitor.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Capcanele implementării de noi versiuni ale unei aplicații cu Helm
În acest moment al poveștii, joc Who Wants to Be a Millionaire cu publicul și ne dăm seama cum să-l convingem pe Helm să actualizeze versiunea aplicației. .
Când învățam cum funcționează Helm, am fost surprins de un comportament ciudat când încercam să actualizez versiunile aplicațiilor care rulează. Am actualizat codul aplicației, am încărcat o nouă imagine în registrul Docker, am trimis comanda de implementare - și nu s-a întâmplat nimic. Mai jos sunt câteva modalități care nu sunt complet de succes de a actualiza aplicațiile. Studiind fiecare dintre ele mai în detaliu, începeți să înțelegeți structura internă a instrumentului și motivele acestui comportament nu este evident.
Metoda 1. Nu modificați informațiile de la ultima lansare
După cum se spune Helm, „Diagramele Kubernetes pot fi mari și complexe, așa că Helm încearcă să nu atingă nimic prea mult.” Prin urmare, dacă actualizați cea mai recentă versiune a imaginii aplicației în registrul docker și executați comanda helm upgrade, atunci nu se va întâmpla nimic. Helm va crede că nimic nu s-a schimbat și nu este nevoie să trimiți o comandă către Kubernetes pentru a actualiza aplicația.
Aici și mai jos, cea mai recentă etichetă este afișată doar ca exemplu. Când specificați această etichetă, Kubernetes va descărca imaginea din registrul docker de fiecare dată, indiferent de parametrul imagePullPolicy. Utilizarea celor mai recente în producție este nedorită și provoacă efecte secundare.
Metoda 2. Actualizați LABEL în imagine
După cum este scris în același , „Helm va actualiza o aplicație numai dacă aceasta s-a schimbat de la ultima lansare.” O opțiune logică pentru aceasta ar părea să fie actualizarea LABEL-ului în imaginea docker în sine. Cu toate acestea, Helm nu se uită la imaginile aplicației și nu are idee despre vreo modificare a acestora. În consecință, la actualizarea etichetelor din imagine, Helm nu va ști despre ele, iar comanda de actualizare a aplicației nu va fi trimisă către Kubernetes.
Metoda 3: Folosiți o cheie --force
Să ne întoarcem la manuale și să căutăm cheia necesară. Cheia are cel mai mult sens --force. În ciuda numelui evident, comportamentul este diferit de cel așteptat. În loc să forțezi o actualizare a aplicației, scopul său real este acela de a restabili o ediție care este în starea FAILED. Dacă nu utilizați această tastă, trebuie să executați comenzile secvenţial helm delete && helm install --replace. Se recomandă utilizarea cheii în schimb --force, care automatizează execuția secvențială a acestor comenzi. Mai multe informații în aceasta . Pentru a-i spune lui Helm să actualizeze versiunea aplicației, din păcate, această cheie nu va funcționa.
Metoda 4. Schimbați etichetele direct în Kubernetes
Actualizarea etichetei direct în cluster folosind comanda kubectl edit - Idee rea. Această acțiune va duce la inconsecvența informațiilor între aplicația care rulează și cea care a fost trimisă inițial pentru implementare. Comportamentul Helm în timpul implementării în acest caz diferă de versiunea sa: Helm 2 nu va face nimic, iar Helm 3 va implementa noua versiune a aplicației. Pentru a înțelege de ce, trebuie să înțelegeți cum funcționează Helm.
Cum funcționează Helm?
Pentru a determina dacă o aplicație s-a schimbat de la ultima sa lansare, Helm poate folosi:
- rularea aplicației în Kubernetes;
- valori noi.yaml și diagramă curentă;
- Informațiile interne ale lui Helm.
Pentru cei mai curioși: unde stochează Helm informațiile interne despre versiuni?Prin executarea comenzii helm history, vom obține toate informațiile despre versiunile instalate folosind Helm.
Există, de asemenea, informații detaliate despre șabloanele și valorile trimise. Putem solicita:
În cea de-a doua versiune a Helm, aceste informații se află în același spațiu de nume în care rulează Tiller (kube-system în mod implicit), în ConfigMap, marcat cu eticheta „OWNER=TILLER”:
Când a apărut a treia versiune a Helm, informațiile s-au mutat în secrete și în același spațiu de nume în care rula aplicația. Datorită acestui fapt, a devenit posibilă rularea mai multor aplicații simultan în spații de nume diferite cu același nume de ediție. În a doua versiune a fost o bătaie de cap serioasă când spațiile de nume sunt izolate, dar se pot influența reciproc.
Al doilea Helm, când încearcă să înțeleagă dacă este necesară o actualizare, folosește doar două surse de informații: ceea ce îi este furnizat acum și informații interne despre versiuni, care se află în ConfigMap.
Al treilea Helm folosește o strategie de îmbinare în trei căi: pe lângă aceste informații, ia în considerare și aplicația care rulează chiar acum în Kubernetes.
Din acest motiv, versiunea veche a Helm nu va face nimic, deoarece nu ține cont de informațiile aplicației din cluster, dar Helm 3 va primi modificările și va trimite noua aplicație pentru implementare.
Metoda 5. Utilizați comutatorul --recreate-pods
Cu o cheie --recreate-pods puteți realiza ceea ce ați plănuit inițial să realizați cu cheia --force. Containerele vor reporni și, conform politicii imagePullPolicy: Întotdeauna pentru cea mai recentă etichetă (mai multe despre asta în nota de subsol de mai sus), Kubernetes va descărca și lansa o nouă versiune a imaginii. Acest lucru nu se va face în cel mai bun mod: fără a ține cont de StrategyType de implementare, se va opri brusc toate instanțele de aplicație vechi și va începe să lanseze altele noi. În timpul repornirii, sistemul nu va funcționa, utilizatorii vor avea de suferit.
În Kubernetes însuși, o problemă similară a existat și de mult timp. Și acum, la 4 ani de la deschidere , problema a fost remediată și, începând cu versiunea 1.15 a Kubernetes, apare capacitatea de a rula și reporni podurile.
Helm pur și simplu oprește toate aplicațiile și lansează containere noi în apropiere. Nu puteți face acest lucru în producție, pentru a nu cauza opriri ale aplicației. Acest lucru este necesar doar pentru nevoile de dezvoltare și poate fi realizat doar în medii de scenă.
Cum se actualizează versiunea aplicației folosind Helm?
Vom schimba valorile trimise către Helm. De obicei, acestea sunt valori care sunt înlocuite în locul etichetei de imagine. În cazul ultimului, care este adesea folosit pentru medii neproductive, informațiile modificabile sunt o adnotare, care este inutilă pentru Kubernetes în sine, iar pentru Helm va acționa ca un semnal pentru necesitatea actualizării aplicației. Opțiuni pentru completarea valorii de adnotare:
- Valoare aleatoare folosind funcția standard -
{{ randAlphaNum 6 }}.
Există o avertizare: după fiecare implementare folosind o diagramă cu o astfel de variabilă, valoarea adnotării va fi unică, iar Helm va presupune că există modificări. Se pare că întotdeauna vom reporni aplicația, chiar dacă nu i-am schimbat versiunea. Acest lucru nu este critic, deoarece nu va exista timp de nefuncționare, dar este totuși neplăcut. - Lipire curent data si ora -
{{ .Release.Date }}.
O variantă este similară cu o valoare aleatoare cu o variabilă permanent unică. - O modalitate mai corectă este utilizarea sume de control. Acesta este SHA-ul imaginii sau SHA-ul ultimului comit din git -
{{ .Values.sha }}.
Acestea vor trebui numărate și trimise către clientul Helm din partea apelantului, de exemplu în Jenkins. Dacă aplicația s-a schimbat, atunci suma de control se va modifica. Prin urmare, Helm va actualiza aplicația doar atunci când este necesar.
Să rezumam încercările noastre
- Helm face modificări în cel mai puțin invaziv mod, așa că orice modificare la nivelul imaginii aplicației din Registrul Docker nu va avea ca rezultat o actualizare: nu se va întâmpla nimic după executarea comenzii.
- Ключ
--forcefolosit pentru a restaura versiunile problematice și nu este asociat cu actualizările forțate. - Ключ
--recreate-podsva actualiza forțat aplicațiile, dar o va face într-un mod vandal: va opri brusc toate containerele. Utilizatorii vor suferi de acest lucru; nu ar trebui să faceți acest lucru în producție. - Faceți direct modificări în clusterul Kubernetes folosind comanda
kubectl editnu: vom distruge consistența, iar comportamentul va diferi în funcție de versiunea Helm. - Odată cu lansarea noii versiuni de Helm, au apărut multe nuanțe. Problemele din depozitul Helm sunt descrise într-un limbaj clar, vă vor ajuta să înțelegeți detaliile.
- Adăugarea unei adnotări editabile la o diagramă o va face mai flexibilă. Acest lucru vă va permite să lansați aplicația corect, fără timpi de nefuncționare.
Un gând de „pace mondială” care funcționează în toate domeniile vieții: citiți instrucțiunile înainte de utilizare, nu după. Numai cu informații complete va fi posibil să construim sisteme fiabile și să-i facă pe utilizatori fericiți.
Alte link-uri conexe:
Acest raport a fost prezentat pentru prima dată la de Mail.ru Cloud Solutions. Uite alte spectacole și abonați-vă la anunțurile despre evenimente pe Telegram .
Sursa: www.habr.com