Saya membuat Kube Eagle - eksportir Prometheus. Ternyata hal ini merupakan hal keren yang membantu untuk lebih memahami sumber daya cluster kecil dan menengah. Pada akhirnya, saya menghemat ratusan dolar karena memilih jenis mesin yang tepat dan mengonfigurasi batas sumber daya aplikasi untuk beban kerja.
Saya akan memberi tahu Anda tentang manfaatnya , tapi pertama-tama saya akan menjelaskan apa yang menyebabkan keributan dan mengapa diperlukan pemantauan berkualitas tinggi.
Saya mengelola beberapa cluster yang terdiri dari 4β50 node. Setiap cluster berisi hingga 200 layanan mikro dan aplikasi. Untuk memanfaatkan perangkat keras yang ada dengan lebih baik, sebagian besar penerapan dikonfigurasikan dengan RAM dan sumber daya CPU yang dapat meledak. Dengan cara ini, pod dapat mengambil sumber daya yang tersedia jika diperlukan, dan pada saat yang sama tidak mengganggu aplikasi lain di node ini. Nah, bukankah itu bagus?
Dan meskipun cluster tersebut mengkonsumsi CPU yang relatif sedikit (8%) dan RAM (40%), kami terus-menerus mengalami masalah dengan pod yang didahului ketika mereka mencoba mengalokasikan lebih banyak memori daripada yang tersedia pada node. Saat itu kami hanya memiliki satu dasbor untuk memantau sumber daya Kubernetes. Seperti ini:
Dasbor Grafana hanya dengan metrik cAdvisor
Dengan panel seperti itu, tidak menjadi masalah untuk melihat node yang memakan banyak memori dan CPU. Masalahnya adalah mencari tahu apa alasannya. Untuk menjaga agar pod tetap berada di tempatnya, tentu saja seseorang dapat menyiapkan sumber daya yang dijamin di semua pod (sumber daya yang diminta sama dengan batasnya). Namun ini bukanlah penggunaan perangkat keras yang paling cerdas. Cluster ini memiliki memori beberapa ratus gigabyte, sementara beberapa node kekurangan memori, sementara node lainnya memiliki sisa cadangan sebesar 4β10 GB.
Ternyata penjadwal Kubernetes mendistribusikan beban kerja secara tidak merata ke seluruh sumber daya yang tersedia. Penjadwal Kubernetes memperhitungkan konfigurasi yang berbeda: aturan afinitas, noda dan toleransi, pemilih node yang dapat membatasi node yang tersedia. Namun dalam kasus saya, tidak ada hal seperti itu, dan pod direncanakan bergantung pada sumber daya yang diminta pada setiap node.
Node yang memiliki sumber daya bebas paling banyak dan memenuhi ketentuan permintaan dipilih untuk pod tersebut. Kami menemukan bahwa sumber daya yang diminta pada node tidak sesuai dengan penggunaan sebenarnya, dan di sinilah Kube Eagle dan kemampuan pemantauan sumber dayanya membantu.
Saya memiliki hampir semua cluster Kubernetes yang dipantau hanya dengan ΠΈ . Pengekspor Node menyediakan statistik penggunaan I/O dan disk, CPU, dan RAM, sedangkan Metrik Status Kube menunjukkan metrik objek Kubernetes seperti permintaan dan batas sumber daya CPU dan memori.
Kita perlu menggabungkan metrik penggunaan dengan metrik permintaan dan batasan di Grafana, lalu kita akan mendapatkan semua informasi tentang masalahnya. Kedengarannya sederhana, namun kedua alat tersebut sebenarnya memberi nama label yang berbeda, dan beberapa metrik tidak memiliki label metadata sama sekali. Kube Eagle melakukan semuanya sendiri dan panelnya terlihat seperti ini:
Kami berhasil memecahkan banyak masalah sumber daya dan menghemat peralatan:
- Beberapa pengembang tidak mengetahui berapa banyak sumber daya yang dibutuhkan layanan mikro (atau tidak peduli). Tidak ada cara bagi kami untuk menemukan permintaan sumber daya yang salah - untuk ini kami perlu mengetahui konsumsi ditambah permintaan dan batasan. Kini mereka melihat metrik Prometheus, memantau penggunaan sebenarnya, serta menyesuaikan permintaan dan batasan.
- Aplikasi JVM membutuhkan RAM sebanyak yang bisa mereka tangani. Pengumpul sampah hanya melepaskan memori ketika lebih dari 75% digunakan. Dan karena sebagian besar layanan memiliki memori yang dapat meledak, maka selalu ditempati oleh JVM. Oleh karena itu, semua layanan Java ini memakan lebih banyak RAM dari yang diperkirakan.
- Beberapa aplikasi meminta terlalu banyak memori, dan penjadwal Kubernetes tidak memberikan node tersebut ke aplikasi lain, meskipun sebenarnya node tersebut lebih bebas dibandingkan node lainnya. Salah satu pengembang secara tidak sengaja menambahkan angka tambahan ke dalam permintaan dan mengambil sebagian besar RAM: 20 GB, bukan 2. Tidak ada yang menyadarinya. Aplikasi memiliki 3 replika, sehingga sebanyak 3 node terpengaruh.
- Kami memperkenalkan batasan sumber daya, menjadwalkan ulang pod dengan permintaan yang benar, dan mendapatkan keseimbangan penggunaan perangkat keras yang ideal di semua node. Beberapa node bisa saja ditutup seluruhnya. Dan kemudian kami melihat bahwa kami memiliki mesin yang salah (berorientasi CPU, bukan berorientasi memori). Kami mengubah jenisnya dan menghapus beberapa node lagi.
Hasil
Dengan sumber daya yang dapat meledak di cluster, Anda menggunakan perangkat keras yang tersedia dengan lebih efisien, tetapi penjadwal Kubernetes menjadwalkan pod berdasarkan permintaan sumber daya, dan ini penuh risiko. Untuk membunuh dua burung dengan satu batu: untuk menghindari masalah dan menggunakan sumber daya secara maksimal, Anda memerlukan pemantauan yang baik. Inilah mengapa ini akan berguna (Ekspor Prometheus dan dasbor Grafana).
Sumber: www.habr.com