【云驻共创】容器，容器云，云容器有什么区别？

容器

容器的基本概念

容器技术是云原生时代一切技术的基石。

根据IBM公司的定义：

Containers are executable units of software in which application code is packaged, along with its libraries and dependencies, in common ways so that it can be run anywhere, whether it be on desktop, traditional IT, or the cloud.

容器是应用代码打包后包含依赖和库的最小的可执行单元，通俗的说她可以在任何地方运行。

容器在计算形态上是一种轻量级的虚拟化技术，不同于传统虚拟化的内核级的Guest OS封装，容器服务是进程级的虚拟化形态封装，容器的启动与部署迅速，能够在应用层面根据资源需求快速的部署与调度，生命周期变化速度快。

我相信所有开发(冤种)都跟测试同事说过这么一句话：

通俗一点的说，容器 = 最精简的操作系统+执行环境+你的应用。

有了容器之后，再也不用担心你的项目在不同版本的系统下表现不一致的问题了——只要测试同事和用户在和你同一个系统版本上跑这段代码——另一个系统版本上存在的BUG就永远不会出现了。（当然编者不是很推荐这种曲线修复BUG的方式）。

容器≠docker

在网上搜索容器的时候，经常出现一堆拿docker夸夸其谈的文章。容器技术包含docker这个产品，但是容器并不等于docker。

严格的说，容器的开放标准接口 OCI （ Open Containers Initiative）出现在docker产品之后，是为了让后续出现的其他容器产品能够在接口和功能上做到一个标准统一。容器技术产品除了docker之外，还包括 runc，containerd，cri-o，podman等。

特别是后续爆发了kubernetes移除dockershim的事情，大部分厂商已经把底层的CRI实现切换到了containerd等其他产品之上。

不过对于这个事情，docker表示他是不慌的：1100万开发者、700万个应用程序和每月130亿次的镜像下载，妥妥的容器界的网红一哥。

容器云

在介绍容器云概念的时候，我想引用一下其他工程师对容器云概念的描述:

Container cloud takes container as the basic unit of resource segmentation and scheduling , Encapsulate the entire software runtime environment , For developers and system administrators to build , A platform for publishing and running distributed applications .

容器云以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建，发布和运行分布式应用的平台。

可以发现，在讲容器云这个概念的时候，它更多强调的是以容器为基本单位这件事情本身。基于容器封装的软件运行时环境，提供他的平台就是容器云平台。

因此这个平台可以是自己封装设计的基于的docker平台，也可以是根据的docker公司产品构建的swam平台，也可以是基于k8s的华为云CCE。涵盖的范围从使用技术，到公有云，私有云，混合云搭建。

为什么需要一个容器平台，我仅仅使用容器技术不就可以了吗？

答案是否定并且简单的——因为实际工作中的容器实在是太！多！了！某互联网公司联邦集群中的容器达十几万个，如果没有一个平台进行这些容器的管理和控制，那么他的运维工作量就是天文数字。（运维：生产队的驴也不能天天拉磨不休息的啊。）

在容器云技术刚出现和使用的时代，大部分的云厂商其实还没有来得及推出基于容器的云服务，因此市面上大部分还是以自己构建的自建容器云平台为主。对于容器的管理就落到了自建平台的用户身上。

当时docker公司的swam借着docker产品的余威，风头一度无二，统一容器管理天下的传言甚嚣尘上。

但最后还是输给了——CNCF的宠儿，谷歌降生，swam的克星，Borg项目的继承者，容器编排大草原上的事实标准——kubernetes!

啊对不起，图放错了

服务编排

管理容器这项工作其实是有一个更加标准的专业术语——Service orchestration 服务编排。Kubernetes、Swam、Mesos 都是业界比较好的服务编排产品，但目前市面上流传的最火的还是简称为K8S的Kubernetes。

Kubernetes给人最大的感受就是他把很多原先基于微服务的功能提升到了平台层面，笔者最先是做Java的微服务的，以前都是使用spring cloud的架构来进行服务发现，负载均衡，配置中心等工作。但是没想到强大的k8s是已经把这些功能提到了平台层，这样的话我们的业务代码项目变得极其简化，无论是开发还是部署工作，都变得比以前更容易多了。

同时在容器的管理方面，它也可以协助我们更好的管理容器。进行一些自动重新启动，健康检查等工作，极大的减轻了我们运维管理容器项目的工作量。

服务网格

写到这里，我曾一度以为容器编排的故事就到此结束了。

但是没想到，容器技术界总能整出一些让人惊叹的优秀作品。比如容器编排技术王冠上的珍珠——servicemesh服务网格技术。

严格地说，服务网格并不等于isito，这也是一个技术产品包含之间的关系。但是目前业界表现最好使用最广泛的技术就是isito。

这个技术在我理解上就是对迟迟暮年的spring cloud的技术又插上了一把刀——熔断，限流，灰度发布，金丝雀部署， Ab测试，链路追踪、等高级特性，也被isito提升到了平台层面。让我们再回顾一下上一代微服务技术的技术栈，已经被这一代容器平台技术抽离的差不多了。

对于基于微服务的Java项目来说，如果把这些功能全部抽离到平台层，那就意味着减少了约120MB以上的jar体积和10s左右的启动速度，以及更加简单的代码。

云容器

虽然从上面的文章中看到了容器技术的进步显著改变，然而它没有停歇下来的意思——轮到云服务商出场了。

在我们使用K8S等容器云的时候,非常难以避免的一个问题就是我们需要花入大量的时间和精力来自己搭建K8S，并且还要在使用的过程中处理各种繁杂的运维问题：包括但不限于网络，带宽，存储，硬件等问题。

尴尬的是大部分容器用户作为一名软件工程师，是不具备运维能力和硬件知识的。比如一些可以轻松写出HTTP客户端的人，在给自己的Linux服务器开启防火墙端口的时候，却有心无力。（没错，正是当初的在下，当然现在肯定已经好多了。狡辩）

更不要说为了写一段容器程序，还得花大量的时间和精力去学习k8s知识。当初不是说好的，只用关心业务逻辑和基础解耦吗？

因此即想要使用容器的解耦和便利，又想同时得到容器云的运维，就需要使用到华为的云容器技术了。云容器其实指的就是以华为云容器引擎CCE 和云容器实例CCI 为代表的建立在云上的容器环境。把运维工作全部交给云服务商来负责，由更加专业的人来做专业的事情，而普通的业务逻辑则由自己完成，分工明确，工作高效。完美！

既然说到了这两个技术，就必须要对他进行一些初步的讲解。

云容器引擎CCE

深入了解的话，可以参照编者另一篇专门的文章介绍 https://bbs.huaweicloud.com/blogs/349349。

这里简单的介绍一下：CCE是华为的提供的基于k8s社区版本的产品，极大的简化了K8S的环境搭建和运维成本。

另外，CCE除了K8S进行本身的功能之外，还加入了华为的asm服务网格功能：也就是大名鼎鼎的ISTIO技术为代表的servicemesh——也就是华为ASM。

云容器实例CCI

华为CCI简直就是容器界的新宠，他的光芒可以和上面的服务网格技术servicemesh不相上下——也就是大名鼎鼎的serverless！

我先说两点亮点

1. 毫秒级启动
2. 按需计费

如果说上一个容器技术是业务项目和基础设施解藕的话，那么这个技术则实现了业务代码和服务器解藕。serverless顾名思义英文字面解释就是没有服务器，但实际上服务器是存在的，只是作为开发工程师的一方完全感觉不到而已。

应用场景。

• 这个技术适用于两大场景。
• 基于事件的驱动场景。
• 需要快速伸缩，弹性扩容缩容的场景。

比如在某些人工智能等需要高密集计算的场景，这一些高密集计算并不是一直在发生，因此对于这些支持高密集计算的硬件设备来说，空闲时间就是一种资源的浪费。消除这种浪费就是成本的降低。

比如在网络购物节或者购物高峰，或者早上上班高峰等场景下。某一些服务会在这个特定时间之内承受巨大的负载。这个时候根据负载和压力动态快速的增加容量。就成了一个必须的需求。同理，当这个高峰之后又把容量缩回到正常的水平。起到节省硬件资源的作用。

华为云UCS

先看官方给的定义：

华为云分布式云原生服务（Ubiquitous Cloud Native Service, UCS）是业界首个分布式云原生产品，为企业提供云原生业务部署、管理、应用生态的全域一致性体验，让客户在使用云原生应用时，感受不到地域、跨云、流量的限制，把云原生的能力带入到企业的每一个业务场景，加速千行百业拥抱云原生。

用通俗易懂的解释，就是当你具备了上述所以强大的容器功能之后，必然会面临接下来的问题：如何管理多个K8S集群？特别是这些集群可能处在不同的可用区之上，他们之间可能已经距离超过40KM了。网络延迟，高可用，脑裂，一致性都是需要考虑的内容。而优秀的华为工程师们基于Karmada 作为技术基座，开发出了优秀的UCS产品。

这个产品整合了目前企业级的云原生部署和管理等，继续为企业的全国业务布局的技术支持做了很好的支撑。该产品当前处于公测阶段，编者作为一名华为粉，虽然有点脱离了本文的范畴，还是顺便推荐下这个产品。

总结

讲了不少的概念，这里做一个总结：容器技术是基石，容器云代表了负责容器编排的平台，而云容器则把这一切都搬到了云上，每一步都比上一步更加的高效和方便。

在文章的最后，感谢优秀的华为工程师们带给了我们这么多优秀的容器技术产品。

引用资料

https://copyfuture.com/blogs-details/20210614211646325l  container cloud

https://support.huaweicloud.com/function-cce/index.html 云容器引擎

https://support.huaweicloud.com/productdesc-asm/asm_productdesc_0001.html  应用服务网格

https://support.huaweicloud.com/productdesc-cci/cci_03_0001.html 云容器实例

https://www.ibm.com/se-en/cloud/learn/containers IBM

本文参与华为云社区【内容共创】活动第19期。

https://bbs.huaweicloud.com/blogs/370132

任务35：容器、容器云、云容器三者有什么区别？