ProHoster > Blogi > Haldamine > Meie kogemus CSI draiveri arendamisel Kubernetes Yandex.Cloudi jaoks

Meie kogemus CSI draiveri arendamisel Kubernetes Yandex.Cloudi jaoks

Meie kogemus CSI draiveri arendamisel Kubernetes Yandex.Cloudi jaoks

Meil on hea meel teatada, et Flant laiendab oma panust Kubernetese avatud lähtekoodiga tööriistadesse, avaldades CSI draiveri alfaversioon (konteineri salvestusliides) Yandex.Cloudi jaoks.

Kuid enne juurutamise üksikasjade juurde asumist vastame küsimusele, miks seda üldse vaja on, kui Yandexil on juba teenus Kubernetese hallatav teenus.

Sissejuhatus

Miks on see?

Oma ettevõtte sees oleme Kubernetese tootmises kasutamise algusest (st juba mitu aastat) arendanud oma tööriista (deckhouse), mille, muide, plaanime peagi ka avatud lähtekoodiga projektina kättesaadavaks teha . Tema abiga konfigureerime ja konfigureerime ühtselt kõik oma klastrid ning praegu on neid juba üle 100, väga erinevatel riistvarakonfiguratsioonidel ja kõigis saadaolevates pilveteenustes.

Deckhouse'i kasutavatel klastritel on kõik tööks vajalikud komponendid: tasakaalustajad, mugavate diagrammide, mõõdikute ja hoiatustega jälgimine, kasutaja autentimine väliste pakkujate kaudu juurdepääsuks kõigile armatuurlaudadele jne. Sellist "ülespumbatud" klastrit pole mõtet hallatavasse lahendusse installida, kuna see on sageli kas võimatu või toob kaasa vajaduse pooled komponendid keelata.

NB: See on meie kogemus ja see on üsna spetsiifiline. Me ei soovita mingil juhul, et kõik peaksid valmislahenduste kasutamise asemel Kubernetese klastreid iseseisvalt juurutama. Muide, meil pole Yandexi Kubernetese haldamisel tegelikku kogemust ja me ei anna selles artiklis sellele teenusele hinnangut.

Mis see on ja kellele?

Niisiis, oleme juba rääkinud Kubernetese kaasaegsest ladustamisviisist: kuidas CSI töötab? и kuidas kogukond tuli sellele lähenemisele.

Praegu on paljud suured pilveteenuse pakkujad välja töötanud draiverid, mis võimaldavad kasutada oma pilvekettaid Kubernetes püsiva helina. Kui tarnijal sellist draiverit pole, kuid kõik vajalikud funktsioonid on API kaudu tagatud, ei takista miski teil draiverit ise juurutada. See juhtus Yandex.Cloudiga.

Võtsime arengu aluseks CSI draiver DigitalOceani pilve jaoks ja paar ideed draiverid GCP jaoks, kuna interaktsioonil nende pilvede API-ga (Google ja Yandex) on mitmeid sarnasusi. Eelkõige API ja GCPja Yandex tagastada objekt Operation kauakestvate toimingute oleku jälgimiseks (näiteks uue ketta loomine). Yandex.Cloud API-ga suhtlemiseks kasutage Yandex.Cloud Go SDK.

Tehtud töö tulemus avaldatud GitHubis ja võib olla kasulik neile, kes mingil põhjusel kasutavad oma Kubernetese installi Yandex.Cloudi virtuaalmasinatesse (aga mitte valmis hallatud klastrit) ja sooviksid kasutada (tellida) kettaid CSI kaudu.

Реализация

Peamised omadused

Praegu toetab draiver järgmisi funktsioone:

  • Ketaste järjestamine klastri kõigis tsoonides vastavalt klastri sõlmede topoloogiale;
  • Varem tellitud plaatide eemaldamine;
  • Võrguühenduseta ketaste suuruse muutmine (Yandex.Cloud ei toeta virtuaalmasinasse ühendatud ketaste suurendamine). Teavet selle kohta, kuidas draiverit tuli muuta, et muuta suuruse muutmine võimalikult valutuks, vt allpool.

Tulevikus plaanime rakendada kettahetketõmmiste loomise ja kustutamise tuge.

Peamised raskused ja kuidas sellest üle saada

Ketaste reaalajas suurendamise võimaluse puudumine Yandex.Cloud API-s on piirang, mis raskendab PV (püsiva helitugevuse) suuruse muutmise toimingut: sel juhul on vaja ketast kasutava rakendusepodi peatada, ja see võib põhjustada seisakurakendusi.

Vastavalt CSI spetsifikatsioonid, kui CSI-kontroller teatab, et suudab ketaste suurust muuta ainult võrguühenduseta (VolumeExpansion.OFFLINE), siis peaks ketta suurendamise protsess käima järgmiselt:

Kui pistikprogrammil on ainult VolumeExpansion.OFFLINE laiendusvõimalus ja maht on praegu avaldatud või siis sõlmes saadaval ControllerExpandVolume TULEB helistada AINULT kas pärast:

  • Pistikprogrammil on kontroller PUBLISH_UNPUBLISH_VOLUME võimekust ja ControllerUnpublishVolume on edukalt välja kutsutud.

VÕI MUIDU

  • Pluginal EI OLE kontrollerit PUBLISH_UNPUBLISH_VOLUME võimalus, on pistikprogrammil sõlm STAGE_UNSTAGE_VOLUME võimekust ja NodeUnstageVolume on edukalt lõpule viidud.

VÕI MUIDU

  • Pluginal EI OLE kontrollerit PUBLISH_UNPUBLISH_VOLUME võimekust ega sõlme STAGE_UNSTAGE_VOLUME võimekust ja NodeUnpublishVolume on edukalt lõpule viidud.

See tähendab sisuliselt, et peate ketta virtuaalmasinast enne selle laiendamist lahti võtma.

Siiski kahjuks rakendamine Külgkorvide CSI spetsifikatsioon ei vasta järgmistele nõuetele:

  • Külgkorvi konteineris csi-attacher, mis peaks vastutama kinnituste vahel vajaliku tühimiku olemasolu eest, seda funktsiooni võrguühenduseta suuruse muutmisel lihtsalt ei rakendata. Selle üle algatati arutelu siin.
  • Mis on selles kontekstis külgkorvi konteiner? CSI pistikprogramm ise ei suhtle Kubernetes API-ga, vaid vastab ainult külgkorvi konteinerite poolt talle saadetud gRPC-kõnedele. Viimased arendamisel Kubernetese kogukonna poolt.

Meie puhul (CSI-plugin) näeb ketta suurendamise toiming välja järgmine:

  1. Saame grRPC kõne ControllerExpandVolume;
  2. Püüame API-s ketast suurendada, kuid saame veateate toimingu võimatuse kohta, kuna ketas on ühendatud;
  3. Ketta identifikaatori salvestame kaardile, mis sisaldab kettaid, mille puhul on vaja teha suurendamisoperatsioon. Allpool nimetame seda kaarti lühiduse huvides kui volumeResizeRequired;
  4. Eemaldage käsitsi plaat, mis kasutab ketast. Kubernetes taaskäivitab selle. Nii et kettal pole aega monteerida (ControllerPublishVolume) enne suurendamistoimingu lõpetamist ühendamise katsel kontrollime, kas antud ketas on ikka sees volumeResizeRequired ja tagastab vea;
  5. CSI draiver proovib suuruse muutmise toimingut uuesti käivitada. Kui toiming õnnestus, eemaldage ketas volumeResizeRequired;
  6. Sest Ketta ID puudub volumeResizeRequired, ControllerPublishVolume läbib edukalt, ketas on paigaldatud, pod käivitub.

Kõik tundub piisavalt lihtne, kuid nagu alati, on lõkse. Suurendab kettaid väline suuruse muutja, mis operatsiooni käigus ilmnenud vea korral kasutab järjekorda aegumise aja eksponentsiaalse pikenemisega kuni 1000 sekundini:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

See võib aeg-ajalt põhjustada ketta laiendamise toimingu pikenemist 15+ minutiks ja seega ei ole vastav moodul saadaval.

Ainus võimalus, mis üsna lihtsalt ja valutult võimaldas meil võimalikke seisakuid vähendada, oli meie välise suuruse muutja versiooni kasutamine maksimaalse ajalõpu piiranguga. 5 sekundiga:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

Kiiremas korras arutelu algatamist ja välise suuruse muutja lappimist me vajalikuks ei pidanud, sest offline ketaste suuruse muutmine on tagasiminek, mis kaob peagi kõigilt pilvepakkujatelt.

Kuidas kasutama hakata?

Draiverit toetavad Kubernetese versioonid 1.15 ja uuemad. Juhi töötamiseks peavad olema täidetud järgmised nõuded:

  • Lipp --allow-privileged väärtusele seatud true API serveri ja kubeleti jaoks;
  • Kaasas --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API serveri ja kubeleti jaoks;
  • Mount levik (mägi levik) peab olema klastris lubatud. Dockeri kasutamisel peab deemon olema konfigureeritud lubama jagatud kinnitusi.

Kõik installimiseks vajalikud sammud kirjeldatud README-s. Installimine hõlmab Kubernetesis objektide loomist manifestidest.

Juhi töötamiseks vajate järgmist:

  • Määrake manifestis kataloogi identifikaator (folder-id) Yandex.Cloud (vaata dokumentatsiooni);
  • Yandex.Cloud API-ga suhtlemiseks kasutab CSI draiver teenusekontot. Manifestis tuleb Saladus läbida volitatud võtmed teenusekontolt. Dokumentatsioonis kirjeldatud, kuidas luua teenusekontot ja hankida võtmeid.

Kokkuvõttes - proovige seda, ja me saame hea meelega tagasisidet ja uued küsimusedkui teil tekib probleeme!

Edasine toetus

Selle tulemusel tahame märkida, et juurutasime selle CSI draiveri mitte suurest soovist Go-s rakendusi lõbusalt kirjutada, vaid ettevõttesisesest tungivast vajadusest. Meile ei tundu otstarbekas oma juurutamist säilitada, nii et kui Yandex ilmutab huvi ja otsustab draiverit jätkuvalt toetada, anname hoidla hea meelega neile üle.

Lisaks on Yandexil tõenäoliselt oma hallatavas Kubernetese klastris oma CSI draiveri juurutamine, mille saab välja anda avatud lähtekoodiga. Samuti näeme seda arendusvõimalust soodsana – kogukond saab kasutada tõestatud draiverit teenusepakkujalt, mitte kolmanda osapoole ettevõttelt.

PS

Loe ka meie blogist:

Allikas: www.habr.com

Lisa kommentaar