🥇Kesimpulan kami dari tahun penghijrahan GitLab.com ke Kubernetes

Catatan. terjemah: Penerimaan Kubernetes di GitLab dianggap sebagai salah satu daripada dua faktor utama yang menyumbang kepada pertumbuhan syarikat. Walau bagaimanapun, sehingga baru-baru ini, infrastruktur perkhidmatan dalam talian GitLab.com dibina pada mesin maya, dan hanya kira-kira setahun yang lalu penghijrahannya ke K8 bermula, yang masih belum selesai. Kami berbesar hati untuk membentangkan terjemahan artikel terbaru oleh jurutera GitLab SRE tentang cara ini berlaku dan kesimpulan yang dibuat oleh jurutera yang mengambil bahagian dalam projek itu.

Selama kira-kira setahun sekarang, bahagian infrastruktur kami telah memindahkan semua perkhidmatan yang dijalankan di GitLab.com kepada Kubernetes. Pada masa ini, kami menghadapi cabaran yang berkaitan bukan sahaja untuk mengalihkan perkhidmatan ke Kubernetes, tetapi juga untuk menguruskan penggunaan hibrid semasa peralihan. Pengajaran berharga yang kami pelajari akan dibincangkan dalam artikel ini.

Sejak awal GitLab.com, pelayannya berjalan di awan pada mesin maya. Mesin maya ini diuruskan oleh Chef dan dipasang menggunakan kami pakej rasmi Linux. Strategi penyebaran sekiranya aplikasi perlu dikemas kini, hanya terdiri daripada mengemas kini armada pelayan secara berurutan yang diselaraskan menggunakan saluran paip CI. Kaedah ini - walaupun perlahan dan sedikit membosankan - memastikan bahawa GitLab.com menggunakan pemasangan dan amalan konfigurasi yang sama seperti pengguna luar talian (urus sendiri) Pemasangan GitLab menggunakan pakej Linux kami untuk ini.

Kami menggunakan kaedah ini kerana adalah sangat penting untuk mengalami semua kesedihan dan kegembiraan yang dialami oleh ahli komuniti biasa apabila memasang dan mengkonfigurasi salinan GitLab mereka. Pendekatan ini berfungsi dengan baik untuk beberapa waktu, tetapi apabila bilangan projek pada GitLab melebihi 10 juta, kami menyedari bahawa ia tidak lagi memenuhi keperluan kami untuk penskalaan dan penggunaan.

Langkah pertama untuk Kubernetes dan GitLab asli awan

Projek itu dibuat pada tahun 2017 Carta GitLab untuk menyediakan GitLab untuk penggunaan awan, dan untuk membolehkan pengguna memasang GitLab pada kelompok Kubernetes. Kami tahu bahawa memindahkan GitLab ke Kubernetes akan meningkatkan kebolehskalaan platform SaaS, memudahkan penggunaan dan meningkatkan kecekapan sumber pengkomputeran. Pada masa yang sama, banyak fungsi aplikasi kami bergantung pada partition NFS yang dipasang, yang memperlahankan peralihan daripada mesin maya.

Dorongan ke arah asli awan dan Kubernetes membenarkan jurutera kami merancang peralihan beransur-ansur, di mana kami meninggalkan beberapa kebergantungan aplikasi pada storan rangkaian sambil terus membangunkan ciri baharu. Sejak kami mula merancang penghijrahan pada musim panas 2019, banyak pengehadan ini telah diselesaikan dan proses pemindahan GitLab.com ke Kubernetes kini sedang berjalan dengan lancar!

Ciri-ciri GitLab.com dalam Kubernetes

Untuk GitLab.com, kami menggunakan gugusan GKE serantau tunggal yang mengendalikan semua trafik aplikasi. Untuk meminimumkan kerumitan penghijrahan (sudah rumit), kami menumpukan pada perkhidmatan yang tidak bergantung pada storan tempatan atau NFS. GitLab.com menggunakan asas kod Rails yang kebanyakannya monolitik, dan kami menghalakan trafik berdasarkan ciri beban kerja ke titik akhir yang berbeza yang diasingkan ke dalam kumpulan nod mereka sendiri.

Dalam kes bahagian hadapan, jenis ini dibahagikan kepada permintaan ke web, API, Git SSH/HTTPS dan Pendaftaran. Dalam kes bahagian belakang, kami membahagikan kerja dalam baris gilir mengikut pelbagai ciri bergantung pada sempadan sumber yang telah ditetapkan, yang membolehkan kami menetapkan Objektif Tahap Perkhidmatan (SLO) untuk pelbagai beban kerja.

Semua perkhidmatan GitLab.com ini dikonfigurasikan menggunakan carta Helm GitLab yang tidak diubah suai. Konfigurasi dijalankan dalam subcarta, yang boleh didayakan secara terpilih semasa kami memindahkan perkhidmatan secara beransur-ansur ke kluster. Walaupun kami memutuskan untuk tidak memasukkan beberapa perkhidmatan stateful kami dalam penghijrahan, seperti Redis, Postgres, GitLab Pages dan Gitaly, menggunakan Kubernetes membolehkan kami mengurangkan secara radikal bilangan VM yang sedang diuruskan oleh Chef.

Keterlihatan dan Pengurusan Konfigurasi Kubernetes

Semua tetapan diuruskan oleh GitLab sendiri. Untuk ini, tiga projek konfigurasi berdasarkan Terraform dan Helm digunakan. Kami cuba menggunakan GitLab sendiri apabila mungkin untuk menjalankan GitLab, tetapi untuk tugas operasi kami mempunyai pemasangan GitLab yang berasingan. Ini diperlukan untuk memastikan bahawa anda tidak bergantung pada ketersediaan GitLab.com semasa melakukan penempatan dan kemas kini GitLab.com.

Walaupun saluran paip kami untuk kluster Kubernetes dijalankan pada pemasangan GitLab yang berasingan, terdapat cermin repositori kod yang tersedia secara umum di alamat berikut:

k8s-workloads/gitlab-com — Rangka kerja konfigurasi GitLab.com untuk carta Helm GitLab;
k8s-beban kerja/gitlab-helmfiles - Mengandungi konfigurasi untuk perkhidmatan yang tidak dikaitkan secara langsung dengan aplikasi GitLab. Ini termasuk konfigurasi untuk pengelogan dan pemantauan kelompok, serta alat bersepadu seperti PlantUML;
Gitlab-com-infrastruktur — Konfigurasi Terraform untuk Kubernetes dan infrastruktur VM lama. Di sini anda mengkonfigurasi semua sumber yang diperlukan untuk menjalankan kluster, termasuk kluster itu sendiri, kumpulan nod, akaun perkhidmatan dan tempahan alamat IP.

Pandangan umum ditunjukkan apabila perubahan dibuat. ringkasan pendek dengan pautan ke perbezaan terperinci yang dianalisis oleh SRE sebelum membuat perubahan pada kelompok.

Untuk SRE, pautan membawa kepada perbezaan terperinci dalam pemasangan GitLab, yang digunakan untuk pengeluaran dan akses yang terhad. Ini membolehkan pekerja dan komuniti, tanpa akses kepada projek operasi (yang hanya terbuka kepada SRE), untuk melihat perubahan konfigurasi yang dicadangkan. Dengan menggabungkan contoh GitLab awam untuk kod dengan contoh peribadi untuk saluran paip CI, kami mengekalkan satu aliran kerja sambil memastikan kebebasan daripada GitLab.com untuk kemas kini konfigurasi.

Apa yang kami dapati semasa hijrah

Semasa pemindahan, pengalaman diperoleh yang kami gunakan untuk migrasi dan penempatan baharu dalam Kubernetes.

1. Peningkatan kos disebabkan oleh trafik antara zon ketersediaan

Statistik keluar harian (bait sehari) untuk kumpulan repositori Git di GitLab.com

Google membahagikan rangkaiannya kepada wilayah. Mereka, seterusnya, dibahagikan kepada zon kebolehaksesan (AZ). Pengehosan Git dikaitkan dengan jumlah data yang besar, jadi penting bagi kami untuk mengawal laluan keluar rangkaian. Untuk trafik dalaman, jalan keluar hanya percuma jika ia kekal dalam zon ketersediaan yang sama. Setakat penulisan ini, kami menyediakan kira-kira 100 TB data dalam hari kerja biasa (dan itu hanya untuk repositori Git). Perkhidmatan yang berada dalam mesin maya yang sama dalam topologi berasaskan VM lama kami kini dijalankan dalam pod Kubernetes yang berbeza. Ini bermakna bahawa sesetengah trafik yang sebelum ini adalah setempat kepada VM berpotensi bergerak di luar zon ketersediaan.

Kelompok GKE serantau membolehkan anda menjangkau berbilang Zon Ketersediaan untuk lebihan. Kami sedang mempertimbangkan kemungkinan pecahkan gugusan GKE serantau kepada gugusan zon tunggal untuk perkhidmatan yang menjana jumlah trafik yang besar. Ini akan mengurangkan kos keluar sambil mengekalkan redundansi peringkat kelompok.

2. Had, permintaan sumber dan penskalaan

Bilangan replika yang memproses trafik pengeluaran di registry.gitlab.com. Trafik memuncak pada ~15:00 UTC.

Kisah migrasi kami bermula pada Ogos 2019, apabila kami memindahkan perkhidmatan pertama kami, Pendaftaran Kontena GitLab, ke Kubernetes. Perkhidmatan dengan trafik tinggi yang kritikal misi ini merupakan pilihan yang baik untuk penghijrahan pertama kerana ia merupakan aplikasi tanpa kewarganegaraan dengan sedikit kebergantungan luar. Masalah pertama yang kami hadapi ialah sejumlah besar pod yang diusir kerana kekurangan memori pada nod. Disebabkan ini, kami terpaksa menukar permintaan dan had.

Telah didapati bahawa dalam kes aplikasi di mana penggunaan memori meningkat dari semasa ke semasa, nilai yang rendah untuk permintaan (menyimpan memori untuk setiap pod) ditambah dengan had keras "murah hati" pada penggunaan membawa kepada ketepuan (ketepuan) nod dan tahap pengusiran yang tinggi. Untuk menangani masalah ini, ia adalah ia telah memutuskan untuk meningkatkan permintaan dan had yang lebih rendah. Ini menghilangkan tekanan daripada nod dan memastikan pod mempunyai kitaran hayat yang tidak memberi tekanan terlalu banyak pada nod. Kini kami memulakan migrasi dengan permintaan dan nilai had yang murah hati (dan hampir sama), melaraskannya mengikut keperluan.

3. Metrik dan log

Bahagian infrastruktur memfokuskan pada kependaman, kadar ralat dan ketepuan dengan dipasang matlamat tahap perkhidmatan (SLO) dipautkan kepada ketersediaan umum sistem kami.

Sepanjang tahun lalu, salah satu peristiwa penting dalam bahagian infrastruktur ialah penambahbaikan dalam pemantauan dan bekerjasama dengan SLO. SLO membenarkan kami menetapkan matlamat untuk perkhidmatan individu yang kami pantau rapi semasa penghijrahan. Tetapi walaupun dengan kebolehmerhatian yang dipertingkatkan ini, tidak selalu mungkin untuk melihat masalah dengan segera menggunakan metrik dan makluman. Contohnya, dengan memfokuskan pada kependaman dan kadar ralat, kami tidak meliputi sepenuhnya semua kes penggunaan untuk perkhidmatan yang mengalami pemindahan.

Isu ini ditemui hampir serta-merta selepas memindahkan beberapa beban kerja ke kluster. Ia menjadi sangat teruk apabila kami perlu menyemak fungsi yang bilangan permintaannya kecil, tetapi yang mempunyai kebergantungan konfigurasi yang sangat spesifik. Salah satu pengajaran utama daripada penghijrahan ialah keperluan untuk mengambil kira bukan sahaja metrik semasa memantau, tetapi juga log dan "ekor panjang" (ini kira-kira sedemikian pengedaran mereka pada carta - lebih kurang. terjemah.) kesilapan. Sekarang untuk setiap migrasi kami menyertakan senarai pertanyaan log yang terperinci (pertanyaan log) dan rancang prosedur rollback yang jelas yang boleh dipindahkan dari satu syif ke seterusnya jika masalah timbul.

Melayan permintaan yang sama secara selari pada infrastruktur VM lama dan infrastruktur berasaskan Kubernetes baharu memberikan cabaran yang unik. Tidak seperti migrasi angkat-dan-anjakan (pemindahan pantas aplikasi "seadanya" kepada infrastruktur baharu; butiran lanjut boleh dibaca, contohnya, di sini - lebih kurang terjemah.), kerja selari pada VM "lama" dan Kubernetes memerlukan alat pemantauan serasi dengan kedua-dua persekitaran dan dapat menggabungkan metrik ke dalam satu paparan. Adalah penting untuk kami menggunakan papan pemuka dan pertanyaan log yang sama untuk mencapai pemerhatian yang konsisten semasa tempoh peralihan.

4. Menukar trafik kepada kluster baharu

Untuk GitLab.com, sebahagian daripada pelayan didedikasikan untuk peringkat kenari. Canary Park menyediakan projek dalaman kami dan boleh juga didayakan oleh pengguna. Tetapi ia direka terutamanya untuk menguji perubahan yang dibuat pada infrastruktur dan aplikasi. Perkhidmatan berhijrah pertama bermula dengan menerima jumlah trafik dalaman yang terhad, dan kami terus menggunakan kaedah ini untuk memastikan SLO dipenuhi sebelum menghantar semua trafik ke kluster.

Dalam kes penghijrahan, ini bermakna permintaan kepada projek dalaman dihantar kepada Kubernetes terlebih dahulu, dan kemudian kami menukar trafik yang selebihnya kepada kluster secara beransur-ansur dengan menukar berat untuk bahagian belakang melalui HAProxy. Semasa penghijrahan daripada VM ke Kubernetes, menjadi jelas bahawa adalah sangat berfaedah untuk mempunyai cara mudah untuk mengubah hala trafik antara infrastruktur lama dan baharu dan, sewajarnya, memastikan infrastruktur lama sedia untuk ditarik balik dalam beberapa hari pertama selepas penghijrahan.

5. Simpan kapasiti buah dan penggunaannya

Hampir serta-merta masalah berikut dikenal pasti: pod untuk perkhidmatan Pendaftaran bermula dengan cepat, tetapi pelancaran pod untuk Sidekiq mengambil masa sehingga dua minit. Masa permulaan yang panjang untuk pod Sidekiq menjadi isu apabila kami mula memindahkan beban kerja ke Kubernetes untuk pekerja yang perlu memproses kerja dengan cepat dan skala dengan cepat.

Dalam kes ini, pengajarannya ialah walaupun Kubernetes' Horizontal Pod Autoscaler (HPA) mengendalikan pertumbuhan trafik dengan baik, adalah penting untuk mempertimbangkan ciri-ciri beban kerja dan memperuntukkan kapasiti ganti kepada pod (terutamanya apabila permintaan diagihkan secara tidak sekata). Dalam kes kami, terdapat lonjakan mendadak dalam pekerjaan, yang membawa kepada penskalaan pantas, yang membawa kepada ketepuan sumber CPU sebelum kami mempunyai masa untuk menskala kumpulan nod.

Sentiasa ada godaan untuk memerah sebanyak mungkin keluar dari kluster, namun, setelah pada mulanya menghadapi masalah prestasi, kami kini bermula dengan bajet pod yang besar dan mengurangkannya kemudian, memerhatikan SLO dengan teliti. Pelancaran pod untuk perkhidmatan Sidekiq telah dipercepatkan dengan ketara dan kini mengambil masa kira-kira 40 saat secara purata. Daripada mengurangkan masa pelancaran pod memenangi kedua-dua GitLab.com dan pengguna kami bagi pemasangan terurus sendiri yang bekerja dengan carta Helm GitLab rasmi.

Kesimpulan

Selepas memindahkan setiap perkhidmatan, kami bergembira dengan faedah menggunakan Kubernetes dalam pengeluaran: penggunaan aplikasi yang lebih pantas dan selamat, penskalaan dan peruntukan sumber yang lebih cekap. Selain itu, kelebihan migrasi melangkaui perkhidmatan GitLab.com. Setiap peningkatan pada carta Helm rasmi memberi manfaat kepada penggunanya.

Saya harap anda menikmati kisah pengembaraan migrasi Kubernetes kami. Kami terus memindahkan semua perkhidmatan baharu ke kluster. Maklumat tambahan boleh didapati dalam penerbitan berikut:

Penemuan kami dari setahun memindahkan GitLab.com ke Kubernetes