e-works数字化企业网  »  文章频道  »  基础信息化  »  物联网

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

2017/12/26    来源:51CTO技术栈    作者:孙杰      
关键字:容器技术  Docker  
基于Docker的容器,是一种更轻量级的虚拟化,我们称之为 CaaS,就是容器级服务。它涵盖了 IaaS 跟 PaaS 两者的优势,可以解决应用的部署、开发运维、微服务这些问题,而且能够更快的加速业务的交付。
    当今容器技术被广泛关注,已经有越来越多的企业开始布局或者已经采用容器技术来构建自己的云基础设施。
 
    在用容器设计新的微服务应用架构或者如何改造现有的应用时,应该了解哪些因素和相关特性,是企业在实施容器平台时必须要考虑的。
 
    很多传统行业和互联网企业相比在容器技术方面起步稍晚,但近两年随着容器关注度的空前火热,企业进步也很快,大力推进容器相关能力的建设。
 
    基于 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 的解决。
 
    任何新的技术都有着各自适用的场景,如何经受住实践的考验,并将新的技术转化为生产力才是重中之重。

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐