1、对传统企业来说，容器云改造方式比较复杂。针对原有网络方面的改造，需要注意的问题主要有哪些？

@caikai：

大体上来说，容器网络的改造，取决于您的运行场景对网络的需求。网络选择有几类：

- 如果是隔离的容器网络环境，不与生产和测试环境网络连通，只做开发测试，技术验证等，性能不敏感，那么overlay方式，甚至原生的NAT就可以考虑。

- 如果是单独的容器网络环境，对性能有要求，不想因为overlay而浪费MTU，又需要对外提供基于容器的服务，那么路由方式可能是选择；对外提供服务可以配置面向外部的4/7层负载均衡。

- 如果要求容器网络和外部统一管理，要求统一的IP地址规划、统一的路由、防火墙、漏洞扫描、SDN能力等，需要对容器集群的网络方案进行深入定制，自己实现CNI/CNM接口，把容器的启动停止过程，比如容器的子网和IP分配等网络相关动作，和外部网络管理关联起来，让外部感知容器的变化，做到自动地配置到容器的路由等。

@shendb：

就谈几个必须要考虑的点供参考。

1、对生产网络压力的评估及安全控制。容器在规模化使用后在镜像分发等场景下会有较大的网络带宽消耗这个是需要考虑到的。

2、网络安全策略回顾。如master与slave间的网络安全策略，是一个大的平台还是各区域分别建设再进行整个，这个和安全控制策略有较大关系。

3、负载均衡策略。是用集中式的还是分布的，是作为基础网络服务能力提供还是作为平台服务能力提供。dns也面临类似情况。

网络方面问题往往容易被忽略，处理不好将给容器平台带来非常大的风险。


2、传统应用迁移到容器云会遇到哪些坑？如何事先规避？

@聂奎甲：

1.评估应用上云的必要性，可行性和风险，综合决定是否上云及哪些部分上云。

2.选择非核心,无状态，前端应用先做试点，等迁移成功稳定后再逐步推广。

@caikai：

如果应用不做任何改造迁移到容器，或者说把容器当虚机用，基本和传统区别不大。但如果应用做了微服务化改造，需要面对很多可能的新问题，这里只大致罗列：

- 服务效率问题：解决的选项可以考虑微服务网关做服务聚合、亲和性调度、缓存机制、断路器、异步调用

- 高可用性问题：解决的选项可以考虑实例自动恢复、服务限流、服务降级、弹性扩容、负载均衡

- 数据一致性及事务性问题：跨微服务的事务性和强一致性处理代价非常高，尽量避免把这样的场景切分到不同的微服务，就是说要尽量避免跨微服务处理事务性，对于没有事务性一致性要求的，或者可以接受最终一致性的任务，才考虑微服务划分

- 安全问题：服务间跨网络的API调用，可能要考虑API需要有鉴权、传输加密、API限速、API设计上考虑避免泄露敏感信息等，另外以容器方式运行，还可能要限制特权模式的权限

- 运维复杂度问题：可以考虑多个方面改进监控系统，包括但不限于日志集中收集、选择适合微服务的监控粒度、微服务设计配合监控的接口提供业务指标、滚动升级和回滚等。


3、应用从IaaS到容器平台迁移时需要做哪些改造？

@聂奎甲：

一个应用开发到上线到你的平台首先有一个过程，容器化。如果是一个新的程序，非常好，直接可以按容器的方式来做。写编排文件就可以直接了。如果是老应用，要先有容器化的过程。这个过程大致可以分为拆分、改造、合并三个阶段。

@caikai： 

基本上有几个方面都会涉及：

1.应用改造：涉及适合场景的梳理，以及应用状态持久化，或更进一步的微服务架构拆分改造。

2.架构优化和运维：这个涉及的复杂问题很多，要应对服务效率降低（例如用服务网关聚合一组API，亲和性调度、断路器、异步调用等）、高可用性要求（例如服务限流、服务降级、弹性扩容、负载均衡、故障恢复、滚动升级和回滚）、分布式系统数据一致性（包括强一致性和最终一致性的分别处理）、分布式系统安全性（统一身份验证、传输加密、API鉴权、API限速、租户隔离）、监控系统改造（日志收集、集中告警灯）。

3.流程改造：CI/CD流水线工具、全生命周期管理的流程、推行类似SRE等的DevOps理念。

4.团队组织：提倡按照业务服务边界而不是技术职能的团队组织和KPI设置等。


4、容器云平台如何对接IaaS平台？

@caikai：

这部分对接通常要涉及的几个方面：

- 对接底层IaaS资源池，遵从云计算资源的统一管理和分配

- 对接或改造容器平台的网络，以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对现有网络管理模式的冲击

- 对接统一身份验证、和整个云平台其它系统采用统一的租户定义、角色定义、资源配额定义等

- 对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统

此外，考虑到对应用的统一规范管理，容器平台可能还需要对接已有的应用发布体系、持续集成系统、应用建模规范、高可用管理策略（例如同城双活的部署、灾备切换方案）

@bryan：

补充一点，由于IaaS平台主要为PaaS提供操作系统资源，这些资源包含存储、网络、计算资源等，在设计的时候要考虑资源的抽象化和统一化，将多种不同的硬件资源都可以抽象成统一的接口和概念，尽量提供统一的接口，对PaaS屏蔽异构资源的差异性，视作从资源池动态调度资源即可。


5、PaaS带来的一些管理问题？

Paas平台的资源管理，防火墙；容器弹性伸缩等问题；以及实ip带来的管理和跟踪问题；此外还想了解镜像和版本如何做好管理？

@caikai：

资源管理可以选择事先划分好宿主机、存储等资源给paas平台使用，这样做比较简单，没有多少和底层资源池或IaaS对接的要求；如果要求资源动态申请，就需要PaaS和IaaS的对接了。

网络如何管理是比较复杂的，也直接影响到防火墙、IP的管理。在这次交流的其它问题里有专门关于网络的，建议参考。

弹性伸缩，目前比较简单的能做到的是基于资源使用情况的弹性，但这样的弹性往往不充分，或者不准确。如果要做到基于业务的弹性，那么理想的情况需要应用配合改造吐出业务状态信息才行，要么提供接口，要么通过日志等。个人觉得目前比较实用、代价比较低的弹性是基于时间表的弹性，因为大多数需要弹性的场景，其实是可预测的，要么有比较固定的时间段，要么就是在某个活动开始前的一段时间。


6、如何实现容器云平台和现有网络的扁平化？

@caikai：

回答前，先假设问题中的“网络扁平化”，是指容器网络和容器平台之外的网络融为一体，不仅可以直接路由互通，还可以完全利用到外部网络已有的各类网络服务能力、SDN能力。

要实现以上目的，在设计容器网络时，需要考虑整个容器网络具备和容器平台以外，例如IaaS的VM有相同的网络层级、IP地址规划、子网划分规则，IP地址分配、根据容器的生灭动态配置防火墙策略、路由策略等。具体的做法变化比较多样，基本上都需要修改已有容器平台的容器网络接口实现，即CNI或CNM的实现。

文章《容器云平台建设的需求分析与关键设计》中举了一个例子，对接了IAAS的Neutron+SDN进行统一网络管理，工作原理是：

- 当容器平台需要为新的租户分配网络资源时，通知Neutron，由Neutron对接的SDN控制器按照预先定义的规则为容器平台分配所需的子网和网络地址空间

- 开发网络驱动，实现CNI接口。当容器平台创建新的容器实例时，网络驱动调用Neutron接口创建port，为容器实例在子网中分配MAC和IP，并把IP绑定到容器网卡（类似nova-compute的工作），然后通知Neutron容器IP配置成功

- 容器平台记录容器的IP地址，作为进行服务注册、服务发现、监控服务的基础

- Neutron和SDN联动，完成为容器实例设置相关的路由策略、防火墙策略等