如何为Kubernetes配置Pod水平自动扩展

干货教程！教你如何在K8S上实现根据CPU等实际使用量与用户的指望值进行比对，实现部署的自动扩展和缩减！

---

介 绍

Kubernetes有一个强大的功能，它能在运行的服务上进行编码并配置弹性伸缩。若是没有弹性伸缩功能，就很难适应部署的扩展和知足SLAs。这一功能称为Horizontal Pod Autoscaler (HPA)。

为何使用HPA

使用HPA，您能够根据资源的使用状况或者自定义的指标，实现部署的自动扩展和缩减，让部署的规模接近于实际服务的负载。

HPA能够为您的服务带来两个直接的帮助：

1. 在须要计算和内存资源时提供资源，在不须要时释放它们

2. 按需增长/下降性能以实现SLA

HPA工做原理

HPA会根据监测到的CPU/内存利用率（资源指标），或基于第三方指标应用程序（如Prometheus、Datadog等）提供的自定义指标，自动调整副本控制器、部署或者副本集合的pods数量（定义最小和最大pods数）。HPA是一种控制回路，它的周期由Kubernetes的controller manager –horizontal-pod-autoscaler-sync-period标志控制（默认值是30s）。

HPA定义

HPA是Kubernetes中弹性伸缩API组下的一个API资源。当前稳定的版本是autoscaling/v1，它只提供了对CPU自动缩放的支持。若是您想额外得到对内存和自定义指标的支持，可使用Beta版本autoscaling/v2beta1。

您能够在HPA API对象中看到更多信息：https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object

在通常状况下HPA是由kubectl来提供支持的。可使用kubectl进行建立、管理和删除：

建立HPA：

• 带有manifest: kubectl create -f <HPA_MANIFEST>

• 没有manifest(只支持CPU)：kubectl autoscale deployment hello-world –min=2 --man=5 –-cpu-percent=50

获取hpa信息:

• 基本信息: kubectl get hpa hello-world

• 细节描述: kubectl describe hpa hello-world

删除hpa:

• kubectl delete hpa hello-world

下面是一个HPA manifest定义的例子：

这里使用了autoscaling/v2beta1版本，用到了cpu和内存指标

• 控制hello-world项目部署的自动缩放

• 定义了副本的最小值1

• 定义了副本的最大值10

• 当知足时调整大小：

  CPU使用率超过50%

  内存使用超过100Mi

安 装

在HPA能够在Kubernetes集群上使用以前，有一些元素须要在系统中安装和配置。

需 求

检查肯定Kubernetes集群服务正在运行而且至少包含了这些标志:

• kube-api: requestheader-client-ca-file

• kubelet: read-only-port 在端口10255

• kube-controller: 可选，只在须要和默认值不一样时使用

• horizontal-pod-autoscaler-downscale-delay:”5m0s”

• horizontal-pod-autoscaler-upscale-delay:”3m0s”

• horizontal-pod-autoscaler-sync-period: “30s”

对于RKE，Kubernetes集群定义，请肯定您已经在服务部分添加了这些行。若是要在Rancher v2.0.X UI中执行此操做，请打开”Cluster options”- “Edit as YAML”并添加下面的定义：

要部署指标服务，您的Kubernetes集群必需要正确配置和部署。

注意：在部署和测试示例时，本文使用的是Rancher v2.0.6以及k8s v1.10.1集群

资源指标

若是HPA想要使用资源指标，那么就须要用到metrics-server包了，它在Kubernetes集群中的kube-system命名空间里。

按照下面的步骤实现：

1. 配置kubectl链接到正确的Kubernetes集群

2. 克隆metrics-server的Github仓库：git clone https://github.com/kubernetes-incubator/metrics-server

3. 安装metrics-server包（假设Kubernetes升级到了1.8）:kubectl create -f metrics-server/deply/1.8+/

4. 检查metrics-server是否运行正常。在命名空间kube-system能够检查服务pod以及日志

5. 检查是否能够从kubectl访问指标API：若是您要直接访问Kubernetes集群，请使用kubectl config的服务器URL，好比‘https://:6443’

若是您想经过Rancher访问Kubernetes集群，那么kubectl config的服务器URL就要像：https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>，即你还要在本来的

API路径后面加上/k8s/clusters/<CLUSTER_ID>

自定义指标（Prometheus）

自定义指标做为一种资源，能够由许多第三方应用程序提供。咱们准备在演示中使用Prometheus。假设Prometheus已经部署在您的Kubernetes集群中了，它能够从pods、节点、命名空间等等地方得到正确的指标，咱们将使用Prometheus url，http://prometheus.mycompany.io，它公开于端口80。

Prometheus能够在Rancher v2.0目录中部署。若是在Kubernetes集群上没有运行，那么就在Rancher目录中部署它。

若是HPA想要使用Prometheus中的自定义指标，那么Kubernetes集群上的kube-system命名空间则须要用到k8s-prometheus-adapter。为了方便k8s-prometheus-adapter的安装，咱们将使用banzai-charts提供的Helm chart。

经过下面的步骤可使用这一chart：

1. 在k8s集群上初始化helm

2. 从Github仓库克隆banzai-charts：

3. 安装prometheus-adapter，指定具体的Prometheus URL和端口

4. 检查prometheus-adapter是否运行正常。检查服务pod和日志是在kube-system命名空间下

5. 检查指标API是否能够从kubectl进行访问：直接访问Kubernetes集群，那么kubectl config的服务器URL就好比https://<K8s_URL>:6443

若是是从Rancher进行访问，那么kubectl config的服务器URL就是https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>，须要加上后缀/k8s/clusters/<CLUSTER_ID>

ClusterRole和ClusterRoleBinding

默认状况下，HPA将尝试经过用户的system:anonymous读取（系统的和自定义的）指标。用户须要定义view-resource-metrics以及view-custom-metrics，而ClusterRole和ClusterRoleBinding将它们分配给system:anonymous来打开对指标的读取访问。

要实现这一点，须要下面的步骤：

1. 配置kubectl正确链接到k8s集群

2. 复制ClusterRole和ClusterRoleBinding文件：

在Kubernetes集群上建立它们（若是你想使用自定义指标的话）：

服务部署

为了让HPA正常工做，服务部署应该要有容器的资源请求定义。

咱们用一个hello-world的例子来测试一下HPA是否正常工做。

咱们根据下面步骤进行，第一步，正确配置kubectl链接到k8s集群，第二步，复制hello-world的部署文件。

1. 在k8s集群上部署它

2. 为资源或者自定义指标复制HPA

3. 资源指标：

``` apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: hello-world namespace: default spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: hello-world minReplicas: 1 maxReplicas: 10 metrics:

• type: Resource resource:name: cpu targetAverageUtilization: 50

• type: Resource resource: name: memory targetAverageValue: 1000Mi

• 自定义指标（和资源指标同样，不过须要添加自定义的cpu_system指标）

4. 得到HPA信息和描述，而且检查资源指标是否已经显示出来：

资源指标：

自定义指标：

5. 给咱们的服务产生负载，进行弹性伸缩的测试。这里可使用各类各样的工具（产生负载），不过这里咱们使用https://github.com/rakyll/hey 向hello-world服务发出http请求，并观察弹性伸缩是否正常工做

6. 观察自动的扩缩容

• 资源指标：

• 当cpu利用率达到目标比例时，自动扩展到2个pods

当cpu使用率达到目标值horizontal-pod-autoscaler-upscale-delay默认超过3分钟时，扩展到3个pods：

当cpu使用率降到目标值horizontal-pod-autoscaler-downscale-delay默认超过5分钟时，缩小到1个pods：

自定义指标：

• 当cpu利用率达到目标时扩展到2个pods：

当cpu_system利用率限制达到目标值，扩展到3个pods：

当cpu利用率限制达到目标值horizontal-pod-autoscaler-upscale-delay超过3分钟（默认），扩展到4个pods：

当全部的指标都低于目标值horizontal-pod-autoscaler-downscale-delay 超过5分钟，自动缩小到1个pods：

总 结

咱们看到了如何在Rancher上使用Kubernetes HPA来进行部署的弹性扩缩容。这是一个很是出色好用的功能，可让部署的规模适应于实际的服务负载而且实现服务SLA。

咱们还看到，如何在kube-controller上对horizontal-pod-autoscaler-downscale-delay (默认5分钟)和 horizontal-pod-autoscaler-upscale-delay (默认3分钟) 进行参数化，调整扩缩容的反应。

对于咱们的自定义指标，咱们在例子cpu_system中进行了展现，不过咱们还可使用全部导出给Prometheus的指标，并了解当前服务的性能，好比http_request_number、http_response_time等等。

为了让以后HPA更容易使用，咱们如今正努力将metric-server做为插件集成到RKE集群部署中。它如今已经包含在RKE v0.1.9-rc2中进行测试，目前还还没有获得官方的支持。它会在RKE v0.1.9版本中获得支持。