Cathetan. nerjemahake.: Adopsi Kubernetes ing GitLab dianggep minangka salah siji saka rong faktor utama sing nyumbang kanggo pertumbuhan perusahaan. Nanging, nganti saiki, infrastruktur layanan online GitLab.com dibangun ing mesin virtual, lan mung setaun kepungkur migrasi menyang K8s diwiwiti, sing isih durung rampung. Kita seneng menehi terjemahan artikel anyar dening insinyur GitLab SRE babagan kedadean iki lan kesimpulan apa sing ditindakake para insinyur sing melu proyek kasebut.
Kira-kira setaun saiki, divisi infrastruktur kita wis migrasi kabeh layanan sing mlaku ing GitLab.com menyang Kubernetes. Sajrone wektu iki, kita nemoni tantangan ora mung kanggo mindhah layanan menyang Kubernetes, nanging uga kanggo ngatur penyebaran hibrida sajrone transisi. Piwulang penting sing kita sinau bakal dirembug ing artikel iki.
Wiwit wiwitan GitLab.com, server kasebut mlaku ing awan ing mesin virtual. Mesin virtual iki dikelola dening Chef lan diinstal nggunakake kita . ing kasus aplikasi perlu dianyari, kasusun saka mung nganyari armada server ing terkoordinasi, proses urut-urutan nggunakake pipo CI. Cara iki - sanajan alon lan sethithik - mesthekake yen GitLab.com nggunakake praktik instalasi lan konfigurasi sing padha karo pangguna offline (ngurus dhewe) Instalasi GitLab nggunakake paket Linux kita kanggo iki.
Kita nggunakake metode iki amarga penting banget kanggo nemu kabeh kasusahan lan kabungahan sing dialami anggota komunitas biasa nalika nginstal lan ngatur salinan GitLab. Pendekatan iki bisa digunakake kanggo sawetara wektu, nanging nalika jumlah proyek ing GitLab ngluwihi 10 yuta, kita nyadari yen ora nyukupi kabutuhan kanggo skala lan penyebaran.
Langkah pisanan menyang Kubernetes lan GitLab asli awan
Proyek kasebut digawe ing 2017 kanggo nyiapake GitLab kanggo panyebaran awan, lan supaya pangguna bisa nginstal GitLab ing kluster Kubernetes. Banjur kita ngerti manawa mindhah GitLab menyang Kubernetes bakal nambah skalabilitas platform SaaS, nyederhanakake panyebaran, lan nambah efisiensi sumber daya komputasi. Ing wektu sing padha, akeh fungsi aplikasi kita gumantung ing partisi NFS sing dipasang, sing nyuda transisi saka mesin virtual.
Dorong menyang native cloud lan Kubernetes ngidini para insinyur kita ngrancang transisi bertahap, nalika kita nilar sawetara dependensi aplikasi ing panyimpenan jaringan nalika terus ngembangake fitur-fitur anyar. Wiwit kita wiwit ngrancang migrasi ing musim panas 2019, akeh watesan kasebut wis dirampungake, lan proses migrasi GitLab.com menyang Kubernetes saiki wis ditindakake!
Fitur GitLab.com ing Kubernetes
Kanggo GitLab.com, kita nggunakake klompok GKE regional siji sing nangani kabeh lalu lintas aplikasi. Kanggo nyilikake kerumitan migrasi (wis angel), kita fokus ing layanan sing ora gumantung ing panyimpenan lokal utawa NFS. GitLab.com nggunakake basis kode Rails sing umume monolitik, lan kita ngarahake lalu lintas adhedhasar karakteristik beban kerja menyang titik pungkasan sing beda-beda sing diisolasi menyang blumbang simpul dhewe.
Ing kasus frontend, jinis iki dipérang dadi panjalukan kanggo web, API, Git SSH/HTTPS lan Registry. Ing kasus backend, kita pamisah proyek ing antrian miturut macem-macem ciri gumantung ing , sing ngidini kita nyetel Sasaran Tingkat Layanan (SLO) kanggo macem-macem beban kerja.
Kabeh layanan GitLab.com iki dikonfigurasi nggunakake bagan GitLab Helm sing ora diowahi. Konfigurasi ditindakake ing subchart, sing bisa diaktifake kanthi selektif nalika kita mindhah layanan menyang kluster. Sanajan kita mutusake ora kalebu sawetara layanan stateful ing migrasi, kayata Redis, Postgres, GitLab Pages lan Gitaly, nggunakake Kubernetes ngidini kita nyuda jumlah VM sing saiki dikelola dening Chef.
Visibilitas lan Manajemen Konfigurasi Kubernetes
Kabeh setelan diatur dening GitLab dhewe. Kanggo iki, telung proyek konfigurasi adhedhasar Terraform lan Helm digunakake. Kita nyoba nggunakake GitLab dhewe nalika bisa mbukak GitLab, nanging kanggo tugas operasional kita duwe instalasi GitLab sing kapisah. Iki dibutuhake kanggo mesthekake yen sampeyan ora gumantung ing kasedhiyan GitLab.com nalika nindakake panyebaran lan nganyari GitLab.com.
Sanajan saluran pipa kanggo kluster Kubernetes mlaku ing instalasi GitLab sing kapisah, ana pangilon saka repositori kode sing kasedhiya kanggo umum ing alamat ing ngisor iki:
- — Kerangka konfigurasi GitLab.com kanggo bagan GitLab Helm;
- - Ngandhut konfigurasi kanggo layanan sing ora langsung digandhengake karo aplikasi GitLab. Iki kalebu konfigurasi kanggo ngawasi logging lan cluster, uga piranti terpadu kaya PlantUML;
- - Konfigurasi Terraform kanggo Kubernetes lan infrastruktur VM warisan. Ing kene sampeyan ngatur kabeh sumber daya sing dibutuhake kanggo mbukak kluster, kalebu kluster kasebut dhewe, blumbang simpul, akun layanan, lan leladen alamat IP.
Tampilan umum ditampilake nalika owah-owahan digawe. kanthi pranala menyang beda rinci sing dianalisis SRE sadurunge nggawe owah-owahan ing kluster.
Kanggo SRE, link kasebut ndadékaké beda rinci ing instalasi GitLab, sing digunakake kanggo produksi lan akses sing diwatesi. Iki ngidini karyawan lan masyarakat, tanpa akses menyang project operasional (sing mung mbukak kanggo SREs), kanggo ndeleng owah-owahan konfigurasi ngajokaken. Kanthi nggabungake conto GitLab umum kanggo kode karo conto pribadi kanggo pipa CI, kita njaga alur kerja siji nalika njamin kamardikan saka GitLab.com kanggo nganyari konfigurasi.
Apa sing ditemokake nalika migrasi
Sajrone pamindhahan, pengalaman dipikolehi sing ditrapake kanggo migrasi lan penyebaran anyar ing Kubernetes.
1. Tambah biaya amarga lalu lintas antarane zona kasedhiyan
Statistik egress saben dina (byte saben dina) kanggo armada gudang Git ing GitLab.com
Google mbagi jaringan dadi wilayah. Sing, ing siji, dipérang dadi zona aksesibilitas (AZ). Git hosting digandhengake karo jumlah data sing akeh, mula penting kanggo ngontrol egress jaringan. Kanggo lalu lintas internal, egress mung gratis yen tetep ing zona kasedhiyan sing padha. Nalika nulis iki, kita nyedhiyakake kira-kira 100 TB data ing dina kerja sing khas (lan mung kanggo repositori Git). Layanan sing manggon ing mesin virtual sing padha ing topologi basis VM lawas saiki mlaku ing pod Kubernetes sing beda. Iki tegese sawetara lalu lintas sing sadurunge lokal menyang VM duweni potensi lelungan ing njaba zona kasedhiyan.
Kluster GKE regional ngidini sampeyan mbentang sawetara Zona Kasedhiyan kanggo redundansi. We are considering kamungkinan kanggo layanan sing ngasilake volume lalu lintas gedhe. Iki bakal nyuda biaya egress nalika njaga redundansi tingkat kluster.
2. Watesan, panjalukan sumber lan skala
Jumlah replika ngolah lalu lintas produksi ing registry.gitlab.com. Puncak lalu lintas ing ~15:00 UTC.
Kisah migrasi kita diwiwiti ing Agustus 2019, nalika kita migrasi layanan pertama kita, GitLab Container Registry, menyang Kubernetes. Layanan kritis lan lalu lintas dhuwur iki minangka pilihan sing apik kanggo migrasi pisanan amarga iki minangka aplikasi tanpa negara kanthi sawetara dependensi eksternal. Masalah pisanan sing ditemoni yaiku akeh polong sing diusir amarga kekurangan memori ing simpul. Amarga iki, kita kudu ngganti panjalukan lan watesan.
Ditemokake manawa ing kasus aplikasi sing konsumsi memori saya mundhak, nilai panjaluk sing sithik (nyetel memori kanggo saben pod) ditambah karo watesan panggunaan sing "murah" nyebabake kejenuhan. (saturasi) node lan tingkat evictions dhuwur. Kanggo menehi hasil karo masalah iki, iku . Iki njupuk tekanan saka kelenjar lan njamin polong duwe siklus urip sing ora menehi tekanan banget ing simpul kasebut. Saiki kita miwiti migrasi kanthi panyuwunan sing loman (lan meh padha) lan mbatesi nilai, nyetel yen perlu.
3. Metrik lan log
Divisi infrastruktur fokus ing latensi, tingkat kesalahan lan jenuh kanthi diinstal (SLO) disambung menyang .
Ing taun kepungkur, salah sawijining acara utama ing divisi infrastruktur yaiku perbaikan ing ngawasi lan nggarap SLO. SLO ngidini kita nyetel gol kanggo layanan individu sing diawasi kanthi rapet sajrone migrasi. Nanging sanajan kanthi observasi sing luwih apik iki, ora mesthi bisa langsung ndeleng masalah nggunakake metrik lan tandha. Contone, kanthi fokus ing latensi lan tingkat kesalahan, kita ora nutupi kabeh kasus panggunaan kanggo layanan sing ngalami migrasi.
Masalah iki ditemokake meh langsung sawise migrasi sawetara beban kerja menyang kluster. Iku dadi utamané leukemia nalika kita kudu mriksa fungsi kang nomer panjalukan cilik, nanging kang duwe dependensi konfigurasi banget tartamtu. Salah sawijining piwulang utama saka migrasi yaiku kudu nggatekake ora mung metrik nalika ngawasi, nanging uga log lan "buntut dawa" (iki babagan ing grafik - kira-kira. transl.) kasalahan. Saiki kanggo saben migrasi kita kalebu dhaptar pitakon log sing rinci (pitakon log) lan rencana prosedur rollback sing jelas sing bisa ditransfer saka siji shift menyang sabanjure yen ana masalah.
Nyedhiyakake panjaluk sing padha kanthi paralel ing infrastruktur VM lawas lan infrastruktur basis Kubernetes anyar menehi tantangan unik. Beda karo migrasi angkat-lan-shift (transfer cepet aplikasi "kaya" menyang infrastruktur anyar; rincian liyane bisa diwaca, contone, - kira-kira. transl.), karya paralel ing VM "lawas" lan Kubernetes mbutuhake alat ngawasi kompatibel karo loro lingkungan lan bisa nggabungake metrik dadi siji tampilan. Penting yen kita nggunakake dashboard lan pitakon log sing padha kanggo entuk observasi konsisten sajrone periode transisi.
4. Ngalih lalu lintas menyang kluster anyar
Kanggo GitLab.com, bagean saka server darmabakti kanggo . Canary Park serves proyèk internal kita lan bisa uga . Nanging utamane dirancang kanggo nguji owah-owahan sing digawe kanggo infrastruktur lan aplikasi. Layanan migrasi pisanan diwiwiti kanthi nampa jumlah lalu lintas internal sing winates, lan kita terus nggunakake cara iki kanggo mesthekake SLO ketemu sadurunge ngirim kabeh lalu lintas menyang kluster.
Ing kasus migrasi, iki tegese panjalukan kanggo proyek internal dikirim menyang Kubernetes dhisik, banjur kita ngalihake lalu lintas liyane menyang kluster kanthi ngganti bobot kanggo backend liwat HAProxy. Sajrone migrasi saka VM menyang Kubernetes, dadi jelas manawa ana cara sing gampang kanggo ngarahake lalu lintas ing antarane infrastruktur lawas lan anyar lan, kanthi mangkono, supaya infrastruktur lawas tetep siyap kanggo muter maneh ing sawetara dina pisanan sawise migrasi.
5. Kapasitas cadangan saka pods lan nggunakake
Meh langsung masalah ing ngisor iki diidentifikasi: pod kanggo layanan Registry diwiwiti kanthi cepet, nanging ngluncurake pod kanggo Sidekiq butuh nganti . Wektu wiwitan sing dawa kanggo pod Sidekiq dadi masalah nalika kita miwiti migrasi beban kerja menyang Kubernetes kanggo para pekerja sing kudu ngolah proyek kanthi cepet lan cepet.
Ing kasus iki, pawulangan yaiku nalika Kubernetes 'Horizontal Pod Autoscaler (HPA) nangani pertumbuhan lalu lintas kanthi apik, penting kanggo nimbang karakteristik beban kerja lan ngalokasikan kapasitas cadangan menyang pods (utamane yen panjaluk disebarake kanthi ora rata). Ing kasus kita, ana mundhak dumadakan ing proyek, anjog kanggo scaling cepet, kang mimpin kanggo jenuh sumber daya CPU sadurunge kita duwe wektu kanggo ukuran blumbang simpul.
Ana tansah nggodha kanggo remet okehe metu saka kluster, Nanging, pisanan nemokke masalah kinerja, kita saiki miwiti karo budget pod loman lan ngurangi mengko, tetep mripat ing SLOs. Bukak pods kanggo layanan Sidekiq wis nyepetake kanthi signifikan lan saiki mbutuhake rata-rata 40 detik. menang loro GitLab.com lan pangguna kita saka panginstalan sing ngatur dhewe sing nggarap bagan Helm GitLab resmi.
kesimpulan
Sawise migrasi saben layanan, kita bungah amarga nggunakake Kubernetes ing produksi: panyebaran aplikasi sing luwih cepet lan luwih aman, skala, lan alokasi sumber daya sing luwih efisien. Kajaba iku, kaluwihan migrasi ngluwihi layanan GitLab.com. Saben perbaikan ing bagan Helm resmi entuk manfaat kanggo pangguna.
Muga-muga sampeyan seneng karo crita petualangan migrasi Kubernetes. Kita terus migrasi kabeh layanan anyar menyang kluster. Informasi tambahan bisa ditemokake ing publikasi ing ngisor iki:
- «";
- «";
- .
PS saka penerjemah
Waca uga ing blog kita:
- «";
- «";
- «";
- «".
Source: www.habr.com