使用 Kubernetes 的客户能够迅速响应终端用户的请求，交付软件也比以往更快。但是，当你的服务增长速度比预期更快时，计算资源不够时，该怎么处理呢？
此时可以很自豪地说： Kubernetes 1.3 提供了一个解决方案：自动伸缩（ auto-scaling ）。搭建在 Google 计算引擎（ GCE ）和 Google 容器引擎（ GKE ）（以及即将用于 AWS ）上， Kubernetes 会在必要时自动扩容你的集群，并在不需要时缩容，以便为你省下一笔费用。
Part 1 ：自动伸缩的优势
这里我们用一个例子说明自动伸缩的应用场景。
想象一下你有一个 7*24 （全天候）的服务，它的负载随着时间变化。在美国地区，白天服务非常繁忙，夜间负载相对较低。
理想情况下，我们希望集群中节点和运行中 Pod 的数量能够动态调整负载，以适应终端用户的需求。新的 自动伸缩 功能与 Horizontal Pod Autoscaler 配合在一起可以自动解决这个问题。
Part 2 ：在 GCE 设置 Autoscaling
以下操作指南适用于 GCE 。对于 GKE 请在集群操作手册（查看“相关链接”）查看 autoscaling 这个章节。
开始之前，我们需要一个活跃的 GCE 项目，并且启用 Google Cloud Monitoring 、 Google Cloud Logging 和 Stackdriver 。
如果你想了解如何创建一个 GCE 项目，请阅读入门指南（查看“相关链接”）。我们还需要下载一个 Kubernetes 项目的最新版本（版本 v1.3.0+）。
第一步：创建一个集群，并启用 Autoscaler 。
集群中的节点数量将从 2 开始，并自动调整到最大 5 。要实现这一点，我们需要设置以下环境变量：
通过 kube-up.sh 启动集群：
kube-up.sh 脚本创建一个集群，并默认启用了 Autoscaler 插件。如果集群中存在 pending pod ， autoscaler 将尝试向集群中添加新的节点，然后 pending 的 pod 会被调度到新节点上。
我们观察一下集群，它应该有两个节点：
第二步：运行并暴露 PHP-Apache 服务
为了演示自动伸缩功能，我们基于 php-apache 镜像制作了一个自己的镜像。镜像可以在这里（见“参考链接”）找到。它定义一个 index.php 页面，这个页面会执行 CPU 密集的计算。
首先，我们创建一个 deployment ，并将其端口暴露出来：
现在，我们将等待一段时间，验证部署和服务是否被正确创建和运行：
使用 wget 命令检查 Php-apache 服务是否运行正常：
第三步：启动 Horizontal Pod Autoscaler
depleoyment 正常运行后，我们将为它创建一个 Horizontal Pod Autoscaler 对象。使用 kubectl autoscale 命令就可以：
这里我们定义了一个 Horizontal Pod Autoscaler ，它保证 deployment 对象 php-apache 控制的 Pod 数量在 1 ～ 10 之间。
换句话说， horizontal autoscaler 通过 deployment 对象增加或减少 Pod 副本数量，以保证所有 Pod 的 CPU 平均使用率在 50%左右。
kubectl run 创建 deployment 时，为每个 Pod 申请了 0.5 核 CPU ，也就是说，每个 Pod 实际平均使用 0.25 核 CPU ）。
关于该算法的详细信息查看文章末尾（“相关链接”）。
我们可以通过” kubectl get hpa ”检查 autoscaler 的状态：
注意，当前的 CPU 使用率是 0%，因为我们没有向服务器发送任何请求（当前列显示的是与 hpa 对应的 rc 下所有 pods 的 CPU 使用率的均值。
第四步：提高负载
现在，我们将看到 Autoscalers （ Cluster Autoscaler 和 Horizontal Pod Autoscaler ）如何响应不断增加的负载。我们将启动两个实例（请运行在不同的终端），每个实例启动一个访问 php-apache 服务的死循环：
我们需要稍微等待一段时间（ 1min 左右），然后检查 Horizontal Pod Autoscaler 的状态：
Horizontal Pod Autoscaler 已经把 Pod 数量增加到 7 。我们检查下是不是所有的 Pod 都在运行：
我们可以发现：一些 pod 处于 pending 状态。我们使用 ” kubectl describe ” 命令查看其中一个 pending pod ，以获取 pending 的原因：
该 pod 正在 pending 是由于在系统中没有足够的 CPU 资源。我们还可以看到有一个 TriggeredScaleUp 事件。这意味着 pod 触发了 Cluster Autoscaler 的响应，一个新节点将被添加到集群中。
现在我们再等待一段时间（ 3min 左右），并列出所有节点：
我们可以发现：一个新节点 kubernetes-minion-group-6z5i 被 Cluster Autoscaler 添加到集群中。我们确认下所有的 pods 都已经运行正常：
添加节点以后，所有的 php-apache pods 都在正常运行！
第五步：降低负载
现在，我们停止向服务器打压力。我们把两个向 server 发请求的死循环都结束掉，然后观察 php-apache 服务的状态：
我们可以看到， Pod 的 CPU 平均使用率已经降到 0%， Pod 个数也降到 1 。
把多余的 Pod 删除以后，大部分的集群资源都都被空出来。短时间内，集群不会被缩容，因为 Cluster Autoscaler 必须确保 php-apache 服务对资源的需求确实降低了，而不是短期或临时原因（比如 Pod 升级）。
更多细节参考 Cluster Autoscaler 的文档（“相关链接”）。
集群缩容可能比扩容花费更多时间。大约 10-12 分钟后，您可以验证集群节点数量的下降：
集群中节点的个数重新恢复到 2 ， 节点 kubernetes-minion-group-6z5i 已经被 Autoscaler 删除。
Part 3 ：其他使用场景
看完上面的例子，我们可以发现，结合 Horizontal Pod Autoscaler 和 Cluster Autoscaler 动态调整 pods 数量是很简单的。
在有些场景下， Cluster Autoscaler 自己也能发挥不少作用，尤其是应对某些不规则的负载变化。
举个例子，与集群相关的开发或者集成测试一般不会在周末和晚上进行。
对于批处理集群，当所有 Job 都结束，而新的 Job 也只能在几个小时后才开始。
让机器闲着绝对是暴殄天物。
在这些场景下， Cluster Autoscaler 能够减少空闲结点的数量，并显示减少支出，因为你只需要为实际运行的服务付费，同时也能够保证你总是有足够的资源运行你的任务。