容器云平台基础架构方案设计思考

【编者的话】本文是作者作为一名云计算运维工程师在参与容器云平台建设中的一些有感记录，此次主要针对基础架构技术方案设计方面谈谈自己的一些认知，如有描述不妥之处，还请多包涵并给予指正。

如今，在移动互联的大时代下，互联网公司金融业务的爆炸式发展给传统金融行业带来了巨大的冲击和挑战，金融行业也纷纷顺应发展趋势，大力发展移动端业务和互金类型业务，因此对业务需求的响应速度有了更高的要求，越来越多传统应用架构，为了适应不断变化的业务需求，难以预估的访问量，而开始进行分布式改造、微服务改造，实现持续集成、持续部署、支持弹性伸缩、灰度发布、蓝绿部署等能力，容器云平台恰恰可以很好的支撑上述需求。容器技术是近些年来最火热的技术弄潮儿，我们关注他，肯定不止是因为它足够火热，需要任何一项技术，一定都是以更好服务于应用，让用户使用感受越来越美好为目的。

笔者在容器平台的建设过程中，参与了大量的技术讨论和思维碰撞，一个非常大的感触就是，容器云的知识栈非常长，想对平台有一个全局的透彻理解，要学习的东西非常之多，而且很多是跨领域的。作为一名云计算运维工程师，在这里也简单聊聊在平台基础架构设计中自己的一些认知。

平台选型

在做IaaS时，即使经过了深度的定制化自动化改造，IaaS上的流程走完时也普遍是在交付时把带有应用软件及软件配置的一台虚拟机交到申请者手中，申请者要自己通过IP登录去部署应用，更不用说各应用组件之间的配合设置。而在容器平台里，从代码开发集成，到一个容器镜像里打包了应用和应用的运行时环境，加上容器的配置文件，一套完整流程走下来时，应用已经可以上线了，负载均衡、安全策略都可以具备了，可以说容器云平台是DevOps理论的最佳实现。所以，对于容器平台的建设，从初期就需要各技术团队紧密结合，了解互相的需求，平台相关技术的原理机制，才能共同设计好一个容器平台。 如果你想和更多容器技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态 。

而对于传统应用容器化改造，应用接入容器云平台一定是一个循序渐进的过程，更是一个不断演讲的过程。为了让应用尽可能平滑的接入，平台设计也应适当考虑业务原场景和使用习惯，尽可能的避免大幅度修改逻辑，不希望为了容器化而容器化，还是要因地制宜，互相找到一个平衡。虽做了很多技术实践经验的调研，但真正在自己的环境中落地时，大家都是摸着石头过河，要通过试点应用，积累应用改造的经验，运维的经验。

对于容器平台，Docker已经成了容器引擎公认的事实标准，而Kubernetes也是公认的容器编排最佳调度平台，早在一两年前声音还没有如此的一致，记得最初做容器平台技术调研时，还要关注Mesos，Swarm等，但现在无论是商业产品还是纯自研，基本都转向了Kubernetes的阵营，说到这里我来简单谈谈Docker和Kubernetes最吸引人，或者说最值得应用的地方。

Docker

Docker我认为最有价值的地方是优秀的可移植性，我们日常中最常见的问题就是应用部署的环境差异，操作系统版本差异，生产测试环境不一致等，往往这种差异会导致应用部署调试消耗大量的人力，还容易出现安全隐患，即使很多部署工作已经自动化，但也对基础环境有一定要求，这点比虚拟机有了更友好的移植能力，Docker能够将应用程序和它依赖的操作系统、类库以及运行时环境整体打包，统一交付，真正抹去了应用程序多个运行实例间的环境和依赖版本差异，同时也把对运维人员的重度依赖解耦开来。Docker有一句响亮的口号不是白叫的“Build once，Run anywhere”。

还有一点就是快，秒级启动，虚拟机虽说是分钟级的启动，其实也已经非常快了，但从单体来看，当出现故障重启（Docker是重新生成），这种差别就是非常明显的，容器甚至可以做到外界无感知，尤其对于当需要应用扩容弹新的节点时，这种秒与分钟效率的差别，对应用的使用对象就是天壤之别的使用体验了，这里还不说虚拟机应急扩节点时应用配置的复杂度和配置时长，单是创建和启动时间，可能就是一个外部用户无感知，一个外部用户感觉到慢甚至短时间内服务不可用了。

Kubernetes

Kubernetes，这个单词来自于希腊语，含义是舵手或领航员，简称K8S。2014年以Google内部用了很久的Brog为原型孵化出来贡献给开源社区的一个自动化部署、伸缩和编排容器的开源平台，其功能强大，Kubernetes实现了IP地址管理、负载均衡、服务发现和DNS名称注册，还原生提供运维人员更为关注的高可用特性及资源智能调度，在我看来Kubernetes对管理基础设施的抽象解耦比虚拟化技术更为彻底、极致，其对CPU兼容性、系统兼容性更为优秀。Kubernetes的自动扩缩容、负载均衡和重新启动应用程序的功能，这些也是使用IaaS或裸机时要二次定制开发的。

这里也要说下，Kubernetes不只支持Docker，它支持符合CRI（containerruntime interface）接口的容器引擎，CoreOS的rkt就是一大代表。

当然构成一套容器云平台，不只是Docker和Kubernetes就够了，他们只是应用运行和调度的最核心的载体，还要有一系列CI\CD、镜像管理、安全、监控、网络、存储等组件，才能构成一个完整的解决方案。

计算方案

应该部署在物理机还是虚拟机上？

这是架构设计时一定会讨论的一个问题，从容器云的架构设计来看，我觉得没有绝对的谁更好的答案，物理机或虚拟化平台均可以，前面也说到了，其核心组件K8S将基础设施抽象的更为极致，所以我认为要综合企业自身基础设施建设现状和内部制度流程等综合因素权衡。

如果之前已经有了IaaS平台建设，并且已经有成熟的运维规范和配套工具，那么就部署于IaaS之上，享受IaaS建设的红利。融入了自助服务、内部流程审批、应用软件安装等自动化流程及规范，且IaaS平台有一些对于运维人员爱不释手的功能——热迁移、快照、HA、快速创建虚拟机等，IaaS平台在易管理性和资源弹性上相比物理机还是优势巨大的。

如果没有现成的IaaS建设，那么我认为首选物理机，没有必要再去投入人力去设计IAAS基础设施，K8S原生解耦了基础设施的依赖，提供了智能调度和高可用能力，针对物理机去定制一些满足自身的管理功能和运维的自动化手段也是理想之选，毕竟建设一套适合自身企业需求的IAAS本身也是个巨大的工程，而且少了一层虚拟化，从架构来看更为清晰简洁，troubleshooting时理论故障点也会少些，虚拟化层的性能损耗也不用考虑了。

网络方案

在容器平台的基础架构层面，网络方案的设计一般都是涉及讨论最多，意见碰撞最多的地方，毕竟网络是底层的基础设施，牵一发动全身，所以定会格外谨慎。underlay、overlay、routing的网络模型都比较了遍，当然这些方案都是要Kubernetes CNI（Container Network Interface）插件标准的，主要关注的有：ipvlan（underlay）、Macvlan（underlay）、Flannel（overlay）、Calico（routing）、NSX-T（routing）。

对于underlay的方案，对于传统的网络架构可以无缝适配，网络的管理模式（IP资源管理，流量管理等）也可以保持一致，但从Kubernetes的管理功能和生态圈来看，underlay的网络方案都不是方向，更多是一种适配传统网络架构的过渡方案，对于ip的管理还是要在外部完成，而且Kubernetes也失去了对于容器的隔离控制能力，此外，例如Macvlan要求启用混杂模式，ipvlan要求linux内核版本要在4.1之上等刚性要求，也不适合绝大多数企业的网络管理规范及操作系统使用现状。对于Overlay的方案，对于传统网络和容器通讯及跨Kubernetes集群的容器通讯需求，该类型方案均存在很大弊端，而且基于vxlan的数据封装传输，对于容器ip的流量监控也不易实现（除非支持解析 vxlan 数据包），对于vxlan的解封包，在性能上也会一定损失，性能表现亦不占优。所以，综合应用的通信需求、运维的管理需求、功能的完善度、技术趋势、性能、安全等多方面的因素，我认为routing的网络模型方案更优，routing模式对传统应用适配，接受传统组织结构都更友好。

接下来我也将routing方案的主要代表介绍下：

Calico

Calico是综合对比后，各方面功能需求最为满足的开源网络方案，而且其在社区的活跃度非常高，通过调研了解到一些容器平台厂商也开始或已经在产品中集成此方案。

Calico是一个纯三层的数据中心网络方案（不需要Overlay），基于BGP协议通过路由转发的方式实现容器的跨主机通信。Calico 将每个节点（Node）虚拟为一个“路由器”，并为之分配独立的虚拟网段，该路由器为当前节点上的容器提供路由服务，完全利用路由规则实现动态组网，通过BGP协议通告路由，小规模部署可以直接互联，大规模下可通过指定的BGProutereflector来完成。

Calico在每一个计算节点实现了Linux内核级的vRouter来负责数据转发，所以性能优异。

其相较其他开源方案，还有一大优势是安全能力，基于iptables提供了丰富而灵活的network policy，支持很细致的ACL控制。

Calico主要由Felix、etcd、BGP client以及BGPRoute Reflector组成：

1. Felix，Calico Agent，跑在每台需要运行Workload的节点上，主要负责为容器配置IP，路由及ACLs（iptable规则）等信息来确保Endpoint的连通状态；
2. etcd，分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性；
3. BGP Client（BIRD），主要负责把Felix写入Kernel的路由信息分发（广播）到当前Calico网络( 通过BGP协议)，确保Workload间的通信的有效性；
4. BGP Route Reflector（BIRD），大规模集群的分级路由分发，摒弃所有节点互联的Mesh模式，通过一个或者多个BGP Route Reflector来完成集中式的路由分发。

NSX-T

NSX-T是VMware的企业级网络虚拟化商业解决方案，是2016年5月在NSX-V/NSX-MH之后推出的新产品，到现在是2.3版本，T版本主要是加入容器网络支持和兼容裸金属物理机这两个重要功能，未来也会逐步将NSX-V/NSX-MH的代码整合完成替代。同Calico一样，也是内核级的数据转发，性能优异，而且产品自身提供了良好的负载均衡及安全能力。对于商业软件，企业级的服务支持和可视化的管理界面是商业方案优势较为明显的地方。

NSX-T我认为最显著的特点是，与传统网络有个南北向清晰地边界——Edge节点，而东西向全部在自己的自制范围内。

这里还有两个我认为比较重要的点应该了解一下，NSX-T与K8S的适配方式，是通过NSX-T Container Plug-in（NCP）插件与其集成，包括其他的容器平台解决方案也是通过此插件进行集成，例如Pivotal Cloud Foundry等。

还有一点是从NSX-T开始，VMware已经从NSX-V使用的基于vxlan的封装转移，并采用了更新的“Geneve”封装。Geneve是由VMware，Microsoft，Red Hat和Intel共同撰写的新版封装。Geneve将当前最佳的封装协议(如VXLAN，STT和NVGRE)整合到一个协议中。封装头的MTU为1600，所以对NSX-T自治域内的MTU值要求大于1600。

存储方案

存储也是基础架构的重要一环，尤其是对于有状态的应用，数据持久化需求的支持。

我觉得在Kubernetes里，对于基础资源（CPU、内存、网络、存储）的管理，存储使用的设计较为别致，使用方式有别于常见的思路，还需要认真去理解。

这里简单介绍下在K8S中存储设计的四个重要概念：Volume、PV（PersistentVolume）、PVC（PersistentVolumeClaim）、Storage Class。

Volume

Volume是最基础的存储抽象，其支持多种类型，包括本地存储、NFS、FC以及众多的云存储，也可以通过flex volume driver或CSI（contaioner storage Interface）编写自己的存储插件来支持特定的存储系统。

Volume可以被Pod直接使用，也可以被PV使用。普通的Volume和Pod之间是一种静态的绑定关系，在定义Pod的同时，通过volume属性来定义存储的类型，通过volumeMount来定义容器内的挂载点。

Volume有一个重要属性是，它与所属的Pod具有相同的生命周期。

Pod是Kubernetes的最小工作单元，每个 Pod 包含一个或多个容器 。

PV

PV与普通的Volume不同，它是Kubernetes中的一个资源对象，创建一个PV相当于创建了一个存储资源对象，向用户屏蔽了具体的存储实现形式，而且这个资源的使用要通过PVC来请求。PV定义的内容包含存储的类型，存储的大小和访问模式等。

PV的生命周期独立于Pod，即当使用它的Pod销毁时对PV没有影响。

PVC

PVC是用户对存储资源PV的请求，请求信息包含存储大小，访问模式等。根据PVC中指定的条件Kubernetes寻找系统中的PV资源并进行绑定。PVC消耗PV资源，PV和PVC是一一对应的。

StorageClass

StorageClass的引入是为了解决个性化的存储需求动态供给的问题，集群管理员可以先将存储资源定义为不同类型的资源，比如高性能存储、常规存储等，之后通过StorageClass的定义动态的去创建PV，然后通过PVC来请求PV绑定。

对于多数银行业的企业，都有丰富的SAN和NAS的存储管理及运维经验，结合应用的存储需求、平台镜像方案的设计，以及银行业的应用系统普遍有多中心部署的监管需求，我认为采用NFS类型的存储支持容器数据持久化以及镜像服务的相关存储需求对容器平台在银行业的落地不失为一个不错的选择，此外还应同时开展对象存储的研究与测试，以给应用对数据存储的使用方式更多选择。

容器云平台建设会是一个不断完善、迭代积累的过程，同时容器相关技术的发展变化非常之快，在平台的建设中要持续保持新技术的敏锐嗅觉，来提升应用服务、运维管理、安全监管等各方面的水平。

原文链接： https://mp.weixin.qq.com/s/O6Za5JGywmnZ-Rswlu5WzA