对于Kubernetes的迷思

在过去的 10 年里，通过我的咨询工作，我有机会了解到很多公司的基础设施和系统架构。在许多企业中，Kubernetes 和 Apache Kafka 已经变得非常普遍和流行，但这往往不是为了发展更好。

Kubernetes 和 Kafka：梦之队还是恐怖秀？

有一天，我认识了几年的一家中型软件公司的 CEO 给我打电话寻求建议。他们的 SaaS 产品运行良好，并在过去几十年中做的很成功，获得了可观的收益。他们成功地从一款面向 Windows 的桌面软件产品过渡到了具有现代事件驱动微服务架构的先进 Web-based SaaS 产品。

他自己在 90 年代中期编写了最初的产品，但随着时间的推移，他对技术的发展有些失去了了解。尽管如此，他认为产品看起来很不错，并解释说它似乎是一个架构良好、专业的产品。说实话，我对他为什么找我有些困惑。

我问他：“怎么了？你为什么找我做咨询？” 那些对开发、基础设施和系统不太了解的高级主管通常会凭直觉感觉到，事情似乎没有朝着正确的方向发展。在许多情况下，他们只是希望我对他们的系统、基础设施以及产品开发方式进行审查，并希望得到一些外部的确认。

我查看了我的日程，安排了一天的时间与他、他的产品和开发团队进行面谈。我很确定这只是一天的面谈、技术讨论，然后为他撰写一份有 5 页内容的最终报告。

管理层开始有了直观感受

我到达的那天，他在办公室里迎接我，我们在喝咖啡时进行了简短的交谈。这时，我第一次听到他希望我审查他的团队正在做的事情的实际原因。他的公司每年的营业额达到百万欧元的中等收入，开发和运维预算大约占总收入的 10%，不包括员工成本。利润率都不错，运营成本仍在可接受的范围内。经过一些闲聊，他终于告诉我他为什么希望我前来审查他的产品团队。

“我们的可用性只有 87%，而我们的服务级别协议规定为 95%，我在下一个财年的运维预算中额外拨款了 50 万欧元。目前我们还没有收到客户投诉，但我对我们的服务质量和运维成本的上升感到担忧。请帮忙看看在服务质量和运维成本方面是否有改进的空间。”

对于这样一家规模较小的公司来说，额外投资 50 万欧元是一个巨大的决定，我理解他为什么希望听取其他人的意见。此外，87% 的可用性非常糟糕，即使在 2019 年也是如此。87% 意味着他们至少有 40 天的停机时间。即使他们的服务级别协议达到了 95%，仍然意味着至少有两周的停机时间。SaaS 在一年内的服务级别协议大多在 97-99% 之间。即使是 97%，也相当于 11 天的停机时间。

为什么选择 Kubernetes 和 Kafka？

他的公司没有庞大的管理层，他自己拥有并经营着这家企业。他有一些运维人员、开发人员、产品和研发经理。他们在现代化应用程序时使用了一个大型代码仓库托管服务，并使用 Jenkins 作为他们的持续集成/持续交付（CI/CD）流水线，将每个微服务部署到一个 Kubernetes 集群中。微服务之间的通信通过 Kafka 实现。

作为咨询顾问，我会在得出结论之前收集信息。因此，我了解了团队选择 Kubernetes 和 Kafka 的原因。他们的原因很简单：在现代化应用程序时，他们请了一位顾问来设计他们的基础架构，其中包括使用 Kubernetes 来运行重构和现代化的应用程序，并通过 Kafka 进行消息传递。

他们的团队非常开放，我获得了所有的统计数据。他们在努力维持系统和基础设施的正常运行，并对我能提供的任何指导表示感激。这是我了解中型企业时常见的情况。他们总是面临资源限制，难以招募到足够的人员。招聘时，他们总是难以与大型科技巨头竞争。

当初起草现代化和迁移计划的顾问早已离职，公司对于对重新聘请他回来似乎并不感兴趣。运维和工程团队的成员对他们的 Kubernetes 和 Kafka 配置并没有过多的热情。在与团队共进午餐时，一位运维人员问我，是否可以彻底抛弃这些技术，是否有更简单的替代方案。

考虑到他们的吞吐量和资源利用情况，他们几乎不会触及 AWS 提供的无服务器方案的服务限制。他们甚至不会超过 AWS SNS 每秒 200 条消息的限制，更不用说达到 AWS SQS 队列的限制了。他们使用 Kafka 的功能都可以通过 SNS 或 SQS 来实现。甚至不需要流式数据，因此无需考虑 AWS Kinesis 作为替代方案。

由于他们已经在 AWS 上运行了 Kubernetes 和 Kafka，他们可以轻松迁移到无服务器方案（如 Lambda、API Gateway、SQS、SNS），并且在基础设施费用方面也有很大的成本降低空间。但是，明显的问题是他们在 Kubernetes 集群的运维上花费了大量时间，而不是云基础设施本身的成本。

与云无关的集群混乱

我不喜欢责怪和指责那些不再参与的决策和人员。选择 Kubernetes 和 Kafka 有其合理的原因。在审查了所有项目文档之后，选择 Kubernetes 和 Kafka 的主要原因是 “与云无关”。在当时的某个时期，有人决定最好 “不依赖任何云提供商”。我还有一种感觉，风险是 CEO 脑海中的一个考虑因素。

演示时间到了！我有一份用于这类情况的无服务器迁移的蓝图演示文稿。我进行了一次演示，解释了团队如何逐步迁移到 AWS 的无服务器方案，以及他们如何接受 AWS、SAM 和 CloudFormation 的培训。

更重要的是，我提出了一份风险缓解的路线图，概述了可能发生的，尽管非常不太可能的转向 Google Cloud、Azure 或 OpenShift 的情况。我的蓝图甚至提供了完全的 “灾难撤退至自建环境” 的选择。尽管撤退到自建环境的选项听起来有些荒谬，但通常能减轻大部分担忧。

最终，我成功说服了团队和管理层逐步采用无服务器方案。我还说服他们将他们已经为代码仓库托管服务付费的 CI/CD 流水线取代他们的 Jenkins。我们达成了一致，我将在几周后回来，查看事情的进展情况。

在我离开他们的办公室之后的几个月里（实际上我只呆了一天！），他们只偶尔向我咨询一些问题，问题很少，以至于我甚至没有向他们收费。最终，我只收取了最初的咨询费用，因为我熟识该公司的 CEO，所以我没有对我们后来的短暂交流收费。

我偶尔询问他们是否需要我亲自前往，但他们拒绝了，称一切都还好。我的咨询业务并不是我的主要职业，我主要从事软件开发工作，所以我并不追求尽可能多的收费小时数。大约在我访问之后的 7 个月，他们邀请我对他们已经构建和迁移的系统进行一次架构审查。

我再次前往他们的办公室，进行了一整天的会议。我们基本上沿着架构图逐步审查了他们迄今为止所构建的内容。说实话，并没有太多令人惊讶的地方：微服务结构配合 API Gateway 和 Lambda，使用 SNS 的中央服务总线，以及一些使用 SQS 的分发架构。还有一些 DynamoDB 表和 S3 存储桶。这些人知道他们在做什么，除了点头表示认同，我几乎没有什么可做的事情了。

99.99% 的可用性和约 40% 的成本降低

从技术角度来看，他们的产品并不具备高度复杂性。他们产品的优势在于与特定行业中客户的现有生态系统紧密集成。他们还使用一些非常出色的功能，完全自动化了客户的高度专业化业务流程。

总体而言，他们的产品涉及网页前端、表单、数据库、PDF 文件、API、Webhooks 等，并没有太多其他复杂的内容。其中最 “复杂” 的系统可能是关系型数据库和搜索引擎。对于普通的运维经理来说，这些并不会让他们过于担心。

毫不奇怪，由于他们的大部分基础设施运维已经外包给了亚马逊，他们的可用性显著提高。他们通过迁移出 Kubernetes 的服务，成功削减了云计算费用，因为这些服务不再需要持续运行，而是按需调用。我们甚至从未讨论过与 AWS Lambda 的冷启动时间有关的问题。

他们正在深入进行他们的 AWS 云之旅，其中一些人考虑获得 AWS 认证，我感觉到他们在开始迁移到 AWS 的原生无服务器服务后，总体上更加平静、轻松和快乐。在现场的仅仅一天时间里，我的工作似乎已经完成得差不多了。

像这样的挑战只是 CEO 和管理团队每天面临的数百个挑战之一。当你从事咨询工作时，你知道几乎不会得到感谢。他们对你的感谢就是将款项汇入你的企业账户，也许会给你一个推荐。就是这样。

我不认为运维和开发团队知道他们离 CEO 说 “我需要通过人力资源来解决这个问题” 有多近。通常情况下，高级管理人员在无法理解技术挑战时，会将问题解决归结为人力资源的问题，作为最后的手段。这意味着管理人员试图通过替换围绕问题的一些人员来解决问题。

这是 Kubernetes 和 Kafka 的错吗？

从技术角度来看，Kubernetes 和 Kafka 并没有任何问题，但它们已经成为一个经济问题。尽管从技术上来说，它们是非常出色的解决方案，但这家企业既没有足够的人力资源，也没有财力资源来运维 Kubernetes 和 Kafka。而且，实际上，他们没有任何有效的经济理由来运维这些系统。

回过头来看，这真是浪费金钱。当企业，更具体地说，内部的人员最初决定选择 Kubernetes 和 Kafka 时，他们没有与其他选择（如 AWS、Google Cloud 或 Azure 上的无服务器方案）进行 TCO（总体拥有成本）的比较。

为什么 Kubernetes 可能让你丢掉工作

Kubernetes 不是一种玩具。运维一个 Kubernetes 集群需要人力、时间和预算。在我参与的大多数业务案例计算中，无论是从经济角度还是与 Serverless 或多 AZ 部署的负载均衡器相比，Kubernetes 始终处于劣势。我们谈论的不仅仅是小差距。

无论你的技术水平有多高，如果 Kubernetes 集群的 TCO 比下一个最佳替代方案高出 2-4 倍，你将会陷入麻烦。随着越来越多的公司转向 FaaS（函数即服务），只需进行尽职调查或技术审计，你就必须解释为什么你选择运行 Kubernetes 集群。当管理层看到其他公司的基准测试时，“其他人都这样做” 这样的论点并不具有说服力。

结果可能是你的管理层会将 Kubernetes 集群或昂贵的 Kafka 环境归咎于你。我的建议是：积极主动地将你的 Kubernetes 和 / 或 Kafka 集群的 TCO 与 AWS、Google Cloud、Azure 或 IBM/Red Hat 上的无服务器方案进行比较。评估你是否需要 Kubernetes 和/或 Kafka，以及为什么没有合理的替代方案。

当你在简历上写拥有 Kafka 和 Kubernetes 的经验时，看起来无疑很好，但如果你能通过放弃它们来节省 50 万欧元的费用，那就更加出色了。雇主投入到过重的基础设施和系统中的每一分钱，都是他们无法花在你身上、你的培训和下一次薪资增加上的一分钱。

你更有可能因为降低成本、提高服务质量和上市时间而获得奖励，而不是因为拥有一个壮观的 Kafka 或 Kubernetes 集群。我还没有遇到过一个会对 Kubernetes 集群印象深刻的 CEO。

你有什么经验？你是否在大规模运行 Kubernetes 集群，它们在经济上与 Serverless 相比如何？你是否曾经成为 Kubernetes 炒作的受害者？