Az én nevem Dmitrij Sugrobov, a „Leroy Merlin” fejlesztője vagyok. A cikkemben arról fogok beszélni, miért van szükség Helmre, hogyan egyszerűsíti a Kubernetes-szel való munkát, mi változott a harmadik verzióban, és hogyan frissíthetjük az alkalmazásokat a termelésben leállás nélkül.
Ez egy összefoglaló a konferencián elhangzott beszéd alapján szerzője — ha nem szeretné olvasni, nézze meg a videót.
Miért használjuk a Kubernetest a termelésben
A „Leroy Merlin” a DIY kiskereskedelem vezetője Oroszországban és Európában. Cégünknél több mint 100 fejlesztő dolgozik, 33 000 belső munkatársunk van, és rengeteg ember látogatja a hipermarketeinket és a weboldalunkat. Annak érdekében, hogy mindenki boldog legyen, úgy döntöttünk, hogy a szektorban standard megközelítéseket követünk. Új alkalmazásokat fejlesztünk mikroszolgáltatás-architektúrával; a környezetek elszigetelésére és a helyes kiszállításra konténereket használunk; az orkhesztrációhoz pedig a Kubernetest alkalmazzuk. Az orkhesztrátorok használatának ára gyorsan csökken: a piacon nő a technológia ismeretével rendelkező mérnökök száma, és megjelennek a szolgáltatók, akik Kubernetes-t kínálnak szolgáltatásként.
Mindent, amit a Kubernetes csinál, természetesen el lehet végezni más módokon is, például ha az egész folyamatot valamilyen Jenkins és docker-compose segítségével scriptelnék, de miért bonyolítsuk az életünket, ha van egy kész és megbízható megoldás? Ezért választottuk a Kubernetest, és már egy éve használjuk a termelésben. Jelenleg huszonnégy Kubernetes klaszterünk van, a legöregebb közülük több mint egy éves, és körülbelül kétszáz pod található benne.
A sok YAML-fájl átka a Kubernestes
Egy mikroszolgáltatás elindításához a Kubernetesen legalább öt YAML-fájlt kell létrehoznunk: a Deploymenthoz, Szolgáltatáshoz, Ingresshez, ConfigMaphez, Secretshez — és el kell küldenünk a klaszterbe. A következő alkalmazás számára megírjuk ugyanazt a csomagot a YAML-fájlokból, a harmadikhoz pedig megint egy másikat, és így tovább. A dokumentumok számát megszorozva a környezetek számával, már több száz fájlt kapunk, és ez még a dinamikus környezeteket nem is számolja.
Adam Reese, a Helm fő karbantartója bevezette a „”, amely így néz ki:
- Másolj YAML — másold a YAML-fájlt.
- Illeszd be YAML — illeszd be.
- Javítsd az Indentációt — javítsd az eltolásokat.
- Ismételd — ismételd meg.
Ez egy működő változat, de sokszor kell másolni a YAML-fájlokat. E ciklus megváltoztatására találták ki Helm-t.
Mi az a Helm
Elsősorban, a Helm — csomagkezelő, amely segít megtalálni és telepíteni a szükséges programokat. A MongoDB telepítéséhez például nem kell ellátogatni a hivatalos weboldalra és letölteni a bináris fájlokat, elegendő végrehajtani a parancsot helm install stable/mongodb.
Másodszor, a Helm — sablonkezelő, amely segít paraméterezni a fájlokat. Térjünk vissza a Kubernetes YAML-fájlok helyzetéhez. Könnyebb megírni ugyanazt a YAML-fájlt, és hozzáadni néhány helyettesítőt, amelyet a Helm helyettesít értékekkel. Tehát a sok YAML-fájl helyett sablonok (template) halmazát kapjuk, amelyekbe a megfelelő pillanatban a szükséges értékek kerülnek.
Harmadszor, a Helm — telepítési mester. Ezzel installálhatunk, visszaállíthatunk és frissíthetünk alkalmazásokat. Nézzük meg, hogyan lehet ezt megtenni.
Hogyan használjuk a Helmet saját alkalmazásaink telepítésére
Telepítjük a Helm klienst a számítógépre, követve a hivatalos . Ezután létrehozunk egy halom YAML-fájlt. Ahelyett, hogy konkrét értékeket adnánk meg, helyettesítőket hagyunk, amelyeket a Helm a jövőben felismer. Az ilyen fájlok halmazát Helm chartnak nevezzük. A Helm konzol kliensnek három módon küldhetjük el:
- megadni a sablonok mappáját;
- becsomagolni .tar archívumba és hivatkozni rá;
- a sablont elhelyezni egy távoli tárolóban, és hivatkozást adni a tárolóra a Helm kliensben.
Szükség van egy értékeket tartalmazó fájlra is — values.yaml. Az onnan származó adatok a sablonba kerülnek. Ezt is létrehozzuk.
A Helm második verziójában egy további szerveralkalmazás létezik — Tiller. Ez kívül helyezkedik el a Kubernetesben, és várja a Helm kliens kérését, a híváskor pedig a szükséges értékeket helyettesíti a sablonban és elküldi a Kubernetesnek.
A Helm 3 egyszerűbb: a sablonok feldolgozása szerveroldalon helyett, az információt most teljes egészében a Helm-kliens oldalán dolgozzák fel és közvetlenül a Kubernetes API-ba küldik. Ez az egyszerűsítés növeli a klaszter biztonságát és megkönnyíti a kiegyensúlyozási sémát.
Hogyan működik mindez
Futtatjuk a parancsot helm install. Megadjuk az alkalmazás kiadásának nevét, megadjuk az elérési utat a values.yaml-hoz. A végén megnevezzük a tárolót, ahol a chart található és a chart nevét. Például ez 'lmru' és 'bestchart'.
helm install --name bestapp --values values.yaml lmru/bestchart
A parancs végrehajtása csak egyszer lehetséges, a parancs ismételt végrehajtásakor a install helyett upgrade. Az egyszerűség kedvéért a két parancs helyett futtathatjuk a parancsot upgrade kiegészítő kulccsal --installElőször a Helm parancsot küld az új verzió telepítésére, a továbbiakban pedig frissíti azt.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Új verziók telepítési buktatói a Helm használatával
E történet során a 'Ki akar milliomos lenni?' játékban játszom a közönséggel, és kiderítjük, hogyan lehet frissíteni a Helm segítségével az alkalmazás verzióját. .
Amikor a Helm működését tanulmányoztam, meglepett az a furcsa viselkedés, amikor megpróbáltam frissíteni a futó alkalmazások verzióit. Az alkalmazás kódot frissítettem, a docker registry-be új képet töltöttem fel, kiadtam a telepítési parancsot – és semmi nem történt. Alább néhány nem túl sikeres módszert ismertetek az alkalmazások frissítésére. Mindegyiket alaposabban tanulmányozva kezdesz megérteni az eszköz belső működését és az ilyen nem nyilvánvaló viselkedés okait.
Módszer 1. Ne módosítsd az információt az utolsó indítás óta
Ahogyan mondja A Helm, 'A Kubernetes chartok nagyok és bonyolultak, ezért a Helm törekszik arra, hogy ne módosítson feleslegesen semmit'. Ezért, ha frissíted az alkalmazás legfrissebb képet a docker registry-ben és végrehajtod a parancsot helm upgrade, akkor semmi nem fog történni. A Helm úgy fogja gondolni, hogy semmi sem változott, így nem szükséges a Kubernetes számára frissítési parancsot küldeni az alkalmazásra.
Itt és a továbbiakban a latest címke kizárólag példaként szerepel. A latest címke megadása esetén a Kubernetes minden alkalommal letölti a képet a docker registry-ből, függetlenül az imagePullPolicy paramétertől. A latest használata a gyártásban nem ajánlott és mellékhatásokat okozhat.
Módszer 2. Frissítsd a LABEL-t a képen
Ahogy a következőben is olvasható , 'A Helm csak akkor frissíti az alkalmazást, ha az az utolsó kiadás óta megváltozott.' Logikus lépésnek tűnik a LABEL frissítése magában a docker képen. Azonban a Helm nem néz bele az alkalmazásokba, és nincs tudomása a bennük bekövetkezett változásokról. Ezért a címkék frissítésekor a Helm nem értesül róluk, és a frissítési parancs nem fog eljutni a Kubernetes-hez.
Módszer 3. Használj kulcsot --force
Nézzük meg a kézikönyveket, és keressük meg a szükséges kulcsot. A legjobban a következő kulcs illik a helyzethez --force. A nevéből adódóan a viselkedés eltér az elvárttól. A valódi célja a FAILED státuszú kiadás helyreállítása, nem pedig az alkalmazás kényszerített frissítése. Ha ezt a kulcsot nem használják, a parancsok végrehajtását sorrendben kell elvégezni. helm delete && helm install --replace. Ehelyett javasolt a kulcsot használni, --force, amely automatizálja ezeknek a parancsoknak a sorrendbeli végrehajtását. További információk találhatók ezen a . Ahhoz, hogy a Helm végül frissítse az alkalmazás verzióját, sajnos ez a kulcs nem megfelelő.
4. módszer. Közvetlenül a Kubernetes címkéit módosítani.
A címke közvetlen frissítése a klaszterben a következő paranccsal: kubectl edit — rossz ötlet. Ez az intézkedés inkonzisztenciához vezet a működő alkalmazás és a kezdetben telepített információ között. A Helm viselkedése telepítéskor ebben az esetben eltér a verziójától: a Helm 2 nem csinál semmit, míg a Helm 3 új verziót telepít az alkalmazásból. A probléma megértéséhez meg kell érteni, hogyan működik a Helm.
Hogyan működik a Helm
A Helm megállapíthatja, hogy változott-e az alkalmazás a legutolsó kiadás óta:
- futtatott alkalmazás a Kubernetesben;
- új values.yaml és aktuális chart;
- a Helm belső információi a kiadásokról.
A legkíváncsibbaknak: hol tárolja a Helm a kiadások belső információit?A parancs végrehajtásával, helm history, információt kapunk a Helm által telepített verziókról.
További részletes információk állnak rendelkezésre a küldött sablonokról és értékekről. Ezt kérhetjük:
A Helm második verziójában ezek az információk ugyanazon a névtérben találhatók, ahol a Tiller fut (alapértelmezés szerint kube-system), a "OWNER=TILLER" címkével ellátott ConfigMap-ban:
A Helm harmadik verziójában az információ titkosításra került, és ugyanabban a névtérben található, ahol az alkalmazás fut. Ennek köszönhetően lehetővé vált több alkalmazás egyidejű futtatása különböző névterekben azonos kiadási névvel. A második verzióban ez komoly fejfájást okozott, amikor a névterek elszigeteltek voltak, de hatással lehettek egymásra.
A második Helm, amikor megpróbálja megérteni, szükséges-e a frissítés, csak két információforrást használ: azt, amit jelenleg kapott, és a kiadásokkal kapcsolatos belső információit, amely a ConfigMap-ban található.
A harmadik Helm a háromfokú összeolvadási stratégiát alkalmazza: a kromatográfához képest a Kubernetesben végrehajtott alkalmazás adatait is figyelembe veszi.
Ezért a régi Helm verziója nem fog semmit tenni, mert nem veszi figyelembe az alkalmazás információit a klaszterben, de a Helm 3 megkapja a változásokat és új alkalmazást fog telepíteni.
5. módszer: Használja a --recreate-pods kulcsot
A kulcs segítségével --recreate-pods elérhetjük azt, amit eredetileg a kulcs segítségével szerettünk volna kapni. --forceA tartályok újraindulnak, és a legújabb címkéhez tartozó imagePullPolicy: Always irányelvekkel (erről a fentebbi lábjegyzetben esett szó) a Kubernetes letölti és elindítja az új kép verziót. Ez nem a legjobb módon fog megtörténni: figyelmen kívül hagyva a telepítési StrategyType-t, hirtelen leállítja az összes régi alkalmazás példányt és újakat indít el. Az újraindítás során a rendszer nem működik, felhasználók szenvedni fognak.
A Kubernetesben is létezett hasonló probléma hosszú ideig. És íme, négy évvel a felfedezése után , a problémát javították, és a Kubernetes 1.15-ös versionál kezdve lehetőség lesz a podok rolling-restart-jára.
A Helm pedig egyszerűen leállít minden alkalmazást és új konténereket indít. A termelési környezetben ezt nem szabad tenni, hogy ne idézzünk elő alkalmazásleállást. Ezt csak fejlesztési célokra szükséges, csak stage-környezetekben végezhető el.
Hogyan frissítsük az alkalmazás verzióját a Helm segítségével?
Meg fogjuk változtatni a Helm-nek elküldött értékeket. Általában ezek az értékek az image tag helyére kerülnek. A 'latest', amelyet gyakran használnak a nem produktív környezetekben, megváltoztatható információként az annotáció szolgál, amely a Kubernetes számára haszontalan, de a Helm számára frissítési jelzést ad. Az annotáció értékének kitöltési lehetőségei:
- Véletlenszerű érték a standard függvény segítségével —
{{ randAlphaNum 6 }}.
Van egy kis részlet: minden egyes telepítés után, amely ezt a változót tartalmazó chartot használ, az annotáció értéke egyedi lesz, és a Helm úgy fogja mondani, hogy van változás. Így mindig újraindítjuk az alkalmazást, még akkor is, ha nem változtattunk a verzión. Ez nem kritikus, mivel nem lesz leállás, de mindenképpen kellemetlen. - Beilleszteni a jelenlegi dátumot és időt —
{{ .Release.Date }}.
Ez a lehetőség hasonló a véletlenszerű értékhez, de folyamatosan egyedi változóval rendelkezik. - A helyesebb módszer — használni ellenőrző összegek. Ez a SHA képe vagy a legutolsó commit SHA-ja a gitben —
{{ .Values.sha }}.
Ezokat számolni kell, és el kell küldeni a Helm kliensnek a hívó oldalon, például Jenkinsben. Ha az alkalmazás megváltozik, az ellenőrző összeg is megváltozik. Következésképpen, a Helm csak akkor frissíti az alkalmazást, amikor szükséges.
Összefoglalva a próbálkozásainkat
- A Helm a legkevésbé invazív módon hajtja végre a változtatásokat, ezért bármilyen változtatás a Docker Registry alkalmazásképén nem vezet frissítéshez: a parancs végrehajtása után semmi sem fog történni.
- Kulcs
--forceproblémás kiadások helyrehozására használható, és nem kapcsolódik a kényszerített frissítéshez. - Kulcs
--recreate-podskényszerítve frissíti az alkalmazásokat, de ezt vandál módon teszi: hirtelen lekapcsol minden konténert. Ez hátrányosan érinti a felhasználókat, a termelésben ezt nem szabad így csinálni. - Közvetlenül a Kubernetes klaszterben a parancs segítségével
kubectl editnem szabad: megsértjük a konzisztenciát, és a viselkedés az Helm verziójától függően eltérő lesz. - Az új Helm verziók megjelenésével sok részlet került előtérbe. Az Issues a Helm tárolóban érthető nyelven van leírva, segítenek eligibilálni a részleteket.
- Egy módosítható annotáció hozzáadása a chart-hoz rugalmasabbá teszi azt. Ez lehetővé teszi az alkalmazás helyes kibővítését, állásidő nélkül.
Az ötlet a "béke a világban" kategóriából, amely minden életterületen működik: olvasd el az utasítást használat előtt, ne után. Csak a teljes információ birtokában lehet megbízható rendszereket építeni és boldoggá tenni a felhasználókat.
További hivatkozások a témában:
Ez a beszéd először hangzott el a Mail.ru Cloud Solutions által. Nézd meg más előadásokat, és iratkozz fel az események értesítéseire a Telegramon .
Forrás: habr.com
