服务上线就要顶的住压力、扛的住考验，不然挨说的还是我们这帮做事的兄弟，还记得上图这个场景吗
老办法是服务集群部署，但总归有个上限，之前跟阿里合作的时候他们有个弹性计算可以通过设置CPU的阀值来动态扩展和收缩计算能力，那时感觉很有逼格，至少在当时我们常规的做法很难做到，没想到时至今日有了Kubernetes我们能也扬眉吐气了，看我来给大家实实在在的秀一把。
Kubernetes的自动扩容针对的是ReplicationController的，它会监控所有Pods的CPU使用情况，如果超过比例就启动更多的Pods来提供服务，反之减少Pods，在一般的情况下我们不会设置Pods的CPU的上限，但要使用自动扩容就要设置它的阀值因此也要设置Pods的CPU使用上限，不然Kubernetes没办法计算它的占用比例，所以我们在创建RC的时候就要指定每个Pod CPU资源占用的上限
配置
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2kind: ReplicationController
3metadata:
4 name: thrift-c
5 namespace: thrift-demo
6spec:
7 replicas:1
8 selector:
9 app: thrift-c
10 template:
11 metadata:
12 name: thrift-c
13 labels:
14 app: thrift-c
15 spec:
16 containers:
17 - name: thrift-c
18 resources:
19 requests:
20 cpu: 200m
21 image: registry2.io/thrift/thrift-c:0.0.2
22 imagePullPolicy: Always
23 ports:
24 - containerPort: 9091
25 imagePullSecrets:
26 - name: registry2key
27
注意resources的配置，指定CPU最高占用为200m，如果是修改的话必须要删除RC，重新创建，apply不行，另外注意我们这里的replicas是1。
在Dashboard中查看，是不是生效了，
压力测试
我们的配置确定生效之后就要看Kubernetes弹性扩容的效果了，第一步要先给我们的服务增加自动扩容的能力，有两种方法，一种是配置文件，另一种是通过Kubectl命令完成，看命令
2
2
参数–max是弹性扩容最大Pods数量，–min自然是最小数量，–cpu-percent是阀值，是一个百分比这里配置的是相当于10%，这条命令运行之后就给我们指定的RC thrift-c增加了自动扩容的能力，查看一下
可以看到target和current以及数量等信息，目前我们没有访问量
第二步，加压，增加访问量和并发，给你一条简单的命令
2
2
我分别在三台机器上执行了这条命令，压力直线上升，
当CPU超过10%的时候我们看下Pods的数量
Pods从一个迅速给扩容到4个，如果服务能力没到达到要求还会增加Pods数量，当我把压力测试命令终止后CPU降下来时Kubernetes大概过了几分钟把Pods减少到最初的一个，我反复测试了多次，这个功能非常好用也很稳定，它能够及时的根据服务的压力做出响应，在收缩的时候有延迟可能是防止短时间内再次发生，CPU稳定一段时间后Pods被减少到我们配置的–min个。
有了这个功能我们再也不怕突发其来的压力和服务器宕机，瓶颈就丢给网络和磁盘IO以及数据库了，服务器方面如果有宕机Kubernetes会把它上面的Pods全部移到其它结点上启动起来，保证你的Pods始终是运行的，但有一点Kubernetes的Master是单点运行的，在后面如果有空研究一下Master的高可用，其实已经有很多网友研究过并给出解决办法，如果有兴趣可以先了解一下。
