Vi introduserer Kubernetes CCM (Cloud Controller Manager) for Yandex.Cloud

I forlengelsen av det siste CSI-driverutgivelse for Yandex.Cloud publiserer vi et annet åpen kildekode-prosjekt for denne skyen - Cloud Controller Manager. CCM kreves ikke bare for klyngen som helhet, men også for selve CSI-driveren. Detaljer om formålet og noen implementeringsfunksjoner er under kuttet.

Innledning

Hvorfor er det sånn?

Motivene som fikk oss til å utvikle CCM for Yandex.Cloud er fullstendig sammenfallende med de som allerede er beskrevet i kunngjøringer CSI-drivere. Vi vedlikeholder mange Kubernetes-klynger fra forskjellige skyleverandører, som vi bruker ett enkelt verktøy for. Den implementerer en rekke bekvemmeligheter «omgå» de administrerte løsningene til disse leverandørene. Ja, vi har en ganske spesifikk sak og behov, men utviklingen som er opprettet på grunn av dem, kan være nyttig for andre brukere.

Hva er egentlig CCM?

Vanligvis forbereder vi miljøet rundt oss for klyngen utenfra - for eksempel ved å bruke Terraform. Men noen ganger er det behov for å administrere skymiljøet rundt oss fra klyngen. Denne muligheten er gitt, og det er den som implementeres CCM.

Nærmere bestemt gir Cloud Controller Manager fem hovedtyper av interaksjon:

1. Forekomster – implementerer et 1:1 forhold mellom et nodeobjekt i Kubernetes (Node) og en virtuell maskin i skyleverandøren. Til dette:
   • fyll ut feltet spec.providerID i objektet Node. For OpenStack CCM har dette feltet for eksempel følgende format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Du kan se navnet på skyleverandøren og den unike UUIDen til serveren (virtuell maskin i OpenStack) til objektet;
   • komplement nodeInfo i objektet Node informasjon om den virtuelle maskinen. For eksempel spesifiserer vi instanstype i AWS;
   • Vi sjekker tilstedeværelsen av en virtuell maskin i skyen. For eksempel hvis et objekt Node gikk inn i en tilstand NotReady, kan du sjekke om den virtuelle maskinen eksisterer i det hele tatt i skyleverandøren ved providerID. Hvis det ikke er der, slett objektet Node, som ellers ville forbli i klyngen for alltid;
2. Soner – setter feildomenet for objektet Node, slik at planleggeren kan velge en node for Pod i henhold til regionene og sonene i skyleverandøren;
3. LoadBalancer – når du lager et objekt Service med type LoadBalancer skaper en slags balanserer som vil lede trafikk utenfra til klyngenodene. For eksempel, i Yandex.Cloud kan du bruke NetworkLoadBalancer и TargetGroup for disse formålene;
4. Rute – bygger et nettverk mellom noder, fordi I henhold til Kubernetes krav, må hver pod ha sin egen IP-adresse og kunne nå enhver annen pod. For disse formålene kan du bruke et overleggsnettverk (VXLAN, GENEVE) eller sette en rutetabell direkte i det virtuelle nettverket til skyleverandøren:

   

5. Volum – Tillater dynamisk bestilling av PV ved bruk av PVC og SC. I utgangspunktet var denne funksjonaliteten en del av CCM, men på grunn av sin store kompleksitet ble den flyttet til et eget prosjekt, Container Storage Interface (CSI). Vi har snakket om CSI mer enn én gang skrev og, som allerede nevnt, til og med løslatt CSI driver.

Tidligere var all kode som samhandlet med skyen plassert i hovedlageret for Git til Kubernetes-prosjektet på k8s.io/kubernetes/pkg/cloudprovider/providers, men de bestemte seg for å forlate dette på grunn av ulempen med å jobbe med en stor kodebase. Alle gamle implementeringer er flyttet til eget depot. For å lette videre støtte og utvikling ble alle felleskomponenter også flyttet til eget depot.

Som med CSI, har mange store skyleverandører allerede designet sine CCM-er for å utnytte skyer på Kubernetes. Hvis leverandøren ikke har CCM, men alle nødvendige funksjoner er tilgjengelige via API, så kan du implementere CCM selv.

For å skrive din egen implementering av CCM er det nok å implementere nødvendige Go-grensesnitt.

И dette er hva vi fikk.

implementering

Hvordan kom du frem til dette

Vi startet utvikling (eller rettere sagt, til og med bruk) med klar(!) CCM for Yandex.Cloud for et år siden.

I denne implementeringen manglet vi imidlertid:

• autentisering via JWT IAM-token;
• Servicekontrollerstøtte.

I samråd med forfatteren (dlisin) i Telegram gaf vi yandex-cloud-controller-manager og la til de manglende funksjonene.

Viktige funksjoner

For øyeblikket støtter CCM følgende grensesnitt:

• Forekomster;
• Soner;
• LoadBalancer.

I fremtiden, når Yandex.Cloud begynner å jobbe med avanserte VPC-funksjoner, vil vi legge til et grensesnitt ruter.

LoadBalanacer som hovedutfordring

I utgangspunktet prøvde vi, som andre CCM-implementeringer, å lage et par LoadBalancer и TargetGroup for alle Service med type LoadBalancer. Yandex.Cloud oppdaget imidlertid en interessant begrensning: du kan ikke bruke TargetGroups med kryssende Targets (par SubnetID - IpAddress).

Derfor, inne i den opprettede CCM, lanseres en kontroller, som når objekter endres Node samler informasjon om alle grensesnitt på hver virtuell maskin, grupperer dem etter deres tilhørighet til visse NetworkID, skaper av TargetGroup på NetworkID, og overvåker også relevansen. Deretter når du oppretter et objekt Service med type LoadBalanacer vi legger bare ved en forhåndsopprettet TargetGroup til nytt NetworkLoadBalanacer'er.

Hvordan begynne å bruke?

CCM støtter Kubernetes versjon 1.15 og høyere. I en klynge, for at det skal fungere, krever det at flagget --cloud-provider=external ble satt til true for kube-apiserver, kube-controller-manager, kube-scheduler og alle kubelets.

Alle nødvendige trinn for selve installasjonen er beskrevet i README. Installasjon koker ned til å lage objekter i Kubernetes fra manifester.

For å bruke CCM trenger du også:

• peke ut i manifestet katalogidentifikatoren (folder-id) Yandex.Cloud;
• tjenestekonto for samhandling med Yandex.Cloud API. I manifestet Secret må overføre autoriserte nøkler fra tjenestekontoen. I dokumentasjonen beskrevet, hvordan du oppretter en tjenestekonto og får nøkler.

Vi vil gjerne motta tilbakemeldinger og nye problemstillingerhvis du støter på problemer!

Resultater av

Vi har brukt den implementerte CCM i fem Kubernetes-klynger i løpet av de siste to ukene og planlegger å utvide antallet til 20 i løpet av den kommende måneden. Vi anbefaler foreløpig ikke bruk av CCM for store og kritiske K8s-installasjoner.

Som i tilfellet med CSI, vil vi være glade hvis Yandex-utviklere tar på seg utviklingen og støtten til dette prosjektet - vi er klare til å overføre depotet på deres forespørsel for å håndtere oppgaver som er mer relevante for oss.

PS

Les også på bloggen vår:

• «Vår erfaring med å utvikle en CSI-driver i Kubernetes for Yandex.Cloud";
• «Er det enkelt og praktisk å forberede en Kubernetes-klynge? Kunngjør tilleggsoperatør";
• «Utvide og komplettere Kubernetes (gjennomgang og videorapport)'.

Kilde: www.habr.com