Kubernetes 的学习路径，容器混合云到底有没有 “easy mode”

近年来，兼具公有云和私有云优势的混合云模式逐渐成为主流。Flexera 发布的 2021 云状态报告显示，92% 的企业在 IT 架构上选择多云战略, 其中 82% 的企业选择混合云。随着混合云的应用越来越广泛，越来越多用户发现在复杂的混合云环境完成容器编排并不容易。虽然 Kubernetes 已成为容器编排和调度的事实标准，但是 Kubernetes 操作复杂，且只专注于单集群租户管理，在多集群管理，尤其是涉及跨云的多集群管理方面并不完善。此外，Kubernetes 为云数据中心设计在边缘计算场景中也有一定的局限性。

面对 Kubernetes 存在的问题以及混合云旺盛的市场需求。各大公有云厂商纷纷推出自己的混合云容器服务，一时间，各类产品和解决方案让人眼花缭乱。在各具优势的混合云容器产品中该如何选择？只要弄清楚混合云容器服务背后的技术路线，便有助于指导开发者痛苦的技术选型之路。

当前的混合云容器服务大致可分为两类，一类是基于 Kubernetes 的，另一类是不基于 Kubernetes 的自研项目。由于 Kubernetes 已成为容器编排和调度的事实标准，因此，前者是当之无愧的主流。近年来，各大公有云厂商也都先后开源了各自基于 Kubernetes 的混合云容器服务。这类服务的技术路线主要分为两类。

第一种是在 Kubernetes 的基础做减法，打造轻量级的容器编排服务，比较典型的产品 K3s。

K3s 是由 Rancher Lab 于 2019 年推出的轻量级 Kubernetes 发行版。K3s 的名字来源于 K8s-5。为减少 Kubernetes 所需内存，Rancher K3s 删除了旧的、非必须的代码、整合正在运行的打包进程、使用 containerd 代替 Docker 作为运行时的容器引擎，此外引入 SQLite 作为可选的数据存储。从而使得其更好的适配 CI、ARM、边缘环境、物联网和测试这五个场景。K3s 所有组件均运行在边缘，因此不涉及云边协同，但从生产的角度 K3s 缺少集群管理方案，负责跨集群应用管理、监控等，然而遗憾的是 Rancher 并未对这部分能力进行开源。

以 K3s 为代表的轻量级容器编排产品适合运行在边缘计算场景中。现有的 Kubernetes 发行版本通常是内存密集型的，在边缘计算环境中显得过于复杂。这类产品通过降低内存，使其能够在边缘场景中更好的部署，此外，在边缘计算场景下，企业需要运维管理的 Kubernetes 集群数量非常庞大，且通常只有很少量的节点，因此运维人员需要负责大规模的基础架构。通过这类轻量级容器编排产品，可最大限度的简化用户的安装和操作步骤，降低运维难度。

第二种是对现有的 Kubernetes 架构做出一些改进。在此技术路线下比较具有代表性的开源产品是 KubeEdge 和 OpenYurt。

在目前的 Kubernetes 架构中，整个控制平面跟数据平面对网络要求比较高，因此这类技术路线对场景进行了一些改进，这两种产品都是在中间提供了一个代理层去维护以及保证不稳定环境下仍能够提供相对来说比较稳定的运用环境。

KubeEdge 是 2018 年开源的一个边缘计算平台，目前由 CNCF 孵化的项目。该项目在 Kubernetes 原生的容器编排和调度能力之上，扩展实现来了云边协同、计算下沉、海量边缘设备管理、边缘自治等能力。从架构上来看云端（K8s master) 增加了 Cloud Hub 组件和各类 controller，而在边缘的（K8s worker) 则是对原生组件进行了重写 EdgeCore 组件，从架构图可以看出 EdgeCore 是基于 Kubelet 重构的，为保证轻量化，裁剪了原生 Kubelet 的部分能力，增加了很多适配边缘场景的能力。尽管相比 Kubernetes，KubeEdge 的确能够更好的适配边缘场景，但由于架构的差异，不可避免会带来一些影响，如对于云原生生态的兼容性将下降。

OpenYurt 相比于 KubeEdge 的开源要稍晚一些，但是它采用非侵入的方式对 Kubernetes 进行增强，即在 Kubernetes 上做加法。在云端 (K8s Master) 上增加 YurtController ManagerYurtApp Manager 以及 Tunnel Server 组件。而在边缘端 (K8sWorker) 上增加了 YurtHub 和 TunnelAgent 组件。相比于 Kubernetes，OpenYurt 提升了边缘单元化、边缘自治、云边协同等能力。同时并未像损失对于云原生生态的兼容能力。然而由于 OpenYurt 始终是在原有架构上做加法，因此轻量化难以保证，此外，原生 Kubernetes 所存在的边缘节点过多可能导致系统不稳定的问题也依旧存在，并未得到解决。

基于 Kubernetes 的开源项目到底香不香？不可否认，在特定场景如边缘计算领域，他们弥补了原生 Kubernetes 的不足。但在做出优化的同时，通常也会产生新的问题。由于这两种技术路线都是在 Kubernetes 架构上做出一些改进，因此均会在不同程度上产生架构差异带来的影响。此外，由于部分项目对 Kubernetes 系统的入侵式修改，后续跟随 Kubernetes 社区的演进将会面临很大的挑战。

既然架构的改进会带来架构差异的影响，那么是否可以沿用原汁原味的 Kubernetes 架构？Amazon EKS Anywhere 为 Kubernetes 生态提供了一种全新的思路。

亚马逊云科技于今年 9 月全面推出 Amazon EKS Anywhere。Amazon EKS Anywhere 完全采用原生 Kubernetes 架构，不进行任何改动，仅仅在原有基础上添加一些管理跟维护工具，使其能够完全兼容并且更加方便的部署在用户自己的数据中心里。

Amazon EKS Anywhere 是 Amazon EKS 的最新部署选项，以往 Amazon EKS 只能在亚马逊自己的云环境之下实现基础设施兼容，但通过 Amazon EKS Anywhere 用户可以在自有基础设施上运行 Amazon EKS。因此，Amazon EKS Anywhere 更适合那些已经拥有、并打算继续使用大规模本地基础设施的企业用户。

Amazon EKS Anywhere 通过默认组件配置帮助简化本地 Kubernetes 集群的创建和运维，同时提供可实现集群管理自动化的工具。它是基于 Amazon EKS Distro 的优势构建的，后者是为亚马逊云科技上的 Amazon EKS 提供支持的同一个 Kubernetes 发行版本。亚马逊云科技支持所有 Amazon EKS Anywhere 组件，包括集成的第三方软件，从而让用户能够降低支持成本，同时无需维护冗余的开源和第三方工具。

此外，Amazon EKS Anywhere 为用户提供与 Amazon EKS 一致的本地 Kubernetes 操作工具。开发者可以利用 EKS 控制台通过 EKS 连接器查看在任何位置运行的所有 Kubernetes 集群（包括 EKS Anywhere 集群）。

虽然 Amazon EKS Anywhere 拥有众多优势，但也存在一些限制。根据亚马逊云科技目前的官方表述，Amazon EKS Anywhere 还仅适用于在本地使用 VMware vSphere 的自有基础设施上部署， 对于其它的部署目标如裸金属环境，将在 2022 年提供支持。另外 Amazon EKS Anywhere 的定位是用于本地数据中心的部署，没有提供对其它公有云部署的支持。

不过，基于 Kubernetes 研发的 Amazon EKS Anywhere 虽然已经在使用门槛上做了大量的工作，在架构层面具有低侵入性的优势，但从根本来看，EKS 依然是基于 Kubernetes 的，特征十分鲜明。对于开发者而言，依然存在较高的入门门槛。

如果企业团队对 Kubernetes 不甚熟悉，或者没有时间调研、学习 Kubernetes，又该如何应对混合云环境下的容器编排和治理问题呢？亚马逊云科技于今年 5 月推出的 Amazon  ECS Anywhere，或许能成为另外一个答案。

据介绍，Amazon ECS 是第一项由亚马逊云科技管理的容器编排服务。为用户提供一套易于使用控制平面，可通过虚拟机实例（Amazon EC2) 或完全无服务器（Amazon Fargate) 形式轻松运行各种容器型工作负载，同时与其他亚马逊云科技的托管服务实现原生集成，进而提供服务网格，日志记录、指标捕捉等增强功能。

Amazon ECS Anywhere 功能的出现，使得用户能够在非亚马逊环境中部署各类 Amazon ECS 任务。以此为基础，客户能够在特定亚马逊区域之内利用同一套易于使用的管理层定义并管理集群内的一切资源，而无需考虑集群位于哪里，执行环境如何。

相比于 Kubernetes 最重要的区别是 Amazon ECS 功能更加强大，而且更加简单易用。尽管 Kubernetes 开源产品生态非常繁荣，但是带来的问题非常复杂，学习曲线比较陡峭，Amazon ECS 非常简单易用且跟云上面很多产品结合非常紧密，用起来很方便。

此外，Amazon ECS Anywhere，非常适合在边缘计算或者用户计算资源比较受限制的场景下使用，非常轻便、灵活，没有太多对于硬件，或者资源方面、网络方面特别严格的要求，所以应用的场景非常多。

从 2021 年起，所有云环境下的开发者，已经不能忽视云边端一体化的大趋势，未来将有超过 50% 的数据跑在各类型的  IoT 终端上，Amazon ECS Anywhere 是对这种趋势的拟合与最佳适配。

此外，开发者只需将 Amazon ECS Anywhere 部署在亚马逊基础设施之外的容器服务当中，使用 External 启动类型，就能使同 Amazon 区域中 Amazon ECS 集群内的云服务实现类似同一环境下的彼此交互，并且，外部容器负载还能充分发挥所处物理位置上本地的方式为系统服务，借此实现内部视频文件的规模化处理等以往难以在云端完成的高强度工作。

由于 Amazon ECS Anywhere 强调基础设施的完全中立性，因此只要开发者制定的操作系统能够运行 Amazon ECS 和 System Manager 代理，即可对各类机器或设备进行注册，极低的注册门槛有助于帮助开发者轻松在亚马逊环境之外，包括边缘位置部署微服务用例，完全不受数据中心的运营要求限制。

那么回过头来看，到底该如何选择混合云容器服务呢？在容器治理层面，如果团队对 Kubernetes 经验丰富，且已经有成熟的架构体系，当然可以选择在集群层面对 Kubernetes 进行深度定制。

但如果需要更高效地推进研发工作，且与云原生、云边端一体化的大趋势结合在一起，那么诸如 Amazon EKS Anywhere、Amazon ECS Anywhere 这一类的产品无疑更好上手，更易维护，且屏蔽了底层的复杂性。

也有人提到，容器的未来绝对是开源的，基于开源软件做定制化，才是面向未来的。

诚然，对于围绕着容器生态 CNCF 云原生技术全景图确实非常庞大，说明整个开源领域的繁荣状态，并且很多技术确实是由开源推动的，是开源领域大家贡献发展的结果；但另一方面，容器层毕竟属于中间层，它对上层能够优化我们应用开发，促进它的迭代速度。对下层来讲它离不开底层网络计算层基础资源的支撑，在这个层面它没办法脱离开，所以在这个层面，公有云上所做的一些技术方面的创新，能够更好地去运行容器上的应用。

对于容器技术的未来，笔者认为将朝着三个方向进行发展。

首先，容器领域以成为事实上标准的技术，包括 Docker 以及 Kubernetes 将继续快速发展下去，会有更多传统企业迁移进来；

其次，过去容器相对来说采用比较集中化的部署方式，比如过去要么是在公有云上部署使用，要么在自己的数据中心使用，这种方式随着混合云的架构，会有很大的改变；

第三，Serverless 无服务器跟容器的结合或者说融合，也是将来发展的趋势。从所谓云原生成熟度上讲，这是更成熟的一种方式，能够迈进到无服务器这个领域，所以基于容器的无服务器技术也是未来发展的一个重要方向。