在我们看来，目前许多公司全力投入 Kubernetes 都是没有意义的，但选择权在他们。如果你读到了这篇文章，而且你所在的组织目前正在设法确定自己有多需要 Kubernetes，那么我希望本文的观点可以帮助你的团队做出正确的决定。
本文最初发布于 Ably 工程博客，由 InfoQ 中文站翻译并分享。
前言
在 Ably，我们运行着一个大规模的生产基础设施，支撑着 Ably 全球客户的实时消息应用程序。和大多数科技公司一样，这个基础设施在很大程度上是基于软件的；这些软件大部分是部署并运行在 Docker 容器上的，这也和大多数科技公司一样。
如果你一直在关注技术领域，那么你可能会想到，下面这个问题经常会有人问：
“那么……你们用 Kubernetes 吗？”
我们当前的客户，我们潜在的客户，对我们平台感兴趣的开发人员，应聘Ably 职位的人，都问过这个问题。我们甚至还碰到过一些有趣的应聘者，他们放弃我们提供的职位，理由是我们没有使用 Kubernetes。
在规划基础设施长期路线图时，我们也问过自己这个问题：我们应该在某个时候将 Kubernetes 作为主要的部署平台吗？
为什么选择 Kubernetes？
Kubernetes 是最知名的容器化软件大规模编排系统。虽然存在不同的声音，但在很大程度上，它仍然处在炒作周期的顶峰——你经常会觉得每个人都在 Kubernetes 上运行软件，或者至少最近听人说，他们希望将所有东西都移到 Kubernetes 上。Mesos 的流行度迅速降低，Docker Swarm 也是少说为妙，而如果你还在往普通的 EC2 实例上部署，那不如索性用穿孔卡得了。
Kubernetes 有很多优点。它是由一些具有大规模生产负载经验的工程师开发的，而且是在现实世界中经过谷歌 Borg 编排系统证明了的技术。它获得了供应商持续不断的支持，现如今，你不会发布一款软件产品而不提供官方 Docker 镜像和 Kubernetes 部署指南。
多少有点令人惊讶的是，Kubernetes 从其灵感来源 Borg 继承下来的东西已经所剩无几，即将一个大型裸金属机器池变成一个私有云环境。现如今的大多数 Kubernetes 部署似乎都是在虚拟机上，而这些虚拟机多数时候是在公有云提供商那。公有云是现在许多组织部署 Kubernetes 的动因；它被视为一个统一的 API 层，使多云部署对 DevOps 人员透明。
即使在一朵云中，这种 Kubernetes 开发体验也经常被提及。开发人员已经习惯使用 Docker 了，而 Kubernetes 可以让相同的容器轻松在生产环境中运行。此外，借助命名空间、内置资源管理以及内置的虚拟网络特性，或服务网格，或两者兼而有之，它还允许部署由不同团队维护的多个交互式任务，并且彼此互不影响。
Ably 用什么来代替 Kubernetes？
Ably 是一个公有云客户。我们的整个生产环境都在AWS 上，目前没有其他地方。我们运行在 EC2 实例上。一天之中，机器总数是自动变化的，但不管怎么变化，总数至少也有几千台，分布在 10 个 AWS 区域。这些机器确实是在运行 Docker，我们的大部分软件也是部署在容器中的。
资源管理
当通过 Kubernetes 管理资源时，我们不是针对每个服务使用大小适中的 EC2 实例，而是使用大实例（.metal 类的一种，也许是最大的），并将它们用容器打包。
打包服务器有个小优点，就是可以使用现有服务器上的空闲资源，而不必为资源需求不大的服务额外分配机器。但这也有一个很大的缺点，就是在同一台机器上运行异构服务，导致资源竞争。这不是什么新问题：云提供商在使用虚拟机时也面临同样的问题，即“吵闹的邻居”。不过，云提供商的系统中有 10 几年积累下的秘密武器，可以在最大程度上为客户减轻这个问题。但在 Kubernetes 上，你得自己解决所有问题。
一种可能的方法是设法在使用 Kubernetes 时保留“一个虚拟机，一个服务“模型。Kubernetes minions 不必都相同，它们可以是不同大小的虚拟机，Kubernetes 的调度条件可以确保每个 minion 只运行一个逻辑服务。这样就有一个问题：如果要在特定的 EC2 实例组上运行特定的容器集，为什么还要有一个 Kubernetes 层，而不直接那样做？
自动缩放
在使用 Kubernetes 时，服务的自动缩放看上去也很类似：暴露一个自定义的“当前使用率”指标，然后设置规则根据需要增加或移除容器。当然，只有在集群节点上还有容量时，Kubernetes 集群才能启动额外的服务 pod。这样说来，我们在部署时就需要留下相当数量的空闲容量，并添加Cluster Autoscaler 来根据需要增加节点。
对于 Cluster Autoscaler 来说，向上扩展集群相当简单——“当空闲容量低于期望值时增加节点”。不过，收缩集群就比较复杂了：可能你最终找到了最空闲的节点，但不是空节点。这就需要把剩余的 pod 迁移到其他节点上，腾空这个节点后再停止该节点，完成集群收缩。
关于自动缩放，我们的结论是，工作方式和现在类似，但我们要解决两个自动缩放问题，而不是一个，而且这两个问题都比我们现在要解决的问题更复杂。按需或按计划容量管理（需人工干预）都更复杂一点，因为我们必须首先保证有足够的 Kubernetes 节点，只有那样才有足够的 pod 来提供所需的服务。
流量入口
使用 Kubernetes 时，流量入口就非常简单了。EKS 团队提供了一些非常值得称道的设计选项：如果集群那样配置，每个 pod 都会收到一个 AWS 托管的 IP 地址，该地址与 EC2 的虚拟网络层 VPC 完全集成。在集群内运行的东西可以直接访问这些 IP，运行在 AWS 上同一个 VPC 族内但不在集群里的东西，则需要通过 AWS 提供的两种虚拟负载均衡器访问。
当在服务的 Kubernetes 规范中添加 Ingress 或 Service 小节时，有一个控制器会自动创建 AWS 负载均衡器，并将它们直接指向对应的 pod 集。总的来说，这不会比我们现在暴露流量路由实例的方式更复杂。
当然，这里有一个隐藏的缺点，就是这种出色的集成完全是 AWS 特有的。因此，如果你想在多云环境下使用 Kubernetes，这就不是很有帮助了。
DevOps
在 Kubernetes 的世界中，软件版本管理和我们现在的方式非常类似。现在，我们是在自定义配置系统中指定一个新的目标版本，所有 EC2 实例会自动滚动替换，使用 Kubernetes 的话，我们需要在Kubernetes Deployment 中指定一个新的目标版本，然后 pod 会滚动替换。
但是还有其他好处吗？
总的来说，我们做的事基本不变，但做法更复杂了。在探讨如何移植现有的基础设施时，如果在 Kubernetes 上运行能提供其他我们没有考虑到的好处，那或许值得这样做。让我们看下人们经常提到的 Kubernetes 的其他优点，看看它们对我们是否有帮助。
多云就绪
我们发现自己属于“不应该”的那部分，当前也就没有执行这样的战略。我们并不是完全赞成，Kubernetes 是达成这一战略的好方法。当服务需要访问集群外的服务时，或者需要从集群外访问时，或者使用某种持久化存储时，不同的主流云提供商之间确实存在差别，而 Kubernetes 并不足以完全屏蔽这种差异，让开发完全不用考虑。
如果你仍然需要一个 Kubernetes on AWS 部署策略，以及另一个相似但不同的 Kubernetes on GCP. 部署策略，那么与不使用 Kubernetes 相比，采用两个相似但不同的 AWS 和 GCP 部署策略不是会困难许多吗？
混合云就绪
在我们看来，管理混合云或内部环境（或者换个说法，管理你自己的物理机）是一个部署 Kubernetes 的有效理由。无独有偶，这也是 Borg 的设计初衷。如果我们已经计划好建设自己的物理数据中心，而不是购买公有云资源，我们将在其中安装的几乎可以肯定是裸机 Kubernetes 集群。
还有一个选项是设法基于虚拟机构建私有云，许多组织选择了这种方式。不过，根据已有的经验，构建那种环境绝不是一个实惠或简单的选项。我们还没有准备好创建自己的数据中心。要等到我们的业务翻几番，拥有自己的硬件所带来的好处值得我们在工程部门保有一个物理基础设施小组。
基础设施即代码
基础设施即代码是我们已经在做的工作，用了CloudFormation 和Terraform 以及我们自定义的工具。编写 Kubernetes YAML 文件并不是管理“基础设施即代码”的唯一方式，在许多情况下，也不是最合适的方式。
有一个很大而且很活跃的社区
使用 Kubernetes，人们常说的一个好处是，有一个很大的用户社区可以分享问题和建议。但是，并不是运行了 Kubernetes 才能参与到这个由用户和开发者组成的庞大社区。云计算还涉及许多其他的方面，我们积极参与了其中许多社区。AWS 用户的技术社区比 Kubernetes 开发者和用户社区更大，也有相当大的重叠。我们部署的许多其他技术，如 Cassandra，也非常流行。我们并没有因为身处 Kubernetes 社区之外而感到孤单。
一个让人更不愿意承认的事实是，在许多情况下，产品庞大而且发展迅速的用户社区并没有什么实际的帮助。Ably SRE 有多名工程师之前曾在 Kubernetes 团队工作，他们发现，数量庞大的初学者使得他们很难就 Kubernetes 相关的问题找到有用的信息。许多人使用 Kubernetes，但根据我们的经验，很少有人对它有深入的了解，因此，对于这样一个拥有庞大用户群体的东西，通过社区解决问题比你想象的要难得多。
大量的供应商涌入这一领域，造成了严重的技术搅动，为了适应新出现的第三方插件，Kubernetes 的核心特性频繁增加或变化。一个庞大而活跃的社区既是一种祝福，也是一种诅咒。
Kubernetes 的附加成本
复杂性。迁到 Kubernetes，组织需要一个完整的工程团队才能保证 Kubernetes 集群的运行，这还是假设使用的是托管 Kubernetes 服务，而且要有其他基础设施团队工程师维护上面的其他支持服务以及组织实际的产品或服务。
例如，上面提到的那些做得很好的 AWS EKS 网络和流量入口服务。那不是 EKS 自带的。你需要创建一个 EKS 集群，然后在上面安装并配置那些服务。然后还有一些其他的服务。
如果我们沿着服务提供商提供的道路走下去，那显然可以减轻我们的工作，但那是有代价的。我们前面提到过这样一个生机勃勃的市场所造成的技术搅动，因此，从一个供应商转到另一个供应商远非易事。选择供应商并不是一件轻巧的事，那本身就是一种架构承诺。
这个问题并不是只有 AWS 提供的托管 Kubernetes 才有——整个行业都是如此。重点不是 EKS 团队的工作不够出色，而是说，即使真有一个维护得很好的托管 Kubernetes 设置，也仍然需要做很多工作才能将其从一个基本的集群变成一个可以可靠运行服务的生产环境。
小结
虽然我们知道 Kubernetes 是一个设计得很好的产品，但我们目前没有使用它，或者说没有计划使用它。不是说部署 Kubernetes 没意义，只是说到目前为止，对我们来说没意义。
在经过仔细的成本收益评估后，我们发现，引入这样一个成本高昂的组件并不能真正解决我们的问题，而只是将问题转移到了其他地方。
在我们看来，目前许多公司全力投入 Kubernetes 都是没有意义的，但选择权在他们。如果你读到了这篇文章，而且你所在的组织目前正在设法确定自己有多需要 Kubernetes，那么我希望自己的观点可以帮助你的团队做出正确的决定。
和其他任何组织的系统一样，我们的生产系统无疑也存在问题和技术债务。我们有一个改进清单，我们也会额外招聘工程师来帮助我们实现这些改进。不过，归根结底，“迁移到 Kubernetes ”不在这份清单上。
查看英文原文：No, we don’t use Kubernetes
本文文字及图片出自 InfoQ
你的反应是：