Kubernetes Dashboard 在 EKS 1.26 升级后的故障排查与解决方案

问题背景

在将 Amazon EKS 集群从 1.24 版本升级到 1.26 版本后，用户遇到了 Kubernetes Dashboard 无法正常工作的问题。Dashboard Pod 处于 CrashLoopBackOff 状态，错误日志显示无法连接到 API 服务器。

初始错误分析

升级后 Dashboard 容器不断重启，主要报错信息为：

panic: Get "https://XXXXXX/api/v1/namespaces/kubernetes-dashboard/secrets/kubernetes-dashboard-csrf": dial tcp XXXXX: connect: no route to host

这表明 Dashboard 无法与 Kubernetes API 服务器建立连接，可能原因包括：

1. 网络策略变更导致 Pod 间通信受阻
2. 服务账户权限不足
3. API 服务器端点配置错误

解决方案探索

第一步：升级 Dashboard 版本

用户最初使用的是较旧的 Dashboard 6.0.8 版本，在升级到 7.10.0 版本后，Pod 能够正常运行，但出现了新的访问问题。

第二步：Ingress 配置问题

升级后 Dashboard 组件包括：

• kubernetes-dashboard-api
• kubernetes-dashboard-auth
• kubernetes-dashboard-kong
• kubernetes-dashboard-web

但 Ingress 资源未被创建，导致无法通过外部访问。检查发现用户的 values.yaml 配置中已启用 Ingress 并指定了 kong 作为 Ingress 控制器。

第三步：Kong 代理配置调整

最终解决方案涉及两个关键修改：

1. 启用 Kong 的 HTTP 代理：

kong:
  proxy:
    http:
      enabled: true

2. 调整 Ingress 资源配置，明确指定后端服务端口为 80：

spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: kubernetes-dashboard-kong-proxy
            port:
              number: 80

技术原理分析

在 Kubernetes 1.26 中，Ingress 资源的行为和 API 可能有变化，特别是与 Ingress 控制器交互的方式。Kong Ingress 控制器默认可能期望 HTTPS 后端，而 Dashboard 服务可能仅暴露 HTTP 端点。

通过强制 Kong 代理使用 HTTP 并明确指定 Ingress 到服务的 80 端口，确保了流量能够正确路由。这种配置在安全环境中可能需要额外的 TLS 终止配置。

最佳实践建议

1. 版本兼容性：升级集群时，应同步升级核心组件如 Dashboard 到兼容版本
2. 渐进式变更：分阶段测试网络连接性，先确保 Pod 间通信，再配置外部访问
3. 监控验证：升级后监控组件日志，及时发现连接性问题
4. 安全考虑：生产环境应考虑启用 HTTPS 并配置适当的网络策略

总结

EKS 升级到 1.26 后 Dashboard 的访问问题主要源于网络配置和组件版本兼容性。通过升级 Dashboard 版本并调整 Kong 代理配置，最终恢复了服务访问。这提醒我们在 Kubernetes 升级时需要全面考虑依赖组件的兼容性和网络配置的适配。