关于Minikube中Ingress与NodePort服务配置的疑问

问题1：Ingress控制器为何部署在ingress-nginx命名空间？能否与业务服务分属不同命名空间？ #

• 用独立命名空间是集群基础设施组件的标准实践：Ingress控制器属于集群核心组件，和业务服务隔离在不同命名空间，便于权限管控、资源配额分配、日志排查，避免和default命名空间的业务资源混淆，降低误操作风险。
• 完全可以和业务服务分属不同命名空间：Ingress控制器是集群级组件，默认配置下其对应的ServiceAccount拥有跨命名空间访问Service的权限，能正常路由到default或其他命名空间的业务服务。

问题2：Ingress清单中指定业务服务的命名空间后，跨命名空间路由是否可行？ #

• 可行。在Ingress资源的规则中，只要明确指定后端Service的命名空间，Ingress控制器就能正确定位到对应资源。示例配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-business-service
            namespace: default  # 明确指定业务服务所在命名空间
            port:
              number: 80

问题3：业务服务必须是NodePort类型才能被Ingress路由？官方文档为何用NodePort？ #

• 不需要！业务服务用ClusterIP类型才是Ingress路由的标准用法。Ingress控制器通过集群内部网络直接访问ClusterIP服务，完全不需要把业务服务暴露成NodePort。
• 官方文档中使用NodePort是额外的演示需求：方便用户在不配置Ingress的情况下，通过minikube service <服务名>直接访问服务，验证业务服务本身是否正常运行，这不是Ingress工作的必要条件。
• Ingress对象的核心作用就是通过统一的Ingress控制器暴露后端服务，替代每个业务服务单独开NodePort/LoadBalancer的方式，实现更灵活的路由规则和流量管理。

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