共计 4646 个字符，预计需要花费 12 分钟才能阅读完成。
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/v1
kind: APIService
metadata:
name: v1beta1.metrics.k8s.io
spec:
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 -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
mockmetrics-app-hpa Deployment/mockmetrics-deploy 0/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 56/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 110/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 90/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 126/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 306/100 1 10 2 11h
mockmetrics-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 运维解决方案，简化、现代化并减速企业数字化转型，推动翻新无处不在。