Pod, node vagy klaszter: mit irányít át valójában egy VPN-sidecar

Egy VPN-sidecar egy Kubernetes Podban jobb modorú, hostszintű VPN-nek látszik, és a hasonlóság a névtér határánál véget ér. Egy Pod konténerei közös hálózati névteret használnak, beleértve a cím- és portteret is, ezért az útvonalakat és szabályzatot telepítő sidecar valóban megváltoztatja, hová mennek az alkalmazás csomagjai. A node többi Podja számára semmit nem változtat, és a node saját vereméhez sem nyúl, hacsak nem állítja be így. Ennek a határnak a helyes megértése dönti el, mit tud telepíteni és mit kell tesztelnie. A következő szakaszok a névtérből kifelé haladva követik ezt.

Közös névtér, közös következmények

Két konténer egy Podban loopbacken keresztül beszél, és ugyanazokat az interfészeket látja, és éppen ezért működik egyáltalán a sidecar-minta: az alkalmazásnak nem kell tudnia, hogy létezik alagút, mert az az útvonal, amelyre feloldódik, abban a névtérben telepítődött, amelyet használ. Ugyanez a tulajdonság azt jelenti, hogy a sidecar hibái az alkalmazás hibái. Egy túl sokat elkapó útvonal, vagy egy DNS-változás, amely az alagúton belüli feloldóra mutat, azonnal érvényes a Pod minden folyamatára. Közös névtérben nincs konténerenkénti útvonalválasztás, ezért a sidecar nem korlátozható egyetlen folyamatra.

Ez az a mechanizmus, amelyet a felülvizsgálat során észben kell tartani: a hatás sugara a Pod, nem a node és nem a klaszter.

Ahová a sidecar nem ér el

A többi Pod megtartja a saját névterét és saját útvonalválasztását, ezért az azonos kimenetet igénylő munkaterhelésnek ugyanaz a sidecar kell, vagy helyette node-szintű tervezés. A node forgalma is a Pod névterén kívül van, a hosthálózatú Podok pedig szándékosan teljesen kimaradnak ebből az elkülönítésből. Ha a sidecart hosthálózattal futtatja, hogy elérjen valami kényelmeset, a hatókört egy Podról az egész node-ra szélesítette, és ezt hangosan ki kell mondani.

A klaszter szolgáltatásai felé menő forgalom a másik gyakori meglepetés. Egy széles alapértelmezett útvonal a Podban elkaphatja az API-kiszolgálónak vagy egy ClusterIP-szolgáltatásnak szánt kéréseket, amelyek aztán úgy hibáznak, mintha az alagút lenne elromolva.

Útvonalterv: Pod-, szolgáltatás-, node- és VPN-tartományok

Írja le a négy tartományt, és ellenőrizze őket átfedés szempontjából, mielőtt bármit telepítene: Pod CIDR, szolgáltatás CIDR, node-címek és a VPN mögötti célok. A VPN privát tartományai és a klaszter saját tere közötti átfedés nem ritka, és az alapértelmezett útvonal rossz megoldás rá. Az útvonalterv ugyanabba a repóba tartozik, mint a manifest, mert a következő klaszter teljesen más Pod- és szolgáltatástartományokat adhat.

A DNS a terv része, nem külön aggodalom. Egy sidecar, amely átírja a feloldó konfigurációját, elronthatja a szolgáltatásfelderítést a klaszterben, miközben a külső lekérdezések tökéletesen működnek.

Az indítás és a meghibásodás kifejezett állapotok

Egy futó sidecar-folyamat nem kimeneti szabályzat. Döntse el, milyen forgalom áramolhat, mielőtt az alagút elkészül, és mi történik, ha utána meghal, majd hajtsa végre ezt a döntést: az alkalmazáskonténert kapuzó próba, alapértelmezésben elutasító hálózati szabályzat, vagy mindkettő. Ezek egyike nélkül az alkalmazás elindul, felold, és a node szokásos útvonalán küldi ki a forgalmat, miközben az alagút még kapcsolódik.

Ez a rés egészséges klaszterben rövid, törött klaszterben állandó, és pontosan ezt a tulajdonságot kedveli egy támadó vagy egy véletlen adatszivárgás.

Kapcsolja össze a sorrendet egy hibatesszttel. Ölje meg a sidecart, és igazolja, hogy az alkalmazás elveszíti a szándékolt kimenetét, ahelyett hogy csendben visszaesne.

Képességek, szabályzatok és tesztelés az alkalmazáskonténerből

Az interfészek létrehozásához és az útvonalak módosításához szükséges képességek megadása kiváltságkérdés, és az izolált Podhoz illő kiváltság nem feltétlenül illik a node veremére. Használja a klaszter által támogatott hálózati és biztonsági szabályzat-megoldásokat, és ne feltételezze, hogy minden CNI- vagy szabályzat-implementáció ugyanúgy kezel egy VPN-interfészt; a különbségek éppen azokban a hibaesetekben mutatkoznak meg, amelyek Önnek fontosak.

Teszteljen a valódi alkalmazáskonténerből, friss kérésekkel egy privát célra, egy klaszter-szolgáltatásra és a nyilvános internetre. A sidecarból indított teszt azt bizonyítja, hogy az alagút működik, nem azt, hogy az alkalmazás eléri, amire szüksége van.

Dokumentálja a klaszter hálózati feltevéseit a VPN-konfiguráció mellett. A munkaterhelés másik klaszterbe költöztetése ekkor az útvonalterv ellenőrzésének gyakorlata, nem pedig egy image-változás, amely csendben működésképtelenné válik.