Pod-IP, ClusterIP of interne lasbalanseerder vir VPN-gebruikers
’n Pod-IP is oor die VPN bereikbaar totdat die Pod vervang word. Vergelyk direkte Pod-toegang, ClusterIP en ’n interne lasbalanseerder, en wat elkeen jou kos.
Met die VPC CNI kan ’n Pod ’n adres uit die VPC dra, en ’n VPN-gebruiker met die regte roete kan dit direk bereik. Dit laat direkte Pod-toegang na die eenvoudigste opsie voel, en dit is dit, totdat die Pod vervang word. Die adres wat ’n gebruiker onthou, moet aan die toepassing behoort, nie aan ’n replika nie. Om die drie inskrywings te vergelyk, kom daarop neer watter objek die adres besit en wat aan die gang moet bly wanneer die werklading skuif.
Kies eers volgens lewensduur, dan volgens wat die netwerk moet doen om die inskrywing bereikbaar te maak.
Drie inskrywings, drie leeftye
’n Pod-IP word deur ’n Pod besit: dit word saam met die Pod toegewys en vrygestel wanneer dit eindig. ’n ClusterIP word deur ’n Service besit en is virtueel, betekenisvol net waar die cluster se diensroetering bestaan. ’n Interne lasbalanseerder word deur ’n wolkehulpbron besit wat die cluster se kontroleerder met backends programmeer. Dié eienaarskapsmodelle voorspel die fout wat jy kry: ’n verouderde adres, ’n onbereikbare naam, of ’n stel backends wat verouderd is.
Skryf die vergelyking neer voordat jy kies. Sodra die eienaar en die fout genoem is, maak die keuse gewoonlik vanself.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Direkte Pod-toegang: nuttig, tydelik
Direkte toegang is werklik nuttig vir ’n beheerde kontrole: een administrateur, een kort sessie, een spesifieke poort. Dit is ’n swak kontrak vir gebruikers, want die adres is ’n implementeringsdetail wat by elke uitrol verander. Om een in ’n wiki op te teken, is hoe ’n werkende diens in ’n gerug verander.
Dit lok ook wye reëls uit. Toestemming vir een administrateur om een Pod te bereik, is nie toestemming vir elke adres in die nodus-subnet nie, en dit is die tweede wat gewoonlik geskryf word.
ClusterIP: by ontwerp tot die cluster beperk
’n ClusterIP werk omdat die cluster se dataplane roetering daarvoor binne die cluster programmeer. Vanaf ’n skootrekenaar op die VPN beteken die adres niks tensy iets dit doelbewus blootstel. ’n Naam wat op svc.cluster.local eindig, behoort aan die cluster se DNS, so om dit na ’n kliënt met ’n ander resolver te kopieer, lewer ’n naam wat nie bestaan nie eerder as ’n roeteringsfout.
ClusterIP bly die regte inskrywing vir oproepers binne die cluster, insluitend ander werkladings. Dit is bloot nie ’n publikasiemeganisme vir gebruikers buite die cluster se roeteringsdomein nie.
Interne lasbalanseerder: die gepubliseerde pad
’n Interne lasbalanseerder gee jou ’n stabiele private adres en ’n naam waarop jou eie sone kan wys, terwyl die kontroleerder die stel backends aktueel hou, soos die EKS-gids vir lasbalansering beskryf. Dit is die inskrywing wat ’n gewone Pod-vervanging oorleef sonder dat iemand ’n dokument redigeer. Dit kos ’n wolkehulpbron, ’n kontroleerderkonfigurasie en ’n roete vanaf die VPN, en dit is die dele wat mense onderskat.
Gebruik die kontroleerder-model wat die cluster werklik gebruik. Aantekeninge wat vir een integrasie geskryf is, geld nie vir ’n ander nie.
Wie die bronadres is
Sekuriteitsgroepe sien die bron wat by hulle grens aankom, wat die gekoppelde kliënt of ’n vertaalde adres kan wees, afhangend van die VPN- en lasbalanseringspad. Op EC2-gebaseerde nodusse erf gewone VPC CNI Pods by verstek die nodus se ENI-groepe, terwyl ondersteunde konfigurasies Pod-spesifieke groepe kan koppel. Skryf reëls vir die gedokumenteerde pad eerder as vir ’n geraamde skootrekenaaradres.
Hou die toepassing se eie luisteraar en verifikasie as aparte kontroles. ’n Reël in die netwerk wat die vloei toelaat, is nie ’n magtigingsbesluit nie en moet nie so behandel word nie.
Wat om aan gebruikers te gee
Gee gebruikers ’n diensnaam, nie ’n adres nie. Publiseer die naam in die private sone, wys dit na die interne inskrywing, en toets dan deur ’n backend-Pod te vervang terwyl ’n kliënt dieselfde naam oop hou. Daardie oefening toets die eienskap wat saak maak: om dieselfde toepassing na ’n roetine-ontplooiing te bereik.
Hou direkte Pod-toegang as ’n gedokumenteerde operasionele uitsondering met sy eie omvang, ver weg van die gebruikergerigte instruksies.