企业如何基于OpenShift容器云平台实现微服务改造的分布式应用集成和流程自动化？活动总结

在企业级软件应用开发中，长期以来，API、服务、数据以及系统的集成都是最具挑战性同时也是最基本的需求。在过去，我们会将这些独立的应用以点对点的方式进行集成，这种方式随后被企业服务总线（enterprise service bus，ESB）和面向服务架构（service-oriented architecture，SOA）所替代。但是，在现代微服务和云原生架构中，我们很少再去讨论应用集成了。但这并不意味着这种现代架构已经解决了企业应用集成的所有挑战。应用集成的挑战几乎没有什么变化，但是我们解决它们的方式却发生了变化。

“微服务”的概念兴起于四五年前，近几年尤其火热，各大企业都在进行微服务化改造和微服务建设。说起微服务，不得不提来自Martin Flower的《Microservices》文中将发展多年的微服务架构进行了重要性总结，推动了微服务的流行。经过微服务架构改造的系统会变得更加复杂，这种复杂性体现在一个软件的全生命周期的所有环节，业界大师Martin Fowler建议微服务要基于一个基础平台最好是一个PaaS平台。 其实不仅是PaaS，这个平台需要涵盖DevOps、容器云、微服务框架三个领域，DevOps平台用于支撑微服务的全生命周期数字化协作，容器以其不可变性和自给自足的特点成为微服务部署与运维的最佳选择，微服务之间通过分布式调用框架所提供的服务注册发现机制、服务路由、集群容错等特性以去中心化的方式进行协同。在微服务化之后，业务模块拆更细，流程变碎，有效地实现分布式应用集成和流程自动化是企业生产环境容器平台建设的挑战。

红帽OpenShift是一个企业就绪型 Kubernetes 容器平台，可以实现全堆栈自动化运营，以管理混合云和多云部署。红帽 OpenShift企业版已对分布式应用集成和流程自动化进行了企业级应用优化。

本次活动，社区邀请到了红帽容器资深技术专家王洪涛和魏新宇，为大家分享基于OpenShift的分布式应用集成和流程自动化解决方案及行业实践，同时也邀请了多家金融企业同行在线交流。

点击链接进行精彩回顾

本次讨论主要分为以下几个方面：

1. 应用微服务化及其实现
   2.应用入容器云的标准
2. 容器云 /Openshift 架构
3. 容器云 /Openshift 安全及存储
4. 容器云 /openshift 对接 DevOps 周边环境
5. Openshift 与 Kubernetes 差异性

应用微服务化及其实现

微服务网关，像 Istio 和 API 网关，类似于 KONG 等，有什么区别？

现在谈到 ServiceMesh ，提的都是 Istio ， Linkerd 这些，这个和 API 网关，像 KONG 等，有什么区别？微服务网关和 API 网关在容器平台实现上有什么异同点？

解答：

API 网关，从技术上，只是微服务治理的其中一环。
servicemesh 对标的是传统的 srpingcloud 。
kong 对标的是 springcloud 里的 zuul 。
servicemsh 里面，还有服务发现、分布式追踪、安全、可视化、监控等能力。

有没有非 JAVA 应用，迁移上容器云的需要注意那些？有没有一些资料推荐？

现在 java 类的微服务框架资料比较多，有没有其他语言，类似于 python 等的微服务改造材料推荐？有部分自研系统是通过 django DRF 和 vue 前后端分离来实现的，这种单体应用往容器云上迁移的时候有什么建议？

解答：

1， 这个问题很具体，假设纯粹技术来说， Docker 可以支撑所有能容器运行的所有服务；但是有很多业务应用本身对于容器来说可能是个不切实际的。诸如需要硬件设备驱动的应用，那么 Docker 就不能满足；

2， 常规的业务应用系统，只要独立的某种架构，其实基本上都可以到 Docker 下面去运行， Django DRF 是可以入容器的服务，但是否把 Django + Vue.js 一起放到容器去部署，还是 Django 容器 + Vue.js 容器来联合部署，则需要看两者之间的通信连接，业务应用和服务的连接；

3， 网络技术是个关键，尤其像这种迁移入容器的方案，更需要网络对接。

如何划分流程自动化覆盖范围界限？微服务化的流程全连路图所需自动化的自动化标准工具技术选型？

解答 1 ：

红帽的流程自动化工具是 rhpam ，它里面实际上也包括规则引擎的内容。对应的开源社区项目是： drools ， jbpm ， bpmn 等。方案可以提供那种图形化的流程展示和拖拽式生成流程。红帽对比也提供企业级支持。

解答2：

这次介绍里提到的自动化，其实更多的是业务规则到流程的自动化，只是在 paas 的这个大话题下，焦点都关注在了 devops 相关的自动化环节。

自动化主要包括：
比较容易实现的是批量作业自动化、自动巡检。
以及实现难度中等的软件批量分发部署和配置与版本管理自动化。这部分需要结合 PaaS 平台的若干能力实现，主要就是 openshift 或者 k8s ，再加上一些 ansible tower 的工具， satellite 之类。
还有实现起来最复杂的应急故障检查和容灾管理自动化。这还需要加入一些咨询服务。

当然，还有自动化测试等领域。

微服务的流程全链路，主要有些：需求管理 Jira ，自动化测试 selenium ，代码扫描 ,Sonarqube ， ,CICD jenkins 或者 TFS ，等

容器云 /Openshift 安全及存储

针对金融行业互联网业务生产环境容器云安全方面该做哪些设计？选用什么产品进行保障？

金融行业面向互联网的渠道业务，通常部署在 DMZ 区，经常会受到攻击。

采用容器平台，从主机、 docker 、应用层面该做哪些安全防护？

最佳实践案例是什么 ? 具体用什么产品？

我们想到的是：主机通过 vmware 进行隔离，通过趋势安全对虚拟化进行防护（操作系统）。

解答1 ：

ocp 的保护手段比较核心的有：通过 ovs 实现项目之间的隔离（ ovs 多租户），提供安全加固后的容器镜像，红帽提供 300 多个；访问应用可以使用双向认证；不让 root 用户运行容器等。如果是第三方的专业安全工具，比如 blackduck ，可以无缝和 ocp 集成，功能更多。金融行业的生产和非生产 ocp 通常做物理隔离，两套集群。非生产的 dev test sit 之类的，可以做项目隔离。

解答2：

主机方面，选择靠谱的，有厂商支持的操作系统，比如一般不推荐 centos 。
另外，建议开启 SELINUX 之类的安全策略， OpenShift 安装默认开启。
Docker 层面，或者说容器层面，选择更安全的运行时，比如现在的 podman ，不需要 root 启动，没有守护进程。
镜像层面，传统的 CVE 漏洞扫描，依然有效。可以选择一些周边的安全产品厂商，如果 BlackDuck 。
安全方面，说来话长。。。。。。。
红帽推荐 10 层安全机制，每一层都需要保护。

针对金融行业容器云 存储使用方案建议？ FC-SAN/NAS/CEPH 还是？？？

针对金融行行业生产环境，搭建 openshift 容器云，共享存储平台该如何选择？

传统的块存储 FC-SAN 、 NFS ，还是分部署存储（ ceph hdfs) 。

针对有状态容器该如何从中作出选择 ? 有何优劣

我个人倾向用传统存储厂家提供 NAS 存储。

解答：

ocp 支持多种存储类型。如果 pod 不需要共享 pv ，用 ceph3 的 rbd 是不错的选择。 bluestore 的性能提升了不少，尤其是写性能。如果有少量的 pod 需要共享 pv ，可以用 cehfs ，但这种性能不如 rbd 。如果大量 pod 都需要共享 pv ，那么用企业级 nas 是比较好的选择。高端 fc 存储的 lun 是没法直接挂给 pod 的，也需要做成文件系统。

如何实现容器基础镜像的安全和合规性管理？
解答：
镜像安全扫描
1 、可以使用 harbor 内的镜像漏洞扫描功能，集成的是 clair 漏洞库。
2 、企业内网可以定期同步更新漏洞数据库， harbor 是放在 postgresql 中，导入即可。
合规性管理
1 、 Harbor 会对某些镜像的拉取 （ pull ） 加以限制，主要是那些被安全策略进行了漏洞 （ CVE ） 扫描，且结果符合限制条件的镜像（例如含义严重级别漏洞的镜像）。一些例外场景，可以配置漏洞白名单。

对于OpenShift，应用内产生的持久化数据，有哪些方案进行存储，同时数据保护这块是怎么做的？

解答：
OpenShift 在数据中心内部部署的时候，如果是生产环境，如果没有多 pod 共享一个 pv 的情况，可以使用 Ceph RDB ，也能还不错。如果有少量的多 pod 共享，可以使用 CephFS 。如果有大量的 pod 都需要共享 pv ，那么可以选用企业级的 NAS 。 Ceph 通过三副本进行数据保护，企业级 NAS 则通过自身存储的机制可以实现。

红帽OpenShift在安全方面有什么特点和加固？
红帽 OpenShift 在安全方面有什么特点和加固，如何防止黑客提权破坏宿主机。

解答：
首先， OpenShift 是包含了 K8S 的企业级 PaaS 平台。红帽每个 OpenShift 的版本都会修复 K8S 上游社区 100 多个缺陷。并且进行了大量安全性和可靠性的测试。 红帽 OpenShift 早在几年 2 年前就通过了 PCI-DSS 安全标准。也就是支付卡行业数据安全标准。
此外，红帽在如下几个方面，对 OpenShift 进行了安全加固
1.Container Content （容器内容）
2.Container Host & Multi-tenancy ( 容器宿主机和多租户 )
3.Container Registries （容器注册仓库）
4.Building Containers （构建容器）
5.Deploying Containers （部署容器）
6.Container Platform （容器平台）
7.Network Isolation （网络隔离）
8.Storage （存储）
9.API Management （ API 管理）

容器云 /openshift 对接 DevOps 周边环境

OpenShift 上 DevOps 流程中角色、权限、功能的相关问题？

1.OpenShift 上 DevOps 流程是否有角色的概念？比如开发、运维、测试，这些角色在平台上的功能和权限是如何定义的？

2.OpenShiftt 上 DevOps 流程是否支持管理上的审批功能？如果支持，是实现在流水线上的？还是独立的审批流程？

解答 1 ：

1， Openshift 是完全有自在的 BRAC 管理体系

2， 只要 BRAC 源支持，就可以集成；

3， 审批部分是将人为管理流程与 CI/CD 流水线相结合的集成，就看展现那些流水线粒度信息给审批者了，这个需要集成开发。

解答 2 ：

1、 有。 OpenShift 本身有角色概念。通过 RBAC 实现角色授权。

2、 支持，流水线上的。

OpenShift 的流程自动化如何和现有的 ITIL ，工单系统对接？
更想关注 OpenShift 的流程自动化和现在哪些 ITIL 有完美对接的案例

解答 1 ：
1 ， ITIL 及工单更偏重于日常管理流程， Openshift 的流程自动化是偏重于业务 - 应用服务诞生的流程，所以两者本质上有区别；
2 ， openshift 流程自动化，是服务编排的自动化过程，涉足的相关负责人是需要 ITIL 流程通知到对应的负责人员，所以期待 Openshift 自动化流程与 ITIL 工单流程相结合，共同服务到业务 - 应用服务的运营运维；
3 ，如何对接，就需要梳理和抽象 ITIL 工单流程中要交互的目标元素和 Openshift 对象元素，两者粒度的衔接，如果衔接完善，就可以对接，否则就只能通过负责人 ID 来进行衔接，此时的对接，基本上都是人为流程，相对来说集成负责程度增加了。
4 ，流程自动化和工单流转自动化，是需要自动化流程引擎的，一个服务编排，一个是服务流转，一个是自动化，一个是粒度元素审批和信息交互，有差别，也有交叉。说实话，挺复杂的！

解答 2 ： OpenShift 平台本身涉及的流程主要在于镜像的构建、版本管理、同步，以及应用的发布、启停。和 ITIL 的集成工单系统对接，也应该在于这些环节。 实现起来最复杂的是：应急故障检查和容灾管理。最好同时借助于其它工具，比如：通过 Ansible Tower + Satellite + ITIL + BPM + 专业服务 / 其他开源工具实现

openshift部署ironic插件管理物理机，目前能否集成到蓝鲸运维系统中？
解答：
OpenShift 是一个大平台，提供管理 API 与第三方系统对接。可以集成到任何第三方系统。 容器云应用集成

openshift的分布式pass平台和Knative Serverless在支持kubernetes上有哪些区别？

解答：
OpenShift 也是使用的 Knative 以及 ISTIO 的部分功能来实现 Serverless 。

如何在OpenShift上实现微服务系统发布的流程自动化？
是通过 jenkins 来做 CICD 吗？有没有比较好的方案？麻烦各位大佬解答

解答：
没错，现阶段，大多数都是使用的 Jenkins 。 openshift 3 和 openshift 4 也都是内置了 Jenkins 组件实现。

红帽openshift在devops发布过程中与流程平台的对接上是否有相关案例？

解答：
之前有客户提出过类似的需求， 但是具体这方面的案例，没有专门了解过。 我个人理解暂时没有必要，因为 DevOps 之前大多使用 Jenkins 或者集成第三方的 DevOps 工具实现，这些工具多数已提供了流程处理。足够使用了。 至于未来，随着原生 K8S DevOps 工具的发展，比如 Tekton ，也许会引入流程平台。 但是等未来再说，这方面的需求没有这么复杂。也不应该这么复杂。

红帽OpenShift容器平台中实现CICD与Jenkins有什么优势和特点？
红帽 OpenShift 容器平台中实现 CICD 与 Jenkins 有什么优势和特点，企业在使用容器平台时，推荐使用企业原有 Jenkins 流程还是使用容器平台的 CICD 解决方案？

解答：
OpenShift3 中，实现 CI/CD 通常会借助于 Jenkins 来实现 Pipeline 管理或者 CI 。 OpenShift4.2 中的 CI/CD 已经可以不适用 Jenkins 了，适用 teckton 实现 pipeline 管理。 OpenShift 上实现 CI/CD ，推荐的方案是使用 teckton 。如果在上 openshift 之前已经使用了 jenkins 做 CI ，也可以延续以前的做法。

应用入容器云的标准

openshift 支持 weblogic 中间件的部署吗？

openshift 目前支持部分中间件，对于暂不支持的是否也需要像 docker 一样创建镜像

解答：

1， 首先 Weblogic/ WebSphere Application Server 是可以入容器 /Docker 的，只不过就是 image 达 几个 GB size 而已

2， 大 Size image 也可以入 Docker ，就是启动速度慢而已；

3， 如果是测试环境，我觉得是完全可以采用，生产环境说实话不建议。理由主要是日志管理比较复杂，不具有传统那么方便。

4， 符合场景下的迁移或改造是可以去测试使用。

为了上 openshift ，传统应用进行无状态化改造的过程中，有哪些特别需要注意的地方或者经验分享？

解答 1 ：

梳理传统应用的交互内容数据集，如果是大而全的紧耦合数据集交互，现将梳理和拆分可以微服务化的松耦合分布式数据集，再进行应用改造；
如此这样可以分步骤、分阶段进行改造；完全颠覆性重构，付出的代价估计比较大，投入成本和相应的运维体系、支撑体系、工具链体系都得配套随着业务改造而增加，不仅学习成本高，维护粒度反而增加，为业务运维人员增加不小的工作量。
1 ，先梳理传统业务应用服务的特点；
2 ，针对改造中涉及的工具链支撑平台先行建设；
3 ，转型服务团队技能和运维体系；
4 ，持续增加技术投入
5 ，适时借鉴第三方厂商经验和技术赋能，是掌握和改造业务 - 应用服务的关键要素。

解答2：

OpenShift 既可以支持无状态应用，也可以支持有状态应用（使用 statefulset ），如 redis 、 mysql 等。整体上看，运行的无状态应用会多一些。

已建立了清晰的可自动化的编译及构建流程
应用使用了如 Maven 、 Gradle 、 Make 或 Shell 等工具实现了构建编译步骤的自动化。这将方便应用在容器平台上实现自动化的编译及构建。

已实现应用配置参数外部化
应用已将配置参数外部化与配置文件或环境变量中，以便于应用容器能适配不同的运行环境。

已提供合理可靠的健康检查接口
容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。

已实现状态外部化，实现应用实例无状态化
应用状态信息存储于数据库或缓存等外部系统，应用实例本身实现无状态化。

不涉及底层的操作系统依赖及复杂的网络通信机制
应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制以提高可移植性。

部署交付件及运行平台的大小在 2GB 以内
轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。

启动时间在 5 分钟以内
过长的启动时间将不能发挥容器敏捷的特性。

容器云 /openshift 架构

OpenShift 相对于开源容器网络解决方案，如 Flannel 、 Calico 有哪些优势？

OpenShift 相对于开源容器网络解决方案，如 Flannel 、 Calico 有哪些优势？针对金融科技行业网络安全区域分级的监管要求， OpenShift 的网络解决方案是否可以有效适配多个网络安全区域隔离的场景？

解答 1:

Calco 是更加贴近于实际物理网络，所以性能相对来说更好一点，但是物理相对来说灵活性上会受到一些挑战；
Flannel 偏向于软件，性能上会稍微逊色一些，但是灵活性和便捷性相对来说比较好。

解答2：

Flannel/Calico ，本身也可以作为 OpenShift 网络解决方案的组成部分。
其中 Flannel 是 coreos 公司专门为 k8s 设计的 sdn 组件，而 coreos 公司现在已被 redhat 收购。

OpenShift 的价值在于平台本身已经对这些组件做了安全认证和集成加固。

openshift的网络方案是怎么样的？
openshift 的网络方案是怎么样的，是 underlay 的还是 overlay 的，能支持同一集群多种网络方案共存么
解答：
OpenShift 相关的网络包含两部分：入口流量和内部的 SND 。入口流量红帽使用容器化的 haproxy 。
SDN 方面， OpenShift 3.11 默认使用 OVS ， overlay 的 ； OpenShift 也认证过几个第三方的 SDN ，如 Calico ， NSX 等。 OpenShift 4 未来的计划是使用 OVN 。目前 OpenShift 4.2 的 OVN ，底层还是调用了 OVS ， overlay 的

使用OpenShift+Fuse对比通过Camel、Servicemix实现分布式应用集成，有什么不同？

解答：

Fuse 即是红帽企业版本的 Camel 。（ Fuse 的上游社区是 Camel ）
Fuse 的镜像在 OpenShift 之上实现了无状态调整。已更好的适应云原生。
Fuse 的镜像去掉了一些没有必要的组件，已提高安全性和启动快捷性。
Fuse 可以更加容易和 API 管理平台，例如 3scale 进行对接。

容器和虚机混合部署的应用，如何进行快速部署？有没有什么好的实践？

解答：

OpenShift3.11 中，虚拟机和 OCP 的部署是想对独立的。也就是说，先部署好 VM ，安装好 RHEL ，然后再通过 Ansible 的 Playbook 来部署 OpenShift 。在 OCP4 的部署模式分为 IPI 和 UPI ，前者是全自动化部署， VM 和 OCP 可以统一部署。目前 4,2 支持的 IPI 包括 AWS 、红帽 OpenStack 。 IPI 是手工部署，需要提前准备好 VM ，然后部署的时候，是 VM 中的 CoreOS 和 OCP 一起部署（ OCP4 底层 HostOS 使用 CoreOS ）。

OCP 中的 pod 要访问外部网络，是通过 NAT 的方式，以其所在的 OCP node IP 出去的。

容器云自动化

敏捷集成和自动化对基础设施，像网络、存储等有什么更高的需求？

敏捷集成和自动化，提高效率的同时，对网络运行环境如 IP 分配、负载和防火墙等提出了什么样的新需求

解答1：

1 ，敏捷其实相对来说，首先得有这些专业的管理平台运营着，且在相应的日常运营运维中确实在使用，那么如果通过这个些工具链打通后，就比较稳固的提升了敏捷本身的效率。如果本身这些工具链平台都不存在，那其实与其说敏捷，还不若说先构建敏捷工具链及其相关集成平台后，再说敏捷更有实际意义；
2 ，问题中潜在意识，个人感觉其实想问安全。逻辑上网络只要可达就可，而且开源工具本身就要求各种网络可达，且对网络安全和限制基本上都不提。这其实也是开源到企业应用过程中必须要走的一个步骤，那就是如何在企业的安全网络环境下使用这个开眼；
3 ，网络本身来说，其实只要联通，只要那些防火墙、负载、路由等应该在网络的什么环节上生效运行，其实更需要网络运维管理人员来说配合。
4 ，最后一点就是工具链技术和网络安全限制相结合，才能谈敏捷交付。

解答2：

敏捷集成方案要求主要是以下 3 点：
1 、分布式，要求有一个 paas 平台，网络、存储要满足 paas 的要求。
2 、集成，要有一个集成软件，满足各种协议的对接。
3 、 API 管理，要有一个 API 管理平台，满足 API 的发布、管理、控制。

应用微服务化标准

传统金融行业，云原生应用比率很低，企业如何基于OpenShift容器云平台做微服务化？

传统金融行业，云原生应用比率很低，企业如何基于 OpenShift 容器云平台做微服务化？微服务架构与传统架构，在产品研发过程，需要提前考虑哪些因素，有无最佳实践？

解答：

云原生是一个较大的话题，实际上企业不必为了云原生而云原生。目前看到的实例案例，金融客户大多 web 类应用，都使用 SpringBoot 开发，然后通过红帽提供的 OopenJDK 进行进行容器化，然后运行在 OopenShift 上。如果要使用 SpringCloud 治理框架，由于它是代码侵入式的，那么在应用开发过程中，就需要使用使用 anotation 引入 SpringCloud 。目前看到的用户，所有 SpringCloud 框架模块都上齐的不太多，大多是使用 SpringBoot ，然后引入少量的治理模块，比如 Hystrix 。从发展角度看， istio 是未来微服务的发展方向，因为它没有代码侵入。目前很多客户在测试它，但国内生产环境案例还不多。

日志管理

使用分布式架构后，应用日志如何管理和问题如何迅速定位？**

使用分布式架构后，应用的日志如何进行有效的管理和分析，因数据量很大 而存储有限，很难满足网安法要求的最少保留六个月的限制。

另外，接口交互时的如何存储？保险的交易日志一般会保留 2 年以上 ，以备交易的跟踪和回溯。

解答：

推荐使用 EFK 日志栈实现。
数据量很大可以使用 EFK+kafka 方案。
存储有限的问题，不在技术考虑范围内，或者说，存储是技术成本的最后考虑因数（存储是最便宜的）。

Kubernetes 与 Openshift 差异性

随着google和社区在不断优化和降低Kubernetes的使用门槛和复杂度，OpenShift相比优势又有那些？

解答：

首先，红帽是 K8S 开源项目的最早发起者，目前也是 K8S 社区代码第二贡献者。早期的 K8S 缺乏企业级功能， OppenShift 则予以补充。目前 K8S 的功能基本已经完善。 K8S 和 OpenShift 的定位区别在于：前者是容器调度平台，后者是企业级 PaaS 平台，提供实现 DevOps 、微服务的能力。每个版本的 OpenShift 都会包含一个版本的 K8S 。但 OpenShift 还提供 K8S 不具备的功能，比如持久化存储 Ceph 、应用的 SSO 、企业级容器化中间件 JBoss 、 Tomcat 等。此外， OpenShift 具备红帽企业级支持，而 K8S 则没有。所以，在金融、能源、电信行业，客户生产环境往往选择 OpenShift, 即使这些客户之前验证过 K8S 。

openshift 4支持部署在Kubernetes上吗？

解答：
每个版本的 OpenShift 都会包含一个版本的 K8S ，比如 3.11 包含 K8S 1.11, OpenShift 4.2 包含 1.14 版本的 OpenShift ，我们在安装 OpenShift 的时候无需手工单独安装 K8S ，都是一体化安装的。

OpenShift与K8s有什么区别？

OpenShift 与 K8s 有什么区别？ OpenShift 有什么优势？在容器的管理、编排等方面是否能够做到自动管理。对于云原生的支持情况怎么样？

解答：

分享一下体会，从以下三个方面对比吧，详细对比，可以参考一下 URL --> https://stackshare.io/stackups/kubernetes-vs-openshift
所有的差异性已经将这些差异性都做了对比，答案也自在其中。
1, 架构层对比

2， 从 vendor support 对比

3， 从一些关键性或功能及交付指标

容器云上应用管理

容器云平台下的弹性伸缩问题？

容器云平台下基于负载预测的弹性伸缩如今的实践方案有哪些？基于阈值弹性伸缩的实现，对于阈值的设定需要注意什么问题，实际生产中弹性伸缩策略有哪些？另外现如今的 Docker Swarm 集群管理工具在现实应用中存在什么样的意义？

解答：

1, 弹性伸缩这个需求在容器平台下进行管理，是个很方便。但是正如问题所写的一样阀值的定位是关键，比如有的时候根据业务应用连接数来进行伸缩，有的就是看不同级别的队列里面的排队数，好一点就业务响应时间，次一点有的看资源性能，总之这些都是作为阀值 triger 伸缩的一个条件；
2 ，但是伸缩这个过程，从实际经验来说还是建议标准化来进行，比如某种服务的 Pod 数量进行伸扩（缩需要慎重），就是按照业务运营的某种模式进行；不建议完全自动化驱动来实现；
3 ，缩减这个动作可以在业务不高峰的时候的进行，就是最好在空窗期进行；
4 ，伸缩后的监控体系和业务运营健康体系评估一定跟进；
5 ，对于规模和技术运营团队不是那么成熟来说， Docker SWARM 其实是可以满足，因地制宜的使用技术实现用户场景，不建议单独一味追求 Kubernetes 技术方案。就好比，汽车未必比人跑的快这个结论，假设总距离就是 10 米，那么肯定是人比汽车跑得快；如果是 500 米距离，通常情况是汽车比人快。所以一定要找到适合自身团队能驾驭的技术来管理整个环境。

应用入云的收益分析

云计算在中小银行实际使用获益和成本如何平衡？
解答：
公有云方面的使用收益，我们无法提供。就 OpenShift 而言， IDC 提供了一个在线计算 ROI 的工具。 我们可以使用这个工具，对 OpenShift 的 ROI 进行分析。 在线工具的网址： https://redhat.valuestoryapp.com/OpenShift_sales/ 。

其它

centos部署openshift，openshift部署kubernetes或openstack的资料网上比较少，能否多分享一些资料？

解答1：

www.bing.com ( 国际版 )--> serach 'Openshift CentOS' --> 内容不少，不过得习惯阅读 E 版信息就好了～～～中文 search 到的内容不多～～～

解答2：

access.redhat.com
里面有 openshift 的中文资料。