企业生产系统迁移至容器云平台难点解读
目前，容器平台应用于生产环境也已经现实可落地。容器以应用为中心，能够快速地在各个平台下部署运行，可以很好地满足应用的快速部署。但是容器运行时使用的是宿主机的内核，在同一台宿主机上的容器也会共享系统的资源，如果没有做好资源的规划及权限的控制，不仅容器之间会互相影响，甚至会让整个系统的受到威胁。另外，容器的网络也是在容器平台规划时需要考虑的一个重点，我们很多网络安全策略都是基于IP做的规则，但是一般而言同一个镜像运行的不同容器的IP是不一样的，一旦容器被重新调度，之前的安全策略便失效了，而新的容器并没有受到安全策略管理。容器平台上生产需要考虑的问题不止这一些，还有容器的调度，存储的规划等等。
随着容器技术的不断演进，以及企业应用的不断加深，容器平台上生产中遇到的问题也得到了很大程度的突破。容器平台厂家为实现容器平台上生产，也在不断优化各自的产品，推出新的解决方案。
为解决容器平台上生产中的诸多问题，社区最近组织答疑活动，邀请招银云创专家和某股份制银行专家一起，基于企业生产系统迁移至容器云平台的网络及安全方案进行探讨；并同时邀请红帽专家，围绕OpenShift4的特性，如何帮助企业基于OpenShift实现企业容器化混合云的价值进行答疑。
本文对活动中问答进行分类总结，供大家参考。
一、容器平台价值
1、容器云和传统的虚拟机比有什么优势？
@PanMichael：
优势：
a. 更快，可以实现秒级启动。
b. 更轻，更加轻量，往往一个容器镜像只有几十兆，可以快速在主机之间迁移，而虚拟机镜像往往是几个G。
c. 更强，性能更好。
并且有了Kubernetes容器编排引擎后，应用的水平扩展、服务发现、滚动升级、应用高可用等等特性变得非常容易实现。
基于此容器可以大大降低于低企业成本，资源成本及运维管理成本。当然容器也有较虚拟机不足的地方。
劣势：
a. 容器共用内核，隔离性低于虚拟机，也不够虚拟机安全。
b. 跨平台性低于虚拟机，容器只能运行在linux系统，而虚机可运行在windows/Linux/Unix系统。
@Steven99：
拿容器和虚拟机比较更准确，不是容器云。
容器优势明显，缺点也很明显。
容器轻量，可快速弹性伸缩，适合部署轻量的分布式应用或服务，但带来管理的复杂性，需要借助容器管理调度工具或者实现的容器云平台。
标准化，容器引擎使基础设施标准化，容器镜像使应用交付标准化，容器使运维调度管理标准化，容器镜像仓库使分发部署标准化。
一致性，容器的标准化使开发、测试、生产环境具备一致性，可以快速构建一致性的环境。
维护简单，一个容器通常部署一个服务或实例，而虚拟机通常很多服务和应用，所以其准备、启动、维护都相对简单很多。
另外需要强调一点的是，容器并不节省资源，在容器规模达到一定程度，能实现资源分时共享时才能节省资源。
@张家驹：
轻量级，资源利用率高扩展容易，最重要的是和微服务结合的好，当然用了PAAS以后你的蓝绿发布，应用构建，灰度发布都更简单。
2、传统应用是否应该迁移到容器环境，有没有意义，有什么值得参考的迁移方法论？
@Steven99：
不同应用有不同的要求，比如稳定性、可靠性、可扩展性等，在迁移之前需要明确容器是否满足应用的要求。应用迁云或迁容器云需要遵循相应的原则和方法，难以一概论之，具体的应用需要根据实际确定具体的方案。
@张家驹：
如果是传统应用做容器话的迁移，那没啥方法轮，如果是为服务改造有很多方法论，比如 绞杀模式 （Strangler） 以及 修缮者模式
二、容器平台架构方案
1、传统架构模式和云与Docker模式结合后如何解决网络和SDN的问题？
@PanMichael：
我们采用的方案是，容器建设在虚拟机或者物理机上，集群中的容器使用SDN网络方案，互相间通讯，同时也可以与宿主机同一网络的主机通信。但是集群外部机器要访问集群内部的服务，只能通过route/ingress/NodePort。
pod与pod之间网络通过networkpolicy做网络隔离，主机与主机之间的使用传统的防火墙来做隔离。
另外macvlan网络方案，可以让pod与宿主机在同一个网络，这种方式下容器间的网络隔离与传统方式一样，每个容器可以当作一个单独的主机。但这种方案生产应用并不常见。
@张家驹：
目前来看没有什么问题啊，传统网络和SDN的问题本身就可以通过网络厂家的设备来解决，如果你说的是PAAS自身的SDN如何同集群外的服务互联互通，那就是通过router来实现（或者是ingress和egress）。安全域的问题更多的是通过多集群和设计的问题来规避。
2、在私有云，在容器环境下安全区域怎么划分，是否设置DMZ区域？
@HugoXiao :
可以考虑部署多个容器集群来设置不同区域。测试环境、生产环境完全隔离的情况下，可考虑建设DMZ区以实现可能需要的镜像流转等场景。
@狄俄尼索斯：
安全组网在容器环境下并不需要改变，按照安全规范实施即可，确保安全优先
@PanMichael：
为了安全，可以部署多个容器集群来设置不同区域。一个集群作为DMZ区，另一个集群作为核心区，还可以有一个互联区的集群。
@gavin_zhang：
在多个网络区域布署不同的容器集群，DMZ，业务区可以分别多套集群，做为多可用区，提高可用性。
3、容器云是否有和SDN集成的方案？
@张家驹：
有很多，但是界面或者说管理能力展示的集成需要自己做，也就是OpenShift并不会有第三方SDN的管理功能，通常来说只要这个SDN厂家有CNI的呃插件，那么OCP4 就可以和他集成，当然如果需要提供售后支持的话，还需要该SDN厂家和红帽做认证。
@liufengyi：
有啊 比如和neutron集成 你可以根据需要自己开发cni的插件，开源实现里面也有kury（python实现）。
4、虚拟机与容器并行承载同一套应用系统是否可行
@asdf-asdf：
负载均衡实现虚拟机应用与容器应用共同支撑业务系统，这个业务场景没有先例。
既然上容器就需要服务治理等一系列微服务框架运维，vm技术和容器技术对应用来说如果不进行微服务化改造，是没有任何区分的。
所以你这个场景是可以实现，但 vm 会比容器快很多，容器需要多层网络转换。
@PanMichael：
我们公司的业务生产环境便是虚拟机与容器并行，容器中运行的是无状态的app及前端静态界面，而中间件及数据库等仍然运行在虚拟机中。
@Steven99：
完全没有问题，简单的你可以看做两个虚拟数据中心，分别部署一套应用系统，前端负载均衡器实现负载分发。所以部署在容器或者虚拟机对前端是不可见的，只要可访问就行。
5、如何按照网络隔离区域对容器集群规划？
@PanMichael：
这个主要看公司对网络安全的要求和成本的平衡。
a 方案每个区都部署一套集群的话，安全性高，但成本高，包括资源成本及维护成本等。
b 方案成本低，也能满足一定的隔离要求
开发测试环境一般更偏向于使用b方案，k8s/OpenShift网络支持多租户，能实现软隔离，及通过给节点作标记Label，定向调度的方式就能够满足隔离的要求。
但是生产环境是需要单独构建集群与开发测试环境隔离的。
6、如何保障容器镜像的安全防护？
@PanMichael：
我们使用的是集成在harbor中的clair容器镜像静态扫描工具。它会定期同步公共源镜像漏洞数据，并对harbor镜像仓库中的镜像做扫描。如果发现有问题会发出通知，且也支持webhook的方式对接公司统一的告警平台。
@张家驹：
红帽有一款产品叫QUAY可以做到你提到的所有功能。
三、容器平台应用
1、容器平台、微服务平台、devops平台在规划建设的时候如何能有序整合起来？
@Steven99：
容器平台是DevOps中的一部分， 不需要微服务平台，微服务部署于容器平台，在容器平台实现微服务管理和治理能力
@HugoXiao：
1、容器平台与服务治理在以下维度相同，需要从统一化进行管理：1）、应用管理；2）、服务管理；3）、实例管理；4）、聚合管理；采用统一权限中心管理，数据权限与操作权限灵活设置，以用户+权限定义产品形态和管理范畴。平台管理（重点在于资源管理），租户管理（重点在于应用管理和服务治理能力）。
2、在建设DevOps的过程中，需要结合企业自身开发运维的流程，与容器云与微服务治理平台的结合的过程中，更多的考虑整体DevOps过程中需要实现的场景，而不是仅仅考虑CICD。
@张家驹：
容器平台更多的是规范运维操作以及故障处理，微服务跟多的是做开发规范，DevOps工作的是工作流工具链的梳理，三个各有侧重点。
@PanMichael：
从不同的角度看才有了容器平台、微服务平台、devops平台。它们之间并不是独立的平台。
首先，容器平台是基础设施，微服务平台和devops平台部署在上面。
其次，devops平台建设过程中，需要考虑微服务架构，采用不同的方案在构建devops流水线时也会有所不同。
最后，如果要做持续部署的话，需要考虑公司的安全规范与流程规范。
以下是我们的实践：
1、分别部署了开发测试容器集群与生产容器集群。
2、devops工具链与流水线构建只在开发测试环境上，构建与测试完成后，通过人工审核后才允许将镜像同步到生产集群，再单独走部署流水线。
3、统一微服务架构，及规范。我们互联网应用都采用spring cloud微服务架构，技术统一后devops流水线也方便统一及优化、维护。
2、容器平台上生产的可靠性及容器平台与devops能否对接？
@PanMichael：
技术上是完全可行的，还需要考虑一些非技术的因素。
由于生产环境的特殊性，公司会有很多复杂的安全规范及流程规范，它们限制devops直接对接生产环境。这个其实与是否在容器平台无关。
安全规范、流程规范，很多公司是一条红线，特别是金融行业，因为多年来正是遵循它们才保证了业务的安全可靠，还有各种认证、审计的需要。
当然技术和规范也都是与时俱进，不断发展的。现在有些公司把流程规范开始融入到持续部署的流程中了，包括临时授权等，也都可以作为流水线中的一个环节。
@Steven99：
容器平台是devops的一部分，devops不是一个平台
需求提议、项目管理、开发测试、部署交付、运维运营、监控反馈、持续改进，容器平台的定位和价值在这些闭环过程中。
3、如何更好地实现现有系统的容器化迁移？
【问题描述】现有系统基本上都是传统架构，开发时也为考虑session共享，请求基本都是有状态的，当往容器里迁移时，就会遇到很大的麻烦，是否有成本和周期比较的解决方案？
@张家驹：
这个真没有，你不能指望平台解决应用的问题
4、部署流计算框架和机器学习平台在红帽容器平台上有什么要注意的？
@张家驹：
主要是用到GPU的话，务必做好PAAS集群和GPU的配置，其他没有太多需要注意的，很多框架已经在k8s上部署运行了很长时间了。OCP没有额外的要求
四、OpenShift 相关
1、OpenShift 4推荐的直接部署物理机还是虚拟机？为物理机部署提供了什么便利？
@张家驹：
OpenShift4 部署在物理机和虚拟机都行，但是红帽推荐部署在虚拟化平台上，因为OCP4以后增加了很多基础架构的管理功能，其中就包括针对OpenShift 节点的自动扩容和缩容。很有用。
2、OpenShift 4对单集群多租户的支持怎么样？
@PanMichael：
OpenShift中不仅有用户，还有用户组。OpenShift的账号管理最简单是使用HtPasswd方式，同时OpenShift可以与多种系统账号对接，如OpenLdap，KeyStore，GitLab，GitHub，OpenID等。
3、OpenShift 4对Serverless的支持情况？
@张家驹：
红帽ocp4 支持knative，不过目前应该是beta版。具体请看 https://github.com/openshift-knative/docs/
4、正在生产运行的OpenShift3是否可以原地升级到OpenShift4？如果不行，该如何升级？
@张家驹：
不行，未来从OCP3系列到OCP4系列都是迁移，当然红帽会有官方的迁移工具来帮助客户做这个事情，但是也需要准备停机窗口，并且两套集群一个是老得ocp3 集群一个是ocp4集群。
5、金融行业对安全非常重视，OpenShift4和RHEL8在安全方面改进的体现有哪些？
@张家驹：
OpenShift一直关注安全 我们的10层安全体系从基础设施层到标准化基础中间件镜像都在层层为客户企业安全进行保障。ocp4的比以前多了coreos作为操作系统选项：CoreOS裁减了传统linux中无用的软件，减少了依赖冲突和attack surface，系统更小、更紧凑、更安全。另外 用来取代传统Docker容器的另一种选择其中podman是最重要的组件之一。其主要优势是无需Docker守护进程，以普通用户形式启动，是一种更安全的容器管理器。
6、OpenShift与Rancher如何选择，是否有可比较性？
@PanMichael：
OpenShift有开源版本，是免费的。
它们俩各有各的特点。
OpenShift：
1、设计了ImageStream，BuildConfig与DeploymentConfig等资源对象，及s2i构建方法，方便了开发者实施Devops。
2、添加了一个内部镜像仓库。
3、使用Route资源，为应用提供了一个公共统一的访问入口。类似于Ingress，使用起来比Ingress方便。
4、提供了一个友好的可视化界面。
5、对容器有更多的安全策略，更安全
6、有更高的可靠性。作为RedHat的企业级容器平台，红帽会对集群做详细的测试，修复bug。
7、一般版本会落后k8s一个大版本
8、一般为只管理单个OpenShift集群
Rancher:
1、具有良好的界面
2、方便管理多个k8s集群
3、对网络插件的选择会比OpenShift更加灵活
4、与k8s版本同步，及时拥有k8s最新的特性
个人认为，单集群管理使用OpenShift，更稳定，更简单，也更安全，而如果是要管理多集群，选择Rancher。不过OpenShift 4起红帽也支持多集群管理，但还能私有化部署。
两种方案都有不少的企业客户选择，因为都是基于k8s， 功能上都差不多 。不管是构建DevOps流水线，还是生产部署原生应用上。
7、OpenShift与其他容器云厂商产品的异同点有哪些？
@PanMichael：
上一个问题中介绍了OpenShift与Rancher的差异，可以作为参考。
还有需要补充一点的是，红帽是继google和社区之后k8s最大的贡献者，不少k8s中的特性是来自于OpenShift，比如说RBAC。同时目前很热的operator是coreos的产品，而coreos现在也是红帽的了。
五、Redhat 相关
1、RHEL8是否对6上的命令还能继续兼容，比如服务命令，6迁移到8有什么注意点？
@asdf-asdf：
rhel8.x 在上线前 一般会等到8.3 第三个维护版本进行上线系统更新。目前在8.0和8.1还有8.2不建议使用。而且从6版本直接升级到8版本,跨度过大业务系统是否支持,都要考虑。只是命令变化不会有太多技术问题,修改下运维脚本没问难度。
@张家驹：
命令会有所改变，关键是8 比6 新太多了，迁移前务必做应用测试，然后再迁移
欢迎点击文末阅读原文到社区讨论交流
以上内容贡献者：PanMichael 招银云创资深架构师、张家驹 红帽首席架构师、gavin_zhang 某股份制银行资深架构师、Steven99 软件架构设计师、HugoXiao 博云企业级PaaS及云管理解决方案中心业务咨询顾问、狄俄尼索斯 UProject软件架构设计师、liufengyi 某互联网银行软件架构设计师、asdf-asdf cloudstone研究学者
相关推荐：
红帽容器技术及方案探讨
http://www.talkwithtrend.com/Document/detail/tid/427399
欢迎关注社区以下技术主题 ，将会不断更新优质资料、文章。地址：
容器云：http://www.talkwithtrend.com/Topic/98447
OpenShift：http://www.talkwithtrend.com/Topic/91779
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场