为什么K8s Ingress在Minikube正常，远程集群访问返回HTTP 404？

从你给出的kubectl get ingress结果对比就能定位最核心的问题：

• 正常可访问的主应用Ingress条目被分配了公网IP 37.44.1.172
• helper服务对应的Ingress条目ADDRESS列完全为空，说明集群的入口Ingress控制器根本没有加载这条Ingress规则
• 你之前尝试修改Traefik相关注解完全无效，因为你收到的是Nginx格式的404响应，说明集群入口是Nginx Ingress控制器，根本不是Traefik，改对应的注解当然没有任何作用。

1. 为什么相同配置在Minikube中可正常运行？ #

• Minikube默认启用的Ingress插件是开箱即用的宽松匹配逻辑：只要命名空间下存在Ingress资源，不管有没有显式标注Ingress Class，只要是集群里唯一的Ingress控制器，就会自动接管所有未标注的资源，不需要额外配置。
• 远程生产/共享集群的Ingress控制器通常是严格匹配逻辑：为了避免多租户环境下的规则冲突，控制器会跳过所有没有显式声明对应Ingress Class的资源，不会自动识别未标注的Ingress。
• 旧版Ingress配置里用注解写kubernetes.io/ingress.class的方式，在1.22+版本的K8s集群中已经被废弃，新的逻辑要求必须在Ingress资源的spec字段下显式声明ingressClassName，否则会被控制器直接忽略。

2. 此处的HTTP 404状态码代表什么含义？ #

• 这个404是入口Nginx Ingress控制器本身返回的，不是后端服务返回的：当请求带着Host: myapp-helper-service.example.com打到Nginx时，因为规则表里没有匹配这个Host的条目，Nginx就会返回默认的404页面。
• 这个场景下的404不是后端服务连通性问题：如果是后端不通、服务异常，Nginx会返回502 Bad Gateway或者503 Service Unavailable，而不是默认的404。
• 辅助验证证据：正常被Ingress控制器加载的资源，都会被控制器回写公网IP到ADDRESS列；你的helper服务Ingress的ADDRESS为空，和主应用的生效规则形成明确对比，进一步说明规则根本没被加载。

3. 如何从集群内部调试服务的可达性？ #

按照从底层到上层的顺序依次排查：

• 第一步：验证Service端点连通性
  执行kubectl get endpoints myapp-helper-service -n 你的命名空间，确认返回的IP、端口和Pod实际监听的端口一致——从你现有输出看，端点172.25.0.207:8080是正常的，这部分链路没有问题。
• 第二步：跳过Service直接测试Pod连通性
  找同命名空间下任意运行中的Pod（比如主应用的myapp-645cd66d9-g84vm），执行kubectl exec -it myapp-645cd66d9-g84vm -n 你的命名空间 -- curl 172.25.0.207:8080，看是否能拿到服务的正常响应，排除Pod内应用本身的问题。
• 第三步：测试ClusterIP连通性
  还是从同一个调试Pod内，执行curl 10.10.10.61:8080（helper服务的ClusterIP），验证Service的转发链路是否正常。
• 临时调试方案：如果没有合适的测试Pod，可以直接启动一个一次性的curl工具Pod：kubectl run curl-test --image=curlimages/curl --rm -it -- sh，进入容器后依次执行上面的测试命令即可。

4. 如何从集群外部/Ingress层调试服务的可达性？ #

• 第一步：先确认集群实际的Ingress控制器类型
  执行kubectl get pods -n kube-system | grep -E 'ingress|traefik'，看返回的Pod是Nginx Ingress还是Traefik，从你收到Nginx格式404的结果已经可以确认是Nginx Ingress，之前改Traefik注解的操作完全是无意义的。
• 第二步：确认Ingress Class配置一致性
  执行kubectl get ingressclass，对比能正常访问的主应用Ingress用的是哪个Ingress Class，直接把这个Class配置复制到helper服务的Ingress的spec字段下。
• 第三步：模拟外部请求测试入口匹配
  拿到主应用Ingress对应的公网IP 37.44.1.172，在本地执行命令curl -v -H "Host: myapp-helper-service.example.com" http://37.44.1.172：
  • 如果还是返回Nginx默认404，说明控制器没有加载对应的Host规则
  • 如果返回502，说明规则已经加载完成，问题出在后端转发链路
• 第四步：查看Ingress控制器日志定位问题
  找到对应的Nginx Ingress控制器Pod，执行kubectl logs -n kube-system <ingress-nginx的Pod名> | grep helper-service，日志里会直接说明为什么规则被跳过——大部分情况是没有指定ingressClassName、或者权限不足读取关联的Service资源。

5. 如果现有配置本身不存在问题，还需要排查哪些维度？ #

首先修正现有配置的明确问题后，再按以下维度排查：

• 必改的配置项：在helper服务的Ingress的spec下，添加和主应用Ingress完全一致的ingressClassName字段，这是解决当前规则不加载问题的核心操作。
• 然后依次排查以下维度：
  • 命名空间一致性：确认Ingress、Service、Deployment三个资源是否在同一个命名空间下，跨命名空间的情况下Ingress是无法找到后端Service的（Helm子chart如果配置错误，很容易把资源部署到默认命名空间）
  • Host名匹配一致性：确认你实际请求时携带的Host头，和Ingress里定义的Host完全一致——你之前的示例配置里写的Host是helper-service.example.com，但集群里实际生成的Ingress Host是myapp-helper-service.example.com，Host不匹配的话必然触发404
  • 规则冲突检查：确认同一个Host下有没有其他优先级更高的Ingress路径规则，覆盖了你定义的/根路径规则
  • RBAC权限检查：你执行describe ingress时看到default-http-backend的权限报错，说明当前操作账号的权限不足，同时也可能存在Ingress控制器本身的RBAC权限不足，无法读取Service端点信息，导致规则加载失败的问题。

内容的提问来源于stack exchange，提问作者Kamafeather