Yandex.Cloud üçün Kubernetes-də CSI sürücüsünü inkişaf etdirmək təcrübəmiz

Flant-ın Kubernetes üçün Açıq Mənbə alətlərinə töhfəsini genişləndirdiyini elan etməkdən məmnunuq. CSI sürücüsünün alfa versiyası Yandex.Cloud üçün (Container Storage Interface).

Ancaq tətbiqin təfərrüatlarına keçməzdən əvvəl, Yandex-də artıq bir xidmət olduqda bunun niyə lazım olduğu sualına cavab verək Kubernetes üçün idarə olunan xidmət.

Giriş

Niyə bu?

Şirkətimiz daxilində Kubernetes-i istehsalda istifadə etməyə başladığı ilk gündən (yəni artıq bir neçə ildir) biz öz alətimizi (göyərtəxana) inkişaf etdiririk, yeri gəlmişkən, biz də tezliklə Açıq Mənbə layihəsi kimi təqdim etməyi planlaşdırırıq. . Onun köməyi ilə biz bütün klasterlərimizi vahid şəkildə konfiqurasiya edirik və konfiqurasiya edirik və hazırda onların 100-dən çoxu müxtəlif aparat konfiqurasiyalarında və bütün mövcud bulud xidmətlərində mövcuddur.

Deckhouse-dan istifadə edən klasterlər işləmək üçün lazım olan bütün komponentlərə malikdir: balanslaşdırıcılar, rahat qrafiklər, ölçülər və xəbərdarlıqlarla monitorinq, bütün tablosuna daxil olmaq üçün xarici provayderlər vasitəsilə istifadəçinin autentifikasiyası və s. İdarə olunan bir həlldə belə bir "pompalanmış" klaster quraşdırmağın mənası yoxdur, çünki bu, çox vaxt ya qeyri-mümkün olur, ya da komponentlərin yarısını söndürmək ehtiyacına səbəb olacaqdır.

NB: Bu, bizim təcrübəmizdir və olduqca spesifikdir. Biz heç bir şəkildə hər kəsin hazır həllərdən istifadə etmək əvəzinə Kubernetes klasterlərini təkbaşına yerləşdirməyi təklif etmirik. Yeri gəlmişkən, Yandex-dən Kubernetes-i idarə etməkdə heç bir real təcrübəmiz yoxdur və bu məqalədə bu xidmətə heç bir qiymət verməyəcəyik.

Bu nədir və kimə?

Beləliklə, Kubernetes-də saxlama üçün müasir yanaşma haqqında artıq danışdıq: CSI necə işləyir? и cəmiyyət necə gəldi bu yanaşmaya.

Hal-hazırda, bir çox böyük bulud xidməti təminatçıları bulud disklərini Kubernetes-də Davamlı Həcm kimi istifadə etmək üçün drayverlər hazırlayıblar. Təchizatçının belə bir sürücüsü yoxdursa, lakin bütün lazımi funksiyalar API vasitəsilə təmin edilirsə, o zaman heç bir şey sürücünü özünüz həyata keçirməyə mane olmur. Yandex.Cloud ilə belə oldu.

İnkişaf üçün əsas götürdük DigitalOcean bulud üçün CSI sürücüsü və bir neçə fikir GCP üçün sürücülər, çünki bu buludların API ilə qarşılıqlı əlaqə (Google və Yandex) bir sıra oxşarlıqlara malikdir. Xüsusilə, API və GCPvə Yandex obyekti qaytarın Operation uzun müddət davam edən əməliyyatların vəziyyətini izləmək (məsələn, yeni disk yaratmaq). Yandex.Cloud API ilə qarşılıqlı əlaqə yaratmaq üçün istifadə edin Yandex.Cloud Go SDK.

Görülən işlərin nəticəsi GitHub-da dərc edilmişdir və nədənsə Yandex.Cloud virtual maşınlarında öz Kubernetes quraşdırmasından istifadə edənlər (lakin hazır idarə olunan klaster deyil) və CSI vasitəsilə disklərdən istifadə etmək (sifariş etmək) istəyənlər üçün faydalı ola bilər.

Tətbiq

Əsas xüsusiyyətlər

Hazırda sürücü aşağıdakı funksiyaları dəstəkləyir:

• Klasterdəki qovşaqların topologiyasına uyğun olaraq klasterin bütün zonalarında disklərin sifarişi;
• Əvvəllər sifariş edilmiş disklərin çıxarılması;
• Disklər üçün oflayn ölçü dəyişikliyi (Yandex.Cloud dəstəkləməyin virtual maşına quraşdırılmış disklərin artırılması). Ölçü dəyişdirməni mümkün qədər ağrısız etmək üçün sürücünün necə dəyişdirilməsi barədə məlumat üçün aşağıya baxın.

Gələcəkdə biz disk anlıq görüntülərinin yaradılması və silinməsi üçün dəstəyi həyata keçirməyi planlaşdırırıq.

Əsas çətinlik və onu necə aradan qaldırmaq olar

Yandex.Cloud API-də real vaxt rejimində diskləri artırmaq qabiliyyətinin olmaması PV (Daimi Həcmi) üçün ölçüsünün dəyişdirilməsi əməliyyatını çətinləşdirən bir məhdudiyyətdir: bu halda, diskdən istifadə edən proqram podunun dayandırılması lazımdır, və bu, tətbiqlərin dayandırılmasına səbəb ola bilər.

Uyğun olaraq CSI spesifikasiyası, əgər CSI nəzarətçisi disklərin ölçüsünü yalnız “oflayn” dəyişə biləcəyini bildirirsə (VolumeExpansion.OFFLINE), onda diskin artırılması prosesi belə getməlidir:

Plugin yalnız varsa VolumeExpansion.OFFLINE genişləndirmə qabiliyyəti və həcmi hal-hazırda nəşr olunur və ya o zaman bir qovşaqda mövcuddur ControllerExpandVolume YALNIZ aşağıdakılardan sonra çağırılmalıdır:

• Plugin nəzarətçiyə malikdir PUBLISH_UNPUBLISH_VOLUME qabiliyyəti və ControllerUnpublishVolume uğurla çağırılıb.

YAXŞI

• Plugin nəzarətçi YOXDUR PUBLISH_UNPUBLISH_VOLUME imkan, plaqinin qovşağı var STAGE_UNSTAGE_VOLUME qabiliyyəti və NodeUnstageVolume uğurla başa çatmışdır.

YAXŞI

• Plugin nəzarətçi YOXDUR PUBLISH_UNPUBLISH_VOLUME qabiliyyəti, nə də node STAGE_UNSTAGE_VOLUME qabiliyyəti və NodeUnpublishVolume uğurla başa vurdu.

Bu o deməkdir ki, diski genişləndirməzdən əvvəl onu virtual maşından ayırmalısınız.

Lakin, təəssüf ki həyata keçirilməsi Yan arabalar vasitəsilə CSI spesifikasiyası bu tələblərə cavab vermir:

• Yan qutuda csi-attacher, montajlar arasında tələb olunan boşluğun olması üçün cavabdeh olmalıdır, bu funksionallıq oflayn ölçüdə sadəcə həyata keçirilmir. Bununla bağlı müzakirəyə başlanılıb burada.
• Bu kontekstdə yan vaqon konteyneri tam olaraq nədir? CSI plagininin özü Kubernetes API ilə qarşılıqlı əlaqə yaratmır, ancaq yan vaqon konteynerləri ilə ona göndərilən gRPC zənglərinə cavab verir. Ən son inkişaf etdirilir Kubernetes icması tərəfindən.

Bizim vəziyyətimizdə (CSI plagini), diskin artırılması əməliyyatı belə görünür:

1. Biz gRPC zəngi alırıq ControllerExpandVolume;
2. API-də diski artırmağa çalışırıq, lakin disk quraşdırıldığı üçün əməliyyatın həyata keçirilməsinin mümkünsüzlüyü ilə bağlı xəta alırıq;
3. Disk identifikatorunu artırma əməliyyatının yerinə yetirilməli olduğu diskləri ehtiva edən xəritədə saxlayırıq. Aşağıda qısalıq üçün bu xəritəni adlandıracağıq volumeResizeRequired;
4. Diski istifadə edən podu əl ilə çıxarın. Kubernetes onu yenidən işə salacaq. Diskin quraşdırmaq üçün vaxtı olmaması üçün (ControllerPublishVolume) quraşdırmaya cəhd edərkən artırma əməliyyatını tamamlamadan əvvəl verilmiş diskin hələ də içəridə olduğunu yoxlayırıq volumeResizeRequired və səhv qaytarmaq;
5. CSI sürücüsü ölçüsünü dəyişmə əməliyyatını yenidən yerinə yetirməyə çalışır. Əməliyyat uğurlu olarsa, diski çıxarın volumeResizeRequired;
6. Çünki Disk ID-si yoxdur volumeResizeRequired, ControllerPublishVolume uğurla keçir, disk quraşdırılır, pod işə düşür.

Hər şey kifayət qədər sadə görünür, amma həmişə olduğu kimi tələlər var. Diskləri böyüdür xarici resizer, əməliyyat zamanı xəta baş verdikdə növbədən istifadə edir 1000 saniyəyə qədər fasilə müddətində eksponensial artım ilə:

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

Bu, vaxtaşırı diskin genişləndirilməsi əməliyyatının 15+ dəqiqə uzadılmasına və beləliklə, müvafiq podun əlçatmaz olmasına səbəb ola bilər.

Potensial dayanma müddətini azaltmağa kifayət qədər asanlıqla və ağrısız bir şəkildə imkan verən yeganə seçim, maksimum fasilə limiti olan xarici resizer versiyamızın istifadəsi idi. 5 saniyədə:

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

Disklərin oflayn ölçüsünün dəyişdirilməsi tezliklə bütün bulud provayderlərindən silinəcək bir geri çəkilmə olduğu üçün təcili olaraq müzakirəyə başlamaq və xarici relizatoru yamaq lazım olduğunu hesab etmədik.

İstifadəyə necə başlamaq olar?

Sürücü Kubernetes 1.15 və daha yüksək versiyalarda dəstəklənir. Sürücünün işləməsi üçün aşağıdakı tələblər yerinə yetirilməlidir:

• Bayraq --allow-privileged dəyər təyin edin true API server və kubelet üçün;
• Daxildir --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API server və kubelet üçün;
• Dağların yayılması (dağı yayılması) klasterdə aktivləşdirilməlidir. Docker istifadə edərkən, demon paylaşılan montajlara icazə vermək üçün konfiqurasiya edilməlidir.

Quraşdırmanın özü üçün bütün lazımi addımlar README-də təsvir edilmişdir. Quraşdırma manifestlərdən Kubernetes-də obyektlərin yaradılmasını əhatə edir.

Sürücünün işləməsi üçün sizə aşağıdakılar lazımdır:

• Manifestdə kataloq identifikatorunu göstərin (folder-id) Yandex.Cloud (sənədlərə baxın);
• Yandex.Cloud API ilə qarşılıqlı əlaqə yaratmaq üçün CSI sürücüsü xidmət hesabından istifadə edir. Manifestdə Gizli keçməlidir səlahiyyətli açarlar xidmət hesabından. Sənədlərdə təsvir edilmişdir, xidmət hesabı yaratmaq və açarları necə əldə etmək olar.

Ümumilikdə - cəhd edin, və biz rəy almaqdan şad olarıq və yeni məsələlərhər hansı bir problemlə qarşılaşsanız!

Əlavə dəstək

Nəticə olaraq qeyd etmək istərdik ki, biz bu CSI sürücüsünü Go-da proqramlar yazaraq əylənmək arzusundan deyil, şirkət daxilində təcili ehtiyac olduğu üçün tətbiq etdik. Öz tətbiqimizi davam etdirmək bizim üçün praktik görünmür, buna görə də Yandex maraq göstərsə və sürücünü dəstəkləməyə davam etmək qərarına gəlsə, anbarı onlara ötürməkdən məmnun olarıq.

Bundan əlavə, Yandex çox güman ki, Açıq Mənbədə buraxıla bilən idarə olunan Kubernetes klasterində CSI sürücüsünün öz tətbiqinə malikdir. Biz bu inkişaf variantını da əlverişli hesab edirik - icma üçüncü tərəf şirkətindən deyil, xidmət təminatçısının sübut edilmiş sürücüsündən istifadə edə biləcək.

PS

Bloqumuzda da oxuyun:

• «Kubernetes yaddaşı üçün həcm plaginləri: Flexvolume-dan CSI-ə qədər";
• «Konteyner Saxlama İnterfeysini başa düşürük (Yalnız Kubernetesdə deyil)";
• «Kubernetes klasterini hazırlamaq asan və rahatdırmı? Əlavə operatoru elan edir";
• «Kubernetes-in genişləndirilməsi və əlavə edilməsi (baxış və video hesabat).

Mənbə: www.habr.com