Pod-IP, ClusterIP of interne load balancer voor VPN-gebruikers
Een Pod-IP is via de VPN routeerbaar tot de Pod wordt vervangen. Vergelijk directe Pod-toegang, ClusterIP en een interne balancer, en wat elk je kost.
Met de VPC CNI kan een Pod een adres uit de VPC hebben, en een VPN-gebruiker met de juiste route kan het direct bereiken. Daardoor lijkt directe Pod-toegang de eenvoudigste optie, en dat is het ook, tot de Pod wordt vervangen. Het adres dat een gebruiker onthoudt, hoort bij de applicatie, niet bij een replica. De vergelijking van de drie ingangen komt neer op welk object het adres bezit en wat moet blijven werken wanneer de workload verhuist.
Kies eerst op levensduur en dan op wat het netwerk moet doen om de ingang bereikbaar te maken.
Drie ingangen, drie levensduren
Een Pod-IP is eigendom van een Pod: het wordt ermee toegewezen en vrijgegeven wanneer die eindigt. Een ClusterIP is eigendom van een Service en is virtueel, het heeft alleen betekenis waar de servicerouting van het cluster bestaat. Een interne load balancer is eigendom van een cloudresource die de controller van het cluster met backends programmeert. Die eigendomsmodellen voorspellen de fout die je krijgt: een verouderd adres, een onbereikbare naam of een verouderde set backends.
Schrijf de vergelijking op voordat je kiest. Zodra de eigenaar en de fout benoemd zijn, maakt de keuze zich meestal zelf.
| 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 |
Directe Pod-toegang: nuttig, tijdelijk
Directe toegang is echt nuttig voor een gecontroleerde controle: één beheerder, één korte sessie, één specifieke poort. Maar het is een slecht contract voor gebruikers, want het adres is een implementatiedetail dat bij elke uitrol verandert. En er een in een wiki vastleggen is de manier waarop een werkende dienst een gerucht wordt.
Het nodigt ook uit tot brede regels. Toestemming voor één beheerder om één Pod te bereiken is geen toestemming voor elk adres in het subnet van de node, en meestal wordt het tweede geschreven.
ClusterIP: naar ontwerp clustergebonden
Een ClusterIP werkt omdat de dataplane van het cluster de routing ervoor binnen het cluster programmeert. Vanaf een laptop op de VPN betekent het adres niets tenzij iets het bewust blootlegt. Een naam die eindigt op svc.cluster.local hoort bij de DNS van het cluster, dus het kopiëren naar een client met een andere resolver levert een niet-bestaande naam op in plaats van een routingfout.
ClusterIP blijft de juiste ingang voor aanroepers binnen het cluster, inclusief andere workloads. Het is alleen geen publicatiemechanisme voor gebruikers buiten het routingdomein van het cluster.
Interne load balancer: het gepubliceerde pad
Een interne load balancer geeft je een stabiel privéadres en een naam waar je eigen zone naar kan wijzen, terwijl de controller de set backends actueel houdt, zoals de EKS-handleiding voor load balancing beschrijft. Dat is de ingang die een gewone Pod-vervanging overleeft zonder dat iemand een document bewerkt. Het kost een cloudresource, een controllerconfiguratie en een route vanaf de VPN, en dat zijn de delen die mensen onderschatten.
Gebruik het controllermodel dat het cluster daadwerkelijk draait. Annotaties die voor de ene integratie zijn geschreven, gelden niet voor een andere.
Wie het bronadres is
Beveiligingsgroepen zien de bron die bij hun grens aankomt, en dat kan de verbonden client zijn of een vertaald adres, afhankelijk van het VPN- en load-balancingpad. Op EC2-gebaseerde nodes erven gewone VPC CNI-Pods standaard de groepen van de ENI van de node, terwijl ondersteunde configuraties Pod-specifieke groepen kunnen koppelen. Schrijf regels voor het gedocumenteerde pad in plaats van voor een geraden laptopadres.
Houd de eigen listener en authenticatie van de applicatie als aparte controles. Een netwerkregel die de stroom toestaat is geen autorisatiebeslissing en moet niet zo worden behandeld.
Wat je gebruikers geeft
Geef gebruikers een dienstnaam, geen adres. Publiceer de naam in de privézone, wijs die naar de interne ingang en test dan door een backend-Pod te vervangen terwijl een client dezelfde naam openhoudt. Die oefening test de eigenschap die ertoe doet: dezelfde applicatie bereiken na een routine-uitrol.
Houd directe Pod-toegang als een gedocumenteerde operationele uitzondering met een eigen bereik, ver weg van de gebruikersinstructies.