Catatan. terjemahan: Adopsi Kubernetes di GitLab dianggap sebagai salah satu dari dua faktor utama yang berkontribusi terhadap pertumbuhan perusahaan. Namun, hingga saat ini, infrastruktur layanan online GitLab.com dibangun di atas mesin virtual, dan baru sekitar setahun yang lalu migrasi ke K8 dimulai, yang masih belum selesai. Kami dengan senang hati mempersembahkan terjemahan artikel terbaru oleh seorang insinyur GitLab SRE tentang bagaimana hal ini terjadi dan kesimpulan apa yang diambil oleh para insinyur yang berpartisipasi dalam proyek ini.
Selama sekitar satu tahun, divisi infrastruktur kami telah memigrasikan semua layanan yang berjalan di GitLab.com ke Kubernetes. Selama masa ini, kami menghadapi tantangan yang tidak hanya terkait dengan perpindahan layanan ke Kubernetes, tetapi juga dalam mengelola penerapan hybrid selama masa transisi. Pelajaran berharga yang kami peroleh akan dibahas dalam artikel ini.
Sejak awal GitLab.com, servernya berjalan di cloud pada mesin virtual. Mesin virtual ini dikelola oleh Chef dan diinstal menggunakan . jika aplikasi perlu diperbarui, cukup dengan memperbarui armada server secara terkoordinasi dan berurutan menggunakan saluran CI. Metode ini - meskipun lambat dan sedikit - memastikan bahwa GitLab.com menggunakan praktik instalasi dan konfigurasi yang sama seperti pengguna offline (dikelola sendiri) Instalasi GitLab menggunakan paket Linux kami untuk ini.
Kami menggunakan metode ini karena sangat penting untuk mengalami semua kesedihan dan kegembiraan yang dialami oleh anggota komunitas biasa ketika menginstal dan mengkonfigurasi salinan GitLab mereka. Pendekatan ini berhasil dengan baik selama beberapa waktu, namun ketika jumlah proyek di GitLab melebihi 10 juta, kami menyadari bahwa pendekatan ini tidak lagi memenuhi kebutuhan penskalaan dan penerapan kami.
Langkah pertama menuju Kubernetes dan GitLab cloud-native
Proyek ini dibuat pada tahun 2017 untuk mempersiapkan GitLab untuk penerapan cloud, dan untuk memungkinkan pengguna menginstal GitLab di cluster Kubernetes. Kami kemudian mengetahui bahwa memindahkan GitLab ke Kubernetes akan meningkatkan skalabilitas platform SaaS, menyederhanakan penerapan, dan meningkatkan efisiensi sumber daya komputasi. Pada saat yang sama, banyak fungsi aplikasi kita bergantung pada partisi NFS yang terpasang, yang memperlambat transisi dari mesin virtual.
Dorongan menuju cloud native dan Kubernetes memungkinkan teknisi kami merencanakan transisi bertahap, di mana kami mengabaikan beberapa ketergantungan aplikasi pada penyimpanan jaringan sambil terus mengembangkan fitur-fitur baru. Sejak kami mulai merencanakan migrasi pada musim panas tahun 2019, banyak dari keterbatasan ini telah teratasi, dan proses migrasi GitLab.com ke Kubernetes kini berjalan dengan baik!
Fitur GitLab.com di Kubernetes
Untuk GitLab.com, kami menggunakan satu cluster GKE regional yang menangani semua traffic aplikasi. Untuk meminimalkan kompleksitas migrasi (yang sudah rumit), kami fokus pada layanan yang tidak bergantung pada penyimpanan lokal atau NFS. GitLab.com menggunakan basis kode Rails yang didominasi monolitik, dan kami merutekan lalu lintas berdasarkan karakteristik beban kerja ke berbagai titik akhir yang diisolasi ke dalam kumpulan nodenya sendiri.
Dalam kasus frontend, jenis ini dibagi menjadi permintaan ke web, API, Git SSH/HTTPS dan Registry. Dalam kasus backend, kami membagi pekerjaan dalam antrian menurut berbagai karakteristik tergantung pada , yang memungkinkan kami menetapkan Sasaran Tingkat Layanan (SLO) untuk berbagai beban kerja.
Semua layanan GitLab.com ini dikonfigurasi menggunakan bagan GitLab Helm yang tidak dimodifikasi. Konfigurasi dilakukan dalam subbagan, yang dapat diaktifkan secara selektif saat kami memigrasikan layanan ke cluster secara bertahap. Meskipun kami memutuskan untuk tidak menyertakan beberapa layanan stateful kami dalam migrasi, seperti Redis, Postgres, GitLab Pages, dan Gitaly, penggunaan Kubernetes memungkinkan kami mengurangi secara drastis jumlah VM yang saat ini dikelola Chef.
Visibilitas dan Manajemen Konfigurasi Kubernetes
Semua pengaturan dikelola oleh GitLab sendiri. Untuk ini, tiga proyek konfigurasi berdasarkan Terraform dan Helm digunakan. Kami mencoba menggunakan GitLab sendiri bila memungkinkan untuk menjalankan GitLab, tetapi untuk tugas operasional kami memiliki instalasi GitLab terpisah. Hal ini diperlukan untuk memastikan bahwa Anda tidak bergantung pada ketersediaan GitLab.com saat melakukan penerapan dan pembaruan GitLab.com.
Meskipun pipeline kami untuk cluster Kubernetes berjalan pada instalasi GitLab terpisah, terdapat mirror dari repositori kode yang tersedia untuk umum di alamat berikut:
- — Kerangka konfigurasi GitLab.com untuk bagan GitLab Helm;
- - Berisi konfigurasi untuk layanan yang tidak terkait langsung dengan aplikasi GitLab. Ini termasuk konfigurasi untuk logging dan pemantauan cluster, serta alat terintegrasi seperti PlantUML;
- — Konfigurasi Terraform untuk Kubernetes dan infrastruktur VM lama. Di sini Anda mengonfigurasi semua sumber daya yang diperlukan untuk menjalankan klaster, termasuk klaster itu sendiri, kumpulan node, akun layanan, dan reservasi alamat IP.
Tampilan publik ditampilkan ketika perubahan dilakukan. dengan tautan ke perbedaan mendetail yang dianalisis SRE sebelum membuat perubahan pada klaster.
Untuk SRE, tautan tersebut mengarah ke perbedaan mendetail dalam instalasi GitLab, yang digunakan untuk produksi dan aksesnya dibatasi. Hal ini memungkinkan karyawan dan komunitas, tanpa akses ke proyek operasional (yang hanya terbuka untuk SRE), untuk melihat perubahan konfigurasi yang diusulkan. Dengan menggabungkan instance GitLab publik untuk kode dengan instance pribadi untuk pipeline CI, kami mempertahankan satu alur kerja sekaligus memastikan independensi dari GitLab.com untuk pembaruan konfigurasi.
Apa yang kami temukan selama migrasi
Selama perpindahan, diperoleh pengalaman yang kami terapkan pada migrasi dan penerapan baru di Kubernetes.
1. Peningkatan biaya karena lalu lintas antar zona ketersediaan
Statistik keluar harian (byte per hari) untuk armada repositori Git di GitLab.com
Google membagi jaringannya menjadi beberapa wilayah. Zona tersebut, pada gilirannya, dibagi menjadi zona aksesibilitas (AZ). Git hosting dikaitkan dengan data dalam jumlah besar, jadi penting bagi kami untuk mengontrol jalan keluar jaringan. Untuk lalu lintas internal, jalan keluar hanya gratis jika tetap berada dalam zona ketersediaan yang sama. Saat tulisan ini dibuat, kami menyajikan sekitar 100 TB data pada hari kerja biasa (dan itu hanya untuk repositori Git). Layanan yang berada di mesin virtual yang sama dalam topologi berbasis VM lama kami sekarang berjalan di pod Kubernetes yang berbeda. Artinya, beberapa lalu lintas yang sebelumnya bersifat lokal ke VM berpotensi melakukan perjalanan ke luar zona ketersediaan.
Cluster GKE regional memungkinkan Anda menjangkau beberapa Availability Zone untuk redundansi. Kami sedang mempertimbangkan kemungkinan tersebut untuk layanan yang menghasilkan volume lalu lintas yang besar. Hal ini akan mengurangi biaya keluar sekaligus mempertahankan redundansi tingkat klaster.
2. Batasan, permintaan sumber daya, dan penskalaan
Jumlah replika yang memproses lalu lintas produksi di registry.gitlab.com. Lalu lintas mencapai puncaknya pada ~15:00 UTC.
Kisah migrasi kami dimulai pada Agustus 2019, saat kami memigrasikan layanan pertama kami, GitLab Container Registry, ke Kubernetes. Layanan yang sangat penting dan memiliki lalu lintas tinggi ini adalah pilihan yang baik untuk migrasi pertama karena merupakan aplikasi tanpa kewarganegaraan dengan sedikit ketergantungan eksternal. Masalah pertama yang kami temui adalah banyaknya pod yang dikeluarkan karena kurangnya memori pada node. Karena itu, kami harus mengubah permintaan dan batasan.
Ditemukan bahwa dalam kasus aplikasi di mana konsumsi memori meningkat seiring waktu, nilai permintaan yang rendah (memesan memori untuk setiap pod) ditambah dengan batas penggunaan yang “murah hati” menyebabkan kejenuhan (kejenuhan) node dan tingkat penggusuran yang tinggi. Untuk mengatasi masalah ini, sudahlah . Hal ini menghilangkan tekanan pada node dan memastikan pod memiliki siklus hidup yang tidak memberikan terlalu banyak tekanan pada node. Sekarang kita memulai migrasi dengan nilai permintaan dan batas yang banyak (dan hampir sama), menyesuaikannya seperlunya.
3. Metrik dan log
Divisi infrastruktur berfokus pada latensi, tingkat kesalahan, dan saturasi dengan instalasi (SLO) ditautkan ke .
Selama setahun terakhir, salah satu peristiwa penting di divisi infrastruktur adalah peningkatan dalam pemantauan dan kerja sama dengan SLO. SLO memungkinkan kami menetapkan sasaran untuk masing-masing layanan yang kami pantau secara ketat selama migrasi. Namun meski dengan kemampuan observasi yang lebih baik, tidak selalu mungkin untuk segera melihat masalah menggunakan metrik dan peringatan. Misalnya, dengan berfokus pada latensi dan tingkat kesalahan, kami tidak sepenuhnya mencakup semua kasus penggunaan layanan yang sedang bermigrasi.
Masalah ini ditemukan segera setelah memigrasikan beberapa beban kerja ke klaster. Hal ini menjadi sangat akut ketika kami harus memeriksa fungsi yang jumlah permintaannya kecil, tetapi memiliki ketergantungan konfigurasi yang sangat spesifik. Salah satu pembelajaran utama dari migrasi ini adalah perlunya memperhitungkan tidak hanya metrik ketika melakukan pemantauan, namun juga log dan “long tail” (ini tentang pada grafik - kira-kira. terjemahan) kesalahan. Sekarang untuk setiap migrasi kami menyertakan daftar kueri log yang terperinci (catat pertanyaan) dan merencanakan prosedur rollback yang jelas yang dapat dialihkan dari satu shift ke shift berikutnya jika timbul masalah.
Melayani permintaan yang sama secara paralel pada infrastruktur VM lama dan infrastruktur baru berbasis Kubernetes menghadirkan tantangan yang unik. Berbeda dengan migrasi lift-and-shift (transfer cepat aplikasi “sebagaimana adanya” ke infrastruktur baru; detail lebih lanjut dapat dibaca, misalnya, - kira-kira. terjemahkan), pekerjaan paralel pada VM “lama” dan Kubernetes mengharuskan alat pemantauan kompatibel dengan kedua lingkungan dan dapat menggabungkan metrik ke dalam satu tampilan. Penting bagi kita untuk menggunakan dasbor dan kueri log yang sama untuk mencapai observasi yang konsisten selama periode transisi.
4. Mengalihkan lalu lintas ke cluster baru
Untuk GitLab.com, sebagian server didedikasikan untuk . Canary Park melayani proyek internal kami dan juga bisa . Namun hal ini terutama dirancang untuk menguji perubahan yang dilakukan pada infrastruktur dan aplikasi. Layanan migrasi pertama dimulai dengan menerima lalu lintas internal dalam jumlah terbatas, dan kami terus menggunakan metode ini untuk memastikan SLO terpenuhi sebelum mengirimkan semua lalu lintas ke cluster.
Dalam kasus migrasi, ini berarti permintaan ke proyek internal dikirim ke Kubernetes terlebih dahulu, dan kemudian kami secara bertahap mengalihkan sisa lalu lintas ke cluster dengan mengubah bobot backend melalui HAProxy. Selama migrasi dari VM ke Kubernetes, menjadi jelas bahwa sangat bermanfaat untuk memiliki cara mudah untuk mengalihkan lalu lintas antara infrastruktur lama dan baru dan, oleh karena itu, menjaga infrastruktur lama tetap siap untuk dikembalikan dalam beberapa hari pertama setelah migrasi.
5. Cadangan kapasitas pod dan penggunaannya
Masalah berikut segera teridentifikasi: pod untuk layanan Registry dimulai dengan cepat, tetapi peluncuran pod untuk Sidekiq memakan waktu hingga . Waktu startup yang lama untuk pod Sidekiq menjadi masalah ketika kami mulai memigrasikan beban kerja ke Kubernetes untuk pekerja yang perlu memproses pekerjaan dengan cepat dan melakukan penskalaan dengan cepat.
Dalam hal ini, pelajaran yang dapat diambil adalah bahwa meskipun Horizontal Pod Autoscaler (HPA) Kubernetes menangani pertumbuhan lalu lintas dengan baik, penting untuk mempertimbangkan karakteristik beban kerja dan mengalokasikan kapasitas cadangan ke pod (terutama ketika permintaan tidak terdistribusi secara merata). Dalam kasus kami, terjadi lonjakan pekerjaan secara tiba-tiba, yang menyebabkan penskalaan cepat, yang menyebabkan kejenuhan sumber daya CPU sebelum kami sempat menskalakan kumpulan node.
Selalu ada godaan untuk mengeluarkan sebanyak mungkin dari sebuah cluster, namun, setelah awalnya mengalami masalah kinerja, kami sekarang memulai dengan anggaran pod yang besar dan kemudian menguranginya, dengan tetap memperhatikan SLO. Peluncuran pod untuk layanan Sidekiq telah dipercepat secara signifikan dan kini rata-rata membutuhkan waktu sekitar 40 detik. memenangkan GitLab.com dan pengguna instalasi mandiri kami yang bekerja dengan bagan Helm GitLab resmi.
Kesimpulan
Setelah memigrasikan setiap layanan, kami bersukacita atas manfaat penggunaan Kubernetes dalam produksi: penerapan aplikasi yang lebih cepat dan aman, penskalaan, dan alokasi sumber daya yang lebih efisien. Selain itu, keuntungan migrasi lebih dari sekadar layanan GitLab.com. Setiap peningkatan pada grafik Helm resmi akan menguntungkan penggunanya.
Saya harap Anda menikmati kisah petualangan migrasi Kubernetes kami. Kami terus memigrasikan semua layanan baru ke cluster. Informasi tambahan dapat ditemukan di publikasi berikut:
- «»;
- «»;
- .
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com