kube state metrics
v2.14.0
kube-state-metrics (KSM) هي خدمة بسيطة تستمع إلى خادم Kubernetes API وتقوم بإنشاء مقاييس حول حالة الكائنات. (راجع الأمثلة في قسم المقاييس أدناه.) ولا يركز على سلامة مكونات Kubernetes الفردية، بل على سلامة الكائنات المختلفة بداخلها، مثل عمليات النشر والعقد والقرون.
تتعلق مقاييس حالة kube بإنشاء مقاييس من كائنات Kubernetes API دون تعديل. وهذا يضمن أن الميزات التي توفرها مقاييس حالة kube تتمتع بنفس درجة الاستقرار التي تتمتع بها كائنات Kubernetes API نفسها. وهذا بدوره يعني أن مقاييس حالة kube في مواقف معينة قد لا تظهر نفس القيم تمامًا مثل kubectl، حيث يطبق kubectl بعض الاستدلالات لعرض الرسائل المفهومة. تعرض kube-state-metrics البيانات الأولية غير المعدلة من واجهة برمجة تطبيقات Kubernetes، وبهذه الطريقة يحصل المستخدمون على جميع البيانات التي يحتاجونها ويقومون بالاستدلال على النحو الذي يرونه مناسبًا.
يتم تصدير المقاييس على نقطة نهاية HTTP /metrics الموجودة على منفذ الاستماع (الافتراضي 8080). يتم تقديمها كنص عادي. لقد تم تصميمها ليتم استهلاكها إما بواسطة Prometheus نفسها أو بواسطة مكشطة متوافقة مع استخراج نقطة نهاية عميل Prometheus. يمكنك أيضًا فتح /metrics في المتصفح لرؤية المقاييس الأولية. لاحظ أن المقاييس المعروضة على نقطة النهاية /metrics تعكس الحالة الحالية لمجموعة Kubernetes. عند حذف كائنات Kubernetes، فإنها لم تعد مرئية على نقطة النهاية /metrics .
ملحوظة
تم إنشاء هذا الملف التمهيدي (README) من قالب. يرجى إجراء التغييرات هناك وتشغيل make generate-template .
الإصدار
نسخة كوبيرنتس
مصفوفة التوافق
توافق إصدار مجموعة الموارد
صورة الحاوية
توثيق المقاييس
حل النزاعات في أسماء التصنيفات
Kube-State-metrics المقاييس الذاتية
توصية الموارد
كمون
ملاحظة حول التكاليف
kube-state-metrics مقابل metrics-server
تحجيم مقاييس حالة kube
التقسيم الآلي
توصية الموارد
التقسيم الأفقي
تقسيم Daemonset لمقاييس الكبسولة
يثبت
بناء حاوية دوكر
الاستخدام
نشر Kubernetes
بيئة امتيازات محدودة
مخطط هيلم
تطوير
مساهمات المطورين
مجتمع
تستخدم kube-state-metrics client-go للتحدث مع مجموعات Kubernetes. يتم تحديد إصدار مجموعة Kubernetes المدعوم من خلال client-go . يمكن العثور على مصفوفة التوافق لمجموعة Client-go وKubernetes هنا. كل التوافق الإضافي هو مجرد أفضل جهد، أو ما زال مدعومًا/مدعومًا بالفعل.
على الأكثر، سيتم تسجيل 5 مقاييس حالة kube و5 إصدارات kubernetes أدناه. بشكل عام، يوصى باستخدام أحدث إصدار من kube-state-metrics. إذا قمت بتشغيل إصدار حديث جدًا من Kubernetes، فقد ترغب في استخدام إصدار لم يتم طرحه للحصول على النطاق الكامل للموارد المدعومة. إذا قمت بتشغيل إصدار أقدم من Kubernetes، فقد تحتاج إلى تشغيل إصدار أقدم حتى تحصل على الدعم الكامل لجميع الموارد. انتبه إلى أن المشرفين سيدعمون الإصدار الأحدث فقط. قد يتم دعم الإصدارات الأقدم من قبل المستخدمين المهتمين في المجتمع.
| مقاييس حالة kube | إصدار عميل Kubernetes |
|---|---|
| v2.10.1 | v1.27 |
| v2.11.0 | v1.28 |
| v2.12.0 | v1.29 |
| v2.13.0 | v1.30 |
| v2.14.0 | v1.31 |
| رئيسي | v1.31 |
يمكن أن تتطور الموارد في Kubernetes، أي أن الإصدار الجماعي لمورد ما قد يتغير من ألفا إلى بيتا وأخيرًا GA في إصدارات مختلفة من Kubernetes. في الوقت الحالي، ستستخدم kube-state-metrics فقط أقدم واجهة برمجة تطبيقات متوفرة في الإصدار الأخير.
يمكن العثور على أحدث صورة للحاوية على:
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.14.0 (arch: amd64 و arm و arm64 و ppc64le و s390x )
عرض جميع الصور متعددة الهندسة المعمارية هنا
يتم استبعاد أي موارد ومقاييس تعتمد على واجهات برمجة تطبيقات alpha Kubernetes من أي ضمان استقرار، والذي قد يتغير في أي إصدار محدد.
راجع دليل docs لمزيد من المعلومات حول المقاييس المكشوفة.
تعرض عائلة المقاييس *_labels تصنيفات Kubernetes كتسميات Prometheus. نظرًا لأن Kubernetes أكثر ليبرالية من Prometheus فيما يتعلق بالأحرف المسموح بها في أسماء التصنيفات، فإننا نقوم تلقائيًا بتحويل الأحرف غير المدعومة إلى شرطات سفلية. على سبيل المثال، يصبح app.kubernetes.io/name label_app_kubernetes_io_name .
يمكن أن يؤدي هذا التحويل إلى إنشاء تعارضات عندما يتم تحويل تسميات Kubernetes المتعددة مثل foo-bar و foo_bar إلى نفس تسمية Prometheus label_foo_bar .
تضيف Kube-state-metrics تلقائيًا اللاحقة _conflictN لحل هذا التعارض، لذلك تقوم بتحويل التسميات المذكورة أعلاه إلى label_foo_bar_conflict1 و label_foo_bar_conflict2 .
إذا كنت ترغب في الحصول على مزيد من التحكم في كيفية حل هذا التعارض، فقد ترغب في التفكير في معالجة هذه المشكلة على مستوى مختلف من المكدس، على سبيل المثال، من خلال توحيد تسميات Kubernetes باستخدام خطاف القبول على الويب الذي يضمن عدم وجود تعارضات محتملة.
تعرض kube-state-metrics مقاييس العملية العامة الخاصة بها ضمن --telemetry-host و --telemetry-port (الافتراضي 8081).
تعرض kube-state-metrics أيضًا مقاييس النجاح والخطأ في القائمة والمشاهدة. يمكن استخدامها لحساب معدل الخطأ في القائمة أو مراقبة الموارد. إذا واجهت تلك الأخطاء في المقاييس، فمن المرجح أن تكون مشكلة في التكوين أو الإذن، والشيء التالي الذي يجب التحقيق فيه هو النظر في سجلات مقاييس حالة kube.
مثال على المقاييس المذكورة أعلاه:
kube_state_metrics_list_total{resource="*v1.Node",result="success"} 1
kube_state_metrics_list_total{resource="*v1.Node",result="error"} 52
kube_state_metrics_watch_total{resource="*v1beta1.Ingress",result="success"} 1تعرض kube-state-metrics أيضًا بعض مقاييس طلب http، ومن أمثلة تلك المقاييس:
http_request_duration_seconds_bucket{handler="metrics",method="get",le="2.5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="10"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="+Inf"} 30
http_request_duration_seconds_sum{handler="metrics",method="get"} 0.021113919999999998
http_request_duration_seconds_count{handler="metrics",method="get"} 30تعرض kube-state-metrics أيضًا مقاييس البناء والتكوين:
kube_state_metrics_build_info{branch="main",goversion="go1.15.3",revision="6c9d775d",version="v2.0.0-beta"} 1
kube_state_metrics_shard_ordinal{shard_ordinal="0"} 0
kube_state_metrics_total_shards 1 يتم استخدام kube_state_metrics_build_info للكشف عن الإصدار ومعلومات البناء الأخرى. لمزيد من الاستخدام حول نمط المعلومات، يرجى مراجعة مشاركة المدونة هنا. تعرض مقاييس المشاركة علامتي --shard و --total-shards ويمكن استخدامها للتحقق من صحة تكوين وقت التشغيل، راجع /examples/prometheus-alerting-rules .
تعرض kube-state-metrics أيضًا مقاييس حول ملف التكوين وملف تكوين حالة الموارد المخصصة:
kube_state_metrics_config_hash{filename="crs.yml",type="customresourceconfig"} 2.38272279311849e+14
kube_state_metrics_config_hash{filename="config.yml",type="config"} 2.65285922340846e+14
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="crs.yml",type="customresourceconfig"} 1.6704882592037103e+09
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="config.yml",type="config"} 1.6704882592035313e+09
kube_state_metrics_last_config_reload_successful{filename="crs.yml",type="customresourceconfig"} 1
kube_state_metrics_last_config_reload_successful{filename="config.yml",type="config"} 1يتغير استخدام الموارد لمقاييس حالة kube مع حجم كائنات Kubernetes (Pods/Nodes/Deployments/Secrets وما إلى ذلك) للمجموعة. إلى حد ما، تتناسب كائنات Kubernetes الموجودة في المجموعة بشكل مباشر مع رقم عقدة المجموعة.
كقاعدة عامة، يجب عليك تخصيص:
ذاكرة 250 ميجابايت
0.1 النوى
لاحظ أنه إذا تم تعيين حدود وحدة المعالجة المركزية على مستوى منخفض جدًا، فلن تتمكن قوائم الانتظار الداخلية لـ kube-state-metrics من العمل بسرعة كافية، مما يؤدي إلى زيادة استهلاك الذاكرة مع زيادة طول قائمة الانتظار. إذا واجهت مشاكل ناتجة عن تخصيص الذاكرة بشكل كبير أو اختناق وحدة المعالجة المركزية، فحاول زيادة حدود وحدة المعالجة المركزية.
في اختبار قياس مجموعة 100 عقدة، كانت أرقام زمن الوصول كما يلي:
"Perc50": 259615384 ns, "Perc90": 475000000 ns, "Perc99": 906666666 ns.
افتراضيًا، تعرض مقاييس حالة kube عدة مقاييس للأحداث عبر مجموعتك. إذا كان لديك عدد كبير من الموارد التي يتم تحديثها بشكل متكرر في مجموعتك، فقد تجد أنه يتم استيعاب الكثير من البيانات في هذه المقاييس. قد يؤدي ذلك إلى تكبد تكاليف عالية على بعض موفري الخدمات السحابية. يرجى تخصيص بعض الوقت لتكوين المقاييس التي ترغب في الكشف عنها، بالإضافة إلى مراجعة الوثائق الخاصة ببيئة Kubernetes الخاصة بك لتجنب التكاليف المرتفعة بشكل غير متوقع.
خادم المقاييس هو مشروع مستوحى من Heapster ويتم تنفيذه لخدمة أهداف خطوط أنابيب المقاييس الأساسية في بنية مراقبة Kubernetes. إنه مكون على مستوى المجموعة يقوم بشكل دوري بجمع المقاييس من جميع عقد Kubernetes التي تخدمها Kubelet من خلال Metrics API. يتم تجميع المقاييس وتخزينها في الذاكرة وتقديمها بتنسيق Metrics API. يقوم خادم المقاييس بتخزين أحدث القيم فقط وليس مسؤولاً عن إعادة توجيه المقاييس إلى وجهات خارجية.
تركز مقاييس حالة kube على إنشاء مقاييس جديدة تمامًا من حالة كائن Kubernetes (على سبيل المثال، المقاييس المستندة إلى عمليات النشر ومجموعات النسخ المتماثلة وما إلى ذلك). فهو يحمل لقطة كاملة لحالة Kubernetes في الذاكرة ويقوم باستمرار بإنشاء مقاييس جديدة تعتمد عليها. وكما هو الحال مع خادم المقاييس، فهو أيضًا ليس مسؤولاً عن تصدير مقاييسه إلى أي مكان.
إن وجود مقاييس حالة kube كمشروع منفصل يتيح أيضًا الوصول إلى هذه المقاييس من أنظمة المراقبة مثل Prometheus.
من أجل تقسيم مقاييس حالة kube أفقيًا، تم تنفيذ بعض إمكانيات التجزئة الآلية. تم تكوينه مع العلامات التالية:
--shard (مفهرس صفر)
--total-shards
تتم المشاركة عن طريق أخذ مجموع md5 من UID الخاص بكائن Kubernetes وإجراء عملية modulo عليه بإجمالي عدد القطع. يقرر كل جزء ما إذا كان سيتم التعامل مع الكائن من خلال المثيل المعني لمقاييس حالة kube أم لا. لاحظ أن هذا يعني أن جميع مثيلات مقاييس حالة kube، حتى لو كانت مقسمة، ستحظى بحركة مرور الشبكة واستهلاك الموارد لإلغاء تنظيم الكائنات لجميع الكائنات، وليس فقط الكائنات المسؤولة عنها. لتحسين ذلك بشكل أكبر، ستحتاج واجهة برمجة تطبيقات Kubernetes إلى دعم إمكانات القائمة/المراقبة المقسمة. في الحالة المثالية، سيكون استهلاك الذاكرة لكل جزء 1/n مقارنةً بالإعداد غير المجزأ. عادةً، تحتاج مقاييس حالة kube إلى تحسين الذاكرة وزمن الاستجابة حتى تتمكن من إعادة مقاييسها بسرعة إلى Prometheus. تتمثل إحدى طرق تقليل زمن الوصول بين مقاييس حالة kube وkube-apserver في تشغيل KSM باستخدام علامة --use-apiserver-cache . بالإضافة إلى تقليل زمن الوصول، سيؤدي هذا الخيار أيضًا إلى تقليل الحمل على إلخ.
يجب استخدام التقسيم بعناية ويجب إعداد مراقبة إضافية لضمان إعداد التقسيم وتشغيله كما هو متوقع (على سبيل المثال، يتم تكوين مثيلات كل جزء من إجمالي الأجزاء).
يسمح التقسيم التلقائي لكل جزء باكتشاف موضعه الاسمي عند نشره في StatefulSet وهو أمر مفيد لتكوين التقسيم تلقائيًا. هذه ميزة تجريبية وقد يتم كسرها أو إزالتها دون سابق إنذار.
لتمكين التجزئة التلقائية، يجب تشغيل مقاييس حالة kube بواسطة StatefulSet ويجب تسليم اسم pod ومساحة الاسم إلى عملية مقاييس حالة kube عبر علامتي --pod و --pod-namespace . يمكن العثور على أمثلة توضح وظيفة التقسيم التلقائي في /examples/autosharding .
تعد طريقة نشر الأجزاء هذه مفيدة عندما تريد إدارة أجزاء KSM من خلال مورد Kubernetes واحد ( StatefulSet واحد في هذه الحالة) بدلاً من الحصول على Deployment واحدة لكل جزء. يمكن أن تكون الميزة ذات أهمية خاصة عند نشر عدد كبير من القطع.
الجانب السلبي لاستخدام الإعداد المقسم تلقائيًا يأتي من استراتيجية الطرح التي تدعمها StatefulSet s. عند إدارتها بواسطة StatefulSet ، يتم استبدال الكبسولات واحدة تلو الأخرى مع إنهاء كل حاوية أولاً ثم إعادة إنشائها. إلى جانب كون عمليات الطرح هذه أبطأ، فإنها ستؤدي أيضًا إلى فترة توقف قصيرة لكل جزء. إذا حدث خلل في Prometheus أثناء عملية الطرح، فمن الممكن أن تفوت بعض المقاييس التي تم تصديرها بواسطة kube-state-metrics.
بالنسبة لمقاييس البود، يمكن تقسيمها لكل عقدة مع العلامة التالية:
--node=$(NODE_NAME)
تستخدم كل حاوية مقاييس حالة kube FieldSelector (spec.nodeName) لمشاهدة/إدراج مقاييس الحافظة على نفس العقدة فقط.
مثال على مقاييس حالة kube daemonset:
apiVersion: apps/v1 kind: DaemonSet spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resource=pods - --node=$(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName
لتتبع مقاييس البودات غير المعينة، تحتاج إلى إضافة عملية نشر إضافية وتعيين --track-unscheduled-pods ، كما هو موضح في المثال التالي:
apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resources=pods - --track-unscheduled-pods
يمكن تقسيم المقاييس الأخرى عبر التجزئة الأفقية.
قم بتثبيت هذا المشروع على $GOPATH الخاص بك باستخدام go get :
go get k8s.io/kube-state-metrics
ما عليك سوى تشغيل الأمر التالي في هذا المجلد الجذر، والذي سيؤدي إلى إنشاء ملف ثنائي مستقل ومرتبط بشكل ثابت وإنشاء صورة Docker:
make container
ما عليك سوى إنشاء مقاييس حالة kube وتشغيلها داخل حجرة Kubernetes التي تحتوي على رمز مميز لحساب الخدمة الذي يتمتع بإمكانية الوصول للقراءة فقط إلى مجموعة Kubernetes.
يقوم المكدس ( kube-prometheus ) بتثبيت مقاييس حالة kube كأحد مكوناته؛ لا تحتاج إلى تثبيت مقاييس حالة kube إذا كنت تستخدم مكدس kube-prometheus.
إذا كنت تريد مراجعة التكوين الافتراضي لـ kube-prometheus، على سبيل المثال لتمكين المقاييس غير الافتراضية، فقم بإلقاء نظرة على تخصيص Kube-Prometheus.
لنشر هذا المشروع، يمكنك ببساطة تشغيل kubectl apply -f examples/standard وسيتم إنشاء خدمة ونشر Kubernetes. (ملاحظة: اضبط إصدار apiVersion لبعض الموارد إذا لم يكن إصدار مجموعة kubernetes لديك 1.8+، فتحقق من ملف yaml لمزيد من المعلومات).
لجعل Prometheus يكتشف مثيلات kube-state-metrics، يُنصح بإنشاء تكوين Prometheus Scrape محدد لمقاييس kube-state-metrics الذي يلتقط نقطتي نهاية المقاييس. لا يُنصح بالاكتشاف المعتمد على التعليقات التوضيحية نظرًا لأنه سيكون من الممكن تحديد واحدة فقط من نقاط النهاية، بالإضافة إلى أن مقاييس kube-state-metrics في معظم الحالات لها متطلبات مصادقة وتفويض خاصة لأنها تمنح بشكل أساسي حق الوصول للقراءة من خلال نقطة نهاية المقاييس لمعظم المعلومات المتاحة لها.
ملاحظة: مستخدمو Google Kubernetes Engine (GKE) - لدى GKE أذونات دور صارمة من شأنها أن تمنع إنشاء أدوار مقاييس حالة kube وارتباطات الأدوار. للتغلب على هذه المشكلة، يمكنك منح هوية Google Cloud Platform دور مسؤول المجموعة عن طريق تشغيل السطر الواحد التالي:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud info --format='value(config.account)')
لاحظ أن هوية Google Cloud Platform حساسة لحالة الأحرف ولكن gcloud info اعتبارًا من Google Cloud SDK 221.0.0 ليست كذلك. وهذا يعني أنه إذا كان عضو IAM الخاص بك يحتوي على أحرف كبيرة، فقد لا يناسبك السطر الواحد أعلاه. إذا كان لديك 403 استجابات محظورة بعد تشغيل الأمر أعلاه وتطبيق kubectl apply -f examples/standard ، فتحقق من عضو IAM المرتبط بحسابك على https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID . إذا كان يحتوي على أحرف كبيرة، فقد تحتاج إلى تعيين علامة --user في الأمر أعلاه على الدور الحساس لحالة الأحرف المدرج في https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID.
بعد تشغيل ما ورد أعلاه، إذا رأيت Clusterrolebinding "cluster-admin-binding" created ، فستتمكن من متابعة إعداد هذه الخدمة.
تتوفر نقاط نهاية التحقق من الصحة التالية (تشير self إلى منفذ القياس عن بعد، بينما تشير main إلى منفذ العرض):
/healthz (مكشوف على main ): يُرجع رمز الحالة 200 إذا كان التطبيق قيد التشغيل. نوصي باستخدام هذا لمسبار بدء التشغيل.
/livez (مكشوف على main ): يُرجع رمز الحالة 200 إذا لم يتأثر التطبيق بانقطاع خادم Kubernetes API. نوصي باستخدام هذا لمسبار الحيوية.
/readyz (مكشوف على self ): يُرجع رمز الحالة 200 إذا كان التطبيق جاهزًا لقبول الطلبات وكشف المقاييس. نوصي باستخدام هذا لمسبار الاستعداد.
لاحظ أنه لا يُنصح باستخدام نقطة نهاية مقاييس القياس عن بعد لأي مسبار عند توكيل بيانات العرض.
إذا كنت تريد تشغيل مقاييس حالة kube في بيئة ليس لديك فيها دور قارئ المجموعة، فيمكنك:
إنشاء حساب الخدمة
apiVersion: v1kind: ServiceAccountmetadata: الاسم: kube-state-metrics مساحة الاسم: سيتم نشر مساحة الاسم الخاصة بك حيث سيتم نشر مقاييس حالة kube
منحه امتيازات view على مساحات أسماء محددة (باستخدام roleBinding) ( ملاحظة: يمكنك إضافة roleBinding هذا إلى جميع NS التي تريد أن يصل إليها حساب الخدمة الخاص بك )
apiVersion: rbac.authorization.k8s.io/v1kind: بيانات تعريف الدور: الاسم: مقاييس حالة kube مساحة الاسم: project1roleRef: apiGroup: rbac.authorization.k8s.io النوع: دور الكتلة الاسم: مواضيع العرض: - النوع: ServiceAccountname: kube-state-metricsnamespace: your-namespace-where-kube-state-metrics-will-deployed
ثم حدد مجموعة من مساحات الأسماء (باستخدام خيار --namespaces ) ومجموعة من كائنات kubernetes (باستخدام --resources ) التي يمكن لحساب الخدمة الخاص بك الوصول إليها في تكوين نشر kube-state-metrics
المواصفات: القالب:المواصفات: الحاويات:
- الاسم: kube-state-metricsargs:
- '--resources=pods' - '--namespaces=project1'للحصول على القائمة الكاملة للوسائط المتاحة، راجع الوثائق الموجودة في docs/developer/cli-arguments.md
بدءًا من مخطط مقاييس حالة kube v2.13.3 (صورة مقاييس حالة kube الإصدار v1.9.8 )، يتم الحفاظ على مخطط Helm الرسمي في مخططات مجتمع بروميثيوس/مخططات الدفة. بدءًا من مخطط مقاييس حالة kube v3.0.0 لا يتم دعم سوى صور مقاييس حالة kube للإصدار v2.0.0 + .
عند التطوير، اختبر تفريغ متري مقابل مجموعة Kubernetes المحلية الخاصة بك عن طريق تشغيل:
يمكن للمستخدمين تجاوز عنوان apiserver في ملف KUBE-CONFIG باستخدام سطر الأوامر
--apiserver.
go install kube-state-metrics --port=8080 --telemetry-port=8081 --kubeconfig=<KUBE-CONFIG> --apiserver=<APISERVER>
ثم حليقة نقطة النهاية المقاييس
curl localhost:8080/metrics
لتشغيل اختبارات e2e محليًا، راجع الوثائق الموجودة في الاختبارات/README.md.
عند التطوير، هناك أنماط معينة من التعليمات البرمجية يجب اتباعها لتحسين تجربتك في المساهمة واحتمالية اجتياز اختبارات e2e واختبارات CI الأخرى. لمعرفة المزيد عنها، راجع الوثائق في docs/developer/guide.md.
هذا المشروع برعاية SIG Instrumentation.
هناك أيضًا قناة لـ #kube-state-metrics على Kubernetes' Slack.
يمكنك أيضًا الانضمام إلى القائمة البريدية لـ SIG Instrumentation. سيؤدي هذا عادةً إلى إضافة دعوات للاجتماعات التالية إلى التقويم الخاص بك، حيث يمكن مناقشة الموضوعات المتعلقة بمقاييس حالة kube.
الاجتماع العادي لمجموعة SIG: أيام الخميس الساعة 9:30 بتوقيت المحيط الهادئ (بتوقيت المحيط الهادئ) (كل أسبوعين). تحويل إلى المنطقة الزمنية الخاصة بك.
اجتماع الفرز العادي: أيام الخميس الساعة 9:30 بتوقيت المحيط الهادئ (بتوقيت المحيط الهادئ) (كل أسبوعين - بالتناوب مع الاجتماع العادي). تحويل إلى المنطقة الزمنية الخاصة بك.
