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设计上考虑避免泄露敏感信息等，另外以容器方式运行，还可能要限制特权模式的权限

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

@wykkx：

这个问题很难用一两句话说清楚。应用上云不是一个动作，而是一整套工程，可以参考《 企业应用上云如何规划及落地》

3、如何实现容器云平台上的多租户隔离？

@caikai ：

网络拓扑规划时，建议把不同租户的容器运行在各自不同的虚拟网络VLAN中，并为不同的VLAN设置必须的防火墙规则、关闭相关的路由来保证不同租户的业务在网络上隔离。

建议容器平台为不同的租户分配各自专属的、不同的资源池，租户只能在属于自己的宿主机上运行自己的容器应用。这虽然导致了资源利用率的降低，但在根本上回避了容器运行依赖共享宿主机内核、隔离性天生不如虚拟机的局限，这和主要基于虚拟机的IaaS平台对多租户隔离的做法不同。

@wykkx：

本质上都通过vlan进行划分的。

4、PAAS带来的一些管理问题？

我们使用的是Ubuntu 16.04 server+ harborv1.4+rancher server+docker17，我们想了解下如何做好？

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

@聂奎甲：

目前Kubernetes支持CPU、Memory伸缩策略，但CPU和Memory很多场景并不适合。CPU和Memory的使用情况有时并不能真实反映实际业务的运行情况，而且用他们来扩展、收缩容器也显得武断，很可能导致没有完成的业务请求的容器被回收。.

@caikai：

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

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

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

5、应用从iaas到容器平台迁移时需要注意的事项和需要做的改造？

@聂奎甲：

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

@caikai： 

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

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

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

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

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

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联动，完成为容器实例设置相关的路由策略、防火墙策略等

7、容器云平台如何对接iaas平台？

@caikai：

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

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

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

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

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

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

@bryan：

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

8、哪种微服务技术更合适和容器技术结合在一起？例如 Spring boot or Dubbo？

@bryan：

按照经典分层，云计算分为IaaS、PaaS和SaaS，每层关注的侧重点各不相同：

1）PaaS层主要侧重于为应用运行提供各种基础运行环境，其中包括负载均衡、高可用等功能，实现这个目标有很多种方法，比如docker、garden等多种容器技术，现在由于docker技术的发展和成熟，一般容器都默认为docker；

2）SaaS层主要侧重于将服务直接提供给消费者，比如在线版的google doc等，实现这个目标有很多种方法，也并未必须依赖PaaS，其中业界使用较多的就是用微服务实现，spring boot 和dubbo就是实现微服务的底层框架。

通过以上概念可以才看出，spring boot 和dubbo是微服务的实现框架，属于SaaS层的范畴；容器技术主要是PaaS的落地实现技术，为上层应用提供基础运行环境，属于PaaS层的范畴。由于SaaS可依赖于PaaS提供的容器运行环境，因此二者均可以与容器技术结合在一起。

如果面临技术选型问题，只是对比二者的优缺点即可，二者在某银行的生产环境上均有使用，dubbo用在与高并发交易中，spring boot用在了大数据的相关业务场景中。

@caikai： 

微服务框架大家知道的比较多的有：Spring Cloud、Dubbo、Service Mesh/istio。这里只列影响面比较大的，事实上还有不少公司有自己特有的微服务框架，例如motan，但相对小众，暂不讨论。

微服务是一种应用的架构模式，和包括容器在内的运行环境并没有必然关系。就像分布式架构的系统，可以运行在各种虚拟化平台上一样，没有谁不合适谁更合适的区别。

从这个角度说，无论哪种微服务框架，它们都是能在容器平台上运行的，没有什么本质的区别。

以上几种微服务框架各有利弊：Spring Cloud优点是社区比较大，人气高，使用人数多，缺点是只支持java，且对代码有侵入性；Dubbo是阿里主导的框架，优点是起步早，成熟，比Spring Cloud通信效率高，缺点是相比Spring Cloud人气低，主要用户在国内，阿里曾一度停止技术支持，最近应该是又恢复了支持，但已经被Spring Cloud抢走了不少用户；Service Mesh/istio的优点是技术先进，微服务间的网络通信问题完全不用关心，支持多种开发语言，没有代码侵入性，正在越来越受到关注，缺点是还不够成熟，但google和IBM主导，发展很快，可能成为下一个主导的微服务框架。

顺便提一提，以上的这些微服务框架，是很适合无状态服务的，对于有状态的服务，需要服务自身进行数据持久化和恢复的工作。如果想从框架层面需求这方面的支持，可以研究一下微软的service fabric。service fabric从框架层面不仅提供了注入注册发现、服务网关、断路器、跟踪器等服务，还提供了帮助和加速微服务开发的SDK，基于SDK实现平台框架负责的有状态服务的管理，功能强大。微软公有云Azure的部分核心，以及某些关键的服务，例如Cosmos DB等都是基于service fabric开发而来，全球每日处理的交易量非常之大，因此性能和稳定性也得到了足够的证明。之所以service fabric大家可能了解的少一些，主要是以前service fabric是微软的封闭技术，但在今年初，微软跟随开源的潮流也把service fabric完全开源了，大家可以关注一下。事实上微软已经是开源领域的重要玩家了，连续几年在github上的贡献都是最多的。