生产 Kubernetes

第 16 章 平台抽象 平台抽象

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

很多时候，我们看到企业在设计和构建 Kubernetes 平台时采用 "建好了就会来"的方法。 然而，这种理念通常充满风险，因为它往往无法满足将与平台互动的众多团队（如开发、信息安全、Network 等）的关键要求，导致返工和额外工作。重要的是，要让其他团队也参与进来，确保构建的平台符合目的。

在本章中，我们将介绍在为其他团队（特别是开发人员）设计 Kubernetes 平台的入职和使用体验时应考虑的一些角度。首先，我们将探讨一些哲学层面的问题，并提出这样一个问题：开发人员应该对 Kubernetes 了解多少？然后，我们将讨论如何为开发人员搭建一个平滑的阶梯，让他们能够开始部署到 Kubernetes 并自行部署集群。最后，我们将重温第 1 章中提到的复杂性范围，并看看我们可以设置的一些抽象层级。我们的目标是在向开发团队提供 Kubernetes 平台时，在复杂性和灵活性之间取得良好的平衡，因为开发团队对底层实施的了解和期望参与程度各不相同。

本章中的许多内容在书中其他地方也有涉及，我们将在适当的地方加以说明。在此，我们将从加强团队协作和建立一个满足组织中每个人需求的平台这一特定立场出发，对各方面进行阐述。虽然从表面上看，这似乎是一个轻松的话题，但其中讨论的问题往往是许多公司最难克服的障碍，也可能决定能否成功采用基于 Kubernetes 的应用平台。

平台曝光

我们在本书中多次谈到，在设计和实施 Kubernetes 平台时，需要评估个人需求并在不同领域提出问题。 一个会影响许多选择的主要问题是，决定你希望开发团队在多大程度上接触底层 Kubernetes 系统和资源。有几个因素会影响这一决定。

Kubernetes 是一项相对较新的技术。在某些情况下，采用 Kubernetes 的动力来自基础设施方面，目的是简化基础设施的使用和效率，或使工作负载标准化。在其他情况下，推动采用 Kubernetes 的动力可能来自开发团队，他们热衷于实施一种新技术，认为这种技术可以适应并加快云本地应用程序的开发和部署。无论驱动力来自哪里，其他团队都会感受到影响，无论是适应新模式、学习新工具，还是与新平台交互时用户体验的改变。

有些企业强烈要求开发团队不接触底层平台。这样做的原因是，他们认为开发人员应该专注于提供业务价值，而不应被正在开发的平台的实施细节所干扰。这种方法有一定的价值，但根据我们的经验，我们并不总是完全赞同。例如，开发人员至少需要对基础平台有一定的了解，才能有效地开发针对基础平台的应用程序。这并不意味着增加应用程序与平台的耦合度，而纯粹是指了解如何最大限度地发挥平台的功能。第 14 章将详细介绍应用程序与平台之间的关系。

要使不接触开发人员的方法取得成功，平台团队必须具备足够的能力。首先是因为他们将完全负责维护和支持环境，其次，该团队还将负责构建开发人员与平台无缝交互所需的必要抽象。这一点非常重要，因为即使开发人员不直接接触 Kubernetes，他们仍然需要分析应用性能、调试问题和排除故障的方法。如果让开发人员kubectl 访问集群会暴露过多的底层细节，那么就需要有一个中间层，让开发人员能够将应用投入生产，同时又不会因为实施细节而不知所措。在第 9 章中，我们将介绍许多以有效方式向开发团队展示调试工具的主要方法。

在某些组织中，仅仅简化开发人员的故障排除体验可能还不够。将应用程序部署到 Kubernetes ...