简介：从第三方的调研数据看，容器和 Kubernetes 曾经成为云原生时代支流的抉择，但理论落地的时候，却陷入了窘境。咱们尝试去总结了一些共通点，以及应答计划，兴许能为正在落地容器技术的企业提供一些参考。

作者：望宸、木环、溪洋 等
审核 & 校对：不瞋、宏良、张磊、志敏

编辑 & 排版：酒圆

容器实质是一项隔离技术，很好的解决了他的后任 – 虚拟化未解决的问题：运行环境启动速度慢、资源利用率低，而容器技术的两个外围概念，Namespace 和 Cgroup，恰到好处的解决了这两个难题。Namespace 作为看起来是隔离的技术，代替了 Hypervise 和 GuestOS，在本来在两个 OS 上的运行环境演进成一个，运行环境更加轻量化、启动快，Cgroup 则被作为用起来是隔离的技术，限度了一个过程只能耗费整台机器的局部 CPU 和内存。

当然，容器技术之所以能风行，更因为他提供了标准化的软件开发交付物 – 容器镜像。基于容器镜像，继续交付这件事才可能真正落地。

咱们还能列举出许多应用容器技术的理由，这里就不再一一赘述。

同时，云计算解决了根底资源层的弹性伸缩，却没有解决 PaaS 层利用随根底资源层弹性伸缩而带来的批量、疾速部署问题。于是，容器编排零碎应运而生。

从第三方的调研数据看，容器和 Kubernetes 曾经成为云原生时代支流的抉择，但理论落地的时候，却陷入了窘境。咱们尝试去总结了一些共通点，以及应答计划，兴许能为正在落地容器技术的企业提供一些参考。

难用在哪？

容器和 Kubernetes 的先进性毋庸置疑，但当大量的企业在开始拥抱容器编排畛域的事实标准 Kubernetes 时，却陷入了窘境。“K8s 就像一把双刃剑，既是最佳的容器编排技术，同时也存在相当高的复杂性和利用的高门槛，这个过程中往往会导致一些常见性谬误”。就连 Kubernetes 的创立者和外围推动者 Google 自身都抵赖这个问题。

一次采访中，阿里巴巴高级技术专家张磊剖析了 Kubernetes 的实质，他指出，“Kubernetes 自身是一个分布式系统而不是一个简略的 SDK 或者编程框架，这自身曾经将其复杂度晋升到了零碎级分布式开源我的项目的地位。此外，Kubernetes 第一次将申明式 API 的思维在开源基础设施畛域遍及开来，并以此为根底提出了一系列诸如容器设计模式和控制器模型等应用范式，这些具备肯定先进性和前瞻性的设计也使得 Kubernetes 我的项目被公众承受时会存在肯定的学习周期。”

咱们大抵总结了 Kubernetes 的 4 大复杂性。

1、认知简单：他和原有的后端研发体系不同，延长出一套全新的实践，并提供了一系列全新的技术概念，并且这些概念，例如 Pod、sidecar、Service、资源管理、调度算法和 CRD 等等，次要是面向平台研发团队而非应用开发者设计，提供很多弱小灵便的能力。然而，这不仅带来了平缓的学习曲线，影响了利用开发者的应用体验，甚至在很多状况下了解不当还会引发错误操作，乃至生产故障。

2、开发简单：K8s 应用申明式办法来编排和治理容器。为了实现这一点，须要配置一个 YAML 文件，但再简单的应用程序中，引入新环节影响了开发者的生产力和敏捷性。此外，不足内置的编程模型，开发者须要依赖第三方库来处理程序间的依赖关系，这些都会影响到开发效率，并减少不必要的 DevOps 开销。

3、迁徙简单：将现有的应用程序迁徙到 K8s 比较复杂，尤其是非微服务架构，在很多状况下，必须重构特定组件或整个架构，并且须要应用云原生原理重构应用程序，例如状态依赖，如写本地目录、有程序，网络依赖，如写死 IP，数量依赖，如正本固定等等。

4、运维简单：K8s 的申明式 API 颠覆了传统的过程式运维模式，申明式 API 对应的是面向终态的运维模式。而随着 K8s 集群规模的增长，徒手基于开源 K8s，运维难度也会呈线性增长，出现在集群治理、利用公布、监控、日志等多个环节，集群稳定性将面临极高的挑战。

是否还有别的解法？

技术总有双面性，容器变革了云计算的基础设施，成为了新的计算界面。而 Kubernetes 则搭建了一个对立的基础设施形象层，为平台团队屏蔽掉了“计算”、“网络”、“存储”等过来咱们不得不关注的基础设施概念，使得咱们可能基于 Kubernetes 不便地构建出任何咱们想要的垂直业务零碎而无需关怀任何基础设施层的细节。这正是 Kubernetes 被称为云计算界的 Linux 以及“Platform for Platforms”的根本原因。

但间接上手操作 Kubernetes 是否是咱们利用容器技术的惟一抉择呢？答案是否定的。在容器技术的演进过程中，咱们也发现了不少可能升高容器编排门槛的开源我的项目和商业化产品，接下来，咱们将从双手的解放水平由低到高，一一介绍。

围绕 Kubernetes 生态的开源工具

OAM/KubeVela 是托管在 CNCF 中的开源我的项目，旨在升高 K8s 在利用开发和运维上的复杂性，最后由阿里云和微软云联结发动。

KubeVela 作为凋谢利用架构模型 OAM 的规范实现，与底层基础设施和无关、原生可扩大，而且最重要的是它齐全以利用为核心。在 KubeVela 中，“利用”被设计为整个平台的「一等公民」。利用团队只须要围绕组件、运维特色、工作流等几个跨平台、跨环境的下层形象来进行利用的交付与治理，无需关注任何基础设施细节和差异性；平台管理员则能够随时以 IaC 的形式配置平台反对的组件类型和运维能力集等个性，以便适配任何利用托管场景。

KubeVela 是齐全基于 K8s 构建的，具备人造的被集成能力和普适性，人造透出 K8s 及其生态的所有能力，而不是往上叠加形象。因而 KubeVela 实用于那些具备肯定的 K8s 平台开发和运维能力，同时心愿可能应用到全套 K8s 能力，一直扩大平台能力的技术团队。

容器曾经从一项隔离技术演进成一个生态，KubeVela 这类能够极大升高 K8s 应用复杂度的开源工具，会逐渐开释其生命力，使开发人员无需成为 K8s 专家即可享受到云原生带来的高效与便捷。

sealer 是一款开源的分布式应用打包交付运行的计划，极大的简化了容器我的项目的交付复杂性和一致性问题。sealer 构建进去的产物可称之为 ” 集群镜像 ”，并内嵌了 K8s，该 ” 集群镜像 ” 能够 push 到 registry 中共享给其余用户应用，也能够在官网仓库中找到十分通用的分布式软件间接应用。

交付是容器生态的另一个难题，面临着依赖简单、一致性的问题，尤其是工业级的 Kubernetes 交付我的项目，交付周期变长、交付品质要求高，sealer 非常适合于软件开发商、ISV 等性质的企业，可将部署工夫缩短至小时级别。

凋谢、标准化的企业级 Kubernetes 服务

大部分云厂商提供了 Kubernetes as a Service 的容器平台能力，比方 AWS EKS 和阿里云的 ACK，能够大幅简化 K8s 集群的部署、运维、网络存储、平安治理等能力，提供了通过 CNCF 标准化认证的 K8s 服务，能够满足简直全场景的工作负载需要，并提供了丰盛的扩大和定制能力。此外，大部分云厂商会基于开源 Kubernetes 框架，在下层做不同水平的封装，来适配不同企业背景和不同场景下的需要，以提供发行版和 Pro 版，例如阿里云的 ACK Pro 就提供了托管 master 和全托管节点池的能力，全面整合 IaaS 能力，更加高效、平安、智能，将容器集群的各种细分场景最佳实际和全栈优化作为内置服务提供给企业。

从现有用户规模来看，这是大部分互联网企业落地容器技术的支流抉择。

更多信息请移步至：《阿里云容器服务多项重磅公布：高效智能、平安无界的新一代平台》。

向 Serverless 演进的 Kubernetes 服务

传统的 Kubernetes 采纳以节点为核心的架构设计：节点是 Pod 的运行载体，Kubernetes 调度器在工作节点池中抉择适合的 node 来运行 Pod。

而对于 Serverless Kubernetes 而言，最重要的一个概念是将容器的运行时和具体的节点运行环境解耦。用户无需关注 node 运维和平安，升高运维老本；而且极大简化了容器弹性实现，无需依照容量布局，按需创立容器利用 Pod 即可；此外 Serverless 容器运行时能够被整个云弹性计算基础设施所撑持，保障整体弹性的老本和规模。

泛滥云厂商也将容器和 Serverless 做进一步的交融：例如阿里云的 Serverless 容器服务 ASK、Google GKE 的 AutoPilot，免得运维的形式升高了客户在 K8s 节点和集群上的操作复杂度，无需购买服务器即可间接部署容器利用；同时，依然能够通过 K8s 命令行和 API 来部署容器利用，充分利用了 K8s 的编排能力，并且依据利用配置的 CPU 和内存资源量进行按需付费。

这类服务十分长于解决一些 Job 类的工作，例如 AI 畛域的算法模型训练，同时领有在 K8s 环境下比拟统一的开发体验，是容器服务生态十分好的补充。

更多信息能够移步至：《Serverless Kubernetes：现实，事实与将来》。

容器和 Serverless 技术加持的新一代 PaaS 服务

企业级市场的需要总是分层的、多样化的，这和技术人才的散布严密相干，并不是每家企业都能建设一个技术实力足够强的团队，尤其是在非北上广深的城市，并且落地一项新技术时，总是分阶段布局的，这就给更多的产品状态孕育了市场空间。

K8s 尽管提供了容器利用的全生命周期治理，然而太丰盛、太简单、太灵便，这既是一种劣势，有时候也是一种劣势。尤其是对于习惯了在虚拟机时代，以利用为视角来治理利用的研发运维人员而言，即使像 AWS EKS、阿里云 ASK 等曾经在肯定水平上升高了 K8s 的操作复杂度，他们依然心愿通过某种形式，能够进一步升高容器技术的应用门槛。

容器和 K8s 并非肯定要捆绑应用，在一些新型的 PaaS 服务中，例如阿里云的 Serverless 利用引擎（SAE），底层将虚拟化技术改造成容器技术，充分利用了容器的隔离技术，来晋升启动工夫和资源利用率，而在利用管理层，则保留了原有的微服务利用的治理范式，使用者不用学习宏大而简单的 K8s 来治理利用。这类新型的 PaaS 服务通常还会内置全套微服务治理能力，客户无需思考框架选型、更无需思考数据隔离、分布式事务、熔断设计、限流降级等，也无需放心社区保护力度无限二次定制开发的问题。

此外，底层计算资源池化后，其人造的 Serverless 属性使得用户不用再独自购买和继续保有服务器，而是按 CPU 和内存资源量来配置所需的计算资源，让容器 + Serverless + PaaS 得以合三为一，使得技术先进性、资源利用率优化、不变的开发运维体验能够交融在一起。因而，相比于本文中的其余计划，这类计划的特色是提供了 PaaS 体验，让新技术落地更加安稳。

大部分传统行业、一些技术能力偏差于业务层的互联网企业、和一些不心愿因受制于后端而影响业务快递迭代的守业公司，大多都会偏向于 PaaS 状态的产品，抛开企业属性，PaaS 类的服务在解决以下场景更具交付劣势：

• 上线了一个新的我的项目，想疾速验证，不要出故障，同时管制人力的投入老本；

• 业务体量回升快，用户越来越多，业务稳定性有点 hold 不住，新版本公布、线上利用治理等环节开始有点畏手畏脚，但技术储备还无奈及时应答以后变动；

• 决定要把原有的单体架构升级成微服务架构，但因为团队短少微服务专家，评估完我的项目发现降级危险比拟高。

更多信息能够移步至：《突破 Serverless 落地边界，阿里云 SAE 公布 5 大新个性》。

更为极致的 Serverless 服务 –  FaaS

FaaS 的呈现，让具备弹性灵便诉求的业务场景，有了更好的选项。越来越多的大中型企业将传统后端畛域对扩容有灵便需要的执行单元剥离进去，运行在 Serverless 架构上。

这使得 FaaS（函数计算）成为容器和 K8s 外，另一种通用算力的抉择。

和 Google Cloud Run、App Runner 等 Serverless 服务一样，FaaS 的产品状态正变得越来越凋谢，运行上的限度越来越少，除了适宜事件驱动的计算模型，也适宜 Web 单体利用、Job 等场景，能够帮忙用户把弹性施展到极致，进一步晋升计算资源的利用率。

例如，游戏行业的莉莉丝将函数计算利用于战斗校验，来验证玩家客户端上传的战斗是否有舞弊的状况。战斗校验个别须要逐帧计算，CPU 耗费会十分高，通常 1 队 v 1 队的战斗须要 n 毫秒，而 5 队 v 5 队的战斗则须要相应 5n 毫秒，对弹性要求很高。此外，容器架构下挂载的 SLB，会因为轮询机制导致无奈感知 Pod 的理论负载，由此引起的负载不均，产生死循环和稳定性危险。

函数计算的调度零碎帮忙莉莉丝合理安排每个申请，对于死循环问题，也贴心的提供了超时杀过程机制，并将调度零碎的复杂性下沉到了基础设施。此外，函数计算深度优化后的冷启动时延大幅降落，从调度、到获取计算资源、再到服务启动，根本在 1 秒 + 左右。

另外，FaaS 的呈现，也极大的解放了守业公司全栈工程师在 DevOps 上破费的精力，来承载小程序、网站等 Web 单体利用，例如，函数计算升高了 Node.js 等前端语言的服务器保护门槛，只有会写 JS 代码就能够保护 Node 服务。

更多信息能够移步至：《逾越行业绊脚石，阿里云函数计算公布 7 大技术冲破》

适合的才是最好的

需要的越多，投入的也会越多，这是恒古不变的情理。在咱们决定引入容器技术后，应用 K8s 之前，须要想分明为什么须要 K8s。

如果咱们心愿充分利用 K8s 的全套能力，并且团队具备肯定的技术储备，那么 KubeVela 是现实的开源选型，sealer 还能帮忙咱们升高交付复杂度；如果心愿将 K8s 下层不同水平的封装工作交给云厂商来解决，以更高效的适配不同业务场景下的需要，那么云厂商提供的商业化的容器服务是不错的抉择；如果容器和 K8s 无奈符合弹性业务类的诉求，则能够抉择 FaaS。

但又如果咱们的利用并没有那么简单，只是奢侈的心愿简化利用生命周期治理和底层基础设施，保障业务的高可用，并专一在业务开发上，那么可能就不须要应用 K8s 来编排容器利用了，毕竟 K8s 是源自 Google 的 Borg，他是用来治理 Google 海量的容器利用的。

参考文章：

1. 《云计算的前世今生》，刘超
2. 《灵便、高效的云原生集群治理教训：用 K8s 治理 K8s》，淮右、临石
3. 《复杂性会成为 Kubernetes 的“致命伤”吗？》，赵钰莹
4. 《Simplifying Kubernetes For
   Developers》，__Rishidot Research
5. 《KubeVela 正式开源：一个高可扩大的云原生利用平台与外围引擎》，OAM 我的项目维护者
6. 《KubeVela 1.0：开启可编程式利用平台的将来》，OAM 我的项目维护者

相干链接：

1. 我的项目地址：
   https://github.com/oam-dev/kubevela
2. 我的项目地址：
   https://github.com/alibaba/sealer

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。