Vi introducerer Kubernetes CCM (Cloud Controller Manager) til Yandex.Cloud

I forlængelse af det seneste CSI driver udgivelse til Yandex.Cloud udgiver vi endnu et Open Source-projekt til denne sky - Cloud Controller Manager. CCM kræves ikke kun for klyngen som helhed, men også for selve CSI-driveren. Detaljer om dets formål og nogle implementeringsfunktioner er under skæring.

Indledning

Hvorfor er det?

De motiver, der fik os til at udvikle CCM til Yandex.Cloud, falder fuldstændig sammen med dem, der allerede er beskrevet i bekendtgørelse CSI-drivere. Vi vedligeholder mange Kubernetes-klynger fra forskellige cloud-udbydere, som vi bruger et enkelt værktøj til. Den implementerer adskillige bekvemmeligheder "omgå" de administrerede løsninger fra disse udbydere. Ja, vi har en ret specifik sag og behov, men de udviklinger, der er skabt på grund af dem, kan være nyttige for andre brugere.

Hvad er CCM helt præcist?

Typisk forbereder vi miljøet omkring os til klyngen udefra - for eksempel ved hjælp af Terraform. Men nogle gange er der behov for at styre cloudmiljøet omkring os fra klynge. Denne mulighed er givet, og det er den, der implementeres CCM.

Specifikt giver Cloud Controller Manager fem hovedtyper af interaktion:

1. tilfælde – implementerer et 1:1 forhold mellem et nodeobjekt i Kubernetes (Node) og en virtuel maskine i cloud-udbyderen. Til dette:
   • udfyld feltet spec.providerID i objektet Node. For eksempel, for OpenStack CCM har dette felt følgende format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Du kan se navnet på cloud-udbyderen og det unikke UUID for objektets server (virtuel maskine i OpenStack);
   • komplement nodeInfo i objektet Node oplysninger om den virtuelle maskine. For eksempel angiver vi instanstype i AWS;
   • Vi kontrollerer tilstedeværelsen af ​​en virtuel maskine i skyen. For eksempel hvis et objekt Node gik i en tilstand NotReady, kan du tjekke, om den virtuelle maskine overhovedet findes i cloud-udbyderen ved providerID. Hvis det ikke er der, skal du slette objektet Node, som ellers ville forblive i klyngen for evigt;
2. Zoner – indstiller fejldomænet for objektet Node, så planlæggeren kan vælge en node til Pod'en i henhold til regionerne og zonerne i cloud-udbyderen;
3. LoadBalancer – når du opretter et objekt Service med type LoadBalancer skaber en slags balancer, der vil dirigere trafik udefra til klyngeknuderne. For eksempel i Yandex.Cloud kan du bruge NetworkLoadBalancer и TargetGroup til disse formål;
4. R – bygger et netværk mellem noder, fordi Ifølge Kubernetes krav skal hver pod have sin egen IP-adresse og kunne nå enhver anden pod. Til disse formål kan du bruge et overlay-netværk (VXLAN, GENEVE) eller indstille en routingtabel direkte i cloud-udbyderens virtuelle netværk:

   

5. Bind – Tillader dynamisk bestilling af PV ved brug af PVC og SC. I starten var denne funktionalitet en del af CCM, men på grund af dens store kompleksitet blev den flyttet til et separat projekt, Container Storage Interface (CSI). Vi har talt om CSI mere end én gang skrev og, som allerede nævnt, endda frigivet CSI driver.

Tidligere var al kode, der interagerer med skyen, placeret i det primære Git-lager i Kubernetes-projektet kl. k8s.io/kubernetes/pkg/cloudprovider/providers, men de besluttede at opgive dette på grund af ulejligheden ved at arbejde med en stor kodebase. Alle gamle implementeringer er flyttet til separat depot. For at lette yderligere support og udvikling blev alle fælles komponenter også flyttet til separat depot.

Som med CSI har mange store cloud-udbydere allerede designet deres CCM'er til at udnytte skyer på Kubernetes. Hvis leverandøren ikke har CCM, men alle nødvendige funktioner er tilgængelige via API, så kan du selv implementere CCM.

For at skrive din egen implementering af CCM er det nok at implementere nødvendige Go-grænseflader.

И dette er hvad vi fik.

implementering

Hvordan kom du til det her

Vi startede udvikling (eller rettere, endda bruge) med klar(!) CCM for Yandex.Cloud for et år siden.

Men i denne implementering manglede vi:

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

Efter aftale med forfatteren (dlisin) i Telegram gaflede vi yandex-cloud-controller-manager og tilføjede de manglende funktioner.

Nøglefunktioner

I øjeblikket understøtter CCM følgende grænseflader:

• tilfælde;
• Zoner;
• LoadBalancer.

I fremtiden, når Yandex.Cloud begynder at arbejde med avancerede VPC-funktioner, vil vi tilføje en grænseflade Ruter.

LoadBalanacer som hovedudfordring

I starten forsøgte vi, ligesom andre CCM-implementeringer, at skabe et par LoadBalancer и TargetGroup for hver Service med type LoadBalancer. Yandex.Cloud opdagede dog en interessant begrænsning: du kan ikke bruge TargetGroups med krydsende Targets (par SubnetID — IpAddress).

Derfor lanceres der inde i den oprettede CCM en controller, som, når objekter ændres Node indsamler information om alle grænseflader på hver virtuel maskine, grupperer dem efter deres tilhørsforhold til bestemte NetworkID, skaber af TargetGroup på NetworkID, og overvåger også relevans. Efterfølgende ved oprettelse af et objekt Service med type LoadBalanacer vi vedhæfter blot en præ-oprettet TargetGroup til nyt NetworkLoadBalanacer'er.

Hvordan begynder man at bruge det?

CCM understøtter Kubernetes version 1.15 og nyere. I en klynge, for at det kan fungere, kræver det, at flaget --cloud-provider=external blev sat til true for kube-apiserver, kube-controller-manager, kube-scheduler og alle kubelets.

Alle nødvendige trin til selve installationen er beskrevet i README. Installation går ud på at skabe objekter i Kubernetes fra manifester.

For at bruge CCM skal du også bruge:

• angive i manifestet mappe-id'et (folder-id) Yandex.Cloud;
• servicekonto til at interagere med Yandex.Cloud API. I manifestet Secret skal overføre autoriserede nøgler fra servicekontoen. I dokumentationen beskrevet, hvordan man opretter en servicekonto og får nøgler.

Vi vil være glade for at modtage din feedback og nye spørgsmålhvis du støder på problemer!

Resultaterne af

Vi har brugt den implementerede CCM i fem Kubernetes-klynger i løbet af de sidste to uger og planlægger at udvide deres antal til 20 i den kommende måned. Vi anbefaler i øjeblikket ikke at bruge CCM til store og kritiske K8s installationer.

Som i tilfældet med CSI, vil vi være glade for, hvis Yandex-udviklere påtager sig udviklingen og supporten af ​​dette projekt - vi er klar til at overføre depotet på deres anmodning for at håndtere opgaver, der er mere relevante for os.

PS

Læs også på vores blog:

• «Vores erfaring med at udvikle en CSI-driver i Kubernetes til Yandex.Cloud";
• «Er det nemt og bekvemt at forberede en Kubernetes-klynge? Annoncerer tilføjelsesoperatør";
• «Udvidelse og udvidelse af Kubernetes (oversigt og videorapport)'.

Kilde: www.habr.com