#kubernetes #amazon-cloudwatch #autoscaling #amazon-eks #hpa
#kubernetes #amazon-cloudwatch #автоматическое масштабирование #amazon-eks #hpa
Вопрос:
Я пытаюсь включить автоматическое масштабирование AWS EKS на основе пользовательской метрики Cloudwatch с помощью адаптера Kubernetes Cloudwatch. Я отправил пользовательские метрики в AWS Cloudwatch и подтвердил, что они отображаются в консоли Cloudwatch, а также могут быть извлечены с помощью клиента boto3 get_metric_data. Это код, который я использую для публикации моей пользовательской метрики в Cloudwatch:
import boto3
from datetime import datetime
client = boto3.client('cloudwatch')
cloudwatch_response = client.put_metric_data(
Namespace='TestMetricNS',
MetricData=[
{
'MetricName': 'TotalUnprocessed',
'Timestamp': datetime.now(),
'Value': 40,
'Unit': 'Megabytes',
}
]
)
У меня есть следующие файлы yaml для установления внешней метрики и автоскалера hpa в kubernetes:
extMetricCustom.yaml:
apiVersion: metrics.aws/v1alpha1
kind: ExternalMetric
metadata:
name: test-custom-metric
spec:
name: test-custom-metric
resource:
resource: "deployment"
queries:
- id: sqs_test
metricStat:
metric:
namespace: "TestMetricNS"
metricName: "TotalUnprocessed"
period: 60
stat: Average
unit: Megabytes
returnData: true
hpaCustomMetric.yaml
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2beta1
metadata:
name: test-scaler
spec:
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: sqs-consumer
minReplicas: 1
maxReplicas: 4
metrics:
- type: External
external:
metricName: test-custom-metric
targetAverageValue: 2
Когда я оцениваю, правильно ли адаптер Kubernetes Cloudwatch обрабатывает мою пользовательскую метрику (kubectl получает hpa), он всегда показывает, что метрика равна 0:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
test-scaler Deployment/sqs-consumer 0/2 (avg) 1 4 1 161m
Как я могу правильно автоматически масштабировать на основе моей пользовательской метрики Cloudwatch?
Ответ №1:
Работал с OP над этим внеполосным и все еще открывал вкладку для этого вопроса позже в тот же день, поэтому публикую результат здесь для потомков для всех, кто наткнется на него.
Основной причиной проблемы был конфликт часовых поясов. Монитор показателей был основан на «текущих» показателях, но следующая строка из сценария генератора показателей создавала временные метки без указания часового пояса, а также находилась в локальном часовом поясе.
'Timestamp': datetime.now(),
Поскольку для текущего часового пояса не было данных «нет данных» (только данные за X часов в прошлом из-за смещения на -X UTC), система не инициировала масштабирование, поскольку фактически было значение «0» / nil / null. Вместо этого можно указать строку времени UTC, чтобы гарантировать своевременность сгенерированных показателей:
'Timestamp': datetime.utcnow(),
Вторичным соображением было то, что узлам Kubernetes необходим доступ для опроса показателей из CloudWatch. Это делается путем привязки этой политики к роли IAM узлов:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData"
],
"Resource": "*"
}
]
}