Kisah ini adalah tentang bagaimana kita menggunakan wadah di lingkungan grosir, terutama di bawah Kubernetes. Artikel ini dikhususkan untuk koleksi metrik dan log dari wadah, serta kumpulan gambar.

gambar

Kami berasal dari perusahaan fintech, Exness, yang mengembangkan layanan untuk perdagangan online dan produk fintech untuk B2B dan B2C. Ada banyak tim berbeda di R&D kami, di departemen pengembangan 100+ karyawan.

Kami mewakili tim yang bertanggung jawab atas platform untuk mengumpulkan dan menjalankan kode oleh pengembang kami. Secara khusus, kami bertanggung jawab untuk mengumpulkan, menyimpan, dan menyediakan metrik, log, dan acara dari aplikasi. Saat ini, kami mengoperasikan sekitar tiga ribu kontainer Docker di lingkungan produk, mendukung penyimpanan data besar 50 TB kami dan memberikan solusi arsitektur yang dibangun di sekitar infrastruktur kami: Kubernetes, Rancher, dan berbagai penyedia cloud publik.

Motivasi kita

Apa yang terbakar? Tidak ada yang bisa menjawab. Dimana perapiannya? Sulit dimengerti. Kapan itu terbakar? Anda bisa mengetahuinya, tetapi tidak segera.

Mengapa beberapa wadah berdiri sementara yang lain jatuh? Wadah mana yang harus disalahkan? Memang, di luar wadah itu sama, tetapi di dalam masing-masing memiliki Neo sendiri.

Pengembang kami adalah orang-orang yang melek huruf. Mereka membuat layanan yang baik yang membuat keuntungan perusahaan. Tetapi ada kepalsuan ketika wadah dengan aplikasi pergi secara acak. Satu wadah mengkonsumsi terlalu banyak CPU, yang lain mengkonsumsi jaringan, yang ketiga mengkonsumsi operasi I / O, dan yang keempat umumnya tidak jelas apa fungsinya dengan soket. Semua ini jatuh, dan kapal itu tenggelam.

Agen

Untuk memahami apa yang terjadi di dalam, kami memutuskan untuk menempatkan agen secara langsung dalam wadah.

Agen-agen ini adalah program penahanan yang menjaga wadah dalam keadaan sedemikian rupa sehingga tidak saling menghancurkan. Agen distandarisasi, dan ini memungkinkan pendekatan standar untuk penanganan wadah.

Dalam kasus kami, agen harus menyediakan log dalam format standar, ditandai dan dengan pelacakan. Mereka juga harus memberi kami metrik standar yang dapat dikembangkan dalam hal aplikasi bisnis.

Agen juga berarti utilitas untuk operasi dan pemeliharaan, mampu bekerja dalam sistem orkestrasi yang berbeda, mendukung gambar yang berbeda (Debian, Alpine, Centos, dll.).

Akhirnya, agen harus mendukung CI / CD sederhana termasuk file Docker. Kalau tidak, kapal akan berantakan, karena kontainer akan mulai dikirim di atas rel yang "melengkung".

Proses perakitan dan gambar perangkat target

Agar semuanya terstandarisasi dan dapat dikelola, Anda harus mematuhi beberapa proses perakitan standar. Oleh karena itu, kami memutuskan untuk mengumpulkan kontainer dengan kontainer - rekursi seperti itu.

Di sini wadah diwakili oleh kontur padat. Pada saat yang sama, mereka memutuskan untuk menempatkan distribusi di dalamnya sehingga "kehidupan tidak tampak seperti raspberry." Mengapa ini dilakukan, kami akan jelaskan di bawah ini.

Hasilnya adalah alat build - wadah dari versi tertentu, yang merujuk pada versi distribusi tertentu dan versi skrip tertentu.

bagaimana kami menggunakannya? Kami memiliki Hub Docker di mana wadah berada. Kami mencerminkannya di dalam sistem kami untuk menyingkirkan ketergantungan eksternal. Wadah yang dihasilkan ditandai dengan warna kuning. Kami membuat templat untuk dipasang di wadah semua distribusi dan skrip yang kami butuhkan. Setelah itu, kami mengumpulkan gambar yang siap dioperasikan: pengembang memasukkan kode dan beberapa dependensi khusus di dalamnya.

Mengapa pendekatan ini bagus?

Pertama, kontrol versi lengkap alat bangun - bangun wadah, skrip dan versi distribusi.
Kedua, kami telah mencapai standardisasi: dengan cara yang sama kami membuat template, gambar sedang dan siap untuk operasi.
Ketiga, wadah memberi kami portabilitas. Hari ini kita menggunakan Gitlab, dan besok kita akan beralih ke TeamCity atau Jenkins dan dengan cara yang sama kita akan dapat meluncurkan kontainer kita.
Keempat, meminimalkan ketergantungan. Bukan kebetulan bahwa kami menempatkan distribusi dalam wadah, karena ini memungkinkan kami untuk tidak mengunduhnya setiap waktu dari Internet.
Kelima, kecepatan perakitan telah meningkat - ketersediaan salinan gambar lokal memungkinkan Anda untuk tidak membuang waktu mengunduh, karena ada gambar lokal.

Dengan kata lain, kami telah mencapai proses perakitan yang terkontrol dan fleksibel. Kami menggunakan alat yang sama untuk membuat wadah apa pun dengan versi lengkap.

Bagaimana prosedur pembangunan kami bekerja

Perakitan diluncurkan dengan satu perintah, proses dilakukan dalam gambar (disorot dengan warna merah). Pengembang memiliki file Docker (disorot dengan warna kuning), kami membuatnya dengan mengganti variabel dengan nilai. Dan di sepanjang jalan kami menambahkan header dan footer - ini adalah agen kami.

Header menambahkan distribusi dari gambar yang sesuai. Dan footer memasang layanan kami di dalam, mengonfigurasi peluncuran beban kerja, pencatatan dan agen lainnya, menggantikan titik masuk, dll.

Kami berpikir lama untuk menentukan atasan. Pada akhirnya, mereka memutuskan bahwa kami membutuhkannya. Pilih S6. Pengawas memberikan kendali atas wadah: memungkinkan Anda untuk menyambungkannya jika terjatuh dalam proses utama dan memberikan kontrol manual terhadap wadah tanpa membuatnya kembali. Log dan metrik adalah proses yang berjalan di dalam sebuah wadah. Mereka juga perlu dikendalikan, dan kami melakukannya dengan bantuan penyelia. Akhirnya, S6 mengurus urusan rumah tangga, pemrosesan sinyal dan tugas-tugas lainnya.

Karena kami menggunakan sistem orkestrasi yang berbeda, setelah perakitan dan peluncuran, wadah harus memahami apa lingkungannya dan bertindak atas situasi tersebut. Contohnya:
Ini memungkinkan kami untuk mengumpulkan satu gambar dan meluncurkannya dalam sistem orkestrasi yang berbeda, dan itu akan diluncurkan dengan mempertimbangkan spesifikasi sistem orkestrasi ini.

Untuk wadah yang sama, kami mendapatkan pohon proses yang berbeda di Docker dan Kubernetes:

Muatan dijalankan di bawah pengawas S6. Perhatikan kolektor dan acara - ini adalah agen kami yang bertanggung jawab atas log dan metrik. Kubernetes tidak memilikinya, tetapi Docker memilikinya. Mengapa?

Jika Anda melihat spesifikasi "perapian" (selanjutnya - Kubernetes pod), kita akan melihat bahwa wadah peristiwa dijalankan di perapian, di mana ada wadah pengumpul terpisah yang melakukan fungsi pengumpulan metrik dan log. Kita dapat menggunakan kemampuan Kubernetes: menjalankan kontainer dalam satu perapian, dalam satu proses dan / atau ruang jaringan. Sebenarnya perkenalkan agen Anda dan lakukan beberapa fungsi. Dan jika wadah yang sama diluncurkan di Docker, itu akan menerima semua fitur yang sama di output, yaitu, ia akan dapat mengirimkan log dan metrik, karena agen akan diluncurkan di dalam.

Metrik dan Log

Pengiriman metrik dan log adalah tugas yang sulit. Ada beberapa aspek dalam keputusannya.
Infrastruktur dibuat untuk memenuhi muatan, dan bukan pengiriman massal kayu bulat. Artinya, proses ini harus dilakukan dengan persyaratan minimal untuk sumber daya wadah. Kami berusaha membantu pengembang kami: "Ambil wadah Docker Hub, luncurkan, dan kami dapat mengirimkan log."

Aspek kedua adalah batasan volume log. Jika dalam beberapa kontainer ada situasi lonjakan volume log (aplikasi menampilkan tumpukan-jejak dalam satu lingkaran), beban pada CPU, saluran komunikasi, sistem pemrosesan log meningkat, dan ini mempengaruhi operasi host secara keseluruhan dan kontainer lain pada host, kadang-kadang hal ini menyebabkan "Fall" dari tuan rumah.

Aspek ketiga - Anda perlu mendukung sebanyak mungkin metode pengumpulan metrik dari kotak. Dari membaca file dan polling Prometheus-endpoint hingga menggunakan protokol aplikasi tertentu.

Dan aspek terakhir - Anda perlu meminimalkan konsumsi sumber daya.

Kami memilih solusi Go sumber terbuka yang disebut Telegraf. Ini adalah konektor universal yang mendukung lebih dari 140 jenis saluran input (input plugins) dan 30 jenis output (plugins output). Kami menyelesaikannya dan sekarang kami akan memberi tahu bagaimana ini digunakan dengan Kubernetes sebagai contoh.

Misalkan pengembang menyebarkan muatan dan Kubernetes menerima permintaan untuk membuat perapian. Pada titik ini, sebuah wadah bernama Kolektor secara otomatis dibuat untuk setiap pod (kami menggunakan webhook mutasi). Kolektor adalah agen kami. Pada awalnya, wadah ini mengkonfigurasikan dirinya untuk bekerja dengan Prometheus dan sistem pengumpulan log.

Untuk melakukan ini, ia menggunakan anotasi perapian, dan bergantung pada isinya, menciptakan, katakanlah, titik akhir Prometheus;
Berdasarkan spesifikasi perapian dan pengaturan spesifik wadah, ia memutuskan bagaimana mengirimkan kayu.

Kami mengumpulkan log melalui API Docker: cukup bagi pengembang untuk meletakkannya di stdout atau stderr, dan kemudian Collector akan mengetahuinya. Log dikumpulkan oleh chunk dengan beberapa penundaan untuk mencegah kemungkinan kemacetan host.

Metrik dikumpulkan pada instance (proses) beban kerja dalam wadah. Semuanya ditandai: namespace, di bawah, dan seterusnya, lalu dikonversi ke format Prometheus - dan tersedia untuk koleksi (kecuali untuk log). Kami juga mengirim log, metrik, dan acara ke Kafka dan selanjutnya:

Log tersedia di Graylog (untuk analisis visual);
Log, metrik, acara dikirim ke Clickhouse untuk penyimpanan jangka panjang.

Demikian juga, semuanya berfungsi di AWS, hanya kami mengganti Graylog dari Kafka dengan Cloudwatch. Kami mengirim log di sana, dan semuanya ternyata dengan sangat mudah: segera jelas kepada siapa cluster dan container itu milik. Hal yang sama berlaku untuk Google Stackdriver. Yaitu, skema kami berfungsi baik di tempat dengan Kafka, dan di awan.

Jika kami tidak memiliki Kubernet dengan pod, skema ini sedikit lebih rumit, tetapi bekerja dengan prinsip yang sama.

Proses yang sama dilakukan di dalam wadah, mereka diatur menggunakan S6. Semua proses yang sama berjalan di dalam wadah yang sama.

Akhirnya

Kami telah menciptakan solusi lengkap untuk merakit dan meluncurkan gambar ke dalam operasi, dengan opsi untuk mengumpulkan dan mengirimkan log dan metrik:

Mengembangkan pendekatan standar untuk perakitan gambar, berdasarkan itu dikembangkan template-CI;
Agen pengumpulan data adalah ekstensi kami ke Telegraf. Kami menjalankannya dengan baik dalam produksi;
Kami menggunakan webhook mutasi untuk menerapkan wadah dengan agen di pod;
Terintegrasi ke dalam ekosistem Kubernetes / Rancher;
Kami dapat menjalankan wadah yang sama dalam sistem orkestrasi yang berbeda dan mendapatkan hasil yang kami harapkan;
Menciptakan konfigurasi manajemen wadah yang sepenuhnya dinamis.

Rekan penulis: Ilya Prudnikov

Gambar yang siap produksi untuk k8s