Jatkoa viimeisimpään Yandex.Cloudille julkaisemme toisen avoimen lähdekoodin projektin tälle pilvelle - . CCM:ää vaaditaan paitsi koko klusterille, myös itse CSI-ohjaimelle. Yksityiskohdat sen tarkoituksesta ja joistakin toteutusominaisuuksista ovat alla.
Esittely
Miksi tämä on?
Motiivit, jotka saivat meidät kehittämään CCM:n Yandex.Cloudille, ovat täysin samat kuin ne, jotka on jo kuvattu CSI-ajurit. Ylläpidämme useita Kubernetes-klustereita eri pilvipalveluntarjoajilta, joihin käytämme yhtä työkalua. Se toteuttaa lukuisia mukavuuksia "ohittaen" näiden tarjoajien hallitut ratkaisut. Kyllä, meillä on melko spesifinen tapaus ja tarpeet, mutta niiden johdosta syntyvistä kehityksestä voi olla hyötyä muille käyttäjille.
Mikä CCM oikein on?
Yleensä valmistelemme ympäristöämme klusteria varten ulkopuolelta - esimerkiksi käyttämällä Terraformia. Mutta joskus on tarvetta hallita ympärillämme olevaa pilviympäristöä klusterista. Tämä mahdollisuus tarjotaan, ja se toteutetaan .
Cloud Controller Manager tarjoaa viisi vuorovaikutuksen päätyyppiä:
- instansseja – toteuttaa 1:1-suhteen solmuobjektin välillä Kubernetesissa (
Node) ja virtuaalikone pilvipalvelussa. Tätä varten me:- täytä kenttä
spec.providerIDobjektissaNode. Esimerkiksi OpenStack CCM:ssä tämän kentän muoto on seuraava:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Näet pilvipalveluntarjoajan nimen ja objektin palvelimen (virtuaalikone OpenStackissa) yksilöllisen UUID-tunnuksen; - täydentää
nodeInfoobjektissaNodetietoja virtuaalikoneesta. Esimerkiksi määritämme ilmentymän tyypin AWS:ssä; - Tarkistamme virtuaalikoneen läsnäolon pilvessä. Esimerkiksi jos esine
Nodemeni tilaanNotReady, voit tarkistaa, onko virtuaalikonetta ollenkaan pilvipalvelun tarjoajassaproviderID. Jos sitä ei ole, poista objektiNode, joka muuten pysyisi klusterissa ikuisesti;
- täytä kenttä
- Zones – määrittää objektin vikaalueen
Node, jotta ajoittaja voi valita solmun Podille pilvipalveluntarjoajan alueiden ja vyöhykkeiden mukaan; - LoadBalancer – kun luot objektia
Servicetyypin kanssaLoadBalancerluo eräänlaisen tasapainottimen, joka ohjaa liikenteen ulkopuolelta klusterin solmuihin. Esimerkiksi Yandex.Cloudissa voit käyttääNetworkLoadBalancerиTargetGroupnäihin tarkoituksiin; - Reitti – rakentaa verkon solmujen välille, koska Kubernetesin vaatimusten mukaan jokaisella podilla on oltava oma IP-osoite ja ne on voitava tavoittaa kaikki muut pod. Näihin tarkoituksiin voit käyttää peittoverkkoa (VXLAN, GENEVE) tai asettaa reititystaulukon suoraan pilvipalveluntarjoajan virtuaaliverkkoon:
- tilavuus – Mahdollistaa PV:n ja SC:n dynaamisen tilauksen. Tämä toiminto oli alun perin osa CCM:ää, mutta sen monimutkaisuuden vuoksi se siirrettiin erilliseen projektiin, Container Storage Interface (CSI). Olemme puhuneet CSI:stä useammin kuin kerran ja, kuten jo mainittiin, jopa CSI kuljettaja.
Aiemmin kaikki pilven kanssa vuorovaikutuksessa oleva koodi sijaitsi Kubernetes-projektin Git-päävarastossa osoitteessa k8s.io/kubernetes/pkg/cloudprovider/providers, mutta he päättivät luopua tästä suuren koodikannan kanssa työskentelyn haitan vuoksi. Kaikki vanhat toteutukset on siirretty . Lisätuen ja kehittämisen helpottamiseksi kaikki yhteiset komponentit siirrettiin myös .
Kuten CSI:n kohdalla, monet suuret pilvipalveluntarjoajat ovat jo suunnitelleet CCM:nsä hyödyntämään Kubernetesin pilviä. Jos toimittajalla ei ole CCM:ää, mutta kaikki tarvittavat toiminnot ovat saatavilla API:n kautta, voit ottaa CCM:n käyttöön itse.
Oman CCM-toteutuksen kirjoittamiseen riittää toteuttaminen .
И .
Реализация
Miten päädyit tähän
Aloitimme kehityksen (tai pikemminkin jopa käytön) kanssa Yandex.Cloudille vuosi sitten.
Tästä toteutuksesta meiltä kuitenkin puuttui:
- todennus JWT IAM -tunnuksen kautta;
- Huoltoohjaimen tuki.
Yhteisymmärryksessä kirjoittajan kanssa (dlisin) Telegramissa haaroitimme yandex-cloud-controller-managerin ja lisäsimme puuttuvat toiminnot.
Tärkeimmät ominaisuudet
Tällä hetkellä CCM tukee seuraavia rajapintoja:
- instansseja;
- Zones;
- LoadBalancer.
Jatkossa, kun Yandex.Cloud alkaa työskennellä kehittyneiden VPC-ominaisuuksien kanssa, lisäämme käyttöliittymän reitit.
LoadBalanacer päähaasteena
Aluksi yritimme muiden CCM-toteutusten tapaan luoda parin LoadBalancer и TargetGroup kaikille Service tyypin kanssa LoadBalancer. Yandex.Cloud löysi kuitenkin yhden mielenkiintoisen rajoituksen: et voi käyttää TargetGroups risteävien kanssa Targets (pari SubnetID - IpAddress).
Siksi luodun CCM:n sisällä käynnistetään ohjain, joka objektien muuttuessa Node kerää tietoa jokaisen virtuaalikoneen kaikista liitännöistä, ryhmittelee ne kuulumisen mukaan tiettyihin NetworkID, luo TargetGroup päälle NetworkIDja valvoo myös osuvuutta. Tämän jälkeen objektia luotaessa Service tyypin kanssa LoadBalanacer liitämme yksinkertaisesti valmiiksi luodun TargetGroup uuteen NetworkLoadBalanacer'olen.
Kuinka aloittaa sen käyttö?
CCM tukee Kubernetes-versiota 1.15 ja uudempia. Klusterissa, jotta se toimisi, se vaatii lippua --cloud-provider=external oli asetettu true kube-apiserverille, kube-controller-managerille, kube-schedulerille ja kaikille kubeleteille.
Kaikki asennukseen tarvittavat vaiheet on kuvattu kohdassa . Asennus tiivistyy objektien luomiseen Kubernetesiin luetteloista.
CCM:n käyttämiseen tarvitset myös:
- manifestissa hakemiston tunniste (
folder-id) Yandex.Cloud; - palvelutili vuorovaikutukseen Yandex.Cloud API:n kanssa. Manifestissa
Secrettäytyy palvelutililtä. Dokumentaatiossa , kuinka luodaan palvelutili ja hankitaan avaimet.
Otamme mielellämme palautetta vastaan ja jos kohtaat ongelmia!
Tulokset
Olemme käyttäneet toteutettua CCM:ää viidessä Kubernetes-klusterissa viimeisen kahden viikon aikana ja aiomme laajentaa niiden lukumäärän 20:een seuraavan kuukauden aikana. Emme tällä hetkellä suosittele CCM:n käyttöä suuriin ja kriittisiin K8s-asennuksiin.
Kuten CSI:n tapauksessa, olemme iloisia, jos Yandex-kehittäjät ottavat tämän projektin kehittämisen ja tuen - olemme valmiita siirtämään arkiston heidän pyynnöstään käsitelläksemme meille tärkeämpiä tehtäviä.
PS.
Lue myös blogistamme:
- «";
- «";
- «'.
Lähde: will.com