随着云计算、DevOps和微服务应用架构的发展，容器云成为IT的主要基础设施平台。以Docker为代表的容器技术，是目前最有效的应用交付模式之一；以Kubernetes为代表的容器编排技术，是目前最流行的应用部署方案。目前的银行都或多或少的处于数字化转型中，云平台的基础设施、DevOps的工程体系和微服务应用架构是IT技术转型的底座。而容器云又是这个底座下的一块基石。

银行因其业务复杂性和对业务连续性的要求，在容器云的应用上不仅会遇到一般的技术难点，还会遇到一些特有的问题。特别是对于刚开始容器云探索的银行企业来说，这些问题和难点往往会影响容器云平台的建设进度，甚至是发展方向。下面几个问题是在Docker+K8S容器云建设过程中，最常被问起和需要解决的难点问题。
更多难点交流问题集锦：http://www.talkwithtrend.com/Activity/index/op/question/id/1525

1、企业是应该选择原生的docker还是定制化的docker，比如胖容器/富容器？

docker是当前企业在进行容器化时首选的容器技术，但是原生的docker在实际使用的过程中，
特别是在传统虚机运维到容器化运维的过渡中，会碰到以下类似问题：
1、如何ssh登录到容器，像登录虚机那样，可以通过ssh进行管理
2、对于普通用户来说，如何从容器中拷贝文件到外部
3、虚机中一般会配置定时任务，在容器中如何实现
4、虚机中一般会安装各种agent，容器中怎么去安装

若企业直接采用原生的docker，那么以上问题是比较棘手的。因此企业在容器技术选型上，是否应该为了最大程度兼容虚机运维模式，对docker进行定制化改造，满足实际需求呢

嘉宾回复：
是使用原生还是定制就要看企业实力了。一般的企业不会去动原生的东西，不愿意将人力花在这个方面。很多企业是通过应用的改造来适配容器化的方案，包括运维上的问题。
4个问题：
1、docker exec可以进入容器，如果是k8s或者ocp，还有有相应的api
2、方便拷贝的方式第一个容器中应用产生的文件目录挂载到本地；第二个使用相应的命令如docker cp；也许你说的不仅限一些简单场景，其实都是有方法的，不仅以上两种
3、容器中也是可以使用crontab定时任务操作的
4、agent的功能要先说清楚，如果上k8s或者ocp，一个pod可以完成你要说的内容。如果仅仅是用docker，根据功能需要应该也是有方法的。

嘉宾回复: gavin_zhang 系统架构师 , 某股份制银行
1 docker exec可以满足要求
2 最直接就是挂在本地磁盘存储到容器上
3 可以考虑一下，定时调度起一个Docker执行任务
4 主要是这些Agent是用来干什么的？Docker实例本来就是作为一种一次性的，不可变的运行实例，传统虚拟机的那个操作Agent，不符合容器的设计理念

定制化最大的问题在于，目前技术升级比较快，一旦定制，就锁定在几个版本了，后续升级维护工作量会很大。

2、容器云平台主流技术和成熟产品选型及如何制定相关的标准和规范探讨？

想问下，在引入容器平台时，需先了解当前主流的容器平台技术和成熟产品，然后制定相关的标准和规范。具体如下：
1、想了解当前主流容器平台openshift3、openshift4、Rancher、博云等国产容器产商的有哪些区别？容器平台如何选型？这些产品的功能、性能比较。
2、除了资金成本，容器平台后期的使用和运维需要如何考虑，目前公司自己对容器平台的开发能力不在，运维人员需要具体具备哪些能力，运维与开发如何协作，投入运维人员的规模如何估算？
3、容器平台早期实施的过程中需要做哪些规划，避免哪些坑。

回复：Garyy 系统工程师 , 某保险
容器这块目前已经成为业务上云的主流技术，越来越多的企业选择容器，可见其已深入“企”心。
1）针对这几个厂商的产品
ocp是红帽搞的一个容器平台，红帽在容器研发领域投入非常大，产品力也是不错的，尤其是平台的易用性和功能性方面，基本可以满足一些中小互联网企业的需求，现在案例也比较多。但是，有几个问题是需要注意的，首先是ocp核心研发好像没有本地化的支持，都是一帮老外在搞，相应没有那么及时；国内基本是靠合作伙伴的能力，来做一些定制化和售后的服务，服务水平和技术实力不一定能达到原厂的要求。
rancher不是太了解，仅仅知道它是一个容器厂商。
博云是一家创业型公司， 总部在苏州， 也是红帽的合作伙伴，从ocp service开始做，目前已经有比较完善的生产线包括容器，微服务，运管平台，devops平台等；金融的案例也比较多，像银联。
2）使用运维一套ocp平台，不仅仅要有运维方面的知识技术，同时还应具备一定的开发能力，例如python，java等，还需要熟悉一些开源的产品技术了，例如nginx，Prometheus，ELK，kafka，jenkins等
3）规划需要case by case的去谈，是新建，还是利旧，跑哪些业务，都是需要去分析的。坑的话，肯定是有的，但是也要case by case去谈。

回复：demon1860aa 信息技术经理 , 农银人寿
我来回答一下你的问题，仅供参考：
国内做容器的有很多公司大都是基于k8s定制而成，很多公司更是做容器管理、做devops发布平台。就产品多样性而言，真正能够有容器生态的也只有redhat一家。openshift是红帽商业化的k8s发行版本，就产品线而言肯定的最为丰富的，中间件JBoss、镜像仓库Redhat Quay，自动化工具Ansible、Ansible Tower、SDS Gluster、Ceph、操作系统RHEL，Cloudforms等等，而当年与Docker吵的不可开交的CoreOS也是被redhat收购，老牌的redhat优点品牌足够响亮，产品生态足够多，缺点国内工程师数量有限，可能不会像小厂商一样直接服务，很多时候可能是由第三方来实施的。

Rancher也是很具有特色的公司，Rancher其实产品很不错，号称Run Kubernetes Everywhere，容易部署，界面简洁且上面功能也很多，支持混合云，能够支持上千k8s集群的管理。也提供了catalog，registry，devops工具能够支持pipeline。缺点也很明显，就是虽然国内有分公司，但是还是人少。但就部署方案来讲，一般的客户好像原厂工程师是可以上门进行实施的。

第三方公司，国内厂商就比较多了比较出名的灵雀云、博云等等从K8s代码来讲基本上贡献率就不谈了，应该更多在做一些外层开发的扩展如运维管理、账号管理、权限管理、Devops发布（如jenkins二次开发等等）、平台级的管理等等上层管理层面的软件。小一些的厂商，也有各自的优势，就是更珍惜客户，客户响应速度肯定很快，但其核心技术能力相对大厂肯定是受限的，尤其是解决底层bug或者定位各类复杂性故障的时候可能会相对慢一些。

再有一个选择可以是阿里云私有化APsara Stack的方案，阿里云其实整体环境生态还是非常不错的，我们知道阿里云的ECS国内市场占有率第一，而阿里云也有私有云方案，也可以和公有云集成实现混合云架构。也有类似第三方开发的权限管理Devops发布平台（code pipeline）等等，还有集成istio Service-meshed，Derrick等自动化转换工具，而且阿里云的公有云生态是成熟度最高的，人工智能、大数据、OCR、身份识别、视频、双录等等解决方案很是齐全。缺点可能是由于阿里云自带互联网企业特性，原有企业运作模式更多是直接2C端，可能和传统厂商和服务商的服务思路还是有一些区别的。

总之，选型还要看企业实际情况，实际需求而来，既然容器的引擎是docker，集群编排靠k8s，其实不同服务商大家优缺点可能不太一样。但核心就是容器及k8s，其他的外围生态、服务质量，产品公司服务的可持续性，服务商自身技术等都决定最后的选择。建议可以多找几家了解一下他们产品，最好能够逐一进行POC。

需要关注的点：第一就是规划，你的容器是直接部署在bare metal上还是虚拟机上，因为虚拟化软件本身就有10%-20%对于硬件的消耗，因为容器本身消耗理论值在5%以内，第二就是你对于容器网络的选择，网络将是你在使用容器时候的一个很大的一个坑。比如Vxlan等技术由于对于数据包的反复封装会导致网络性能下降，kube-proxy默认使用的iptables在条目过多的情况下性能也是衰减的，当然要结合你的部署架构。第三就是你的存储，是通过传统FC-SAN，还是通过NFS、还是对象存储等等方式，如果是网络存储这将影响你的数据读取速度。第四就是你的微服务的设计和拆分，第五就是你的CI/CD的设计。第五就看你们在建设的时候的需求了，如果你需要对象存储，你可能还需要选择ceph，如果你选择ABtest、蓝绿部署、或是灰度发布那么就考验我们发布方案和编排能力了。会不会写dockerfile、会不会写deployment.yaml，jenkins file，这些可能需要和开发团队、IT领导，服务商一起去探讨，如果需要引入代码审核，安全扫描等。

回复：李鸿宇 系统架构师 , Rancher企业级Kubernetes管理平台
针对您关心的问题，我来回答一下；

想了解当前主流容器平台openshift3、openshift4、Rancher、博云等国产容器产商的有哪些区别？
Rancher和Redhat的openshift是国际上主流的私有容器平台，和博云相比，这两家的产品不仅仅只是关注容器云领域，更是提供了一系列云原生相关的解决方案。比如：Rancher不仅提供了自家的Rancher容器平台，还有Rancher OS容器操作系统、Longhorn分布式容器存储、Submariner跨集群网络通讯、RKE自动化集群部署工具、K3S边缘计算以及Rio轻量级PaaS平台。而Redhat作为一个老牌linux系统厂商，更是提供了很多对于容器平台支撑层面的解决方案支持。

容器平台如何选型？

如果您是开源社区的爱好者，并且对于云原生建设有自己的想法和个性化需求，那么强烈建议您选择Rancher，这是一个100%开源的容器平台，并且它提供了容器平台上所有功能的API支持，方便用户开发定制。Rancher可以做到对国内外主流的公有云、私有云的多集群统一纳管，这是企业在未来混合容器云平台建设所要考虑的关键功能。当然如果您的环境里已经大量使用Redhat解决方案，并且对于平台操作更偏向于编排好的固定式的使用习惯，可以考虑Redhat openshift，因为它可以比较容易的和Redhat其他解决方案结合。目前Redhat openshift是一个部分开源的容器云解决方案，对于多云管理的支持可能会被限定在对国外的公有云支持比较好。Rancher提供的是原厂服务，在中国拥有核心研发部门，技术水平非常高。今年在中国的人员规模有大幅度增长，服务的响应和覆盖有了巨大的提高。Redhat研发主要在国外，国内主要靠代理商服务。

这些产品的功能和性能比较？

目前不管是Redhat的openshift、Rancher还是博云，都是基于docker和Kubernetes技术发展来的，所以在产品性能上各个厂家的产品都是差不多。主要是在产品功能上有所不同，拿Rancher和Redhat为例，Rancher主要功能优势是在多云多集群管理、云原生生态融合、原生kubernetes支持以及简单易用上面，同时Rancher也集成好了很多云原生的解决方案。例如：日志监控、告警通知、应用商店、微服务网格、DevOps工具链、Windows容器集群支持等。Redhat openshift主要功能优势是在和Redhat众多解决方案融合，专注于开发人员的使用体验以及Redhat全堆栈安全支持，另外Redhat openshift也提供了日志监控、告警通知、应用商店、微服务网格、DevOps工具链等功能，但是不支持windows容器集群。

除了资金成本，容器平台后期的使用和运维需要如何考虑？

制定一个三步走的计划，让运维人员分阶段参与业务项目的开发工作，了解项目从开发到构建到测试到上线的全部流程，实现开发和运维的一体化。

目前公司自己对容器平台的开发能力不在，运维人员需要具体具备哪些能力？

运维人员除了计算、网络、存储这些日常技术架构的管理能力，另外需要了解docker、kubernetes、CI/CD流水线、日志监控、微服务等容器平台生态的管理能力，建议参加kubernetes CKA认证培训，可以让运维掌握容器平台运维的基础能力。Rancher提供很多免费在线培训，可以去哔哩哔哩上搜索Rancher去学习相关知识。

运维与开发如何协作？

运维和开发协作，目前业界有两种声音，一种声音是文化先行，通过对运维和开发部门进行Devops文化建设，统一运维人员和开发人员的思想，打破部门墙，最后通过引入容器平台和Devops工具实现开发运维一体化。另一种声音是工具先行，通过引入容器平台和Devops工具，让开发和运维人员将部分应用运行在此平台上积累经验，最后形成内部Devops文化，实现开发运维一体化。当前大部分用户都是采用第二种方式来增强运维和开发的统一协作。

投入运维人员的规模如何估算？

对于投入运维人员的规模，我这里有个案例可以供您参考，国内某大型寿险企业使用Rancher容器平台，运行超过200个物理服务器、接近6000个容器规模，总共投入运维人员为5个。

容器平台早期实施的过程中需要做哪些规划，避免哪些坑？

容器平台早期实施的过程要进行以下几个方面的规划：基础资源层面（计算、网络、存储），运维管理层面（性能监控、日志告警、告警通知、认证管理），开发运维层（应用容器化、流水线集成、微服务）。目前容器技术已经越来越成熟了，很多客户开始将核心业务迁移到容器平台，我认为在容器平台建设中最大的坑还是在于用传统基础架构的管理思想去使用容器平台。

回复：gavin_zhang 系统架构师 , 某股份制银行
我来回答一下吧
1 现在的容器平台，基本都是基于kubernetes做的产品话，最基本的功能上没有太大的差别，主要是看一些附加的能力，如云管工具，对IaaS的支持还有安全，对开发人员的友好性这些方面。选型是还要考虑厂商的支持能力，还有就是厂商在开源社区的影响力等。具体的功能性能对比没有做过，每个厂商都会提供，综合对比一下
2 不考虑自己开发和增量开发，后期的运维主要就是容器平台的日常运维（监控，告警处理和问题定位等），还有容器平台属于更新比较快的产品，平台升级和补丁也会比普通应用多。运维人员对Linux的基础，自动化脚本能力要求比较高。

3. 这边真没有什么规则，如果说有，就是尽量各层解耦，选择主流的技术路线。

回复：匿名用户
曾在博云工作过，这些问题可以简要回答：
1、国内很多厂商都是基于K8S在做，博云有细分版本是基于OCP，如江苏银行。功能、性能上大致都一样，底层都是依赖OCP或者K8S。
2、先了解什么是docker吧，不管是K8S还是OCP，网上有大量的教程可以轻松搭建一套试验环境，可以在试验环境上一步步操作了解其有哪些功能，能做哪些事情。容器平台的大部分功能都可以通过命令行实现。
3、上不上容器是要做一番前期调研工作的，比如要上容器的应用是敏态还是稳态，业务迭代是否频繁、是否要频繁上下线替换版本，是否有不确定性的业务爆发期等。强事务性的应用不建议上容器

回复：郑金辉 技术总监 , 中国电信系统集成公司
我很赞成上面专家说的内容，重复的话就不说，想说以下几点：
1、事前的规划很重要：关键是上容器有没有最好相应的准备，业务类型是什么，稳态还是敏态，是否频繁变化；有没有做好做的技术储备和技术积累，不光是人；有没有做好团队重塑的准备。
2、选型要量力而行：Redhat肯定是生态最完善的大厂，但在国内的服务高度依赖代理商，需要考虑，强调国产自主可控的场景需要慎重。Rancher技术过硬，但是国内的服务覆盖的问题不能不考虑；博云、时速云、灵雀云等是国内容器云的代表，服务能力是强项，自主产品参差不齐，需要甄别。
3、产品能力不是唯一的维度：容器云的上线，跟微服务有千丝万缕的联系，不是简单产品的堆砌，更是需要大量服务的结合。
最重要的是要结合自身的实际情况，谨慎一点没大错！

3、kubenetes在金融多安全域的环境中，架构规划问题？

金融行业网络架构中存在多安全域的设计，kubenetes在多安全域网络隔离的情况下，每个安全域都部署一套k8s集群吗？生产环境k8s集群中calico有哪些网络控制策略最佳实践？

回复：nameless 技术总监 , 某云计算厂商
理论上来说各个安全域的网络时隔离的，如果部署一套k8s集群，所有的node节点和master节点是联通的，node直接默认也是联通的。 可以每个安全域部署一套k8s集群，使用同一的容器管理平台，这是k8s多集群管理。
calico是k8s其中一个网络插件，其他还有flannel、ovs等不同的网络插件，生产使用哪一种网络插件需根据自身业务需求选择。

回复：匿名用户
其实不需要这么复杂，比如分了互联网区、中间业务区、核心业务区，k8s集群有6个node节点，可以两个放互联网、两个放中间业务，两个放核心业务，比如master节点都在OA区，只要将master跟着6个node网络上能通即可，不需要node间都能互相访问，一个集群也是可以的。

calico是可以解决集群内外访问的问题，但是随着需要访问集群的外部节点的增加，那运维成本就很高了。可以使用ingress类似的解决方案

4、容器云平台建设难点之网络如何选择？如果选SDN网络，那么SDN网络实现方案又应该如何选择？

容器网络如何选择？容器云平台的网络一直是一个技术难题，是采用SDN网络还是桥接到Underlay网络；如果使用SDN网络，那么多的SDN网络实现方案，如何选择？

回复：Garyy 系统工程师 , 某保险
关于容器网络的建设思路：
容器网络发展到现在，已经是双雄会的格局。双雄会其实指的就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。

网络需求调研发现，业务部门主要关注以下几点：1、容器网络与物理网络打通2、速度越快越好3、改动越少越好4、尽可能少的风险点。

容器的网络方案大体可分为协议栈层级、穿越形态、隔离方式这三种形式
协议栈层级：二层比较好理解，在以前传统的机房或虚拟化场景中比较常见，就是基于桥接的 ARP+MAC 学习，它最大的缺陷是广播。因为二层的广播，会限制节点的量级；三层（纯路由转发），协议栈三层一般基于 BGP，自主学习整个机房的路由状态。它最大的优点是它的 IP 穿透性，也就是说只要是基于这个 IP 的网络，那此网络就可以去穿越。显而易见，它的规模是非常有优势，且具有良好的量级扩展性。但在实际部署过程中，因为企业的网络大多受控。比如，有的企业网络的 BGP 是基于安全考虑不给开发者用或者说企业网络本身不是 BGP，那这种情况下你就受限了；协议栈二层加三层，它的优点是能够解决纯二层的规模性扩展问题，又能解决纯三层的各种限制问题，特别是在云化 VPC 场景下，可以利用 VPC 的跨节点三层转发能力。

穿越形态：

这个与实际部署环境十分相关。穿越形态分为两种：Underlay、Overlay。

Underlay：在一个较好的可控的网络场景下，我们一般利用 Underlay。可以这样通俗的理解，无论下面是裸机还是虚拟机，只要整个网络可控，容器的网络便可直接穿过去 ，这就是 Underlay。

Overlay：Overlay 在云化场景比较常见。Overlay 下面是受控的 VPC 网络，当出现不属于 VPC 管辖范围中的 IP 或者 MAC，VPC 将不允许此 IP/MAC 穿越。出现这种情况时，我们可利用 Overlay 方式来做。

Overlay网络使物理网络虚拟化、资源池化，是实现云网融合的关键。把Overlay网络和SDN技术结合使用，把SDN控制器作为Overlay网络控制平面的控制器，这种方式更容易使网络与计算组件整合，是网络向云平台服务转变的理想选择。

隔离方式：

隔离方式通常分为VLAN和VXLAN 两种：

VLAN：VLAN 机房中使用偏多，但实际上存在一个问题。就是它总的租户数量受限。众所周知，VLAN 具有数量限制。

VXLAN：VXLAN 是现今较为主流的一种隔离方式。因为它的规模性较好较大，且它基于 IP 穿越方式较好。

我们从协议层级、穿越形态和隔离方式对kubernetes几个常见的网络组件（calico、contiv、flannel、Openshift SDN、自定义路由）在传统机房网络以及云化VPC网络应用场景下做一个分析，用连线图来表述它们之前的关系。

回复：liufengyi 软件架构设计师 , 某互联网银行
优先考虑公司整个网络扁平化，互联互通，这样对应用改造成本要小很多，即基于公司原来的网络打通来进行，如果容器的应用是一个相对独立的服务，可以考虑overlay。规模不大的情况下一些开源网络组件可以考虑采用

回复：Steven99 软件架构设计师 , steven
容器网络选择我个人觉得不是重点，其实不管哪种网络，都应该对终端用户透明，所以不应该纠结于网络模型
需要考虑的重点可能是安全性，稳定性，易用性等，我们使用calico网络，发现也是很多问题，在考虑替换。开源产品总是需要很多额外的工作，测试验证，逐步优化，不实际使用，很难说哪种更合适，在使用过程中可能会逐步清晰自己的需求
容器安全，容器网络安全可能是重点，特别上生产业务，服务数量达到一定量后，会有很多想不到的问题，当然，不实际做过，也很难选择，所以可以尝试先用起来，经常使用会逐步清晰明白自己要什么。

回复：匿名用户
calico、bgp、ingress、nginx等都是可以的
1、calico将集群内与集群外网络打通，但是随着集群外访问集群内的节点越来越多，运维难度会加大
2、bgp需配置内部路由协议，性能上有损耗
3、ingress、nginx道理类似，将需要被外部访问的应用使用这两个组件外部负载进到集群内部
4、hostnetwork方式
5、nodeport方式
。。。

如何选择要根据自身IT架构及监管要求定了

5、容器东西向网络安全是怎么考虑的？

回复：zhuqibs 软件开发工程师 , Mcd
东西向流量的控制，是服务网格的控制范畴，istio可以实现，但目前istio不完善，所有很不好用。建议使用kong、traefik为代表的api gateway，其中Kong基于nginx，可以在容器中部署到每个pod中去，控制pod和pod之间的流量。

回复：nameless 技术总监 , 某云计算厂商
东西向流量指同一宿主机上与其他容器相互访问，同一主机上pod默认是互通的。
我认为可以从上层逻辑控制上减少安全隐患，即根据业务划分不同的逻辑集群，尽量让有血缘关系的业务放在同一逻辑集群。

6、容器中的应用问题排查方法探讨？

如何获取容器里面的堆栈信息，如何抓包分析，当有容器外应用访问容器内应用或容器内应用访问容器外应用，如何根据ip追踪访问链路。

回复：zhuqibs 软件开发工程师 , Mcd
从监控组件考虑，可以使用skywalking进行链路上api调用中端口信息的跟踪，如果用商业化apm组件，cisco、听云都有不错的产品。
在微服务架构中，每个pod就是一个服务，在每个应用pod中加入kong组件，每个kong组件都可以输入流量监控数据到prometheus，这样，也能不方便取代链路监控软件的功能，当然只是“部分”，skywalking和apm还能取到其他类型的数据。

回复：liufengyi 软件架构设计师 , 某互联网银行
我们集成了apm来做故障发现和排查，可以通过查询容器在哪台宿主机上，然后抓指定虚拟网卡上容器的网络包

回复：gavin_zhang 系统架构师 , 某股份制银行
堆栈信息可以在应用框架加入dump功能，以日志的方式输出到日志系统。
实现应用的全链路最终，解决方案有Spring cloud sleuth等

7、容器云平台的整体规划：包括计算资源、存储、网络的选型？

大家好，我想了解一下容器云平台的一个整体规划，包括计算资源、存储、网络的选型，我们打算将微服务迁移到容器云平台。

回复：nameless 技术总监 , 某云计算厂商
个人意见：
1、首先确定目标，建设容器云平台的目标，规划哪些业务上容器，大概的资源需求是多少，集群规模多大等等；
2、容器平台选型，基本是k8s，这个应该没问题；
3、计算资源：基本是采用裸机还是虚拟机作为计算资源，两种方案各有优劣，如果已有IaaS平台，可以采用虚拟机，如果没有IaaS平台，也可以直接使用裸机；
4、网络资源：需要考虑业务上容器是否需要对业务进行改造，另外就是将来业务向容器平台迁移过程，比如一个微服务业务，迁移至容器平台时，先迁移部分微服务，还是整体迁移？迁移部分微服务后，已上容器微服务和未上微服务网络网络通信等等；
5、存储资源：考虑业务上容器是有状态业务还是无状态业务，已经业务对性能的影响，选择合适的存储资源；

综上，还需要考虑运维团队的运维能力、以及和开发对接等等。

8、使用容器云平台，如何提升系统开发和测试的能力？

目前公司选择springcloud微服务体系，在开发测试过程中，如何使用容器云平台提升系统开发测试能力？能够提升哪些能力？
有没有较好的实践路径和应注意的关键点？比如是否在开发测试云上先搭建通用的服务（注册中心等，是否开发测试云通用一套服务？），maven私仓管理、基础镜像管理等等

回复：gavin_zhang 系统架构师 , 某股份制银行
对于测试，可以使用容器平台的持续交付的能力，缩短测试版本周期和环境准备的时间；使用平台灵活的路由功能，进行多版本兼容性测试。
较好的实践路径和应注意的关键点 ：
1 通用的服务建议统一建设成平台服务，但是不建议测试开发使用同一个运行实例。
2 建立私有的镜像仓库，制定基础镜像白名单
3 做好镜像的版本管理，利用容器和git的tag，做到实例和镜像，镜像和源码的对应

9、银行重要的业务场景如何用k8s做滚动更新？

回复：匿名用户
这个问题细说的话就多了，需要看业务场景。强一致性交易类业务，像消费之类的需要应用本身来保证，事务失败要能回滚。那版本升级回滚就要有优雅停机的动作，一些渠道类交易，只是做中间转接，一般是可以直接做升级回滚的。
升级回滚的操作，主要是通过替换应用依赖的镜像版本。k8s的升级回滚是利用新版本镜像或者旧版本镜像拉起一个新pod，下线一个旧pod依次完成此操作的，保证业务正常运行。

回复：gavin_zhang 系统架构师 , 某股份制银行
平台方面：结合K8s的流量分发，实现金丝雀发布机制，通过精细的流量控制，来实现业务的滚动更新。应用方面：应用需要有合理的设计，在规划时就需要有相关的设计，对应用有合理的低耦合的切分，尽量减少发布应用的涉及面，这其中最重要的如何实现问题的回退，特别是影响到账务数据的，采用数据染色或是零时表的方式，尽量做到应用可回溯。

回复；rangeryu 产品经理 , 蚂蚁金服
这个问题可以结合着蚂蚁作大规模发布的时候所关注的变更管理来回答。

原生 deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。

在实际的生产环境中，围绕容器大规模变更会配合业务监控及更多维度的观察，确保每一步都是符合预期、验证通过的。这样在应用实例层面的精细化管控，为运维提供了能够及时刹车回滚的机会，是线上应用发布的一个重要的保险绳。

简单来说，在蚂蚁内部所有的变更要满足” 可灰度、可监控、可应急 “，当基础设施全面转向云原生，就开始基于Kubernetes作了非常多扩展和补充。对于金融业务场景，从实际产品层，需要做到：

1. 感知底层拓扑
2. 分组/beta/分批发布
3. 优雅摘流

10、 容器云的高可用问题？为了实现高可用，容器云内部需要多个独立的Kubernetes集群，底层网络和基础设施应该如何部署才能实现故障隔离？应用如何在多个集群之间实现故障转移？

回复：匿名用户
k8s应用高可用的功能都是k8s本身完成的，如果需要做到集群间的单个应用的高可用，应该是要做高度定制，在容器云平台上监控应用的状态，公用镜像仓库。

回复：gavin_zhang 系统架构师 , 某股份制银行
目前的一种实现方案是有应用层来做跨集群的高可用方案，利用Euraka或是Zookeeper这种跨集群的管理中心，来实现应用之间的跨集群调用。如果实现了服务网格（Service Mesh），可以考虑在Service Mesh层实现。