容器编排SDK的崛起

回顾10到15年前软件发行的镀金时代。如果你正在建立一个分布式平台，如门户网站或电子商务网站，它很可能是用Java编写的，即“写一次，随处运行”（WORA）。二进制发行版的打包会由一个或多个EAR（企业归档）、WAR（Web归档）和/或JAR（Java归档）组成。针对不同应用程序服务器会有特别说明。从产品管理的角度来看，考虑到应用程序服务器的差异，你会提供不同的web.xml文件。

多么美好的时光。

快进到今天。有一系列的打包和发行机制可以使你的产品得到采用。客户和最终用户需要选择安装产品的位置和方式。这要求产品经理不仅要做关于创建原始二进制文件的决定，还要考虑基础设施即代码、特定于云提供商的自动化和容器编排器格式等。对于日益复杂的分布式平台，应用程序基础设施需求很难简单地用这些新的发行格式来描述。

你有Docker吗？

我在容器繁荣期间担任多家公司的解决方案架构师时，客户经常会问我是否有我们产品/平台的Dockerized版本。每次我问为什么时，他们会说他们遵循公司的指令，要求工作负载转向容器格式，因为公司正在采用容器编排策略。他们的最终目标是容器必杀技，其中中间件（或系统）工程团队只管理容器编排。

别心急

很少有一个完全无状态的平台。一个典型的平台可能有许多需要编排的无状态和有状态服务。某些部件或应用程序不会容器化。随着系统以不同的速度发展，Martin Fowler的Strangler Pattern开始变得非常真实。通过复杂的分布式基础设施（如消息传递），需要管理特定容差和基础设施需求。

假设你正在处理故障或就地升级。例如，使用容器编排器可能无法轻松配置强鲁棒性的安装，因为集群机制需要特定的指标才能做出反应。最小阻力的路径是把平台硬塞进编排器。你能容器化吗？能。你能从有状态工作负载的失败中恢复吗？不能，因为这些步骤可能涉及一个编排器本身无法执行的工作流程，例如重放或重试。

Marathon vs. Kubernetes：这还在继续吗？

从容器编排器的市场格局来看，两个主要的平台是Marathon和Kubernetes，后者已经取得巨大成功。对于大多数正在进行容器化进程的组织而言，最初的障碍是以两种格式之一描述其应用程序：marathon.json或kubernetes.yaml。

当然，每个编排器都有其优点和缺点。Marathon和Kubernetes之间的功能差距似乎总能带来两个社区的快速变化。对于更复杂的分布式平台，普通的Kubernetes YAML可能没有足够的粒度来描述围绕初始化的编排器的vanilla安装/实现的操作步骤。

为什么欢迎SDK？

之前隐藏在编排器后面的是软件开发套件（SDK），例如Mesosphere DC / OS SDK。伴随着CoreOS与Operators for Kubernetes的共同贡献，RedHat / CoreOS最近推出了Operator Framework。

现在，你不是用部署描述符描述应用程序或平台，而是将应用程序或平台构建到SDK。想象一下，Kubernetes扩展了CRD（自定义资源定义）和与CRD一起使用的控制器——在GO中编写一个控制器来定义需要监视的内容以及如何对状态变化作出反应。

无畏的产品经理需要考虑的另一个决定是：从重新描述原始包装（包括Puppet或Chef脚本）转变为创建一个构建到编排器SDK的新版本/可部署。

通过构建到其中一个编排器SDK，产品的最终用户可以使用其中一个编排器接口（Mesosphere CLI / KubeCTL）来管理和扩展。用于对产品进行集群的复杂布线或用于重放/重试的工作流程由一个编排器接口进行模糊处理。

多大的牵引力？

GitHub提供了一个基于Kubernetes operator的平台列表。该列表定期更新。对于DC / OS SDK，要告诉哪些实际包含SDK有点困难，因为在DC / OS Universe中没有调用SDK。

最后的想法

我相信SDK的重要性仅次于混合云（Mesosphere的DC/OS和Kubernetes的Federation），并且将迎来更复杂的工作负载，这些工作负载不易于用编排器/资源管理器描述。潜在部署SDK可能会改变你对编排框架的vanilla安装，因为需要将定制/内部内容写入编排器以支持其他功能。截至2018年6月下旬，DCOS SDK处于alpha，operator框架SDK处于pre-alpha。当然，这些快速发展的项目会有很多变化。

原文链接：

https://thenewstack.io/the-rise-of-the-container-orchestrator-sdks/