jegyzet fordítás: Ez a Weaveworks áttekintése bemutatja a legnépszerűbb alkalmazáskiterjesztési stratégiákat, és bemutatja, hogyan lehet a legfejlettebbeket megvalósítani a Kubernetes Flagger operátor segítségével. Egyszerű nyelven íródott, és olyan vizuális diagramokat tartalmaz, amelyek lehetővé teszik, hogy még a kezdő mérnökök is megértsék a problémát.
A diagram innen származik a Container Solutions szolgáltatásban készült bevezetési stratégiák
A felhőalapú natív alkalmazások fejlesztésének egyik legnagyobb kihívása manapság a telepítés felgyorsítása. A mikroszolgáltatási megközelítésben a fejlesztők már teljesen moduláris alkalmazásokkal dolgoznak és terveznek, lehetővé téve a különböző csapatok számára, hogy egyidejűleg írjanak kódot és módosítsanak az alkalmazáson.
A rövidebb és gyakoribb telepítés a következő előnyökkel jár:
- A piacra jutás ideje csökken.
- Az új funkciók gyorsabban elérik a felhasználókat.
- A felhasználói visszajelzések gyorsabban eljutnak a fejlesztőcsapathoz. Ez azt jelenti, hogy a csapat gyorsabban tud hozzáadni funkciókat és kijavítani a problémákat.
- A fejlesztői morál nő: a fejlesztés során több funkcióval szórakoztatóbb dolgozni.
De ahogy a kiadások gyakorisága növekszik, annak az esélye is nő, hogy negatívan befolyásolják az alkalmazás megbízhatóságát vagy felhasználói élményét. Ezért fontos, hogy a műveletek és a DevOps csapatok úgy építsenek fel folyamatokat és kezeljék a telepítési stratégiákat, hogy a minimálisra csökkentsék a termék és a felhasználók kockázatát. (További információ a CI/CD csővezeték automatizálásáról .)
Ebben a bejegyzésben a Kubernetes különböző telepítési stratégiáiról fogunk beszélni, beleértve a gördülő telepítéseket és a fejlettebb módszereket, mint például a Canary bevezetéseket és azok változatait.
Telepítési stratégiák
A céltól függően többféle telepítési stratégia használható. Például előfordulhat, hogy a további teszteléshez módosítania kell egy bizonyos környezetet vagy a felhasználók/kliensek egy részét, vagy korlátozott felhasználói tesztet kell végrehajtania egy funkció létrehozása előtt. nyilvános.
Gördülő (fokozatos, „gördülő” telepítés)
Ez a Kubernetes szabványos telepítési stratégiája. Fokozatosan, egyenként lecseréli az alkalmazás régi verzióját tartalmazó podokat az új verziójú podokra – fürt leállás nélkül.
A Kubernetes megvárja, amíg az új pod-ok készen állnak a működésre (ellenőrzi őket a ), mielőtt elkezdené felgöngyölíteni a régieket. Ha probléma lép fel, ez a folyamatos frissítés megszakítható a teljes fürt leállítása nélkül. A telepítési típust leíró YAML-fájlban az új lemezkép lecseréli a régi lemezképet:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Az átgörgetéses frissítés paraméterei a jegyzékfájlban adhatók meg:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Újra létrehozása
Ennél a legegyszerűbb telepítési típusnál a régi elemeket egyszerre leöli, és újakra cseréli:
A megfelelő manifest valahogy így néz ki:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Kék/zöld (kék-zöld telepítések)
A kék-zöld telepítési stratégia (néha pirosnak/feketének is nevezik) magában foglalja az alkalmazás régi (zöld) és új (kék) verzióinak egyidejű telepítését. Mindkét verzió közzététele után a normál felhasználók hozzáférhetnek a zöldhöz, a kék pedig a minőségbiztosítási csapat rendelkezésére áll a tesztek automatizálásához külön szolgáltatáson vagy közvetlen porttovábbításon keresztül:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"A kék (új) verzió tesztelése és kiadásának jóváhagyása után a szolgáltatás átvált rá, és a zöld (régi) verzió össze van hajtva:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanári (kanári bevetések)
A kanári kiterjesztés hasonló a kék-zöld kiterjesztésekhez, de jobb a vezérlésük és a használatuk lépésről lépésre történő megközelítés. Ez a típus számos különböző stratégiát tartalmaz, beleértve a „lopakodó” indítást és az A/B tesztelést.
Ezt a stratégiát akkor használjuk, ha valamilyen új funkció kipróbálására van szükség, általában az alkalmazás hátterében. A megközelítés lényege, hogy két szinte egyforma szervert kell létrehozni: az egyik szinte minden felhasználót kiszolgál, a másik pedig új funkciókkal csak a felhasználók egy kis alcsoportját szolgálja ki, ami után összehasonlítják a munkájuk eredményét. Ha minden hiba nélkül megy, az új verzió fokozatosan megjelenik a teljes infrastruktúrában.
Bár ez a stratégia kizárólag a Kubernetes használatával megvalósítható, a régi podokat újakra cserélve, sokkal kényelmesebb és egyszerűbb egy olyan szolgáltatáshálót használni, mint az Istio.
Például lehet, hogy két különböző jegyzéke van a Gitben: egy normál jegyzék 0.1.0 címkével és egy kanári jegyzék 0.2.0 címkével. Az Istio virtuális átjáró jegyzékében szereplő súlyok módosításával szabályozhatja a forgalom elosztását a két telepítés között:
A kanári telepítések Istio használatával történő megvalósításához lépésről lépésre szóló útmutatóért lásd: . (Jegyzet. ford.: A kanári kigurítással kapcsolatos anyagokat is lefordítottuk Istio-ra .)
Kanári bevetések a Weaveworks jelzővel
lehetővé teszi a kanári kihelyezések egyszerű és hatékony kezelését.
A jelző automatizálja a velük való munkát. Az Istio vagy az AWS App Mesh segítségével irányítja és váltja a forgalmat, a Prometheus metrikákat pedig az eredmények elemzéséhez. Ezen túlmenően a kanári telepítések elemzése kiegészíthető webhookokkal az átvételi tesztek, terhelési tesztek és bármilyen más típusú ellenőrzés elvégzésére.
A Kubernetes-telepítés és szükség esetén a pod-ok horizontális skálázása (HPA) alapján a Flagger objektumkészleteket hoz létre (Kubernetes-telepítések, ClusterIP-szolgáltatások és Istio vagy App Mesh virtuális szolgáltatások) a Canary-telepítések elemzéséhez és megvalósításához:
A vezérlőkör megvalósítása (vezérlő hurok),Flagger fokozatosan átkapcsolja a forgalmat a Canary szerverre, miközben egyidejűleg méri a kulcsfontosságú teljesítménymutatókat, például a sikeres HTTP-kérelmek arányát, a kérések átlagos időtartamát és a pod-ok állapotát. A KPI (Key Performance Indicators) elemzés alapján a kanári nő vagy összeesik, és az elemzés eredményeit a Slack publikálja. Ennek a folyamatnak a leírása és bemutatása az anyagban található .
Sötét (rejtett) vagy A/B telepítések
A lopakodó telepítés a kanári stratégia másik változata (amivel egyébként a Flagger is működhet). A lopakodó és a kanári telepítések közötti különbség az, hogy a lopakodó telepítések az előtérrel foglalkoznak, nem pedig a háttérrel, mint a canary telepítésekkel.
Ezeknek a telepítéseknek egy másik neve A/B tesztelés. Ahelyett, hogy az új funkciót minden felhasználó számára elérhetővé tennénk, csak korlátozott részüknek kínáljuk. Ezek a felhasználók általában nincsenek tudatában annak, hogy úttörő tesztelők (innen ered a "lopakodó telepítés" kifejezés).
Funkciókapcsolók használata (funkció kapcsoló) és más eszközökkel is nyomon követheti, hogy a felhasználók hogyan lépnek kapcsolatba az új funkcióval, leköti-e őket, vagy nem találják-e zavarónak az új felhasználói felületet, és más típusú mérőszámokat.
Jelző és A/B telepítések
A súlyalapú útválasztáson túl a Flagger HTTP-paraméterek alapján is képes a forgalmat a Canary szerverre irányítani. Az A/B tesztelés során HTTP-fejléceket vagy cookie-kat használhat a felhasználók meghatározott szegmensének megcélzására. Ez különösen hatékony olyan előtér-alkalmazások esetében, amelyek munkamenet-kötést igényelnek a kiszolgálóhoz (munkamenet-affinitás). További információ a bejelentő dokumentációjában található.
A szerző hálás , a Weaveworks mérnöke (és a Flagger megalkotója) mindezekhez a csodálatos telepítési mintákhoz.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com