Kubernetes主动弹性伸缩能够依据业务流量，主动减少或缩小服务。这一性能在理论的业务场景中非常重要。在本文中，咱们将理解Kubernetes如何针对利用产生的自定义指标实现主动伸缩。

为什么须要自定义指标？

应用程序的CPU或RAM的耗费并不一定可能正确表明是否须要进行扩大。例如，如果你有一个音讯队列consumer，它每秒能够解决500条音讯而不会导致解体。一旦该consumer的单个实例每秒解决靠近500条音讯，你可能心愿将应用程序扩大到两个实例，以便将负载散布在两个实例上。测量CPU或RAM对于扩大这样的应用程序来说有点矫枉过正了，你须要寻找一个与应用程序性质更为密切相关的指标。一个实例在特定工夫点解决的音讯数量能更贴切地反映该利用的理论负载。同样，可能有一些利用的其余指标更有意义。这些能够应用Kubernetes中的自定义指标进行定义。

Metrics流水线

Metrics Server和API

最后，这些指标会通过Heapster裸露给用户，Heapster能够从每个kubelet中查问指标。Kubelet则与localhost上的cAdvisor对话，并检索出节点级和pod级的指标。Metric-server的引入是为了取代heapster，并应用Kubernetes API来裸露指标从而以Kubernetes API的形式提供指标。Metric server仅提供外围的指标，比方pod和节点的内存和CPU，对于其余指标，你须要构建残缺的指标流水线。构建流水线和Kubernetes主动伸缩的机制将会放弃不变。

Aggregation Layer

可能通过Kubernetes API层裸露指标的要害局部之一是Aggregation Layer。该aggregation layer容许在集群中装置额定的Kubernetes格局的API。这使得API像任何Kubernetes资源一样可用，但API的理论服务能够由内部服务实现，可能是一个部署到集群自身的Pod（如果没有在集群级别实现，你须要启用aggregation layer）。那么，这到底是如何发挥作用的呢？作为用户，用户须要提供API Provider（比方运行API服务的pod），而后应用APIService对象注册雷同的API。

让咱们以外围指标流水线为例来阐明metrics server如何应用 API Aggregation layer注册本人。APIService对象如下：

apiVersion: apiregistration.k8s.io/v1kind: APIServicemetadata:  name: v1beta1.metrics.k8s.iospec:  service:    name: metrics-server    namespace: kube-system  group: metrics.k8s.io  version: v1beta1  insecureSkipTLSVerify: true  groupPriorityMinimum: 100  versionPriority: 100

部署应用APIService注册API的metrics server之后，咱们能够看到Kubernetes API中提供了指标API：

Metrics流水线：外围局部和残缺流水线

咱们曾经理解了根本组件，让咱们把它们放在一起组成外围metrics流水线。在外围流水线中，如果你曾经失当地装置了metrics server，它也将创立APIService将本人注册到Kubernetes API server上。正如咱们在上一节中所理解到的那样，这些指标将在/apis/metrics.k8s.io中裸露，并被HPA应用。

大部分简单的应用程序须要更多的指标，而不仅仅是内存和CPU，这也是大多数企业应用监控工具的起因，最常见的监控工具有Prometheus、Datadog以及Sysdig等。而不同的工具所应用的格局也有所区别。在咱们能够应用Kubernetes API聚合来裸露endpoint之前，咱们须要将指标转换为适合的格局。此时须要应用小型的adapter（适配器）——它可能是监控工具的一部分，也可能作为一个独自的组件，它在监控工具和Kubernetes API之间架起了一座桥梁。例如，Prometheus有专门的Prometheus adapter或者Datadog有Datadog Cluster Agent — 它们位于监控工具和API之间，并从一种格局转换到另一个种格局，如下图所示。这些指标在略微不同的endpoint都能够应用。

Demo：Kubernetes主动伸缩

咱们将演示如何应用自定义指标主动伸缩应用程序，并且借助Prometheus和Prometheus adapter。你能够持续阅读文章，或者间接拜访Github repo开始构建demo：

https://github.com/infracloud...

设置Prometheus

为了让适配器能够应用指标，咱们将应用Prometheus Operator来装置Prometheus。它创立CRD来在集群中部署Prometheus的组件。CRD是扩大Kubernetes资源的一种形式。应用Operator能够“以Kubernetes的形式”（通过在YAML文件中定义对象）轻松配置和保护Prometheus实例。由Prometheus Operator创立的CRD有：

  • AlertManager
  • ServiceMonitor
  • Prometheus

你能够依据下方链接的领导设置Prometheus：

https://github.com/infracloud...

部署Demo应用程序

为了生成指标，咱们将部署一个简略的应用程序mockmetrics，它将在/metrics处生成total_hit_count值。这是一个用Go写的网络服务器。当URL被拜访时，指标total_hit_count的值会一直减少。它应用Prometheus所要求的展现格局来显示指标。

依据以下链接来为这一应用程序创立deployment和服务，它同时也为应用程序创立ServiceMonitor和HPA：

https://github.com/infracloud...

ServiceMonitor

ServiceMonitor为Prometheus创立了一个配置。它提到了服务的标签、门路、端口以及应该在什么时候抓取指标的工夫距离。在服务label的帮忙下，抉择了pods。Prometheus会从所有匹配的Pod中抓取指标。依据你的Prometheus配置，ServiceMonitor应该放在相应的命名空间中。在本例中，它和mockmetrics 在同一个命名空间。

部署和配置Prometheus Adapter

当初要为HPA提供custom.metrics.k8s.io API endpoint，咱们将部署Prometheus Adapter。Adapter心愿它的配置文件在Pod中可用。咱们将创立一个configMap并将其挂载在pod外部。咱们还将创立Service和APIService来创立API。APIService将/api/custom.metrics.k8s.io/v1beta1 endpoint增加到规范的Kubernetes APIs。你能够依据以下教程来实现这一指标：

https://github.com/infracloud...

接下来，咱们看一下配置：

  • seriesQuery用于查问Prometheus的资源，标签为“default“和”mockmetrics-service“。
  • resources局部提到标签如何被映射到Kubernetes资源。针对咱们的状况，它将“namespace“标签与Kubernetes的”namespace“进行映射，服务也是如此。
  • metricsQuery又是一个Prometheus查问，它能够将指标导入adapter。咱们应用的查问是获取2分钟内所有匹配regexmockmetrics-deploy-(.*)的pods的均匀total_hit_count总和。

Kubernetes主动伸缩实际

一旦你依据下文中的步骤进行，指标值会一直减少。咱们当初就来看HPA：

https://github.com/infracloud...

$ kubectl get hpa -wNAME                  REFERENCE                       TARGETS   MINPODS   MAXPODS   REPLICAS   AGEmockmetrics-app-hpa   Deployment/mockmetrics-deploy   0/100     1         10        1          11hmockmetrics-app-hpa   Deployment/mockmetrics-deploy   56/100    1         10        1          11hmockmetrics-app-hpa   Deployment/mockmetrics-deploy   110/100   1         10        1          11hmockmetrics-app-hpa   Deployment/mockmetrics-deploy   90/100    1         10        2          11hmockmetrics-app-hpa   Deployment/mockmetrics-deploy   126/100   1         10        2          11hmockmetrics-app-hpa   Deployment/mockmetrics-deploy   306/100   1         10        2          11hmockmetrics-app-hpa   Deployment/mockmetrics-deploy   171/100   1         10        4          11h

你能够看到当该值达到目标值时，正本数如何减少。

工作流程

主动伸缩的整体流程如下图所示：

图片起源: luxas/kubeadm-workshop

结 论

你能够从下方链接中理解更多相干我的项目和参考资料。在过来的几个版本中，Kubernetes中的监控流水线曾经大有倒退，而Kubernetes的主动伸缩次要基于该流水线工作。如果你不相熟这个环境，很容易感到困惑和迷茫。

https://github.com/infracloud...

原文链接：https://dzone.com/articles/ku...

About SUSE Rancher

Rancher是一个开源的企业级Kubernetes治理平台，实现了Kubernetes集群在混合云+本地数据中心的集中部署与治理。Rancher一贯因操作体验的直观、极简备受用户青眼，被Forrester评为“2020年多云容器开发平台领导厂商”以及“2018年寰球容器治理平台领导厂商”，被Gartner评为“2017年寰球最酷的云基础设施供应商”。

目前Rancher在寰球领有超过三亿的外围镜像下载量，并领有包含中国联通、中国安全、中国人寿、上汽团体、三星、施耐德电气、西门子、育碧游戏、LINE、WWK保险团体、澳电讯公司、德国铁路、厦门航空、新东方等寰球驰名企业在内的共40000家企业客户。

2020年12月，SUSE实现收买RancherLabs，Rancher成为了SUSE “翻新无处不在（Innovate Everywhere）”企业愿景的要害组成部分。SUSE和Rancher独特为客户提供了无可比拟的自在和所向无敌的创新能力，通过混合云IT基础架构、云原生转型和IT运维解决方案，简化、现代化并减速企业数字化转型，推动翻新无处不在。