ProHoster > Blog > Amministrazione > A nostra sperienza in u sviluppu di un driver CSI in Kubernetes per Yandex.Cloud

A nostra sperienza in u sviluppu di un driver CSI in Kubernetes per Yandex.Cloud

A nostra sperienza in u sviluppu di un driver CSI in Kubernetes per Yandex.Cloud

Semu felici d'annunzià chì Flant espansione a so cuntribuzione à l'arnesi Open Source per Kubernetes alliberendu versione alfa di u driver CSI (Container Storage Interface) per Yandex.Cloud.

Ma prima di passà à i dettagli di implementazione, rispondemu à a quistione perchè questu hè necessariu quandu Yandex hà digià un serviziu. Serviziu amministratu per Kubernetes.

Introduzione

Perchè hè questu?

In a nostra cumpagnia, da u principiu di l'usu di Kubernetes in a pruduzzione (vale à dì dapoi parechji anni), avemu sviluppatu u nostru propiu strumentu (deckhouse), chì, per via, avemu ancu pensatu di rende prestu dispunibule cum'è un prughjettu Open Source. . Cù u so aiutu, cunfiguremu è cunfigumu uniformi tutti i nostri clusters, è attualmente ci sò digià più di 100 di elli, nantu à una larga varietà di cunfigurazioni hardware è in tutti i servizii cloud dispunibili.

I clusters chì utilizanu deckhouse anu tutti i cumpunenti necessarii per u funziunamentu: balancers, monitoring with convenient charts, metrics and alerts, user authentication through external providers for access to all dashboards, etc. Ùn ci hè nunda à stallà un tali cluster "pumped up" in una suluzione amministrata, postu chì questu hè spessu impussibile o porta à a necessità di disattivà a mità di i cumpunenti.

NB: Questa hè a nostra sperienza, è hè abbastanza specifica. Ùn suggeremu in ogni modu chì tutti duveranu implementà clusters Kubernetes per sè stessu invece di utilizà suluzioni pronti. Per via, ùn avemu micca una vera sperienza in uperazione di Kubernetes da Yandex è ùn daremu micca una valutazione di stu serviziu in questu articulu.

Chì ghjè è per quale ?

Dunque, avemu digià parlatu di l'approcciu mudernu à u almacenamiento in Kubernetes: cumu funziona CSI? и cumu hè ghjunta a cumunità à questu approcciu.

Attualmente, parechji grandi fornitori di servizii di nuvola anu sviluppatu drivers per utilizà i so dischi nuvola cum'è Volume Persistente in Kubernetes. Se u fornitore ùn hà micca un tali driver, ma tutte e funzioni necessarie sò furnite via l'API, allora nunda ùn impedisce di implementà u driver stessu. Questu hè accadutu cù Yandex.Cloud.

Avemu pigliatu cum'è una basa per u sviluppu Driver CSI per DigitalOcean cloud è un paru di idee da driver per GCP, Siccomu l'interazzione cù l'API di sti nuvole (Google è Yandex) hà parechje similitudini. In particulare, l'API è GCP, è à Yandex rinvià un oggettu Operation per seguità u statutu di l'operazioni longu (per esempiu, a creazione di un novu discu). Per interagisce cù l'API Yandex.Cloud, utilizate Yandex.Cloud Go SDK.

U risultatu di u travagliu fattu publicatu in GitHub è pò esse utile per quelli chì, per una certa ragione, utilizanu a so propria installazione Kubernetes nantu à e macchine virtuali Yandex.Cloud (ma micca un cluster gestionatu prontu) è vulete usà (ordine) dischi attraversu CSI.

Реализация

Funzioni chjave

Attualmente u driver supporta e seguenti funzioni:

  • Ordine di discu in tutte e zoni di u cluster secondu a topologia di i nodi in u cluster;
  • Eliminazione di dischi urdinati prima;
  • Resize offline per i dischi (Yandex.Cloud ùn sustene micca aumentendu i dischi chì sò muntati à a macchina virtuale). Per infurmazione nantu à cumu u cunduttore hà da esse mudificatu per fà ridimensionà u più indolore pussibule, vede quì sottu.

In u futuru, pensemu à implementà u supportu per creà è sguassà snapshots di discu.

A difficultà principale è cumu per superà

A mancanza di capacità di aumentà i dischi in tempu reale in l'API Yandex.Cloud hè una limitazione chì complica l'operazione di resize per PV (Volume Persistente): in questu casu, hè necessariu chì l'applicazione pod chì usa u discu sia fermatu, è questu pò causà applicazioni di downtime.

Sicondu Specificazioni CSI, se u controller CSI informa chì pò ridimensionà i dischi solu "offline" (VolumeExpansion.OFFLINE), allura u prucessu di aumentà u discu duveria esse cusì:

Se u plugin hà solu VolumeExpansion.OFFLINE A capacità di espansione è u voluminu hè attualmente publicatu o dispunibule nantu à un node allora ControllerExpandVolume DEVE esse chjamatu solu dopu:

  • U plugin hà un controller PUBLISH_UNPUBLISH_VOLUME capacità è ControllerUnpublishVolume hè statu invucatu cù successu.

O ALTRO

  • U plugin ùn hà micca un controller PUBLISH_UNPUBLISH_VOLUME capacità, u plugin hà node STAGE_UNSTAGE_VOLUME capacità, è NodeUnstageVolume hè stata cumpletata cù successu.

O ALTRO

  • U plugin ùn hà micca un controller PUBLISH_UNPUBLISH_VOLUME capacità, nè node STAGE_UNSTAGE_VOLUME capacità, è NodeUnpublishVolume hà finitu cun successu.

Questu significa essenzialmente chì avete bisognu di staccà u discu da a macchina virtuale prima di espansione.

Tuttavia, sfurtunatamenti implementazione A specificazione CSI via sidecars ùn risponde micca questi requisiti:

  • In un containeru sidecar csi-attacher, chì deve esse rispunsevuli di a presenza di u spaziu necessariu trà e muntagne, sta funziunalità ùn hè micca solu implementata in u resize offline. Una discussione nantu à questu hè stata iniziata ccà.
  • Chì ghjè esattamente un containeru sidecar in questu cuntestu? U plugin CSI stessu ùn interagisce micca cù l'API Kubernetes, ma solu risponde à e chjama gRPC mandate da cuntenituri sidecar. Ultimi sò sviluppati da a cumunità Kubernetes.

In u nostru casu (plugin CSI), l'operazione di aumentà u discu pare cusì:

  1. Ricevemu una chjamata gRPC ControllerExpandVolume;
  2. Pruvemu di aumentà u discu in l'API, ma avemu ricevutu un errore nantu à l'impossibilità di fà l'operazione perchè u discu hè muntatu;
  3. Guardamu l'identificatore di discu in a mappa, chì cuntene i dischi per i quali l'operazione di crescita deve esse realizatu. Sottu, per brevità, chjameremu sta mappa cum'è volumeResizeRequired;
  4. Eliminate manualmente u pod chì usa u discu. Kubernetes riavviarà. Cusì chì u discu ùn hà micca u tempu di muntà (ControllerPublishVolume) prima di cumpiendu l'operazione di crescita quandu si prova di muntà, verificamu chì u discu datu hè sempre in volumeResizeRequired è torna un errore;
  5. U driver CSI prova di ri-eseguisce l'operazione di resize. Se l'operazione hè successu, allora sguassate u discu volumeResizeRequired;
  6. Perchè L'ID di u discu manca volumeResizeRequired, ControllerPublishVolume passa cun successu, u discu hè muntatu, u pod principia.

Tuttu pare abbastanza simplice, ma cum'è sempre ci sò trappule. Ingrandisce i dischi resizer esternu, chì in casu d'errore durante l'operazione usa una fila cù un aumentu esponenziale di u tempu di timeout finu à 1000 seconde:

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)},
  )
}

Questu pò esse periòdicamenti chì l'operazione di espansione di discu hè allargata per più di 15 minuti è, cusì, u pod currispundente ùn hè micca dispunibule.

L'unica opzione chì abbastanza facilmente è senza dolore ci hà permessu di riduce i tempi di inattività potenziale era l'usu di a nostra versione di resizer esternu cù un limitu massimu di timeout. in 5 seconde:

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

Ùn avemu micca cunsideratu necessariu d'inizià urgentemente una discussione è patch u resizer esternu, perchè u resize offline di i dischi hè un ritruvamentu chì sparirà prestu da tutti i fornituri di nuvola.

Cumu cumincià à aduprà?

U driver hè supportatu in Kubernetes versione 1.15 è superiore. Per u travagliu di u cunduttore, deve esse cumpletu i seguenti requisiti:

  • Bandiera --allow-privileged mette à valore true per u servitore API è kubelet;
  • Inclusu --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true per u servitore API è kubelet;
  • propagazione di muntagna (propagazione di muntagna) deve esse attivatu nantu à u cluster. Quandu si usa Docker, u demoniu deve esse cunfiguratu per permette e muntagne spartute.

Tutti i passi necessarii per a stallazione stessu descritta in README. L'installazione implica a creazione di oggetti in Kubernetes da manifesti.

Perchè u driver per travaglià, avete bisognu di i seguenti:

  • Specificate l'identificatore di u cartulare in u manifestu (folder-id) Yandex.Cloud (vede a documentazione);
  • Per interagisce cù l'API Yandex.Cloud, u driver CSI usa un contu di serviziu. In u manifestu, Secret deve esse passatu chjavi autorizati da u contu di serviziu. In a documentazione descrittu, cumu per creà un contu di serviziu è uttene chjave.

Tuttu in tuttu - pruvà, è saremu felici di riceve feedback è prublemi novis'è tù scontri ogni prublema!

Più sustegnu

In u risultatu, vulemu nutà chì avemu implementatu stu driver CSI micca per un grande desideriu di divertisce l'applicazioni di scrittura in Go, ma per una necessità urgente in a cumpagnia. Ùn ci pare micca praticu di mantene a nostra propria implementazione, perchè se Yandex mostra interessu è decide di cuntinuà à sustene u driver, seremu felici di trasfirià u repository à elli.

Inoltre, Yandex hà prubabilmente a so propria implementazione di u driver CSI in u so cluster Kubernetes amministratu, chì pò esse liberatu in Open Source. Avemu ancu vede sta opzione di sviluppu cum'è favurevule - a cumunità puderà utilizà un driver pruvucatu da un fornitore di serviziu, è micca da una cumpagnia di terzu.

PS

Leghjite puru nant'à u nostru blog:

Source: www.habr.com

Add a comment