OpenTelemetry Demo 项目中图片加载问题的排查与解决方案

问题现象描述

在部署 OpenTelemetry Demo 项目时，前端界面中的图片资源无法正常加载。具体表现为浏览器开发者工具中显示对图片资源的请求返回404状态码，而实际上这些图片文件确实存在于服务端的静态文件目录中。

环境配置

该问题出现在一个基于AWS EC2实例部署的Kubernetes集群环境中，使用Kubespray进行部署。集群配置包括：

• 控制平面节点：1个（Ubuntu 24.04 LTS）
• 工作节点：4个（Ubuntu 24.04 LTS）
• 网络插件：Calico
• 已安装组件：CoreDNS和NodeLocal DNS Cache

问题排查过程

初步观察

通过检查imageprovider pod的日志发现，虽然GET请求返回了200状态码，但前端仍然无法显示图片。日志示例如下：

10.233.97.17 - - [04/Dec/2024:07:39:17 +0000] "GET /Banner.png HTTP/1.1" 200 354115 "http://opentelemetry-demo-frontendproxy:8080/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/120.0.6099.28 Safari/537.36"

深入分析

1. 直接访问测试：在imageprovider pod内部使用curl直接请求图片资源可以成功获取，证明nginx配置正确，能够正常提供静态文件服务。

2. 前端访问路径：发现前端尝试通过/images/Banner.png路径访问图片资源，而实际上图片存储在/static目录下。

3. 服务暴露方式：最初通过NodePort方式暴露前端服务，但正确的做法应该是通过frontendproxy服务来访问。

根本原因

问题的核心在于服务暴露和请求路由的配置不当：

1. 错误的访问路径：前端代码中引用了/images路径，而实际资源存储在/static路径下。

2. 服务暴露方式错误：直接暴露前端服务而非frontendproxy服务，导致请求路由不正确。

解决方案

临时解决方案

使用kubectl port-forward命令正确转发frontendproxy服务而非前端服务：

kubectl port-forward svc/opentelemetry-demo-frontendproxy 8080:8080 -n otel-demo

生产环境推荐方案

在生产环境中，建议使用Ingress控制器来正确路由请求。以下是使用nginx ingress的配置示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: otel-demo-ingress
  namespace: otel-demo
spec:
  rules:
  - host: otel-demo.example.com
    http:
      paths:
        - pathType: Prefix
          path: "/"
          backend:
            service:
              name: opentelemetry-demo-frontendproxy
              port:
                number: 8080

经验总结

1. 理解服务架构：在OpenTelemetry Demo项目中，frontendproxy服务负责处理所有前端请求，包括静态资源的路由。

2. 正确的调试方法：当遇到资源加载问题时，应该：

   • 首先检查pod内部是否可以访问
   • 然后检查服务暴露方式是否正确
   • 最后检查前端代码中的资源引用路径

3. 生产环境部署：在测试环境可以使用port-forward快速验证，但在生产环境应该使用专业的Ingress控制器来管理访问路由。

通过这次问题排查，我们不仅解决了图片加载问题，更重要的是深入理解了OpenTelemetry Demo项目的服务架构和请求处理流程，这对后续的项目部署和维护都有重要参考价值。