定制JFrog x射线水平Pod自动缩放器
在云原生计算(Kubernetes在我们的示例中，需要自动缩放用于执行任务的计算资源。2022世界杯阿根廷预选赛赛程的自动定量云计算策略允许动态调整应用程序服务器的活动数量和分配的资源，而不是手动实时响应需要更多资源和实例的流量激增。2022世界杯阿根廷预选赛赛程
的执掌图表用于安装JFrog Xray利用的水平Pod自动缩放器(HPA)，它基于CPU利用率。这意味着，如果Xray应用程序的CPU使用率超过指定的阈值，HPA将启动额外的pod，以帮助更平均地分配负载。当CPU总消耗低于一定阈值时，HPA会相应减少pod的数量。
然而，这种自动缩放方法有两个主要缺点:
- 自动缩放仅在CPU消耗达到或超过给定阈值时才会发生，与预测未来资源增加并提前缩放的更主动的策略相比，这种策略效率较低，因为更多的计算能力已经可用，因此可能缩短x射线扫描持续时间。
- 一些应用程序特性，例如x射线DB同步，是单线程的，不能从集群中的其他应用程序节点中获益。如果这些特性导致CPU使用量增加，就会出现不必要的扩展，从而导致本可以避免的费用增加。
为了改进这一点，我们可以根据特定的应用程序指标定制自动缩放，而不是根据一般的资源利用率。
这篇博文将描述如何使用一种高级方法实现自定义度量HPA来改进JFrog Xray在Kubernetes中的缩放。
使用自定义指标
JFrog Xray的特点是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规则:default: false自定义:- seriesQuery: 'queue_messages_total{queue_name="index"}' resources:2022世界杯阿根廷预选赛赛程 {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 . .最后，我们将构建一个HPA，并根据适配器承载的指标将其设置为缩放:
spec: scaleTargetRef: apiVersion: apps/v1 kind: StatefulSet name: xray minReplicas: 1 maxReplicas: 10 metrics: - type: Pods Pods: metric: name: index target: type: AverageValue AverageValue: "100"结论
基于RabbitMQ索引队列中100条消息的平均值，上面的HPA自动将x射线pod从1缩放到10。这意味着如果消息队列少于100,Xray将有一个pod，如果队列超过500，则有五个pod，依此类推。
使用这种自定义配置，新的HPA可以识别随着所选RabbitMQ队列的大小增加而传入的x射线流量，并提前扩展节点，为即将到来的工作负载做准备。与现有的基于cpu的HPA相比，这减少了x射线扫描工件所需的时间。
此外，虽然现有的基于cpu的HPA在DB同步后可以扩展到4个额外的pod，但新的指标HPA在DB同步或类似的单线程操作后不会执行任何自动扩展。这意味着不会因不必要的计算能力增加而产生额外的费用。
