k8s从入门到放弃(2): 缩扩容&更新

前言

自动缩扩容是现代化的容器调度平台带给我们的最激动人心的一项能力。在上规模的业务系统中我们无时无刻不面临着这样的难题：用户的流量往往随着时间波动，甚至偶尔出现不可预测的峰值（毛刺流量），每当流量增加时都需要手工的对应用进行扩容，峰值流量消失后又需要将扩容的机器回收，运维起来费时费力。

幸运的是，k8s这样的容器调度平台正在逐渐帮助我们解决这样的问题，它带来的AutoScaler功能目前已经支持在多个不同维度上的弹性缩扩容，可以根据应用的负载情况进行自适应。尽管在一些较为苛刻的场景下，由于容器启动速度等原因的限制，AutoScaler的效果还不尽人意，但相信在不久的将来，自动缩扩容方案将会完全成熟，届时我们将轻松获取具有强大弹性能力的服务集群。

现在来试着使用一下k8s的Scale相关功能吧

手动调整服务规模

我们可以使用kubectl提供的命令来手动调整某个Deployment的规模，也就是其包含的Pod数量，这里拿上一节里创建的HelloWorld服务来作为例子，当前的deployment状态如下：

• DISIRED 表示配置时声明的期望副本数
• CURRENT 表示当前正在运行的副本数
• UP-TO_DATE 表示符合预期状态的副本数（比如某个副本宕机了，这里就不会计算那个副本）
• AVAILABLE 表示目前可用的副本数

我们可以使用kubectl scale命令来手动调整deployment的规模，现在尝试把helloworld服务的副本数量扩充到4个：

执行命令后，k8s很快就为我们创建了另外3个helloworld的副本，这时候整个服务就有多个实例在运行了，那么对应Service的负载均衡功能便会生效，可以看到Service的状态里已经侦测到多个EndPoint:

当我们连续调用service时，可以看到每次实际调用的pod都不同（这里对服务的源码做了一些修改，打印出了hostname）：

同理，我们也可以用同样的方式把服务缩容，比如把副本集的数量下调到两个：

自动缩扩容：极致弹性？

参考好文

刚才的例子中，我们是通过命令行的方式来手动调整服务规模的，显然在面对线上真实流量时是不能这么做的，我们希望调度平台能够根据服务的负载来智能地调控规模，进行弹性缩扩容。这时候就轮到k8s中的AutoScaler出场了

到目前为止，