Pod IP, ClusterIP ali notranji porazdeljevalnik obremenitve za uporabnike VPN

Z VPC CNI lahko Pod dobi naslov iz VPC, uporabnik VPN z ustrezno potjo pa ga doseže neposredno. Zato se neposreden dostop do Poda zdi najpreprostejša možnost in tudi je, dokler se Pod ne zamenja. Naslov, ki si ga uporabnik zapomni, bi moral pripadati aplikaciji, ne repliki. Primerjava treh vhodov se na koncu zvede na to, kateri objekt ima naslov in kaj mora še naprej delovati, ko se delovna obremenitev premakne.

Najprej izbirajte po življenjskem ciklu, nato po tem, kaj mora omrežje narediti, da bo vhod dosegljiv.

Trije vhodi, trije življenjski cikli

Naslov Pod IP ima Pod: dodeli se z njim in sprosti, ko se konča. ClusterIP ima Service in je virtualen, smisel ima le tam, kjer obstaja usmerjanje storitev v gruči. Notranji porazdeljevalnik ima v oblaku gostujoči vir, ki ga krmilnik gruče programira z zalednimi sistemi. Ti modeli lastništva napovedo napako, ki jo boste dobili: zastarel naslov, nedosegljivo ime ali zastarel nabor zalednih sistemov.

Zapišite primerjavo, preden izberete. Ko sta lastnik in napaka poimenovana, se izbira običajno naredi sama.

Neposreden dostop do Poda: koristen, začasen

Neposreden dostop je resnično koristen za nadzorovan pregled: en skrbnik, ena kratka seja, ena določena vrata. Toda za uporabnike je slaba pogodba, ker je naslov podrobnost izvedbe, ki se spreminja ob vsaki namestitvi. In če ga zapišete v wiki, se delujoča storitev spremeni v govorice.

Spodbuja tudi široka pravila. Dovoljenje enemu skrbniku, da doseže en Pod, ni dovoljenje za vsak naslov v podomrežju vozlišča, in običajno se zapiše drugo.

ClusterIP: po zasnovi omejen na gručo

ClusterIP deluje, ker podatkovna ravnina gruče zanj programira usmerjanje znotraj gruče. S prenosnika na VPN naslov ne pomeni ničesar, razen če ga nekaj namerno izpostavi. Ime, ki se konča na svc.cluster.local, pripada DNS gruče, zato kopiranje na odjemalca z drugim razreševalnikom ustvari neobstoječe ime namesto napake usmerjanja.

ClusterIP ostaja pravi vhod za klicatelje znotraj gruče, vključno z drugimi delovnimi obremenitvami. Preprosto ni mehanizem objave za uporabnike zunaj domene usmerjanja gruče.

Notranji porazdeljevalnik: objavljena pot

Notranji porazdeljevalnik vam da stabilen zasebni naslov in ime, na katerega lahko kaže vaša cona, medtem ko krmilnik ohranja nabor zalednih sistemov ažuren, kot opisuje vodnik EKS za porazdeljevanje obremenitve. To je vhod, ki preživi običajno zamenjavo Poda, ne da bi kdor koli urejal dokument. Stane oblačni vir, konfiguracijo krmilnika in pot z VPN, in prav te dele ljudje podcenjujejo.

Uporabite model krmilnika, ki ga gruča dejansko izvaja. Opombe, napisane za eno integracijo, ne veljajo za drugo.

Kdo je izvorni naslov

Varnostne skupine vidijo vir, ki prispe na njihovo mejo, in to je lahko povezani odjemalec ali preveden naslov, odvisno od poti VPN in porazdeljevanja obremenitve. Na vozliščih na osnovi EC2 običajni Podi VPC CNI privzeto podedujejo skupine ENI vozlišča, medtem ko lahko podprte konfiguracije priložijo skupine, specifične za Pod. Pišite pravila za dokumentirano pot, ne za domnevni naslov prenosnika.

Ohranite lastni poslušalec in preverjanje pristnosti aplikacije kot ločeni kontroli. Omrežno pravilo, ki dovoli tok, ni odločitev o avtorizaciji in se ne bi smelo obravnavati kot tako.

Kaj predati uporabnikom

Uporabnikom dajte ime storitve, ne naslova. Objavite ime v zasebni coni, usmerite ga na notranji vhod in nato preizkusite tako, da zamenjate zaledni Pod, medtem ko odjemalec drži isto ime odprto. Ta vaja preveri lastnost, ki je pomembna: doseči isto aplikacijo po rutinski namestitvi.

Neposreden dostop do Poda ohranite kot dokumentirano operativno izjemo z lastnim obsegom, daleč od navodil za uporabnike.