A nevem Dmitrij Sugrobov, a Leroy Merlin fejlesztője vagyok. Ebben a cikkben elmesélem, miért van szükség a Helm-re, hogyan egyszerűsíti le a Kubernetes-szel való munkát, mi változott a harmadik verzióban, és hogyan használható fel az éles alkalmazások frissítésére leállás nélkül.
Ez egy összefoglaló egy konferencián elhangzott beszéd alapján by - ha nem akarsz olvasni, nézd meg a videót.
Miért használjuk a Kuberneteset a termelésben?
A Leroy Merlin vezető szerepet tölt be a barkácsolás kiskereskedelmi piacán Oroszországban és Európában. Cégünk több mint száz fejlesztővel, 33 000 belső munkatárssal, valamint hatalmas számú hipermarket és weboldal látogatóval rendelkezik. Annak érdekében, hogy mindannyiukat boldoggá tegyük, úgy döntöttünk, hogy az ipari szabványos megközelítéseket követjük. Új alkalmazások fejlesztése mikroszolgáltatási architektúrával; konténereket használjon a környezet elkülönítésére és a megfelelő szállítás biztosítására; és a hangszereléshez a Kuberneteset használja. Rohamosan olcsóbbá válik a hangszerelők használatának ára: egyre nő a technológiában jártas mérnökök száma a piacon, és megjelennek a Kubernetes szolgáltatást kínáló szolgáltatók.
Természetesen mindent, amit a Kubernetes csinál, más módon is meg lehet csinálni, például néhány Jenkins lefedésével és a docker-compose szkriptekkel, de minek bonyolítani az életet, ha van kész és megbízható megoldás? Ezért jöttünk a Kuberneteshez, és már egy éve használjuk a gyártásban. Jelenleg huszonnégy Kubernetes klaszterünk van, amelyek közül a legrégebbi több mint egy éves, körülbelül kétszáz hüvelyes.
A nagy YAML-fájlok átka a Kubernetesben
A Kubernetes mikroszolgáltatásának elindításához legalább öt YAML-fájlt hozunk létre: Deployment, Service, Ingress, ConfigMap, Secrets - és elküldjük a fürtnek. A következő alkalmazáshoz ugyanazt a jamb-csomagot írjuk, a harmadikkal egy másikat, és így tovább. Ha a dokumentumok számát megszorozzuk a környezetek számával, máris több száz fájlt kapunk, és ez még nem veszi figyelembe a dinamikus környezeteket.
Adam Reese, a Helm fő karbantartója bemutatta a "", ami így néz ki:
- YAML másolása – YAML fájl másolása.
- YAML beillesztése – illessze be.
- Behúzások javítása – behúzások javítása.
- Ismétlés - ismételje meg újra.
Az opció működik, de sokszor kell másolnia a YAML fájlokat. Ennek a ciklusnak a megváltoztatására találták fel a Helmet.
Mi az a Helm
Először is Helm... csomagkezelő, amely segít megtalálni és telepíteni a szükséges programokat. Például a MongoDB telepítéséhez nem kell felkeresnie a hivatalos webhelyet és letöltenie a bináris fájlokat, csak futtassa a parancsot helm install stable/mongodb.
Másodszor Helm - sablon motor, segít a fájlok paraméterezésében. Térjünk vissza a Kubernetes YAML-fájlok helyzetéhez. Egyszerűbb ugyanazt a YAML fájlt megírni, hozzáadni néhány helyőrzőt, amelybe a Helm behelyettesíti az értékeket. Ez azt jelenti, hogy a nagy állványkészlet helyett egy sablonkészlet lesz, amelybe a szükséges értékeket a megfelelő időben behelyettesítik.
Harmadszor Helm - bevetési mester. Ezzel telepítheti, visszaállíthatja és frissítheti az alkalmazásokat. Találjuk ki, hogyan kell ezt megtenni.
Hogyan használhatja a Helmet saját alkalmazásai telepítéséhez
A hivatalos utasításokat követve telepítsük a Helm klienst a számítógépére . Ezután létrehozunk egy YAML-fájlkészletet. Konkrét értékek megadása helyett helyőrzőket fogunk hagyni, amelyeket a Helm a jövőben tölt meg információkkal. Az ilyen fájlok halmazát Helm diagramnak nevezzük. Háromféleképpen küldhető el a Helm konzolkliensnek:
- jelöljön meg egy mappát sablonokkal;
- csomagolja be az archívumot egy .tar fájlba, és mutasson rá;
- helyezze el a sablont egy távoli lerakatba, és adjon hozzá egy hivatkozást a lerakatra a Helm kliensben.
Szüksége van egy értékekkel rendelkező fájlra is - értékek.yaml. Az onnan származó adatok bekerülnek a sablonba. Alkossunk mi is.
A Helm második verziója egy további szerveralkalmazással rendelkezik - a Tiller. A Kubernetesen kívül lefagy, és várja a Helm klienstől érkező kéréseket, és amikor hívják, behelyettesíti a szükséges értékeket a sablonba, és elküldi a Kubernetesnek.
A Helm 3 egyszerűbb: a sablonok szerveren történő feldolgozása helyett az információk feldolgozása teljes egészében a Helm kliens oldalán történik, és közvetlenül a Kubernetes API-nak küldik el. Ez az egyszerűsítés javítja a fürt biztonságát és megkönnyíti a bevezetési sémát.
Hogyan működik mindez
Futtassa a parancsot helm install. Jelöljük meg az alkalmazás kiadásának nevét, és adjuk meg a értékeket.yaml elérési útját. A végén jelezzük a tárat, amelyben a diagram található, és a diagram nevét. A példában ezek „lmru” és „bestchart”.
helm install --name bestapp --values values.yaml lmru/bestchart
A parancs csak egyszer hajtható végre, ha helyette újra install kell használni upgrade. Az egyszerűség kedvéért két parancs helyett futtathatja a parancsot upgrade kiegészítő kulccsal --install. Az első végrehajtáskor a Helm parancsot küld a kiadás telepítéséhez, és a jövőben frissíteni fogja.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Az alkalmazások új verzióinak Helmmel való üzembe helyezésének buktatói
A történetnek ezen a pontján a Ki akar lenni milliomos című filmet játszom a közönséggel, és azon gondolkodunk, hogyan vehetjük rá Helmet az alkalmazás verziójának frissítésére. .
Amikor megtanultam, hogyan működik a Helm, meglepődtem a furcsa viselkedésen, amikor futó alkalmazások verzióit próbáltam frissíteni. Frissítettem az alkalmazás kódját, feltöltöttem egy új képet a Docker registry-be, elküldtem a telepítési parancsot - és semmi sem történt. Az alábbiakban bemutatunk néhány nem teljesen sikeres módszert az alkalmazások frissítésére. Mindegyiket részletesebben tanulmányozva elkezdi megérteni a műszer belső felépítését és ennek a nem nyilvánvaló viselkedésnek az okait.
1. módszer. Ne változtassa meg az információkat az utolsó indítás óta
Ahogy mondja Helm: „A Kubernetes diagramok lehetnek nagyok és összetettek, ezért Helm igyekszik semmihez sem nyúlni túl sokat.” Ezért, ha frissíti az alkalmazás lemezképének legújabb verzióját a docker beállításjegyzékében, és futtatja a parancsot helm upgrade, akkor nem lesz semmi. Helm úgy gondolja, hogy semmi sem változott, és nem kell parancsot küldeni a Kubernetesnek az alkalmazás frissítéséhez.
Itt és lent a legújabb címke csak példaként látható. Ha megadja ezt a címkét, a Kubernetes minden alkalommal letölti a képet a docker-nyilvántartásból, az imagePullPolicy paramétertől függetlenül. A legújabb gyártású termékek használata nem kívánatos, és mellékhatásokat okoz.
2. módszer. Frissítse a LABEL-t a képen
Ahogy ugyanebben írják , "A Helm csak akkor frissít egy alkalmazást, ha az megváltozott a legutóbbi kiadás óta." Ennek logikus megoldása a LABEL frissítése magában a docker-képben. Helm azonban nem néz bele az alkalmazásképekbe, és fogalma sincs a rajtuk lévő változtatásokról. Ennek megfelelően a képen lévő címkék frissítésekor a Helm nem tud róluk, és az alkalmazásfrissítési parancsot sem küldi el a Kubernetes.
3. módszer: Használjon kulcsot --force
Lapozzuk át a kézikönyveket, és keressük meg a szükséges kulcsot. A kulcs a legértelmesebb --force. A nyilvánvaló név ellenére a viselkedés eltér a várttól. Az alkalmazásfrissítés kényszerítése helyett annak valódi célja a SIKERTELEN állapotú kiadás visszaállítása. Ha nem használja ezt a billentyűt, akkor a parancsokat egymás után kell végrehajtania helm delete && helm install --replace. Javasolt helyette a kulcs használata --force, amely automatizálja e parancsok egymás utáni végrehajtását. Bővebb információ ebben . Sajnos ez a kulcs nem fog működni annak érdekében, hogy a Helmnek utasítsa az alkalmazás verziójának frissítését.
4. módszer: Változtassa meg a címkéket közvetlenül a Kubernetesben
Címke frissítése közvetlenül a fürtben a paranccsal kubectl edit - rossz ötlet. Ez a művelet inkonzisztenciát eredményez a futó alkalmazás és az eredetileg telepítésre küldött alkalmazás között. A Helm viselkedése a telepítés során ebben az esetben eltér a verziójától: a Helm 2 nem tesz semmit, a Helm 3 pedig az alkalmazás új verzióját fogja telepíteni. Ahhoz, hogy megértsük, miért, meg kell értened, hogyan működik a Helm.
Hogyan működik a Helm?
Annak megállapítására, hogy egy alkalmazás változott-e a legutóbbi kiadása óta, a Helm a következőket használhatja:
- alkalmazás futtatása Kubernetesben;
- új értékek.yaml és aktuális diagram;
- Helm belső kiadási információi.
A kíváncsibbak számára: hol tárolja a Helm a kiadásokkal kapcsolatos belső információkat?A parancs végrehajtásával helm history, minden információt megkapunk a Helm segítségével telepített verziókról.
Az elküldött sablonokról és értékekről is részletes információ található. Kérhetjük:
A Helm második verziójában ezek az információk ugyanabban a névtérben találhatók, ahol a Tiller fut (alapértelmezés szerint kube-rendszer), a ConfigMap-ben, „OWNER=TILLER” címkével jelölve:
Amikor megjelent a Helm harmadik verziója, az információ a titkokba került, és ugyanabba a névtérbe, ahol az alkalmazás futott. Ennek köszönhetően lehetővé vált több alkalmazás egyidejű futtatása különböző névterekben, azonos kiadásnévvel. A második verzióban komoly fejtörést okozott, amikor a névterek elszigeteltek, de befolyásolhatják egymást.
A második Helm, amikor megpróbálja megérteni, hogy szükség van-e frissítésre, csak két információforrást használ: azt, amit most biztosítanak, és a kiadásokról szóló belső információkat, amelyek a ConfigMap-ben találhatók.
A harmadik Helm háromirányú egyesítési stratégiát használ: ezen információkon kívül figyelembe veszi a Kubernetesben éppen futó alkalmazást is.
Emiatt a Helm régi verziója nem tesz semmit, mivel nem veszi figyelembe a fürtben lévő alkalmazásinformációkat, de a Helm 3 megkapja a változtatásokat, és elküldi az új alkalmazást telepítésre.
5. módszer. Használja a --recreate-pods kapcsolót
Kulccsal --recreate-pods a kulccsal elérheti azt, amit eredetileg el akart érni --force. A tárolók újraindulnak, és az imagePullPolicy: Mindig a legújabb címkére vonatkozó szabályzatának megfelelően (erről bővebben a fenti lábjegyzetben) a Kubernetes letölti és elindítja a kép új verzióját. Ez nem a legjobb módon fog megtörténni: a StrategyType telepítési mód figyelembevétele nélkül hirtelen kikapcsol minden régi alkalmazáspéldányt, és újakat indít el. Az újraindítás során a rendszer nem fog működni, a felhasználók szenvedni fognak.
Magában a Kubernetesben is hasonló probléma állt fenn sokáig. És most, 4 évvel a nyitás után , a probléma kijavított, és a Kubernetes 1.15-ös verziójától kezdve megjelenik a podok görgetéses újraindításának lehetősége.
A Helm egyszerűen kikapcsol minden alkalmazást, és új konténereket indít el a közelben. Ezt nem teheti meg éles üzemben, hogy ne okozzon leállást az alkalmazásokban. Ez csak fejlesztési igényekhez szükséges, és csak színpadi környezetben hajtható végre.
Hogyan frissíthető az alkalmazás verziója a Helm segítségével?
Módosítjuk a Helmnek küldött értékeket. Általában ezek olyan értékek, amelyeket a képcímke helyett helyettesítenek. A legfrissebb, nem produktív környezetekben gyakran használt változat esetében a változtatható információ egy megjegyzés, ami magának a Kubernetesnek haszontalan, a Helm számára pedig jelzésként szolgál az alkalmazás frissítésének szükségességére. A megjegyzés értékének kitöltési lehetőségei:
- Véletlenszerű érték a standard funkció használatával -
{{ randAlphaNum 6 }}.
Van egy figyelmeztetés: minden ilyen változót tartalmazó diagram használatával történő telepítés után a megjegyzés értéke egyedi lesz, és Helm azt feltételezi, hogy változások történtek. Kiderült, hogy mindig újraindítjuk az alkalmazást, még akkor is, ha nem változtattunk a verzióján. Ez nem kritikus, mivel nem lesz leállás, de ez így is kellemetlen. - Beillesztési áram dátum és idő -
{{ .Release.Date }}.
Egy változat hasonló egy véletlenszerű értékhez, amelynek állandóan egyedi változója van. - Helyesebb módja a használat ellenőrző összegeket. Ez a kép SHA-ja vagy az utolsó véglegesítés SHA-ja a gitben -
{{ .Values.sha }}.
Ezeket meg kell számolni és el kell küldeni a hívó oldalon lévő Helm kliensnek, például Jenkinsben. Ha az alkalmazás megváltozott, akkor az ellenőrző összeg is megváltozik. Ezért a Helm csak szükség esetén frissíti az alkalmazást.
Foglaljuk össze próbálkozásainkat
- A Helm a legkevésbé invazív módon hajtja végre a változtatásokat, így a Docker Registry alkalmazásképszintjén végzett változtatások nem eredményeznek frissítést: a parancs végrehajtása után semmi sem történik.
- kulcs
--forcea problémás kiadások visszaállítására szolgál, és nem kapcsolódik a kényszerített frissítésekhez. - kulcs
--recreate-podserőszakosan frissíti az alkalmazásokat, de vandál módon teszi: hirtelen kikapcsol minden konténert. A felhasználók szenvedni fognak ettől; ezt nem szabad megtenni az éles környezetben. - Módosítsa közvetlenül a Kubernetes-fürtöt a paranccsal
kubectl editne: megtörjük a konzisztenciát, és a viselkedés a Helm verziójától függően eltérő lesz. - A Helm új verziójának megjelenésével számos árnyalat jelent meg. A Helm repository problémái érthető nyelven vannak leírva, segít megérteni a részleteket.
- Szerkeszthető megjegyzés hozzáadása a diagramhoz rugalmasabbá teszi azt. Ez lehetővé teszi az alkalmazás megfelelő, állásidő nélküli kihelyezését.
Az élet minden területén működő „világbéke” gondolat: használat előtt olvassa el az utasításokat, ne utána. Csak teljes körű információk birtokában lehet megbízható rendszereket felépíteni és a felhasználókat boldoggá tenni.
Egyéb kapcsolódó linkek:
Ezt a jelentést először a a Mail.ru Cloud Solutions által. Néz egyéb előadásokat, és iratkozzon fel a Telegram eseményhirdetéseire .
Forrás: will.com