9.5.1 理解 Ingress API 和 Ingress Controller
当涉及到暴露 Kubernetes 集群内部的应用程序时，我们可以使用 ClusterIP 类型的 Service 对象。到目前为止，我们就是这样做的，使 Pod 能够在集群内相互交互。例如，Catalog Service Pod 就是这样与 PostgreSQL Pod 通信的。
Service 对象也可以是 LoadBalancer 类型，它依赖于云提供商配置的外部负载均衡器将应用程序暴露到互联网。我们可以为 Edge Service 定义 LoadBalancer Service，而不是 ClusterIP。在公共云中运行系统时，供应商会配置负载均衡器，分配公共 IP 来自该负载均衡器的所有流量将被定向到 Edge Service Pod。这是一种灵活的方法，允许你将服务直接暴露到互联网，并且适用于不同类型的流量。
LoadBalancer Service 方法涉及为我们决定暴露到互联网的每个服务分配不同的 IP 地址。由于服务是直接暴露的，我们没有机会应用任何进一步的网络配置，例如 TLS 终止。我们可以在 Edge Service 中配置 HTTPS，通过网关路由所有定向到集群的流量（甚至不属于 Polar Bookshop 的平台服务），并在那里应用进一步的网络配置。Spring 生态系统提供了我们需要的一切来解决这些问题，在许多场景中我们可能会这样做。然而，由于我们想在 Kubernetes 上运行我们的系统，我们可以在平台级别管理这些基础设施问题，使我们的应用程序更简单、更易于维护。这就是 Ingress API 派上用场的地方。
Ingress 是一个对象，"管理对集群中服务的外部访问，通常是 HTTP。Ingress 可以提供负载均衡、SSL 终止和基于名称的虚拟主机"（https://kubernetes.io/docs）。Ingress 对象充当 Kubernetes 集群的入口点，能够将来自单个外部 IP 地址的流量路由到集群内运行的多个服务。我们可以使用 Ingress 对象执行负载均衡、接受定向到特定 URL 的外部流量，以及管理 TLS 终止以通过 HTTPS 暴露应用程序服务。
Ingress 对象本身什么都不做。我们使用 Ingress 对象来声明路由和 TLS 终止方面的期望状态。实际执行这些规则并将流量从集群外部路由到内部应用程序的组件是 Ingress Controller。由于有多种可用实现，核心 Kubernetes 发行版中没有默认的 Ingress Controller——需要你自行安装。Ingress Controller 是通常使用反向代理（如 NGINX、HAProxy 或 Envoy）构建的应用程序。一些示例是 Ambassador Emissary、Contour 和 Ingress NGINX。
在生产环境中，将使用云平台或专用工具来配置 Ingress Controller。在我们的本地环境中，我们需要一些额外的配置来使路由工作。对于 Polar Bookshop 示例，我们将在两种环境中使用 Ingress NGINX（https://github.com/kubernetes/ingress-nginx）。
注意： 有两个基于 NGINX 的流行 Ingress Controller。Ingress NGINX 项目（https://github.com/kubernetes/ingress-nginx）在 Kubernetes 项目本身中开发、支持和维护。它是开源的，也是我们在本书中将使用的。NGINX Controller（www.nginx.com/products/nginx-controller）是由 F5 NGINX 公司开发和维护的产品，它有免费和商业选项。
让我们看看如何在本地 Kubernetes 集群上使用 Ingress NGINX。Ingress Controller 是一个工作负载，就像在 Kubernetes 上运行的任何其他应用程序一样，它可以以不同的方式部署。最简单的选项是使用 kubectl 将其部署清单应用到集群。由于我们使用 minikube 管理本地 Kubernetes 集群，我们可以依靠内置的插件来启用基于 Ingress NGINX 的 Ingress 功能。
首先，让我们启动第 7 章中介绍的 polar 本地集群。由于我们配置了 minikube 在 Docker 上运行，请确保你的 Docker Engine 已启动并运行：
$ minikube start --cpus 2 --memory 4g --driver docker --profile polar
接下来，我们可以启用 Ingress 插件，它将确保 Ingress NGINX 部署到我们的本地集群：
$ minikube addons enable ingress --profile polar
最后，你可以通过以下方式获取有关 Ingress NGINX 部署的不同组件的信息：
$ kubectl get all -n ingress-nginx
前面的命令包含一个我们尚未遇到的参数：-n ingress-nginx。它意味着我们想要获取在 ingress-nginx 命名空间中创建的所有对象。
命名空间是"Kubernetes 用于支持单个集群内资源组隔离的抽象。命名空间用于组织集群中的对象，并提供划分集群资源的方式"（https://kubernetes.io/docs/reference/glossary）。
我们使用命名空间来保持集群组织有序，并定义网络策略以出于安全原因将某些资源隔离。到目前为止，我们一直在使用默认命名空间，我们将继续为所有 Polar Bookshop 应用程序使用它。然而，对于 Ingress NGINX 等平台服务，我们将依赖专用命名空间来隔离这些资源。
现在 Ingress NGINX 已安装，让我们继续部署 Polar Bookshop 应用程序使用的后端服务。查看本书附带的源代码仓库（Chapter09/09-end），将 polar-deployment/kubernetes/platform/development 文件夹的内容复制到你的 polar-deployment 仓库中的相同路径，覆盖我们在前面章节中使用的任何现有文件。该文件夹包含运行 PostgreSQL 和 Redis 的基本 Kubernetes 清单。
打开终端窗口，导航到 polar-deployment 仓库中的 kubernetes/platform/development 文件夹，运行以下命令在本地集群中部署 PostgreSQL 和 Redis：
$ kubectl apply -f services
你可以使用以下命令验证结果：
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
polar-postgres 1/1 1 1 73s
polar-redis 1/1 1 1 73s
提示： 为了方便起见，我准备了一个脚本，可以通过单个命令执行所有前面的操作。你可以运行它来使用 minikube 创建本地 Kubernetes 集群，启用 Ingress NGINX 插件，并部署 Polar Bookshop 使用的后端服务。你会在刚刚复制到 polar-deployment 仓库的 kubernetes/platform/development 文件夹中找到 create-cluster.sh 和 destroy-cluster.sh 文件。在 macOS 和 Linux 上，你可能需要通过
chmod +x create-cluster.sh命令使脚本可执行。
让我们通过将 Edge Service 打包为容器镜像并将制品加载到本地 Kubernetes 集群来结束本节。打开终端窗口，导航到 Edge Service 根文件夹（edge-service），运行以下命令：
$ ./gradlew bootBuildImage
$ minikube image load edge-service --profile polar
在下一节中，你将定义一个 Ingress 对象，并配置它来管理对 Kubernetes 集群中运行的 Polar Bookshop 系统的外部访问。