Kubernetes 真的很难吗？

作者 | Artur Rychlewicz  译者 | 弯月

责编 | 王子彧

出品 | CSDN（ID：CSDNnews）

最近，37signals 发布了内部开发的工具 mrsk，用于简化服务的部署。但随工具一起发布的博客文章在网上引发了热议。

Kubernetes 很难吗？

许多人认为 Kubernetes 很复杂，从某种程度上，我认同他们的看法。

Kubernetes 的复杂性部分源于功能的多样化，几乎可以在 Kubernetes 上运行任何工作负载。功能的多样化需要资源可组合。这些资源必须像乐高积木一样，用户可以将多个组件连接起来构建有意义的产品。以容器为例，Kubernetes 有一个 Pod 的概念，指的是一组紧密耦合的一个或多个容器。但即便使用 Pod，你也不太可能单独运行它们。通常，你会通过部署、进程集或状态集来运行 Pod。这些只是在向外界公开服务之前需要涉及的组件。

但这仅仅是其中一个方面，任何生产级别的 Kubernetes 集群都包含了许多 Kubernetes 本来不需要的组件。当然，你可以构建一个最低限度的 Kubernetes 集群，但没必要。

构建生产环境很难

在构建服务时，最不希望看到的情况之一便是让用户失望。比如提供的服务不可靠。可能你的服务不需要一直运行，甚至不需要以 99.999% 的正常运行时间为目标，但停机次数太多，用户就无法信任服务。比如用户将图片上传到服务，一天后却发现图片不见了？

服务无法提供出色体验的原因很多，比如新推出了一款新产品，因新用户注册太多，服务不堪重负。换一个角度看，这是一个好现象。但更多的时候，是因为服务存在导致应用程序崩溃的错误。

因此，我们可以认为：构建生产环境很难。需要管理应用程序、日志、指标、存储、数据库、备份、负载均衡、部署、机密数据以及许多其他的方面。如果你使用了微服务，那么工作量更大。

无论是否使用 Kubernetes，这些工作都要完成。有了云，只要花一些钱就能省却很多工作，如果你愿意花钱，而且愿意接受被供应商锁定的风险，就可以大幅简化构建生产环境的工作。在 Kubernetes 出现之前，我们就采用了这种方式，而且事实证明没有任何问题。

姑且抛开炒作不谈，Kubernetes 被这么多公司采用是有原因的。它可以减轻开发团队的负担，只要编写一个简单的 YAML 文件就可以完成服务的部署。更重要的是，团队不再需要开发运维或基础设施工作人员添加 DNS 条目并创建负载均衡器来公开服务。如果你有操作员，他们可以以声明的方式完成这些工作。

必须使用 Kubernetes 吗？

如果使用 Kubernetes，维护集群的“负担”就落到了开发运维或基础设施工作人员的肩上。Kubernetes 适合每一家公司吗？不一定，如果你有三个微服务，或者公司达到一定规模，或许应该采用 Kubernetes。但如果实际情况很简单，采用 Kubernetes 的成本太高。

采用 Kubernetes 意味着拥有统一的开发体验，可以根据公司的成长进行调整。在有需要的时候，混合搭配使用，创建强大的自动化。还有自动扩展，如何按照正确的方式自动扩展服务？应该采用水平扩展，还是垂直扩展？服务应该通过开放连接进行扩展吗？也许你根本不需要自动扩展。

我喜欢 Kubernetes。非常喜欢。但无论遇到何种情况，我都会使用 Kubernetes 吗？不会，我会根据每家公司的实际情况综合考虑。Kubernetes 提供了许多开箱即用的好东西，可以推进业务的发展。但这是否意味着，所有服务都要放到 Kubernetes 上运行？当然不是。