Kubernetes på Windows

I Kubernetes 1.5 introducerades stöd för Windows-containrar i en alpha-release. Betaversionen är precis runt hörnet, så vi satte stödet för Windows på prov. Är det tillräckligt moget för produktionsmiljöer?

Containerlösningar, som Docker, har blivit en populär trend inom mjukvaruutveckling och driftsättning. De gör det enkelt för utvecklare att leverera applikationer ”var som helst” utan att behöva oroa sig för miljökonfiguration. Kubernetes (även kallat k8s) hjälper oss att hantera livscyklerna för containeriserade applikationer genom ett ramverk för orkestrering, till exempel automatisk skalning, hälsokontroller och återställning.

En annan aktuell trend inom mjukvaruutveckling är mikrotjänster, där applikationer delas upp i mindre, lätta och distribuerade (containeriserade) tjänster. Eftersom containrar har sitt ursprung i Linux hade Docker (och därmed k8s) från början endast stöd för Linux. Men oavsett om vi vill det eller inte finns det fortfarande många applikationer, både äldre och nya, som är specifika för Windows. I en mikrotjänstarkitektur kan dessutom vissa tjänster behöva köras i en Windows-miljö. Därför samarbetade Microsoft med Docker Inc. för att introducera Windows-containrar i samband med lanseringen av Windows Server 2016.

Windows-containrar måste fortfarande köras på Windows-värdar. Om du vill använda kraften i k8s för att hantera containerapplikationer som delvis eller helt körs på Windows behöver du därför ha Windows-noder i ditt k8s-kluster. Därför bildades en särskild intressegrupp för Windows (SIG) för att ge stöd för att lägga till Windows-minions (noder) i Kubernetes-kluster. I Kubernetes 1.5 fanns Windows-stödet i alpha-release, och enligt färdplanen skulle en betaversion vara klar när Kubernetes 1.8 släpptes. Den stora frågan är dock om det är tillräckligt moget för produktionsmiljöer.

Alpha-releasen har vissa begränsningar, enligt tillkännagivandet. För det första har Windows inte stöd för nätverksnamnrymder, vilket innebär att containrar i samma podd inte kan kommunicera via localhost. Därmed begränsas antalet containrar per podd till en. DNS-funktionaliteten var dessutom inte fullt implementerad, och UDP stöddes inte i en container.

Test av alpha-releasen på AWS med Kops

Vi testade alpha-releasen av Windows-stödet för k8s på ett kluster som skapats med Kops på AWS. Kops gör det enkelt att driftsätta och hantera ett k8s-kluster på AWS. Kops har stöd för att skapa ett Linux-baserat kluster, både för master och minions, vilket innebär att du måste lägga till Windows-minions manuellt i klustret genom att följa guiden från k8s. Guiden visar hur du konfigurerar nätverket, bygger binärfilerna kubelet och kube-proxy för Windows samt startar dem. När Windows-minions har anslutits till ditt k8s-kluster kan du instruera k8s-schemaläggaren att placera specifika poddar (logiska grupper av containrar) på Windows-minions med NodeSelector.

När alpha-releasen används med Kops på AWS uppstår flera utmaningar som gör den olämplig för användning i produktion:

• Om du manuellt ändrar molnresurserna i ditt k8s-kluster, till exempel genom att starta Windows EC2-instanser i klustrets VPC, skapas beroenden som ditt klusterhanteringsverktyg, exempelvis Kops, inte känner till. Det kan påverka hur verktyget fungerar. Om du till exempel försöker ta bort klustret med Kops efter att du manuellt har lagt till Windows-minions misslyckas det på grund av beroenden mellan AWS-molnresurser som Kops inte känner till.

• Installationsprocessen som föreslås i den officiella guiden är känslig, och det är lätt att nätverkskonfigurationen blir fel. Dessutom måste du gissa vilket Pod CIDR-intervall som mastern kommer att tilldela din Windows-minion innan det faktiskt har tilldelats. Det är inte särskilt smidigt!

• Eftersom Windows-stödet i k8s är relativt nytt förändras det fortfarande medan det mognar. SIG-gruppen håller till exempel på att införa en ny metod för att lägga till Windows-minions i ett k8s-kluster, där OVN används för nätverk. Även om guiden använder OVN för nätverksfunktionerna omfattar den fortfarande flera steg för att installera och konfigurera OVS/OVN, inte bara på Windows-minions utan även på mastern och Linux-minions. Därför går OVN-metoden inte att använda tillsammans med k8s-hanteringsverktyg som Kops.

• Windows Server 2017, som väntas senare i år, kommer också med vissa förbättringar av containernätverk som förväntas förbättra Windows-stödet i k8s-kluster.

Slutsats

I nuläget mognar Windows-stödet i k8s-kluster, men det är inte redo för produktionsmiljöer, särskilt inte om du vill använda ett klusterhanteringsverktyg. Vad gör du då om du ändå behöver ha Windows-minions i dina Kubernetes-kluster? Du har två alternativ:

1. Antingen flyttar du dina kluster till Azure och använder den nyligen tillagda funktionen Azure Container Service, som gör det möjligt att driftsätta Kubernetes-kluster med Windows-minions.

2. Eller, om du bara behöver Windows-minions som komplement till befintliga applikationer i ditt k8s-kluster, till exempel för att hosta Windows-slavar för Jenkins, kan du starta dina Windows-instanser (VM:ar) utanför dina k8s-kluster, i en separat VPC, och låta applikationerna i ditt k8s-kluster använda dessa Windows-instanser. Vi kommer att visa detta tillvägagångssätt i ett kommande inlägg, där vi driftsätter Jenkins master i ett k8s-kluster med Windows-slavar som ansluter till mastern från en annan VPC.

Det senaste året har utvecklingen av Windows-stöd kring Docker och k8s gått snabbt, och Microsoft och dess partner verkar fast beslutna att driva den vidare. Vi kommer att följa utvecklingen under de kommande månaderna när Windows Server 2017 släpps och Windows-stödet i k8s mognar.