Qeyd. tərcümə.: GitLab-da Kubernetes-in qəbulu şirkətin böyüməsinə töhfə verən iki əsas amildən biri hesab olunur. Bununla belə, son vaxtlara qədər GitLab.com onlayn xidmətinin infrastrukturu virtual maşınlar üzərində qurulmuşdu və cəmi bir il əvvəl onun K8-lərə miqrasiyasına başlanılıb, bu hələ də tamamlanmayıb. Bunun necə baş verdiyi və layihədə iştirak edən mühəndislərin hansı nəticələrə gəldiyi barədə GitLab SRE mühəndisinin son məqaləsinin tərcüməsini təqdim etməkdən məmnunuq.
Artıq bir ildir ki, infrastruktur bölməmiz GitLab.com-da işləyən bütün xidmətləri Kubernetes-ə köçürür. Bu müddət ərzində biz təkcə xidmətlərin Kubernetes-ə köçürülməsi ilə deyil, həm də keçid zamanı hibrid yerləşdirmənin idarə edilməsi ilə bağlı problemlərlə qarşılaşdıq. Öyrəndiyimiz dəyərli dərslər bu məqalədə müzakirə olunacaq.
GitLab.com-un əvvəlindən onun serverləri virtual maşınlarda buludda işləyirdi. Bu virtual maşınlar Chef tərəfindən idarə olunur və bizim istifadəmizlə quraşdırılır . proqramın yenilənməsi lazım olduğu halda, sadəcə olaraq CI boru kəmərindən istifadə edərək koordinasiyalı, ardıcıl şəkildə server donanmasının yenilənməsindən ibarətdir. Bu üsul - yavaş və bir az da olsa - GitLab.com-un oflayn istifadəçilərlə eyni quraşdırma və konfiqurasiya təcrübələrindən istifadə etməsini təmin edir (özünü idarə edən) Bunun üçün Linux paketlərimizdən istifadə edən GitLab quraşdırmaları.
Biz bu metoddan istifadə edirik, çünki cəmiyyətin adi üzvlərinin GitLab nüsxələrini quraşdırarkən və konfiqurasiya edərkən yaşadıqları bütün kədər və sevincləri yaşamaq son dərəcə vacibdir. Bu yanaşma bir müddət yaxşı işlədi, lakin GitLab-da layihələrin sayı 10 milyonu keçəndə biz başa düşdük ki, o, artıq miqyaslandırma və yerləşdirmə ehtiyaclarımızı ödəmir.
Kubernetes və bulud-doğma GitLab-a ilk addımlar
Layihə 2017-ci ildə yaradılıb bulud yerləşdirilməsi üçün GitLab hazırlamaq və istifadəçilərə GitLab-ı Kubernetes klasterlərində quraşdırmaq imkanı vermək. Biz o zaman bilirdik ki, GitLab-ın Kubernetes-ə köçürülməsi SaaS platformasının miqyasını artıracaq, yerləşdirmələri sadələşdirəcək və hesablama resurslarının səmərəliliyini artıracaq. Eyni zamanda, tətbiqimizin bir çox funksiyası virtual maşınlardan keçidi yavaşlatan quraşdırılmış NFS arakəsmələrindən asılı idi.
Doğma bulud və Kubernetlərə doğru təkan mühəndislərimizə tədricən keçidi planlaşdırmağa imkan verdi, bu müddət ərzində biz yeni funksiyaları inkişaf etdirməyə davam edərkən tətbiqin şəbəkə yaddaşından bəzi asılılıqlarından imtina etdik. 2019-cu ilin yayında miqrasiyanı planlaşdırmağa başladığımızdan bu məhdudiyyətlərin çoxu həll olundu və GitLab.com-un Kubernetes-ə köçürülməsi prosesi indi yaxşı gedir!
Kubernetes-də GitLab.com-un xüsusiyyətləri
GitLab.com üçün biz bütün tətbiq trafikini idarə edən vahid regional GKE klasterindən istifadə edirik. (artıq çətin) miqrasiyanın mürəkkəbliyini minimuma endirmək üçün biz diqqəti yerli yaddaşa və ya NFS-ə etibar etməyən xidmətlərə yönəldirik. GitLab.com əsasən monolit Rails kod bazasından istifadə edir və biz iş yükü xüsusiyyətləri əsasında trafiki öz node hovuzlarına təcrid olunmuş müxtəlif son nöqtələrə yönləndiririk.
Frontend vəziyyətində bu növlər veb, API, Git SSH/HTTPS və Registry sorğularına bölünür. Backend vəziyyətində, növbədəki işləri müxtəlif xüsusiyyətlərə görə bölürük , bu bizə müxtəlif iş yükləri üçün Xidmət Səviyyəsi Məqsədlərini (SLO) təyin etməyə imkan verir.
Bu GitLab.com xidmətlərinin hamısı dəyişdirilməmiş GitLab Helm diaqramından istifadə etməklə konfiqurasiya edilmişdir. Konfiqurasiya, xidmətləri tədricən klasterə köçürdükcə seçimlə aktivləşdirilə bilən alt diaqramlarda həyata keçirilir. Redis, Postgres, GitLab Pages və Gitaly kimi bəzi dövlət xidmətlərimizi miqrasiyaya daxil etməməyi qərara alsaq da, Kubernetes-dən istifadə bizə Chef-in hazırda idarə etdiyi VM-lərin sayını kökündən azaltmağa imkan verir.
Kubernetes Konfiqurasiya Görünüşü və İdarəetmə
Bütün parametrləri GitLab özü idarə edir. Bunun üçün Terraform və Helm əsasında üç konfiqurasiya layihəsindən istifadə olunur. GitLab-ı işə salmaq üçün mümkün olduqda GitLab-ın özündən istifadə etməyə çalışırıq, lakin əməliyyat tapşırıqları üçün ayrıca GitLab quraşdırmamız var. Bu, GitLab.com yerləşdirmələrini və yeniləmələrini həyata keçirərkən GitLab.com-un mövcudluğundan asılı olmamağınızdan əmin olmaq üçün lazımdır.
Kubernetes klasteri üçün boru kəmərlərimiz ayrıca GitLab quraşdırmasında işləsə də, aşağıdakı ünvanlarda ictimaiyyətə açıq olan kod anbarlarının güzgüləri var:
- — GitLab Helm diaqramı üçün GitLab.com konfiqurasiya çərçivəsi;
- - GitLab tətbiqi ilə birbaşa əlaqəli olmayan xidmətlər üçün konfiqurasiyaları ehtiva edir. Bunlara giriş və klaster monitorinqi üçün konfiqurasiyalar, həmçinin PlantUML kimi inteqrasiya edilmiş alətlər daxildir;
- — Kubernetes və köhnə VM infrastrukturu üçün Terraform konfiqurasiyası. Burada siz klasterin özü, qovşaq hovuzları, xidmət hesabları və IP ünvan rezervasiyaları daxil olmaqla, klasteri idarə etmək üçün lazım olan bütün resursları konfiqurasiya edirsiniz.
Dəyişikliklər edildikdə ictimai görünüş göstərilir. klasterə dəyişiklik etməzdən əvvəl SRE-nin təhlil etdiyi təfərrüatlı fərqə keçid ilə.
SRE üçün keçid istehsal üçün istifadə edilən və girişi məhdudlaşdırılan GitLab quraşdırmasında ətraflı fərqə gətirib çıxarır. Bu, işçilərə və icmaya əməliyyat layihəsinə (yalnız SRE-lər üçün açıqdır) girişi olmayan təklif edilən konfiqurasiya dəyişikliklərinə baxmaq imkanı verir. Kod üçün ictimai GitLab instansiyasını CI boru kəmərləri üçün özəl instansiya ilə birləşdirərək, konfiqurasiya yeniləmələri üçün GitLab.com-dan müstəqilliyi təmin etməklə bərabər, vahid iş axını saxlayırıq.
Köç zamanı öyrəndiklərimiz
Köçürmə zamanı Kubernetes-də yeni miqrasiya və yerləşdirmələrə tətbiq etdiyimiz təcrübə əldə edildi.
1. Mövcudluq zonaları arasında trafikə görə artan xərclər
GitLab.com-da Git depo donanması üçün gündəlik çıxış statistikası (gündə bayt)
Google öz şəbəkəsini bölgələrə bölür. Bunlar da öz növbəsində əlçatanlıq zonalarına (AZ) bölünür. Git hosting böyük həcmli məlumatlarla əlaqələndirilir, ona görə də şəbəkə çıxışına nəzarət etmək bizim üçün vacibdir. Daxili trafik üçün çıxış yalnız eyni mövcudluq zonasında qaldıqda pulsuzdur. Bu yazıya görə, biz tipik bir iş günündə təxminən 100 TB məlumat təqdim edirik (və bu, yalnız Git depoları üçündür). Köhnə VM əsaslı topologiyamızda eyni virtual maşınlarda yaşayan xidmətlər indi müxtəlif Kubernetes podlarında işləyir. Bu o deməkdir ki, əvvəllər VM üçün yerli olan bəzi trafik potensial olaraq əlçatanlıq zonalarından kənara çıxa bilər.
Regional GKE klasterləri artıqlıq üçün çoxlu Əlçatımlılıq Zonalarını əhatə etməyə imkan verir. Biz imkanları nəzərdən keçiririk böyük həcmdə trafik yaradan xidmətlər üçün. Bu, klaster səviyyəsində artıqlığı qoruyarkən çıxış xərclərini azaldacaq.
2. Limitlər, resurs sorğuları və miqyası
registry.gitlab.com saytında istehsal trafikini emal edən replikaların sayı. Trafik pik nöqtəsi ~15:00 UTC.
Miqrasiya hekayəmiz 2019-cu ilin avqustunda, ilk xidmətimiz olan GitLab Konteyner Reyestrini Kubernetes-ə köçürdükdə başladı. Bu kritik vəzifəli, yüksək trafikə malik xidmət ilk miqrasiya üçün yaxşı seçim idi, çünki o, az sayda xarici asılılığı olan vətəndaşlığı olmayan proqramdır. Qarşılaşdığımız ilk problem, qovşaqlarda yaddaşın olmaması səbəbindən çox sayda çıxarılan pods idi. Bu səbəbdən sorğu və limitləri dəyişməli olduq.
Yaddaş istehlakının zamanla artdığı bir tətbiq vəziyyətində, istifadə üçün "səxavətli" sərt məhdudiyyətlə birlikdə sorğular üçün aşağı dəyərlər (hər bir pod üçün yaddaş ehtiyatı) doymaya səbəb olduğu aşkar edilmişdir. (doyma) qovşaqlar və yüksək səviyyəli çıxarılma. Bu problemlə məşğul olmaq üçün idi . Bu, qovşaqlardakı təzyiqi götürdü və podların qovşaq üzərində çox təzyiq göstərməyən bir həyat dövrünə sahib olmasını təmin etdi. İndi biz səxavətli (və demək olar ki, eyni) sorğu və limit dəyərləri ilə miqrasiyaya başlayırıq, lazım olduqda onları tənzimləyirik.
3. Metriklər və qeydlər
İnfrastruktur bölməsi gecikmə, səhv dərəcələri və quraşdırılmış doymaya diqqət yetirir (SLO) ilə əlaqələndirilir .
Keçən il ərzində infrastruktur bölməsində əsas hadisələrdən biri SLO-ların monitorinqi və onlarla işin təkmilləşdirilməsi olmuşdur. SLO-lar miqrasiya zamanı yaxından izlədiyimiz fərdi xidmətlər üçün hədəflər qoymağa imkan verdi. Lakin bu təkmilləşdirilmiş müşahidə qabiliyyəti ilə belə, ölçülər və xəbərdarlıqlardan istifadə edərək problemləri dərhal görmək həmişə mümkün olmur. Məsələn, gecikmə və xəta dərəcələrinə diqqət yetirməklə, miqrasiyaya məruz qalan xidmət üçün bütün istifadə hallarını tam əhatə etmirik.
Bu problem bəzi iş yüklərinin klasterə köçürülməsindən dərhal sonra aşkar edildi. Sorğuların sayı az olan, lakin çox spesifik konfiqurasiya asılılığı olan funksiyaları yoxlamalı olduğumuz zaman xüsusilə kəskinləşdi. Miqrasiyadan əldə edilən əsas dərslərdən biri monitorinq zamanı təkcə ölçüləri deyil, həm də qeydləri və “uzun quyruğu” nəzərə almaq zərurəti idi. (bu haqqında diaqramda - təqribən. tərcümə.) səhvlər. İndi hər miqrasiya üçün log sorğularının ətraflı siyahısını daxil edirik (log sorğuları) və problemlər yaranarsa bir növbədən digərinə ötürülə bilən aydın geri qaytarma prosedurlarını planlaşdırın.
Köhnə VM infrastrukturunda və yeni Kubernetes əsaslı infrastrukturda eyni sorğulara paralel olaraq xidmət göstərmək unikal problem təqdim etdi. Lift və sürüşdürmə miqrasiyasından fərqli olaraq (tətbiqlərin “olduğu kimi” yeni infrastruktura sürətli ötürülməsi; daha ətraflı oxumaq olar, məsələn, - təqribən. tərcümə.), “köhnə” VM-lər və Kubernetes üzərində paralel iş monitorinq alətlərinin hər iki mühitə uyğun olmasını və ölçüləri bir görünüşdə birləşdirə bilməsini tələb edir. Keçid dövründə ardıcıl müşahidəyə nail olmaq üçün eyni tablosundan və log sorğularından istifadə etməyimiz vacibdir.
4. Trafikin yeni klasterə keçidi
GitLab.com üçün serverlərin bir hissəsi ona həsr edilmişdir . Canary Park daxili layihələrimizə xidmət edir və edə bilər . Lakin o, ilk növbədə infrastruktura və tətbiqə edilən dəyişiklikləri sınamaq üçün nəzərdə tutulub. İlk köçmüş xidmət məhdud miqdarda daxili trafiki qəbul etməklə başladı və biz bütün trafiki klasterə göndərməzdən əvvəl SLO-ların yerinə yetirilməsini təmin etmək üçün bu metoddan istifadə etməyə davam edirik.
Miqrasiya vəziyyətində, bu o deməkdir ki, daxili layihələrə sorğular əvvəlcə Kubernetes-ə göndərilir və sonra biz HAProxy vasitəsilə backend üçün çəki dəyişdirərək, trafikin qalan hissəsini tədricən klasterə keçirik. VM-dən Kubernetes-ə köçmə zamanı məlum oldu ki, köhnə və yeni infrastruktur arasında trafiki yönləndirməyin asan yoluna sahib olmaq və müvafiq olaraq, köçdən sonrakı ilk bir neçə gündə köhnə infrastrukturu geri qaytarmağa hazır vəziyyətdə saxlamaq çox faydalıdır.
5. Qrupların ehtiyat tutumları və onlardan istifadə
Demək olar ki, dərhal aşağıdakı problem müəyyən edildi: Reyestr xidməti üçün podlar tez başladı, lakin Sidekiq üçün podların işə salınması bir qədər vaxt apardı. . Sidekiq podları üçün uzun işə başlama vaxtı, işləri tez bir zamanda emal etməli və tez bir zamanda miqyas almalı olan işçilər üçün iş yüklərini Kubernetes-ə köçürməyə başladığımız zaman problem oldu.
Bu vəziyyətdə, dərs ondan ibarət idi ki, Kubernetes'in Horizontal Pod Autoscaler (HPA) trafik artımını yaxşı idarə edərkən, iş yüklərinin xüsusiyyətlərini nəzərə almaq və podlara ehtiyat tutum ayırmaq vacibdir (xüsusilə tələb qeyri-bərabər paylandıqda). Bizim vəziyyətimizdə iş yerlərində qəfil artım baş verdi və bu, sürətli miqyaslamaya gətirib çıxardı, bu da qovşaq hovuzunu miqyaslandırmağa vaxtımız olmadıqca CPU resurslarının doymasına səbəb oldu.
Bir çoxluqdan mümkün qədər sıxışdırmaq hər zaman var, lakin ilkin olaraq performans problemi ilə qarşılaşdığımız üçün indi səxavətli pod büdcəsi ilə başlayırıq və SLO-ları diqqətlə izləyərək onu daha sonra azaldırıq. Sidekiq xidməti üçün podların işə salınması əhəmiyyətli dərəcədə sürətlənib və indi orta hesabla təxminən 40 saniyə çəkir. həm GitLab.com, həm də rəsmi GitLab Helm diaqramı ilə işləyən öz-özünə idarə olunan quraşdırma istifadəçilərimizi qazandı.
Nəticə
Hər bir xidməti köçürdükdən sonra istehsalda Kubernetes-dən istifadənin faydalarına sevindik: tətbiqin daha sürətli və təhlükəsiz yerləşdirilməsi, miqyasının artırılması və daha səmərəli resurs bölgüsü. Üstəlik, miqrasiyanın üstünlükləri GitLab.com xidmətindən kənara çıxır. Rəsmi Helm qrafikindəki hər təkmilləşdirmə istifadəçilərinə fayda verir.
Ümid edirəm ki, Kubernetes miqrasiya sərgüzəştlərimizin hekayəsindən zövq aldınız. Biz bütün yeni xidmətləri klasterə köçürməyə davam edirik. Əlavə məlumatı aşağıdakı nəşrlərdə tapa bilərsiniz:
- «";
- «";
- .
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com