一文搞懂基于 OpenTelemetry 进行 Kubernetes 全链路观测

2023-09-25 微信公众号 Kubernetes

Hello folks，我是 Luga，今天我们来聊一下云原生生态核心技术—— 可观测性，即 “基于 OpenTelemetry 进行 Kube.NETes 全链路观测” 。

一、基于 OpenTelemetry 彻底改变我们的观测意识

随着组织越来越多地采用 Kubernetes 来部署和管理应用程序，Kubernetes 已成为事实上的容器编排标准。在这样的动态 Kubernetes 环境中，观测资源对于确保平台上运行的应用程序的健康至关重要。

然而，动态的 Kubernetes 环境给观测带来了很大的复杂性。应用程序不断地进行扩展、部署和更新，传统的依赖代理或轮询的监控技术无法满足 Kubernetes 环境的需求，因为它们无法跟上环境变化的速度和分布式架构的复杂性。

如果无法及时提供实时观测功能，将导致平均解决时间(MTTR)的增加。这将显著影响应用程序的整体可用性和性能，对业务本身产生负面影响。

为了克服传统监控解决方案的这些缺点，技术团队依靠使用 OpenTelemetry 的创新方法来观测 Kubernetes 环境。通过采用 OpenTelemetry，我们可以使用标准化的方法来收集、处理和导出遥测数据。

OpenTelemetry 提供了一套统一的 API 和工具，使得在 Kubernetes 环境中收集和处理遥测数据变得更加简单和一致。它支持跨语言和跨平台，可以与不同的组件和工具集成。这使得管理员能够实时监测应用程序的性能指标、日志和跟踪数据，并使用可视化工具进行分析和故障排除。

通过 OpenTelemetry，技术团队可以更好地了解 Kubernetes 环境中应用程序的行为和性能，快速识别和解决潜在的问题。这将有助于减少 MTTR，提高应用程序的可用性，并确保业务能够正常运行。

二、当前观测 Kubernetes 所面临的挑战

传统观测 Kubernetes 环境面临一些挑战，这些挑战可能限制组织对其应用程序和基础设施的完整可见性和细粒度控制。

复杂性：Kubernetes 是一个高度复杂的容器编排平台，由多个组件和服务组成。传统的观测方法可能无法有效应对这种复杂性，导致难以收集和分析相关的监控数据。
动态性：Kubernetes 环境中的应用程序和资源拓扑通常是动态变化的，包括 Pod 的创建、删除、缩放等操作。传统观测方法可能无法及时跟踪这些变化，导致监控数据的准确性和一致性受到影响。
高度分布式：Kubernetes 环境中的应用程序通常是分布式的，由多个容器和服务组成。传统的观测方法可能无法提供对分布式系统的全面可见性，导致难以追踪和分析应用程序的端到端性能和依赖关系。
多样性：Kubernetes 生态系统中存在多种不同的组件和工具，用于不同的观测需求，例如 Prometheus、Grafana、ELK 堆栈等。组织可能需要整合和管理这些不同的工具，以获得全面的观测能力。
弹性和可扩展性：Kubernetes 环境的弹性和可扩展性使得应用程序的规模和负载模式可能随时发生变化。传统观测方法可能无法有效应对这种变化，导致监控数据的准确性和时效性受到影响。

面对这些挑战，组织需要采用更先进的观测方法和工具，如 OpenTelemetry，以应对 Kubernetes 环境的复杂性和动态性，提供更全面和准确的观测能力。这样可以帮助组织更好地理解和管理其应用程序和基础设施，提高性能和可用性，并加快故障排除和问题解决的速度。

OpenTelemetry 提供了一种方法，可以从应用程序和 Kubernetes 环境中收集这些观测参数，包括轻松实现分布式跟踪。这使得组织能够快速识别和诊断问题，从而提高故障排除的效率。

通过 OpenTelemetry，组织可以获得更全面的可见性，了解应用程序的各个组件之间的相互依赖关系和性能表现。它提供了一种标准化的方式来收集和传输监控数据，使组织能够深入了解应用程序的运行状况，并快速响应潜在的问题。

因此，使用 OpenTelemetry 可以帮助组织克服传统观测方法的局限性，提供更全面、细粒度的观测能力，从而提高对分布式应用程序的理解和故障诊断能力。

三、揭秘 OpenTelemetry 在观测 Kubernetes 中的关键作用

尽管有多种方法可以对 Kubernetes 进行观测，但与传统的观测选项相比，使用 OpenTelemetry 提供了更多的优势。然而，如果完全忽视对业务应用程序的观测，可能会对其性能和可用性产生严重而可怕的影响。

忽视观测意味着组织将无法准确地了解应用程序的运行状况和健康状态。没有及时的观测数据，组织将无法获得关键的指标和指示器，以评估应用程序的性能表现和资源利用情况。这将使组织难以发现潜在的性能瓶颈、资源争用或其他可能导致应用程序性能下降和可用性问题的因素。

而同时，缺乏观测将导致组织拥有更长的平均解决时间(MTTR)，因为组织将没有必要的指标来有效和高效地识别应用程序中问题的根本原因。通过监控 Kubernetes Cluster 中的关键组件，可以显著降低 MTTR。

组织可能会在没有充分观测其 Kubernetes 环境的情况下遇到一些问题，例如 Kubernetes Pod 崩溃循环、持续的卷故障和作业故障。所有这些问题都会导致 Kubernetes 环境和在这些资源上运行的应用程序出现严重的停机时间和性能问题。

另一个需要通过充分观测来改进的关键方面是识别应用程序的分布式组件和运行这些服务的基础设施之间的依赖关系所需的端到端可见性。如果对应用程序的整体情况缺乏了解，组织就无法对可能出现的问题进行分析和深入研究，从而增加了缩小根本原因和减少平均解决时间(MTTR)的复杂性。

观测还为异常检测奠定了基础，这允许组织识别与应用程序正常操作不符的行为。这一点在尝试解决可能影响应用程序性能的异常时变得尤为重要。

OpenTelemetry 提供的额外好处确保了观测实施不当造成的挑战最小化，团队可以通过解决 MTTR 时间增加、可见性有限等问题来充分利用这些功能。因此，使用 OpenTelemetry 观测 Kubernetes 是至关重要的。

四、最佳实践：确定关键观测目标

在收集和分析来自 Kubernetes 环境的指标时，有一些关键指标需要考虑。以下内容提供了组织所需收集的关键指标的良好基础知识。

1.Node 指标

此指标提供有关各个 Kubernetes Cluster节点性能和资源使用情况的详细信息，包括 CPU、内存和网络使用情况。通过监测节点指标，可以了解到节点的负载状况，发现资源瓶颈并进行容量规划。

2.Pod 指标

此指标提供有关在节点上运行的 Pod 资源使用和操作的信息，包括 CPU、内存和网络使用情况。通过监测 Pod 指标，可以了解到每个 Pod 的资源消耗情况，识别资源密集型的 Pod 并进行优化。

3.Container 指标

此指标提供有关 Pod 中运行的各个容器性能和资源使用情况的详细信息，包括 CPU、内存和网络使用情况。通过监测容器指标，可以深入了解每个容器的资源消耗情况，找到资源泄漏或不良配置的容器并进行调整。

4.API Server 指标

此指标包括请求延迟、响应时间和错误率，提供有关 Kubernetes API 服务器功能和可用性的详细信息。通过监测 API 服务器指标，可以了解API服务器的性能状况，识别潜在的性能瓶颈和故障情况。

5.Etcd 指标

此指标包括磁盘使用情况、响应时间和错误率，提供有关 Etcd Cluster 操作和状态的详细信息。通过监测 Etcd 指标，可以了解 Etcd Cluster 的健康状况、性能瓶颈和故障情况。

通过收集和分析这些关键指标，组织可以获得关于 Kubernetes 环境中 Node、Pod、Container、API Server 和 Etcd Cluster 的详细信息。这将帮助组织实时监测和优化 Cluster 性能，提高应用程序的可靠性和性能。

五、基于 OpenTelemetry 进行 Kubernetes 的解决方案

在 Kubernetes 上部署一个 OpenTelemetry 收集器，这个收集器将负责接收和处理跟踪数据。一旦部署完成，我们可以使用 OpenTelemetry 提供的 OTEL 检测库(基于 Go 语言编写的应用程序)将跟踪数据发送到收集器。

一旦跟踪数据到达收集器，它将被传送到 Jaeger 收集器，进一步处理和存储。最后，我们可以使用 Jaeger 的用户界面(UI)来可视化这些跟踪数据，以便更好地理解应用程序的性能和行为。

下面的图示展示了这个流程，包括应用程序、OpenTelemetry 收集器和 Jaeger 之间的交互，以及跟踪数据的流动路径。具体可参考：

在此方案中，我们的 OTEL 设置如下所示：

在实际的业务场景中，OpenTelemetry 可与 Kubernetes 结合使用，从 Kubernetes Cluster 上运行的容器化应用程序收集遥测数据。OpenTelemetry 提供了多个 Kubernetes 特定的组件和集成，使我们可以轻松地在 Kubernetes 环境中收集和处理遥测数据。

这些包括：

1.Kubernetes 特定的工具

Kubernetes API 服务器、Etcd、Kubelet 等。这些仪器可用于生成用于 Pod 创建、删除和扩展等操作的遥测数据。

2.Kubernetes 元数据注入

自动将 Kubernetes 特定的元数据(例如 Pod 名称、Pod 命名空间和容器 ID)注入到遥测数据中。这样可以更轻松地将遥测数据与 Kubernetes 特定的元数据关联起来，并诊断与容器化应用程序相关的问题。

3.Kubernetes 感知采样

根据 Kubernetes 特定的元数据(例如 Pod 名称、命名空间或服务名称)采样遥测数据。这有助于减少发送到后端的遥测数据量并提高性能。

4.Kubernetes 部署

OpenTelemetry 可以部署为 Kubernetes 部署或守护进程集，从而可以轻松在 Kubernetes 环境中扩展和管理 OpenTelemetry 组件。

通过基于 OpenTelemetry 的 Kubernetes 解决方案，我们可以实现对 Kubernetes Cluster 中应用程序的端到端监测和可观察性，从而帮助我们更好地理解应用程序的性能、排查问题，并采取适当的优化措施，以提高应用程序的可靠性和性能。

六、实施 OpenTelemetry 的核心步骤

通过实施 OpenTelemetry 来观测 Kubernetes 环境，团队组织可以收集和分析各种指标，并将这些指标与从应用程序的不同部分收集的其他指标相关联，以更好地了解整体应用程序的性能。

在实际的业务场景中，如下是正确实施 OpenTelemetry 来观测 Kubernetes 环境的四个易于遵循的核心步骤，具体可参考：

1.安装 OpenTelemetry Collector

首先，我们需要正确安装 OpenTelemetry Collector。Collector 是用于接收、处理和导出遥测数据的组件。我们可以根据官方文档提供的指南，在 Kubernetes Cluster 上安装和配置 Collector。

在 Kubernetes Cluster 中，可以将 OpenTelemetry 代理配置为一个 DaemonSet，以确保代理在 Cluster 中的每个节点上都能运行。通过以下命令可以安装代理：

[leonli@LugaLab ~ ] % kubectl Apply -f https://Github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

当然，这里，我们还可以使用 Helm Charts 进行安装：https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator

2.配置 OpenTelemetry Collector

一旦安装了 Collector，我们需要配置它以收集所需的指标和数据。配置文件可以指定要收集的指标类型、导出器(用于将数据发送到后端)以及其他特定的收集器设置。通过仔细配置 Collector，我们可以根据组织的需求来定制数据收集和导出。

OTel 支持多种后端，包括 Prometheus、Jaeger 和 Zipkin。具体配置可参考如下示例：

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  prometheus:
    endpoint: "localhost:4444"
  jaeger:
    endpoint: "http://jaeger:14268/api/traces"
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [jaeger, prometheus]

3.在 Kubernetes 应用程序中启用 OpenTelemetry 检测

为了在 Kubernetes 应用程序中启用 OpenTelemetry 检测，我们通常需要在应用程序代码中添加 OpenTelemetry SDK。SDK 提供了用于在应用程序中插入代码以收集指标、跟踪请求和记录日志的 API。通过在应用程序中使用 OpenTelemetry SDK，我们可以捕获关键的性能数据和上下文信息。

4.将数据发送到首选的后端

最后一步，我们需要配置 OpenTelemetry Collector 将收集到的数据发送到所首选的后端。后端可以是各种数据存储和分析平台，如 Prometheus、Grafana、Jaeger 等。根据我们的需求和环境，选择合适的后端，并配置收集器以将数据导出到该后端。

这里，以 Jaeger 后端为例，它提供了各种可视化选项，使我们可以轻松理解 Kubernetes Cluster 中的请求流，并支持各种跟踪格式，包括 OTel 等，具体可参考如下所示：

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: allInOne
  allInOne:
    image: jaegertracing/all-in-one:latest
    options:
      log-level: debug

在确保基于 Kubernetes 的应用程序的性能、可靠性和可用性方面，观测 Kubernetes 是至关重要的。OpenTelemetry 为观测 Kubernetes 环境提供了一个强大的框架，利用分布式跟踪、指标和日志记录等功能。

通过遵循最佳实践并利用适当的工具，如 OpenTelemetry 和其他工具，我们可以实时了解 Kubernetes Cluster 的状态，从而提升应用程序的性能。

随着 Kubernetes 的广泛应用，强大的观测策略比以往任何时候都更为重要。通过实施 OpenTelemetry 和其他监控工具，您可以避免潜在问题，并确保 Kubernetes 环境的平稳运行。

这些监控工具可以帮助我们收集和分析关键的指标、跟踪请求的路径，并记录关键事件和日志。通过实时观测 Kubernetes Cluster，我们可以及时发现潜在的问题，追踪性能瓶颈，并采取适当的措施来优化和调整应用程序。

总而言之，通过实施 OpenTelemetry 及其他类似观测工具，我们可以建立强大的观测策略，从而确保基于 Kubernetes 的应用程序的性能和可靠性。这样，我们将能够及时发现和解决问题，提高应用程序的可用性，并为用户提供更好的体验。