Kajian Kubecost untuk menjimatkan wang pada Kubernetes di awan

Pada masa ini, semakin banyak syarikat memindahkan infrastruktur mereka daripada pelayan perkakasan dan mesin maya mereka sendiri ke awan. Penyelesaian ini mudah dijelaskan: tidak perlu risau tentang perkakasan, kluster mudah dikonfigurasikan dalam pelbagai cara... dan yang paling penting, teknologi sedia ada (seperti Kubernetes) memungkinkan untuk menskalakan kuasa pengkomputeran bergantung pada beban. .

Aspek kewangan sentiasa penting. Alat yang dibincangkan dalam artikel ini direka bentuk untuk membantu mengurangkan belanjawan apabila menggunakan infrastruktur awan dengan Kubernetes.

Pengenalan

Kubecost ialah permulaan California daripada Google, mencipta penyelesaian untuk mengira kos infrastruktur dalam perkhidmatan awan (dalam kluster Kubernetes + sumber dikongsi), mencari kesesakan dalam tetapan kluster dan menghantar pemberitahuan yang sesuai kepada Slack.

Kami mempunyai pelanggan dengan Kubernetes dalam kedua-dua awan AWS dan GCP yang biasa, dan dalam Azure, yang lebih jarang berlaku untuk komuniti Linux - secara umum, pada semua platform yang disokong oleh Kubecost. Bagi sesetengah daripada mereka, kami mengira sendiri kos perkhidmatan intra-kluster (menggunakan kaedah yang serupa dengan yang digunakan oleh Kubecost), dan juga memantau kos infrastruktur dan cuba mengoptimumkannya. Oleh itu, adalah logik bahawa kami berminat dengan kemungkinan mengautomasikan tugas tersebut.

Kod sumber modul Kubecost utama dibuka di bawah syarat lesen Sumber Terbuka (Lesen Apache 2.0). Ia boleh digunakan secara bebas dan ciri-ciri yang ada sepatutnya mencukupi untuk projek kecil. Walau bagaimanapun, perniagaan adalah perniagaan: selebihnya produk ditutup, ia boleh digunakan oleh langganan berbayar, yang juga membayangkan sokongan komersial. Di samping itu, pengarang menawarkan lesen percuma untuk kluster kecil (1 kluster dengan 10 nod - semasa penulisan artikel ini, had ini telah berkembang kepada 20 nod) atau tempoh percubaan dengan keupayaan penuh selama 1 bulan.

Bagaimana ia berfungsi

Jadi, bahagian utama Kubecost ialah aplikasi model kos, ditulis dalam Go. Carta Helm yang menerangkan keseluruhan sistem dipanggil penganalisis kos dan pada terasnya ialah pemasangan daripada model kos dengan Prometheus, Grafana dan beberapa papan pemuka.

Secara umumnya, model kos mempunyai antara muka webnya sendiri, yang menunjukkan graf dan statistik terperinci tentang kos dalam bentuk jadual, serta, sudah tentu, petua untuk mengoptimumkan kos. Papan pemuka yang dibentangkan dalam Grafana adalah peringkat awal dalam pembangunan Kubecost dan mengandungi banyak data yang sama seperti model kos, menambahnya dengan statistik biasa tentang penggunaan CPU/memori/rangkaian/ruang cakera dalam gugusan dan komponen.

Bagaimanakah Kubecost berfungsi?

• Model kos menerima harga untuk perkhidmatan melalui API penyedia awan.
• Selanjutnya, bergantung pada jenis besi nod dan rantau, kos setiap nod dikira.
• Berdasarkan kos menjalankan nod, setiap pod daun mendapat kos setiap jam penggunaan CPU, setiap gigabait memori yang digunakan dan setiap jam setiap gigabait data yang disimpan - bergantung pada nod yang sedang dijalankan atau kelas storan.
• Berdasarkan kos operasi pod individu, pembayaran dikira untuk ruang nama, perkhidmatan, Penggunaan, StatefulSets.
• Statistik dikira menggunakan metrik yang disediakan oleh kube-state-metrics dan nod-exporter.

Adalah penting untuk mempertimbangkan bahawa Kubecost secara lalai hanya mengira sumber yang tersedia dalam Kubernetes. Pangkalan data luaran, pelayan GitLab, storan S3 dan perkhidmatan lain yang tiada dalam kelompok (walaupun terletak dalam awan yang sama) tidak kelihatan kepadanya. Walaupun untuk GCP dan AWS anda boleh menambah kunci akaun perkhidmatan anda dan mengira semuanya bersama-sama.

Pemasangan

Kubecost memerlukan:

• Kubernetes versi 1.8 dan lebih tinggi;
• kube-state-metrics;
• Prometheus;
• pengeksport nod.

Kebetulan dalam kluster kami semua syarat ini dipenuhi terlebih dahulu, jadi ternyata cukup untuk hanya menentukan titik akhir yang betul untuk akses kepada Prometheus. Walau bagaimanapun, carta Helm kubecost rasmi mengandungi semua yang anda perlukan untuk menjalankan gugusan kosong.

Terdapat beberapa cara untuk memasang Kubecost:

1. Kaedah pemasangan standard diterangkan dalam Directions di tapak web pembangun. Diperlukan tambahkan repositori penganalisis kos pada Helm, dan kemudian pasang carta. Yang tinggal hanyalah memajukan port anda dan melaraskan tetapan kepada keadaan yang dikehendaki secara manual (melalui kubectl) dan/atau menggunakan antara muka web model kos.

   Kami belum pun mencuba kaedah ini, kerana kami tidak menggunakan konfigurasi siap sedia pihak ketiga, tetapi ia kelihatan seperti pilihan "cuba sendiri" yang bagus. Jika anda sudah mempunyai beberapa komponen sistem yang dipasang atau anda mahukan lebih penalaan halus, adalah lebih baik untuk mempertimbangkan laluan kedua.

2. Gunakan secara asasnya carta yang sama, tetapi konfigurasi dan pasang sendiri dalam apa jua cara yang mudah.

   Seperti yang telah disebutkan, sebagai tambahan kepada kubecost itu sendiri, carta ini mengandungi carta Grafana dan Prometheus, yang juga boleh disesuaikan mengikut keinginan.

   Tersedia pada carta values.yaml untuk penganalisis kos membolehkan anda mengkonfigurasi:

   • senarai komponen penganalisis kos yang perlu digunakan;
   • titik akhir anda untuk Prometheus (jika anda sudah mempunyai satu);
   • domain dan tetapan kemasukan lain untuk model kos dan Grafana;
   • anotasi untuk pod;
   • keperluan untuk menggunakan storan kekal dan saiznya.

   Senarai lengkap pilihan konfigurasi yang tersedia dengan penerangan tersedia dalam dokumentasi.

   Memandangkan kubecost dalam versi asasnya tidak boleh menyekat akses, anda perlu segera mengkonfigurasi pengesahan asas untuk panel web.

3. Pasang hanya teras sistem - model kos. Untuk melakukan ini, anda mesti memasang Prometheus dalam kluster dan nyatakan nilai yang sepadan dengan alamatnya dalam pembolehubah prometheusEndpoint untuk Helm. Selepas itu - memohon set konfigurasi YAML dalam kelompok.

   Sekali lagi, anda perlu menambah Ingress secara manual dengan asas-auth. Akhir sekali, anda perlu menambah bahagian untuk mengumpul metrik model kos extraScrapeConfigs dalam konfigurasi Prometheus:

   - job_name: kubecost
     honor_labels: true
     scrape_interval: 1m
     scrape_timeout: 10s
     metrics_path: /metrics
     scheme: http
     dns_sd_configs:
     - names:
       - <адрес вашего сервиса kubecost>
       type: 'A'
       port: 9003

Apa yang kita dapat?

Dengan pemasangan penuh, kami mempunyai panel web kubecost dan Grafana dengan satu set papan pemuka.

Jumlah kos, dipaparkan pada skrin utama, sebenarnya menunjukkan anggaran kos sumber untuk bulan tersebut. ini diunjurkan harga mencerminkan kos penggunaan kluster (sebulan) pada tahap penggunaan sumber semasa.

Metrik ini lebih kepada menganalisis perbelanjaan dan mengoptimumkannya. Ia tidak begitu mudah untuk melihat jumlah kos untuk abstrak Julai dalam kubecost: anda perlu melakukan ini pergi ke pengebilan. Tetapi anda boleh melihat kos dipecahkan mengikut ruang nama, label, pod selama 1/2/7/30/90 hari, pengebilan yang tidak akan ditunjukkan kepada anda.

Bercakap tentang label. Anda harus segera pergi ke tetapan dan tetapkan nama label yang akan digunakan sebagai kategori tambahan untuk kos pengumpulan:

Anda boleh menggantung sebarang label pada mereka - mudah jika anda sudah mempunyai sistem pelabelan anda sendiri.

Di sana anda juga boleh menukar alamat titik akhir API yang disambungkan oleh model kos, melaraskan saiz diskaun dalam GCP dan menetapkan harga anda sendiri untuk sumber dan mata wang untuk ukurannya (atas sebab tertentu ciri ini tidak menjejaskan Jumlah kos).

Kubecost boleh menunjukkan pelbagai masalah dalam kluster (dan juga berjaga-jaga sekiranya berlaku bahaya). Malangnya, pilihan itu tidak boleh dikonfigurasikan, dan oleh itu, jika anda mempunyai persekitaran untuk pembangun dan menggunakannya, anda akan sentiasa melihat sesuatu seperti ini:

Alat penting - Simpanan Kluster. Ia mengukur aktiviti pod (penggunaan sumber, termasuk sumber rangkaian), dan juga mengira jumlah wang yang boleh anda simpan dan apa.

Nampaknya petua pengoptimuman agak jelas, tetapi pengalaman menunjukkan bahawa masih ada sesuatu untuk dilihat. Khususnya, aktiviti rangkaian pod dipantau (Kubecost mencadangkan memberi perhatian kepada yang tidak aktif), memori yang diminta dan sebenar serta penggunaan CPU dibandingkan, serta CPU yang digunakan oleh nod kluster (mencadangkan meruntuhkan beberapa nod menjadi satu), cakera beban dan beberapa dozen lagi parameter.

Seperti mana-mana isu pengoptimuman, mengoptimumkan sumber berdasarkan data Kubecost memerlukan: merawat dengan berhati-hati. Sebagai contoh, Penjimatan Kluster mencadangkan pemadaman nod, mendakwa bahawa ia selamat, tetapi tidak mengambil kira kehadiran pemilih nod dan kotoran dalam pod yang digunakan pada nod yang tidak tersedia pada nod lain. Dan secara umum, walaupun pengarang produk dalam mereka artikel terbaru (omong-omong, ia boleh menjadi sangat berguna bagi mereka yang berminat dengan topik projek) adalah disyorkan untuk tidak tergesa-gesa ke dalam pengoptimuman kos, tetapi untuk mendekati isu itu dengan teliti.

Keputusan

Selepas menggunakan kubecost selama sebulan pada beberapa projek, kami boleh membuat kesimpulan bahawa ia adalah alat yang menarik (dan juga mudah dipelajari dan dipasang) untuk menganalisis dan mengoptimumkan kos untuk perkhidmatan penyedia awan yang digunakan untuk kelompok Kubernetes. Pengiraan ternyata sangat tepat: dalam eksperimen kami, pengiraan itu bertepatan dengan perkara yang sebenarnya diperlukan oleh pembekal.

Terdapat juga beberapa kelemahan: terdapat pepijat yang tidak kritikal, dan di beberapa tempat fungsi itu tidak meliputi keperluan khusus untuk beberapa projek. Walau bagaimanapun, jika anda perlu memahami dengan cepat ke mana wang itu pergi dan perkara yang boleh "dipotong" untuk mengurangkan bil untuk perkhidmatan awan secara konsisten sebanyak 5-30% (inilah yang berlaku dalam kes kami), ini adalah pilihan yang bagus .

PS

Baca juga di blog kami:

• «Autoscaling dan pengurusan sumber dalam Kubernetes (gambaran keseluruhan dan laporan video)»;
• «Pengembaraan Kubernetes Dailymotion: mencipta infrastruktur di awan + di premis»;
• «Petua & kiat Kubernetes: mengenai peruntukan nod dan beban aplikasi web'.

Sumber: www.habr.com