Infrastruktúra rugalmasságának megvalósítása a Kubernetes használatával
Az infrastruktúra-alapú rugalmasság megvalósításához használhat szolgáltatáshálót. A kód módosítása nélküli rugalmasság mellett a szolgáltatásháló forgalomkezelést, szabályzatot, biztonságot, erős identitást és megfigyelhetőséget biztosít. Az alkalmazás leválasztva van ezekről az üzemeltetési képességekről, amelyeket az infrastruktúra rétegbe helyez át. Architektúra szempontból a szolgáltatásháló két összetevőből áll: egy vezérlősíkból és egy adatsíkból.
A vezérlősík-összetevő számos olyan összetevővel rendelkezik, amelyek támogatják a szolgáltatásháló kezelését. Az összetevők leltára általában a következőket tartalmazza:
- Felügyeleti felület, amely lehet felhasználói felület vagy API.
- Szabályok és szabályzatdefiníciók, amelyek meghatározzák, hogy a szolgáltatáshálónak hogyan kell implementálnia bizonyos képességeket.
- Biztonsági felügyelet az olyan dolgokhoz, mint az erős identitások és az mTLS-tanúsítványok.
- Metrikák vagy megfigyelési képességek az alkalmazásokból való adatok gyűjtésére és összesítésére.
Az adatsík-összetevő az egyes szolgáltatások mellett transzparensen injektált proxykból áll, amelyeket Sidecar-minta néven ismerünk. Minden proxy úgy van konfigurálva, hogy szabályozza a szolgáltatást tartalmazó pod bejövő és kimenő hálózati forgalmát. Ez a konfiguráció lehetővé teszi az egyes proxyk konfigurálását a következőre:
- A forgalom biztonságossá tételét az mTLS-en keresztül.
- Dinamikusan irányítsa a forgalmat.
- Szabályzatok alkalmazása a forgalomra.
- Metrikák és nyomkövetési információk gyűjtése.
A Kubernetes-fürtök népszerű szolgáltatásháló-opciói közé tartozik a Linkerd, az Istio és a Consul. Ez a modul a Linkerdre összpontosít. Az alábbi diagram az adat- és vezérlősíkok összetevői közötti interakciókat mutatja be:
A kódalapú megközelítések összehasonlítása
A Linkerd fő hibakezelési stratégiája újrapróbálkozásokból és időtúllépésekből áll. Azért, mert a Linkerd átfogó képet nyújt a teljes fürtről, újszerű rugalmassági megközelítéseket alkalmazhat. Ilyen például az újrapróbálkozás, amely legfeljebb 20 százalékos többletterhelést ad hozzá a célszolgáltatáshoz. Linkerd metrikákon alapuló nézete lehetővé teszi, hogy a cluster feltételeihez valós időben dinamikusan alkalmazkodjon. Ez a megközelítés egy másik dimenziót növel a fürt kezeléséhez, de nincs szükség kód hozzáadására.
Kódalapú megközelítéssel, például Pollyval:
- Meg kell határoznia, hogy mely újrapróbálkozások és időtúllépési paraméterek megfelelőek.
- Összpontosítson egy adott HTTP-kérésre.
Az alkalmazás kódjában nem lehet ésszerű módon reagálni az infrastruktúra meghibásodására. Vegye figyelembe az egyidejűleg feldolgozott kérések százait vagy ezreit. Még az exponenciális visszakapcsolással (időkérések száma) rendelkező újrapróbálkozások is eláraszthatják a szolgáltatást.
Ezzel szemben az olyan infrastruktúra-alapú megközelítések, mint a Linkerd, nem ismerik az alkalmazások belső funkcióit. Az összetett adatbázis-tranzakciók például nem láthatók a Linkerd számára. Az ilyen tranzakciók Polly segítségével védhetők a hibáktól.
A következő egységekben a Polly és a Linkerd használatával valósítja meg a kuponszolgáltatás rugalmasságát.