云原生架构中Kubernetes可观察性的挑战

Posted 2021-04-23 K8S技术社区

Kubernetes是一个事实上的标准平台，用于编排容器化工作负载和微服务，它们是云原生应用程序的构建块。Kubernetes的工作负载是高度动态的、短暂的，并且部署在分布式和敏捷的基础设施上。Kubernetes管理云原生应用程序的好处很多，但新的可观察性挑战应运而生。

数据孤岛：传统的监控工具专门收集应用程序和基础设施层的指标。考虑到云原生应用程序的高度动态性、分布性和短暂性，这种指标收集方式会在孤岛中创建数据，这些数据需要在服务上下文中缝合在一起，以便使DevOps和SREs能够调试服务问题（例如响应时间慢、停机等）。此外，如果DevOps或服务所有者为观察添加新的指标，那么数据孤岛可能会导致交叉引用中断和数据误解，从而导致数据不对齐、通信速度减慢和分析不正确。

数据量和细粒度组件：Kubernetes部署有细粒度组件，如pod、容器和微服务，它们运行在分布式和短暂的基础设施之上。每一层都会生成大量的细粒度数据，如警报、日志和跟踪，而且这些数据量会随着服务的扩展而增长。数据越多，梳理出模式和调试问题就越困难。随着数据的增长，可观察性和故障排除变得更加困难。

Kubernetes抽象：Kubernetes抽象使得理解动态的、短暂的和分布式的基础设施发生了什么变得困难。对这些抽象进行解包就像剥洋葱（在容器、节点、网络和进程级别，有时甚至是套接字和包级别）来理解根本的问题。

鉴于Kubernetes微服务部署的复杂性和生成的大量数据，对Kubernetes环境中的应用程序进行故障排除是一项挑战。需要一种不同的方法来解决Kubernetes可观察性挑战。

Kubernetes可观察性的另一种方法

Kubernetes的声明性使得它非常容易实现可观察性。DevOps、SREs或服务所有者可以围绕他们想要如何保护和观察系统来声明高级语言构造，Kubernetes则可以负责实现。可观察性可以被视为代码，这样它就可以作为应用程序的一个组成部分连接起来，然后随着应用程序一起传输，这样它就可以在任何云、基础设施、网络或应用程序上运行。可观察性可以进一步改进，因为代码可以集成到CI/CD链中并向上游移动。这允许开发人员和软件工程师以适当的可观察性级别构建应用程序，以确保应用程序按预期工作。

为了进一步理解这一点，我们看一个简单的示例，它展示了代码的可观察性如何在Kubernetes环境中为云原生应用程序工作。

Online Boutique（以前称为Hipster Shop）是来自谷歌云的11层微服务演示应用程序。

其中一个微服务是ProductCatalogService，其目的是显示最新的目录（目录会随着新产品的可用性和现有产品库存的变化而变化）。Online Boutique部署后，相关的微服务（包括ProductCatalogService）将受到故障、超时和性能下降方面的监控。

使用传统的监控和故障排除方法，开发人员、DevOps和SREs在各自的数据孤岛中工作，分别为ProductCatalogService捕获数据，然后通过构建内部脚本或利用第三方软件将各自的数据相互关联。最初，在数据量较低的情况下，这是可能的，但这种方法不会随着业务的增长而扩展（因为需要更大的产品目录和/或业务逻辑）。由于应用程序使用Kubernetes作为临时的、分布式的和动态的基础设施来运行ProductCatalogService，Kubernetes抽象将使节点、容器、网络、进程和数据包级别的数据上下文变得困难。所有这些挑战加在一起将导致更长的故障排除时间，并在应用程序崩溃或性能下降时进行猜测。

DevOps或SREs可以采用另一种方法，可观察性即代码，利用Kubernetes原生抽象及其声明模型来正确观察ProductCatalogService。

apiVersion: projectcalico.org/v3

kind: PacketCapture

metadata:

name: productcatalogservice-pcap

namespace: onlineboutique

spec:

selector: app == "productcatalogservice"

destination:

   ports:

   - 80

protocol: TCP

以上是可观察性即代码的一个例子。在命名空间“onlineboutique”中创建一个作业“packetcapture pcap”，该作业选择并过滤标记为“app==productcatalogservice”的Kubernetes上运行的工作负载，并在端口80和TCP协议上执行数据包捕获。由于Packetcapture是Online Boutique 中ProductCatalogService的一部分，并且正在收集所有相关元数据，因此消除了数据孤岛和数据粒度问题。这种方法有以下好处：

1.由于应用程序和相关的微服务是由Kubernetes部署在短暂的分布式基础设施上的，因此代码中的标签和作业确保所有相关的上下文都为所有团队成员所用。这允许对流量有效负载进行简单的过滤和后续分析。

2.此示例可由不同的团队成员用于其他服务或在不同端口捕获数据包，或用于不同的协议。

3.与开发团队维护单元测试以确保其代码在构建时的质量一样，可以维护代码的可观察性（如本例中的代码），以确保各种相关人员（DevOps、SREs等）可以轻松地在运行时对应用程序进行故障排除。

如本例所示，数据孤岛、数据量和粒度组件以及Kubernetes抽象带来的可观察性挑战可以通过使用可观测性即代码方法来解决，该方法利用了Kubernetes的声明性特性。如果应用程序遇到性能、故障或超时问题，它会带来更快的故障排除和更短的解决问题时间。

原文链接：

https://thenewstack.io/kubernetes-observability-challenges-in-cloud-native-architecture/