随着云计算、DevOps和微服务应用架构的发展，容器云成为IT的主要基础设施平台之一。以Docker为代表的容器技术，是目前有效的应用交付模式之一；以Kubernetes为代表的容器编排技术，是目前流行的应用部署方案。云平台的基础设施、DevOps的工程体系和微服务应用架构是IT技术转型的底座。而容器云又是这个底座下的一块基石。
下面几个问题是在Docker+K8S容器云建设过程中，最常被问起和需要解决的难点问题。来自社区交流活动，多位社区会员分享解答，整理者：gavin_zhang
【问题描述】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、容器平台早期实施的过程中需要做哪些规划，避免哪些坑？
此问题有多位同行进行详细的解答分享，我们已经专门整理成一篇文章，并在不久前向读者们推送过，点击下面的标题即可回顾阅读：
争议 | 主流容器云平台的功能、性能比较，我们该如何选型？
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网络实现方案，如何选择？
@liufengyi 某互联网银行 软件架构设计师：
优先考虑公司整个网络扁平化，互联互通，这样对应用改造成本要小很多，即基于公司原来的网络打通来进行。如果容器的应用是一个相对独立的服务，可以考虑overlay。规模不大的情况下一些开源网络组件可以考虑采用。
@某金融企业 系统工程师：
calico、bgp、ingress、nginx等都是可以的
1、calico将集群内与集群外网络打通，但是随着集群外访问集群内的节点越来越多，运维难度会加大
2、bgp需配置内部路由协议，性能上有损耗
3、ingress、nginx道理类似，将需要被外部访问的应用使用这两个组件外部负载进到集群内部
4、hostnetwork方式
5、nodeport方式
……
如何选择要根据自身IT架构及监管要求定了
@zhuqibs 软件开发工程师：
关于SDN还是underlay，如果你是自建的，一定不会选用SDN， 成本啊，兄弟们！Cisco去年要给我们搭建个ACI， 一个交换机就是1万多，如果是银行钱多没有关系，中小企业资金紧张加上疫情，哪会选择。
VMware的NST-G我们也用过，有bug，这个PKS每个月都会有一次“月经”，每次网络存储全堵死，IO基本龟速，厂商派人解决了大半年，连交换机都换了都没有解决，结果赔了3台服务器，帮我们全换成普通的vcentor。
SDN听上去美好，现实很骨感，当然如果你有钱并愿意试错，又追求新技术，当然也是没问题的。比如阿里云、腾讯云这些公有云，基本必然是SDN，人家有钱有人，来填坑。
所以，一般公司Underlay就可以了，加上Kubernetes自己的calico，fannel，或cattle，一般都没问题，就是网络上没有硬隔离，没有客户化的东东，但我们可以用公有云的啊，自己去建，多费钱。
@xiaoping378 某行科技公司 系统架构师：
1. 既然是说容器云平台建设，肯定已经有了网络基础设施，那不考虑数据中心级别的SDN方案。只考虑在已有的网络建设成果上建设。
2. 不用迷信商业方案，无论是开源还是商业方案，大家都得遵守k8s的cni接口。不建议在容器网络方案中寄托太多的功能，如网络限速、安群策略等等。
3. 考虑目前主机层面大都可以保障二层是通的。最简单方案方案可以选flannel。目前flannel发展到现在，已经支持vxlan模式下启用DR网络了，通俗讲，就是同一子网下，走hostgw，宿主机充当软路由，性能接近裸网，垮子网的情况走vxlan。即兼顾了性能，又考虑了可扩展性。另外flannel目前也重点优化了大规模容器云的路由表或arp占用过多问题，做到了：每扩展一个主机只增加一个路由项、一个fdb项、一个arp项。
4. 如果考虑容器网络隔离和安全策略的话(其实没必要，网络隔离，可以从项目级别来设置调度策略做到物理隔离)，可以考虑Canal网络方案，他是calico和flannel的结合体。
@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 穿越方式较好。
@Steven99 软件架构设计师：
容器网络选择我个人觉得不是重点，其实不管哪种网络，都应该对终端用户透明，所以不应该纠结于网络模型。
需要考虑的重点可能是安全性，稳定性，易用性等，我们使用calico网络，发现也是很多问题，在考虑替换。开源产品总是需要很多额外的工作，测试验证，逐步优化，不实际使用，很难说哪种更合适，在使用过程中可能会逐步清晰自己的需求。
容器安全，容器网络安全可能是重点，特别上生产业务，服务数量达到一定量后，会有很多想不到的问题，当然，不实际做过，也很难选择，所以可以尝试先用起来，经常使用会逐步清晰明白自己要什么。
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集群，底层网络和基础设施应该如何部署才能实现故障隔离？应用如何在多个集群之间实现故障转移？
@某银行 技术经理：