基于Custom Metrics API的CoreDns水平扩展

Metrics Server

从Kubernetes 1.8开始，Kubernetes通过Metrics API提供资源使用指标，例如容器CPU和内存使用。这些度量可以由用户直接访问，例如通过使用kubectl top命令，或者由群集中的控制器（例如Horizo​​ntal Pod Autoscaler）使用来进行决策。

root@k8s-master-1:~# kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
192.168.2.10   215m         5%     1679Mi          43%       
192.168.2.11   119m         2%     1383Mi          36%       
192.168.2.12   116m         2%     912Mi           23%       
192.168.2.13   292m         7%     1573Mi          41%   


root@k8s-master-1:~# kubectl top pod
NAME                                    CPU(cores)   MEMORY(bytes)   
kube-resource-report-6d6ddfcfbc-sxg4k   0m           65Mi            
myapp-c78bcd8fb-dt87s                   0m           10Mi            
myapp-envoy-696b6d764d-s8gvs            5m           30Mi

Metrics API

通过Metrics API，您可以获得给定节点或给定pod当前使用的资源量。此API不存储Metrics Value，因此例如在10分钟前获取给定节点使用的资源量是不可能的。

API与任何其他API没有区别：

  • 它可以通过与/apis/metrics.k8s.io/路径下的其他Kubernetes API相同的端点发现
  • 它提供相同的安全性，可扩展性和可靠性保证

API在k8s.io/metrics 存储库中定义。您可以在那里找到有关API的更多信息。

注意： API要求在群集中部署Metrics Server。否则它将无法使用。

Metrics Server

Metrics Server 实现了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

custom-metrics-apiserver 该 API 允许消费者访问通过任意指标描述的 Kubernetes 资源。如果你想实现这个 API Service，这是一个用来实现 Kubernetes 自定义指标的框架。

Horizontal Pod Autoscaler

Horizo​​ntal Pod Autoscaler根据观察到的CPU利用率（或者，通过Custom Metrics API 支持，根据其他一些应用程序提供的指标）自动调整复制控制器，部署或副本集中的pod数 。请注意，Horizo​​ntal Pod Autoscaling不适用于无法缩放的对象，例如DaemonSet。

Horizo​​ntal Pod Autoscaler实现为Kubernetes API资源和控制器。资源确定控制器的行为。控制器会定期调整复制控制器或部署中的副本数，以使观察到的平均CPU利用率与用户指定的目标相匹配。

Horizo​​ntal Pod Autoscaler如何工作

Horizo​​ntal Pod Autoscaler实现为循环监测，其周期由控制器管理器的--horizontal-pod-autoscaler-sync-period标志控制（默认值为15秒）。

在每个期间，控制器管理器根据每个Horizo​​ntalPodAutoscaler定义中指定的度量查询资源利用率。控制器管理器从资源指标API（针对每个窗格资源指标）或自定义指标API（针对所有其他指标）获取指标。

  • 对于每个pod资源指标（如CPU），控制器从Horizo​​ntalPodAutoscaler所针对的每个pod获取资源指标API中的指标。然后，如果设置了目标利用率值，则控制器将利用率值计算为每个容器中容器上的等效资源请求的百分比。如果设置了目标原始值，则直接使用原始度量标准值。然后，控制器在所有目标pod中获取利用率的平均值或原始值（取决于指定的目标类型），并产生用于缩放所需副本数量的比率。

请注意，如果某些pod的容器没有设置相关的资源请求，则不会定义pod的CPU利用率，并且autoscaler不会对该度量标准采取任何操作。有关自动调节算法如何工作的更多信息，请参阅下面的算法详细信息部分。

  • 对于每个pod自定义指标，控制器的功能与每个pod资源指标类似，不同之处在于它适用于原始值，而不是使用值。

  • 对于对象度量和外部度量，将获取单个度量，该度量描述相关对象。将该度量与目标值进行比较，以产生如上所述的比率。在autoscaling/v2beta2API版本中，可以选择在进行比较之前将此值除以pod的数量。

所述Horizo​​ntalPodAutoscaler通常由一系列的API聚集（的获取度量metrics.k8s.io， custom.metrics.k8s.io和external.metrics.k8s.io）。该metrics.k8s.ioAPI通常是通过Metrics Server，其需要单独启动提供。有关说明，请参阅 metrics-server。Horizo​​ntalPodAutoscaler还可以直接从Heapster（从Kubernetes 1.11开始，不推荐从Heapster获取指标。）获取指标。

安装 Metrics Server

安装官方文档 metrics server yaml
创建metrics-server pod

image.png

生成 metrics.k8s.io/v1beta1

image.png

查看 nodes 指标

image.png

查看 pods 指标

image.png

安装Custom Metrics Server

需要在集群内有Prometheus 从中收集指标并将其存储为 Prometheus 时间序列数据库。

安装 custom metrics apiserver 提供的 metrics 来扩展 Kubernetes 自定义指标 API

image.png

基于自定义指标的自动扩容

CoreDns本身也是可以基于cpu负载来做HPA，但是实际测试下来波动较大，所以考虑通过自定义指标来弹性伸缩

CoreDns 作为Kubernetes 1.11版本之后的默认dns插件之后，本身9153端口提供/metrics接口

  • coredns_build_info{version, revision, goversion}- 有关CoreDNS本身的信息。
  • coredns_panic_count_total{} - 恐慌总数。
  • coredns_dns_request_count_total{server, zone, proto, family} - 总查询次数。
  • coredns_dns_request_duration_seconds{server, zone} - 处理每个查询的持续时间。
  • coredns_dns_request_size_bytes{server, zone, proto} - 请求的大小（以字节为单位）。
  • coredns_dns_request_do_count_total{server, zone} - 设置了DO位的查询
  • coredns_dns_request_type_count_total{server, zone, type} - 每个区域和类型的查询计数器。
  • coredns_dns_response_size_bytes{server, zone, proto} - 响应大小（字节）。
  • coredns_dns_response_rcode_count_total{server, zone, rcode} - 每个区域和rcode的响应。
  • coredns_plugin_enabled{server, zone, name} - 指示是否基于每个服务器和区域启用插件。

这次我就利用coredns_dns_request_count_total{server, zone, proto, family} Prometheus adapter（即 custom-metrics-apiserver）删除了 _total 后缀并将该指标标记为 coredns_dns_request_count

从Custom Metrics API 获取每秒的总查询次数：

root@k8s-master-1:~/k8s_manifests# kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/kube-system/pods/*/coredns_dns_request_count" | jq .
{
  "kind": "MetricValueList",
  "apiVersion": "custom.metrics.k8s.io/v1beta1",
  "metadata": {
    "selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/kube-system/pods/%2A/coredns_dns_request_count"
  },
  "items": [
    {
      "describedObject": {
        "kind": "Pod",
        "namespace": "kube-system",
        "name": "coredns-dc8bbbcf9-5jdqc",
        "apiVersion": "/v1"
      },
      "metricName": "coredns_dns_request_count",
      "timestamp": "2019-05-13T08:25:00Z",
      "value": "911m"
    },
    {
      "describedObject": {
        "kind": "Pod",
        "namespace": "kube-system",
        "name": "coredns-dc8bbbcf9-fp7wx",
        "apiVersion": "/v1"
      },
      "metricName": "coredns_dns_request_count",
      "timestamp": "2019-05-13T08:25:00Z",
      "value": "577m"
    }
  ]
}

m 表示 毫，例如，911m 表示911 毫次/每秒

创建一个 HPA，如果请求数超过每秒 1000 次将扩大 coredns 副本数：

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: coredns
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metricName: coredns_dns_request_count
      targetAverageValue: 1000

总结

不是所有的应用都可以适用依靠 CPU 和Memory指标做弹性伸缩来满足系统的负载，大多数 Web 应用的后端都需要基于每秒的请求数量QPS进行弹性伸缩来处理突发流量。而一些 ETL 应用程序，可以通过设置 Job 队列长度超过某个阈值来触发弹性伸缩工作pod。
通过 Prometheus 来监控应用程序并暴露出用于弹性伸缩的指标/metric，可以微调应用程序以更好地处理突发事件，从而确保其高可用性。

参考文档：

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
https://github.com/coredns/coredns/tree/master/plugin/metrics
https://github.com/kubernetes-incubator/metrics-server
https://github.com/DirectXMan12/k8s-prometheus-adapter
https://github.com/coreos/prometheus-operator

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 197,597评论 5赞 462
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 83,053评论 2赞 375
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 144,583评论 0赞 326
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 52,888评论 1赞 267
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 61,772评论 5赞 358
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 46,536评论 1赞 275
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 36,922评论 3赞 388
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 35,554评论 0赞 254
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 39,838评论 1赞 293
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,861评论 2赞 314
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,677评论 1赞 328
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,483评论 3赞 316
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 37,928评论 3赞 300
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,104评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,403评论 1赞 255
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 41,945评论 2赞 343
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 41,156评论 2赞 339