Selama bertahun-tahun, 300 juta pengguna Pinterest telah menciptakan lebih dari 200 miliar pin di lebih dari 4 miliar papan. Untuk melayani banyak pengguna dan basis konten yang luas, portal ini telah mengembangkan ribuan layanan, mulai dari layanan mikro yang dapat ditangani oleh beberapa CPU, hingga monolit raksasa yang berjalan di seluruh armada mesin virtual. Dan tibalah saatnya ketika mata perusahaan tertuju pada k8. Mengapa βkubusβ terlihat bagus di Pinterest? Anda akan mempelajarinya dari terjemahan artikel terbaru kami dari .
Jadi, ratusan juta pengguna dan ratusan miliar pin. Untuk melayani sejumlah besar pengguna dan basis konten yang luas, kami telah mengembangkan ribuan layanan, mulai dari layanan mikro yang dapat ditangani oleh beberapa CPU, hingga monolit raksasa yang berjalan di seluruh armada mesin virtual. Selain itu, kami memiliki beragam kerangka kerja yang mungkin juga memerlukan akses CPU, memori, atau I/O.
Dalam memelihara kumpulan alat ini, tim pengembangan menghadapi sejumlah tantangan:
- Tidak ada cara yang seragam bagi para insinyur untuk menjalankan lingkungan produksi. Layanan tanpa kewarganegaraan, layanan Stateful, dan proyek yang sedang dikembangkan secara aktif didasarkan pada rangkaian teknologi yang sangat berbeda. Hal ini menyebabkan terciptanya kursus pelatihan menyeluruh bagi para insinyur, dan juga sangat mempersulit pekerjaan tim infrastruktur kami.
- Pengembang yang memiliki armada mesin virtualnya sendiri menimbulkan beban besar bagi administrator internal. Akibatnya, operasi sederhana seperti memperbarui OS atau AMI membutuhkan waktu berminggu-minggu dan berbulan-bulan. Hal ini menyebabkan peningkatan beban kerja dalam situasi sehari-hari.
- Kesulitan dalam menciptakan alat manajemen infrastruktur global selain solusi yang ada. Situasi ini semakin diperumit oleh kenyataan bahwa menemukan pemilik mesin virtual tidaklah mudah. Artinya, kami tidak mengetahui apakah kapasitas ini dapat diekstraksi dengan aman untuk dioperasikan di bagian lain dari infrastruktur kami.
Sistem orkestrasi kontainer adalah cara untuk menyatukan manajemen beban kerja. Hal ini membuka pintu bagi peningkatan kecepatan pembangunan dan penyederhanaan pengelolaan infrastruktur, karena semua sumber daya yang terlibat dalam proyek dikelola oleh satu sistem terpusat.
Gambar 1: Prioritas infrastruktur (keandalan, produktivitas pengembang, dan efisiensi).
Tim Cloud Management Platform di Pinterest menemukan K8 pada tahun 2017. Pada paruh pertama tahun 2017, kami telah mendokumentasikan sebagian besar kemampuan produksi kami, termasuk API dan semua server web kami. Setelah itu, kami melakukan penilaian menyeluruh terhadap berbagai sistem untuk mengatur solusi container, membangun cluster, dan bekerja dengannya. Menjelang akhir tahun 2017, kami memutuskan untuk menggunakan Kubernetes. Itu cukup fleksibel dan didukung secara luas di komunitas pengembang.
Hingga saat ini, kami telah membangun alat boot cluster kami sendiri berdasarkan Kops dan memigrasikan komponen infrastruktur yang ada seperti jaringan, keamanan, metrik, logging, manajemen identitas, dan lalu lintas ke Kubernetes. Kami juga menerapkan sistem pemodelan beban kerja untuk sumber daya kami, yang kompleksitasnya disembunyikan dari pengembang. Sekarang kami fokus untuk memastikan stabilitas cluster, menskalakannya, dan menghubungkan klien baru.
Kubernetes: Cara Pinterest
Memulai Kubernetes pada skala Pinterest sebagai platform yang disukai para teknisi kami memiliki banyak tantangan.
Sebagai perusahaan besar, kami telah banyak berinvestasi pada peralatan infrastruktur. Contohnya mencakup alat keamanan yang menangani pemrosesan sertifikat dan distribusi kunci, komponen kontrol lalu lintas, sistem penemuan layanan, komponen visibilitas, serta komponen pengiriman log dan metrik. Semua ini dikumpulkan karena suatu alasan: kami melalui jalur coba-coba yang normal, dan oleh karena itu kami ingin mengintegrasikan semua peralatan ini ke dalam infrastruktur baru di Kubernetes daripada menciptakan kembali roda lama di platform baru. Pendekatan ini secara keseluruhan menyederhanakan migrasi, karena semua dukungan aplikasi sudah ada dan tidak perlu dibuat dari awal.
Di sisi lain, model perkiraan beban di Kubernetes itu sendiri (seperti penerapan, pekerjaan, dan set Daemon) tidak cukup untuk proyek kami. Masalah kegunaan ini merupakan hambatan besar untuk berpindah ke Kubernetes. Misalnya, kami mendengar pengembang layanan mengeluh tentang pengaturan login yang hilang atau salah. Kami juga mengalami kesalahan penggunaan mesin template, ketika ratusan salinan dibuat dengan spesifikasi dan tugas yang sama, yang mengakibatkan masalah debugging yang buruk.
Juga sangat sulit untuk mempertahankan versi yang berbeda dalam cluster yang sama. Bayangkan kerumitan dukungan pelanggan jika Anda perlu bekerja secara bersamaan di beberapa versi lingkungan runtime yang sama, dengan segala masalah, bug, dan pembaruannya.
Properti dan Pengontrol Pengguna Pinterest
Untuk memudahkan teknisi kami dalam mengimplementasikan Kubernetes, serta menyederhanakan dan mempercepat infrastruktur kami, kami telah mengembangkan definisi sumber daya khusus (CRD) kami sendiri.
CRD menyediakan fungsionalitas berikut:
- Menggabungkan berbagai sumber daya asli Kubernetes sehingga berfungsi sebagai satu beban kerja. Misalnya, sumber daya PinterestService mencakup penerapan, layanan login, dan peta konfigurasi. Hal ini memungkinkan pengembang tidak perlu khawatir tentang pengaturan DNS.
- Menerapkan dukungan aplikasi yang diperlukan. Pengguna hanya perlu fokus pada spesifikasi container sesuai dengan logika bisnisnya, sementara pengontrol CRD mengimplementasikan semua container init, variabel lingkungan, dan spesifikasi pod yang diperlukan. Hal ini memberikan tingkat kenyamanan yang berbeda secara mendasar bagi pengembang.
- Pengontrol CRD juga mengelola siklus hidup sumber daya asli dan meningkatkan ketersediaan debug. Hal ini termasuk merekonsiliasi spesifikasi yang diinginkan dan aktual, memperbarui status CRD dan memelihara log peristiwa, dan banyak lagi. Tanpa CRD, pengembang akan terpaksa mengelola banyak sumber daya, yang hanya akan meningkatkan kemungkinan kesalahan.
Berikut ini contoh Layanan Pinterest dan sumber daya internal yang dikelola oleh pengontrol kami:
Seperti yang Anda lihat di atas, untuk mendukung container khusus kita perlu mengintegrasikan container init dan beberapa add-on untuk memberikan keamanan, visibilitas, dan lalu lintas jaringan. Selain itu, kami membuat templat peta konfigurasi dan menerapkan dukungan untuk templat PVC untuk pekerjaan batch, serta pelacakan beberapa variabel lingkungan untuk melacak identitas, konsumsi sumber daya, dan pengumpulan sampah.
Sulit membayangkan pengembang ingin menulis file konfigurasi ini dengan tangan tanpa dukungan CRD, apalagi memelihara dan men-debug konfigurasi lebih lanjut.
Alur kerja penerapan aplikasi
Gambar di atas menunjukkan cara men-deploy sumber daya kustom Pinterest ke cluster Kubernetes:
- Pengembang berinteraksi dengan cluster Kubernetes kami melalui CLI dan antarmuka pengguna.
- Alat CLI/UI mengambil file YAML konfigurasi alur kerja dan properti build lainnya (ID versi yang sama) dari Artifactory lalu mengirimkannya ke Layanan Pengiriman Pekerjaan. Langkah ini memastikan bahwa hanya versi produksi yang dikirimkan ke klaster.
- JSS merupakan pintu gerbang untuk berbagai platform, termasuk Kubernetes. Di sini pengguna diautentikasi, kuota dikeluarkan dan konfigurasi CRD kami diperiksa sebagian.
- Setelah memeriksa CRD di sisi JSS, informasi dikirim ke API platform k8s.
- Pengontrol CRD kami memantau peristiwa di semua sumber daya pengguna. Ini mengubah CR menjadi sumber daya k8 asli, menambahkan modul yang diperlukan, menetapkan variabel lingkungan yang sesuai, dan melakukan pekerjaan dukungan lainnya untuk memastikan aplikasi pengguna dalam container memiliki dukungan infrastruktur yang memadai.
- Pengontrol CRD kemudian meneruskan data yang diterima ke API Kubernetes sehingga dapat diproses oleh penjadwal dan dimasukkan ke dalam produksi.
Catatan: Alur kerja penerapan pra-rilis ini dibuat untuk pengguna pertama platform k8s baru. Kami sedang dalam proses menyempurnakan proses ini agar dapat terintegrasi sepenuhnya dengan CI/CD baru kami. Artinya kami tidak dapat memberi tahu Anda segala sesuatu yang berhubungan dengan Kubernetes. Kami berharap dapat berbagi pengalaman kami dan kemajuan tim dalam arah ini dalam postingan blog kami berikutnya, βMembangun platform CI/CD untuk Pinterest.β
Jenis sumber daya khusus
Berdasarkan kebutuhan spesifik Pinterest, kami telah mengembangkan CRD berikut untuk menyesuaikan dengan alur kerja yang berbeda:
- PinterestService adalah layanan tanpa kewarganegaraan yang telah berjalan sejak lama. Banyak dari sistem inti kami didasarkan pada serangkaian layanan tersebut.
- PinterestJobSet memodelkan pekerjaan batch siklus penuh. Skenario umum di Pinterest adalah beberapa pekerjaan menjalankan kontainer yang sama secara paralel, terlepas dari proses serupa lainnya.
- PinterestCronJob banyak digunakan bersamaan dengan beban periodik kecil. Ini adalah pembungkus untuk cron asli yang berfungsi dengan mekanisme dukungan Pinterest yang bertanggung jawab atas keamanan, lalu lintas, log, dan metrik.
- PinterestDaemon menyertakan Daemon infrastruktur. Keluarga ini terus berkembang seiring kami menambahkan lebih banyak dukungan ke klaster kami.
- PinterestTrainingJob meluas ke proses Tensorflow dan Pytorch, memberikan tingkat dukungan runtime yang sama seperti semua CRD lainnya. Karena Pinterest secara aktif menggunakan Tensorflow dan sistem pembelajaran mesin lainnya, kami punya alasan untuk membuat CRD terpisah di sekitarnya.
Kami juga sedang mengerjakan PinterestStatefulSet, yang akan segera diadaptasi untuk gudang data dan sistem stateful lainnya.
Dukungan waktu proses
Saat pod aplikasi berjalan di Kubernetes, pod aplikasi secara otomatis menerima sertifikat untuk mengidentifikasi dirinya. Sertifikat ini digunakan untuk mengakses penyimpanan rahasia atau untuk berkomunikasi dengan layanan lain melalui mTLS. Sementara itu, Konfigurator Init Kontainer dan Daemon akan mengunduh semua dependensi yang diperlukan sebelum menjalankan aplikasi dalam container. Ketika semuanya sudah siap, sidecar lalu lintas dan Daemon akan mendaftarkan alamat IP modul ke Zookeeper kami sehingga klien dapat menemukannya. Semua ini akan berfungsi karena modul jaringan telah dikonfigurasi sebelum aplikasi diluncurkan.
Di atas adalah contoh umum dukungan runtime untuk beban kerja. Jenis beban kerja lainnya mungkin memerlukan dukungan yang sedikit berbeda, namun semuanya hadir dalam bentuk sidecar tingkat pod, Daemon tingkat node, atau tingkat mesin virtual. Kami memastikan bahwa semua ini diterapkan dalam infrastruktur manajemen dan konsisten di seluruh aplikasi, yang pada akhirnya secara signifikan mengurangi beban dalam hal pekerjaan teknis dan dukungan pelanggan.
Pengujian dan QA
Kami membangun pipeline pengujian end-to-end di atas infrastruktur pengujian Kubernetes yang ada. Pengujian ini berlaku untuk semua cluster kami. Saluran pipa kami mengalami banyak revisi sebelum menjadi bagian dari cluster produk.
Selain sistem pengujian, kami memiliki sistem pemantauan dan peringatan yang terus-menerus memantau status komponen sistem, konsumsi sumber daya, dan indikator penting lainnya, memberi tahu kami hanya jika diperlukan intervensi manusia.
Alternatif
Kami melihat beberapa alternatif terhadap sumber daya khusus, seperti pengontrol akses mutasi dan sistem templat. Namun, semuanya memiliki tantangan operasional yang signifikan, sehingga kami memilih rute CRD.
Pengontrol penerimaan mutasi digunakan untuk memperkenalkan sidecar, variabel lingkungan, dan dukungan runtime lainnya. Namun, ia menghadapi berbagai masalah, seperti pengikatan sumber daya dan manajemen siklus hidup, dimana masalah tersebut tidak muncul di CRD.
Catatan: Sistem template seperti grafik Helm juga banyak digunakan untuk menjalankan aplikasi dengan konfigurasi serupa. Namun, aplikasi kerja kita terlalu beragam untuk dikelola menggunakan templat. Juga selama penerapan berkelanjutan akan terjadi terlalu banyak kesalahan saat menggunakan templat.
Pekerjaan yang akan datang
Saat ini kami sedang menghadapi beban campuran di semua cluster kami. Untuk mendukung berbagai jenis dan ukuran proses tersebut, kami bekerja di bidang berikut:
- Kumpulan cluster mendistribusikan aplikasi besar ke berbagai cluster berbeda untuk skalabilitas dan stabilitas.
- Memastikan stabilitas, skalabilitas, dan visibilitas cluster untuk menciptakan konektivitas aplikasi dan SLA.
- Mengelola sumber daya dan kuota sehingga aplikasi tidak saling bertentangan, dan skala cluster dikendalikan oleh kami.
- Platform CI/CD baru untuk mendukung dan menerapkan aplikasi di Kubernetes.
Sumber: www.habr.com