容器云经常询问的常见问题

有不少的朋友希望写一些有关容器云平台实际建设使用过程中的具体问题，作为开发人员，这是基本思维，不过要作为架构师，关注的就不应该只是技术细节，更要在平台建设全局上考虑。今天我们讨论几个有关容器云建设实践的典型问题，希望对大家有帮助。

一、 容器云的定位：

要建设容器云，首先要考虑清楚为什么要建设容器云，建设容器云用来做什么，或者说它能做什么，容器云在云计算中又承担什么样的职责，跟各种主流技术又有什么样的关系等等。把这些问题考虑清楚了，也就知道该不该建设容器云，建设什么样的容器云。我们技术人员最忌讳的就是人云亦云、邯郸学步、东施效颦。无论我们是否有机会有平台把自己的想法说出来，坚持自己的想法，不断验证并完善自己的想法，深入土壤，总会长成参天大树的。容器云平台说到底只是工具，最终还是要服务于企业业务应用的。再好的技术也只是工具，所以容器技术再牛，在容器云平台中它也不是核心。那些把“容器”二字非要显示在容器云平台的人，明显是不知道该干什么的。容器云平台是来承载应用的，所以应用管理才是容器云平台的核心，所有的能力都是围绕应用管理来建设的。不管容器云平台的资源管理，容器云平台的多租户隔离机制，以及容器云平台的安全、监控、日志等组件，都要围绕应用管理来建设的，所有平台核心不是“容器”，是“应用”。所以容器云厂商要避免闭门造车，开发人员避免当初生牛犊无知无畏了。而用户需要考虑的是建设容器云是为了实现什么能力。现在已经过了容器技术概念验证的阶段，容器云平台需要产品化，不是几项功能的堆砌就可以上生产用的。容器云平台是工具，客户要用它来管理应用，为应用提供资源，为应用提供全生命周期运营管理的支撑工具。
容器云只是PaaS平台的一种实现方式，我们更多的说是一种轻量化实现。一些功能并不适合在容器云平台上去实现。对于那些笨重的资源占用量大的无法利用容器技术特性的应用，不建议在容器云上去做，无论是迁移还是新建。
至于说容器云平台产生的数据，那就交给数据平台或大数据平台进行分析和处理。大数据应用可以部署于容器云平台；容器云平台提供基础设施资源，来支撑业务应用，这些应用包括大数据应用。大数据应用的数据来源于大数据平台。容器云平台和应用等产生的数据又可以存储于大数据平台，用于分析、统计、数据挖掘等。

二、 持续集成和容器云平台的关系：

CI/CD与容器云平台的关系在我们以前的文章中也讨论过多次，不过到目前为止，仍有许多的容器云厂商没有转过弯来。 首先来考虑一个问题，你是否会把持续集成的代码、编译、打包的过程部署于生产环境？为什么？
如果真正懂IT治理过程的话，10个人有9个半是不会这么做的，这也是我们接触容器云平台这么久来让我们觉得不可思议的地方。你说容器技术调研、PoC验证可以这么做，生产还这么做？上生产还能拿小孩子过家家的玩艺儿去部署？是不是不可思议？目前大部分容器云产品至多算是个玩具，至多是PoC概念验证的工具，完全不具备生产部署的要求。这也是我们为什么一再强调要把CI持续集成从容器云平台资源和应用管理分离出来，成为独立的一个模块或产品，实现标准化镜像输出能力的原因。
想想阿里为什么有个云效平台，想想IBM为什么推出的是基于容器技术的微服务管理平台，特别传统行业，谁会傻到在生产环境上去开发、编译、测试？不过还真别说，目前看到的容器云产品基本上都是傻傻的分不清。所以这也是我们重点提出来讨论的原因。
持续集成流程终点应该是镜像仓库，持续集成只服务于开发测试阶段，是不需要在生产环境中体现的。持续集成需要做的是实现自动化的源码检查、编译、单元测试、镜像打包、镜像上传、镜像安全扫描等能力。最重要的是不要让用户自己再写docker file等，需要通过提示客户输入或选择实现自动化的docker file生成。减少终端客户的学习成本。
既然这样，那持续集成或pipeline工具就应该单独拿出来作为独立的产品或组件，提供持续集成服务。就像jenkins那样，配置一下jdk、maven、Git or SVN等工具，实现自动化的docker file生成（选择基础镜像，添加需要的文件等到基础镜像，设置端口影射等，自动生成docker file），连接到镜像仓库，上传镜像，完成这些步骤后在镜像仓库就可以看到新的镜像。这样对用户来说很友好。至于说是用jenkins或者自定义的pipeline，都没什么关系。作为用户我关注的是结果——镜像，中间过程可以是透明的（除了需要选择基础镜像，选择上传文件等UI交互操作）。

三、 镜像仓库及镜像管理

镜像通常包含我们打包的应用。但也有中间件镜像，比如Kafka、MySQL等，这些中间件镜像应该由谁来维护？租户还是容器云平台？我们说容器云平台是用来支撑业务应用的，那么租户关注的应该是业务应用镜像。中间件镜像就应该由容器云平台来提供。镜像就可能分为平台镜像和租户镜像，那么镜像仓库就需要区分平台镜像仓库和租户镜像仓库。平台支持多租户，租户的镜像仓库可能有很多个，甚至每个租户都有多个镜像仓库。平台镜像仓库中提供的镜像是面向所有租户的，每个租户都可以使用平台镜像仓库中的所有镜像，因此可以成为公共镜像仓库， 每个租户的镜像仓库可以看作是私有镜像仓库，所以对一个租户来说，有来自公共镜像库的公共镜像和来自自有的私有镜像可以用。
租户是否可以有自己的中间件镜像？当然可以，公共镜像库没有的镜像，租户需要自己来构建。但对于企业私有云来说，建议由容器云平台来维护公用的镜像，这也是规范化、标准化的要求。
还有个问题是不同镜像库之间镜像同步的问题。比如从测试库到生产库。测试和生产通常网络是隔离的，不通的，当然可以通过双网卡配置网络使两个网段相通，或者单向通信。也可以通过中转机。但有个前提是，只有经过镜像安全检查的镜像才可以同步到生产镜像库。
还有就是镜像版本控制，特别是开发测试环境，持续集成可能产生众多版本的镜像，我们团队几天时间就发了好几百个，时间长了这个数会成为一个问题，因此需要考虑限制可用镜像版本，比如只保留最近的10版本，其他的版本都删除。或者可以选择保留的milestone里程碑的版本。

四、 多租户

不得不再提这个问题。虽然都声称支持多租户，但是国内私有云厂商还真没有把多租户做的比较好的。一个admin干了所有角色的工作。多简单啊！是啊，好简单，也好幼稚！云平台多租户机制实现租户之间的隔离，即便是私有容器云平台，也是要实现多租户隔离的。也可能面临这部门之间资源使用的计量计费，也可能面临着业务监管的硬性隔离要求。所以只要是云计算平台，就要考虑多租户机制，考虑租户隔离需求。
多租户除了资源隔离需求，也要求有完善的权限管理体系。容器云平台管理员其实就是一个特殊的租户，它关注的是资源管理；租户关注的是业务应用管理。整个平台的权限体系是统一的。我们在《容器云权限中心设计》一文中有过讨论，基于角色的权限管理体系，支持任意组织架构/用户/角色的定义。

五、 平台设置

这是我们在容器云平台首次提出的问题，各厂商基本上也没考虑到。容器云做产品化，在安装初始化时可能需要做一些初始设置。平台在日常运行过程中，也可能需要调整某些平台组件参数，更新设置，比如更新平台页面logo。或者菜单项中某项名称有歧义，需要更改；或者需要设置不可见……容器云平台需要提供一个接口来更改这些配置。这些可以统一放置于平台设置中来实现。
虽然目前通过命令行可以做，但非常不友好，也容易出错。严重的失误可能导致巨大的损失，因此该屏蔽的功能需要屏蔽掉，只提供可以操作的功能项，禁止直接终端访问容器集群节点等。不只是界面友好性的要求，更是安全的要求。

六、 微服务和API管理

我们说了，容器云平台是用来承载业务应用的。容器的特性非常适合微服务化的应用。但是有个问题是，微服务组件可能有很多个服务实例，对外需要提供统一的接口API。那可能就需要考虑负载均衡，是客户端负载均衡还是服务端负载均衡？容器的弹性伸缩、可迁移性使之在客户端实现不是一个好办法。另外，每个实例都需要在注册中心注册吗？再说，容器内的服务注册到注册中心使用的是容器地址，是内部地址，容器云平台外部的服务是无法访问的。况且弹性伸缩的时候，容器迁移的时候会带来延迟，这可能会导致超时等问题。
目前不管采用SpringCloud或其他，都不足以满足微服务在容器云平台直接部署和方便管理的要求。要支撑微服务，一个重要的组件是API网关。其通常需要提供API网关能力、API管理能力，Open API Portal并不是必须的。
所有非业务功能都可以考虑在网关层实现，比如授权认证、访问控制、负载均衡、服务编排、路由转换、限流限额、过滤熔断等。但要设置这些能力，是需要提供API管理能力的。
API网关提供了统一的接口服务和负载均衡等能力，那么在容器云平台就不需要每个实例都再注册到注册中心，所有的服务对外有唯一的接口API，在容器云平台内部可以充分利用容器技术的特性。
如果要采用微服务架构，一定需要关注API网关这个组件。商用的产品虽然贵，但功能强大，适合传统的企业采用。

七、 应用管理

应该管理是容器云平台的核心，不管是中间件应用，实际的业务应用，或者提供软件服务的应用等（应用提供“服务”， 基础设施服务、平台服务、软件服务中的“服务”和业务应用下的“服务”或“服务实例”虽然都称为“服务”，内涵有点不同），平台提供应用托管、应用运维、甚至应用开发的能力。目前更多的话是关注应用运维，很多时候我们可以称之为“微服务平台”。当然在容器云平台提供的中间件服务等，也涉及应用开发的能力，提供类似Github、SVN的能力，加上运维管理，就是应用托管的能力。
我们建设容器云平台不是为了管理容器，而是为了业务应用，来支撑公司业务。因此在容器云平台我们是不需要看到“容器”的，我们看到的是应用、服务、服务实例，没有“容器”什么事（至少表面上）。所以容器云平台需要围绕应用全生命周期的管理来设计实现并支持这些需求。也这是下面服务治理的要求。

八、 服务治理

很多公司都在做微服务治理平台，不管用gRPC或是Istio等，个人觉得完全没有必要单独实现一个微服务治理平台，完全可以基于容器云平台+商用API 管理工具（通常包含API 网关、API管理、API Portal甚至API 开发工具等）足矣。这也是我们强调容器云平台要以应用管理为核心的一个原因。治理，可以作为管理的一个方面。采用容器云平台就要考虑充分利用容器技术的特性，采用微服务架构也要考虑微服务的特性，把两者结合起来充分利用其优点避免其缺点，而不是分开考虑，是我们把微服务部署于容器云平台时需要面对的课题。
API网关你可以看作是一个服务网关，在服务网关可以实现大部分非业务逻辑的治理能力，比如路由、限流、转换、过滤、负载均衡、访问控制、授权认证，甚至服务编排、统计计费、注册发现、日志监控等，结合容器云平台提供的权限、资源管理、应用管理、租户机制等可以实现服务治理的能力。这样就简化了服务管理、服务治理的功能，成本也相对较小。我们一直的观点就是尽可能选择成熟的产品和方案，没必要自己都趟一遍坑。

九、 容器内外部服务访问

这应该算是服务治理的内容，不过我们觉得应该是个典型问题，因此提出来一起讨论。服务部署于容器，注册时用的是容器的地址。容器外的服务如果访问注册中心，获取到的服务地址也是这个容器地址，是无法解析的，况且容器地址可能会迁移，这就比较麻烦了。厂商提出要把外部的服务主机加入到容器网络，虽然可以解决问题，但不是一个好方法。前面我们提到API Gateway，它可以做这个事情。
如果用容器云，在服务部署时，不要自动注册，容器内的访问使用容器的service机制，容器外的访问通过API网关，在API网关层实现服务注册、路由、负载均衡等。其实在容器内也有一层可以实现负载均衡，服务实例级别的。具体怎么实现，根据具体的业务需求来确定。弹性伸缩需求的，最好在容器层实现，就不需要在容器外考虑负载均衡等机制。
这样其实是分两个层次来考虑。API网关可以容器化也可以非容器化，我们基于部署、扩展等要求建议是非容器化。为什么这么考虑？一是租户隔离需求，租户之间的访问要经过API网关，即便是一个公司内部，也要考虑建立明确的应用隔离机制。二是封装技术细节，简化开发要求。开发人员在实现服务或微服务时，不需要考虑服务注册、负载均衡、熔断等机制的实现，只关注于业务逻辑的实现，关注于容器多实例分布式访问需求。这样就简化了，那些非业务逻辑的功能都交给API网关去做。
当然容器内部的访问使用容器平台提供的Service方式。可以实现内部的服务域名访问。

十、 结语

我们在实施过程中遇到了很多问题，大家关注的比较多的可能就是这些细节的实现方案，我们也会逐步整理供大家参考，以期共同学习，大家在后期的实践中能少走弯路。