Pod-IP, ClusterIP eller intern lastbalanserare för VPN-användare

Med VPC CNI kan en Pod ha en adress från VPC:n, och en VPN-användare med rätt rutt kan nå den direkt. Det får direkt Pod-åtkomst att kännas som det enklaste alternativet, och det är det, tills Poden ersätts. Adressen en användare minns bör tillhöra applikationen, inte en replik. Jämförelsen av de tre ingångarna handlar till slut om vilket objekt som äger adressen och vad som måste fortsätta fungera när arbetslasten flyttar sig.

Välj först efter livscykel, sedan efter vad nätverket måste göra för att göra ingången nåbar.

Tre ingångar, tre livscykler

En Pod-IP ägs av en Pod: den tilldelas med den och släpps när den avslutas. En ClusterIP ägs av en Service och är virtuell, den har bara betydelse där klustrets tjänstroutning finns. En intern lastbalanserare ägs av en molnresurs som klustrets kontrollant programmerar med backends. Dessa ägarmodeller förutsäger felet du får: en inaktuell adress, ett namn som inte går att nå, eller en inaktuell uppsättning backends.

Skriv ner jämförelsen innan du väljer. När ägaren och felet är namngivna gör valet sig oftast själv.

Direkt Pod-åtkomst: användbar, tillfällig

Direkt åtkomst är verkligen användbar för en kontrollerad kontroll: en administratör, en kort session, en viss port. Men det är ett dåligt avtal för användare, eftersom adressen är en implementeringsdetalj som ändras vid varje utrullning. Och att skriva ner en i en wiki är sättet en fungerande tjänst blir ett rykte.

Det bjuder också in till breda regler. Tillstånd för en administratör att nå en Pod är inte tillstånd för varje adress i nodens subnät, och det är vanligtvis det andra som skrivs.

ClusterIP: klusterbegränsad enligt design

En ClusterIP fungerar eftersom klustrets dataplan programmerar routning för den inne i klustret. Från en laptop på VPN:et betyder adressen ingenting om inte något medvetet exponerar den. Ett namn som slutar på svc.cluster.local tillhör klustrets DNS, så att kopiera det till en klient med en annan resolver ger ett namn som inte finns i stället för ett routningsfel.

ClusterIP är fortfarande rätt ingång för anropare inne i klustret, inklusive andra arbetslaster. Det är bara inte en publiceringsmekanism för användare utanför klustrets routningsdomän.

Intern lastbalanserare: den publicerade vägen

En intern lastbalanserare ger dig en stabil privat adress och ett namn som din egen zon kan peka på, medan kontrollanten håller backend-uppsättningen uppdaterad, som EKS-guiden för lastbalansering beskriver. Det är ingången som överlever ett vanligt Pod-byte utan att någon redigerar ett dokument. Den kostar en molnresurs, en kontrollantkonfiguration och en rutt från VPN:et, och det är de delarna folk underskattar.

Använd den kontrollantmodell som klustret faktiskt kör. Anteckningar skrivna för en integrering gäller inte för en annan.

Vem källadressen är

Säkerhetsgrupper ser källan som anländer till deras gräns, och det kan vara den anslutna klienten eller en översatt adress beroende på VPN- och lastbalanseringsvägen. På EC2-baserade noder ärver vanliga VPC CNI-Pods nodens ENI-grupper som standard, medan konfigurationer som stöds kan koppla Pod-specifika grupper. Skriv regler för den dokumenterade vägen i stället för för en gissad laptopadress.

Håll applikationens egen lyssnare och autentisering som separata kontroller. En nätverksregel som tillåter flödet är inte ett auktoriseringsbeslut och bör inte behandlas som ett.

Vad du ska ge användarna

Ge användarna ett tjänstenamn, inte en adress. Publicera namnet i den privata zonen, peka det mot den interna ingången och testa sedan genom att byta ut en backend-Pod medan en klient håller samma namn öppet. Den övningen testar egenskapen som spelar roll: att nå samma applikation efter en rutinmässig utrullning.

Håll direkt Pod-åtkomst som ett dokumenterat operativt undantag med eget omfång, långt från användarinstruktionerna.