企业生产系统迁移至容器云平台的众多难题

自从2013年Docker应用开源以来，容器技术飞速发展，它彻底改变了PaaS原先的发展轨迹。2014年Google发布的容器编排应用Kubernetes，经过5年的发展，更是已经成为了现代容器平台的事实标准，容器平台应用于生产环境也已经现实可落地。

与之前的虚拟技术相比，容器技术具有更快、更轻、更强的优势。

更快，体现在容器可以实现秒级启动。

更轻，体现在容器更加轻量，往往一个容器镜像只有几十兆，可以快速在主机之间迁移，而虚拟机镜像往往是几个G。

更强，体现在容器的性能更好。容器是直接调用硬件资源，不存在虚拟化层，所以它的性能接近于原生应用。

容器以应用为中心，能够快速地在各个平台下部署运行，可以很好地满足应用的快速部署。

但是容器运行时使用的是宿主机的内核，在同一台宿主机上的容器也会共享系统的资源，如果没有做好资源的规划及权限的控制，不仅容器之间会互相影响，甚至会让整个系统的受到威胁。那么怎样能够避免这些问题呢？这是在容器平台上生产前必须考虑的问题。

另外，容器的网络也是在容器平台规划时需要考虑的一个重点，我们很多网络安全策略都是基于IP做的规则，但是一般而言同一个镜像运行的不同容器的IP是不一样的，一旦容器被重新调度，之前的安全策略便失效了，而新的容器并没有受到安全策略管理。另外生产中的主机一般会配置多个网络，有业务网，管理网等，那么容器化后是否有办法支持多网络平面呢？

当然容器平台上生产需要考虑的问题不止这一些，比如说容器的调度，存储的规划等等。

但随着容器技术的不断演进，以及企业应用的不断加深，容器平台上生产中遇到的问题也得到了很大程度的突破。此外，容器生态圈中的重要力量——容器平台厂家为更能满足企业客户生产的要求，实现容器平台上生产，也在不断优化各自的产品，推出新的解决方案。

其中，2019年5月红帽推出了RHEL8和第四代OpenShift容器平台，该版本融合了OpenShift与CoreOS两家容器平台大玩家的技术。相对于第三代OpenShift，新一代OpenShift拥有很多新的特性，比如说Operator管理组件的生命周期，添加了多集群管理等。同时网络及安全方面也是OpenShift4.1版本升级的一个重要部分。

为解决容器平台上生产中的诸多问题，本次活动不仅邀请到招银云创专家和某股份制银行专家一起，基于企业生产系统迁移至容器云平台的网络及安全方案进行探讨；并同时邀请红帽专家，围绕OpenShift4的特性，如何帮助企业基于OpenShift实现企业容器化混合云的价值进行答疑。
企业生产系统迁移至容器云平台的网络及安全方案探讨—暨红帽容器化混合云解决方案在线发布活动（精彩回顾）

答疑结束后，对活动中提出的问题进行了分类总结，供大家参考。

容器平台价值

容器云和传统的虚拟机比有什么优势呢？
解答1：
优势：
a. 更快，可以实现秒级启动。
b. 更轻，更加轻量，往往一个容器镜像只有几十兆，可以快速在主机之间迁移，而虚拟机镜像往往是几个G。
c. 更强，性能更好。

并且有了Kubernetes容器编排引擎后，应用的水平扩展、服务发现、滚动升级、应用高可用等等特性变得非常容易实现。
基于此容器可以大大降低于低企业成本，资源成本及运维管理成本。当然容器也有较虚拟机不足的地方。

劣势：
a. 容器共用内核，隔离性低于虚拟机，也不够虚拟机安全。
b. 跨平台性低于虚拟机，容器只能运行在linux系统，而虚机可运行在windows/Linux/Unix系统。

解答2：
拿容器和虚拟机比较更准确，不是容器云

容器优势明显，缺点也很明显

容器轻量，可快速弹性伸缩，适合部署轻量的分布式应用或服务，但带来管理的复杂性，需要借助容器管理调度工具或者实现的容器云平台
标准化，容器引擎使基础设施标准化，容器镜像使应用交付标准化，容器使运维调度管理标准化，容器镜像仓库使分发部署标准化
一致性，容器的标准化使开发、测试、生产环境具备一致性，可以快速构建一致性的环境
维护简单，一个容器通常部署一个服务或实例，而虚拟机通常很多服务和应用，所以其准备、启动、维护都相对简单很多
另外需要强调一点的是，容器并不节省资源，在容器规模达到一定程度，能实现资源分时共享时才能节省资源

解答3：
轻量级，资源利用率高扩展容易，最重要的是和微服务结合的好，当然用了PAAS以后你的蓝绿发布，应用构建，灰度发布都更简单

传统应用是否应该迁移到容器环境，有没有意义，有什么值得参考的迁移方法论？
解答1：
不同应用有不同的要求，比如稳定性、可靠性、可扩展性等，在迁移之前需要明确容器是否满足应用的要求。应用迁云或迁容器云需要遵循相应的原则和方法，难以一概论之，具体的应用需要根据实际确定具体的方案

解答2：
如果是传统应用做容器话的迁移，那没啥方法轮，如果是为服务改造有很多方法论，比如 绞杀模式 （Strangler） 以及 修缮者模式

容器平台架构方案

传统架构模式和云与docker模式结合后如何解决网络和SDN的问题？
解答1：
我们采用的方案是，容器建设在虚拟机或者物理机上，集群中的容器使用SDN网络方案，互相间通讯，同时也可以与宿主机同一网络的主机通信。但是集群外部机器要访问集群内部的服务，只能通过route/ingress/NodePort。
pod与pod之间网络通过networkpolicy做网络隔离，主机与主机之间的使用传统的防火墙来做隔离。
另外macvlan网络方案，可以让pod与宿主机在同一个网络，这种方式下容器间的网络隔离与传统方式一样，每个容器可以当作一个单独的主机。但这种方案生产应用并不常见。

解答2：
目前来看没有什么问题啊，传统网络和SDN的问题本身就可以通过网络厂家的设备来解决，如果你说的是PAAS自身的SDN如何同集群外的服务互联互通，那就是通过router来实现（或者是ingress和egress）。安全域的问题更多的是通过多集群和设计的问题来规避。

在私有云，在容器环境下安全区域怎么划分，是否设置DMZ区域？
解答1：
可以考虑部署多个容器集群来设置不同区域。测试环境、生产环境完全隔离的情况下，可考虑建设DMZ区以实现可能需要的镜像流转等场景。

解答2：
安全组网在容器环境下并不需要改变，按照安全规范实施即可，确保安全优先

解答3：
为了安全，可以部署多个容器集群来设置不同区域。一个集群作为DMZ区，另一个集群作为核心区，还可以有一个互联区的集群。

解答4：
在多个网络区域布署不同的容器集群，DMZ，业务区可以分别多套集群，做为多可用区，提高可用性

容器云是否有和SDN集成的方案？
解答1：
有很多，但是界面或者说管理能力展示的集成需要自己做，也就是openshift 并不会有第三方SDN的管理功能，通常来说只要这个SDN厂家有CNI的呃插件，那么OCP4 就可以和他集成，当然如果需要提供售后支持的话，还需要该SDN厂家和红帽做认证。

解答2：
有啊 比如和neutron集成 你可以根据需要自己开发cni的插件，开源实现里面也有kury（python实现）

虚拟机与容器并行承载同一套应用系统是否可行？
解答1：
负载均衡实现虚拟机应用与容器应用共同支撑业务系统, 这个业务场景没有先例
既然上容器就需要服务治理等一系列微服务框架运维,
vm技术和容器技术对应用来说如果不进行微服务化改造, 是没有任何区分的,
所以你这个场景 是可以实现但 vm 会比 容器快很多, 容器需要多层网络转换

解答2：
我们公司的业务生产环境便是虚拟机与容器并行，容器中运行的是无状态的app及前端静态界面，而中间件及数据库等仍然运行在虚拟机中。

解答3：
完全没有问题，简单的你可以看做两个虚拟数据中心，分别部署一套应用系统，前端负载均衡器实现负载分发。所以部署在容器或者虚拟机对前端是不可见的，只要可访问就行

如何按照网络隔离区域对容器集群规划？
解答：
这个主要看公司对网络安全的要求和成本的平衡。
a 方案每个区都部署一套集群的话，安全性高，但成本高，包括资源成本及维护成本等。
b 方案成本低，也能满足一定的隔离要求
开发测试环境一般更偏向于使用b方案，k8s/openshift网络支持多租户，能实现软隔离，及通过给节点作标记Label，定向调度的方式就能够满足隔离的要求。
但是生产环境是需要单独构建集群与开发测试环境隔离的。

如何保障容器镜像的安全防护？
解答1：
我们使用的是集成在harbor中的clair容器镜像静态扫描工具。它会定期同步公共源镜像漏洞数据，并对harbor镜像仓库中的镜像做扫描。如果发现有问题会发出通知，且也支持webhook的方式对接公司统一的告警平台。

解答2：
红帽又一款产品叫QUAY可以做到你提到的所有功能，更详细的信息还请看红帽工程师的博客： http://www.10tiao.com/html/360/201806/2663487906/1.html

容器平台应用

容器平台、微服务平台、devops平台在规划建设的时候如何能有序整合起来？
解答1：
容器平台是DevOps中的一部分， 不需要微服务平台，微服务部署于容器平台，在容器平台实现微服务管理和治理能力

解答2：

1. 容器平台与服务治理在以下维度相同，需要从统一化进行管理：1、应用管理；2、服务管理；3、实例管理；4、聚合管理；采用统一权限中心管理，数据权限与操作权限灵活设置，以用户+权限定义产品形态和管理范畴。平台管理（重点在于资源管理），租户管理（重点在于应用管理和服务治理能力）。

   1. 在建设DevOps的过程中，需要结合企业自身开发运维的流程，与容器云与微服务治理平台的结合的过程中，更多的考虑整体DevOps过程中需要实现的场景，而不是仅仅考虑CICD。

解答3：
容器平台更多的是规范运维操作以及故障处理，微服务跟多的是做开发规范，DevOps工作的是工作流工具链的梳理，三个各有侧重点。

解答4：
从不同的角度看才有了容器平台、微服务平台、devops平台。它们之间并不是独立的平台。
首先，容器平台是基础设施，微服务平台和devops平台部署在上面。
其次，devops平台建设过程中，需要考虑微服务架构，采用不同的方案在构建devops流水线时也会有所不同。
最后，如果要做持续部署的话，需要考虑公司的安全规范与流程规范。
以下是我们的实践：

1. 分别部署了开发测试容器集群与生产容器集群。
2. devops工具链与流水线构建只在开发测试环境上，构建与测试完成后，通过人工审核后才允许将镜像同步到生产集群，再单独走部署流水线。
3. 统一微服务架构，及规范。我们互联网应用都采用spring cloud微服务架构，技术统一后devops流水线也方便统一及优化、维护。

容器平台上生产的可靠性及容器平台与devops能否对接？
解答1：
技术上是完全可行的，还需要考虑一些非技术的因素。
由于生产环境的特殊性，公司会有很多复杂的安全规范及流程规范，它们限制devops直接对接生产环境。这个其实与是否在容器平台无关。
安全规范、流程规范，很多公司是一条红线，特别是金融行业，因为多年来正是遵循它们才保证了业务的安全可靠，还有各种认证、审计的需要。
当然技术和规范也都是与时俱进，不断发展的。现在有些公司把流程规范开始融入到持续部署的流程中了，包括临时授权等，也都可以作为流水线中的一个环节。

解答2：
容器平台是devops的一部分，devops不是一个平台
需求提议、项目管理、开发测试、部署交付、运维运营、监控反馈、持续改进，容器平台的定位和价值在这些闭环过程中。

如何更好地实现现有系统的容器化迁移？
解答：
这个真没有，你不能指望平台解决应用的问题

部署流计算框架和机器学习平台在红帽容器平台上有什么要注意的？
解答：
主要是用到GPU的话，务必做好PAAS集群和GPU的配置，其他没有太多需要注意的，很多框架已经在k8s上部署运行了很长时间了。OCP没有额外的要求

Openshift4特性

Openshift 4推荐的直接部署物理机还是虚拟机？为物理机部署提供了什么便利？
解答：
Openshift4 部署在物理机和虚拟机都行，但是红帽推荐部署在虚拟化平台上，因为OCP4以后增加了很多基础架构的管理功能，其中就包括针对openshift 节点的自动扩容和缩容。很有用

OpenShift 4对单集群多租户的支持怎么样？
解答：
OpenShift中不仅有用户,还有用户组。OpenShift的账号管理最简单是使用HtPasswd方式，同时OpenShift可以与多种系统账号对接，如OpenLdap，KeyStore，GitLab，GitHub，OpenID等。

OpenShift 4对Serverless的支持情况？
解答：
红帽ocp4 支持knative 啊，不过目前应该是beta版。具体请看 https://github.com/openshift-knative/docs/

正在生产运行的OpenShift3是否可以原地升级到OpenShift4？如果不行，该如何升级？
解答：
不行，未来从OCP3系列到OCP4系列都是迁移，当然红帽会有官方的迁移工具来帮助客户做这个事情，但是也需要准备停机窗口，并且两套集群一个是老得ocp3 集群一个是ocp4集群。

金融行业对安全非常重视，OpenShift4和RHEL8在安全方面改进的体现有哪些？
解答：
openshift一直关注安全 我们的10层安全体系从基础设施层到标准化基础中间件镜像都在层层为客户企业安全进行保障。ocp4的比以前多了coreos作为操作系统选项：CoreOS裁减了传统linux中无用的软件，减少了依赖冲突和attack surface，系统更小、更紧凑、更安全。另外 用来取代传统docker容器的另一种选择其中podman是最重要的组件之一。其主要优势是无需docker守护进程，以普通用户形式启动，是一种更安全的容器管理器。

OpenShift与其它容器平台比较

Openshift与Rancher如何选择，是否有可比较性？
解答：
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流水线，还是生产部署原生应用上。

openshift 与其他容器云厂商产品的异同点有哪些？
解答：
上一个问题中介绍了Openshift与Rancher的差异，可以作为参考。

还有需要补充一点的是，红帽是继google和社区之后k8s最大的贡献者，不少K8S中的特性是来自于OpenShift，比如说RBAC。同时目前很热的operator是coreos的产品，而coreos现在也是红帽的了。

红帽容器化混合云跟其他友商的方案在稳定性、安全性上有哪些不同，是否有更好的表现？
解答：
容器就是linux，红帽的RHEL是最安全的，因此红帽的PAAS平台必然也是最安全的，当然红帽的研发策略一直是做减法，把最重要和最稳定的特性和代码放到自己的企业版，因此在你说的稳定性和安全性上，红帽一定是全球第一，但是特性上不一定，国内创业公司都在做加法，所以特性上都会比红帽PAAS多那么一点

Redhat

RHEL8否对6上的命令还能继续兼容，比如服务命令，6迁移到8有什么注意点？
解答1：
rhel8.x 在上线前 一般会等到8.3 第三个维护版本进行上线系统更新
目前在8.0和8.1还有8.2不建议使用
而且从6版本直接升级到8版本,跨度过大业务系统是否支持,都要考虑
只是命令变化不会有太多技术问题,修改下运维脚本没问难度

解答2：
命令会有所改变，关键是8 比6 新太多了，迁移前务必做应用测试，然后再迁移