Vi introducerar Kubernetes CCM (Cloud Controller Manager) för Yandex.Cloud

I fortsättningen till det senaste CSI-drivrutinsversion för Yandex.Cloud publicerar vi ytterligare ett projekt med öppen källkod för detta moln - Cloud Controller Manager. CCM krävs inte bara för klustret som helhet, utan också för själva CSI-drivrutinen. Detaljer om dess syfte och vissa implementeringsfunktioner är under snittet.

Inledning

Varför är detta?

Motiven som fick oss att utveckla CCM för Yandex.Cloud sammanfaller helt med de som redan beskrivits i meddelande CSI-drivrutiner. Vi har många Kubernetes-kluster från olika molnleverantörer, för vilka vi använder ett enda verktyg. Den implementerar många bekvämligheter som "förbigår" de hanterade lösningarna från dessa leverantörer. Ja, vi har ett ganska specifikt fall och behov, men utvecklingen som skapas på grund av dem kan vara användbar för andra användare.

Vad är CCM egentligen?

Vanligtvis förbereder vi miljön omkring oss för klustret från utsidan - till exempel med Terraform. Men ibland finns det ett behov av att hantera molnmiljön omkring oss från kluster. Denna möjlighet tillhandahålls, och det är den som implementeras CCM.

Specifikt tillhandahåller Cloud Controller Manager fem huvudtyper av interaktion:

1. Instanser – implementerar en 1:1 relation mellan ett nodobjekt i Kubernetes (Node) och en virtuell maskin i molnleverantören. För detta:
   • fyll i fältet spec.providerID i objektet Node. Till exempel, för OpenStack CCM har detta fält följande format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Du kan se namnet på molnleverantören och det unika UUID:t för servern (virtuell maskin i OpenStack) för objektet;
   • komplement nodeInfo i objektet Node information om den virtuella maskinen. Till exempel anger vi instanstyp i AWS;
   • Vi kontrollerar närvaron av en virtuell maskin i molnet. Till exempel om ett objekt Node gick in i ett tillstånd NotReady, kan du kontrollera om den virtuella maskinen överhuvudtaget finns i molnleverantören genom att providerID. Om det inte finns där, ta bort objektet Node, som annars skulle förbli i klustret för alltid;
2. Zoner – ställer in feldomänen för objektet Node, så att schemaläggaren kan välja en nod för Pod enligt regionerna och zonerna i molnleverantören;
3. Lastbalanserare – när du skapar ett objekt Service med typ LoadBalancer skapar en sorts balanserare som kommer att dirigera trafik utifrån till klusternoderna. Till exempel, i Yandex.Cloud kan du använda NetworkLoadBalancer и TargetGroup för dessa ändamål;
4. Rutt – bygger ett nätverk mellan noder, eftersom Enligt Kubernetes krav måste varje pod ha sin egen IP-adress och kunna nå vilken annan pod som helst. För dessa ändamål kan du använda ett överläggsnätverk (VXLAN, GENEVE) eller ställa in en routingtabell direkt i molnleverantörens virtuella nätverk:

   

5. Volym – Tillåter dynamisk beställning av PV med PVC och SC. Till en början var denna funktion en del av CCM, men på grund av dess stora komplexitet flyttades den till ett separat projekt, Container Storage Interface (CSI). Vi har pratat om CSI mer än en gång писали och, som redan nämnts, till och med släppte CSI-drivrutinen.

Tidigare fanns all kod som interagerar med molnet i huvudförrådet för Git i Kubernetes-projektet på k8s.io/kubernetes/pkg/cloudprovider/providers, men de bestämde sig för att överge detta på grund av besväret med att arbeta med en stor kodbas. Alla gamla implementeringar har flyttats till separat förvar. För att underlätta ytterligare support och utveckling flyttades också alla gemensamma komponenter till separat förvar.

Precis som med CSI har många stora molnleverantörer redan designat sina CCM för att utnyttja moln på Kubernetes. Om leverantören inte har CCM, men alla nödvändiga funktioner är tillgängliga via API, så kan du implementera CCM själv.

För att skriva en egen implementering av CCM räcker det att implementera nödvändiga Go-gränssnitt.

И det här är vad vi fick.

genomförande

Hur kom du fram till detta

Vi började utveckla (eller snarare, till och med använda) med klar(!) CCM för Yandex.Cloud för ett år sedan.

Men i den här implementeringen saknade vi:

• autentisering via JWT IAM-token;
• Service controller support.

I samförstånd med författaren (dlisin) i Telegram delade vi yandex-cloud-controller-manager och la till de saknade funktionerna.

Viktiga funktioner

För närvarande stöder CCM följande gränssnitt:

• Instanser;
• Zoner;
• Lastbalanserare.

I framtiden, när Yandex.Cloud börjar arbeta med avancerade VPC-funktioner, kommer vi att lägga till ett gränssnitt rutter.

LoadBalanacer som huvudutmaning

Till en början försökte vi, precis som andra CCM-implementeringar, att skapa ett par LoadBalancer и TargetGroup för varje Service med typ LoadBalancer. Yandex.Cloud upptäckte dock en intressant begränsning: du kan inte använda TargetGroups med korsning Targets (par SubnetID - IpAddress).

Därför, inuti den skapade CCM, startas en kontroller, som, när objekt ändras Node samlar information om alla gränssnitt på varje virtuell maskin, grupperar dem efter deras tillhörighet till vissa NetworkID, skapar av TargetGroup på NetworkID, och övervakar även relevans. Därefter när du skapar ett objekt Service med typ LoadBalanacer vi bifogar helt enkelt en förskapad TargetGroup till nya NetworkLoadBalanacer'am.

Hur börjar man använda det?

CCM stöder Kubernetes version 1.15 och högre. I ett kluster, för att det ska fungera, krävs att flaggan --cloud-provider=external var inställd på true för kube-apiserver, kube-controller-manager, kube-scheduler och alla kubelets.

Alla nödvändiga steg för själva installationen beskrivs i README. Installation handlar om att skapa objekt i Kubernetes från manifest.

För att använda CCM behöver du också:

• ange i manifestet katalogidentifieraren (folder-id) Yandex.Cloud;
• tjänstkonto för att interagera med Yandex.Cloud API. I manifestet Secret nödvändigt överföra auktoriserade nycklar från tjänstekontot. I dokumentationen beskrivs, hur man skapar ett tjänstekonto och får nycklar.

Vi tar gärna emot din feedback och nya frågorom du stöter på några problem!

Resultat av

Vi har använt den implementerade CCM i fem Kubernetes-kluster under de senaste två veckorna och planerar att utöka antalet till 20 under den kommande månaden. Vi rekommenderar för närvarande inte att använda CCM för stora och kritiska K8s-installationer.

Precis som i fallet med CSI kommer vi att vara glada om Yandex-utvecklare tar på sig utvecklingen och stödet av detta projekt - vi är redo att överföra arkivet på deras begäran för att hantera uppgifter som är mer relevanta för oss.

PS

Läs även på vår blogg:

• «Vår erfarenhet av att utveckla en CSI-drivrutin i Kubernetes för Yandex.Cloud";
• «Är det enkelt och bekvämt att förbereda ett Kubernetes-kluster? Tillkännager addon-operator";
• «Utöka och komplettera Kubernetes (recension och videorapport)".

Källa: will.com