容器技术在企业落地的9个关键问题云计算

来源:互联网 / 作者:SKY / 2017-12-20 20:57 / 点击:
基于Docker的容器,是一种更轻量级的虚拟化,我们称之为 CaaS,就是容器级服务。它涵盖了 IaaS 跟 PaaS 两者的优势,可以解决应用的部署、开发运维、微服务这些

【Chinaz.com原创稿件】当今容器技术被广泛关注,已经有越来越多的企业开始布局或者已经采用容器技术来构建自己的云基础设施。

容器技术在企业落地的9个关键问题

在用容器设计新的微服务应用架构或者如何改造现有的应用时,应该了解哪些因素和相关特性,是企业在实施容器平台时必须要考虑的。

很多传统行业和互联网企业相比在容器技术方面起步稍晚,但近两年随着容器关注度的空前火热,企业进步也很快,大力推进容器相关能力的建设。

基于 Docker 的容器,是一种更轻量级的虚拟化,我们称之为 CaaS,就是容器级服务。它涵盖了 IaaS 跟 PaaS 两者的优势,可以解决应用的部署、开发运维、微服务这些问题,而且能够更快的加速业务的交付。

企业要用正确的姿态拥抱容器并且使用好容器,需要在应用容器技术之前考虑清楚以下九个关键问题

企业容器云方案设计需要遵循什么原则?

容器云技术产品如何选型?

容器云的网络应该如何设计?

容器的持久化存储方案如何选择和设计?

容器云上日志集中管理如何设计?

容器应用的监控方案如何设计?

容器云的多租户和权限如何设计?

容器与 OpenStack 和 Kubernetes 集成的能力?

容器云如何实现高可用和跨区部署?

企业容器云方案设计需要遵循什么原则?

Docker 作为新一代的云计算技术,毫无疑问将会给整个虚拟化开发运维、微服务、持续集成与持续交付,传统的中间件以及我们的应用带来深刻的变化,实现更高的性能以及效率,那么企业容器方案设计应该遵循什么原则呢?

首先,我们要明确企业上容器云的目的,容器是为业务服务的,任何技术都是为了能够更好的服务业务,这是我们的出发点。

其次,结合业务特点选择合适的容器框架,比如我们的业务本身是不是可以基于新型微服务架构进行改造,业务是不是具有变化快、弹性大、更新迭代快等特点。

还有要和已有系统较好地对接整合,在上容器之前,企业通常都已经有比较成熟和稳定的其他 IT 系统,例如网络系统、集中监控系统、安全防护系统等。

为避免重复建设,同时也为了容器平台能够更容易被接受和使用,应让容器平台融入企业原有的整个 IT 系统,而不是另起炉灶重新建设。

容器平台要承载生产业务,也需要满足安全的监管合规要求,例如隔离不同安全等级的应用、支持对应用容器的安全漏洞扫描、安全有效的防火墙策略管理等。

生产环境的业务要求高可用性、连续性,还应该考虑整个容器应用层面的高可用性和数据连续性、安全可靠。

建设容器平台的目的是为应用带来灵活、弹性、节省资源等优势,这要求应用最好具备微服务架构、无状态化等特点,让这些优势更好地发挥。

但不适合容器化的应用也不能勉强,否则容器平台建设后,如果不能给应用和业务带来预期的价值,不仅浪费了大量企业投入,还使得容器平台的价值得不到认可。这是每一个投入大量精力和热情进行容器平台建设的人最不愿意看到的结果。

容器云技术产品如何选型?

技术选型这个问题有很多复杂的影响因素,包括技术和非技术两方面,不同的组织情况下也不尽相同。

一个企业在应用新技术前,还需要考虑 IT 部门自身的技术能力,包括开发能力、运维能力,同时对自身业务系统从开发平台、开发过程、开发规范等有决定能力。

如果企业自身的开发和运维能力不强,则采用成熟的 PCF、OpenShift 等方案是不错的选择。

如果考虑现有系统对接需求,包括监控、网络、安全需求等,特别是现有网络架构对容器的网络方案有较大影响时,应该考虑使用 Kubernetes、Mesos、Swarm 等开源方案更便于定制,也能较好的融入现有 IT 系统。

Kubernetes、Mesos、Swarm 这三个开源方案都是行业内比较火热的资源编排解决方案,但它们各自的立足点各有千秋。

从应用的发布环节来比较:Docker 的 Swarm 功能,以及 Kubenetes 的编排,Mesos 的调度管理,很难直接决出高低。

换言之,如果加上企业级应用场景,来辅佐容器技术选型,则会显得更有意义。

企业规模不大,应用不是太复杂

这时 Docker Swarm Mode 还是比较好用的,集群的维护不需要 Zookeeper,Etcd 自己内置,命令行和 Docker 一样用起来顺手,服务发现和 DNS 是内置的,Overlay 网络是内置的。

企业规模大一些、应用够复杂

这时集群规模有几百个节点,很多人就不愿意使用 Docker Swarm Mode 了,而是用 Mesos 和 Marathon。

因为 Mesos 是一个非常优秀的调度器,它的双层调度机制可以使得集群规模大很多,Mesos 的优势在于第一层调度先将整个 Node 分配给一个 Framework,Framework 的调度器面对的集群规模小很多,然后在里面进行二次调度。

如果有多个 Framework,例如有多个 Marathon,则可以并行调度不冲突,同时 Mesos 在传统数据计算方面拥有较多的案例,相信也是企业选型时考虑的要素之一。

企业规模大、业务复杂、应用粒度更细

这时 Kubenetes 就更适合了,因为 Kubernetes 模块划分得更细更多,比 Marathon 和 Mesos 功能丰富,而且模块之间完全的松耦合,可以非常方便地进行定制化。

还有就是 Kubernetes 提供了强大的自动化机制,从而使后期的系统运维难度和运维成本大幅降低,而且 Kubernetes 社区的热度,可以使得使用 Kubernetes 的公司能够很快地得到帮助,方便问题和 Bug 的解决。

任何新的技术都有着各自适用的场景,如何经受住实践的考验,并将新的技术转化为生产力才是重中之重。

容器云的网络应该如何设计?

Docker 一直以来的理念都是“简单为美”,从 Docker 对 Linux 网络协议栈的操作可以看到,Docker 一开始并没有考虑到多主机互联的网络解决方案。

Docker 成名以后,收购了一家网络解决方案公司 Socketplane,将原有的网络部分抽离,单独成了 Docker 的网络库,即 libnetwork。

libnetwork 实现了 5 种驱动,通过插件的形式允许用户根据自己的需求来实现 network driver,但 libnetwork 组件只是将 Docker 平台中的网络子系统模块化为一个独立库的简单尝试,离成熟和完善还有一段距离。

随着容器技术在企业生产系统的逐步落地,用户对于容器云的网络特性要求也越来越高,跨主机容器间的网络互通已经成为最基本的要求。

跨主机的容器网络解决方案不外乎三大类:

隧道方案

比如 Flannel 的 VxLan,特点是对底层的网络没有过高的要求,一般来说只要是三层可达就可以,只要是在一个三层可达网络里,就能构建出一个基于隧道的容器网络。

不过问题也很明显,一个得到大家共识的是随着节点规模的增长、复杂度会提升,而且出了网络问题跟踪起来比较麻烦,大规模集群情况下,这是需要考虑的一个点。

路由方案

路由技术从三层实现跨主机容器互通,没有 NAT,效率比较高,和目前的网络能够融合在一起,每一个容器都可以像虚拟机一样分配一个业务的 IP。

但路由网络也有问题,路由网络对现有网络设备影响比较大,路由器的路由表应该有空间限制,一般是两三万条,而容器的大部分应用场景是运行微服务,数量集很大。

如果几万新的容器 IP 冲击到路由表里,会导致下层的物理设备没办法承受;而且每一个容器都分配一个业务 IP,业务 IP 会很快消耗。

VLAN

所有容器和物理机在同一个 VLAN 中。如下图,是一个网友的测试报告:

容器技术在企业落地的9个关键问题

图中我们看到 Calico 的方案和基于 HOST 的网络解决方案性能较好。

基于 HOST 的端口冲突和网络资源竞争比较麻烦,相对来说 Calico 的是纯三层的 SDN 实现,它基于 BPG 协议和 Linux 自己的路由转发机制,不依赖特殊硬件,没有使用 NAT 或 Tunnel 等技术。

它能够方便的部署在物理服务器、虚拟机(如 OpenStack)或者容器环境下,同时它自带的基于 Iptables 的 ACL 管理组件非常灵活,能够满足比较复杂的企业安全隔离需求。

关于容器应用的网络隔离还有多种解决方案,基本上就是把不同的应用容器放置在不同的 vlan/vxlan 中,通过让不同的 vlan/vxlan 不能互访而实现隔离。

简单的方案可以尝试用 docker overlay 来解决,首先创建不同的 network,然后在启动不同应用的容器时,使用 --net 参数指定容器所在的对应的 vxlan 即可。

结果是同一个 network 中的容器是互通的,不同的 network 中的容器是不通的。企业里应用目前是 OVS/Linux-bridge +VLAN 方案的比较多,但长远看来 Calico 方案前景不错。

容器的持久化存储方案如何选择和设计?

在讨论持久化存储之前,首先声明,运行容器并不意味着完全摒弃数据持久化。在容器中运行的应用,应用真正需要保存的数据,也可以写入持久化的 Volume 数据卷。

在这个方案中,持久层产生价值,不是通过弹性,而是通过灵活可编程,例如通过优秀设计的 API 来扩展存储。目前,主要支持 Docker 或 Kubernetes 的 Volume。

Docker 的容器卷插件

Docker 发布了容器卷插件规范,允许第三方厂商的数据卷在 Docker 引擎中提供数据服务。

这种机制意味着外置存储可以超过容器的生命周期而独立存在,而且各种存储设备只要满足接口 API 标准,就可接入 Docker 容器的运行平台中。

现有的各种存储可以通过简单的驱动程序封装,从而实现和 Docker 容器的对接。可以说,驱动程序实现了和容器引擎的北向接口,底层则调用后端存储的功能完成数据存取等任务。

目前已经实现的 DockerVolume Plugin 中,后端存储包括常见的 NFS、CIFS、GlusterFS 和块设备等。

K8S 的数据卷

K8S 的每个 Pod 包含一个或多个容器。Pod 可部署在集群的任意节点中,存储设备可通过数据卷提供给 Pod 的容器使用。

为了不绑定特定的容器技术,K8S 没有使用 Docker 的 Volume 机制,而是制定了自己的通用数据卷插件规范,以配合不同的容器运行来使用(如 Docker 和 rkt)。

阅读延展

1
3