Kubernetes 1.19: Framtiden för inkommande trafik och routning

Kubernetes 1.19 och Ingress-resursen

I Kubernetes 1.19 uppgraderades resursen Ingress, som definierar hur HTTP-trafik kommer in i och dirigeras i Kubernetes, från beta till GA. Medan Ingress-resursen hade betastatus skedde viss utveckling i Kubernetes 1.18, där jokertecken för värdnamn introducerades. Min tolkning är att framtida utveckling av trafikens ingress och routning i Kubernetes kommer att ske med andra resurstyper. Utvecklingen vi såg i Kubernetes 1.18 och uppgraderingen av Ingress till GA/v1 i 1.19 kan ses som ett sätt att lösa de mest akuta problemen innan man fastställde utformningen av Ingress-resursen. 

En resurs med en fastställd version får endast buggfixar och bakåtkompatibla ändringar, så det är osannolikt att vi kommer att se några större förändringar av Ingress-resursen i framtiden. Den långa tiden i betastatus, i kombination med den utbredda användningen av Ingress-resursen, innebär också att den i praktiken hade haft GA-status under lång tid och inte kunde vidareutvecklas nämnvärt utan att bryta bakåtkompatibiliteten. Vi kan kalla detta fixa, (glömma) och gå vidare – lås designen, lös bara buggar framöver och skapa nya resurstyper för en vidareutvecklad design.

Problemet med Ingress-resursen är att designen egentligen inte går att vidareutveckla utan att avvika kraftigt från den nuvarande utformningen. Det innebär att vi behöver skapa en ny resurstyp om vi vill förnya och därmed förändra Ingress-resursen väsentligt. Det framgår också av det pågående arbetet med Kubernetes service-API:er inom SIG och exempelvis Gateway API. 

Så vilka är de största problemen med Ingress-resursen, och vilken modell kan vi förvänta oss av version 2 av resurstypen Ingress? Läs vidare ... 

Kubernetes Ingress-resurs

Ingress-resursen i Kubernetes är det officiella sättet att exponera HTTP-baserade tjänster. Ingress-resursen har levt ett osäkert liv som betaresurs under de senaste 18 Kubernetes-versionerna – ja, sedan Kubernetes v1.1! Den långa tiden som beta-API och spridningen av Ingress-controller-specifika annotationer som används för att utöka och ändra Ingress-resursens beteende visar att Ingress-resursen inte är lika väl utformad som andra Kubernetes-resurser. I nästa avsnitt beskriver vi skalbarhetsproblemet med Ingress-resursen och ett sätt att lösa det. 

Separata roller

Ett problem med Ingress-resursen är att den kombinerar följande i en och samma resursdefinition:

1. Identitet – domännamnet

2. Autentisering – TLS-certifikatet

3. Routning – vilka URL-sökvägar som dirigeras till vilka Kubernetes-tjänster

Om en person hanterar en något mer komplex webbplats, det vill säga en webbplats med komponenter som hanteras av flera oberoende team, vill vi helst delegera ovanstående områden till separata roller. Till exempel:

• Säkerhets-/infrastrukturadministratör – hanterar domännamn och TLS-certifikat

• Webbplatsadministratör – hanterar routning till komponenter/applikationer som hanteras av enskilda team

• Applikationsteam – hanterar routning till olika applikationsversioner, canary-versioner, blue/green-versioner osv.

Föreställ dig att vi har en webbplats, example.com, som består av två komponenter, login och mainsite, som båda hanteras av separata team. Vi kan illustrera de olika rollerna och trafikroutningen enligt följande figur. Blå rutor illustrerar en roll och röda rutor illustrerar en definition av trafikroutning. Routningsdefinitionerna använder antingen en URL-sökväg eller en HTTP-header som väljare.

Här hanterar rollen ”säkerhetsadministratör” webbplatsens identitet genom domännamnet och TLS-certifikaten (och eventuellt även DNS, som ligger utanför den här beskrivningens omfattning). Domännamnet och TLS-certifikatet ändras sällan, och åtkomsten till den här rollen bör vara mycket begränsad. Om certifikat hanteras med Lets Encrypt innebär begränsad åtkomst också att webbplatsadministratörer eller applikationsteam inte kan utlösa förnyelser av certifikat. Det minskar risken för att nå Lets Encrypt gräns för certifikatutgivning, vilket innebär att det inte finns någon risk att misslyckas med att få ett TLS-certifikat på grund av gränsen.

Rollen ”webbplatsadministratör” definierar routning på högsta nivå, till exempel routning till de två applikationer som hanteras av våra två team. Den här routningen ändras bara när vi lägger till eller tar bort applikationer från vår webbplats.

”Applikationsteamen” hanterar underkomponenterna i varje applikation, inklusive testdriftsättningar. Varje applikationsteam kan definiera routning till exempelvis testinstanser för att implementera canary-testning, blue/green-testning osv.

I Kubernetes definierar Ingress-resursen domännamnet, TLS-certifikatet och routningen till Kubernetes-tjänster i ett enda objekt. Konsekvensen är att ett applikationsteam som vill utföra exempelvis canary-testning behöver åtkomst för att ändra den globala Ingress-resursen för hela webbplatsen. Detta påverkar både säkerheten och stabiliteten – det mest uppenbara är att ett syntaxfel i Ingress-resursen gör hela webbplatsen otillgänglig.

Kubernetes API SIG:s arbete med Gateway API syftar till att stödja denna uppsättning med flera roller. Även om det ännu inte finns några implementationer av Gateway API är API:t starkt inspirerat av API:t för Ingress-controllern Contour. I följande avsnitt visar vi hur du kan implementera denna uppsättning med flera roller med Contour, för att få en uppfattning om ett möjligt framtida Gateway API i Kubernetes.

Implementera en uppsättning med flera roller med Contour och Envoy

Envoy är en proxy med graduated-status hos Cloud Native Computing Foundation (CNCF), och Contour är en Ingress-controller som bygger på Envoy. Contour utökar idén med Ingress-resurser med ett HTTPProxy-objekt som gör det möjligt att delegera från ett HTTPProxy-objekt till ett annat. Med andra ord kan vi definiera trafikroutning med flera HTTPProxy-resurser i flera Kubernetes-namespaces, där åtkomsten till namespaces begränsas av olika roller. Detta illustreras nedan.

En artikel om Kubernetes är inte komplett utan lite YAML, så låt oss titta på YAML:en för implementeringen ovan. Först HTTPProxy-resursen på högsta nivå som definierar webbplatsens identitet:

HTTPProxy-resursen example-com-root i namnrymden security-admin-only definierar webbplatsens identitet genom domännamnet och TLS-certifikatet, och delegerar vidare routning till HTTPProxy-resursen site-fanout i namnrymden site-admin-only:

HTTPProxy-resursen site-fanout definierar routning av allt under sökvägen /login till HTTPProxy-resursen login i namnrymden login. Teamet som hanterar inloggningsapplikationen har fullständig åtkomst till namnrymden login och kan därför skapa följande HTTPProxy-resurs för att routa till Kubernetes-tjänster som de också kontrollerar:

HTTPProxy-resursen login definierar routning till Kubernetes-tjänsten test-login-app-service när HTTP-headern x-test innehåller true (till exempel vid ett blue/green-test), och annars routning till Kubernetes-tjänsten login-app-service.

Rego och Conftest

Självklart bör namnrymderna ovan vara låsta med Kubernetes RBAC, så att exempelvis teamet ”login” bara kan skapa HTTPProxy-resurser i sin egen namnrymd login. Men du kanske undrar hur man begränsar skapandet av HTTPProxy-rotresurser som example-com-root ovan till namnrymden security-admin-only.

Det går att begränsa skapandet av sådana resurser med OPA GateKeeper. GateKeeper är en Kubernetes admission controller som accepterar policyer definierade med språket Rego. Jag har skapat ett exempel på ett Rego-baserat test som testar HTTPProxy-rotresurser. Testet ingår i en testsvit som är användbar för GitOps CI, till exempel när du vill validera dina Kubernetes-resurser innan du driftsätter dem i Kubernetes.

När får Kubernetes en ny ingress-resurs?

Troligen aldrig.

Trenden i Kubernetes är att utökningar sker med CRD:er (custom resource definitions) – ett dynamiskt tillvägagångssätt där utökningar introduceras utanför Kubernetes kärna. Det innebär att projekt som Contour eller Istio introducerar sina egna CRD:er som gör det möjligt att definiera trafik-Ingress och routning. Av dessa skäl är det osannolikt att en ny gemensam Ingress-definition introduceras i Kubernetes kärna.