内容简介:转:从 Kubernetes 1.8 开始,资源使用指标(如容器 CPU 和内存使用率)通过 Metrics API 在 Kubernetes 中获取。这些指标可以直接被用户访问(例如通过使用 kubectl top 命令),或由集群中的控制器使用(例如,Horizontal Pod Autoscale
转: https://blog.csdn.net/yevvzi/article/details/79561150
核心指标管道
从 Kubernetes 1.8 开始,资源使用指标(如容器 CPU 和内存使用率)通过 Metrics API 在 Kubernetes 中获取。
这些指标可以直接被用户访问(例如通过使用 kubectl top 命令),或由集群中的控制器使用(例如,Horizontal Pod Autoscale
可以使用这些指标作出决策)。
Resource Metrics API
通过 Metrics API,您可以获取指定 node 或 pod 当前使用的资源量。这个 API 不存储指标值,
因此想要获取某个指定 node 10 分钟前的资源使用量是不可能的。
Metrics API 和其他的 API 没有什么不同:
它可以通过与 /apis/metrics.k8s.io/ 路径下的其他 Kubernetes API 相同的端点来发现
它提供了相同的安全性、可扩展性和可靠性保证
Metrics API 在 k8s.io/metrics 仓库中定义。您可以在这里找到关于Metrics API 的更多信息。
注意: Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
Metrics Server
Metrics Server 实现了Resource Metrics API
Metrics Server 是集群范围资源使用数据的聚合器。
从 Kubernetes 1.8 开始,它作为一个 Deployment 对象默认部署在由 kube-up.sh 脚本创建的集群中。
如果您使用了其他的 Kubernetes 安装方法,您可以使用 Kubernetes 1.7+ (请参阅下面的详细信息)
中引入的 deployment yamls 文件来部署。
Metrics Server 从每个节点上的 Kubelet 公开的 Summary API 中采集指标信息。
通过在主 API server 中注册的 Metrics Server Kubernetes 聚合器 来采集指标信息, 这是在 Kubernetes 1.7 中引入的。
在 设计文档 中可以了解到有关 Metrics Server 的更多信息。
custom metrics api
该API允许消费者访问任意度量描述Kubernetes资源。
API的目的是通过监测管道供应商,在其度量存储解决方案之上实现。
如果你想实现这个API API服务器,请参阅kubernetes-incubator/custom-metrics-apiserver库,其中包含需要建立这样一个API服务器基础设施
其中包含设置这样一个API服务器所需的基本基础设施。
Import Path: k8s.io/metrics/pkg/apis/custom_metrics.
custom metrics apiserver
custom metrics apiserver是为了实现k8s自定义监控指标
的框架。
HPA
自动伸缩是一种根据资源使用情况自动伸缩工作负载的方法。
自动伸缩在Kubernetes中有两个维度:cluster Autoscaler处理节点扩容操作和Horizontal Pod Autoscaler自动缩放rs或rc中的pod。
cluster Autoscaler和Horizontal Pod Autoscaler一起可用于动态调整的计算能力以及并行性的水平,你的系统需要满足sla。
虽然cluster Autoscaler高度依赖于托管集群的云提供商的底层功能,但是HPA可以独立于您的IaaS/PaaS提供商进行操作。
在Kubernetes v1.1中首次引入了hpa特性,自那时起已经有了很大的发展。
hpa第一个版本基于观察到的CPU利用率,后续版本支持基于内存使用。
在Kubernetes 1.6中引入了一个新的API自定义指标API,它允许HPA访问任意指标。
Kubernetes 1.7引入了聚合层,允许第三方应用程序通过注册为API附加组件来扩展Kubernetes API。
自定义指标API以及聚合层使得像Prometheus这样的监控系统可以向HPA控制器公开特定于应用程序的指标。
hpa 实现了一个控制环,可以周期性的从资源指标API查询特定应用的CPU/MEM信息。
image.png
实战
以下是关于Kubernetes 1.9或更高版本的HPA v2配置的分步指南。您将安装提供核心指标的度量服务器附加组件,
然后您将使用一个演示应用程序来展示基于CPU和内存使用的pod自动伸缩。在指南的第二部分,
您将部署Prometheus和一个自定义API服务器。您将使用聚合器层注册自定义API服务器,然后使用演示应用程序提供的自定义度量配置HPA。
前提
- go 1.8+
- clone k8s-prom-hpa repo
cd $GOPATH git clone https://github.com/stefanprodan/k8s-prom-hpa
安装 Metrics Server
Kubernetes Metrics Server是一个集群范围的资源使用数据聚合器,是Heapster的继承者。
metrics服务器通过从kubernet.summary_api收集数据收集节点和pod的CPU和内存使用情况。
summary API是一个内存有效的API,用于将数据从Kubelet/cAdvisor传递到metrics server。
image.png
如果在v1版本的HPA中,您将需要Heapster提供CPU和内存指标,在HPA v2和Kubernetes 1.8中,
只有度量服务器是需要的,而水平-pod-autoscaler-use-rest-客户机是打开的。
在Kubernetes 1.9中默认启用HPA rest客户端。GKE 1.9附带了预先安装的指标服务器。
在 kube-system
命名空间总部署metrics-server
kubectl create -f ./metrics-server
一分钟后,度量服务器开始报告节点和荚的CPU和内存使用情况。
查看nodes指标
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq .
查看pod指标
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq .
基于CPU和内存使用的自动缩放
你将使用一个基于golang的小程序测试hpa.
部署podinfo到默认命名空间
kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml
在 http://<K8S_PUBLIC_IP>:31198
通过nodeport访问podinfo
接下来定义一个HPA,保持最小两个副本和最大十个如果CPU平均超过80%或如果内存超过200mi。
apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: podinfo spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: podinfo minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu targetAverageUtilization: 80 - type: Resource resource: name: memory targetAverageValue: 200Mi
创建HPA
kubectl create -f ./podinfo/podinfo-hpa.yaml
几秒钟之后,HPA控制器与metrics server联系,然后取出CPU和内存使用情况。
kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE podinfo Deployment/podinfo 2826240 / 200Mi, 15% / 80% 2 10 2 5m
为了提高CPU使用率、运行 rakyll/hey
进行压力测试
#install hey go get -u github.com/rakyll/hey #do 10K requests hey -n 10000 -q 10 -c 5 http://<K8S_PUBLIC_IP>:31198/
你可以通过以下命令获取HPA event
$ kubectl describe hpa Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 7m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target
先将 podinfo
移除一会儿,稍后将再次部署:
kubectl delete -f ./podinfo/podinfo-hpa.yaml,./podinfo/podinfo-dep.yaml,./podinfo/podinfo-svc.yaml
安装Custom Metrics Server
为了根据custom metrics进行扩展,您需要有两个组件。一个从应用程序中收集指标并将其存储为Prometheus时间序列数据库的组件。
第二个组件将Kubernetes自定义指标API扩展到由收集的k8s-prometheus-adapter提供的指标。
image.png
您将在专用命名空间中部署Prometheus和adapter。
创建 monitoring
命名空间
kubectl create -f ./namespaces.yaml
将 Prometheus v2部署到monitoring命名空间:
如果您部署到GKE,您可能会得到一个错误:从服务器(禁止)中出错:创建这个错误将帮助您解决这个问题:RBAC on GKE。
kubectl create -f ./prometheus
生成由Prometheus adapter所需的TLS证书:
make certs
部署Prometheus自定义api适配器
kubectl create -f ./custom-metrics-api
列出由prometheus提供的自定义指标:
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
获取monitoring命名空间中所有pod的FS信息:
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytes" | jq .
基于自定义指标的自动扩容
创建podinfo nodeport服务并在default命名空间中部署:
kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml
podinfo应用程序的暴露了一个自定义的度量http_requests_total。普罗米修斯适配器删除_total后缀标记度量作为一个计数器度量
从自定义度量API获取每秒的总请求数:
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests" | jq .
{ "kind": "MetricValueList", "apiVersion": "custom.metrics.k8s.io/v1beta1", "metadata": { "selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/http_requests" }, "items": [ { "describedObject": { "kind": "Pod", "namespace": "default", "name": "podinfo-6b86c8ccc9-kv5g9", "apiVersion": "/__internal" }, "metricName": "http_requests", "timestamp": "2018-01-10T16:49:07Z", "value": "901m" }, { "describedObject": { "kind": "Pod", "namespace": "default", "name": "podinfo-6b86c8ccc9-nm7bl", "apiVersion": "/__internal" }, "metricName": "http_requests", "timestamp": "2018-01-10T16:49:07Z", "value": "898m" } ] }
m
代表 milli-units
,例如, 901m
意味着 milli-requests
。
创建一个HPA,如果请求数超过每秒10当将扩大podinfo数量:
apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: podinfo spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: podinfo minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metricName: http_requests targetAverageValue: 10
在default命名空间部署podinfo HPA:
kubectl create -f ./podinfo/podinfo-hpa-custom.yaml
过几秒钟HPA从标准的API取得http_requests的值:
kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE podinfo Deployment/podinfo 899m / 10 2 10 2 1m
用25每秒请求数给podinfo服务加压
#install hey go get -u github.com/rakyll/hey #do 10K requests rate limited at 25 QPS hey -n 10000 -q 5 -c 5 http://<K8S-IP>:31198/healthz
几分钟后,HPA开始扩大部署。
kubectl describe hpa Name: podinfo Namespace: default Reference: Deployment/podinfo Metrics: ( current / target ) "http_requests" on pods: 9059m / 10 Min replicas: 2 Max replicas: 10 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 2m horizontal-pod-autoscaler New size: 3; reason: pods metric http_requests above target
以每秒当前的请求速率,部署将永远无法达到10个荚的最大值。三副本足以让RPS在10每pod.
负载测试结束后,HPA向下扩展部署到初始副本。
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 3; reason: pods metric http_requests above target Normal SuccessfulRescale 21s horizontal-pod-autoscaler New size: 2; reason: All metrics below target
你可能已经注意到,自动定标器不使用峰值立即做出反应。默认情况下,指标每30秒同步一次,
并且扩展/收缩当3-5分钟没有重新扩展发生变化时。在这种方式中,HPA防止快速执行并保留了指标生效时间
总结
不是所有的系统都可以依靠CPU/内存使用指标单独满足SLA,大多数Web和移动后端需要以每秒请求处理任何突发流量进行自动缩放。
对于ETL应用程序,可能会由于作业队列长度超过某个阈值而触发自动缩放,等等。
通过prometheus检测你应用程序的正确指,并为自动是很所提供正确指标,您可以微调您的应用程序更好地处理突发和确保高可用性。
参考
https://github.com/kubernetes/metrics
https://github.com/kubernetes-incubator/custom-metrics-apiserver
https://github.com/kubernetes-incubator/metrics-server
https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/
以上所述就是小编给大家介绍的《K8s -- 通过自定义prometheus数据实现k8s hpa》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 【自定义】通过Dockerfile创建httpd镜像
- Android 通过DrawableInflater加载自定义Drawable 原 荐
- 通过Spring Boot中的手动Bean定义提高启动性能
- 通过昨晚的 Build 2017 大会,微软用「云」+「AI」重新定义自己
- k8s与HPA--通过 Prometheus adaptor 来自定义监控指标
- 通过 CSS自定义属性(CSS变量)和 JavaScript 实现高级CSS主题切换
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
算法交易与套利交易
赵胜民 / 厦门大学出版社 / 2010-9 / 35.00元
《算法交易与套利交易》主要介绍算法交易和一些套利交易的策略,以便于读者对相关方面的内容进行阅读和学习。在《算法交易与套利交易》的第一部分,我们回顾了投资学一些相关的基本内容。其中,前两章介绍了证券投资的收益和风险等特征,以及马可维茨的最优资产配置模型。第3章则介绍了股票投资分析当中常用的资本资产定价模型(CAPM)、套利定价模型(APT),以及因素模型。然后,第4、5章分别讲到了金融证券估值模型、......一起来看看 《算法交易与套利交易》 这本书的介绍吧!