Day17-Kubernetes 那些事 - Auto Scaling

前言

之前的文章介绍了如何利用 ReplicaSet 或 Replication Controller 来建立多个 Pod，但这些都是写死的设定，没办法根据当前状况而有变动，通常一个应用程序会有所谓的尖峰期以及离峰期，假如我们都是用这种死板板的方式来建立多个 Pod，那岂不就要根据时间重新设定 Replica 吗？这样真的太累了所以今天笔者要来介绍如何利用 K8s 自身的功能来达到自动生成 Pod 的效果。

Scaling

首先要来介绍一个专业术语：Scaling，Scaling 代表的是缩放的意思，一般来说 Scaling 有分水平缩放(Horizontal Scaling)以及垂直缩放(Vertical Scaling)，接下来就讲讲这两种缩放的差别吧！

• Horizontal Scaling

  Horizontal Scaling 通常都是为了增加连接端点，以达到分散流量的作用，让每个服务器的负担不会过大，像之前所介绍利用 ReplicaSet 或 Replication Controller 产生的多个 Pod 都是属於 Horizontal Scaling。

• Vertical Scaling

  Vertical Scaling 通常是为了让旗下的服务器能拥有更多的资源存取量，有种上对下的感觉，上面的人给越多东西底下的人才能做更多事情，通常 Vertical Scaling 都会发生在云端服务上，像 GCP、AWS 等等云端服务都有自动机器让整个 cluster 能拥有更多的资源可以使用。

K8s Auto Scaling 写法

一样我们先看个简单的范例。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: helloworld
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: helloworld
  minReplicas: 2
  maxReplicas: 5
  targetCPUUtilizationPercentage: 10

这边可以发现 apiVersion 後面的值又不一样了，这是因为 Auto Scaling 的部分在 K8s 中也有独立的设定值就跟 Deployment 一样，所以这边要填上 autoscaling/v1。

再来可以看到 spec 的部分有一个设定值为 scaleTargetRef，这个代表在进行 Scaling 时的详细依据，所以要填上针对哪个 ReplicaSet 或 Deployment 或 Replication Controller 等等用来管理 Pod 的物件资讯，这边笔者就接续之前所介绍的 Deployment 来撰写，所以就要填上 Deployment 的资讯，像是 apiVersion、kind、name。

之後可以看到 minReplicas 以及 maxReplicas，这两个代表 Pod 数量的范围，相信大家看到名称也知道 minReplicas 代表 Pod 的最少数量而 maxReplicas 代表的是 Pod 的最大数量。

最後可以看到 targetCPUUtilizationPercentage 这个设定，在进行 Auto Scaling 的时候都是依据 CPU 的使用量进行扩展，而依据来源为 Resource Quotas 中的 Request 设定值。

假如今天 Resource Quotas 的 Request CPU 设定为 200m 而 Auto Scaler 设定的 targetCPUUtilizationPercentage 为 10，就代表当 Pod 的 CPU 使用率为 20m 的时候就要进行 Auto Scaling。

当然该 Pod 的 CPU 使用率还是可以使用到 Resource Quotas 中 Limits 设定的上限，只是在那之前 Auto Scaler 会先产生一个新的 Pod 出来。

Auto Scaling 建立

由於现在要让 K8s 自行建立 Pod，因此我们必须要把 minikube 上用来监控流量的 addons 打开，这边要打开的是 metrics-server。

接下来就可以透过 apply 这个参数把刚刚写好的 HorizontalPodAutoscaler(HPA) 档建立起来。

建立完後可以下 get 的参数查看 Auto Scaler，这边可以发现 target 的部分为 <unknown>，这是因为 Auto Scaler 还在抓取目前 Deployment 流量的关系，假如我们没有把 metrics-server 打开的话，这边就会一直是 <unknown> 所以要请读者特别注意一下。

等一小段时间之後，Auto Scaler 就会把流量抓取完毕了，这时候就可以看到 <unknown> 已经不见了。

接下来就可以稍微测试一下 HPA 是否有正常运行，这里笔者就不断的打网址输出网页内容看看是否真的会自动产生新的 Pod。

经过一段时间後，接下来在查看一次 HPA 的资讯，可以发现当流量开始超过我们设定的临界值之後，HPA 就会开始产生新的 Pod 了。

可以看到 Replicas 的部分不断的在增加直到我们设定的 MaxPods 数量後就不会再增加了。

最後可以把刚刚打网址的回圈关掉，再等一段时间後就可以发现 HPA 也会自动地减少 Pod 直到我们设定的 MinPods 数量。

ReplicaSet v.s. HPA

相信大家应该会很好奇到底 Pod 的数量会跟着 ReplicaSet 走还是跟着 HPA 走，由於我们已经启动 K8s 的自动扩展 Pod 的功能了，所以现在会变成 HPA 来控管 Pod ，即便今天将 Deployment 进行更新也不会依照我们设定好的 replica 的值而产生相对应数量的 Pod，所以笔者建议假如要设定 HPA，其 minReplicas 最好设定跟 Deployment 中的 replica 的值一样。

小结

今天介绍了 K8s 是如何让 Pod 自动扩展，相信大家应该更了解如何自动产生更多 Pod 了，但假如一直肆无忌惮的增加 Pod 要如何得知每个 Pod 是否都是健康的呢？

所以下一篇文章就要来介绍要如何在 Pod 中建立 Health Check，如果对於文章有任何问题都欢迎留言给我，那我们就下篇文章见喽～