定制JFrog x射线水平Pod自动缩放器

在云原生计算中(Kubernetes在我们的例子中)，需要自动扩展用于执行任务的计算资源。2022世界杯阿根廷预选赛赛程的自动定量云计算策略允许动态调整活动的应用服务器数量和分配的资源，而不是手动实时响应需要更多资源和实例的流量激增。2022世界杯阿根廷预选赛赛程

的执掌图表用于安装JFrog x射线利用的水平吊舱自动缩放器(HPA)，这是基于CPU利用率。这意味着，如果x射线应用程序的CPU使用率超过了指定的阈值，HPA将启动额外的pod来协助并更平均地分配负载。当总CPU消耗低于某个阈值时，HPA将相应地减少pod的数量。

然而，这种自动伸缩方法有两个主要缺点:

1. 自动缩放仅在CPU消耗达到或超过给定阈值时才会发生，这与更主动的策略(预测未来的资源增加并提前扩展)相比效率较低，这可能会缩短x射线扫描持续时间，因为已有更多的计算能力可用。
2. 一些应用程序特性，例如x射线DB同步，是单线程的，不能从集群中的其他应用程序节点中获益。如果这些特性导致CPU使用率上升，就会发生不必要的扩展，从而导致本可以避免的费用增加。

为了改进这一点，我们可以根据特定的应用程序指标(而不是一般的资源利用率)定制自动伸缩。

这篇博文将描述如何使用一种先进的方法来实现自定义度量HPA，以改善JFrog Xray在Kubernetes中的缩放。

使用自定义度量

JFrog x射线功能OpenMetrics API在其他指标中，其中包括的大小Xray RabbitMQ队列．当正确评估时，队列大小可以直接与当前和潜在的资源利用率相关。这意味着，如果我们基于特定的队列(Indexer, Persist & Analysis)自动扩展，我们可以预测未来资源需求的增长，并提前扩展pod。为了避免不必要的扩展，我们不会对任何不能从扩展中受益的指标或队列执行自动扩展。

Kubernetes支持自定义度量缩放对于HPA，这意味着我们应该为HPA找到一种策略来访问Xray API端点并利用它提供的指标。

开发解决方案

默认的Kubernetes Metrics Server不能直接连接到HTTP端点(如Xray API)来检索数据，这意味着需要另一个组件来从Xray获取数据并允许HPA访问它。而不是开发一个全新的指标服务器，我们可以看到有现有的适配器可以充当度量服务器并链接自定义应用程序和hpa。

其中一个适配器称为“prometheus-adapter”可以用来使hpa根据存储在已存在的指标自动伸缩普罗米修斯实例。

架构如下:

首先，我们将部署。kube-prometheus-stack'到K8s集群，并配置一个刮作业，通过' / Xray /api/v1/metrics '定期1秒间隔向Xray发送一个认证请求，并在本地存储度量:

prometheus: prometheusSpec: serviceMonitorSelectorNilUsesHelmValues: false additionalScrapeConfigs: - job_name: 'xray-metrics' metrics_path: '/xray/api/v1/metrics' scrape_interval: 1s honor_labels: true static_configs: - targets: ['xray:8082'] labels: pod: 'xray-0' authorization: credentials: ""

接下来，我们将部署和配置' Prometheus -adapter '，并确认它可以从Prometheus操作符中提取指标:

prometheus: url: http://prometheus-operator-kube-p-prometheus rules: default: false custom:—seriesQuery: 'queue_messages_total{queue_name="index"}' re2022世界杯阿根廷预选赛赛程sources: {template: "<<。资源>>"}name: matches: "^(.*)" as: "index" # HPA将使用的指标名称metricsQuery: 'queue_messages_total{queue_name="index"}' #查询被发送到prometheus-operator > http://localhost:9090/api/v1/query?query=

$ kubectl get——raw="/apis/custom.metrics.k8s.io/v1beta1/namespaces/project/pods/*/index . txt /api /custom.metrics.k8s.io/v1beta1/namespaces/project/pods/*/index . txt

最后，我们将构建一个HPA，并将其设置为基于适配器托管的度量标准:

规格:scaleTargetRef: apiVersion: apps/v1 kind: StatefulSet名称:xray minReplicas: 1 maxReplicas: 10 metrics: - type: Pods Pods: metric: name: index target: type: AverageValue AverageValue: "100"

结论

基于RabbitMQ索引队列中100条消息的平均值，上面的HPA自动将Xray pods从1扩展到10。这意味着如果消息队列小于100,Xray将有一个pod，如果队列超过500，则有五个pod，依此类推。

使用这种定制的配置，新的HPA可以在选择的RabbitMQ队列的大小增加后识别传入的x射线流量，并在早期扩展节点，为即将到来的工作负载做好准备。与现有的基于cpu的HPA相比，这减少了x射线扫描工件所需的时间。

此外，现有的基于cpu的HPA在DB同步后可以扩展到4个额外的pod，而新的度量HPA不会在DB同步或类似的单线程操作后执行任何自动伸缩。这意味着不会因为不必要的计算能力增加而产生进一步的费用。