Kubernetes的需求层次

本文翻译自《The Kubernetes Hierarchy of Needs》。

在我的职业生涯中，我很幸运能够与硅谷的一些最聪明的人和最前沿的公司一起工作。在过去的几年里，Kubernetes一直主导着我的客户。我认识的大多数工程师都在努力开展Kubernetes项目，成为这次技术潮流运动的一部分，以提高其市场价值。但是，即使采用Kubernetes这种疯狂的冲动，我也目睹了许多这些项目远未实现其最初目标。

事实是Kubernetes很复杂。生态系统正在迅速发展。这导致许多团队将重点转移到技术堆栈上。团队最终讨论每个单独的组件和/或CNCF项目，而不是将产品交付给他们的客户并根据反馈进行迭代。

在所有这些失败中，模式已经开始从成功的Kubernetes部署中出现 - 更具体地说，这些公司用于从白板到生产的想法。我已将这些知识整合到我称之为“Kubernetes需求层次”的内容中。

Kubernetes需求层次并不专注于单个技术组件，它是一个程序系统，使团队专注于客户可交付成果并协调一致以实现业务成功。其目的是在不断变化的基础技术领域上保持一层，在这一层大家专注于确定需要解决的问题，以便部署Kubernetes并编写代码，释放到生产环境。

Kubernetes需求层次由三个连续阶段组成：构建，部署，运维。这个序列对于驱动力的增强绝对至关重要。在每个阶段，您的客户必须验证最小可行产品（或可证明的功能），然后再进入下一阶段。这完成了三件事：

• 作为强制功能，专注于可交付成果与个别技术。
• 通过实现定义明确的里程碑，为企业和客户提供支持。
• 在您的团队和关键利益相关者之间创建明确的期望，从而产生必要的反馈循环，以推动进度和效率。

让我们更详细地看一下层次结构的每个阶段。

构建基础架构：您必须部署Kubernetes。这不仅是展示进步的第一个里程碑，而且还为您提供了如何操作和与系统交互的第一个真实体验。您和您的团队将学习命名法，建立您在部署阶段需要与之相关的可信度，并教授将加入的开发人员。此时，您是选择部署原生Kubernetes还是像GKE这样的托管服务并不重要。这一切都是为了进入一个可以加入服务的状态。

很多时候，我看到开发人员在建立他们的Kubernetes环境之前尝试回答后期问题。“我应该与Istio合作吗？我们如何跨数据中心的集群提供服务发现？“处理这些问题会带来不必要的复杂性。

请记住，这个阶段就是提供一个可用的集群，并展示您的团队对其组件的掌握程度。您这样做的速度越快，团队的可信度就越高，您的客户就越想与您合作。

部署应用程序：这是您开始考虑客户如何在平台上配置应用程序的地方。在构建任何内容之前，请与您的客户一起定义基本要求。然后建立规范。

例如，如果它是一个12因素的无状态应用程序，则无需立即提供存储持久性解决方案。而不是关注如何解决租赁问题，首先要说明用户如何与API进行交互并推送代码。一旦您了解了应用程序的生命周期和客户的能力，CI/CD管道就会变得相关。

令人惊讶的是，在许多情况下，应用程序团队在转换到Kubernetes时首次体验微服务。这对您和您的团队来说是一个巨大的机会，可以作为指导。保持技术简单，使这个过程更容易调试和优化。不要强制执行可能会创建其他学习曲线的流程或工具使用。

如果您的客户不愿意与您合作，他们将放弃该平台，影响您的团队品牌以及您招募其他内部客户的能力。

运维：恭喜！您的用户现在可以自由地推送代码，并且对他们可以实验和实施更改的速度感到发狂。而且您一直很聪明地了解您加入平台的人员，确保您的团队了解客户需求，只考虑适合现有平台功能和规模的应用程序。

不幸的是，你的工作尚未完成。您现在正在经历第一手微服务的缺点。如果您的团队组织得像我与之合作过的大多数人一样，那么核心架构师和SRE会随时待命，因为每一个警报都会出现在PagerDuty上。您发现大多数这些基于指标的警报已不再相关。它们由他们依赖的其他服务触发。更不用说，对于SLO来说，这是狂野的西部，你将与应用团队携手合作来定义它们。在事件发生期间，您会发现很多挫折感只是找到每个服务的自定义仪表板来验证SLI。最终的结果将是你曾经参与过的一些最大的战争室。

不要让这件事发生在你身上。在这里，您需要确定事件响应的优先级并建立SLO。与您的客户合作，清楚地了解客户如何监控他们的应用，哪些工作流程最重要，以及他们是否有相关（且准确）的SLO。您的团队将不再能够成为每项服务的细微差别和失败模式的专家。

有成熟的技术和CNCF项目用于记录和获取指标，两者在这些环境中仍然发挥着重要作用。由于能够提供端到端可见性，依赖性图表和性能分析，因此跟踪在微服务监控方面也获得了很大的动力。我与之合作过的最好的客户设计了可观察性数据管道和最佳实践，使服务所有者能够构建性能更高，更具弹性的应用程序。您实际上可能确定您只负责监控基础架构。这也没关系，但要确保期望从大门出发。

这让我回到最初带给我们的地方。有一个商业原因首先资助了这个项目。在一天结束时，它是关于更快地提供客户体验。

从业务方面考虑一下。当贵公司决定发布新产品时，它们会根据客户要求而定。这些要求推动了它们提供的功能的优先级。对于将在何时提供的内容有一个共同的理解，并且客户反馈和采用会告知接下来会发生什么。早期的产品采用推动了持续的投资和产品的发展。以同样的方式对待您的平台。使用Kubernetes Hierarchy of Needs来保持以客户为中心，并提供一个能够提供真正客户价值的平台。

译者注： 《Kubernetes实战：高可用集群搭建,配置,运维与应用》这门实战课可以帮助你和你的客户顺利度过这三个阶段，进而可以深入的走入Kubernetes的世界！

讲师主页：tonybai_cn
讲师博客: Tony Bai
实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》
免费课：《Kubernetes基础：开启云原生之门》