HorizontalPodAutoscaler: является ли полная и правильная опубликованная документация по развертыванию адаптера стека-драйвера настраиваемых метрик в GKE?

Question

Google публикует учебник по использованию пользовательских метрик для управления HorizontalPodAutoscaler здесь , и этот учебник содержит инструкции для:

1. Использование манифеста Kubernetes для развертывания пользовательских метрик адаптер в пространство имен custom-metrics.
2. Развертывание фиктивного приложения для создания метрик.
3. Настройка HPA для использования пользовательских метрик.

Мы внедряем в кластер по умолчанию без каких-либо специальных правил VP C, и мы примерно следовали инструкциям руководства, за некоторыми исключениями:

• Мы используем Helm v2, а не предоставляем роль администратора кластера Tiller Мы предоставили все необходимые роли кластера и привязки ролей для работы манифеста Kubernetes, развертывающего пользовательский адаптер метрик, для работы. Мы не видим проблем там; По крайней мере, настраиваемый адаптер метрик запускается и запускается.
• Мы определили некоторые пользовательские метрики, основанные на данных, извлеченных из jsonPayload в журналах Stackdriver.
• Мы развернули каждую минуту минутный CronJob, который читает вышеуказанные метрики и публикует производную метрику c, которая является значением, которое мы хотим использовать для управления автомасштабатором. CronJob работает, и мы можем видеть metri c в производном metri c, для каждого модуля, в журнале metri c explorer:

Мы настраиваем HPA для масштабирования на основе среднего значения производного показателя c по всем пакетам, принадлежащим к набору с состоянием (HPA имеет запись метрики с типом Pod). Однако HPA не может прочитать наш производный показатель c. Мы видим это сообщение об ошибке:

failed to get object metric value: unable to get metric xxx_scaling_metric: no metrics returned from custom metrics API

Обновление

Мы видели ошибки DNS, но это были, очевидно, ложные тревоги, возможно, в войти, пока кластер раскручивался.

Мы перезапустили адаптер метрик Stackdriver с параметром командной строки --v=5, чтобы получить более подробную отладку. Мы видим записи в журнале, подобные этим:

I0123 20:23:08.069406       1 wrap.go:47] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/defaults/pods/%2A/xxx_scaling_metric: (56.16652ms) 200 [kubectl/v1.13.11 (darwin/amd64) kubernetes/2e298c7 10.44.1.1:36286]
I0123 20:23:12.997569       1 translator.go:570] Metric 'xxx_scaling_metric' not found for pod 'xxx-0'
I0123 20:23:12.997775       1 wrap.go:47] GET /apis/custom.metrics.k8s.io/v1beta2/namespaces/default/pods/%2A/xxx_scaling_metric?labelSelector=app%3Dxxx: (98.101205ms) 200 [kube-controller-manager/v1.13.11 (linux/amd64) kubernetes/56d8986/system:serviceaccount:kube-system:horizontal-pod-autoscaler 10.44.1.1:36286]

Так что выглядит для нас , как будто HPA делает правильный запрос для пользовательских метрик на основе модулей. Если мы спросим API пользовательских метрик о том, какие данные у него есть, и отфильтруем с jq в нашу интересующую метрику c, мы увидим:

{"kind":"MetricValueList",
 "apiVersion":"custom.metrics.k8s.io/v1beta1",
 "metadata: {"selfLink":"/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/xxx_scaling_metric"},
 "items":[]}

То, что массив элементов пуст, вызывает беспокойство. Опять же, мы можем видеть данные в обозревателе метрик, поэтому нам остается только задаться вопросом, предоставляет ли наше приложение CronJob, которое публикует наше масштабирование metri c, правильные поля для сохранения данных в Stackdriver или предоставления через метрики адаптер.

Сколько стоит карта resource.labels для временного ряда, который мы публикуем в нашем CronJob, выглядит так:

{'cluster_name': 'test-gke', 
 'zone': 'us-central1-f', 
 'project_id': 'my-project-1234', 
 'container_name': '', 
 'instance_id': '1234567890123456789',
 'pod_id': 'xxx-0', 
 'namespace_id': 'default'}

Answer 1

Мы наконец решили это. Наш CronJob, который публикует производную метрику c, которую мы хотим использовать, получает свои необработанные данные из двух других метрик, извлеченных из журналов Stackdriver, и вычисляет новое значение, которое оно публикует обратно в Stackdriver.

Мы использовали метки ресурсов, которые мы видели из этих метрик при публикации нашего производного метри c. Значение метки ресурса POD_ID в метриках «input» Stackdriver, которые мы читаем, является именем модуля. Однако адаптер пользовательских метрик стека-драйвера в gcr.io/google-containers/custom-metrics-stackdriver-adapter:v0.10.0 перечисляет модули в пространстве имен и запрашивает у стека-драйвера данные, связанные с идентификаторами UID модулей, а не их имена. (Прочитайте исходный код адаптера, чтобы понять это ...)

Итак, наш CronJob теперь строит карту имен модулей для идентификаторов модулей (для этого требуется список модулей RBA C и получение ролей), и публикует производную метрику c, которую мы используем для HPA с POD_ID, установленной в качестве UID модуля вместо его имени.

Причина, по которой были опубликованы примеры пользовательских метрик для HPA (например, this ) работа заключается в том, что они используют Downward API для получения UID модуля и предоставляют это значение как "POD_ID". Оглядываясь назад, это должно было стать очевидным, если бы мы посмотрели на то, как «фиктивные» экспортеры метрик получили свои значения pod id, но, безусловно, есть примеры (как в метриках журналирования Stackdriver), где POD_ID заканчивается именем, а не UID.