Üdv mindenkinek! A nevem Pavel Agaletckij. Csoportvezetőként dolgozom azon a csapaton, amely a Lamoda szállítási rendszerét fejleszti. 2018-ban a HighLoad++ konferencián beszéltem, és ma szeretném bemutatni az előadásom szöveges átírását.

A témám a vállalatunk tapasztalatait mutatja be különböző környezetekbe történő rendszerek és szolgáltatások telepítéséről. Kezdve a prehistorikus időszaktól, amikor még minden rendszerünket hagyományos virtuális szerverekre telepítettük, egészen a fokozatos átmenetig a Nomadtól a Kubernetesre történő telepítésig. Elmondom, miért tettük ezt, és milyen problémákkal szembesültünk a folyamat során.

Alkalmazások telepítése VM-re

Kezdjük azzal, hogy 3 évvel ezelőtt a cég minden rendszere és szolgáltatása hagyományos virtuális szervereken került telepítésre. Műszakilag úgy volt megszervezve, hogy a rendszereink összes kódja automatizált build eszközökkel, jenkins segítségével készült. Az Ansible segítségével a verziókezelő rendszerünkből telepítettük a virtuális szerverekre. Minden egyes rendszer, amely a cégünknél volt, legalább 2 szerverre került telepítésre: az egyik a head, a másik a tail volt. Ezek a rendszerek teljesen azonosak voltak minden beállításban, teljesítményben, konfigurációban és egyéb paraméterekben. Az egyetlen különbség köztük az volt, hogy a head kapta a felhasználói forgalmat, míg a tail soha nem kapott felhasználói forgalmat.

Miért volt ez így?

Amikor új verziókat telepítettünk az alkalmazásunkból, szerettük volna biztosítani a zökkenőmentes telepítést, vagyis a felhasználók számára észrevehetetlen következményekkel. Ezt úgy értük el, hogy a következő, Ansible által összeállított verziót a tail-re telepítettük. Itt azok, akik a telepítéssel foglalkoztak, meg tudták nézni és megbizonyosodni arról, hogy minden rendben van: az összes metrikus érték, szakasz és alkalmazás működik; a szükséges szkriptek elindulnak. Csak miután megbizonyosodtak arról, hogy minden rendben van, átkapcsolták a forgalmat. A forgalom azon szerverre kezdett áramlani, amely korábban tail volt. Az a szerver, amely korábban head volt, felhasználói forgalom nélkül maradt, de a rajta folyamatban lévő előző verzióval.

Így tehát a felhasználók számára ez zökkenőmentes volt. Mivel a váltás azonnali, mivel csupán a terheléselosztó váltásáról van szó. Nagyon könnyen vissza lehet térni az előző verzióra, csak annyit kell tennie, hogy visszakapcsolja a terheléselosztót. Ezen kívül biztosíthattuk az alkalmazás képességeit a termelés előtt, mielőtt a felhasználói forgalom érkezett volna, ami elég kényelmes volt.

Mik voltak az előnyök, amiket mindezen keresztül láttunk?

1. Először is, ez elég egyszerűen működik. Mindenki számára világos, hogyan működik egy ilyen telepítési séma, mert a legtöbb ember valaha telepített már hagyományos virtuális szerverekre.
2. Ez elég megbízható, mivel a telepítési technológia egyszerű, amelyet ezernyi cég kipróbált. Milliónyi szerver települ így. Nehéz valamit elrontani.
3. Végül, megkaptuk a atomikus telepítéseket. Azok a telepítések, amelyek a felhasználók számára egyszerre történnek, anélkül, hogy észlelni kellene a váltást a régi verzió és az új között.

De mindezekben láttunk néhány hátrányt is:

1. A termelési környezeten kívül, léteznek más környezetek is, mint például a qa és preproduction. Akkoriban sok szerverünk és körülbelül 60 szolgáltatásunk volt. Ezért kellett minden szolgáltatás számára fenntartani a számára releváns verziót a virtuális gépből. Ráadásul, ha frissíteni akarja a könyvtárakat vagy új függőségeket szeretne telepíteni, akkor ezt minden környezetben meg kell tennie. Időben is szinkronizálni kellett, amikor új verziót akartunk telepíteni az alkalmazásunkból, a devops által szükséges környezeti beállítással. Így könnyen olyan helyzetbe kerülhetünk, amikor a környezetünk több szempontból is eltérhet egymástól a különböző környezetekben. Például a QA környezetben más könyvtár verziók lesznek, mint a termelésben, ami problémákhoz vezethet.
2. A függőségek frissítésének nehézsége a kiválasztott alkalmazásában. Ez nem rajtad múlik, hanem egy másik csapaton. Nevezetesen a devops csapaton, amely a szervereket támogatja. Meg kell fogalmaznia számukra a megfelelő feladatot, és meg kell adnia a leírást arról, mit szeretne tenni.
3. Akkoriban azt is szerettük volna, hogy a meglévő nagy monolitokat kisebb szolgáltatásokra osszuk, mivel tudtuk, hogy ezek száma folyamatosan növekedni fog. Akkor már több mint 100 szolgáltatásunk volt. Minden új szolgáltatáshoz külön virtuális gépet kellett létrehozni, amit szintén karbantartani és telepíteni kellett. Ezen kívül nem egy, hanem legalább két gépre volt szükség. Ehhez jött még a QA környezet is. Ez problémákat okozott, és megnehezítette az új rendszerek létrehozását és indítását. A folyamat így bonyolultabbá, költségesebbé és időigényesebbé vált.

Ezért úgy döntöttünk, hogy célszerűbb a hagyományos virtuális gépek telepítése helyett a docker konténerekbe való alkalmazás-deploy-ra váltani. A docker használatával olyan rendszerre van szükség, amely képes az alkalmazást klaszterben futtatni, mivel nem lehet egyszerűen csak úgy elindítani egy konténert. Általában szeretnénk figyelni, hogy hány konténer van futásban, hogy automatikusan elinduljanak. Ezért szükségünk volt egy irányító rendszer kiválasztására.

Hosszan töprengtünk azon, hogy melyiket válasszuk. Az a helyzet, hogy akkoriban ez a telepítési technológia a hagyományos virtuális szerverekre elavultnak számított, mivel nem a legfrissebb operációs rendszereket használtuk. Valamikor még FreeBSD-t is használtunk, amit nehezen lehetett karbantartani. Megértettük, hogy minél előbb át kell migrálnunk a dockerra. A DevOps csapatunk a meglévő tapasztalataik alapján választotta a Nomad nevű megoldást.

Átállás a Nomadra

A Nomad a "HashiCorp" cégtől származó termék. Ezenkívül más megoldásaikról is ismertek:

"Consul" — ez egy szolgáltatásfelfedező eszköz.

"Terraform" — szerverkezelő rendszer, amely lehetővé teszi a konfigurációval történő beállításokat, amit infrastructure-as-code-nak neveznek.

"Vagrant" — lehetővé teszi virtuális gépek helyi vagy felhőbeli telepítését bizonyos konfigurációs fájlok segítségével.

Abban az időben a Nomad elég egyszerű megoldásnak tűnt, amelyre gyorsan át lehetett állni anélkül, hogy az egész infrastruktúrát meg kellett volna változtatni. Ráadásul viszonylag könnyen elsajátítható. Ezért ezt választottuk a konténerünk szűrőrendszereként.

Mi szükséges ahhoz, hogy egyáltalán telepíthessük a rendszert a Nomadban?

1. Mindenekelőtt szükség van docker image-re az alkalmazásához. Össze kell állítani, és el kell helyezni a docker képek tárolójában. Ebben az esetben ez az artifactory – egy olyan rendszer, amely lehetővé teszi különböző típusú artefaktumok feltöltését. Képes archiválásokat, docker képeket, PHP composer csomagokat, NPM csomagokat stb. tárolni.
2. Továbbá szükséges konfigurációs fájl, amely megmondja a Nomad-nak, hogy mit, hová és milyen mennyiségben szeretne telepíteni.

Amikor a Nomad-ról beszélünk, az információs fájl formátumaként HCL nyelvet használ, ami az alábbiakat jelenti HashiCorp Configuration Language. Ez egy Yaml-ra épülő szuperhalmaz, amely lehetővé teszi, hogy a szolgáltatását Nomad kifejezéseivel írja le.

Ez megmondja, hogy hány konténert szeretne telepíteni, mely képekből kell átadnia nekik különböző paramétereket a telepítés során. Tehát ezt a fájlt kapja meg a Nomad, és ennek megfelelően indítja el a konténereket a termelésben.

Az esetünkben rájöttünk, hogy nem lenne kényelmes minden szolgáltatáshoz ugyanazokat, azonos HCL fájlokat írni, mivel sok a szolgáltatás, és néha szeretnénk frissíteni őket. Előfordul, hogy egy szolgáltatás nem egy példányban, hanem több különbözőben van telepítve. Például az egyik rendszerünk, amely a termelésben van, több mint 100 példánnyal rendelkezik. Azonos képekből indulnak, de különböző konfigurációs beállításokkal és konfigurációs fájlokkal rendelkeznek.

Ezért úgy döntöttünk, hogy kényelmesebb lenne tárolni az összes konfigurációs fájlunkat egy közös tárolóban. Így láthatóvá váltak: könnyen karbantarthatóvá váltak, és láthattuk, milyen rendszereink vannak. Szükség esetén nem volt nehéz valamit frissíteni vagy megváltoztatni. Új rendszert is egyszerű hozzáadni – elég, ha létrehoz egy konfigurációs fájlt egy új könyvtáron belül. Abban találhatók a fájlok: service.hcl, amely a szolgáltatásunk leírását tartalmazza, és néhány env-fájl, amelyek lehetővé teszik a szolgáltatás beállítását, amikor az a termelésben van.

Néhány rendszerünk azonban nem egy példányban, hanem több példányban került telepítésre a termelésben. Ezért úgy döntöttünk, hogy nem a konfigurációkat tiszta formában, hanem a sablonosított formájukban tároljuk. A sablonkezelő nyelvként pedig a jinja 2. Ilyen formátumban tároljuk a szolgáltatás konfigurációs fájljait és a szükséges env-fájlokat.

Ezenkívül egy közös deploy scriptet helyeztünk el a repóban, amely lehetővé teszi, hogy a szolgáltatását a megfelelő környezetbe, a megfelelő célnak megfelelően indítsa és telepítse. Amikor a HCL-konfigurációt sablonra alakítottuk, a korábban hagyományos Nomad konfiguráció HCL-fájlja némileg megváltozott.

Tehát kicseréltük a konfiguráció néhány változóját olyan változókra, amelyek az env-fájlokból vagy más forrásokból származnak. Ezen kívül lehetőségünk nyílt dinamikusan generálni az HCL-fájlokat, tehát nemcsak hagyományos változóbeillesztéseket alkalmazhatunk. Mivel a jinja támogatja a ciklusokat és feltételeket, a konfigurációs fájlokat is így készíthetjük, amelyek a telepített alkalmazások helyétől függően változnak.

Például, ha a szolgáltatását a preporduction és production környezetekbe kívánja telepíteni. Tegyük fel, hogy a preporduction környezetben nem szeretné futtatni a cron-skripteket, hanem csak a szolgáltatást szeretné látni egy külön domainen, hogy megbizonyosodjon arról, hogy működik. Aki telepíti a szolgáltatást, annak a folyamat nagyon egyszerű és átlátható. Elég, ha végrehajtja a deploy.sh fájlt, megadva, hogy melyik szolgáltatást szeretné telepíteni és melyik célnak. Például, ha egy rendszert szeretne telepíteni Oroszországba, Beloruszba vagy Kazahsztánba. Ehhez elég, ha megváltoztatja az egyik paramétert, és összegyűlik a megfelelő konfigurációs fájl.

Amikor a Nomad szolgáltatás már telepítve van a klaszterbe, a következőt mutatja.

Első lépésként szüksége van egy külső terheléselosztóra, amely fogadja a felhasználói forgalmat. Ez együtt fog működni a Consul-al, és megtudja tőle, hogy hol, melyik noden, milyen IP-cím alapján határozza meg a helyet helyezkedik el a konkrét szolgáltatás, amely összefügg a meghatározott domain névvel. A Consul-ban a szolgáltatások a Nomad-ból származnak. Mivel ezek ugyanannak a cégnek a termékei, jól kapcsolódnak egymáshoz. Azt mondhatjuk, hogy a Nomad alapértelmezés szerint regisztrálja az összes benne futó szolgáltatást a Consul-ban.

Miután a külső terheléselosztónk megtudta, hogy melyik szolgáltatásba kell irányítani a forgalmat, az megfelelő konténerre vagy konténerekre irányítja azt, amelyek a te alkalmazásodnak felelnek meg. Természetesen közben a biztonságra is gondolni kell. Még ha minden szolgáltatás ugyanazon virtuális gépeken fut is konténerekben, általában meg kell tiltani a szolgáltatások közötti szabad hozzáférést. Ezt szegmentálással értük el. Minden szolgáltatás saját virtuális hálózaton futott, ahol a vonatkozó útválasztási szabályok és a más rendszerekhez és szolgáltatásokhoz való hozzáférési engedélyezési/tiltási szabályok szerepeltek. Ezek lehettek a klaszter belsejében vagy kívül. Például, ha meg akarod akadályozni, hogy egy szolgáltatás csatlakozzon egy bizonyos adatbázishoz, ezt hálózati szegmentálással lehet megtenni. Tehát még véletlenül sem tudsz csatlakozni a tesztkörnyezetből a gyártási adatbázisodhoz.

Mennyibe került nekünk a váltás emberi erőforrás szempontjából?

Körülbelül 5-6 hónapunkba telt a céget teljesen a Nomadra átállítani. Szolgáltatásonként váltottunk, de elég gyors ütemben. Minden csapat saját konténereket kellett, hogy készítsen a szolgáltatásaikhoz.

Nálunk az a megközelítés érvényesül, hogy minden csapat önállóan felelős a saját rendszereik docker képeiért. A devops csapat viszont a telepítéshez szükséges általános infrastruktúrát biztosítja, azaz a klaszter támogatását, a CI rendszer támogatását és így tovább. Akkoriban több mint 60 rendszerünk költözött a Nomadra, körülbelül 2000 konténer alakult meg.

A devops csapat felelős a telepítéssel, a szerverekkel kapcsolatos általános infrastruktúráért. A fejlesztőcsapat pedig a saját konkrét rendszeréhez tartozó konténerek megvalósításáért felel, mivel ők tudják, hogy mit is akarnak az adott konténerben.

A Nomad elhagyásának okai

Milyen előnyöket nyertünk a Nomad és a docker használatával történő telepítés során?

1. Mi biztosítottuk az azonos feltételeket minden környezetben. A fejlesztésben, QA környezetben, előprodukcióban és produkcióban ugyanazokat a konténerképeket és azokkal az azonos függőségeket használják. Ennek megfelelően gyakorlatilag nincs esély arra, hogy a produkcióba olyan kerül, amit korábban helyben vagy a tesztkörnyezetben teszteltek.
2. Azt is megállapítottuk, hogy elegendő könnyen hozzáadni egy új szolgáltatást.. Bármilyen új rendszer szempontjából a telepítés nagyon egyszerűen indul. Csak annyit kell tennie, hogy bemegy a konfigurációkat tároló repóba, hozzáad egy új konfigurációt az Ön rendszeréhez, és már készen is áll. A DevOps számára nem jelent plusz erőfeszítést, hogy a rendszerét a produkcióba telepítse.
3. Transzparens árak konfigurációs fájlok egy közös repóban áttekinthetővé váltak. Abban a pillanatban, amikor a rendszereinket telepítettük virtuális szerverek, Ansible-t használtunk, ahol a konfigurációk ugyanabban a repóban voltak. Azonban a legtöbb fejlesztő számára ennek kezelése kicsit nehezebb volt. A konfigurációk és a kód mennyisége, amelyet hozzá kell adni a szolgáltatás telepítéséhez, sokkal kisebb lett. Plusz a DevOps számára rendkívül egyszerű javítani vagy módosítani. Például, ha új verzióra váltanak a Nomad esetében, tömegesen frissíthetik az összes operációs fájlt, amely ugyanabban a helyen található.

De néhány hátránnyal is szembesültünk:

Kiderült, hogy mi nem tudtuk elérni a deployok zökkenőmentességét a Nomad esetében. Amikor a konténereket különböző környezetekből tolták ki, előfordulhatott, hogy az elindult, és a Nomad már készen állt a forgalom fogadására. Ez még azelőtt történt, hogy a benne lévő alkalmazás elindult volna. Emiatt a rendszer rövid időre 500-as hibákat kezdett el kiadni, mert a forgalom olyan konténerekhez kezdett el menni, amelyek még nem voltak készen a fogadásra.

Találkoztunk néhány hibával.A legfontosabb hiba abban rejlik, hogy a Nomad nem kezeli jól a nagy klasztert, ha sok rendszered és konténered van. Amikor egy, a Nomad klaszterébe tartozó szervert szeretnél karbantartásra kivenni, meglehetősen nagy a valószínűsége, hogy a klaszter nem fog jól érezni magát, és szétesik. Egyes konténerek például összeomolhatnak, és nem indulnak újra — ez később nagyon drágán fog kijönni, ha minden rendszered éppen a Nomad által kezelt klaszterben fut a termelésben.

Ezért úgy döntöttünk, hogy elgondolkodunk, merre tovább. Ekkor már sokkal jobban tudtuk, mit szeretnénk elérni. Nevezetesen: megbízhatóságra, egy kicsit több funkcióra, mint amit a Nomad biztosít, és egy érettebb, stabilabb rendszerre vágyunk.

E tekintetben a Kubernetes-re esett a választásunk, mint a legnépszerűbb platformra a klaszterek futtatásához. Főleg azért, mert a konténereink mérete és száma elég nagy volt. Ilyen célokra a Kubernetes tűnt a legmegfelelőbb rendszernek azok közül, amiket megvizsgálhattunk.

Átállás a Kubernetes-re

Kicsit mesélek a Kubernetes alapfogalmairól, és arról, hogyan különböznek a Nomadtól.

Elsősorban a Kubernetes legalapvetőbb fogalma a pod. Pod — egy vagy több konténer csoportja, amelyek mindig együtt indulnak el. Úgy működnek, mintha mindig egyetlen virtuális gépen lennének. Egymás számára a 127.0.0.1 IP-címen, különböző portokon érhetők el.

Tegyük fel, hogy van egy PHP-alkalmazásod, amely nginx-ből és php-fpm-ből áll — klasszikus séma. Valószínűleg azt szeretnéd, hogy az nginx és a php-fpm konténerei mindig együtt legyenek. A Kubernetes lehetővé teszi, hogy ezt elérd, ha egy közös pod-ként írod le őket. Pontosan ezt nem tudtuk megvalósítani a Nomad segítségével.

A második fogalom pedig stb.);. A lényeg az, hogy a pod önmagában egy efemer dolog, elindul és eltűnik. Azt akarod, hogy először kill-eld az összes korábbi konténered, majd azonnal indítsd el az új verziókat, vagy fokozatosan szeretnéd őket bevezetni – éppen ezért a deployment fogalma felelős. Ez írja le, hogyan telepíted a pod-okat, milyen mennyiségben és hogyan frissíted őket.

A harmadik fogalom pedig a SystemD inicializálási rendszer számára:A service is essentially your system that accepts some traffic and then directs it to one or more pods corresponding to your service. This means it allows you to state that all incoming traffic for a specific service with a given name should be routed to these specific pods. Additionally, it provides you with traffic balancing. This way, you can run two pods of your application, and all incoming traffic will be evenly distributed among the related pods for that service.

And the fourth main concept is Ingress. This is a service that runs in a Kubernetes cluster. It acts as an external load balancer that handles all incoming requests. Using the Kubernetes API, Ingress can determine where these requests should be sent. Moreover, it does this very flexibly. You can specify that all requests to this host and such a URL should be sent to this service. And those requests coming to this host but on a different URL should be sent to another service.

The coolest thing from the perspective of the application developer is that you can manage all of this yourself. By setting up the Ingress configuration, you can route all traffic arriving at a specific API to individual containers, for example, written in Go. And the traffic coming to the same domain but on another URL can be sent to containers written in PHP, where there's a lot of logic, but they are not very fast.

If we compare all these concepts with Nomad, we can say that the first three concepts together form a Service. The last concept is absent in Nomad itself. We used an external load balancer for this: it could be haproxy, nginx, nginx+, and so on. In the case of Kubernetes, you don't need to introduce this additional concept separately. However, if you look at Ingress internally, it is either nginx, haproxy, or traefik, but built-in within Kubernetes.

All the concepts I described are essentially resources that exist within the Kubernetes cluster. The YAML format is used to describe them in Kubernetes, which is more readable and familiar than the HCL files used in Nomad. Structurally, they describe the same thing in the case of a pod, for example. They indicate – I want to deploy these pods there, with these images, in this quantity.

Ezen kívül megértettük, hogy nem szeretnénk kézzel létrehozni minden egyes erőforrást: deployment, szolgáltatások, Ingress és így tovább. Ehelyett azt akartuk, hogy a telepítés során minden rendszerünket leírhassuk Kubernetes terminológiájában, így nem kell kézzel újra létrehoznunk az összes szükséges erőforrást a megfelelő sorrendben. E célra a Helm rendszert választottuk.

A Helm alapvető fogalmai

A Helm a Kuberneteshez készült. Nagyon hasonlóan működik, mint a programozási nyelvek csomagkezelői. Lehetővé teszi, hogy a szolgáltatást, például az nginx deployment, php-fpm deployment, Ingress konfiguráció és configmap-ek (ez egy olyan entitás, amely lehetővé teszi a környezeti változók és egyéb paraméterek megadását a rendszeredhez) úgynevezett chartok formájában tárolhassuk. Eközben a Helm csomagkezelő a Kubernetes fölött működik. . Tehát nem egy különálló rendszer, hanem csak egy újabb szolgáltatás, amely a klaszterben fut. Az API-ján keresztül interakcióba lépsz vele parancssori utasítással. Az előnye, hogy még ha a helm hibát is jelez, vagy eltávolítod a klaszterből, a szolgáltatásaid nem tűnnek el, mivel a helm valójában csak a rendszer indításáért felelős. A szolgáltatások működését és állapotát továbbra is a Kubernetes biztosítja.Azt is megértettük, hogy

a sablonozás , amelyet korábban saját magunknak kellett megvalósítanunk a jinja integrálásával a konfigurációinkba, a helm egyik alapvető funkciója. Minden olyan konfigurációt, amelyet a rendszereidhez készítesz, a helm sablonként tárol, amelyek egy kicsit hasonlítanak a jinja-ra, de valójában a Go nyelv sablonozását használják, amelyen a helm és a Kubernetes is íródott.A Helm még néhány további fogalmat is bevezet.

A Chart

a szolgáltatásod leírása. Más csomagkezelők esetében ezt csomagnak, bundlenek vagy hasonlónak neveznék. Itt ezt chart-nak hívják. A Values

azok a változók, amelyeket a sablonokból készült konfigurációid összeszereléséhez szeretnél használni. A Release

KiadásMinden alkalommal, amikor egy szolgáltatást helm segítségével telepítünk, az egy incrementális verziót kap. A Helm emlékszik arra, mi volt a szolgáltatás konfigurációja az előző, előző előtti verziókban. Tehát, ha vissza kell lépnünk, elég csak végrehajtani a helm rollback parancsot, megadva neki az előző verziót. Még ha a visszaállítás pillanatában a megfelelő konfiguráció nem is áll rendelkezésre a tárolónkban, a helm még mindig emlékszik arra, hogy mi volt az, és visszaállítja a rendszert az előző verzió állapotára.

Amikor helm-et használunk, a szokásos Kubernetes konfigurációk sablonokká válnak, amelyekben lehetőség van változók, függvények használatára és feltételes operátorok alkalmazására. Így a szolgáltatás konfigurációját a környezet függvényében lehet összeállítani.

A gyakorlatban úgy döntöttünk, hogy egy kissé más megközelítést alkalmazunk, mint a Nomad esetében. Míg a Nomad esetében egy tárolóban tároltuk a telepítési konfigurációkat és az n-változókat, amelyek szükségesek voltak a szolgáltatás telepítéséhez, itt úgy döntöttünk, hogy ezeket két külön tárolóra osztjuk. A 'deploy' tárolóban csak azok az n-változók találhatók, amelyek a telepítéshez szükségesek, míg a 'helm' tárolóban a konfigurációk vagy chartok vannak.

Mit nyertünk ezzel?

Bár a konfigurációs fájlokban nem tárolunk valóban érzékeny adatokat, például adatbázis jelszavakat, ezek Kubernetes titkokként vannak tárolva. Ennek ellenére vannak olyan információk, amelyekhez nem szeretnénk mindenkinek hozzáférést adni. Ezért a 'deploy' tárolóhoz való hozzáférést szigorúbban korlátozzuk, míg a 'helm' tároló csak a szolgáltatás leírását tartalmazza. Ebből kifolyólag ezt biztonságosan nagyobb kör számára is elérhetővé lehet tenni.

Mivel nemcsak a produkciós, hanem más környezetek is rendelkezésünkre állnak, ennek a szétválasztásnak köszönhetően újra felhasználhatjuk a helm-chart-okat, hogy szolgáltatásokat telepítsünk nemcsak a produkciós, hanem például a QA-környezetbe is. Még lokális telepítés céljából is, a használatával Minikube — ez egy olyan eszköz, amely lehetővé teszi a Kubernetes lokális futtatását.

Minden egyes tárolóban elkülönített könyvtárakat hagytunk minden szolgáltatás számára. Ezért minden könyvtárban olyan sablonok találhatók, amelyek a megfelelő diagramhoz kapcsolódnak, és leírják azokat a forrásokat, amelyeket telepíteni kell a rendszerünk indításához. A „deploy” tárolóban csak az env fájlokat hagytuk meg. Esetünkben nem használtunk Jinja alapú sablonkezelést, mert a Helm magától is biztosít sablonkezelést – ez egyik alapvető funkciója.

Hagytunk egy telepítési skriptet – deploy.sh, amely egyszerűsíti és standardizálja a telepítést Helm segítségével. Így bárki, aki telepíteni szeretne, számára a telepítési felület pontosan úgy néz ki, mint a Nomad-alapú telepítéseknél. Ugyanaz a deploy.sh, a szolgáltatásod neve, és ahová telepíteni szeretnéd. Ez azt jelenti, hogy belül a Helm fut. Ő pedig összegyűjti a konfigurációkat a sablonokból, behelyettesíti a szükséges values fájlokat, majd telepíti őket a Kubernetesbe.

Következtetések

A Kubernetes szolgáltatás bonyolultabbnak tűnik, mint a Nomad.

Itt a kimenő forgalom az Ingressbe érkezik. Ez a frontkontroller, amely minden kérést fogad, és később a megfelelő szolgáltatásokhoz irányítja őket az adott kérés alapján. Ezeket a konfigurációk alapján határozza meg, amelyek a Helmben az alkalmazásod leírásának részét képezik, és amelyeket a fejlesztők önállóan határoznak meg. A szolgáltatás pedig a saját podjaira küldi a kéréseket, vagyis a konkrét konténerekre, kiegyensúlyozva a bejövő forgalmat az összes olyan konténer között, amely a szolgáltatáshoz tartozik. És persze nem szabad megfeledkezni arról sem, hogy a hálózati szintű biztonságból nem szabad lefelé távoznunk. Ezért a Kubernetes klaszterben szegmentáció működik, amely a címkézésen alapul. Minden szolgáltatásnak vannak meghatározott címkéi, amelyekhez a szolgáltatások hozzáférési jogosultságait kötik az adott külső/belső erőforrásokhoz a klaszteren belül vagy kívül.

Átmenet során észrevettük, hogy a Kubernetes rendelkezik mindazokkal a lehetőségekkel, amelyeket a Nomad kínált, amit korábban használtunk, és sok újat is hozzáad. Bővíthető pluginokon keresztül, és valójában egyedi erőforrástípusokkal. Tehát lehetőséged van nemcsak arra, hogy a Kubernetes dobozból kiinduló elemeit használd, hanem saját erőforrást és szolgáltatást készíts, amely az általad létrehozott erőforrással dolgozik. Ez további bővítési lehetőségeket ad a rendszered számára anélkül, hogy újra kellene telepítened a Kubernetest vagy módosításokat kellene végezned.

Egy példa az ilyen használatra a Prometheus, amelyet a Kubernetes klaszterünk belsejében futtatunk. Ahhoz, hogy elkezdje gyűjteni a metrikákat egy bizonyos szolgáltatásról, hozzá kell adnunk a szolgáltatás leírásához egy további erőforrástípust, úgynevezett szolgáltatásfigyelőt. A Prometheus, mivel képes kezelni a Kubernetesben futó egyedi erőforrástípusokat, automatikusan elkezdi gyűjteni a metrikákat az új rendszerről. Ez elég kényelmes.

Az első telepítés, amelyet a Kubernetessel végeztünk, 2018 márciusában volt. Ez idő alatt soha nem tapasztaltunk vele problémát. Elég stabilan működik, lényeges hibák nélkül. Ráadásul tovább bővíthetjük. Jelenleg elegendőek számunkra a benne található lehetőségek, és nagyon tetszik a Kubernetes fejlődési üteme. Jelenleg több mint 3000 konténer található a Kubernetesben. A klaszter több Node-ból áll. Emellett karbantartott, stabil és nagyon ellenőrzött.

Forrás: habr.com