实录分享 | 最需要关爱的运维能通过容器得到什么?

数人云“容器助力产品迭代力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实现配置管理,这是我们今年下半年要做的事情。

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