最需要关爱的运维能通过容器得到什么？

数人云“容器助力产品迭代力MAX”沙龙干货分享实录持续上新，大家各抒己见，Mesos来了，K8S来了，Swarm也来了。今天是来自易宝支付系统架构师于涛的分享。作为一个做了十几年的运维老兵，于涛介绍了云时代的运维是怎样的，以及容器技术对于运维来说究竟意味着什么。

于涛

易宝支付系统架构师

我来自易宝支付，易宝支付是一家有十多年历史的支付公司。大家可以想象，一个发展了十几年的公司，IT系统会有多少的历史包袱。我加入易宝支付以后，主要负责技术的选型，我认为容器技术对运维来说是一项会引起很大变革的突破性技术。

传统运维那些事

下面说的适用于一般的公司，服务器规模从几百台，上千台，几万台，甚至到几十万台。传统运维一般来说分为三部分：基础运维、应用运维和监控。

基础运维包括IDC、上架、装机、网络，还有硬件驱动的升级。大家有没有人做过服务器、交换机或者存储设备的Firmware升级？这是个挺痛苦的事。一旦出了问题，厂家会让你升级Firmware，解决不了，就让你找亚洲研发中心或美国研发中心；应用运维的事就更多了，环境、部署、升级/回滚、自愈，还有容量管理。产品说下周有个应用有突发流量，可能是一款新业务的秒杀活动，要准备机器，部署应用；监控，做运维的大部分都半夜里被叫起来过吧，应该都有这种经历。

平台演变之路

从物理机时代到第一代云，或者说OpenStack时代，再到现在的容器时代，我有几点体会，一是时间成本降低了很多，二是底层越来越下降。

在以前，对于一个有上万台服务器的公司来说，升级Firmware是一个经常做的事情。到了OpenStack虚拟机时代，可以感觉到我们已经不再关心底层的Firmware这些东西了。而到了Docker时代，运维也不再关心虚拟机、虚拟网卡，以及虚拟网络的性能了。从裸机时代到Docker时代，我们越来越贴近应用。

最开始IT对业务是支撑的作用，比如生产汽车的公司需要IT做一个ERP系统。但是到了Docker时代，IT和业务贴的越来越近，这是一个融合的时代，是IT和应用融合的过程。

Itil与容器云

从Itil时代到云时代，也就是XaaS，一切即服务。

Itil很复杂，是一些大公司提出来的，它以CMDB为核心，并加入事件管理、配置管理、发布管理，还有工作台，涉及的概念也比较多。

互联网公司做CMDB的有很多，CMDB有一个很困难的地方就是CI配置项，尤其到应用是很难做的。应用要连DB，当变了的时候，得到这个变更信息是比较困难的。CMDB有一个分支叫DCIM，就是说不再关心应用方面的配置信息，而是去关注包括服务器、带宽、机架，IDC这样的硬件设备的基础运维。再往后发展，基础设施逐渐迁到云上，再往后是DevOps，Docker时代经历了这样的演变。

这是主流的容器平台。易宝支付选型的是Kubernetes，我感觉技术选型适用就好，没有说哪个好，哪个坏，而是要看哪个更适和自己。

这个图是Kubernetes比较经典的图，它的核心，ETCD是唯一存储数据的地方。它的Master的API、Schedule，还有计算节点都不存任何数据。如果要做Master的HA，或者是多节点，给ETCD做个集群就可以。Kubernetes里面技术栈比较多，而且基于他很多人，很多公司玩出了很多花样，我就不细致的讲各个组件了。

这是Kubernetes的一些基本组件和功能。有资源限额Namespace、pod、服务、事件，这些基本涵盖了运维很大部分的工作。

CMDB与ETCD

从CMDB时代到ETCD时代发生了一些变化，有一些东西没有了，一些常见的保留了，比如资产管理、事件/变更管理，CI&关系维护，工作流设计，这是CMDB经常会做的工作。

到ETCD，主机信息一般是在Registry Minions，这是它的物理机信息。

网络配置就是通过一个Flannel，Master作为一个ETCD的网络控制平面，提供IP，子网定义之类的。

应用信息通过Pod描述，这是我们现在测试环境里的一个Demo。

服务，多个Pod，出现相同的Pod就抽象成一个服务，相当于我们在做F5时，三台机器配置一个应用，做一个F5表示一个可用的服务。这是我们现在环境里的一些现有的服务。

事件管理，当Pod出现了问题，它会维持副本数，比如维持三个，也就是说，一个出现了问题，它会自动Kill有问题的，重新启动一个新的。举例来说，维持三个Nginx，给Nginx定义三个，当少于三个的时候，它就会从调度系统里启动一个Nginx。

配置管理与Configmap

配置管理在运维环境里是一个非常麻烦的地方，有沟通的问题、有业务复杂性的问题，还有参数调整的问题。配置管理第一个要求是程序和代码一定要分离。Configmap是配置管理功能，所有的配置信息还是存在ETCD里。是一种key／value的键值对，加载方式可以通过命令行、环境变量或数据卷文件，我们特别推荐通过环境变量来加载。

拿Kubernetes官方文档举例如何配Redis。其实配置简单来说可以分为两类，一是参数配置，还有一种是关系配置，访问数据库，访问Redis，访问外部资源等等，这些都可以用Configmap功能做。具体来说，就是创建一个Redis Config文件，Config文件定义一个两兆Memory。

创建之后，通过这个文件Pod来加载他，这里创建了一个Config文件，加载的时候Pod的一些资源信息。

易宝实践之路

目前，易宝支付在容器云实践方面做了很多的调研和测试，已经测试了很长时间了。我们从0.17版本开始跟，那个时候装一个Kubernetes还是挺困难的。现在已经到了1.3版了。官方的实验基本上都做过了，目前，公司的运维部门基本上都接受了，获益确实不少。

现在的问题是怎么把应用迁进来，我们也有很多考虑。我们计划首先把应用放进来实现弹性的负载资源化，负载均衡器，然后对集群内\集群外的DNS做服务发现。以前我们要考虑服务如何命名，注册到CMDB里面以后就不用考虑这个问题了。加一台机器，自动就可以加到负载均衡集群里，这就是服务的概念。滚动升级，灰度发布，一键上线，一键回滚，这些也都是Kubernetes的特性，这些我们都做过测试。如果仓库里有版本页，就可以回滚到任何一个版本，实现自动的扩容、缩容，根据CPU使用率和冷却时间来做。

我们正在公司内部逐步推行软件基础设施，就是Infra. as a code。以前加一个机器，加一个交换机或者增加一个G的带宽，是不能形成代码的，可能是形成一个Word文档，或是一个方案。用集群的方式，所有的操作都可以用Yaml文件或做成版本管理，甚至做扩容和缩容，在测试环境下跑一跑。比如，在以前要增加二十台机器，加一个机柜，上连两个线路做Portchannel，这时找环境是不太好验证的。因为同型号、同模块，甚至同机器、同网卡都不太好实现。到了容器云时代，我们可以在测试环境下，在这个基础设施下做任何变通，也可以做一个、跑一遍，在测试环境下跑成功了，那生产环境下也可以跑，这就是Infra. as a code。基础设施作为代码也可以有持续集成，也可以有CI/CD，这就是基础设施即代码。

这是一个类似的图，用户浏览器有一个域名可以访问到Kubernetes的一个物理机的Node IP。Node里面运行了一个Nginx，相当于一个接入层。然后根据域名做一些Ngnix Server的配置，区分不同的域名。根据匹配规则来区分，把不同的应用访问通过match匹配转到不同的Pod上去，这是一个从外部访问的流程。其实这还没完，访问，刚才提到的扩容、缩容，日志处理，后面还有很多要做的事。用户可以加入一些策略、Waf，或者防火墙。这样，整个集群就变得很灵活了。

不可变基础设施。以前维护一台机器，会因为操作系统不一样导致硬件的配置也不一样，而硬件不一样，维护的人也不一样，这个人喜欢用VI，那个人喜欢用ED。如果用不可变基础设施这个概念，也就是说基础设施一旦放下去，就不许做修改。如果实在要把它换掉就用一个新的替代，这就解决了上面说到的问题。

讲一下我以前的一个案例，我有一台戴尔的机器出问题了。戴尔说主板坏了，给我换完主板，我发现戴尔换完主板后，它的序列号没变，还是原来的。这其实是好多年以前的事了，到现在来说，我觉得现在提出的不可变基础设施概念和那件事有点相似。我觉得这些公司考虑的还是挺周全的。

不可变基础设施的方式使部署和配置管理更便捷，而且是可重复的。

在容器云时代，我们老讲放养和宠物，一个应用可以随时杀死他，不会再像以前那样。我们现在还实现了整个应用的全生命周期管理，比如滚动升级，从APP V1状态，把一台升到V2，滚动，两台升到V2，三台升到V2，这是滚动升级。扩容，从V2，从三台到五台，缩容从三台，这些都是一键操作。

再谈谈易宝支付现在的情况，现在整个测试、调研和研发都进行的差不多了，初期我们的目的是解放运维，把Kubernetes这套平台作为一个软件定义的数据中心。原来我们做F5，加机器，减机器，要做多份部署。现在我们的运维能够实现自动化，新上的业务都必须是无状态应用。也就是说，一定要落到后端，可以选择Redis，可以选择DB，但本地不允许落文件，所有的文件读写都放到后端存储上去，也就是Ceph对象存储方式。日志通过流式输出，这块现在条件都具备了，运维正在和研发一块碰。然后再使用Configmap实现配置管理，这是我们今年下半年要做的事情。

分享就到这里，谢谢大家。