موقف شائع: لديك العديد من التطبيقات ، أحدها لديه ذروة الحمل في النهار ، وفي ساعات أخرى لا أحد يصل إليه (أو يتم الوصول إليه ، ولكن نادرًا) ؛ بينما يمكن للتطبيقات الأخرى استخدام طاقة الكتلة ليلا. كمثال على هذه التطبيقات ، يمكننا الاستشهاد بخدمات الويب ، وبعض معالجات البيانات.

كالعادة ، موارد نظام المجموعة ليست كافية على الإطلاق. عليك أن تتوصل إلى شيء لتحسين استخدام الموارد ، و Kubernetes رائعة في هذا الصدد. إنه يحتوي على Horod Pod Autoscaler ، والذي يسمح لك بتوسيع نطاق التطبيقات على أساس المقاييس.



يتم توفير المقاييس عادة بواسطة خادم القياس . بعد ذلك ، سأتحدث عن استبدال الخادم المتري بـ Prometheus (لأن Prometheus يطبق البيانات التي يوفرها الخادم المتري ونتخلص من رابط إضافي واحد) وكيفية توسيع نطاق تطبيقاتنا في Kubernetes استنادًا إلى مقاييس من Prometheus.

للبدء ، قم بتثبيت مشغل بروميثيوس . أنا شخصياً أستخدم البيانات الجاهزة . يمكنك استخدام الرسم البياني لـ Helm (لكنني لم أتحقق من أدائه). قم أيضًا بإزالة الخادم المتري ، إذا كان لديك واحد. بعد ذلك ، تحقق مما إذا كان كل شيء يعمل كما يجب.

# 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" ] } ] } 

ثم تطبيق البيانات من هذا الدليل . سيؤدي ذلك إلى تثبيت محول بروميثيوس. لقد وجدت مخططًا يحتوي على هذه البيانات ، لكن لم أقم بمراجعته. بعد ذلك ، يجب تشغيل الأمر بشكل صحيح:

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

(ستكون هناك قائمة كبيرة جدًا ، لذا لن أدرجها هنا)

لفهم ما تعنيه عناوين url metrics.k8s.io و custom.metrics.k8s.io ، يمكن أن تساعدك الوثائق .

إذا لم يعمل شيء ما ، فابحث كالمعتاد في السجلات. يمكنك أيضًا البحث عن حل في المشكلات .

الآن إعداد autoscaling.

لدي تطبيق يستهلك الكثير من موارد المعالج ويخدم قائمة الانتظار. بمجرد أن يتجاوز حجم قائمة الانتظار بعض العتبات ، أريد زيادة عدد الموقد في النسخة المتماثلة المعينة لمعالجة قائمة الانتظار بشكل أسرع. بمجرد أن يصبح حجمه أقل من العتبة ، يجب تحرير موارد نظام المجموعة.

لفهم كيفية كتابة قواعد لمحول Prometheus ، تحتاج إلى قراءة هذا المستند والصفحات ذات الصلة به بعناية. هذه هي الطريقة التي تبدو معي.

طلب بروميثيوس

 wqueue_tube_total_size{tube="dmload-legacy"} 

يعود:

 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 

وأنا أكتب القاعدة التالية لبروميثيوس محول:

 - 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"} 

تجدر الإشارة إلى أنه يجب علي تعيين معلمة tube في service ، ثم استخدام hpa في الوصف.

تكوين 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 

أشير هنا إلى أنه بمجرد أن يتجاوز عدد الوظائف في قائمة الانتظار wqueue_tube_total_size_dmload_legacy 30 ، أضف القرون حتى يبلغ عددها 20 ، وإذا انخفض targetValue 30 ، targetValue إلى 2.

نحن نطبق ونرى ما سيحدث. يعمل نظامي لعدة أيام وفي الوقت الحالي يقلل عدد الموقد فقط:

 # 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 

تم تنفيذ كل ما تم وصفه على Kubernetes 1.13.2.

الخاتمة

في هذا المقال القصير ، أوضحت كيفية تغيير حجم التطبيقات تلقائيًا في مجموعة Kubernetes باستخدام مقاييس من بروميثيوس.

تم تكوين مكونات مشغل بروميثيوس وإنشاء البيانات اللازمة.

نتيجةً لذلك ، بناءً على قياس من Prometheus على حجم قائمة الانتظار ، اتضح زيادة أو تقليل عدد القرون التي تعالج قائمة الانتظار هذه.


(يوضح الرسم البياني كيف يختلف عدد الموقد اعتمادًا على حجم قائمة الانتظار)

شكرا لاهتمامكم!