众所周知，目前好多互联网公司纷纷用上了 容器化部署方案，最常见的就是 k8s、docker、openshift 、docker swarm、mesos sphere 等；

今天就聊一下容器化的部署方案真正意义上的使用场景  以及 怎么使用能把容器化部署真正的威力发挥出来；

k8s 大家都清楚，他目前作为 弹性伸缩、资源容器的编排和治理的代表工具，部署一个集群版的k8s十分容易，我之前的博客也写过如何去部署，大家可以参考；

但是我发现好多公司使用k8s 在我的理解里就是 为了使用k8s 而去使用k8s，我感觉他们不一定明白k8s的真正的威力，他们用k8s大多看中了 k8s的故障漂移、故障自愈、弹性伸缩(这里先打一个问号)、云交付、资源编排/ 治理 等等，用 k8s 这些都没问题，但是不用k8s 这些照样有N种办法解决，那么为何要用k8s呢？ 你可以说你的k8s就是个工厂，意义不大，不建议这么干；

举个实际场景的例子，一个公司生产环境有20台ECS，部署了一个k8s集群，然后他们发现一个问题，就是他们的资源老不够用，动不动CPU和内存就告警，请我帮忙排查了下，发现问题很严重，他们这个DevOps场景是 伪DevOps场景， k8s最怕的就是在一个 固定的资源池里玩，他们的 资源池20台服务器减去1台master，19台资源，所有的 deployment和statefulset 都在在19台ECS里玩，这里就应该发现问题，他们做了弹性伸缩，资源监控，一旦CPU、内存、网络达到阈值立马扩容出一个pod出来，20台ecs的资源池说多不多，他们是一个流量型的应用，用户访问的频率取决于当下的热门实事，这种类型的应用APP 肯定不能基于固定资源池内玩 资源动态伸缩， 在重复一遍，不能基于固定的资源池内玩 资源动态伸缩，这不是k8s的初衷；k8s的优势之一是资源动态伸缩，那么我问问大家，在固定的资源池内如何玩动态伸缩，还不如直接把所有的服务都部署在20台服务器上呢，直接walle + haproxy + keepalived + zookeeper + consul 等等的不就搞定了？ 何必花样玩k8s呢？对吧，下面我来说说我是怎么高效玩k8s部署的：

1. DevOps体系打通私有云和公有云的接口，内部自研一个DevOps平台做到 管理K8S集群所有的节点 、管理服务器（裸金属、ECS）、有效纳管公有云平台（接口打通，取决于你用哪些平台，比如华为云、阿里云、腾讯云 等等）；

2. 做整体的资源监控，不仅仅局限于 k8s的监控，而是全局资源监控，及时发现资源即将达到阈值的风险；

3. 提前做好服务器镜像，做好服务器相关配置的编排脚本或者服务；

4. 做好k8s集群的管理和控制，弹性伸缩 node；

5. 一旦全局资源发生告警，DevOps平台会立刻调用公有云平台的接口，创建出一台或者多台服务器出来，镜像就用你们之前打好的，调用相关服务或者脚本 及时加入到 k8s集群里来，设置相关的标签；

6. 这样只要你们的固定服务器资源不够了，随时扩容，我经过测试 接口创建一台ECS服务器一分钟左右吧 加上相关的自动化配置，一共3分钟左右搞定；假设你的阈值设定为80%，那么你的服务器可能在阈值上限后还能支撑几分钟，足够给扩容服务器留出时间，这时候你可能会较真了，我这样多繁琐，直接人工扩容不行吗？ 我回答你，可以  只要你的运维没意见就行，实时盯着监控大屏就行；

7. 这么一来不管你们的流量怎么激增，都不会给你的线上业务造成宕机或者大范围卡顿现象；前提是你的公有云账户里必须有钱，没钱啥都干不了；  然后等流量下来了 不再需要了，按照你们制定的相关策略 可以自动让devops平台调用公有云接口释放掉新购买多余的服务器，然后调用k8s服务的API 删除新增进来的node节点；

8. 当然了还有一种方案就是 k8s联邦，可以了解下；