Kubernetes 已经存在近 10 年了。在过去五年中，我们看到各种规模的工程团队的采用率急剧增加。从静态网站到成熟的微服务解决方案，部署标准化和跨类型的应用程序扩展的承诺推动了这种爆发式的增长。

Kubernetes 目前正处于“炒作周期”阶段。对于工程师来说，建议 Kubernetes 作为他们选择的平台是更容易接受的，无论他们使用的是云还是本地基础设施。我们已经看到实体零售店部署单节点 Kubernetes 集群来管理其收银系统，我们还看到电子商务网站在数百个数据中心部署数千个节点来管理正常运行时间。

毫无疑问，Kubernetes 势不可挡，但这股热潮消退之时，我们也会发现：Kubernetes留给我们的，即便不是一地鸡毛，也是分歧良多。

人们在宣传 Kubernetes，往往避不开这个话题：标准化。这个想法是，你运行的所有内容都可以容器化，使每个服务都具有标准形状，并具有标准连接器。

的确，Kubernetes 以标准化的方式解决了大规模部署软件的问题。但问题在于：它没有解决如何知道该软件是否正在做它应该做的事情。我们根本无法标准化了解某件事是否正在做该做的事情，因为不同的应用程序解决不同的问题。

我是一名应用工程师，而且，我是一名完全拥抱 DevOps 运动的应用工程师。我称其为一场运动，因为这对我来说就是如此。这不是一个新角色或新职责，也不是关于 CI/CD 管道或 IaC。对我来说，DevOps 就是与专家更密切地合作，他们为我编写的代码提供了超越本地计算机的生命力，并与他们合作以确保我的应用程序以最佳状态运行并快速到达用户手中。

这对我来说非常好，因为我开始了解他们面临的挑战，而且他们也开始看到我所面临的限制并可以提供解决方案。我们一起创建了用户想要的应用程序。

使用 Kubernetes，开发团队的运行速度如此之快，以至于他们没有注意到新的分歧正在悄然出现，当然这一次换了一个新名字：平台工程。现在，我们有 Kubernetes 管理员可以创建我们的集群，但他们对集群上运行的内容一无所知，因为我们已经标准化了容器周围的所有内容。

有人可能认为这很棒，因为现在应用程序（容器）和基础设施（集群）之间的界限更加清晰。但对此，我不同意。因为在我看来，工程师必须考虑部署、服务、sidecar、服务网格、节点、节点关联性——这样的例子不胜枚举。

你可以说，“但这不是他们应该担心的，这是平台的工作！” 但这恰恰证明上文我提到的观点：现在存在分歧。我们推动基础设施和应用工程师一起工作，深入了解彼此的世界并了解每个部分，以便我们可以向彼此提出明智的问题。现在我们说，“把它留给别人吧；” 他们知道自己在做什么”，这就是我们 10 年前的情况。当出现问题时，孤立的团队会互相指责。应用工程师现在可以说：“它在我的机器上运行，但在生产中停止运行，因此平台的工作就是修复它”，平台工程师可以指着他们的仪表板说一切正常。

不要误会我的意思。在这些团队之间进行良好的对话，并意识到沟通和接受他们需要不同的工具来完成各自的任务，才能让项目能够执行下去。平台工程师管理从自动扩展到网络路由的所有事务，应用工程师负责产品功能并确保客户获得最佳体验。

然而，我们看到的是，迁移到 Kubernetes 被视为结束。但第二天呢？一旦一切都在那里运行，我们就没有其他事可做了，对吗？我们不需要每年升级 Kubernetes，不是吗？

随着转向 Kubernetes，以及我们用来托管应用程序的基础设施（例如 Pod）的短暂性，我们用于监控和调试应用程序的方法失败了。我们正在采用在基础设施级别使用的方法，并将其应用于应用程序调试技术，因为现在一切都是标准化的，所以一切都是基础设施。这严重影响了在 Kubernetes 中构建的应用程序开发人员，以及希望为他们提供更多系统上下文的平台工程师的服务。

K8s在支持现代应用程序开发时，维护的方法同样需要进化。Kubernetes 并没有让我们的应用程序更易于观察，只是让它们更容易部署和迭代。这并不是一件坏事。

轻松更新应用程序、促进更多部署、进行红/绿部署和金丝雀的能力——这些都是伟大的事情，将提高应用程序工程师支持其应用程序的能力。它并没有让应用程序开发人员更轻松地调试他们的应用程序。最好的情况是，在 Kubernetes 成为首选部署系统之前，我们就处于这样的状态。最坏的情况是，我们引入了更多现在需要调查的故障点。

当我们处理的服务器数量固定时，我们会将每台服务器添加为应用程序指标中的一个维度。然后我们添加应用程序的版本号。从那里，我们可以深入了解哪个版本/哪个服务器有问题——或者是否所有服务器都有问题。服务器名称和应用程序版本的组合是低基数数据，非常适合时间序列聚合数据库。不过，我们现在所处的情况是 Pod 可以随时重新安排，从而导致可能使用新节点。对于每次部署，我们都有一个新的 Pod 名称，大多数时候，这都是高基数数据，传统的基于指标的系统很难处理。

正如我所说，用户并不关心您的基础设施。Pod只是Kubernetes中最小的资源管理组件，他们根本不关心 Pod 上的 CPU、网络带宽或者是否使用服务网格。他们不在乎每项服务是 1 个还是 10 个。他们只关心你的整个系统是否响应他们的请求。

我们所处的情况是，除非代码中有异常、HTTP 错误或其他类型的错误，否则很可能会将其作为基础设施问题推送给平台团队。任何与延迟相关的事情——或者对应用工程师来说没有意义的响应——都会被推给平台团队进行调查。此时，平台团队对应用程序的信息很少，只能根据粗粒度指标调查基础设施问题。再说一遍，我们处于孤立的团队中，彼此之间不交谈。

然而现实情况是，问题可能是 Pod，但也可能是代码。在此阶段，我们需要能够了解问题是否局限于单个基础设施组件（例如 Pod 或节点），或者是否影响到所有内容。这就是考虑高基数数据（例如 Pod 名称）对于应用程序遥测变得至关重要的地方。

这就是为什么需要弥合这一差距的原因。平台和应用工程师需要齐心协力。他们需要有关应用程序和基础设施的上下文、深层上下文数据。他们需要将以客户为中心的数据（例如由应用程序工程师定制的跟踪，以提供特定于其应用程序的上下文）与以基础设施为中心的数据（例如由平台团队管理的 Kubernetes 指标）相关联，以充分了解客户不满意的原因。

当企业完成向 Kubernetes 的迁移并进入运营模式时，他们需要当心：要避免孤立作战的方法。平台工程涉及应用工程师的支持以及他们如何共同为客户提供最佳服务。要提供流程、工具和文化，以便这些团队能够一起工作至关重要。它将确保不存在“我们和他们”的心态，从而导致糟糕的整体客户体验。

这是通过协作而不是控制来完成的。请记住：如果某个工具，必须通过命令使用，而不是人们自发想要使用它，则该工具可能存在问题。

要建立这些无缝协作的高绩效团队，你需要使用通用技术语言充当桥梁。使用 OpenTelemetry 等工具可以通过跟踪（以开发人员、以客户为中心）和指标（以平台基础设施为中心）提供联合思维，这将有所帮助。

平台工程团队和应用程序/产品工程团队一起才能提供最佳的客户体验，但这些关系是需要培养的，当然这不是免费的。

简而言之，Kubernetes 并不是让软件获得获更好性能的灵丹妙药，几个团队一起协作才是至关重要的。

作者 | Martin Thwaites

编译 | 言征（公众号：51CTO技术栈）