【翻译】容器管理服务。解释和比较KaaS、KPaaS和CaaS

作者：Lars Larsson 11月4日, 2021年

Elastisys高级云计算架构师和DevOps专家工程师Lars Larsson在Elastisys的博客上发表的原创客座文章

云计算服务模式向我们表明，基础设施即服务将继续存在。在2021年，我们以虚拟机、虚拟网络和虚拟存储的形式消耗虚拟化的硬件，这是一个既定事实。所有这些都有看似无限的容量（嗯，有点），我们可以随便使用。

但是，为虚拟机管理操作系统和网络，也许不是大多数公司想要投入时间的事情。相反，管理服务可以是一种具有成本效益的方式，可以获得云计算的好处，并更直接地专注于使公司的应用独一无二。为客户提供价值，而不是管理基础系统。

在这篇文章中，我比较了现代和容器化应用程序的管理服务产品。首先，我们看一下更普遍的平台即服务（PaaS）模型，它启发并定义了这个领域。然后，我们还讨论了更完备的Kubernetes-as-a-Service和Container-as-a-Service模式，并对其进行了更详细的描述。然后，我展示了旧的管理容器运行时模型各自的优点和缺点是如何形成一个新的服务模型的基础。Kubernetes-Platform-as-a-Service（KPaaS），它提供了两者的优势。

平台即服务（PaaS）

PaaS建立在基础设施即服务（IaaS）的基础上，但扩展了其范围。一个典型的PaaS是有主见的，在这个意义上，它也许只支持一种编程语言或语言运行时间。但作为交换，它在代码层面上与你的应用程序深度整合。通过周围的工具，这种服务模式使得快速开发、构建、更新和管理你的应用程序变得容易。

PaaS的一个很好的例子就是Heroku的开发者体验。应用程序开发人员从不管理底层服务器。用一小部分选定的语言编写的代码，被部署到Heroku平台上。适当的语言运行时间完全由Heroku管理，并保持更新。因此，应用程序开发人员没有责任去升级，例如NodeJS运行时，也没有责任去升级它所部署的服务器。

另一方面，这种深度集成意味着你的应用程序基本上受制于该平台的服务提供商。如果你是Heroku的客户，你的应用程序与该PaaS深度集成。你不可能轻易地离开它。

因为PaaS的目标是主流用例，你的应用可能/将最终超越所提供的东西。当Heroku的服务（和定价模型，据说也是更多地面向初创企业而不是企业）限制了他们的发展时，我已经帮助很多客户实现了这种转变。

关于容器的简短括号

容器技术允许人们将应用程序源代码（或二进制形式的现成程序可执行文件）与它所依赖的所有代码一起打包。因此，所产生的容器中拥有所有的东西，可以完全描述软件运行所需的所有内容。这意味着，它决不是束缚在任何一个特定的平台上。相反，它是完全可移植的：它在开发者的笔记本电脑上和在云服务器上的运行是完全一样的。

然而，在容器中运行的软件必须相互连接协作，并由一个运行容器化软件（或简称 "容器"）的平台管理。开源的Kubernetes就是这样一个容器 编排系统。它不是唯一的一个，但它是迄今为止最流行的一个。Kubernetes的流行主要是由于它是开源的。它主要的仍然活跃的竞争者是AWS ECS。较早的，如Docker Swarm、DC/OS和CloudFoundry，在很大程度上已经落伍了。

Kubernetes-as-a-Service (KaaS)

Kubernetes在逻辑上由两部分组成。控制平面和工作节点。控制平面是Kubernetes系统的大脑：它决定各个容器应该在哪个工作节点上运行，以及其他一系列的自动化任务。控制平面被部署在一组云服务器上，而工作节点是另一组云服务器。

KaaS通常意味着控制平面部分是由服务提供商管理的。这要么是云基础设施提供商本身，要么是一个合作伙伴。最常见的KaaS是AWS的EKS、Azure的AKS和谷歌的GKE。

因此，KaaS客户不需要管理Kubernetes集群的大脑，但肯定需要管理大脑：工作节点。这无疑降低了复杂性，但仍有大量的系统管理工作需要团队管理。工作节点必须保持最新，包括操作系统和Kubernetes版本，而且必须处理基础设施相关的事情，如网络和存储。

KaaS使运行容器化的应用程序更加容易，但对于团队来说，绝对不是一个可以放手管理的经验。大量招聘 "Kubernetes管理员 "的广告，将其中一个主要的KaaS列为基础平台，清楚地表明了这一点。

容器即服务（CaaS）

CaaS的客户反而选择了完全不需要动手的容器运行时间体验。从本质上讲，他们把容器连同它应该拥有的资源描述（X GB RAM，Y CPU核心）一起交给服务提供商，并让他们想办法部署它。最流行的此类服务是AWS Fargate。该服务所依据的系统对客户是隐藏的：反正他们既不能也不需要排除任何问题，因为该服务是完全管理的。

这种复杂性降低的背面是，虽然CaaS使运行容器变得简单，但这种服务是供应商特定的平台。而且，围绕着甚至是流行的AWS Fargate，已经形成的社区心智和支持非常少。

我从开发人员和DevOps工程师那里听到的关于Fargate的消息是，它的价值初听起来很好，但他们最终感到失控了。来自管理层的所有责任都是为了保持应用程序的正常运行，但没有控制和能力来确保它的正常运行。因为Fargate是AWS特有的技术解释云计算应用，而AWS是唯一拥有实际控制权的公司，使用Fargate确保业务连续性的唯一方法是支付高级支持协议。而且你可以从他们的支持定价页面看到，这无疑进一步提高了Fargate的价格（你会听到DevOps人员普遍抱怨）。

PaaS、KaaS和CaaS之间的比较

因此，PaaS需要深度整合，以使一个应用程序与平台一起工作。但是，这是一个聪明的设置，所以系统管理可以被最小化。

然后，容器和KaaS出现了，整合基本上减少到零，因为容器是完全独立的软件包。他们只是需要一个足够智能的系统来部署容器。

由于KaaS需要系统管理员，CaaS被发明了。但是，这又重新引入了对平台的依赖!

CaaS本质上是PaaS，但有容器。

因此，CaaS的好处是，开发者不必关心管理底层容器运行时或协调系统。坏处是，它把他们锁在里面，而且在社区里，围绕着这些供应商的特定平台，没有很多伟大的解决方案。

而KaaS的伟大之处在于，它是Kubernetes，围绕着它有很多社区的牵引力和对常见问题的伟大解决方案。但是，对于KaaS，你必须做你并不真正想做的系统管理，也不关心。

通过一个完全管理的Kubernetes平台获得KaaS和CaaS的好处

我相信在KaaS和CaaS之间有一个甜蜜点。在最好的情况下，我希望这个中间地带能给我。

下面的信息图显示了作为客户的你将负责哪些部分，以及服务提供商承诺为你提供哪些服务。

这个甜蜜点包含了KaaS和CaaS的最佳部分。KaaS的主要缺点是只管理控制平面，而不管理工作节点。CaaS会给你这些，但它的容器编排不是Kubernetes，所以你不能轻松地运行现成的应用程序。但是，由于甜蜜点从这两种选择中获取了最好的东西，它没有各自的缺点。

但是，如你所知，这不是主要的云计算供应商提供的东西。而且说实话，我怀疑他们永远不会。特别是最后一部分关于避免锁定客户的云端特定技术。如果他们想的话，他们已经可以有类似的东西了。他们只是没有。

相反，为了获得这种完全管理的Kubernetes平台服务（KPaaS），我们必须求助于第三方，他们不受制于任何特定的云供应商。这意味着甜蜜点也必须附带自己的日志、监控和访问控制功能（等等），因为他们不能依赖单一云提供商提供的这些功能。我认为这是一个福音，因为这意味着管理的Kubernetes服务在操作上的感觉是一样的，无论它恰好部署在哪个云提供商上。

什么服务模式适合你的使用情况？

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!