Megjegyzés: Ez a Weaveworks által készült áttekintő anyag bemutatja a legnépszerűbb alkalmazáskiadási stratégiákat, és beszél a legfejlettebbek megvalósításának lehetőségéről a Kubernetes Flagger operátor segítségével. Egyszerű nyelven íródott, és szemléletes ábrákat tartalmaz, amelyek lehetővé teszik, hogy még a kezdő mérnökök is megértsék a kérdés lényegét.
Az ábra innen származik a kiadási stratégiákról, amelyet a Container Solutions készített
Napjaink egyik legnagyobb problémája a felhőalapú alkalmazások fejlesztésében a telepítések felgyorsítása. Mikroszolgáltatás alapú megközelítés esetén a fejlesztők már teljesen moduláris alkalmazásokkal dolgoznak, és úgy tervezik azokat, hogy különböző csapatok egyszerre írjanak kódot és végezzenek módosításokat az alkalmazáson.
A rövidebb és gyakoribb telepítések a következő előnyökkel járnak:
- Csökken a piacra jutás ideje.
- Az új funkciók gyorsabban eljutnak a felhasználókhoz.
- A felhasználói visszajelzések gyorsabban eljutnak a fejlesztőcsapathoz. Ez azt jelenti, hogy a csapat gyorsabban tudja bővíteni a funkciókat és orvosolni a problémákat.
- Nő a fejlesztők morálja: a több fejlesztés miatt érdekesebb dolgozni.
De a kiadási gyakoriság növekedésével nő a kockázata annak, hogy negatívan befolyásolja az alkalmazás megbízhatóságát vagy a felhasználói élményt. Éppen ezért az üzemeltetési és DevOps csapatoknak fontos, hogy olyan folyamatokat és kiadási stratégiákat építsenek ki, amelyek minimalizálják a termékre és a felhasználókra jelentkező kockázatokat. (Tudjon meg többet a CI/CD pipeline automatizálásáról .)
Ebben a publikációban különböző telepítési stratégiákat fogunk megvitatni Kubernetesben, beleértve a rolling telepítéseket és a fejlettebb módszereket, mint a canary kiadások és azok változatai.
Telepítési stratégiák
Számos különböző típusú telepítési stratégia áll rendelkezésre a céloknak megfelelően. Például szükség lehet arra, hogy módosításokat végezzen egy adott környezetben további tesztelés céljából, vagy egy felhasználói/kliens halmazban, vagy elképzelhető, hogy korlátozott tesztelést kell végezni a felhasználókon, mielőtt egy funkciót nyilvánossá tennének.
Rolling (fokozatos, 'lekerekített' telepítés)
Ez a Kubernetes alkalmazás telepítési stratégiája. Fokozatosan, egymás után cseréli le a régi verziójú podokat az új verziójú podokra – a klaszter leállása nélkül.
A Kubernetes megwaitalja, hogy az új podok készen álljanak a működésre (ellenőrizve őket ), mielőtt elkezdené a régi podok leállítását. Ha probléma merül fel, a hasonló frissítés megszakítható a teljes klaszter leállítása nélkül. A deployment típusú YAML fájlban az új kép lecseréli a régit:
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: 8080A frissítési paramétereket a manifest fájlban lehet pontosítani:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (újra létrehozás)
Ebben a legegyszerűbb telepítési típusban a régi podokat egyszerre megölni és újakkal helyettesítik:
A megfelelő manifest körülbelül így néz ki:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (kék/zöld telepítések)
A kék/zöld telepítési stratégia (más néven piros/fekete) lehetővé teszi a régi (zöld) és az új (kék) verzió egyidejű telepítését. Miután mindkét verziót telepítették, a normál felhasználók a zöldhöz férnek hozzá, míg a kék a QA csapat számára elérhető automatizált tesztekhez egy 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"Miután a kék (új) verziót tesztelték és jóváhagyta a kiadást, a szolgáltatás átvált erre, míg a zöld (régi) leáll:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (kanári telepítések)
A kannári telepítések hasonlóak a kék/zöld telepítésekhez, de jobban kezelhetőek és lépcsős megközelítést alkalmaznak. E típusba különböző stratégiák tartoznak, beleértve a "rejtett" indításokat és az A/B tesztelést.
Ez a stratégia akkor alkalmazható, amikor új funkciók tesztelése szükséges, jellemzően az alkalmazás háttérfüggetlenében. A megközelítés lényege, hogy gyakorlatilag két azonos szervert hozzunk létre: az egyik majdnem minden felhasználót kiszolgál, míg a másik, új funkciókkal rendelkező kis csoport felhasználót, majd összehasonlítjuk a munkájuk eredményeit. Ha minden probléma nélkül zajlik, az új verzió fokozatosan kiterjesztésre kerül az egész infrastruktúrára.
Bár ezt a stratégiát kizárólag Kubernetes eszközeivel is megvalósítható, az új pod-ok lecserélésével sokkal kényelmesebb és egyszerűbb használni egy service mesh-t, mint például az Istio.
Például lehet két különböző manifeszt a Git-ben: egy normál 0.1.0-s címkével, és egy "kanári" 0.2.0-s címkével. A virtuális Istio átjáró manifestben a súlyok módosításával irányíthatjuk a forgalmat a két deployment között:
A kanári telepítések Istio segítségével történő megvalósításához lépésről lépésre útmutatót találhat a következő anyagban . (Megjegyzés fordítás.: Az Istio kanári telepítésekről szóló anyagot is lefordítottuk .)
Kanári telepítések Weaveworks Flagger-rel
egyszerűvé és hatékonnyá teszi a kanári telepítések kezelését.
A Flagger automatizálja ezek működését. Istio-t vagy az AWS App Mesh-t használja a forgalom irányításához és átkapcsolásához, valamint a Prometheus metrikákat az eredmények elemzéséhez. Továbbá, a kanári telepítések elemzését webhooks segítségével is kiegészíthetjük elfogadási tesztek (acceptance), terhelési és más típusú ellenőrzések lefolytatásához.
A Kubernetes deployment alapján, és ha szükséges, a pod-ok vízszintes skálázásával (HPA), a Flagger Kubernetes objektumok (deployment, ClusterIP szolgáltatások és virtuális Istio vagy App Mesh szolgáltatások) csoportjait hozza létre a kanári telepítések elemzéséhez és megvalósításához:
A vezérlési körsor megvalósítása során (control loop), a Flagger fokozatosan átkapcsolja a forgalmat a kanári szerverre, párhuzamosan mérve a kulcsfontosságú teljesítménymutatókat, mint a sikeres HTTP-kérések aránya, a kérelem átlagos időtartama és a pod-ok állapota. A KPI (kulcsfontosságú teljesítménymutatók) elemzése alapján a kanári rész vagy növekszik, vagy csökken, és az elemzés eredményeit Slack-en teszik közzé. A folyamat leírását és bemutatását a következő anyagban találhatja .
Sötét (rejtett) vagy A/B-telepítések
A rejtett telepítés egy újabb változata a kanári stratégiának (amivel a Flagger is képes együttműködni, egyébként). A rejtett és a kanári telepítések közötti különbség az, hogy a rejtett telepítések a frontenddel foglalkoznak, nem pedig a backenddel, mint a kanáriak.
Ezeket a telepítéseket más néven A/B-tesztelésnek is hívják. Ahelyett, hogy minden felhasználónak hozzáférést biztosítanának egy új funkcióhoz, azt csak egy korlátozott csoportnak kínálják. Általában ezek a felhasználók nem tudják, hogy tesztelők, így született a „rejtett telepítés” kifejezés.
Funkcionalitáskapcsolókkal (feature toggles) és egyéb eszközök révén nyomon lehet követni, hogy a felhasználók hogyan lépnek interakcióba az új funkcióval, leköti-e őket vagy zavarosnak találják az új felhasználói felületet, és további mérőszámokat.
Flagger és A/B-telepítések
A súlyozott irányításon kívül a Flagger a kanári szerverre irányíthatja a forgalmat HTTP-paraméterek alapján is. A/B-tesztelés során HTTP-fejléceket vagy sütiket használhatunk a felhasználók bizonyos szegmenseinek átirányítására. Ez különösen hatékony frontend-alkalmazások esetén, amelyek session affinity-t igényelnek a szerverhez. (session affinity). További információk találhatók a Flagger dokumentációjában.
A szerző köszönetét fejezi ki , a Weaveworks mérnöke (és a Flagger alkotója) által készített csodálatos telepítési diagramokért.
Fejlesztési eszközök, amelyek Kubernetesben futnak
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
