DevOps 规划和建设是基于容器化的 PaaS 平台，还是把 PaaS 平台作为 DevOps 中的一部分，不同的人有不同的理解和要求。随着容器化 PaaS 平台落地案例越来越多，支撑起了越来越多的业务应用和企业工作流程，以及越来越多的中间件工具。容器化服务带来了敏捷的部署和弹性伸缩能力，而标准化的镜像交付和容器引擎又为环境一致性和敏捷部署提供了便利；容器的无状态特性使业务应用的回归测试环境秒级构建，而不用担心每次测试的数据和状态的不一致；容器的自修复、自动迁移特性也使一些运维工作相对简单化。大多数证券企业 IT 人员数量不是很多，决定其可能不适合建设笨重的 DevOps 平台，更适合轻量化、敏捷的、弹性的、自动化的基于容器化 PaaS 平台的 DevOps 。 DevOps 要实现从项目管理、开发、测试、部署、运维、监控反馈整个应用生命周期的管理和治理，涉及的流程和工具链还是很多的。证券企业无论在人力还是技术积累等方面往往都是相对薄弱的，所以基于容器化 PaaS 平台的轻量化 DevOps 平台可能在一段时间内是相对适合的，能以低成本学习投入更快的提升研发和运维的效率。
为此， twt 社区也邀请到了行业和领域技术专家以及红帽资深解决方案架构师分享了他们的容器云项目实践经验，现在我就大家提出的宝贵问题进行一个全面的梳理和总结，希望对大家有所帮助和借鉴。

一、 容器化 PaaS 平台和 DevOps 的关系讨论

【 Q 1 】 、如何理解容器云平台和 DevOps 之间的关系 ? 基于容器化 PaaS 平台的 DevOps 有什么优势？

【A1】魏新宇售前技术支持,红帽企业级开源解决方案中心

广义上的DevOps建设会包含：人、流程、工具等多方面内容。 IT 厂商提供的微服务和 DevOps 主要指的是工具层面的落地和流程咨询。

在 Kubernetes 和容器普及之前，我们通过虚拟机也可以实现DevOps，只是速度相对较慢，因此普及性不高（想象一下通过 x86 虚拟化来实现中间件集群弹性伸缩的效率）。而正是容器的出现，为 DevOps 工具层面的落地提供非常好的承载平台，使得这两年容器云平台风生水起。这就好比 4G （ 2014 年出现）和微信（ 2011 年出现）之间的关系：在手机网速 3G 的时代，流量按照兆收费，（即使有）大家对于微信语音聊天、微信视频也不会太感兴趣。到了 4G 时代，网速提高而且收费大幅下降，像微信这样的社交和互联网支付工具才能兴起和流行。

OpenShift 以容器技术和 Kubernetes 为基础，在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（ S2I/Jenkins ）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，实现DevOps落地效率比较高。

【 A2 】 Steven99 软件架构设计师 某证券公司
容器云平台可以是DevOps的一部分, 也就是提供运行时环境,部署运维日志监控反馈等

基于容器云平台的DevOps是轻量的, 或者用于PoC测试目的的,在于快速构建环境和完成部署.节省成本,维护工作量也相对较小.适合中小公司或者对研发等并不是要求特别高的公司.

建议根据自己的实际情况选择合适的方式,devops建设并不容易,也不仅仅是开发运维这么简单,流程、标准、度量、奖惩、组织、后勤保障等都密切相关

【 A3 】 rechen 云计算架师 , 某大型银行

1、容器云平台，需要DevOps以标准化和提升IT研发和交付能力。 DevOps可以部署在容器云平台上。

2、基于容器化PaaS平台的DevOps，可以使用容器云的资源，譬如DevOps平台的相关技术组件，可以以容器方式部署在容器云上，以支持多pipeline流水线并发编译所需要的弹性资源。

【 Q2 】、想要落地devops的话，只考虑好的paas容器平台就够了么？

【 A1 】 魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

容器云只是DevOps的底座。这个底座上面还需要很多内容，我们仅以工具层举例：

项目管理：禅道、 Jira 、 Trello 等。

知识管理： MediaWiki 、 Confluence 等。

源代码版本控制（ SCM ）： GitHub 、 Gitlab 、 BitBucket 、 SubVersion 、 Gogs 等。

代码复审： Gitlab 、 Gerrit 、 Fisheye 等。

构建工具： Ant 、 Maven 、 Gradle 等。

持续集成（ CI ）： Jenkins 、 Bamboo 、 CircleCI 、 Travis CI 等。

单元测试： Junit 、 Mocha 、 PyUnit 等。

静态代码分析： Findbugs 、 Sonarqube 、 CppTest 等。

测试用例管理： Testlink 、 QC 等。

API 测试： Jmeter 、 Postman 等。

功能测试： Selenium 、 Katalon Studio 、 Watir 、 Cucumber 等。

性能测试： Jmeter 、 Gradle 、 Loadrunner 等。

配置管理： Ansible 、 Chef 、 Puppet 、 SaltStack 等。

监控告警： Zabbix 、 Prometheus 、 Grafana 、 Sensu 等。

二进制库： Artifactory 、 Nexus 等。

镜像仓库： Docker Distribution 、 Harbor 、 Quay 、 Nexus3 、 Artifactory 等

我们再看一个图，其中的OpenShift是底座，上面有很多工具。

【 A2 】 wykkxwykkx 系统架构师 , 某基金公司

还差的非常远。。。 devops是以业务需求驱动为主体，需要打通业务，项目管理，开发，测试，运维一整套流程的。这里涉及的不仅仅是技术问题，更多的是文化，管理，技术的一个整体的规划。所以要想落地devops，简单来说，首先需要形成一个整体的规划，其次需要引入工具平台支持，这个工具平台是否为paas容器平台，没有任何关系。最后，在工具落地后，采用mvp原则，让大家看到收益，然后进一步推广。

【 A3 】 Steven99 软件架构设计师 , steven

确切地说远远不够

DevOps涉及的东西很多，开发运维项目管理全过程都密切相关。DevOps的目的是提升效率，所以不在于用什么平台，而在于根据企业实际情况选择合适的组件和流程、工具、方法、组织架构、奖惩措施等，尽可能以自动化的方式高效交付，同时激励相关人员的主动性，提高规范化和标准化要求，这是一个螺旋提升的过程，一个不断完善的过程

【 A4 】 gxcornflakesgxcornflakes 信息技术经理 , 某金融单位

DevOps是一种理念，是轻量级的ITIL，技术部一般基于ITIL提供服务目录完成服务请求，中间有复杂的审批、手动操作，DevOps将服务流程规范化、标准化并通过自动化技术实现pipline，提升工作效率。要想落地DevOps，关键是思维和理念的提升，再次是团队的变革，还有平台和工具的支持。PaaS仅仅是一个支持平台，解决一部分问题。

【 Q3 】、PaaS平台和DevOps平台的融合和边界问题？

【 A1 】rechenrechen 云计算架师 , 某大型银行

1、PaaS平台和DevOps平台融合为一还是分开建设，这和每家单位的组织机构有关系。如果工程管理的平台和工具，已经有一个单独的职能部门在负责，则DevOps平台由此部门承接。 此时，PaaS平台宜分开建设。

2、 分开建设的话，PaaS平台和DevOps 的边界在容器镜像，一般情况有通过容器仓库进行交互。

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

如果按照客户的IT建设，是先有IaaS，再有容器云/PaaS。

关于PaaS和IaaS边际，以OpenShift4为例，虚拟机及以下，是IaaS层；虚拟机中的操作系统及以上，是PaaS层。这主要是因为OpenShift的宿主机操作系统已经被OpenShift统一纳管了。

关于IaaS和PaaS统一还是分开建设，这取决于具体的情况。

1.对于大的银行，客户的IaaS未必只承载容器云，可能还承载大量的虚拟机上的应用，因此统一建设有一定难度。况且IaaS通常有专门的部门的负责。

2.对于中小金融的某个单的的项目，比如容器云项目，在符合公司的规划下，可以考虑IaaS和PaaS统一建设。现在OpenShift4可以通过Machine API对IaaS（如vSphere，红帽OpenStack，AWS，Azure）进行纳管。

【 Q4 】、如何规划容器化PaaS和DevOps？

【 A1 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

可以把容器云平台理解成航母，把容器云上的容器化应用理解为航母舰载机。PaaS、DevOps、微服务这三个概念，不是纯IT技术技术术语。在容器云普及之前，这三个概念就已经有了。无非是如何技术落地的问题。没有容器云，通过虚拟机也能实现 PaaS、DevOps、微服务 。只是相对效率低一些，所以之前这些技术也没被大规模使用。容器云为 PaaS、DevOps、微服务提供了非常好的技术落地实现。

云原生是近两年兴起的概念。这个概念大体就是纯IT领域的术语了。 2018 年， CNCF 组织对云原生进行了重新定义“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API ”。 从 CNCF 对云原的定义来看，它和容器、服务网格、微服务等技术是密切相关的。云原生的范畴更广，包含了轻量级的应用开发框架内容。

我此前基于OpenShift规划了一个敏态IT构建路径图，请参考。

【A2】 mtming333 系统运维工程师 , 甜橙金融翼支付

容器：船上的集装箱

容器云：很多船上的集装箱

容器化 PaaS ：很多船上的集装箱的指挥中心

混合云：租赁船上的集装箱 + 自购船上的集装箱

DevOps ：造集装箱货物的人和管集装箱的人都在船上一起干活

微服务：集装箱里的货物

云原生：未经改装拿来就用的公共船、集装箱、指挥中心

【 Q5 】、使用容器平台做devops对比使用虚拟机环境做devops有什么优缺点？

【 A1 】rechen 云计算架师 , 某大型银行

1、使用虚拟机环境做devops，优点是虚拟机环境能够完整支持windows，linux等环境。 使用容器平台做devops一般以linux容器环境为主。

2、如果单位已经建设有容器平台且有团队研发和运维，则建议优先选择使用容器平台做devops，实施成本可平摊，在容器平台上做DEVOPS已经有很成熟的技术方案，实施难度不大。且能够获得较好的扩展性。

3、如果单位没有容器平台的基础设施支持，而且像VMWARE的虚拟机环境，则建议使用虚拟机环境做 DEVOPS，是实施成本小，难度小。其扩展性可以使用云管平台或者自动化脚本来实现。

【 Q6 】、IaaS、PaaS、SaaS、DevOps等概念技术在业务领域的着重点？

【 A1 】 rechen 云计算架师 , 某大型银行

1、从业务领域角度看，IaaS, PaaS, DevOps的建设，是IT部门能够提升研发效能和交付效率。 而SaaS则更贴近业务，业务部门可以承接运营，直接面向市场为客户提供服务。

【 A2 】 wykkxwykkx 系统架构师 , 某基金公司

iaas平台主要是提供计算/存储/安全/网络方面的能力，即基础设施即服务，主要的建设部门是数据中心或者是运维部门；paas平台主要提供中间件能力/数据服务能力/编码服务化能力，主导部门主要是运维部门和开发部门；saas是软件即服务，一般把IT作为成本中心的企业（例如银行/证券等），是很少提供saas服务的。Devops主要是以业务驱动为核心，满足业务需求，打通业务/需求/开发/测试/运维一整套流程，devops的落地是一整套管理/文件/工具落地的集合体，目的是为了以最低成本和最快速度实现业务需求，实现业务价值。

二、 在金融证券行业的场景讨论

【 Q7 】、容器化PaaS平台在证券行业的应用前景和场景是什么？

【 A1 】wykkxwykkx 系统架构师 , 某基金公司

首先对这个问题进行拆解，容器化和paas平台两者没有必然的联系。容器化可以做iaas层的一种承载方式，也可以是paas层，saas层的承载方式。paas平台可以基于容器或者虚拟机部署，提供诸如中间件服务、数据库服务、devops流水线、分布式链路跟踪等能力。

其次，paas平台的能力，在证券行业可能有80%的场景是为自研应用服务，（外购系统很多出于产品化的原因都是做了完整的自包含），所以在设计paas平台时，应该多收集开发团队的需求点。

最后谈下devops与容器，其实devops的落地与容器并没有太强的关联，只是说目前商用的容器平台利用镜像的特点和容器平台多租户的特点，较为便捷的落地了devops。但是基于虚拟机的方式实现devops也并不难，所以两者在我看来没有促进与否的问题。

【 A2 】mtming333 系统运维工程师 , 甜橙金融翼支付

我倒觉得应该是容器化PaaS平台去促进DevOps落地，做好了容器paas，用户爱用了，才能继续devops的工作流程改造

【 A3 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

我咨询过一些证券行业的IT专家，目前证券行业使用容器，主要是少量的中间件容器化。在容器云的使用上，金融行业里保险公司走的快一些，有的保险公司基于容器云承载互联网核心、销售管理系统等业务。因此对于证券行业而言，后续互联网接入、DevOps的流水线，可以迁移到容器云，提升效率。

【 A4 】gxcornflakes 信息技术经理 , 某金融单位

1、容器化PaaS平台在证券行业的应用前景和场景是什么？

随着证券行业应用系统自主化建设，PaaS容器云将应用越来越广泛，主要场景有几个方面：1、互联网应用系统；快速部署，弹性伸缩；2、微服务（中台应用）；3、大数据人工智能应用；

2、如何结合DevOps促进容器化PaaS平台的落地？

DevOps一种文化，即轻量级ITIL理念。DevOps的思想是要求作业流水线化实现自动化，即要求流水线的每个step标准化、规范化，而PaaS容器平台落地就是对资源和应用的标准化，所以DevOps和PaaS是相互促进

【 Q8 】、金融行业如果从全局数字化运营的角度规划整套DevOps平台？

【 A1 】Steven99 软件架构设计师 , steven

这个内容就太多了，devops提供敏捷的研发运维流程、工具、方法、规范等。但它也仅是数字化转型中的一小部分。数字化转型重点在于利用金融科技实现业务的变革和创新，业务模式的变革和创新。这需要公司全局的规划和布局，不同公司的情况不一样，路经和方法也可能不一样，适合自己的事最好的。

但有一条需要记住，提高效率！无论是开发运维效率或者是业务响应效率，这是devops等需要首先的目的

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

构建DevOps平台这个话题比较大。如果只讨论技术层面的话，主要是工具层的选型和落地。

DevOps 发展到现在，所涉及的工具繁杂，下面列出一些主要的类别：

项目管理：禅道、 Jira 、 Trello 等。

知识管理： MediaWiki 、 Confluence 等。

源代码版本控制（ SCM ）： GitHub 、 Gitlab 、 BitBucket 、 SubVersion 、 Gogs 等。

代码复审： Gitlab 、 Gerrit 、 Fisheye 等。

构建工具： Ant 、 Maven 、 Gradle 等。

持续集成（ CI ）： Jenkins 、 Bamboo 、 CircleCI 、 Travis CI 等。

单元测试： Junit 、 Mocha 、 PyUnit 等。

静态代码分析： Findbugs 、 Sonarqube 、 CppTest 等。

测试用例管理： Testlink 、 QC 等。

API 测试： Jmeter 、 Postman 等。

功能测试： Selenium 、 Katalon Studio 、 Watir 、 Cucumber 等。

性能测试： Jmeter 、 Gradle 、 Loadrunner 等。

配置管理： Ansible 、 Chef 、 Puppet 、 SaltStack 等。

监控告警： Zabbix 、 Prometheus 、 Grafana 、 Sensu 等。

二进制库： Artifactory 、 Nexus 等。

镜像仓库： Docker Distribution 、 Harbor 、 Quay 、 Nexus3 、 Artifactory 等

我提供一个DevOps的技术架构样式图作为参考：

【 A3 】rechen 云计算架师 , 某大型银行

组织架构上要有充分的保障，DEVOPS团队的人员除了负责平台建设，流程规范，还要负责运营和推广培训。一种比较好的安排是由项目管理团队负责规划和实施DEVOPS平台

【 Q9 】、证券行业一流券商容器化目前已经涉及到哪些应用场景？

【 A1 】 魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

据我了解是互联网渠道接入和部分中间件的容器化。但我觉得后续场景会越来越多，尤其是DevOps和互联网接入层，比较适合证券行业对突发大访问量业务的需求。

【 A2 】 Steven99 软件架构设计师

弹性伸缩、环境一致性、灰度发布、服务治理、多集群容灾备份、中台支撑、平台融合等

【 Q10 】、券商适合云上的容器还是需要自建容器平台？

【 A1 】 魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

对于大型银行来讲，一定是用在数据中心内建私有云，一方面出于数据安全，一方面是技术自主可控。对于券商而言，可以考虑公有云和私有云混合的模式，比如互联网的接入，可以放到公有云上，但容器云核心的部分，最好自建，而且使用开源的方案，避免被锁死。

【 A2 】 Steven99 软件架构设计师 , steven

不同公司有不同的想法和做法，取决于你怎么看待数据价值，以及云厂商有多大程度的可信度，公有云的可靠性、可用性等能力

就我们而言，自建的容器云平台，是支撑众多业务系统的基础平台，也是devops中的重要运行时部分

【 A3 】沈天真 售前支持 , 浪潮商用机器企业云创新中心

具体情况具体分析；券商核心交易及相关联的一些场景，目前国内还没有到容器化那一步，而且是否真的需要容器化，能带来多大收益，都是个大问号。非核心的应用场景，也需要认真思考一下，到底什么样的场景下使用容器才能有收益 ？至少要有个收益清单列在那儿吧。如果确认容器化能够带来收益，大中型券商不建议将基础架构控制权拱手让出；小型券商自己掂量着办吧；

【 A4 】 nameless 技术总监 , 某云计算厂商

看业务需求和监管需求。

有数据要求不能放公有云，那就只能自建。

国内几种情况都有，有用公有云，有的自建，也有用混合云

三、 Openshift应用讨论

【 Q11 】、Openshift 作为一种容器技术有开源和商用，那么目前有哪些服务场景在使用？

【 A1 】 魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

OpenShift本身是一个开源的软件，它有还有对应的社区版本OKD。这就和RHEL和CentOS的关系。在金融行业，目前银行和保险行业使用OpenShift较多，应用如：直销银行、保险公司的销售管理系统、互联网核心。

如果站在IT角度，我们主要通过那哪些应用适合上容器，哪些不适合上容器来判断。可以参照下面标准：

1.已建立了清晰的可自动化的编译及构建流程

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

2.已实现应用配置参数外部化

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

3.已提供合理可靠的健康检查接口

容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。

4.已实现状态外部化，实现应用实例无状态化

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

5.不涉及底层的操作系统依赖及复杂的网络通信机制

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

6.部署交付件及运行平台的大小在2GB以内

轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。

7.启动时间在5分钟以内

过长的启动时间将不能发挥容器敏捷的特性。

【 A2 】 rechen 云计算架师 , 某大型银行

生产环境建议采用openshift商用版本。openshift能够承载java平台，.net core平台的业务应用系统，包括OA办公，内部管理，在线交易系统。

【 A3 】 ypl75 工程師 , 金融業

我們公司目前運用在網路銀行、行動銀行及API管理系統

【 Q12 】、相比于K8S，OpenShift在帮助客户构建PaaS平台的优势在哪？

【 A1 】 wykkx 系统架构师 , 某基金公司

这个问题主要涉及几个点：一是k8s属于开源产品，需要使用方完全负责生命周期的运维工作，对使用者的要求较高；openshift属于商用产品，有厂商负责生命周期的运维工作。二是k8s由于其开源架构，社区活跃度较高，可以获取到更多的外部信息；三是k8s在paas层原生提供的功能比openshift原生提供的功能丰富一些。如果是自研能力较强，建议使用k8s，如果是团队自身能力不足建议使用openshift来进行系统建设。

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

优势其他专家已经说得很清楚了。这里我补充一下OpenShift对K8S的扩展，以方便理解。

2.1.1 OpenShift 对 Kubernetes 的增强

早期的 Kubernetes 功能尚弱，红帽的 OpenShift 补充了大量的企业级功能，并逐渐将这些功能贡献给上游 Kubernetes 社区，此时， Kubernetes 和 OpenShift 共同成长。随着纳入了 CoreOS 优秀基因的 OpenShift 的发布，其功能特性和健壮性大胜往昔，并进一步推动 Kubernetes 社区的发展。所以说， OpenShift 和 Kubernetes 是相互推动、相互促进的。接下来，我们具体看一下 OpenShift 对 Kubernetes 的一些关键性增强。

1.稳定性的提升

Kubernetes 是一个开源项目，面向容器调度； OpenShift 是企业级软件，面向于企业 PaaS 平台。 OpenShift 除了包含 Kubernetes ，还包含很多其他企业级组件，如认证集成、日志监控等。

OpenShift 提供企业版和社区版，红帽订阅客户可以使用企业版并获得 OpenShift 企业级支持。 Kubernetes 有很多发行版，但由于它是一个开源项目，如果遇到技术问题，主要依靠社区或外部专家来解决。

Kubernetes 每年发布 4 个版本， OpenShift 通常使用次新版本的 Kubernetes 为最新版本产品的组件，这样保证客户企业级 PaaS 产品的稳定性。

2.OpenShift 实现了一个集群承载多租户和多应用

企业客户通常需要 PaaS 集群具备租户隔离能力，以支持多应用和多租户。多租户是 Kubernetes 社区中一个备受争议的话题，也是当时 Kubernetes 早期版本所欠缺的。

为解决这个问题，红帽在许多关键领域投入了大量资源。红帽推动了 Kubernetes Namespaces 和资源限制 Quota 的开发，以便多个租户可以共享一个 Kubernetes 集群，并可以做资源限制。红帽推动了基于 Kubernetes 角色的访问控制（ RBAC ）的开发，以便可以为用户分配具有不同权限级别的角色。 2015 年发布的 OpenShift 3.0( 基于 Kubernetes 1.0) 就已经提供了 RBAC 的功能；而 Kubernetes 直到 1.6 版本，才正式提供 RBAC 功能。当年没有 RBAC 、 Namespaces 、 Qouta 这些功能的 Kubernetes 是无法满足企业客户的需求的。

3.OpenShift 实现了应用程序的简单和安全部署

Kubernetes 为应用程序提供了诸如 Pod ， Service 和 Controller 等功能组件，但在 Kubernetes 1.0 中部署应用程序并实现应用程序版本管理并不是一件简单的事情。红帽在 OpenShift 3.0 （基于 Kubernetes 1.0 ）中开发了 DeploymentConfig ，以提供参数化部署输入、执行滚动部署、启用回滚到先前部署状态，以及通过触发器驱动自动部署（ BuildConfig 执行完毕后触发 DeploymentConfig ）。红帽 OpenShift DeploymentConfig 中许多功能最终将成为 Kubernetes Deployments 功能集的一部分，目前 OpenShift 也完全支持 Kubernetes Deployments 。

企业客户需要更多安全工具，来处理正在部署的应用程序。容器生态系统在容器镜像扫描、签名等解决方案方面已经走过了漫长的道路。但是，开发人员常常仍在寻找和部署缺乏任何来源且可能不太安全的 Image 。 Kubernetes 通过 Pod 安全策略来提升安全性。例如我们可以设置 Pod 以非 root 用户方式运行。 Pod 安全策略是 Kubernetes 中的较新的功能，这也是受 OpenShift SCC （安全上下文约束）的启发。

为了真正实现容器镜像的安全，红帽致力于消除单一厂商控制的容器镜像格式和运行时（即 Docker ）。红帽为 Kubernetes 开发了 CRI-O ，这是一个轻量级、稳定且更安全的容器运行时，基于 OCI 规范并通过 Kubernetes Container Runtime Interface 集成。目前已经在 OpenShift 中正式发布。

4.OpenShift 帮助 Kubernetes 运行更多类型的应用负载

Kubernetes 本身适合无状态的应用运行。但如果企业中大量有状态的应用都无法运行在 Kubernetes 上的话， Kubernetes 的使用场景终将有限。有状态应用在 Kubernetes 上运行的最基本要求就是数据持久化。为此，红帽创建了 OpenShift 存储 Scrum 团队，专注于此领域，并为上游的 Kubernetes 存储卷插件做出贡献，为这些有状态服务启用不同的存储后端。随后，红帽推动了动态存储配置的诞生，并推出了 OpenShift Container Storage 等创新解决方案。红帽还参与了 Kubernetes 容器存储接口（ CSI ）开源项目，以实现 Pod 与后端存储的松耦合。

5.OpenShift 实现应用的快速访问

Kubernetes 1.0 中没有 Ingress 的概念，因此将入站流量路由到 Kubernetes Pod 和 Service 是一项非常复杂、需要手工配置的任务。 在 OpenShift 3.0 中，红帽开发了 Router ，以提供入口请求的自动负载平衡。 Router 是现在 Kubernetes Ingress 控制器的前身，当然， OpenShift 也支持 Kubernetes Ingress 。

Kubernetes 本身不包含 SDN 和虚拟网络隔离。而 OpenShift 包括集成了 OVS 的 SDN ，并实现虚拟网络隔离。此外， 红帽还帮助推动了 Kubernetes 容器网络接口开发、为 Kubernetes 集群提供了丰富的第三方 SDN 插件生态系统 。目前， OpenShift 的 OVS 支持 Network Policy 模式 ，其网络隔离性更强，而且默认使用 Network Policy 模式，极大提升了容器的网络安全。

6.OpenShift 实现了容器镜像的便捷管理

OpenShift 使用 ImageStreams 管理容器镜像。一个 ImageStream 是一类应用镜像的集合，而 ImageStreams Tag 则指向实际的镜像。

对于一个已经有的镜像，如 Docker.io 上的 Docker Image ，如果 OpenShift 想使用，则可以通过将 Image 导入 ImageStream 中。需要注意的是，我们在将 Image 导入 ImageStream 的时候，可以加上 --scheduled=true 参数，它的作用是当 ImageStream 创建好以后， ImageStream 会定期检查镜像库的更新，然后保持指向最新的 Image 。

在介绍 OpenShift 对 Kubernetes 的增强以后，接下来我们介绍 OpenShift 对 Kubernetes 生态的延伸。

2.1.2 OpenShift 对 Kubernetes 生态的延伸

OpenShift 对 Kubernetes 生态的延伸，主要体现在七个方面，我们将分别进行介绍。

1.OpenShift 实现了与 CI/CD 工具的完美集成

目前 OpenShift Pipeline 默认使用 Tekton 。 Tekton 是一个功能强大且灵活的 Kubernetes 原生开源框架，用于创建持续集成和交付（ CI/CD ）。通过抽象底层实现细节，用户可以跨多云平台和本地系统进行构建、测试和部署。

Tekton 将许多 Kubernetes 自定义资源（ CR ）定义为构建块，这些自定义资源是 Kubernetes 的扩展，允许用户使用 Kubectl 和其他 Kubernetes 工具创建这些对象并与之交互。

Tekton 的自定义资源包括：
Step ：在包含卷、环境变量等内容的容器中运行命令。

Task ：执行特定 Task 的可重用、松散耦合的 Step （例如， building a container image ）。 Task 中的 Step 是串行执行的。

Pipeline ： Pipeline 由多个 Tasks 组成，按照指定的顺序执行， Task 可以运行在不同的节点上，它们之间有相互的输入输出。

PipelineResource ： Pipeline 的资源，如输入（例如， Git 存储库）和输出（例如， Image Registry ）。

TaskRun ：是 CRDs 运行时，运行 Task 实例的结果。

PipelineRun ：是 CRDs 运行时，运行 Pipeline 实例的结果，其中包含许多 TaskRuns 。

OpenShift Pipeline 的工作流程图如图 2-5 所示：通过 Task 定义 Pipeline , Tekton 执行 Pipeline ; Task 和 Pipeline 都 变成运行时状态，并在 OpenShift 中启动 Pod 来运行 Pipeline 。

在 OpenShift 的 Operator Hub 中，提供 OpenShift Pipeline Operator ，如图 2 - 6 所示

Tekton 部署成功以后， OpenShift Pipeline 的实现就无须借助于第三方工具（如 Jenkins ）。通过 Tekton 构建 Pipeline 的示例 如图 2 - 7 所示 ：

虽然 OpenShift 默认使用 Tekton 实现 Pipeline ，但 OpenShift 会继续发布并支持与 Jenkins 的集成。 OpenShift 与 Jenkins 的集成，体现在以下几个方面：

统一认证： OpenShift 和部署在 OpenShift 中的 Jenkins 实现了 SSO 。根据 OpenShift 用户在 Project 中的角色，可以自动映射与之匹配的 Jenkins 角色（ view 、 edit 或 admin ）。

OpenShift 提供两个版本的 Jenkins ： Ephemeral 版本的 Jenkins （无持久存储）和具有持久存储的 Jenkins 。并提供了一键部署 Jenkins 的两个模板，如下图 2-8 所示：

图 2-8 两种类型的 Jenkins 模板

自动同步 Secret ：在同一个项目中， OpenShift 的 Secret 与 Jenkins 凭证自动同步，以便 Jenkins 可以使用用户名 / 密码、 SSH 密钥或 Secret 文本，不必在 Jenkins 中单独创建。

Pipeline 的集成：我们可以在 Jenkins 中定义 Pipeline 去调用 OpenShift API ，完成一些应用构建和发布等操作。

2.OpenShift 实现从开发运维一体化

在 Kubernetes 刚发布时，红帽主要想借助于 Kubernetes 构建企业级开发平台。为了全面提升 OpenShift 的运维能力，红帽收购 CoreOS ，将其中优秀的运维工具纳入到 OpenShift 中。 CoreOS 麾下对 OpenShift 运维能力大幅提升的组件有：

Tectonic ：企业级 Kubernetes 平台。

Container Linux ：适合运行容器负载的 Linux 操作系统 CoreOS 。

Quay ：企业级镜像仓库。

Operator ：有状态应用的生命周期管理工具。

Prometheus ：容器监控平台。

CoreOS 在 Prometheus 社区建立了领导地位，这为红帽带来了宝贵的专业知识。红帽 OpenShift 也逐步与 CoreOS 完成整合：

在监控方面， Prometheus 成为默认的监控工具，提供了原生的 Prometheus 监控、警报和集成的 Grafana 仪表板。

在运维管理方面， OpenShift 将 CoreOS Tectonic 控制台的功能完全融入到了 OpenShift 中，提供运维能力很强的 Cluster Console 。

操作系统 CoreOS 作为 OpenShift 的宿主机操作系统。

将 Operator 作为集群组件和容器应用的部署方式。

Quay 正在与 OpenShift 进行最后的集成。后面 OpenShift 的 Docker Registry 可以由 Quay 替代。

3.OpenShift 实现有状态应用的全生命周期管理

CoreOS 开发了管理 Kubernetes 上运行的应用的 Operator 。 Operator 扩展了 KubernetesAPI ，它可以配置和管理复杂的、有状态应用程序的实例。如今， Operator 能够纳管的应用数量迅速增加。

Operator 为什么这么重要？因为我们在 Kubernetes 上运行复杂的有状态应用程序（如数据库，中间件和其他服务）通常需要特定于该服务的操作领域知识。 Operator 允许将领域知识编程到服务中，以便使每个服务自我管理，同时利用 Kubernetes API 和声明性管理功能来实现这一目标。 Operator 可以实现跨混合云的应用生命周期统一管理。而 Operator 会用到的 Kubernetes 中的 ** CRDs ，也是红帽推动开发的。

OpenShift 提供一个非常方便的“容器应用商店”： OperatorHub 。 OperatorHub 提供了一个 Web 界面，用于发现和发布遵循 Operator Framework 标准的 Operator 。开源 Operator 和商业 Operator 都可以发布到 OperatorHub 。截止到目前 OperatorHub 中的应用数量超过 200 个，如图 2-9 所示：

4.OpenShift 实现了对 IaaS 资源的管理

Kubernetes 虽然对运行在其上的容器化应用有较强的管理能力，但 Kubernetes 缺乏对 Kubernetes 下的基础设施进行管理的能力。为了实现 PaaS 对基础架构的纳管， OpenShift 引入 Machine API ，通过配置 MachineSet 实现 IaaS 和 PaaS 统一管理。也就是说，当 OpenShift 集群性能不足的时候，自动将基础架构资源加入到 OpenShift 集群中。目前 OpenShift 实现了对 AWS EC2 、微软 Azure 、 Red Hat OpenStack 等云平台的纳管。

5.OpenShift 实现集群实时更新

安装 Kubernetes 集群后，一个重大挑战是让它们保持最新状态。 CoreOS 率先推出了 Tectonic 和 Container Linux 的 “over the air updates” 概念。通过这个技术，客户能够将 OpenShift 集群连接到红帽官网，这样客户就可以收到有关新版本和关键更新的自动通知。如果客户的 OpenShift 集群不能连接红帽官网，客户仍然可以从本地镜像仓库下载和安装相同的更新。

OpenShift 的主机操作系统基于 CoreOS ，将提供平滑升级的能力。

【 A3 】rechenrechen 云计算架师 , 某大型银行

相比于社区K8S，OpenShift产品的优势在于稳定性，安全加固，以及技术支持。

【 Q13 】、应用容器化改造上openshift时，有那些规范和注意事项？

【 A1 】 魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

应用容器化上OpenShift，整体上要符合如下标准：

1.已建立了清晰的可自动化的编译及构建流程

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

2.已实现应用配置参数外部化

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

3.已提供合理可靠的健康检查接口

容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。

4.已实现状态外部化，实现应用实例无状态化

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

5.不涉及底层的操作系统依赖及复杂的网络通信机制

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

6.部署交付件及运行平台的大小在2GB以内

轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。

7.启动时间在5分钟以内

过长的启动时间将不能发挥容器敏捷的特性。

其他的注意事项，内容很多，建议可以关注我那本《OpenShift在企业中的实践》书籍，里面通过2-3章进行了阐述。

就日志而言，目前还是输出 json比较多，可以借助于jq工具对json文件进行格式化。

就scc而言，通常不会使用anyuid，如果个别应用需要高权限，则单独给他的Service Account赋权就可以，例如

oc adm policy add-scc-to-user anyuid -z apacheuser

这样虽然稍微麻烦一点，但对金融客户而言，安全性和稳定性是第一位的。

【 A2 】 rechen 云计算架师 , 某大型银行

在企业进行应用容器化改造工作，建议有统一开发框架的支持。开发框架可以提供统一公共组件以落地标准化技术规范，譬如统一日志格式，错误码格式等。

【 Q14 】、OpenShift在帮助企业构建敏态IT、进行数字化转型的步骤是什么？

【 A1 】 魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

我以OpenShift举例进行说明：

图中的纵坐标为业务敏捷性，企业业务敏捷性方面的转型通常包含以下几步：

第一步：构建 PaaS 平台。 PaaS 平台为开发人员提供了构建应用程序的环境，旨在加快应用开发的速度，实现平台即服务，使业务敏捷且具有弹性。近几年容器技术的崛起更是促进了 PaaS 的发展，红帽 OpenShift 就是首屈一指企业级容器 PaaS 平台。

第二步：基于 PaaS 实现 DevOps 。 PaaS 平台是通过提高基础设施的敏捷而加快业务的敏捷，而 DevOps 则是在流程交付上加快业务的敏捷。通过 DevOps 可以实现应用的持续集成、持续交付，加速价值流交付，实现业务的快速迭代。

第三步：借助于轻量级应用服务器，为现有单体应用提速。在开启云原生应用之旅时，企业不能只关注开发新的应用。很多传统应用都是确保企业顺利运营和不断创收的关键所在，不能简单地取而代之。企业需将这类应用与新的云原生应用整合到一起。但是，问题是我们如何加快现有单体式应用的运行速度。正确的方法是：将现有的单体式架构迁移到模块化程度更高且基于服务的架构中，并采用基于 API 的通信方式，从而实施快速单体式方案。在开始实施将单体式应用重构为微服务的艰巨任务前，企业应该先为他们的单体式架构奠定坚实的基础。虽然单体式应用的敏捷性欠佳，但其受到诟病的主要原因是自身的构建方式。运行快速的单体式应用可以实现微服务所能带来的诸多敏捷性优势，而且不会增加相关的复杂性和成本。

通过对快速单体式方案进行评估，可以确保应用在构建时遵循严苛的设计原则，以及正确定义了域边界。这样，企业就能在需要时以更加循序渐进、风险更低的方式过渡至微服务架构。如能以这种方式实现快速单体式应用的转型，即可为优良的微服务架构打下扎实的基础。借助于 Red Hat OpenShift 和轻量级的应用服务器 Red Hat JBoss EAP 、 JBoss Web Server ，我们可以将传统单体应用迁移到容器中，为现有单体应用提速。此外，随着 OpenShift 承载的单体应用越来越多，就会涉及通过数据网格为单体应用提速。此外，随着越来越多的业务迁移到 OpenShift ，这必然会牵扯到不同业务系统之间的协议转换，即分布式集成。

第四步：选择云原生的应用开发和运行框架。 随着物联网（ IoT ）、机器学习、人工智能（ AI ）、数据挖掘、图像识别、自动驾驶汽车等新兴技术的兴起，应运而生的应用开发框架也越来越多，我们需要根据特定的业务应用需求来选择语言或框架，因此不同的云原生应用会采用不同的应用开发框架。这就要求容器 PaaS 平台能够支持多种应用开发框架。红帽 OpenShift 不仅支持传统 JavaEE 应用、 SpringBoot 应用，红帽也发布了基于 Java 的云原生开发框架： Quarkus 。此外，随着 IoT 、 AI 的普及，实时数据流平台显得越来越重要。在 IoT 平台上，如何能够实现对数据库的变化数据捕获也是我们需要考虑的。此外，如何在 OpenShift 上更进一步地运行 Serverless 也是需要我们关注的。

通过 IT 自动化管理、避免手动执行 IT 任务，是加速交付云原生应用的重点。 IT 自动化管理工具会创建可重复的流程、规则和框架，以替代或减少会延迟上市的劳动密集型人工介入。这些工具可以进一步延伸到具体的技术（如容器）、方法（如 DevOps ），再到更广泛的领域（如云计算、安全性、测试、监控和警报）。因此，自动化是 IT 优化和数字化转型的关键，可以缩短实现价值所需的总时长。

第五步：实现微服务治理。通过对业务微服务化改造，将复杂业务分解为小的单元，不同单元之间松耦合、支持独立部署更新，真正从业务层面提升敏捷性。在微服务的实现上，客户可以选择采用 Spring Cloud ，但我们认为 Istio 是微服务治理架构的未来方向。图中横坐标是业务健壮性的提升，通常建设步骤为：

第一步：建设单数据中心。大多数企业级客户，如金融、电信和能源客户的业务系统运行在企业数据中心内部的私有云。在数据中心初期建设时，通常是单数据中心。

第二步：建设多数据中心。随着业务规模的扩张和重要性的提升，企业通常会建设灾备或者双活数据中心，这样可以保证当一个数据中心出现整体故障时，业务不会受到影响。

第三步：构建混合云。随着公有云的普及，很多企业级客户，尤其是制造行业的客户，开始将一些前端业务系统向公有云迁移，这样客户的 IT 基础架构最终成为混合云的模式。

企业的 IT 基础架构与业务系统是相辅相成的。在笔者看到的客户案例中，很多客户都是两者同步建设，实现基于混合云的 PaaS 、 DevOps 和微服务，并最终实现基于混合云构建 云原生能力。

四、 规划建设容器云和DevOps讨论

【 Q15 】、PaaS选型POC测试时应重点考察哪些内容？

【 A1 】 rechen 云计算架师 , 某大型银行

1、建设功能面，重点考察平台管理、基础设施接口、应用管理、服务管理。

2、非功能面，重点 考察 备份、恢复、容灾，扩展性。运维的易管理性。安全管控。

3、特别建议要做性能测试，以评估稳定性。

【 A1 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

建议PoC的重点是PaaS平台本身的稳定性、安全性、性能、产品是否有清晰的Roadmap。不要将太多的精力放在UI界面的展现。

比如测试在各种故障情况下，PaaS平台的稳定性、PaaS上应用的稳定性、恢复时间等。

【 Q16 】、如果环境中同时存在虚拟机环境和容器环境，如何做devops？

【 A1 】 rechen 云计算架师 , 某大型银行

如果单位有容器平台建设团队交付容器环境，则建议直接使用容器环境做devops。

如果选择混用虚拟机和容器环境做devops，则建议在资源交付层，使用CMP云管平台进行纳管，以降低devops建设的复杂度，提升可维护性。

【 A2 】 gxcornflakes 信息技术经理 , 某金融单位

devops的理念是建设pipline，pipline的基础是原子化作业，这需要作业的规划化和标准化同事支持自动化

1、虚拟机环境，devops涉及资源交付和应用部署，资源交付层devops通过云管CMP或者自动化的形成pipline调用虚拟机技术的API进行资源快速交付，再深一层是，就是在虚拟机交付的同时做完中间件的自动化部署；应用部署层devops通过自动化技术如ansible进行部署。

2、容器环境，镜像已完成OS+中间件的交付，同时加载应用实现部署：两种方式：（1）镜像同时包含应用的形式，优势是可直接镜像部署，劣势是如果应用两大镜像会越来越大导致镜像存储和宿主机临时存储问题，另外就是需要应用配置无状态化，各个环境的配置文件通过配置中心进行热加载。（2）镜像+发布包的形式，镜像启动后加载应用，优势是各个环境镜像完全统一容量很小，应用由于不同环境存在不同的发布包可以采用很多方式解决，劣势比第一种方式稍显复杂。

【 Q17 】、金融企业建立容器平台时如何规划网络？

【 A1 】 mtming333 系统运维工程师 , 甜橙金融翼支付

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

随着 Kubernetes 的发展，业内在网络方向上希望通过统一的方式来集成不同的网络方案，也就有了现在的网络开放接口 CNI （ Container Network Interface ）。

CNI 项目是由多个公司和项目创建组成的，包括 CoreOS 、红帽、 Apache Mesos 、 Cloud Foundry 、 Kubernetes 、 Kurma 和 rkt 。 CoreOS 首先提出定义网络插件和容器之间的通用接口， CNI 被设计为规范，它仅关注容器的网络连接并在删除容器时删除分配的网络资源。

CNI 有三个主要组成部分：

CNI 规范：定义容器运行时和网络插件之间的 API 。

插件：对各种 SDN 对接的组件。

库：提供 CNI 规范的 Go 实现，容器运行时可以使用它来便捷地使用 CNI 。

各厂商遵守规范开发网络组件，在技术实现上共分为两大阵营：

基于二层实现：通过将 Pod 放在一个大二层网络中，跨节点通信通常使用 Vxlan 或 UDP 封包实现，常用的此类插件有 Flannel （ UDP 或 Vxlan 封包模式）、 OVS 、 Contiv 、 OVN 等。

基于三层实现：将 Pod 放在一个互联互通的网络中，通常使用路由实现，常用的此类插件有 Calico 、 Flannel-GW 、 Contiv 、 OVN 等。

就OpenShift而言，目前默认使用的SDN是OVS，它的好处是稳定性高，代码质量也很不错，可以通过Network Policy实现网络的隔离，安全性做的不错。OpenShift也对Calico的网络插件进行了认证。

OpenShift 3 中，一个 OpenShift 集群只能选择一个 SDN 插件，一个 Pod 也只能配置一块网卡。那么，有没有一种可能，我们为一个 Pod 配置多个网卡，连接多个网络，让一个 Pod 沿多个不同的网络链路发送流量。例如 OpenShift 集群的网络流量使用 OVS 网络，而对性能要求较高业务数据则连接其他类型的 SDN ？

在 OpenShift 4 中引入了 Multus CNI ，它同样是一个 CNI 插件，它实现了在 OpenShift 中将多个网络接口连接到同一个 Pod 。在 Multus CNI 模式下，每个 Pod 都有一个 eth0 接口，该接口连接到集群范围的 Pod 网络。使用 Multus CNI 添加的其他网络接口，则将其命名为 net1 ， net2 等。同时， Multus CNI 作为一个 CNI 插件，可以调用其他 CNI 插件。

它支持：

CNI 规范的参考插件（例如 Flannel ， DHCP ， Macvlan ）。

所有第三方插件（例如 Calico ， Weave ， Cilium ， Contiv ）。

Kubernetes 中的 SRIOV ， SRIOV-DPDK ， OVS-DPDK 和 VPP 工作负载以及 Kubernetes 中的基于云原生和基于 NFV 的应用程序。

我们可以根据业务需要，对插件进行选择。例如对网络性能要求高，可以使用带有 Multus CNI 的 SR-IOV 设备插件。

【 A3 】 rechen 云计算架师 , 某大型银行

如果容器平台非常关注网络时延，建议直接使用macvlan、flannel host-gw、calico 这类underlay技术方案。

【 A4 】 ypl75 工程師 , 金融業

我們使用Openshift 3.11 不太容易監控網路

但評估 VMware NSX - T 插件 可以看的到

【 Q18 】、建设容器云对公司运维部门和人员有啥要求吗？是否需要安排专岗？或者运维是否可以整体外包？

【 A1 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

建设容器云很重要的一个目的是实现DevOps，也就是打通开发到运维的隔阂。

有的中小金融客户的IT运维外包和托管。如果要构建容器云，建议运维团队有自己的员工，兼职或全职负责容器云的事宜，配合公司的开发部门完成日常的工作。

【 A2 】Steven99 软件架构设计师 , steven

建议自主控制，合作研发，日常运维可以外包，但自己一定要有人能在关键时刻顶起来。自主可控，自主把控，所以至少要有一个专职人员负责平台的规划和建设、应用的改造和迁移部署等。

【 A3 】gxcornflakesgxcornflakes 信息技术经理 , 某金融单位

建议公司有专门的容器云运维人员，特别是金融机构如银行更是需要，因为金融机构需要开发和运维严格分离，运维人员需内部培养或外部招聘，或建设初期由外包支持内部人员。

【 Q19 】、公司目前没有专职运维团队，如果上容器云的话，需要如何规划和准备？

【 A1 】Steven99 软件架构设计师 , steven

首先我觉得要先弄清楚上容器云的目的，要解决的哪些问题，至于有没有专职运维团队不重要

容器云是工具，拿工具来做什么，是否真正能按照想法和规划达到目的，收益是什么，这些弄明白了我觉得就知道如何规划和准备容器云的建设步骤了

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

客户构建容器云，现在常见的主要有三种用途：

1.通过容器云构建PaaS平台

2.通过构建DevOps平台

3.通过容器云构建微服务平台

如果公司没有准没的运维团队，最好公司有一名IT人员兼任容器云的架构师，可以整体协调公司的运维和开发部门，这样才能发挥出容器云的威力。

【 A3 】gxcornflakes 信息技术经理 , 某金融单位

首先思考PaaS云平台建设的角色

1、产品经理

2、架构师

3、开发人员

4、运维人员

5、运营

不同时间段，需要的人的角色不一样，有些角色可以一人身兼多职，有些角色可以有厂商代替，随着运营规模的不断扩大，就不断充实团队，对于金融行业、特别是银行业来说，运维必须是内部员工，这个需要内部转型或者外部招聘。

【 Q20 】、在devops中，人员组织的结构调整怎么适应devops的变化？

【 A1 】 Steven99 软件架构设计师 , steven

取决于负责devops建设的人员是否能够触达人员组织架构的调整能力。

devops可能是一个持续优化的过程，人员组织架构的调整也可能是一个动态的过程，这个无法一步到位，因此虽则devops的建设推进，相应的人员和组织结构可能会适时调整，并不需要刻意去做适应

devops不是唯一，只是公司流程、文化的一部分，是动态变化的

【 A2 】 rechen 云计算架师 , 某大型银行

建设研发管理团队或项目管理团队承载规划和实施、运营DEVOPS平台。 开发测试人员、系统运维人员只需要培训相应的流程和操作技勇，无需要做大的结构调整。

【 Q21 】、如何对容器云进行监控？

【 A1 】Steven99 软件架构设计师 , steven

通常可以考虑分层实现监控，然后由统一的监控中心汇总数据进行展示

分层比如说基础设施资源层、容器云平台层、数据层、应用层、周边工具等

每一层次关注的重点不一样，但理论上层与层之间是关联和支撑的，从应用层可以下钻到数据层、平台层，平台层可以下钻到基础设施资源层，基础设施资源层也可能分为若干子层，这样就可以把需要监控的内容都监控起来

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

现在大多数容器云，如OpenShift，都使用 grafana+prometheus进行监控。

需要补充的是，OpenShift上的 grafana+prometheus主要针对容器云平台进行监控，如果客户想定制化监控应用的指标，一般建议单独部署一套 grafana+prometheus，也就是说，把应用的监控和应用的监控分开。如果监控指标不需要定制化，只需要报表的定制化，那么单独部署一个 grafana ，从现有 prometheus 中抓取数据即可。

【 A3 】gxcornflakes 信息技术经理 , 某金融单位

4个层面的监控

1、宿主机监控

2、PaaS云各组件的监控

3、容器资源监控

4、容器内部中间件、JVM的监控（最重要）

【 A4 】rechen 云计算架师 , 某大型银行

建议制定统一的日志规范，将容器云平台，以及其上的业务应用系统的日志进行采集，进行监控和告警。 特别是生产环境的容器云平台要先进行严格的POC测试，包括对供应商产品的监控等功能，选择好成熟的K8S商用发行版。

【 A5 】dyjiafeimao 技术总监 , 12321

可以使用grafana+prometheus进行监控，grafana做可视化展现，prometheus做容器云资源的收集。

【 Q22 】、生产环境怎么监控层面的健康状态？

【 A1 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

就技术层面而言，容器云监控pod的健康，主要是通过liveness和rediness实现的。

前者检查pod是不是好的，后者检查应用是不是可用的。

设置的话，设置在deployments或dc上就可以：

oc set probe dc/mapit --liveness --get-url=http://:8080/health --initial-delay-seconds=30

oc set probe dc/mapit --readiness --get-url=http://:8080/health --initial-delay-seconds=30

【 A2 】Steven99 软件架构设计师 , steven

监控要分层次实现，比如资源层 、平台层、应用层等，不同层次实现方案和采用工具会是不一样的，但可以把监控采集数据统一发送的监控中心，由监控中心对数据进行处理和组合，统一展示

【 A3 】mtming333 系统运维工程师 , 甜橙金融翼支付

prometheus blackbox exporter + alter manager

【 Q23 】、容器云平台选型时，容器云平台测试方案？

【 A1 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

每个厂商都会强调自身容器云平台的优点，从技术角度，有如下建议：

1.容器云平台在金融行里的案例数量，以及使用容器云平台客户的反馈。这点很重要，用过的人才清楚优缺点。

2.选择容器云平台时，不要过多关注UI界面的定制化。主要关注本身代码的稳定性。K8S迭代速度很快，UI和容器云最好做到松耦合。

3.参考第三方关于容器云的调查报告，比如Forester、Gartner关于容器云的报告，他们的评论都很中立。

4.测试性能可以通过压力测试工具，比如Loadrunner发起对容器云上web应用的请求等。

5.稳定性可以通过模拟各种故障，比如网络、Master down之类的测试场景。

【 A2 】Steven99 软件架构设计师 , steven

建议可以找厂商直接要以前的测试方案作为参考，要几家的，对比学习，然后根据自己的实际情况和需求进行调整

【 A3 】rechen 云计算架师 , 某大型银行

技术选型时，需要进行严格的POC技术测试。POC测试时，譬如在稳定性方面，可以考察产品的各个关键组件，设计相应的破坏性的测试案例，以及大并发和高负荷场景下的性能表现等。

【 Q24 】、容器平台工作节点类型选择？

【 A1 】 mtming333 系统运维工程师 , 甜橙金融翼支付

看主机的设施基础是啥，有啥用啥，区别不大。

没包袱，就用物理机。

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

理论上物理机部署能获得最大的性能需求，但是不易扩展、运维困难；而选择虚拟机部署网络以及计算资源的损耗较大。我们通常会从以下维度对比：

集群性能：通常裸物理机运行在性能上占据优势，主要由于虚拟化层带来的资源损耗。

运维管理：使用虚拟化可以利用 IaaS 层提供的运维便利性，而物理机运维相对复杂。

资源利用率：物理机部署如果仅部署 OpenShift 运行应用，在业务不饱和的情况下，物理机资源利用率低，而虚拟机则可以将物理机资源统一调度分配，资源利用率高。

虚拟化成熟度：企业是否已经有成熟的 IaaS 管理系统。

IaaS 与 PaaS 的联动集成：企业是否考虑实现 IaaS 与 PaaS 的联动，主要表现在 OpenShift 自动扩容集群节点或对节点做纵向扩展。

成本：分别计算虚拟机和物理机所需要的成本，理论上虚拟机的成本更低，物理机可能涉及很多额外的硬件采购。

上面给出的几点选型参考，每个企业的实际情况不同，需要结合企业的具体情况进行选择，必要时可以进行对比测试。当然，这也不是非此即彼的选择，目前实施落地的客户中，有完全运行在物理机环境的，也有完全运行在虚拟机环境的，还有客户选择 Master 节点使用虚拟机， Node 节点使用物理机的。

如果选择使用虚拟机部署， OpenShift 3 认证的虚拟化平台有红帽 OpenStack 、红帽 KVM 、红帽 RHV 以及 vSphere ，在具体的项目实践中，选择在 vSphere 虚拟化和红帽 OpenStack 的情况较多。

【 A3 】Steven99 软件架构设计师 , steven

补充几点：

1.虚拟化层性能损失大概在20%多， 容器性能损失在1%多

2.虚拟化隐藏了物理服务器细节，不同型号的物理服务器性能是不一样的，某些特殊场景下可能会导致负载不均衡

3.虚拟化的好处是容器节点扩容方便，另外也进行了一层隔离，相对更安全，安全性更高

4.虚拟化可能导致虚拟机所在的物理服务器资源争用，但在容器层是看不到的，无法有效定位问题

【 Q25 】、开发测试生产环境如何衔接设计的devops流水线是最好的，有没有所谓的最佳实践？

【 A1 】Steven99 软件架构设计师 , steven

我一直不建议用最佳实践，每个公司情况都不一样，适合别人的不见得适合你。一切从实际出发，理解自己的现状和特点，选择适合自己的工具和流程，实现自动化。

初始可以基于容器化paas实现一些devops流水线，但对于大公司来说，构建独立的工具和流程可能是更好的方法

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

从技术落地角度，目前DevOps的实现主要有几种：

1.基于Jenkins Pipeline

2.基于OpenShift S2I+ Jenkins

3.基于Tekton

在目前的实现中，第一种和第二种多一些。我也建议通过Jenkins File打通流水线。

关于几种方式的对比，请参照我的文章。

https://developer.ibm.com/zh/depmodels/cloud/articles/cl-lo-building-an-enterprise-oriented-cicd-based-on-openshift/

【 Q26 】、生产环境中，由于测试环境与生产物理隔离，镜像如果提取到生产不知道大家是怎么处理的呢？

【 A1 】wykkx 系统架构师 , 某基金公司

如果是完全的真物理隔绝，这个问题无解。另外有一种折衷的方案，会比问题中使用的方案好一些，就是使用网闸的方式。

【 A2 】rechen 云计算架师 , 某大型银行

1、搭建一个统一的容器镜像仓库，开通生产网访问此仓库的端口的路由和防火墙。

2、建立管理规范，只有UAT测试通过的项目，投产申请审批通过后，才将相应的镜像复制到生产的REPO中。

【 A3 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

这是个好问题。生产和非生产，一般都会做物理隔离，部署两套集群。两个集群之间，可以配置两个镜像仓库之间的同步。然后生产和非生产可以通过一个Jenkins Pipeline串起来，这个pipeline可以放到两个环境都能访问的内部git上。我觉得你们的方案可以，如果觉得不安全。可以考虑手工把镜像导入到生产，但这样会稍微麻烦一些。

【 Q27 】、开发测试环境与生产环境物理隔离的情况下如何做容器平台的devops？

【 A1 】rechen 云计算架师 , 某大型银行

定义好职能边界：devops的Cl，和研发管理的开发，测试活动，在开发测试环境中进行。CD到ST环境，UAT环境，也是在开发测试环境。

建设跨2个环境可以访问的统一的制品库，制定好管理规范，只有UAT验证过，且上线审批过的项目制品，才能CD到生产环境

五、 安全相关话题

【 Q28 】、如何保证容器云符合等保安全要求？

【 A1 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

此前红帽OpenShift4已经在和相关部门进行等保3的认证，应该很快就会颁发证书了。里面主要是OpenShift如何通过配置满足等保3的要求

【 Q29 】、devsecops中的质量门，除了做代码安全，还建议做些什么？

【 A1 】rechen 云计算架师 , 某大型银行

1、容器的镜像安全。

2、资源的安全加固。

3、重要密码、密钥凭证的统一管控。

【 A2 】魏新宇 售前技术支持 , 红帽企业级开源解决方案中心

DevSecOps是个比较全面的概念，如下图所示：

OpenShift 既可以承载无状态应用，如 Web 类应用；也可以承载有状态应用，如 redis 等。从安全角度看，Web 类应用由于直接对外暴露，显然更容易受到黑客攻击。因此目前在 DevSecOps 引用的安全工具中，大多也是针对于 Web 类应用展开的。

DevSevOps 的 Web 安全工具大体分为静态安全工具和动态应用安全工具。静态安全工具，主要是通过分析或者检查 Web 应用程序源代码的语法、结构、过程、接口等来检查程序的正确性。静态安全工具使我们能在开发阶段（而非应用开发完成后）探测出源码中的安全漏洞，从而大大降低修复安全问题的成本。

相比于静态安全分析工具在开发阶段发现问题，动态应用安全工具则是在 Web 应用运行时模拟黑客攻击，从而无需源代码即可识别安全漏洞，并确定组织的实际风险。

在开源界，静态应用安全工具如 SonaQube，动态应用安全工具如 OWASP（Open Web Application Security Project）都被广泛使用。

我们看一个DevSecOps的例子：

上图所示模型基于 OpenShift 3.11，通过 Jenkins 实现 Pipeline 管理。整个 DevSecOps 包含如下 7 个大的阶段： 1.启动 pipeline 后，首先将从 git 存储库中获取 JavaWeb 应用程序源代码。 2.调用 maven 进行代码构建。 3.调用 JNnit 运行自动化测试。 4.使用 SonarQube 执行静态代码分析扫描，将生成的工件（jar 包）推送到 Nexus 进行存储。 5.通过 OpenShift Source to Image 构建包含应用程序的容器映像，并将其推送到红帽企业级镜像仓库 Quay，以便进行额外的 OpenSCAP 安全扫描。 6.将应用容器镜像部署到 OpenShift，以便 OWASP ZAP 可以扫描该应用程序的 Web 漏洞。 7.根据 OWASP ZAP 扫描的结果，引入人工判断工作流，决定将应用自动部署到 Stage 和 Prod 环境。