Pod-VPN a Kubernetesben vagy kimeneti átjáró: kié az alagút?

Üzembe helyez egy vpn-gateway nevű Podot, egy tesztklienst az címére irányít, és látja, ahogy a csomagok eltűnnek. A manifestben semmi sem hibás, és a kubeletnek nincs kifogása. Az ok szerkezeti, nem konfigurációs: a Kubernetes minden Podnak saját hálózati névteret ad, ezért egy név, egy címke vagy egy közös API-névtér semmit sem változtat azon, hová mennek a csomagok. Ezért a VPN-forgalom klaszterből való kilépéséről szóló döntés a tulajdonjog kérdésével kezdődik, nem a konténerképekével.

Két mechanizmus fedi le a legtöbb valós telepítést, és nem csereszabatosak. Az egyik az alagutat a munkaterhelés saját hálózati névterébe teszi. A másik a CNI-t kéri, hogy a kiválasztott forgalmat egy kijelölt átjáró-csomóponton vezesse át. Másképp hibáznak, másképp skálázódnak és más csapatokhoz tartoznak, ezért a konténerkérdés általában soha le nem záruló vitákat szül.

A Pod határa névtér, nem ugrógép

Egy Linux hálózati névtér birtokolja a saját interfészeit, címeit, útvonalait és tűzfal-szabályait, és minden Pod kap egyet. A Podon belüli konténerek csatlakoznak hozzá, és pontosan ezért tud egy segédkonténer átírni olyan útvonalakat, amelyeket az alkalmazás aztán követ. Egy szomszédos Pod azonosnak látszó, de teljesen különálló vermet kap. Nincs közös tábla, amelyet egy átjáró-Pod örökölhetne, és nincs forgalom implicit átadása egyik névtérből a másikba.

Ezért is csak akkor működik az átjáró-Pod minta, ha valami feljebb valóban csomagokat küld neki: egy Service, egy statikus útvonal a csomóponton vagy irányítási szabály a CNI-ben. Egy cím önmagában semmit sem vonz.

Mit ad az alagút Podonként, és mi az ára

A munkaterhelés névterében futó alagút saját kliensidentitást ad a munkaterhelésnek, amelyet sok távelérési szolgáltatás megkövetel, mielőtt engedélyezne vagy elszámolna egy munkamenetet. A kár sugara is helyi marad: egy törött alagút egy Deploymentet visz ki ahelyett a közös útvonal helyett, amelyet minden használ. Hogyan fut, a megvalósítástól függ, és itt tévednek az emberek.

Egy olyan beállítás, amely csak kernelállapotot igényel, befejeződhet egy init konténerben és kiléphet. Egy felhasználói térben futó démonnak, amelynek a Pod teljes élettartama alatt életben kell maradnia, a Kubernetes 1.29-ben natív oldalkonténerként bevezetett újraindítható init konténer formára van szüksége, és ez a különbség az alagút megvalósításából jön, nem ízlésből. Ennek a modellnek az ára a duplikáció: minden replika hitelesít, saját alagútcímet kap és egy távoli munkamenethelyet foglal el, így egy autoskalálási esemény kapacitáseseménnyé válik a kapcsolat másik oldalán. Egyetlen hitelesítő adat másolása minden replikába nem szünteti meg ezt az árat, hanem eltünteti az auditnyomot. A jogosultságok ugyanezt a vizsgálatot érdemlik, mert egy alagútnak, amely a saját névterében NET_ADMIN akar, semmi oka nincs arra, hogy örökölje a teljes gazdagép fölötti hatalmat egy privileged: true példából.

Amikor a CNI birtokolja a kimenetet

Ha a CNI támogatja, egy kimeneti átjáró munkaterhelés és célútvonal-tartomány szerint választ forgalmat, majd kiválasztott csomópontokon keresztül továbbítja egyetlen kiszámítható forrás-cím alatt. A Cilium verziója a szokásos hivatkozás, és a dokumentációja egyértelműen kimondja, hogy a funkcióhoz meghatározott Cilium-konfiguráció és a megfelelő interfészekkel és címekkel ellátott átjáró-csomópontok kellenek. Azt is megjegyzi, hogy a Pod létrehozása után van egy kezdeti időszak, amikor az irányítás még nem érvényesül, ami tervezési bemenet, nem lábjegyzet.

Olvassa ezt a késleltetést a saját ígéretével szemben. Ha a szabály az, hogy semmilyen forgalom nem távozhat más útvonalon, egy új Pod, amely a rés alatt ad, már megszegte, ezért az indítási sorrendnek saját válaszra van szüksége: tartsa vissza az alkalmazást, amíg a szabályzat érvénybe lép, vagy fogadja el az ablakot és dokumentálja.

Tartsa szűken az állítást. A kimeneti átjáró útvonalat választ és fordít. Nem fejez be VPN-t, és nem teszi a klasztert a távoli hálózat kliensévé mögötte támogatott kapcsolat nélkül.

A fordítás csendesen megváltoztatja, amit a távoli oldal lát

Amint az átjáró átírja a forrást, a Podonkénti címek eltűnnek, így az identitásra épülő engedélyezési lista egyetlen közös címre épülő listává válik. Ez csere, nem hiba: kevesebb karbantartandó szabály, durvább hozzárendelés, ha valami rosszul viselkedik.

Az alkalmazásszintű hitelesítésnek és a kérésnaplózásnak kell hordoznia azt, amit a hálózat már nem jelent. Kezelje az átjáró kapacitását és cseréjét megosztott infrastruktúraként, mert egyetlen csomópont újraindítása most minden mögötte lévő munkaterhelést megszakít, és ellenőrizze korán a visszaútvonalat: a távoli végnek tudnia kell, hogyan érje el a fordított címet, általában egy olyan útvonalon vagy NAT-on keresztül, amelyet embernek, nem manifestnek kell birtokolnia. A címtervezés is ide tartozik, mert az átfedő klaszter- és távoli tartományok mindkét modellt megtörik, és az IPv6 bevezetése nem mentesít az ellentmondó terv alól.

Tulajdonjog alapján döntsön, majd tesztelje az ígért hibát

Válassza a Podonkénti alagutat, ha a távoli szolgáltatás egyedi munkaterheléseket hitelesít, ha csak néhány Deploymentnek kell a kapcsolat, és ha a hibának helyben kell maradnia. Válassza az átjárót, ha egy hálózati csapat már birtokolja az útvonalat, ha sok munkaterhelés osztozik egy célon, és ha a stabil forráscím az egész gyakorlat célja.

Akárhogy is, az eladott tulajdonságot ellenőrizze, ne az állandósult állapotot. Hozzon létre egy Podot, hagyja azonnal adni, és figyelje az első másodperceket, ha az ígéret az volt, hogy semmi sem szökik ki az alagútból. Skálázzon öt replikára, és számolja meg a munkameneteket, amelyeket a távoli vég jelent, ha az ígéret a munkaterhelésenkénti identitás volt. Ez a két ellenőrzés sokkal gyorsabban tárja fel a mechanizmus korlátait, mint a manifest áttekintése, és megmondja, melyik csapaté a következő incidens.