容器云平台建设需求分析
来源：护士资格 发布时间：2020-08-29 点击：
容器云平台建设需求分析
目录 1
容器云平台概述 .............................................................................................................................................................. 01
1.1
............................................................................................................................................ 容器的兴起. ................................................................................................................................................................................................................... 01
1.2
............................................................................................................................................ 容器云平台规划时需要考虑的一些问题. .............................................................................................................................................................. 01
1.3
............................................................................................................................................ 容器云面临的机遇和挑战. ............................................................................................................................................................................................................. 02 2
容器云平台建设思路 ......................................................................................................................................................................... 04 2.1 概述. ............................................................................................................................................................................................................... 04
2.2 部署. ............................................................................................................................................................................................................................ 04
2.3
网络方案. ........................................................................................................................................................................................................................... 05 2.4
存储方案. ........................................................................................................................................................................................................................... 05 2.5 总结. ............................................................................................................................................................................................................................ 06
3
以金融行业为例看容器云平台的建设要点 ........................................................................................................................................ 07 参考资料 ................................................................................................................................................................................................ 07 Ⅱ
1.1
容器的兴起 1 容器云平台概述
进入 21 世纪，社会和经济在不断进步的 IT 技术的推动下发生了巨大的变化，竞争越来越激烈，对各行业的要求也越来越高。企业必须要保持“敏捷、开放、创新”，才能在竞争中保持优势 1,2,3,4,5 。
在新经济形态下，业务和应用系统和二为一。新的业务需求如洪水一般滔滔不绝地从市场的第一线喷涌到企业的应用开发部门和系统运维部门。为了满足不断变化的业务需求，企业的信息系统的建设也在不断地变革，而且从未停步。应用系统的架构从客户端/服务器(C/S)架构，变为分布式计算(Distributed Comput- ing)架构和多层(Multi-tier)架构，应用系统从互不连通的信息孤岛，变为面向服务的架构(SOA)和微服务架构(MSA)；软件工程方法从瀑布式，变为敏捷式(Agile Method)；应用系统的部署，从物理机，变为虚拟机和基础设施即服务(IaaS) 云， 再变为平台即服务(PaaS) 云和功能即服务 (FaaS) 云 6,7,8,9,10,11,12,13 。
通过近十年云化的推进，大多数有一定规模的企业已经实现了基础设施资源的池化和云化，这里的基础设施资源指的是诸如服务器、网络、存储。用户可以用很短的时间获取业务应用运行所需的虚拟机。基础设施资源云化其实并不是目的，而是手段。最终的目标是让承载业务的应用可以更快地上线。但现实是，通过虚拟机获取的基础设施资源并不能被我们的最终业务应用直接使用。应用系统还必须进行或繁或简的部署和调试才可能运行。部署涉及到操作系统的配置的修改，编程语言运行环境的安装配置，中间件的安装配置， 数据库的安装配置，应用程序的发布和数据初始化等。部署的过程在一些企业仍然是通过手工完成，低效且容易出错。有的企业则是通过简单的自动化方式完成，提高了效率，但是满足不了后期更高级别的要求， 如，补丁更新、操作系统升级、弹性伸缩、快速更改配置、动态申请存储、动态调整应用服务之间的网络访问。即使勉强通过自动化工具帮助实现，后期随着基础设施资源和部署的应用系统的类型的增多以及复杂化，维护的难度将会以几 何级增高，无法真正做到持续集成、持续部署和开发运维一体化(DevOps) 14,34 。
基于这个背景，业界需要有一种手段来弥合业务应用和基础设施资源的这道鸿沟，让应用可以做到“一键式”便捷地云上运行。为了实现这个目标，业界出现了多种不同的轻量级虚拟化技术，即，Linux容器(LXC) 15,16 。随后，一个叫Docker的开源项目出现了。Docker通过对 Linux内核已有功能的整合，为业务应用部署提供了一个更简单的方案，其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，并推出了Docker Swarm
容器编排工具 1 7 。而后Kubernetes异军突起，通过竞争击败了Docker Swarm和 Apache Mesos，成为当前业界主流的容器编排软件，即，容器云平台的核心。Kubernetes源于Google开源的容器集群管理系统，目前属于云原生计算基金会(CNCF) 18,19 ，它通过规范的接口集成容器运行时，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容、负载均衡等整一套功能 20 。CNCF定义了一系列的规范， 孵化了众多的项目，并建设了生态系统，以补充和完善基于Kubernetes的容器云平台解决方案 21,22,23,24,25 。
1.2
容器云平台规划时需要考虑的一些问题 容器云平台是一个全栈的企业级容器应用解决方案。它为容器提供了一揽子基础设施和平台服务：CRI 兼容的容器运行时 26 、CNI 兼容的网络服务 27 、CSI 兼容的存储服务 35 、主机管理、负载均衡、防火墙、操作系统和平台软件……云端时代容器云平台让上述服务跨越公有云、私有云、虚拟机、物理机环境运行，真正实现一键式部署和应用 28 。
容器云平台采用基于VXLAN的Overlay网络方案 30 ，采用 VXLAN Overlay 网络能够简化不同网络区域主 机间的防火墙设置，容器之间通过Overlay网络通讯，防火墙只需开通主机之间的Overlay网络端口，容器内
部通讯可以通过network policy进行控制。这样对网络设备的要求降低了，无大二层的必要，消除了arp 广播风暴和网络设备不兼容的风险。
容器云平台可以部署和管理多个集群，集群可以部署在公有云、私有云、虚拟机、物理机上。此架构下多个独立集群，可独立扩展、升级，可扩展性和灵活性最佳；集群管理和计算资源完全隔离，安全性最佳； 可以进行混合云部署，平衡私有云的数据安全性和公有云的最佳经济性。
容器云平台必须提供数据中心级别的高可用性，单个数据中心故障时不影响应用系统的正常运行和使用。Kubernetes集群：每个数据中心有独立的Kubernetes集群，单个数据中心故障时，另一数据中心的集群仍可正常提供服务。用户可根据需要，将应用部署在两个数据中心以确保高可用性（需要注意的是应用系统的应用程序和数据库需要支持数据同步，将状态实时向每个数据中心同步，以保证业务数据的一致性）。容器云平台的管理平面和数据库：采用高可用(HA)的跨数据中心部署，对于光纤直连的同城数据中心，可保证主备节点之间的数据一致性。通过前端负载均衡实现单入口访问，采用灾难恢复(DR)技术保证在一个数据中心故障时自动切换到另一个数据中心。
容器云平台使用OCI兼容的镜像仓库，并实现多数据中心的高可用部署，即，每个数据中心均有高可用部署的镜像仓库，每个数据中心的镜像仓库的服务均可读可写，同时支持同步复制数据到其他数据中心，保证了高可用和镜像一致性 29,36 。
1.3
容器云面临的机遇和挑战 云计算在IT市场上的比重会越来越高。当市场上同时存在OpenStack 、 Apache Mesos 、DockerSwarm 和Kubenetes等云平台，并且存在竞争关系时，Kubernetes容器云平台的机会在哪里？从CNCF的统计数据来看，Kubernetes关注度已经超越 OpenStack，并逐渐将与CloudFoundry、DockerSwarm和ApacheMesos 的差距拉大，这至少在一定程度上说明基于Kubernetes的容器云平台是未来云计算的趋势，趋势就是机会 3 1 。从某个角度上讲，容器云可以做为IaaS/PaaS提供服务，容器云平台的流行并不意味着IaaS/PaaS的消亡，容器云平台是IaaS/PaaS在云计算道路上的进化，是企业和个人用户选择的结果，特别是企业用户，在选择第 一代IaaS/PaaS之后有几个问题是避不开的。
1．第一代IaaS/PaaS服务运维门槛相对偏高，对运维人员的要求也高，组建一个合适的云计算运维团队不容易。即使有了专门的运维岗位和运维人员，在后续的业务迭代过程中运维和开发人员之间产生的沟通成本也无法忽略。
2．对企业来说，理想情况下是建设自己的私有云，退而求其次是使用托管云服务。但是无论私有云还是托管云，它们的代价都不小。因此，对中小型企业来说，最佳选择就是按需付费的公有云平台。当然，选择公有云平台也不是没有顾虑的。一来担心公有云平台本身生命周期太短，还不及自己产品的生命周期长； 二来担心技术架构被公有云平台的技术、服务和条款所绑架 31 。
而Kubernetes容器编排技术的出现恰好解决了企业应用上云和交付的这几个痛点。
首先，容器轻量，成本低，运行效率高。容器的本质是一种操作系统级别的轻量级虚拟化，启动一个应用容器其实就是启动容器应用进程本身，这是容器技术与传统虚拟机技术的最大差别。
其次，容器镜像具有不变性。容器镜像能够将应用程序和它依赖的操作系统、类库以及运行时环境整体打包，统一交付。另外，容器镜像还可以通过Dockerf ile定义，换言之，应用程序和运行环境一起是可以被版本化分层管理的。容器镜像真正抹去了应用程序多个运行实例间的环境和依赖版本差异，同时也把对运维人员的重度依赖解耦开来。
最后，Kubernetes容器编排与平台无关，兼容性好。Kubernetes容器编排在Linux平台各发行版下是兼容的，这意味着应用架构一旦在Kubernetes上部署之后，就可以在任何云平台间无缝迁移，不会被云提供商所绑架。Kubernetes容器编排技术出现在最被需要的时候，就像那只站在风口上的猪，这就是容器云平台的机会。
虽然业界普遍看好Kubernetes容器云的前景，但是也不乏一些唱衰的观点出现。对构建一个良性的社区环境而言，正面和反面的声音同样重要 32 。
1．容器技术和容器生态仍需要持续发展
容器的出现是近几年的事情。一般来说，会把Docker技术诞生的2013年作为容器技术流行的元年。众多的Docker用户只是将其做为一个轻量级虚拟机来使用，当使用Kubernetes管理Docker时，Docker的一些固有的缺陷就暴露出来了。例如，Docker的网络和存储管理带有天然的缺陷，成为大部分生产环境实践的障碍，另外，以 root启动的Docker daemon进程引入了过多安全风险。另外，容器依赖于Linux核心，容器的问题往往需要在Linux核心解决，若遇到各家扯皮就会是个大问题。
2．用户的使用习惯仍需要培养
从我们开展的容器目标群体调研结果来看，大家对容器的使用方式和容器的正确使用方式之间存在差异。长久以来的虚拟机概念深入人心，再加上LXC容器技术的先入为主，导致用户习惯于以使用虚拟机的方式在使用容器。这也是网易蜂巢提供容器化主机的根本原因。因为我们意识到，大部分用户的容器云使用习惯在短期内难以改变，只能慢慢引导。我们也期望通过不断丰富云平台功能，可以将用户使用容器云的角度，从IaaS转变为PaaS，释放出容器真正的威力。
3．安全仍是个大问题
容器技术本身非但没有提升应用的安全性，反而在一定程度上降低了安全性。因为容器与宿主机共享操作系统内核，只要同一个宿主机上任一容器存在漏洞，或者宿主机本身存在安全漏洞，都有可能导致上面的所有容器安全性受到影响。再加上公有镜像市场中的容器镜像鱼龙混杂、恶意镜像的传播途径更是不可控的，使得单独容器对容器云平台的安全性造成很大的威胁。如何有效防止外部攻击和内部渗透把危害带给云平台和业务，也是各容器云平台厂商需要思考并且解决的。
2.1
概述 2 容器云平台建设思路
在做IaaS时，即使经过了深度的定制化自动化改造，IaaS上的流程走完时也普遍是在交付时把带有应用软件及软件配置的一台虚拟机交到申请者手中，申请者要自己通过IP登录去部署应用，更不用说各应用组件之间的配合设置。而在容器云平台里，从代码开发，到集成，到一个容器镜像里打包了应用和应用的运行时环境，加上容器的配置文件，一套完整流程走下来时，应用已经可以上线了，服务注册、负载均衡、安全策略、持久化存储、集中监控和日志等都由容器云平台提供，可以说容器云平台是DevOps理论的最佳实现。
所以，对于容器云平台的建设，从初期就需要各技术团队紧密结合，了解互相的需求，平台相关技术的原理机制，才能共同设计好一个容器云平台。
而对于传统应用的容器化改造，应用接入容器云平台一定是一个循序渐进的过程，更是一个不断演讲的过程。为了让应用尽可能平滑的接入，平台设计也应适当考虑业务原场景和使用习惯，尽可能的避免大幅度修改逻辑，不希望为了容器化而容器化，还是要因地制宜，找到一个平衡点。虽做了很多技术实践经验的调研，但真正在自己的环境中落地时，大家都是摸着石头过河，要通过试点应用，积累应用改造的经验，运维的经验。
对于容器云平台，Kubernetes已经是公认的容器编排的最佳调度平台，在2017年之前声音还没有如此的一致，记得最初做容器云平台技术调研时，还要关注Apache Mesos，Docker Swarm等，但现在无论是商业产品还是纯自研，基本都转向了Kubernetes 的阵营。
Kubernetes，2014年以Google内部用了很久的Brog为原型孵化出来贡献给开源社区的一个自动化部署、伸缩和编排容器的开源平台，其功能强大，Kubernetes实现了IP地址管理、负载均衡、服务注册发现和DNS命名，还原生提供运维人员更为关注的高可用特性及资源智能调度。Kubernetes对管理基础设施的抽象解耦比虚拟化技术更为彻底、极致，其对 CPU 兼容性、系统兼容性更为优秀；自动扩缩容、负载均衡和容器健康检查/ 重新启动应用程序等功能，也是使用IaaS时不具备的，要定制开发的功能。
同时，Kubernetes通过规范，支持符合CRI接口的容器运行时，例如，Red Hat公司的cri-o就是一个后起之秀 20 。当然构成一套容器云平台，不只是容器运行时和Kubernetes就够了，他们只是应用运行和调度的 最核心的载体，还要有一系列CI/CD 33
件，才能构成一个完整的解决方案。
2.2
部署 工具、基础镜像、安全、监控、网络、存储、中间件、数据库等组
应该部署在物理机还是虚拟机上？这是架构设计时一定会讨论的一个问题，从容器云的架构设计来看， 没有绝对的谁更好的答案，物理机或虚拟化平台均可以，前面也说到了，其核心组件Kubernetes将基础设施抽象的更为极致，所以要综合企业自身基础设施建设现状和内部制度流程等综合因素权衡。
如果之前已经有了IaaS平台建设，并且已经有成熟的运维规范和配套工具，那么就部署于IaaS之上，享受IaaS建设的红利。融入了自助服务、内部流程审批、应用软件安装等自动化流程及规范，且IaaS平台有一
些对于运维人员爱不释手的功能——热迁移、快照、HA、快速创建虚拟机等，IaaS平台在易管理性和资源
弹性上相比物理机还是有优势的。
如果没有现成的IaaS建设，那么首选物理机，没有必要再去投入人力去设计IaaS基础设施，Kubernetes 原生解耦了基础设施的依赖，提供了智能调度和高可用能力，针对物理机去定制一些满足自身的管理功能和运维的自动化手段也是理想之选，毕竟建设一套适合自身企业需求的IAAS本身也是个巨大的工程，而且少了一层虚拟化，从架构来看更为清晰简洁，故障处理时理论上的故障点也会少些，虚拟化层的性能损耗也不用考虑了。
2.3
网络方案 在容器云平台的基础设施层面，网络方案的设计一般都是涉及讨论最多，意见碰撞最多的地方，毕竟网络是底层的基础设施，牵一发动全身，所以定会格外谨慎。Underlay、Overlay、Routing的网络模型实现
都有，当然这些方案都是要符合KubernetesCNI插件标准的，主要有：Openvswitch（overlay）、Macvlan(underlay）、Flannel（overlay）、Calico（routing）、NSX-T（routing）、Cisco（硬件）、Juniper（硬件）。
对于Underlay的方案，对于传统的网络架构可以无缝适配，网络的管理模式（IP资源管理，流量管理等）也可以保持一致，但从Kubernetes的管理功能和生态圈来看，Underlay的网络方案都不是方向，更多是一种适配传统网络架构的过渡方案，对于ip的管理还是要在外部完成，而且Kubernetes也失去了对于容器的隔离控制能力，此外，例如Macvlan要求启用混杂模式的刚性要求，也不适合绝大多数企业的网络管理规范及操作系统使用现状。对于Overlay的方案，实现了传统网络和容器通讯及跨Kubernetes集群的容器通讯需求，该类型方案也存在弊端，例如，由于基于VXLAN的数据封装传输，对于容器ip的流量监控也不易实现 (除非支持解析VXLAN数据包），对于VXLAN的解封包，在性能上也会一定损失，性能表现亦不占优。对于Routing的网络模型方案，如，Calico，由于目前还不支持多播，一些传统的应用软件可能会受到很大的局限。对于硬件的解决方案，由于兼容性导致了品牌锁定，对企业现有网络设备资产的处置比较麻烦。
2.4
存储方案 存储也是基础设施的重要一环，尤其是对于有状态应用的数据持久化需求。
在Kubernetes里，对于基础资源（CPU、内存、网络、存储）的管理，存储使用的设计较为别致，使用方式有别于常见的思路，还需要认真去理解。这里简单介绍下在Kubernetes中存储设计的四个重要概念：
Volume、PV（PersistentVolume）、PVC（PersistentVolumeClaim）、Storage Class。
1．Volume
Volume是最基础的存储抽象，其支持多种类型，包括本地存储、NFS、FC以及众多的云存储，也可以 通过f l ex volume driver或CSI（Container Storage Interface编写自己的存储插件来支持特定的存储系统。
Volume可以被Pod直接使用，也可以被PV使用。普通的Volume和Pod之间是一种静态的绑定关系，在
定义Pod的同时，通过Volume属性来定义存储的类型，通过VolumeMount来定义容器内的挂载点。Volume
有一个重要属性是，它与所属的Pod具有相同的生命周期。Pod是Kubernetes的最小工作单元，每个Pod包含一个或多个容器。
2．PV
PV与普通的Volume不同，它是Kubernetes中的一个资源对象，创建一个PV相当于创建了一个存储资源对象，向用户屏蔽了具体的存储实现形式，而且这个资源的使用要通过PVC来请求。PV定义的内容包含存储的类型，存储的大小和访问模式等。PV的生命周期独立于Pod，即当使用它的Pod销毁时对PV没有影响。
3．PVC
PVC是用户对存储资源PV的请求，请求信息包含存储大小，访问模式等。根据PVC中指定的条件Kubernetes寻找系统中的 PV 资源并进行绑定。PVC消耗PV资源，PV和PVC是一一对应的。
4．StorageClass
StorageClass的引入是为了解决个性化的存储需求动态供给的问题，集群管理员可以先将存储资源定义 为不同类型的资源，比如高性能存储、常规存储等，之后通过StorageClass的定义动态的去创建PV，然后 通过PVC来请求PV绑定。
2.5
总结 容器云平台需要能够支撑目前流行的微服务架构的应用和开发运维一体化，但建设会是一个不断积累和完善的过程，同时容器云相关技术的发展变化非常快，在平台的建设中除了要持续保持对新技术的关注，还要开阔眼界，了解应用开发、运维管理、安全监管、中间件数据库等各方面的知识。
3 以金融行业为例看容器云平台的建设要点 金融企业建设容器云平台，不仅需要为基于微服务架构的新业务提供容器化运行和管控平台之外，还必须非常重视满足金融行业的监管和安全要求。这样的定位决定了在金融企业建设容器云平台除了要具备市场上大多数容器云平台产品的能力，还应该为金融企业的特殊监管需求进行定制。
因此制定金融企业容器云平台的需求时，建议考虑的方面有：
管理大规模容器集群能力，包括：提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。
为满足金融业务的监管和安全要求，平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、后台运维的4A纳管、审计日志；如果容器云平台在公网提供服务，那么还需要考虑访问链路加密、安全证书等。
还有一个重要方面是，金融企业的金融云是一个范围更大的复杂云环境，容器云平台通常是这个复杂系统中的一部分，因此容器云平台还要遵从银行已有的 IT 技术规范和运维要求，例如可能还需要考虑：
支持银行自身的应用发布体系、持续集成系统、应用建模规范、高可用管理策略对接金融云底层资源池（例如 IaaS），遵从云计算资源的统一管理和分配 对接或改造容器云平台的网络，以满足容器云平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对银行现有网络管理模式的冲击
对接统一身份验证、和整个金融云其它系统采用统一的租户定义、角色定义、资源配额定义等对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统 至于存储方面，对于多数银行业的企业，都有丰富的 SAN 和 NAS 的存储管理及运维经验，
结合应用的存储需求、平台镜像方案的设计，以及银行业的应用系统普遍有多中心部署的监管需求，采用NAS类型的存储支持容器数据持久化以及镜像服务的相关存储需求对容器平台在银行业的落地不失为一个不错的选择，此外还应同时开展对象存储的研究与测试， 以给应用对数据存储的使用方式更多选择。
参考资料
https://wiki.mbalib.com/wiki/%E5%BF%AB%E9%B1%BC%E6%B3%95%E5%88%99
https://www.hbrchina.org/2016-07- 04/4267.html
https://www.forbes.com/sites/henrychesbrough/2011/03/21/everything-you- need-to-know-about-open-innovation/#7412e83d75f4 https://www.forbes.com/sites/henrychesbrough/2011/03/21/everything-you- need-to-know-about-open-innovation/#7412e83d75f4
https://www.forbes.com/sites/adigaskell/2018/10/23/how-open-innovation-can-reduce-the-costs-of-innovation/#219301db7251 https://www.forbes.com/sites/adigaskell/2018/10/23/how-open-innovation-can-reduce-the-costs-of-innovation/#219301db7251
https://www.forbes.com/sites/stephenkey/2020/01/29/why-large-and-powerful-companies-embrace-open-innovation/#178358213295 https://www.forbes.com/sites/stephenkey/2020/01/29/why-large-and-powerful-companies-embrace-open-innovation/#178358213295
https://en.wikipedia.org/wiki/Client%E2%80%93server_model https://en.wikipedia.org/wiki/Distributed_computing https://en.wikipedia.org/wiki/Multitier_architecture
https://en.wikipedia.org/wiki/Service- oriented_architecture
https://martinfowler.com/articles/microservices.html
https://martinfowler.com/articles/microservices.html
https://devspacehttps://devspace.cloud/blog/2019/10/31/advantages-and-
disadvantages-of-
https://www.pmi.org/learning/library/agile-versus-waterfall-approach-erp- project-6300 https://www.pmi.org/learning/library/agile-versus-waterfall-approach-erp- project-6300
https://en.wikipedia.org/wiki/Cloud_computing
https://dzone.com/articles/8- devops-myths-debunked-1
https://www.redhat.com/en/blog/history-containers
https://www.cncf.io/news/2019/04/08/container-journal-cncf-formally-adopts- cri-o-runtime-for-kubernetes/
https://www.cncf.io/news/2019/04/08/container-journal-cncf-formally-adopts- cri-o-runtime-for-kubernetes/
https://www.cncf.io/blog/2017/04/26/service-mesh-critical-component-cloud-native-stack/ https://www.cncf.io/blog/2017/04/26/service-mesh-critical-component-cloud-native-stack/
https://www.cncf.io/cncf- prometheus-project-journey/
https://www.cncf.io/blog/2020/02/26/cncf-tools-overview- f l uentd-uni f i ed-logging-layer/
https://www.cncf.io/blog/2020/02/26/cncf-tools-overview- f l uentd-uni f i ed-logging-layer/
https://www.cncf.io/announcement/2019/10/31/cloud-native-computing-foundation-announces-jaeger-graduation/
https://www.cncf.io/announcement/2019/10/31/cloud-native-computing-foundation-announces-jaeger-graduation/
https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in- kubernetes/ https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in- kubernetes/
https://www.cncf.io/blog/2017/05/23/cncf-hosts-container-networking-interface-cni/ https://www.cncf.io/blog/2017/05/23/cncf-hosts-container-networking-interface-cni/
https://landscape.cncf.io/
https://quay.io/
.cloud/blog/2019/10/31/advantages-and- disadvantages-of-kubernetes
https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/
https://en.wikipedia.org/wiki/Open_Container_Initiative https://www.theregister.co.uk/2020/03/19/nasa_cloud_data_migration_mess/
https://tools.ietf.org/html/rfc7348
https://en.wikipedia.org/wiki/Apache_Mesos
https://en.wikipedia.org/wiki/Docker_(software) https://www.cncf.io/blog/2018/11/05/34097/
https://en.wikipedia.org/wiki/CI/CD
https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/
https://en.wikipedia.org/wiki/Virtualization https://en.wikipedia.org/wiki/LXC
https://en.wikipedia.org/wiki/DevOps
推荐访问:容器 需求 分析