Pod IP, ClusterIP alebo interný load balancer pre používateľov VPN

S VPC CNI môže Pod niesť adresu z VPC a používateľ VPN so správnou cestou sa k nemu dostane priamo. Preto sa priamy prístup k Podu zdá byť najjednoduchšou voľbou a aj je, kým sa Pod nevymení. Adresa, ktorú si používateľ pamätá, by mala patriť aplikácii, nie replike. Porovnanie troch vstupov sa napokon redukuje na to, ktorý objekt adresu vlastní a čo musí ďalej fungovať, keď sa záťaž presunie.

Vyberajte najprv podľa životného cyklu, potom podľa toho, čo musí sieť urobiť, aby bol vstup dostupný.

Tri vstupy, tri životné cykly

Adresu Pod IP vlastní Pod: prideľuje sa s ním a uvoľňuje, keď skončí. ClusterIP vlastní Service a je virtuálny, zmysel má len tam, kde existuje smerovanie služieb v klastri. Interný load balancer vlastní cloudový prostriedok, ktorý kontrolér klastra programuje backendmi. Tieto modely vlastníctva predpovedajú poruchu, ktorú dostanete: zastaranú adresu, nedostupné meno alebo zastaranú množinu backendov.

Napíšte porovnanie, kým začnete vyberať. Keď sú vlastník a porucha pomenovaní, voľba sa zvyčajne urobí sama.

Priamy prístup k Podu: užitočný, dočasný

Priamy prístup je skutočne užitočný na kontrolovanú skúšku: jeden správca, jedna krátka relácia, jeden konkrétny port. Pre používateľov je to však zlá zmluva, pretože adresa je detail implementácie, ktorý sa mení pri každom nasadení. A zapísať ju do wiki je spôsob, akým sa fungujúca služba zmení na fámu.

Pozýva to aj k širokým pravidlám. Oprávnenie jedného správcu dosiahnuť na jeden Pod nie je oprávnenie pre každú adresu v podsieti uzla a zvyčajne sa zapisuje to druhé.

ClusterIP: obmedzený na klaster už z návrhu

ClusterIP funguje preto, lebo dátová rovina klastra preň programuje smerovanie vnútri klastra. Z notebooku na VPN adresa nič neznamená, kým ju niečo zámerne nevystaví. Meno končiace na svc.cluster.local patrí DNS klastra, takže jeho skopírovanie klientovi s iným resolverom dá neexistujúce meno, a nie chybu smerovania.

ClusterIP zostáva správnym vstupom pre volajúcich vnútri klastra, vrátane ďalších záťaží. Jednoducho to nie je mechanizmus publikovania pre používateľov mimo domény smerovania klastra.

Interný load balancer: publikovaná cesta

Interný load balancer vám dá stabilnú privátnu adresu a meno, na ktoré môže vaša zóna ukazovať, zatiaľ čo kontrolér udržiava množinu backendov aktuálnu, ako opisuje príručka EKS pre vyvažovanie záťaže. To je vstup, ktorý prežije bežnú výmenu Podu bez toho, aby niekto upravoval dokument. Stojí cloudový prostriedok, konfiguráciu kontroléra a cestu z VPN, a práve tieto časti ľudia podceňujú.

Použite model kontroléra, ktorý klaster skutočne prevádzkuje. Anotácie napísané pre jednu integráciu neplatia pre inú.

Kto je zdrojová adresa

Bezpečnostné skupiny vidia zdroj, ktorý dorazí na ich hranicu, a môže to byť pripojený klient alebo preložená adresa podľa cesty VPN a vyvažovania záťaže. Na uzloch na EC2 bežné Pody VPC CNI predvolene dedia skupiny ENI uzla, zatiaľ čo podporované konfigurácie môžu pripojiť skupiny špecifické pre Pod. Píšte pravidlá pre dokumentovanú cestu, nie pre odhadovanú adresu notebooku.

Držte vlastný listener a autentifikáciu aplikácie ako samostatné kontroly. Sieťové pravidlo, ktoré povoľuje tok, nie je rozhodnutie o autorizácii a nemalo by sa tak brať.

Čo odovzdať používateľom

Dajte používateľom meno služby, nie adresu. Publikujte meno v privátnej zóne, nasmerujte ho na interný vstup a potom to otestujte výmenou backendového Podu, kým klient drží rovnaké meno otvorené. Toto cvičenie preveruje vlastnosť, na ktorej záleží: dosiahnuť rovnakú aplikáciu po rutinnom nasadení.

Držte priamy prístup k Podu ako dokumentovanú prevádzkovú výnimku s vlastným rozsahom, ďaleko od pokynov pre používateľov.