Pod IP, ClusterIP, nebo interní load balancer pro uživatele VPN

S VPC CNI může Pod nést adresu z VPC a uživatel VPN se správnou cestou se k němu dostane přímo. Proto se přímý přístup k Podu zdá být nejjednodušší volbou a také jí je, dokud se Pod nevymění. Adresa, kterou si uživatel pamatuje, by měla patřit aplikaci, ne replice. Srovnání tří vstupů se nakonec redukuje na to, který objekt adresu vlastní a co musí dál fungovat, když se zátěž přesune.

Vybírejte nejprve podle životního cyklu, potom podle toho, co musí síť udělat, aby byl vstup dostupný.

Tři vstupy, tři životní cykly

Adresu Pod IP vlastní Pod: přiděluje se s ním a uvolňuje, když skončí. ClusterIP vlastní Service a je virtuální, smysl má jen tam, kde existuje směrování služeb v clusteru. Interní load balancer vlastní cloudový prostředek, který kontroler clusteru programuje backendy. Tyto modely vlastnictví předpovídají poruchu, kterou dostanete: zastaralou adresu, nedostupné jméno nebo zastaralou sadu backendů.

Napište srovnání, než začnete vybírat. Když jsou vlastník a porucha pojmenováni, volba se obvykle udělá sama.

Přímý přístup k Podu: užitečný, dočasný

Přímý přístup je skutečně užitečný pro kontrolovanou zkoušku: jeden správce, jedna krátká relace, jeden konkrétní port. Pro uživatele je to ale špatná smlouva, protože adresa je detail implementace, který se mění při každém nasazení. A zapsat ji na wiki je způsob, jak se fungující služba promění ve fámu.

Zve to také k širokým pravidlům. Oprávnění jednoho správce dosáhnout na jeden Pod není oprávnění pro každou adresu v podsíti uzlu a obvykle se zapisuje to druhé.

ClusterIP: omezený na cluster už z návrhu

ClusterIP funguje proto, že dataplane clusteru pro něj programuje směrování uvnitř clusteru. Z notebooku na VPN adresa neznamená nic, dokud ji něco záměrně nevystaví. Jméno končící na svc.cluster.local patří DNS clusteru, takže jeho zkopírování klientovi s jiným resolverem dá neexistující jméno, a ne chybu směrování.

ClusterIP zůstává správným vstupem pro volající uvnitř clusteru, včetně dalších zátěží. Prostě to není mechanismus publikace pro uživatele mimo doménu směrování clusteru.

Interní load balancer: publikovaná cesta

Interní load balancer vám dá stabilní privátní adresu a jméno, na které může vaše zóna ukazovat, zatímco kontroler udržuje sadu backendů aktuální, jak popisuje průvodce load balancingem v EKS. To je vstup, který přežije běžnou výměnu Podu, aniž by někdo upravoval dokument. Stojí cloudový prostředek, konfiguraci kontroleru a cestu z VPN a právě tyto části lidé podceňují.

Použijte model kontroleru, který cluster skutečně provozuje. Anotace napsané pro jednu integraci neplatí pro jinou.

Kdo je zdrojová adresa

Bezpečnostní skupiny vidí zdroj, který dorazí na jejich hranici, a tím může být připojený klient nebo přeložená adresa podle cesty VPN a vyvažování zátěže. Na uzlech na EC2 dědí běžné Pody VPC CNI ve výchozím stavu skupiny ENI uzlu, zatímco podporované konfigurace mohou připojit skupiny specifické pro Pod. Pište pravidla pro dokumentovanou cestu, ne pro odhadovanou adresu notebooku.

Držte vlastní listener a autentizaci aplikace jako samostatné kontroly. Síťové pravidlo, které provoz povoluje, není rozhodnutí o autorizaci a nemělo by se tak brát.

Co předat uživatelům

Dejte uživatelům jméno služby, ne adresu. Publikujte jméno v privátní zóně, namiřte ho na interní vstup a pak to otestujte výměnou backendového Podu, zatímco klient drží stejné jméno otevřené. Toto cvičení prověřuje vlastnost, na které záleží: dosáhnout stejné aplikace po rutinním nasazení.

Držte přímý přístup k Podu jako dokumentovanou provozní výjimku s vlastním rozsahem, daleko od pokynů pro uživatele.