容器、容器云和容器化PaaS平台之间到底是什么关系？

本文分享自天翼云开发者社区《容器、容器云和容器化PaaS平台之间到底是什么关系？》，作者：s****n
不停都有很多人迷惑于容器应该属于 IaaS 或是 PaaS 层，也搞不清晰容器云到底是该归到那边，该由哪个团队来建设、哪个团队来维护。K8s 是不是就等同于容器云？以是我们看到概念和定义的杂乱，在实施容器云的时候也会有浩繁的分歧，无所适从。目前又有浩繁的公司推出容器化 PaaS 的概念，更搞不清晰谁是谁了。那么容器、容器云、容器化 PaaS 以及与 Docker 、 Kubernetes 之间是个什么样的关系？这是需要我们明确并明白的问题。 

容器是一种操作体系级虚拟化技能， Docker 是一种容器引擎。使用 Docker 来运行操作容器。但从容器自身来说，其提供的是 IaaS 层本领。Kubernetes 提供了容器调度和管理的本领，加上云盘算租户功能，实现容器云平台功能。而基于容器技能所构建的应用开发、应用托管和应用运维平台则可以称为容器化 PaaS 平台，它是一种轻量化 PaaS 实现。联合日志、监控、认证、权限等底子本领则可以构建企业级的平台和可复用服务，采用微服务架构实现企业技能服务中台本领，支持企业业务敏捷研发和模式转型。
一、 容器
容器是一种轻量虚拟化技能，它不同于 VMware 虚拟化，以是其隔离性相对差、安全性差，但轻量也正是其特点。容器的概念实在也早就有之，只不过实践的选择有差异。早在 2006 年的时候，我其时所在的公司就提出了基于 java 的多 jvm Containers 概念并进行了产品实践，一个 java 容器可以运行多个 jvm ，不过因为 java 自身特性导致的厥后转型并不成功，最后不得不放弃了。应用层容器和操作体系级容器的实现照旧有很大差异。操作体系级的容器设计明显更公道，更易于实现和推广。
通过标准化镜像封装，从而实现了环境划一性。 容器为了弹性伸缩本领倾向于无状态应用，这样简化了容器设计实现的复杂性。以是基于容器自身的特点，容器实用的场景并不是无限的。固然 kubernetes 从 1.9 版本正式支持有状态应用，增强了容器的场景适应本领，扩展了实用场景。 经常有人拿容器和虚拟机比较，虽然都是虚拟化，但二者差异照旧很大的。虚拟机就好比是一个完备的人，而容器类似于妈妈肚子里的胎儿。它需要依赖于母体来生存，以是我们可以看到容器在操作体系中以进程的方式运行。容器的虚拟化损耗约 1% ， 而虚拟机的损耗约 20% 左右。但是容器带来了管理和运维的复杂性。Docker 提供了 CLI 和 REST API 方式，都需要很高学习成本，在达到一定数量的容器后用 CLI 来管理和运维将会是噩梦，以是有 Docker Swarm 、 Mesos 、 Kubernetes 等容器调度管理框架的出现，提升管理和运维服从，降低运维难度和工作量。
既然容器也是操作体系级的虚拟化，其可以看作类似于虚拟机的对象，容器自己提供的服务依然是底子办法资源服务，以是容器应该是处于 IaaS 层。而基于容器技能和容器调度管理技能如 kubernetes 实现的容器云平台则封装了容器操作，提供平台本领，以是容器云平台应该属于 PaaS 层。这也是很多人直接把容器云平台称为 PaaS 平台的原因吧。不过确切的说，容器云平台并非真的 PaaS 。目前很多容器云平台所提供的本领无法满意应用开发、应用托管、应用运维的 PaaS 平台本领要求，而通常仅仅实现租户 + 云端的容器调度管理本领，依然有大量的 CLI 运维工作。对使用容器云的人员的学习成本和要求都比较高。
二、 容器云
Kubernetes 并不等于容器云， kubernets 只是一种容器调度管理框架，和 docker swarm 、 mesos 等一样，用于调度、管理容器。比如调度容器到匹配的资源上，管理容器的弹性伸缩、灰度发布、负载路由等。云盘算很重要的一个概念是租户。租户租用共享的云盘算资源，按需和用量计费，不消则不产生费用。而 kubernetes 中是没有租户的概念的。以是仅有 kubernetes 是不够的， kubernetes 可以看作是容器云平台的内核，我们需要使用 kubernetes 来实现容器云平台，但还需要基于 kubernetes 进行封装，支持租户共享底子办法资源等本领。
租户可以是一个跨平台的概念。在容器云平台建设中，有容器云平台的租户设计是基于 kubernetes 的 namespaces 来划分的，一个租户使用一个 namespaces ，这会带来很大的局限性。虽然租户的定义没有明确标准，但从理论上说租户是高于 kubernetes 的，以是在 kubernetes 内部没有租户的概念，而是用 namespaces 来实现资源隔离。在容器云平台实践中，需要考虑租户的设计，大概是跨越多个 kubernetes 集群的，甚至跨越多个 IaaS 平台用 kubernetes 实现容器调度，也就是可以把容器调度到不同的云平台上运行，比如同时可以把容器调度到腾讯云、华为云、 AWS 云等云平台上（通过云管来实现资源的统一管控，支持容器云平台的资源调度），从而实现高等级备份和容灾等。这就需要考虑基于 Kubernetes 多集群之上的容器云平台本领的抽象和设计。 容器实用于轻量、弹性、无状态等业务场景，这也决定了在传统行业其应用场景并不广阔。传统行业业务追求稳定性，并不需要频繁的变更和重启。重启大概会带来数据的丢失，也大概造成业务流量处理的波动。
另外需要认识到，生产环境和测试环境的要求是不一样的。测试环境可以敏捷的迭代测试、快速的环境准备、频繁的部署删除，但生产环境往往要求持续稳定的运行。以是容器更多的适合测试环境，以更快的构建测试环境，确保回归测试环境划一性，更快更频繁的构建、发布、部署、测试、反馈，从而提升服从，减少出错频率。这也是我们公司各个团队都乐意转到容器云平台的一个原因。生产环境则要求稳定，应用服务部署之后，不需要频繁的启停，也很少频繁的弹性伸缩，往往需要提前规划好体系容量需求，确保安稳和稳定。
一种技能解决不了所有问题。容器不是万能，它有适合的场景。我们不能削足适履，而是要明白容器的特点，选择符合的业务场景。企业内需要不同技能的组合来满意企业业务需求，而容器适合支持轻量、弹性、无状态业务应用。以是测试环境我尽可以把 kafka 、 Mysql 、 ES 等快速部署起来用于测试，但这些组件在生产环境就需要物理化部署，而不是容器化部署。测试和生产在性能、稳定性、服从等方面的要求是不一样的，以是不同的场景需要考虑不同的方式。
也有很多人鼓吹容器节流资源，这只是相对的。每个容器都是一个完备的业务应用及依赖包组合，依赖的文件越多，部署容器越多，重复的资源占用就越多。浪费就越多，反而比如一台服务器上直接起若干服务。而且大量的容器假如调度不公道往往会导致资源争抢的出现，应用性能不时受到影响。什么时候容器云会节流资源？在达到一定量后，中大规模应用之后，可以实现资源的分时段使用，比如白天做业务处理，晚上做数据分析、盘算、整合、统计等，相称于使资源分片，但这取决于业务的运行资源和时段要求以及容器量，只有达到一定量之后才气更好的规划和分时利用资源，从而达到“节流资源”的目的。但这些对容器云平台的容器调度本领提出了非常高的要求。
三、 容器化PaaS
容器云可以看作是容器化 PaaS 的一个雏形，但并不能真正称为 PaaS 。PaaS 平台类似于操作体系（云操作体系），提供应用开发、托管、运维等本领。特别对传统行业人员来说，需要具备友爱的 UI ，使用户可以或许不需要额外学习就可以方便的使用 PaaS 平台来完成应用开发、托管和运维需求。
容器云或容器化 PaaS 平台属于底子平台，理论上应该由运维团队来搭建。但采用容器云之后， PaaS 运维团队是有别于传统的运维团队，而应该是一种开发型运维团队，重点是运维平台建设、运维工具开发以及稳态业务应用运维。而运维可以分 2-3 个条理：底子办法资源运维、平台和工具运维、业务应用运维。开发团队则专注于业务应用的开发和迭代，业务团队则专注于业务的运营和创新。PaaS 平台则起到一个承上启下的作用，向下使用底子办法资源，向上则支持业务应用的开发、运维和运营等。这有点类似于 Google SRE ，这也是企业数字化转型 IT 组织转型的重要方面。
容器化 PaaS 平台可以更好的利用容器的特点支持微服务化业务应用。以是我们在建设容器云平台时就提出了“以应用管理为核心”，支持微服务化业务应用，这就需要在容器云平台具备服务治理本领。服务治理不是指 SpringCloud ，也不是 dubbo ，微服务开发框架和微服务治理是两个概念。在容器云平台或容器化 PaaS 平台，可以不消 SpringCloud ，不消 dubbo ，同样可以开发微服务，反而会简化微服务的管理和治理。比如说服务注册，使用 SpringCloud 可以要使用 Eureka ，就需要额外的 Eureka 组件，而容器云平台自身是提供服务注册发现机制的，以是没必要非要选择 SpringCloud 等工具。但是这就对容器云平台或容器化 PaaS 提出了比较高的要求，要能实现不同范例微服务的管理和治理。
明白了这一点，在设计实现容器化 PaaS 平台的时候，就不会只考虑 SpringCloud 或 Dubbo ，就可以设计出更通用的 PaaS 平台。 我们把容器化 PaaS 定义为轻量化 PaaS 。所谓轻量化 PaaS ，就是让它来支持微服务架构业务应用，而不去部署如生产数据库、 Kafka 、 ES 等重型数据库或中间件体系，因为它无论在稳定性、可靠性、性能等方面都不如非容器化部署，运维复杂度高。因此，使用容器云或容器化 PaaS 来支持微服务架构业务应用，实现敏捷的业务应用服务开发和迭代，快速构建划一性的开发、测试环境，支持弹性伸缩应对突发流量，扩展服务治理增强安全管控，提供统一的日志、监控、审计等企业级本领中央等，从而就可以基于容器化 PaaS 构建企业的可复用中台服务，从而满意企业业务应用的敏捷变化需求和业务模式转型，促进企业数字化转型。 也不少人在提敏态和稳态双态运维，我们以为核心不是新的运维模式和传统运维模式并行，而是不同的业务场景需求。任何时候都存在敏态和稳态的需求，假如把数据库都容器化部署，这不是敏态，而是自找麻烦。我们前面提到， PoC 和测试环境可以这么干，但生产环境就是不一样的场景需求。无论互联网类业务大概传统业务，生产环境的稳定性都是首要要求。
容器、容器云、容器化 PaaS 对使用者有不同的要求。容器云产品化需要向容器化 PaaS 平台转型，并需要考虑不同业务场景的需求，以更好的实现应用开发、托管和运维本领需求。这也是实现 PaaS 平台的一个相对便捷的途径。
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。