简介： 从第三方的调研数据看，容器和 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 技术加持的新一代 PaaS 服务
企业级市场的需求总是分层的、多样化的，这和技术人才的分布紧密相关，并不是每家企业都能建立一个技术实力足够强的团队，尤其是在非北上广深的城市，并且落地一项新技术时，总是分阶段规划的，这就给更多的产品形态孕育了市场空间。
K8s 虽然提供了容器应用的全生命周期管理，但是太丰富、太复杂、太灵活，这既是一种优势，有时候也是一种劣势。尤其是对于习惯了在虚拟机时代，以应用为视角来管理应用的研发运维人员而言，即便像 AWS EKS、阿里云 ASK 等已经在一定程度上降低了 K8s 的操作复杂度，他们仍然希望通过某种方式，可以进一步降低容器技术的使用门槛。
容器和 K8s 并非一定要捆绑使用，在一些新型的 PaaS 服务中，例如阿里云的 Serverless应用引擎（SAE），底层将虚拟化技术改造成容器技术，充分利用了容器的隔离技术，来提升启动时间和资源利用率，而在应用管理层，则保留了原有的微服务应用的管理范式，使用者不必学习庞大而复杂的 K8s 来管理应用。这类新型的 PaaS 服务通常还会内置全套微服务治理能力，客户无需考虑框架选型、更无需考虑数据隔离、分布式事务、熔断设计、限流降级等，也无需担心社区维护力度有限二次定制开发的问题。
此外，底层计算资源池化后，其天然的 Serverless 属性使得用户不必再单独购买和持续保有服务器，而是按 CPU 和内存资源量来配置所需的计算资源，让容器 + Serverless + PaaS 得以合三为一，使得技术先进性、资源利用率优化、不变的开发运维体验可以融合在一起。因此，相比于本文中的其他方案，这类方案的特色是提供了PaaS 体验，让新技术落地更加平稳。
大部分传统行业、一些技术能力偏向于业务层的互联网企业、和一些不希望因受制于后端而影响业务快递迭代的创业公司，大多都会倾向于 PaaS 形态的产品，抛开企业属性，PaaS 类的服务在处理以下场景更具交付优势：
- 上线了一个新的项目，想快速验证，不要出故障，同时控制人力的投入成本；
- 业务体量上升快，用户越来越多，业务稳定性有点 hold 不住，新版本发布、线上应用管理等环节开始有点畏手畏脚，但技术储备还无法及时应对当前变化；
- 决定要把原有的单体架构升级成微服务架构，但由于团队缺少微服务专家，评估完项目发现升级风险比较高。
更多信息可以移步至：
更为极致的 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 服务。
更多信息可以移步至：
合适的才是最好的
需求的越多，投入的也会越多，这是恒古不变的道理。在我们决定引入容器技术后，使用 K8s 之前，需要想清楚为什么需要 K8s。
如果我们希望充分利用 K8s 的全套能力，并且团队具备一定的技术储备，那么 KubeVela 是理想的开源选型，sealer 还能帮助我们降低交付复杂度；如果希望将 K8s 上层不同程度的封装工作交给云厂商来处理，以更高效的适配不同业务场景下的需求，那么云厂商提供的商业化的容器服务是不错的选择；如果容器和 K8s 无法契合弹性业务类的诉求，则可以选择 FaaS。
但又如果我们的应用并没有那么复杂，只是朴素的希望简化应用生命周期管理和底层基础设施，保障业务的高可用，并专注在业务开发上，那么可能就不需要使用 K8s 来编排容器应用了，毕竟 K8s 是源自 Google 的 Borg，他是用来管理 Google 海量的容器应用的。
参考文章：
- 《云计算的前世今生》，刘超
- 《灵活、高效的云原生集群管理经验：用 K8s 管理 K8s》，淮右、临石
- 《复杂性会成为 Kubernetes 的“致命伤”吗？》，赵钰莹
- 《Simplifying Kubernetes For
Developers》，Rishidot Research - 《KubeVela 正式开源：一个高可扩展的云原生应用平台与核心引擎》，OAM项目维护者
- 《KubeVela 1.0 ：开启可编程式应用平台的未来》，OAM项目维护者
原文链接
本文为阿里云原创内容，未经允许不得转载。