Infrastruktúra rugalmasságának megvalósítása a Kubernetes használatával
Az infrastruktúraalapú rugalmasság megvalósításához szolgáltatási hálót használhat. A kódmódosítás nélküli rugalmasság mellett a szolgáltatási háló forgalomkezelést, szabályzatokat, biztonságot, erős identitást és megfigyelhetőséget is nyújt. Az alkalmazást leválasztja ezekről a műveleti funkciókról, amelyek átkerülnek az infrastruktúrarétegre. Az architektúra szempontjából a szolgáltatási há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 jellemzően az alábbiakat tartalmazza:
- Egy 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ási háló hogyan valósítson meg bizonyos funkciókat.
- Biztonságkezelés olyan dolgokhoz, mint az erős identitás és az mTLS-tanúsítványok.
- Metrikák vagy megfigyelhetőség az alkalmazásokból származó összesítő mérőszámokhoz és telemetriai adatokhoz.
Az adatsík-összetevő olyan proxykból áll, amelyeket az egyes szolgáltatások mellett transzparensen injektálnak; ezt Sidecar-minta néven ismerjük. Minden proxy úgy van konfigurálva, hogy szabályozza a szolgáltatást tartalmazó pod bejövő és kimenő hálózati forgalmát. Ezzel a konfigurációval minden proxy konfigurálható a következőre:
- A forgalom biztonságossá tétele mTLS-szel.
- A forgalom dinamikus irányítása.
- Szabályzatok alkalmazása a forgalomra.
- Metrikák és nyomkövetési adatok gyűjtése.
A Kubernetes-fürtök népszerű szolgáltatási hálója a Linkerd, az Istio és a Consul. Ez a modul a Linkerddel foglalkozik. Az alábbi ábrán az adat- és a vezérlősík összetevőinek interakciói láthatók:
Összehasonlítás a kódalapú megközelítésekkel
A Linkerd fő hibakezelési stratégiája újrapróbálkozásokból és időtúllépésekből áll. Mivel a Linkerd rendszerszintű nézetet mutat a teljes fürtről, újszerű rugalmassági stratégiákat alkalmazhat. Például úgy tud újrapróbálni egy folyamatot, hogy legfeljebb 20%-os további terhelést helyez a célszolgáltatásra. A Linkerd metrikaalapú nézetének köszönhetően dinamikusan és valós időben képes alkalmazkodni a fürtállapotokhoz. Ez a megközelítés új dimenziót nyit a fürtkezelésben, azonban nem ad hozzá kódot.
A kódalapú (például a Pollyval végzett) megközelítésre az alábbiak jellemzők:
- Ki kell találnia, mely újrapróbálkozási és időtúllépési paraméterek megfelelők.
- Egy adott HTTP-kérelemre kell összpontosítania.
Az alkalmazás kódjában nem válaszolhat megfelelően az infrastruktúrahibákra. Figyelembe kell vennie a több száz vagy több ezer egyszerre feldolgozott kérést. Még az exponenciális visszatartásos ú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. A Linkerd számára például láthatatlanok az összetett adatbázis-tranzakciók. Az ilyen tranzakcióknak a Polly nyújthat védelmet a hibák ellen.
A közelgő egységekben a Polly és a Linkerd használatával valósíthatja meg a kuponszolgáltatás rugalmasságát.