OpenYurt 1.4.0 边缘节点日志访问问题分析与解决方案

问题背景

在使用OpenYurt 1.4.0构建的7节点集群中，包含3个控制平面节点和4个边缘节点(edgebox)。在完成集群部署和网关配置后，尝试通过kubectl logs命令查看边缘节点上运行的Pod日志时，遇到了"ServiceUnavailable"错误。

错误现象

执行kubectl logs命令时，系统返回如下错误信息：

Error from server (ServiceUnavailable): the server is currently unable to handle the request (pods/log yurt-hub-edgebox2)

问题分析

通过对Raven Agent组件的日志分析，发现该问题与OpenYurt的网络连接机制有关。OpenYurt使用Raven组件来实现云边通信，其中包含两种类型的连接：

1. Tunnel类型：用于建立反向隧道连接
2. Proxy类型：用于代理请求

在正常情况下，这两种连接类型都应该显示为"activeEndpoints: true"状态。但在本案例中，虽然状态显示正常，但实际连接存在问题。

根本原因

深入排查后发现，问题出在云网关(cloud gateway)的配置上。具体表现为：

1. 云网关的Proxy类型配置中缺少公共IP地址
2. 这一缺失导致边缘节点无法正确建立与云端的通信通道
3. 由于通信通道不完整，kubectl logs请求无法正确路由到边缘节点

解决方案

通过以下步骤解决了该问题：

1. 修正云网关配置，确保Proxy类型包含正确的公共IP地址
2. 重启所有边缘节点上的Raven Agent组件
3. 验证所有连接状态恢复正常

完成这些操作后，不仅kubectl logs功能恢复正常，kubectl exec命令也能正常工作。

延伸问题：边缘服务超时

在解决日志访问问题后，还发现边缘节点上的服务存在超时问题。例如，Longhorn CSI驱动无法连接到后端服务，报错显示"context deadline exceeded"。

针对这个问题，采取了以下措施：

1. 为服务添加注解：openyurt.io/topologyKeys: openyurt.io/nodepool
2. 更新kube-system命名空间中的yurt-hub-cfg配置
3. 确保servicetopology配置包含正确的节点池信息

最佳实践建议

1. 部署OpenYurt集群时，务必仔细检查所有网关配置，特别是公共IP地址设置
2. 定期监控Raven Agent组件的日志，确保连接状态正常
3. 对于边缘服务，合理使用拓扑感知路由注解
4. 在yurt-hub-cfg配置中明确指定服务拓扑关系

总结

OpenYurt作为云边协同的Kubernetes发行版，其网络通信机制与传统Kubernetes有所不同。通过本案例的分析和解决过程，我们了解到在OpenYurt环境中，确保云边通信通道完整配置的重要性。同时，对于边缘服务，正确的拓扑配置也是保障服务可用性的关键因素。