Situasi umum: Anda memiliki beberapa aplikasi, salah satunya memiliki beban puncak di siang hari, dan pada jam lain tidak ada yang mengaksesnya (atau diakses, tetapi jarang); sementara aplikasi lain dapat menggunakan kekuatan cluster di malam hari. Sebagai contoh aplikasi semacam itu, kita dapat mengutip layanan web, beberapa penangan data.

Seperti biasa, sumber daya cluster tidak cukup sama sekali. Anda harus menemukan sesuatu untuk mengoptimalkan penggunaan sumber daya, dan Kubernetes sangat bagus untuk ini. Ini memiliki Horizontal Pod Autoscaler , yang memungkinkan Anda untuk mengukur aplikasi berdasarkan metrik.



Metrik biasanya disediakan oleh server metrik . Selanjutnya, saya akan berbicara tentang mengganti server metrik dengan Prometheus (karena Prometheus mengimplementasikan data yang disediakan server metrik dan kami menyingkirkan satu tautan tambahan) dan bagaimana mengatur skala aplikasi kami di Kubernetes berdasarkan metrik dari Prometheus.

Untuk memulai, instal operator Prometheus . Secara pribadi, saya menggunakan manifes yang sudah jadi . Anda dapat menggunakan grafik untuk Helm (tapi saya tidak memeriksa kinerjanya). Hapus juga server metrik, jika ada. Setelah itu, periksa apakah semuanya berfungsi sebagaimana mestinya.

# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "metrics.k8s.io/v1beta1", "resources": [ { "name": "nodes", "singularName": "", "namespaced": false, "kind": "NodeMetrics", "verbs": [ "get", "list" ] }, { "name": "pods", "singularName": "", "namespaced": true, "kind": "PodMetrics", "verbs": [ "get", "list" ] } ] } 

Kemudian terapkan manifes dari direktori ini . Ini akan menginstal Prometheus-adapter. Saya menemukan bagan yang berisi manifes ini, tetapi tidak memeriksanya. Setelah itu, Anda harus menjalankan perintah dengan benar:

 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq 

(akan ada daftar yang sangat besar, jadi saya tidak akan mencantumkannya di sini)

Untuk memahami apa arti url metrics.k8s.io dan custom.metrics.k8s.io, dokumentasi dapat membantu Anda.

Jika ada yang tidak berhasil, maka lihat, seperti biasa, di log. Anda juga dapat mencari solusi dalam masalah .

Sekarang atur autoscaling.

Saya memiliki aplikasi yang menghabiskan banyak sumber daya prosesor dan melayani antrian. Segera setelah ukuran antrian melebihi ambang batas, saya ingin menambah jumlah perapian di set replika untuk memproses antrian lebih cepat. Segera setelah ukurannya menjadi kurang dari ambang batas, sumber daya gugus harus dibebaskan.

Untuk memahami cara menulis aturan untuk adaptor Prometheus, Anda harus membaca dokumen ini dan halaman terkaitnya dengan cermat. Beginilah tampilannya dengan saya.

Permintaan ke Prometheus

 wqueue_tube_total_size{tube="dmload-legacy"} 

mengembalikan:

 wqueue_tube_total_size{endpoint="pprof-port",instance="10.116.2.237:8542",job="wqueue-pprof",namespace="default",pod="wqueue-b9fdd9455-66mwm",service="wqueue-pprof",tube="dmload-legacy"} 32 

Dan saya menulis aturan berikut untuk Prometheus-adapter:

 - seriesQuery: wqueue_tube_total_size{tube="dmload-legacy"} resources: overrides: namespace: resource: namespace tube: resource: service name: {as: "wqueue_tube_total_size_dmload_legacy"} metricsQuery: wqueue_tube_total_size{tube="dmload-legacy"} 

Perlu dicatat bahwa saya harus memetakan parameter tube dalam service , kemudian menggunakan hpa dalam deskripsi.

Konfigurasi Hpa:

 --- kind: HorizontalPodAutoscaler apiVersion: autoscaling/v2beta1 metadata: name: dmload-v3-legacy namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: dmload-v3-legacy minReplicas: 2 maxReplicas: 20 metrics: - type: Object object: metricName: wqueue_tube_total_size_dmload_legacy target: apiVersion: v1 kind: Service name: dmload-legacy targetValue: 30 

Di sini saya menunjukkan bahwa segera setelah jumlah pekerjaan dalam antrian wqueue_tube_total_size_dmload_legacy melebihi 30, tambahkan pod sampai ada 20, dan jika targetValue turun di bawah 30, kemudian kurangi menjadi 2.

Kami mendaftar dan melihat apa yang terjadi. Sistem saya berfungsi selama beberapa hari dan saat ini hanya mengurangi jumlah perapian:

 # kubectl describe hpa dmload-v3-legacy Name: dmload-v3-legacy Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling/v2beta1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"dmload-v3-legacy","namespace":"d... CreationTimestamp: Thu, 24 Jan 2019 16:16:43 +0300 Reference: Deployment/dmload-v3-legacy Metrics: ( current / target ) "wqueue_tube_total_size_dmload_legacy" on Service/dmload-legacy: 14 / 30 Min replicas: 2 Max replicas: 20 Deployment pods: 15 current / 14 desired Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 14 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from Service metric wqueue_tube_total_size_dmload_legacy ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 59m (x14 over 40h) horizontal-pod-autoscaler New size: 13; reason: All metrics below target Normal SuccessfulRescale 59m (x13 over 40h) horizontal-pod-autoscaler New size: 12; reason: All metrics below target Normal SuccessfulRescale 57m (x14 over 40h) horizontal-pod-autoscaler New size: 11; reason: All metrics below target Normal SuccessfulRescale 56m (x14 over 40h) horizontal-pod-autoscaler New size: 10; reason: All metrics below target Normal SuccessfulRescale 56m (x11 over 38h) horizontal-pod-autoscaler New size: 8; reason: All metrics below target Normal SuccessfulRescale 55m (x6 over 36h) horizontal-pod-autoscaler New size: 7; reason: All metrics below target Normal SuccessfulRescale 47m (x103 over 40h) horizontal-pod-autoscaler (combined from similar events): New size: 20; reason: Service metric wqueue_tube_total_size_dmload_legacy above target Normal SuccessfulRescale 3m38s (x19 over 41h) horizontal-pod-autoscaler New size: 17; reason: All metrics below target Normal SuccessfulRescale 2m8s (x23 over 41h) horizontal-pod-autoscaler New size: 16; reason: All metrics below target Normal SuccessfulRescale 98s (x20 over 40h) horizontal-pod-autoscaler New size: 15; reason: All metrics below target Normal SuccessfulRescale 7s (x18 over 40h) horizontal-pod-autoscaler New size: 14; reason: All metrics below target 

Semua yang dijelaskan dilakukan di Kubernetes 1.13.2.

Kesimpulan

Dalam artikel singkat ini, saya menunjukkan cara untuk secara otomatis mengukur aplikasi di cluster Kubernetes menggunakan metrik dari Prometheus.

Komponen Prometheus-operator telah dikonfigurasi dan manifes yang diperlukan dibuat.

Akibatnya, berdasarkan metrik dari Prometheus pada ukuran antrian, ternyata menambah atau mengurangi jumlah polong yang memproses antrian ini.


(grafik menunjukkan bagaimana jumlah perapian bervariasi tergantung pada ukuran antrian)

Terima kasih atas perhatian anda!