如果口述一套容器云平台

你是不是和我有同样的感觉，那就是有些知识你明明知道，但是却没办法将其表述出来，确切的说是不怎么从何说起，如何去说。可能在你的脑袋里对每一个组件，每一个模块都有概念，但是却没办法将其完完整整的说出来，用大佬的话说是知识太片面了，或者是太零碎了，对其没有一个整体的把握，也就是全局观。

我们在运维的时候，从发现问题到定位问题，其实是需要我们对自己的业务逻辑熟悉，对架构熟悉，而且处理问题的思路要清晰，这样才能更快的解决问题。如果没有一个全局的认识，那么处理问题的速度可能会大打折扣。今天我就尝试一下如何说出一套容器云平台。

以下内容纯个人理解，如果有不对的地方还请指出。

在说之前先考虑几个问题。
1、为什么要用容器？它能给我们带来什么？和直接用虚拟机有何不同？
2、如何选择容器云？用私有云自己搭建维护还是用公有云现有的容器云平台？
3、怎么完成一个完整的架子？

为什么用容器？

接触过容器的朋友可能会很清楚的意识到，容器云其实也没那么神秘，它能实现的虚拟机依然可以实现，而且稳定性可能比容器云平台还高。既然这样为什么还有这么多公司用容器呢？

其实，不论是公有云还是私有云，技术已经很成熟了，基本上可以满足我们所有的需求，但是容器也有其得天独厚的优势。
1、启动速度快。容器的启动速度和虚拟机不是一个量级，容器可以达到秒级，而虚拟机基本都是分钟级别。
2、资源利用率高。一个容器镜像最多几百MB，而一个虚拟机镜像基本都是已GB为单位了。再则，使用虚拟机我们需要在底层系统之上再创建一个虚拟机，而容器仅仅是一个进程，可以直接运行在底层系统之上。
3、环境一致性。用虚拟机的时候经常会遇到环境不一致导致应用各种问题，而容器我们只需要将其打包成一个镜像，这个应用运行所需的基础环境都放在这个镜像中了，那么我们就可以在”任何”地方运行。
4、故障迁移、自愈能力高。以kubernetes为例，kubernetes有各种controller来保证实际状态和期望状态高度一致，一个实例在某个节点故障可以快速另起一个实例，基本上无需人为干预，而且故障实例的资源会被回收。

下面简单总结以下容器和虚拟机的区别。

如何选择容器云平台？

这个其实没有一个标准，主要还是看公司现在用的是哪一种。比如公司现在就用的公有云，那么直接用公有云就好，用公有云的好处是底层的网络、存储等等不需要自己去考虑、去维护，基本上只要出钱就可以了。但是如果直接用公有云的服务其实是存在一个依赖问题，对于以后要换云或者下云是有一定的阻碍的。

私有云平台的话定制性高，很多都可以自我控制，但是维护成本大，而且底层的网络、存储这些专业的东西需要专业的人士来处理，稍有不慎就万劫不复~

如何搭架子？

下面以私有云平台中使用kubernetes为例。

在选的好使用哪种方式过后，一般情况下会评估以下几个问题。
1、集群会有多大的规模
2、集群的高可用怎么保证
3、存储如何选择
4、集群如何监控
5、应用如何部署
6、日志如何收集
7、如何演练故障

1、集群会有多大规模

这个根据自己目前的业务情况来看，我个人认为上下浮动20%，而且集群本身可以快速的扩缩容。

2、集群高可用如何保证

对于kubernetes来说，需要高可用就是master组件和etcd存储。对于etcd来说，本身就支持高可用部署，建议基数节点，可以和master组件部署在相同节点也可以部署在集群外。我个人建议部署在集群外，这样和集群是解耦合的。
对于master组件来说，需要我们自己去做高可用的组件只有apiserver，其他组件可以在配置文件中配置。对于apiserver我们可以使用HAProxy+keepalived，也可以使用NGINX+keepalived等等。其他应用的高可用完全有kubernetes自己控制了。

3、存储如何选择

存储的选择面其实非常多，有商业版的也有开源版的，商业版的好处就太明显了，一切问题找厂家。开源版的维护成本和学习成本比较高，比如ceph，它的维护成本和学习成本就很高。如果公司有现成的存储工程师，那么这都不是问题了，都找他来给你解决。如果用开源产品并且自己维护，就要好好考虑一下了，这个存储软件我能hold住么？如果故障了，我能解决么？它在业界的使用情况和相关的文档丰富么（方便自己处理问题~~）？

4、集群如何监控

对于监控来说，目前容器的监控主流的就是Prometheus，可以说它是为容器而生的。
它主要有以下几个组件。

• Prometheus Server
• exporters
• alter
• pushGateway
• Prometheus UI

其中Prometheus Server就是中枢神经，exporters就是负责收集监控信息的，alter负责处理报警相关，pushGateway用于接收定制监控信息的，UI就是一个简单的UI界面。整个监控系统看起来并不复杂，复杂的地方在于我们收集到了各种信息，如何提取我们需要的，如果制定相应的规则，说白了就是如何去提高监控的质量，具体的规则其实是需要研发，测试，运维共同制定的。

应用如何部署

我个人觉得这主要是咱们CI/CD部分了，目前做CI/CD的开源软件很多，而且各有所长。目前做CI的开源软件活跃度比较高的就是Jenkins，我们也是使用的Jenkins。Jenkins社区的活跃度很高，而且基本上遇到的问题也都有答案。CD部分，因为咱们用的是容器，我们的制品是镜像，那么只要是可以部署镜像的方法都可以，比如调API，使用helm，或者直接用kubectl命令。

这中间其实主要考虑几个问题：
1、pipeline的规范，共享库的建立、管理等
2、制品库的管理，包括备份、晋级、回滚等
3、使用Jenkinsfile的话是放在共享库还是代码库

日志如何收集

目前容器日志收集方案常用的就是EFK，根据日志量来确定需不需要加kafka或者redis。
日志收集的方式大概有三种：

• 日志是stdout,stderr，直接用daemonSet方式收集
• 日志输出到文件，可以使用sidecar方式收集
• 日志直接输出到es、kafka或者redis中

收集完日志就需要对日志进行一系列的处理，比如清洗、聚合、告警等等。

故障演练

主要有：
1、集群故障演练，包括存储、网络、集群节点、数据库等等
2、应用故障演练