服务上线就要顶的住压力、扛的住考验，不然挨说的还是我们这帮做事的兄弟，还记得上图这个场景吗

老办法是服务集群部署，但总归有个上限，之前跟阿里合作的时候他们有个弹性计算可以通过设置CPU的阀值来动态扩展和收缩计算能力，那时感觉很有逼格，至少在当时我们常规的做法很难做到，没想到时至今日有了Kubernetes我们能也扬眉吐气了，看我来给大家实实在在的秀一把。

Kubernetes的自动扩容针对的是ReplicationController的，它会监控所有Pods的CPU使用情况，如果超过比例就启动更多的Pods来提供服务，反之减少Pods，在一般的情况下我们不会设置Pods的CPU的上限，但要使用自动扩容就要设置它的阀值因此也要设置Pods的CPU使用上限，不然Kubernetes没办法计算它的占用比例，所以我们在创建RC的时候就要指定每个Pod CPU资源占用的上限

配置

apiVersion: v1
kind: ReplicationController
metadata:
name: thrift-c
namespace: thrift-demo
spec:
replicas:1
selector:
app: thrift-c
template:
metadata:
name: thrift-c
labels:
app: thrift-c
spec:
containers:
- name: thrift-c
resources:
requests:
cpu: 200m
image: registry2.io/thrift/thrift-c:0.0.2
imagePullPolicy: Always
ports:
- containerPort: 9091
imagePullSecrets:
- name: registry2key

注意resources的配置，指定CPU最高占用为200m，如果是修改的话必须要删除RC，重新创建，apply不行，另外注意我们这里的replicas是1。

在Dashboard中查看，是不是生效了，

压力测试

我们的配置确定生效之后就要看Kubernetes弹性扩容的效果了，第一步要先给我们的服务增加自动扩容的能力，有两种方法，一种是配置文件，另一种是通过Kubectl命令完成，看命令

kubectl autoscale rc thrift-c -nthrift-demo --max=10 --cpu-percent=10 --min=1

参数--max是弹性扩容最大Pods数量，--min自然是最小数量，--cpu-percent是阀值，是一个百分比这里配置的是相当于10%，这条命令运行之后就给我们指定的RC thrift-c增加了自动扩容的能力，查看一下

可以看到target和current以及数量等信息，目前我们没有访问量

第二步，加压，增加访问量和并发，给你一条简单的命令

while true; do wget -q -O- http://test.k8s.io/hi?name=3213; done

我分别在三台机器上执行了这条命令，压力直线上升，

当CPU超过10%的时候我们看下Pods的数量

Pods从一个迅速给扩容到4个，如果服务能力没到达到要求还会增加Pods数量，当我把压力测试命令终止后CPU降下来时Kubernetes大概过了几分钟把Pods减少到最初的一个，我反复测试了多次，这个功能非常好用也很稳定，它能够及时的根据服务的压力做出响应，在收缩的时候有延迟可能是防止短时间内再次发生，CPU稳定一段时间后Pods被减少到我们配置的--min个。

有了这个功能我们再也不怕突发其来的压力和服务器宕机，瓶颈就丢给网络和磁盘IO以及数据库了，服务器方面如果有宕机Kubernetes会把它上面的Pods全部移到其它结点上启动起来，保证你的Pods始终是运行的，但有一点Kubernetes的Master是单点运行的，在后面如果有空研究一下Master的高可用，其实已经有很多网友研究过并给出解决办法，如果有兴趣可以先了解一下。