Kubernetes中调用API报503错误，无法访问查询到的Ingress资源该如何处理？

这种kubectl get ingress能查到资源、但describe/访问时提示不存在的情况完全可能发生，常见触发原因如下：

• 命名空间不匹配：默认kubectl操作仅针对当前上下文配置的默认命名空间，若Ingress创建在其他命名空间下，未指定命名空间执行describe就会报资源不存在
• 客户端缓存/资源时序问题：kubectl的list操作结果存在短时间缓存，若执行get后到describe的间隙，Ingress被清理脚本、其他操作人员或异常controller删除，也会出现该报错
• RBAC权限伪装：若当前使用的kubeconfig账号只有集群维度list Ingress的权限，没有对应命名空间下get/describe Ingress的权限，Kubernetes API服务器会出于安全考虑返回「资源不存在」的报错，而非权限不足提示
• 多集群上下文切换：两次操作期间kubectl上下文被切换到了其他集群，自然在新集群中查不到原集群的Ingress资源

按以下顺序操作即可定位到目标Ingress：

1. 查询全集群Ingress匹配目标资源
   执行以下命令查询所有命名空间下的Ingress，定位目标资源所属的命名空间：
   kubectl get ingress -A | grep dett-server-bss-ingress
   返回结果的第一列为该Ingress对应的命名空间，后续所有操作都加上命名空间参数即可，例如查询详情：
   kubectl describe ingress dett-server-bss-ingress -n <替换为实际命名空间>
2. 验证操作上下文一致性
   执行以下命令确认当前kubectl上下文未发生切换：
   kubectl config current-context
   若两次操作上下文不一致，切换回原集群上下文后再操作即可
3. 校验账号权限
   执行以下命令检查是否拥有目标Ingress的访问权限：
   kubectl auth can-i get ingress/dett-server-bss-ingress -n <替换为实际命名空间>
   若返回no，需要联系集群管理员开通对应命名空间的Ingress访问权限
4. 后续503问题排查（Ingress定位后的延伸操作）
   确认Ingress可正常访问后，按以下逻辑排查503错误：

• 检查Ingress配置中关联的后端Service名称、端口是否和实际部署的Service一致
• 执行kubectl get endpoints <对应Service名称> -n <命名空间>检查Service是否有正常的就绪Pod IP，若Endpoints为空则需要排查Pod的就绪探针、启动状态是否正常
• 检查Ingress Controller的运行日志，确认是否有路由转发异常

内容的提问来源于stack exchange，提问作者Mr.Gomer