有这篇文章文章，其中包含 Ingress 的描述：
虽然 Pod 和服务在 Kubernetes 上有自己的 IP 地址， 这些 IP 地址只能在 Kubernetes 集群内部访问，外部客户端无法访问。中的 Ingress 对象 Kubernetes 虽然仍处于测试阶段，但旨在发出信号 某个服务需要可访问的 Kubernetes 平台 外部世界，它包含所需的配置，例如 外部可访问的 URL、SSL 等。
这真的是需要引入Ingress才能让服务对外开放吗？
还有另一篇文章描述了NodePort：
NodePort - 在每个选定节点的同一端口上公开服务 在集群中使用 NAT。 使服务可从外部访问 使用 :< NodeIP > 进行集群< NodePort >。 ClusterIP 的超集。
看起来 NodePort 还可以从集群外部访问服务。还有一种 LoadBalancer 类型的服务，作为扩展也应该服务于此目的。我认为 Ingress 的某些功能可能是 NodePort / LoadBalancer 服务未涵盖的，但对我来说，kubernetes 开发过程中的一些架构选择会导致该平台提供的功能重叠，从而导致混乱。难道我错了？
Ingress 可以进行基于 HTTP 主机和路径的路由。在多服务应用程序中，您可以提供单个 HTTP 服务，其中
http://cluster.example.com/a/http://cluster.example.com/b/负载均衡器类型的服务需要外部负载均衡器，并且每个服务都有不同的主机名。您的本地环境可能需要一组特定的注释来获取外部主机名或 TLS 证书。但是，它可以支持任何基于 TCP 的协议，而不是特定的 HTTP。
NodePort 类型的 Service 需要直接访问 Kubernetes 节点，通常不会在生产环境中使用它。
自从您引用的文章撰写以来，Ingress 已经从“测试版”发展到“稳定”（Kubernetes 1.19），再到“有一点限制，可能会被取代”。对于基本的 HTTP 路由，Ingress 工作得很好，但对于许多甚至稍微复杂的情况，您需要在 Ingress 对象上添加特定于入口控制器的注释，这对于 Nginx、Contour 和其他东西来说是不同的。 Gateway API 是该 API 的较新版本，同样专门用于 HTTP 路由。
对于典型的面向生产的工作负载，我会使用 Ingress 对象来公开服务的 HTTP 端点（或网关 HTTPRoute，或者可能是更专业的东西，如 Istio VirtualService），并且我会避免使用 NodePort 或 LoadBalancer 类型的服务，单入口控制器除外。