k8a 对外服务（ingress）详解（定义，暴露，代理，重写，）

一、对外服务

service策略的作用

外部访问方案

适用场景和限制

ingress如何实现对外服务

ingress 概念

定义

组成

工作原理

总结

二、部署 nginx-ingress-controller

创建 ingress-controller pod及相关资源

创建目录：

下载配置文件

修改集群角色(ClusterRole) 资源配置

暴露ingress服务

暴露的三种方式

三、采用DaemonSet+HostNetwork+nodeSelector暴露服务

先指定控制器运行在node02节点上

修改 Deployment 为 DaemonSet ，指定节点运行，并开启 hostNetwork 网络

在所有 node 节点上传 nginx-ingress-controller 镜像压缩包 ingree.contro.tar.gz 到 /opt/ingress 目录，并解压和加载镜像

启动 nginx-ingress-controller

验证 Pod 状态

检查 ConfigMaps 和 DaemonSet：

在node02节点检查

检查网络监听：

创建 ingress 规则

创建一个deploy的业务pod和svc

创建ingress资源

测试访问

查看controller的pod状态，并在pod内部查看ingress规则是否被正确配置

查看 nginx-ingress-controller Pod 状态：

进入 nginx-ingress-controller Pod 的 Bash shell：

查看 Nginx 配置文件：

四、采用Deployment+NodePort模式的Service暴露服务

创建目录并下载配置文件：

所有节点上传并加载 Docker 镜像：

启动 nginx-ingress-controller

查看状态

五、 Ingress HTTP 代理访问

环境准备：

创建资源：

应用配置：

验证部署：

测试服务

进入Pod并修改HTML文件：

获取Service信息：

添加本地域名解析：

外部访问测试：

六、 Ingress HTTP 代理访问虚拟主机

前期准备

创建虚拟主机1的资源

创建Deployment资源：

创建Service资源：

应用配置：

创建虚拟主机2的资源

创建Deployment资源：

创建Service资源：

应用配置：

创建ingress资源

创建Ingress资源：

应用：

测试访问

获取Ingress Controller的Service信息

测试虚拟主机访问：

七、 Ingress HTTPS 代理访问

环境准备

创建HTTPS配置目录：

切换到HTTPS配置目录：

创建SSL证书：

创建Secret资源：

获取Secret资源信息：

查看Secret资源：

创建 deployment、Service、Ingress Yaml 资源

创建YAML配置文件：

应用配置：

查看Service信息：

访问测试

编辑本地hosts文件：

访问HTTPS服务：

八、 Nginx 进行 HTTP身份验证（BasicAuth）

环境准备

创建基本认证目录：

生成用户密码认证文件：

创建Secret资源：

创建Ingress资源：

应用Ingress配置：

访问测试

获取Ingress Controller的Service信息：

修改本地hosts文件：

浏览器访问：

九、配置nginx实现URL重写

Nginx Ingress Controller的注解配置说明

创建重写Ingress资源：

应用Ingress配置：

修改本地hosts文件：

浏览器访问：

一、对外服务

service策略的作用

在Kubernetes中，Service是一种抽象，用于定义一组Pod的访问方式和网络策略。它提供了一种稳定的网络终结点，以便其他应用程序可以访问这些Pod。Service的作用主要体现在两个方面：

服务发现： Service允许其他应用在集群内发现并访问特定的Pod，即使Pod的IP地址会随着时间的变化而改变，Service提供了一个稳定的虚拟IP和DNS名称，使得其他应用能够持续地与服务通信。
负载均衡： 当一个Service代表多个Pod时，它可以在这些Pod之间进行负载均衡，确保请求被均匀地分发到各个Pod上，从而提高应用程序的可用性和性能。

在 Kubernetes 中，Pod 的 IP 地址和 Service 的 ClusterIP 只能在集群内部网络中访问。这意味着，对于集群外部的应用来说，这些地址是不可见的。

外部访问方案

NodePort：通过在每个节点上开放一个端口（NodePort），可以将service服务暴露给外部网络。Kube-Proxy 负责在服务网络、Pod 网络和节点网络之间进行通信。这种方式在测试环境中适用，但在生产环境中，当服务数量众多时，端口管理会变得复杂，因为每个端口只能对应一种服务，且端口范围有限（通常为 30000-32767）。
LoadBalancer：这种方式通过云服务提供商的负载均衡器（LoadBalancer）来暴露服务。这通常在公有云平台上使用，但受限于云平台的支持，并且可能需要额外的费用。
externalIPs：Service 可以被分配一个或多个外部 IP 地址。如果这些 IP 地址能够路由到集群中的一个或多个节点，那么服务就会通过这些 IP 地址暴露。流量通过这些外部 IP 进入集群后，会被路由到 Service 的 Endpoint。
Ingress：Ingress 提供了一种更为高效的方式，它允许使用一个或少量的公网 IP 地址和负载均衡器（LB）来同时暴露多个 HTTP 服务。Ingress 可以看作是 Service 的进一步抽象，它基于域名和 URL 路径来定义规则，将用户的请求转发到一个或多个 Service。

适用场景和限制

NodePort：
适用场景：在小型集群或测试环境中，NodePort 是一个简单且易于设置的选项。它允许直接通过节点的 IP 地址和特定端口访问服务。
限制：在生产环境中，由于端口范围有限（30000-32767），并且每个端口只能映射到一个服务，这可能导致端口资源耗尽和管理复杂性增加。
LoadBalancer：
适用场景：在云服务提供商（如 AWS、Azure、Google Cloud 等）的环境中，LoadBalancer 是最常使用的方案。它提供了自动的负载均衡和扩展能力，适合需要高可用性和可扩展性的生产环境。
成本：使用 LoadBalancer 可能会产生额外的费用，因为它通常涉及云服务提供商的负载均衡服务。
externalIPs：
适用场景：当集群部署在具有固定公网 IP 地址的环境中，或者需要直接使用外部 IP 地址时，externalIPs 是一个合适的选择。这在私有云或混合云部署中较为常见。
限制：需要确保外部 IP 地址能够正确路由到集群节点，并且可能需要额外的网络配置。
Ingress：
适用场景：Ingress 是最灵活的方案，它允许通过一个或少量的公网 IP 地址来暴露多个服务。这在需要管理大量服务的复杂应用场景中非常有用，尤其是在需要基于域名和路径进行细粒度流量控制时。
优势：Ingress 提供了更高级的功能，如 SSL/TLS 终端、HTTP 重写、负载均衡、虚拟主机等。它也支持更复杂的路由规则，如基于路径的路由和重定向。
在实际部署中，Ingress 由于其灵活性和高级功能，通常被认为是最常使用的方案，尤其是在生产环境中。它允许开发者和运维人员以声明式的方式管理入口流量，而无需关心底层的网络实现细节。此外，Ingress 控制器（如 nginx-ingress 或 traefik）的流行也促进了 Ingress 的广泛采用。

ingress如何实现对外服务

在Kubernetes中，LB（负载均衡器）和Ingress一起使用时，LB通常指的是负载均衡器服务，而Ingress是一种资源，用于定义应用程序的外部入口。LB通过将外部流量路由到Kubernetes集群内的Ingress Controller来实现对多个服务的管理。Ingress Controller会根据Ingress规则将请求路由到相应的服务，为应用提供统一的入口。这组合提供了高级别的路由和负载平衡功能，使得在Kubernetes环境中更灵活地管理服务的访问。

LB和Ingress结合起来实现对外服务的过程大致如下：

LB配置： 负载均衡器（Load Balancer）通过配置将外部流量引导到Kubernetes集群。这可能涉及到云服务商的负载均衡器设置或其他物理设备。
Ingress Controller部署： 在Kubernetes集群中部署Ingress Controller，它负责管理Ingress资源并根据其规则处理请求。
Ingress资源定义： Kubernetes用户通过创建Ingress资源定义外部访问规则，包括路径、主机等信息。这些规则描述了如何将外部请求路由到集群内的服务。
Ingress Controller监听： Ingress Controller会监听集群中的Ingress资源的变化，并根据定义的规则更新其配置。
请求路由： 当外部请求到达负载均衡器时，LB将请求转发到Ingress Controller。Ingress Controller根据Ingress规则将请求路由到相应的服务。
服务响应： 被选中的服务接收请求并提供相应的响应。这使得在Kubernetes环境中，可以更加灵活地管理多个服务的对外访问。

这整个过程的目标是实现集中化的入口管理，允许动态调整路由规则而无需修改底层服务。

ingress 概念

定义

Ingress 是 Kubernetes 中的一个 API 对象，它允许你定义一组规则，这些规则控制着外部访问你的集群内服务的方式。Ingress 可以被看作是集群的入口点，它提供了一种机制来管理外部访问到集群内部服务的 HTTP 和 HTTPS 流量。Ingress 规则基于域名和 URL 路径，将用户的请求转发到一个或多个后端服务。

Ingress并不直接处理或转发流量，它需要与Ingress Controller一起使用。Ingress Controller是一个实际处理流量的组件，它根据Ingress资源中定义的规则，将请求路由到正确的服务。这种组合使得在Kubernetes环境中能够方便地管理多个服务的访问入口。

组成

Ingress 资源对象：这是通过 YAML 文件配置的，它定义了请求如何转发到服务的规则。Ingress 对象可以包含多个规则，每个规则可以指定不同的域名、路径和后端服务。
Ingress 控制器（Ingress Controller）：这是一个运行在 Kubernetes 集群中的组件，它负责实现 Ingress 资源对象中定义的规则。Ingress 控制器通常是一个反向代理服务器，如 Nginx 或 Traefik，它根据 Ingress 规则来处理进入集群的流量。

一般，ingress-controller的形式都是一个pod，里面跑着daemon程序和反向代理程序。daemon负责不断监控集群的变化，根据 ingress对象生成配置并应用新配置到反向代理，比如ingress-nginx就是动态生成nginx配置，动态更新upstream，并在需要的时候reload程序应用新配置。为了方便，后面的例子都以k8s官方维护的ingress-nginx为例。

Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx

Ingress-Nginx 官方网站：https://kubernetes.github.io/ingress-nginx/

总结来说：ingress-controller才是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到 ingress-controller，而ingress对象是用来告诉ingress-controller该如何转发请求，比如哪些域名、哪些URL要转发到哪些service等等。

工作原理

Ingress 控制器通过与 Kubernetes API Server 交互，动态感知集群中 Ingress 规则的变化。
控制器读取这些规则，并根据自定义的规则生成相应的配置（例如 Nginx 配置），而规则就是写明了哪个域名对应哪个service。
控制器将这些配置应用到其运行的反向代理服务中，例如将配置写入 Nginx 的配置文件，并重新加载服务以使配置生效。也就是写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中。
reload后配置生效

总结

Ingress作为请求入口：
Ingress确实是Kubernetes集群的入口点，它允许外部流量进入集群内部。Ingress提供了一种机制，可以根据定义的规则将外部HTTP和HTTPS请求路由到集群内的多个服务。
Ingress资源对象与Ingress Controller：
Ingress资源对象定义了路由规则，包括URL路径、主机名、重定向、负载均衡等。
Ingress Controller是一个运行在集群中的组件，它负责实现Ingress资源对象中定义的规则。Ingress-Nginx是Kubernetes社区原生支持的一种Ingress Controller实现，它使用Nginx作为反向代理服务器。
Ingress Controller的选择：
根据具体的需求，可以选择不同的Ingress Controller。除了Ingress-Nginx，还有其他实现，如Traefik、HAProxy等。每种实现都有其特点和优势，选择合适的Ingress Controller可以提高集群的灵活性和性能。
Ingress的暴露方式：
Ingress可以通过多种方式暴露服务，包括NodePort、LoadBalancer、IngressClass等。
NodePort在集群节点上为服务提供一个静态端口，外部流量可以通过这个端口访问服务。
LoadBalancer通常用于云环境，它创建一个负载均衡器，为服务提供一个外部可访问的IP地址。
IngressClass提供了一种更灵活的方式来定义Ingress资源的行为，允许管理员定义不同的Ingress策略。

二、部署 nginx-ingress-controller

创建 ingress-controller pod及相关资源

创建目录：

mkdir /opt/ingress
cd /opt/ingress

下载配置文件

官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml

由于官方下载地址可能无法下载，可以使用国内的Gitee镜像来下载所需的YAML配置文件。这里有两个版本的配置文件，一个是nginx-0.25.0，另一个是nginx-0.30.0。可以选择一个版本进行下载。

对于nginx-0.25.0版本：

wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml

对于nginx-0.30.0版本：

wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml

确保下载的是最新版本的配置文件，因为新版本可能包含了安全更新和功能改进。如果不确定哪个版本更适合你，可以查看官方文档或者社区讨论来决定。

mandatory.yaml文件中包含了很多资源的创建，包括namespace、ConfigMap、role，ServiceAccount等等所有部署ingress-controller需要的资源。

修改集群角色(ClusterRole) 资源配置

clusterRole用于定义集群中资源的权限

vim mandatory.yaml
......
apiVersion: rbac.authorization.k8s.io/v1beta1
#RBAC相关资源从1.17版本开始改用rbac.authorization.k8s.io/v1，rbac.authorization.k8s.io/v1beta1在1.22版本即将弃用
kind: ClusterRole
metadata:name: nginx-ingress-clusterrolelabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
rules:- apiGroups:- ""resources:- configmaps- endpoints- nodes- pods- secretsverbs:- list- watch- apiGroups:- ""resources:- nodesverbs:- get- apiGroups:- ""resources:- servicesverbs:- get- list- watch- apiGroups:- "extensions"- "networking.k8s.io"    # （0.25版本）增加 networking.k8s.io Ingress 资源的 api resources:- ingressesverbs:- get- list- watch- apiGroups:- ""resources:- eventsverbs:- create- patch- apiGroups:- "extensions"- "networking.k8s.io"   # （0.25版本）增加 networking.k8s.io/v1 Ingress 资源的 api resources:- ingresses/statusverbs:- update

这份 YAML 文件是对 Kubernetes 中的 ClusterRole 资源进行配置的，ClusterRole 用于定义对集群中资源的权限。下面是对该文件中各部分的详细解析：

apiVersion：指定 Kubernetes API 的版本，此处使用的是 rbac.authorization.k8s.io/v1beta1 版本，但注释中提到从 1.17 版本开始应改用 rbac.authorization.k8s.io/v1，而 v1beta1 版本将在 1.22 版本后弃用。
kind：指定资源的类型，这里是 ClusterRole，表示集群级别的角色。
metadata：指定资源的元数据，包括名称和标签等信息。
rules：定义了针对不同资源的访问规则。在这里，包含了多个规则，每个规则指定了对一类资源的访问权限。
第一个规则指定了对 ConfigMaps、Endpoints、Nodes、Pods 和 Secrets 等资源的 list 和 watch 权限。
第二个规则指定了对 Nodes 资源的 get 权限。
第三个规则指定了对 Services 资源的 get、list 和 watch 权限。
第四个规则指定了对 Ingress 资源的 get、list 和 watch 权限，其中包括了对 "extensions" 和 "networking.k8s.io" API 组的 Ingress 资源的权限。
第五个规则指定了对 Events 资源的 create 和 patch 权限。
最后一个规则指定了对 Ingress 资源状态的 update 权限，同样包括了 "extensions" 和 "networking.k8s.io" API 组的 Ingress 资源。

这些规则定义了该 ClusterRole 在集群中对各种资源的访问权限，以及允许的操作。这样配置的 ClusterRole 可以被绑定到用户、服务账户或者其他身份上，以控制它们对集群资源的访问权限。

暴露ingress服务

暴露的三种方式

方式一：Deployment+LoadBalancer 模式的 Service
这种方式适用于在公有云环境中部署 Ingress。首先使用 Deployment 来部署 ingress-controller。
然后创建一个 type 为 LoadBalancer 的 Service，这个 Service 会与 ingress-controller 的 Pod 关联。
大多数公有云服务提供商会为 LoadBalancer 类型的 Service 自动创建一个负载均衡器，并分配一个公网 IP 地址。
只需要将域名解析到这个公网 IP 地址，就可以实现服务的外部访问。
方式二：DaemonSet+HostNetwork+nodeSelector
使用 DaemonSet 部署 ingress-controller，这样可以确保在每个节点上都运行一个 ingress-controller 的 Pod。
通过设置 hostNetwork: true，使得 Pod 直接使用宿主机的网络命名空间，这样 Pod 就可以直接使用宿主机的 IP 地址和端口。
使用 nodeSelector 可以选择特定的节点来部署 ingress-controller。
这种方式下，Ingress 控制器所在的节点就像传统的边缘节点，例如机房入口的 Nginx 服务器。
这种方式的优点是请求链路简单，性能较好。但缺点是每个节点只能部署一个 ingress-controller Pod，因为它们直接使用了宿主机的网络和端口。
方式三：Deployment+NodePort模式的 Service
同样使用 Deployment 来部署 ingress-controller。
创建一个 type 为 NodePort 的 Service，这样 Ingress 会暴露在集群节点的 IP 地址上的一个特定端口。
NodePort 模式会为每个节点分配一个随机端口，通常你会在前面设置一个负载均衡器来转发请求到这些端口。
这种方式适用于宿主机 IP 地址相对固定且不会变化的场景。
虽然 NodePort 方式简单方便，但由于多了一层网络地址转换（NAT），在高并发情况下可能会对性能产生影响。

三、采用DaemonSet+HostNetwork+nodeSelector暴露服务

先指定控制器运行在node02节点上

为节点添加标签

kubectl label node node02 ingress=true

查看节点标签

kubectl get nodes --show-labels

这个命令会列出所有节点及其标签。可以在输出中查找 node02 节点，确认 ingress=true 标签已经被成功添加。

修改 Deployment 为 DaemonSet ，指定节点运行，并开启 hostNetwork 网络

4、修改 Deployment 为 DaemonSet ，指定节点运行，并开启 hostNetwork 网络
vim mandatory.yaml
...
apiVersion: apps/v1
# 修改 kind
# kind: Deployment
kind: DaemonSet
metadata:name: nginx-ingress-controllernamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
spec:
# 删除Replicas
# replicas: 1selector:matchLabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginxtemplate:metadata:labels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginxannotations:prometheus.io/port: "10254"prometheus.io/scrape: "true"spec:# 使用主机网络hostNetwork: true# 选择节点运行nodeSelector:ingress: "true"serviceAccountName: nginx-ingress-serviceaccount
......

要将 nginx-ingress-controller 的部署方式从 Deployment 修改为 DaemonSet，并且指定它在具有特定标签的节点上运行，同时开启 hostNetwork 模式，你需要对 mandatory.yaml 文件进行以下修改：

修改 kind 为 DaemonSet：将 kind: Deployment 更改为 kind: DaemonSet。
删除 replicas 字段： DaemonSet 不需要 replicas 字段，因为它会确保 Pod 在每个选定的节点上运行一个实例。
添加 hostNetwork: true：在 spec.template.spec 下添加 hostNetwork: true，这将使 Pod 使用宿主机的网络命名空间。
添加 nodeSelector：在 spec.template.spec 下添加 nodeSelector 字段，并设置 ingress: "true"，以便 Pod 只在带有 ingress=true 标签的节点上运行。

在所有 node 节点上传 nginx-ingress-controller 镜像压缩包 ingree.contro.tar.gz 到 /opt/ingress 目录，并解压和加载镜像

上传镜像压缩包：首先，需要将 ingree.contro.tar.gz 文件上传到所有节点的 /opt/ingress 目录。这可以通过 SSH 或其他文件传输方法完成。如果你有多个节点，你可以使用如 scp 或 rsync 这样的工具来批量传输文件。
解压镜像压缩包：通过 SSH 登录到每个节点，然后导航到 /opt/ingress 目录并解压镜像文件。

cd /opt/ingress
tar zxvf ingree.contro.tar.gz

加载 Docker 镜像：解压后，可以使用 docker load 命令来加载镜像。确保已经切换到了包含解压后的 Docker 镜像文件的目录。然后执行：

docker load -i ingree.contro.tar

这个命令会将镜像文件加载到 Docker 的镜像列表中。加载完成后，可以使用 docker images 命令来验证镜像是否已经被成功加载。

请注意，如果你的 Kubernetes 集群使用的是 Containerd 或其他容器运行时，而不是 Docker，那么加载镜像的命令可能会有所不同。在这种情况下，可能需要使用相应的工具来导入镜像。

启动 nginx-ingress-controller

nginx-ingress-controller 已经在 node02 节点上成功运行，并且配置了 hostNetwork，这意味着 nginx 直接在宿主机上监听了 80、443 和 8181 端口。这样，任何对这些端口的请求都会被转发到 nginx-ingress-controller。

现在，为了确保 nginx-ingress-controller 能够正常工作并对外提供服务，需要执行以下步骤：

验证 Pod 状态

确保 nginx-ingress-controller Pod 的状态是 Running，并且 READY 列显示为 1/1，这表示 Pod 已经准备好接收流量。

kubectl get pod -n ingress-nginx -o wide

检查 ConfigMaps 和 DaemonSet：

确保所有相关的 ConfigMaps 和 DaemonSet 都已经创建，并且状态正常。

kubectl get cm,daemonset -n ingress-nginx -o wide

在node02节点检查

检查网络监听：

在 node02 节点上运行 netstat 命令来验证 nginx 是否在预期的端口上监听。 netstat 的输出，显示了 nginx 在 80、443 和 8181 端口上的监听。

netstat -lntp | grep nginx

其中 8181 是 nginx-controller 默认配置的一个 default backend（Ingress 资源没有匹配的 rule 对象时，流量就会被导向这个 default backend）。

这样，只要访问 node 主机有公网 IP，就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话，可以在多个 node上部署，并在前面再搭建一套 LVS+keepalived 做负载均衡。

创建 ingress 规则

创建一个deploy的业务pod和svc

vim service-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-app
spec:replicas: 2selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: nginx-app-svc
spec:type: ClusterIPports:- protocol: TCPport: 80targetPort: 80selector:app: nginx

在应用这个配置文件之前，请确保已经有一个名为 ingress-nginx 的命名空间，因为 Ingress 控制器通常在这个命名空间中运行。如果还没有这个命名空间，可以创建它：

kubectl create namespace ingress-nginx

然后，应用 service-nginx.yaml 文件来创建 Deployment 和 Service：

kubectl apply -f service-nginx.yaml -n ingress-nginx

创建ingress资源

#方法一：（extensions/v1beta1 Ingress 在1.22版本即将弃用）
vim ingress-app.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: nginx-app-ingress
spec:rules:- host: www.test.comhttp:paths:- path: /backend:serviceName: nginx-app-svcservicePort: 80#方法二：
vim ingress-app.yaml      
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: nginx-app-ingress
spec:rules:- host: www.test.comhttp:paths:- path: /pathType: Prefix     backend:service:name: nginx-app-svcport:number: 80

现在，已经准备好应用 Ingress 规则。在应用 Ingress 规则之前，请确保域名 www.test.com 已经正确解析到了运行 nginx-ingress-controller 的节点的公网 IP 地址。如果域名解析还没有设置好，Ingress 规则将无法正常工作，因为外部请求无法正确路由到你的服务。

接下来，可以应用 Ingress 规则：

kubectl apply -f ingress-app.yaml -n ingress-nginx

这将创建一个名为 nginx-app-ingress 的 Ingress 资源，它将所有到 www.test.com 的 HTTP 请求路由到 nginx-app-svc 服务的 80 端口。

应用 Ingress 规则后，可以检查 Ingress 资源的状态：

kubectl get ingress -n ingress-nginx

应该会看到 nginx-app-ingress 已经创建，并且有一个与 www.test.com 关联的地址和端口。

最后，可以检查 Pod 的状态，确保 nginx-app 的 Pod 正在运行：

kubectl get pods -n ingress-nginx

如果一切正常，应该看到 nginx-app 的 Pod 状态为 Running，并且 READY 列显示为 1/1。

现在，当访问 www.test.com 时，请求应该会被 nginx-ingress-controller 接收，并转发到 nginx-app-svc 服务。因为 nginx-ingress-controller 配置了 hostNetwork，那么它将直接在节点的 80 端口上监听，并将流量转发到相应的服务。如果遇到问题，可以查看 nginx-ingress-controller 的日志来帮助诊断问题。

测试访问

添加host域名解析

vim /etc/hosts
192.168.41.31 master
192.168.41.33 node01
192.168.41.34 node02
192.168.41.34 www.test.comcurl www.test.com

查看controller的pod状态，并在pod内部查看ingress规则是否被正确配置

查看 `nginx-ingress-controller` Pod 状态：

kubectl get pod -n ingress-nginx -o wide

这个命令显示了 nginx-ingress-controller Pod 的详细信息，包括它的 IP 地址、所在的节点等。

进入 `nginx-ingress-controller` Pod 的 Bash shell：

kubectl exec -it nginx-ingress-controller-99h72 -n ingress-nginx /bin/bash

这个命令允许以交互模式进入 Pod 的内部。

查看 Nginx 配置文件：

# more /etc/nginx/nginx.conf

在 Pod 的 Bash shell 中，可以使用 more 或 cat 命令来查看 Nginx 的配置文件。你应该能够看到 www.test.com 的配置，这表明 Ingress 规则已经被正确地应用到了 Nginx 的配置中。

如果看到了 www.test.com 的配置，这意味着 nginx-ingress-controller 已经根据你创建的 Ingress 规则更新了 Nginx 的配置。现在，当外部请求到达 node02 节点的 80 端口时，它们将被正确地路由到 nginx-app-svc 服务。

如果需要查看更详细的 Nginx 配置，或者需要调试 Ingress 规则，可以查看 nginx-ingress-controller Pod 的日志：

kubectl logs nginx-ingress-controller-99h72 -n ingress-nginx

这将显示 Pod 的日志输出，其中可能包含有关 Ingress 规则处理的详细信息。

四、采用Deployment+NodePort模式的Service暴露服务

创建目录并下载配置文件：

创建一个新的目录 /opt/ingress-nodeport，然后下载 nginx-ingress-controller 的配置文件和 NodePort 服务的配置文件。

mkdir /opt/ingress-nodeport
cd /opt/ingress-nodeport

官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

国内 gitee 资源地址：
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

所有节点上传并加载 Docker 镜像：

将 ingress-controller-0.30.0.tar 镜像包上传到所有节点的 /opt/ingress-nodeport 目录，并使用 docker load 命令加载镜像。

# 假设你已经有了 ingress-controller-0.30.0.tar 文件
# 将文件上传到所有节点的 /opt/ingress-nodeport 目录
# 然后加载镜像
docker load -i ingress-controller-0.30.0.tar

启动 `nginx-ingress-controller`

使用 kubectl apply 命令应用 mandatory.yaml 和 service-nodeport.yaml 配置文件来启动 nginx-ingress-controller。

kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml

这将创建 nginx-ingress-controller 的 Deployment 和相关的 RBAC 配置，以及一个 NodePort 类型的 Service，该 Service 将暴露 80 和 443 端口，允许外部流量通过这些端口访问 Ingress 控制器。

如果 Kubernetes Pod 调度失败，并且 kubectl describe pod 命令的输出显示了 "0/2 nodes are available: 2 node(s) didn't match node selector" 的警告时，这意味着 Pod 的调度请求无法找到符合其节点选择器（nodeSelector）的节点。这通常发生在 Pod 定义中指定了特定的节点选择器，但是集群中没有节点带有相应的标签。

要解决这个问题，有两个选择：

给需要调度的节点添加标签：如果 Pod 需要在特定的节点上运行，需要确保这些节点有正确的标签。可以使用 kubectl label nodes 命令来给节点添加标签。例如，如果 Pod 需要在操作系统为 Linux 的节点上运行

kubectl label nodes <node_name> kubernetes.io/os=linux

将 <node_name> 替换为实际的节点名称。

删除或修改 Pod 定义中的节点选择器：如果 Pod 不需要在特定的节点上运行，可以从 Pod 的定义中删除节点选择器。这通常在 Pod 的 YAML 文件中进行。例如，如果你的 Pod 定义如下：

spec:nodeSelector:kubernetes.io/os: linux

可以删除 nodeSelector 字段，或者将其设置为一个空对象：

spec:nodeSelector: {}

然后重新应用 Pod 的 YAML 文件：

kubectl apply -f <pod_definition.yaml>

请确保在修改 Pod 定义后重新应用配置，以便更改生效。

查看状态

kubectl get pod,svc -n ingress-nginx

从输出来看，nginx-ingress-controller Pod 正在 ingress-nginx 命名空间中正常运行，状态为 Running。同时，ingress-nginx 服务是 NodePort 类型，这意味着它在集群的每个节点上都开放了特定的端口（80 端口映射到 32383 端口，443 端口映射到 32133 端口）以供外部访问。

五、 Ingress HTTP 代理访问

环境准备：

进入Kubernetes集群中的Ingress相关的目录：/opt/ingress-nodeport。

cd /opt/ingress-nodeport

创建资源：

使用vim编辑器创建一个名为ingress-nginx.yaml的YAML文件，该文件包含以下资源的定义：
- Deployment：名为nginx-app，包含两个Nginx容器副本，监听容器端口80。
- Service：名为nginx-svc，类型为ClusterIP，端口80，选择器为name=nginx。
- Ingress：名为nginx-test，配置了一个规则，将访问www.gzb.com域名的流量转发到nginx-svc服务的端口80。

vim ingress-nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-app
spec:replicas: 2selector:matchLabels:name: nginxtemplate:metadata:labels:name: nginxspec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: nginx-svc
spec:ports:- port: 80targetPort: 80protocol: TCPselector:name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: nginx-test
spec:rules:- host: www.gzb.comhttp:paths:- path: /pathType: Prefixbackend:service: name: nginx-svcport:number: 80

应用配置：

使用kubectl apply -f ingress-nginx.yaml命令应用上述YAML文件中的配置。

kubectl apply -f ingress-nginx.yaml

验证部署：

使用kubectl get svc,pods -o wide命令查看服务和Pod的状态。输出显示nginx-svc服务已创建，但没有外部IP，两个Nginx Pod正在运行。

kubectl get svc,pods -o wide

为了使外部流量能够访问到这个服务，需要确保：

Ingress Controller已正确安装并运行。
域名www.gzb.com已正确解析到Ingress Controller的外部IP地址。
如果在云服务提供商上部署，可能需要配置负载均衡器或网络策略。

测试服务

进入Pod并修改HTML文件：

使用kubectl exec命令进入名为nginx-app-65d7b99f6b-l4g65的Pod，并在/usr/share/nginx/html/目录下创建或修改index.html文件，添加内容this is web1

kubectl exec -it pod/nginx-app-65d7b99f6b-l4g65 bash# cd /usr/share/nginx/html/# echo 'this is web1' >> index.html

对另一个名为nginx-app-65d7b99f6b-zcqgp的Pod执行相同的操作，添加内容this is web2。

kubectl exec -it pod/nginx-app-65d7b99f6b-zcqgp bash# cd /usr/share/nginx/html/# echo 'this is web2' >> index.html

获取Service信息：

使用kubectl get svc -n ingress-nginx命令获取名为ingress-nginx的Service信息。该Service配置了NodePort类型，监听端口80和443，并且有对应的NodePort（例如，80端口对应的NodePort为32383）。

kubectl get svc -n ingress-nginx

添加本地域名解析：

vim /etc/hosts
192.168.41.31 master
192.168.41.33 node01
192.168.41.34 node02
192.168.41.34 www.test.com www.gzb.com

外部访问测试：

使用curl命令尝试通过外部域名www.gzb.com和NodePort32383访问服务。

curl http://www.gzb.com:32383

六、 Ingress HTTP 代理访问虚拟主机

前期准备

mkdir /opt/ingress-nodeport/vhost
cd /opt/ingress-nodeport/vhost

创建目录：
使用mkdir命令创建一个新的目录/opt/ingress-nodeport/vhost。这个目录用于存放虚拟主机的配置文件，如SSL证书、密钥、以及其他与虚拟主机相关的文件。
切换目录：
使用cd命令切换到新创建的vhost目录。这通常是为了在该目录下进行后续的操作，比如编辑配置文件或者添加其他必要的文件。
这些步骤是配置Ingress资源的前期准备工作。

创建虚拟主机1的资源

在Kubernetes集群中创建一个名为deployment1的Deployment和一个名为svc-1的Service。

创建Deployment资源：

vim deployment1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: deployment1
spec:replicas: 2selector:matchLabels:name: nginx1template:metadata:labels:name: nginx1spec:containers:- name: nginx1image: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: svc-1
spec:ports:- port: 80targetPort: 80protocol: TCPselector:name: nginx1kubectl apply -f deployment1.yaml

在该文件中定义了一个Deployment，名为deployment1，它包含两个Nginx容器的副本，这些容器使用标签name: nginx1进行选择。
容器使用的镜像是soscscs/myapp:v1，并且监听容器端口80。

创建Service资源：

在同一个YAML文件中定义了一个Service，名为svc-1。
该Service配置了一个端口80，用于将外部流量转发到选择器name: nginx1匹配的Pod的80端口。
Service类型默认为ClusterIP，这意味着它只能在集群内部访问。

应用配置：

使用kubectl apply -f deployment1.yaml命令将这些配置应用到Kubernetes集群中。
这些资源的创建将允许在集群内部通过svc-1服务访问名为nginx1的Deployment中的Nginx容器。

创建虚拟主机2的资源

在Kubernetes集群中创建第二个虚拟主机资源，包括一个名为deployment2的Deployment和一个名为svc-2的Service

创建Deployment资源：

vim deployment2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: deployment2
spec:replicas: 2selector:matchLabels:name: nginx2template:metadata:labels:name: nginx2spec:containers:- name: nginx2image: soscscs/myapp:v2imagePullPolicy: IfNotPresentports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: svc-2
spec:ports:- port: 80targetPort: 80protocol: TCPselector:name: nginx2kubectl apply -f deployment2.yaml

在该文件中定义了一个Deployment，名为deployment2，它包含两个Nginx容器的副本，这些容器使用标签name: nginx2进行选择。
容器使用的镜像是soscscs/myapp:v2，并且监听容器端口80。

创建Service资源：

在同一个YAML文件中定义了一个Service，名为svc-2。
该Service配置了一个端口80，用于将外部流量转发到选择器name: nginx2匹配的Pod的80端口。
Service类型默认为ClusterIP，这意味着它只能在集群内部访问。

应用配置：

使用kubectl apply -f deployment2.yaml命令将这些配置应用到Kubernetes集群中。

这些资源的创建将允许在集群内部通过svc-2服务访问名为nginx2的Deployment中的Nginx容器。与之前创建的deployment1和svc-1类似，deployment2和svc-2也是内部服务，需要通过Ingress资源来实现外部访问。

创建ingress资源

vim ingress-nginx.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress1
spec:rules:- host: www1.gzb.comhttp:paths:- path: /pathType: Prefixbackend:service: name: svc-1port:number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress2
spec:rules:- host: www2.gzb.comhttp:paths:- path: /pathType: Prefixbackend:service: name: svc-2port:number: 80kubectl apply -f ingress-nginx.yaml

创建Ingress资源：

在该文件中定义了两个Ingress资源，ingress1和ingress2。
ingress1配置了一个规则，当访问www1.gzb.com时，流量将被路由到名为svc-1的服务的端口80。
ingress2配置了一个规则，当访问www2.gzb.com时，流量将被路由到名为svc-2的服务的端口80。

应用：

使用kubectl apply -f ingress-nginx.yaml命令将这些Ingress配置应用到Kubernetes集群中。

这些配置已经在集群中安装并配置了Ingress Controller，例如Nginx Ingress Controller。Ingress Controller将根据这些规则处理进入集群的HTTP流量，并将请求根据主机名转发到相应的后端服务。

测试访问

成功通过Ingress资源配置了两个虚拟主机后，在集群内部通过curl命令测试了它们的访问。

获取Ingress Controller的Service信息

使用kubectl get svc -n ingress-nginx命令查看Ingress Controller的Service信息。会看到了ingress-nginx服务，它是一个NodePort类型的服务，没有外部IP地址，但有一个内部的ClusterIP，并且配置了两个端口：80和443，分别映射到NodePort的32383和32133。

kubectl get svc -n ingress-nginx

测试虚拟主机访问：

使用curl命令尝试从集群内部访问两个不同的虚拟主机www1.gzb.com和www2.gzb.com。由于在集群内部执行这些命令，您可以直接使用NodePort（32383）来访问这些服务。
会收到了两个不同的响应，每个响应都显示了相应的应用版本（v1和v2），这表明Ingress规则正确地将请求路由到了对应的后端服务。

curl www1.gzb.com:32383
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>curl www2.gzb.com:32383
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

七、 Ingress HTTPS 代理访问

在Kubernetes集群中配置HTTPS代理访问通常涉及以下步骤：

获取或生成SSL/TLS证书和私钥。
将证书和私钥文件放置在集群节点可以访问的位置，例如您刚刚创建的https目录。
创建Ingress资源的YAML配置文件，指定SSL/TLS证书和私钥的位置，以及需要启用HTTPS的虚拟主机规则。

一旦这些步骤完成，就可以使用kubectl apply命令应用Ingress配置，从而启用HTTPS代理访问。这将允许外部用户通过安全的HTTPS连接访问您的服务。

环境准备

创建HTTPS配置目录：

使用mkdir命令在/opt/ingress-nodeport路径下创建一个新的目录，命名为https。这个目录将用于存放与HTTPS相关的配置文件，如SSL/TLS证书和密钥。

mkdir /opt/ingress-nodeport/https

切换到HTTPS配置目录：

使用cd命令切换到新创建的https目录。这通常是为了在该目录下进行后续的操作，比如添加SSL/TLS证书和密钥文件，或者创建Ingress资源的YAML配置文件。

cd /opt/ingress-nodeport/https

创建SSL证书：

使用openssl req命令创建一个新的自签名SSL证书（tls.crt）和私钥（tls.key）。
证书的主题（-subj）被设置为/CN=nginxsvc/O=nginxsvc，这通常代表证书的通用名称（Common Name）和组织名称（Organization）。
证书有效期设置为365天，使用2048位的RSA密钥。

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"

创建Secret资源：

使用kubectl create secret tls命令创建一个新的Kubernetes Secret资源，名为tls-secret。
该Secret资源包含您之前创建的tls.key（私钥）和tls.crt（证书）文件。

kubectl create secret tls tls-secret --key tls.key --cert tls.crt

获取Secret资源信息：

使用kubectl get secret命令查看当前命名空间（默认为default）中的Secret资源列表。
可以看到了名为tls-secret的Secret资源，它包含TLS类型的数据。

kubectl get secret

查看Secret资源：

使用kubectl describe secret tls-secret命令获取tls-secret的详细信息。
可以看到了Secret资源的类型为kubernetes.io/tls，并且包含了证书和私钥的数据。

kubectl describe secret tls-secret

现在，可以在创建Ingress资源时引用这个Secret，以便为Ingress Controller配置HTTPS支持。这将允许Ingress Controller使用这个SSL证书来终止外部HTTPS请求。

创建 deployment、Service、Ingress Yaml 资源

创建YAML配置文件：

在该文件中定义一个Deployment（nginx-app），它包含两个Nginx容器的副本。
定义一个Service（nginx-svc），它将端口80的流量转发到标签为name: nginx的Pod。
定义一个Ingress资源（nginx-https），它配置了HTTPS支持，使用之前创建的tls-secret证书和私钥。
Ingress资源中定义了一个规则，当访问www3.gzb.com时，流量将被路由到nginx-svc服务的端口80。

vim ingress-https.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-app
spec:replicas: 2selector:matchLabels:name: nginxtemplate:metadata:labels:name: nginxspec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: nginx-svc
spec:ports:- port: 80targetPort: 80protocol: TCPselector:name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: nginx-https
spec:tls:- hosts:- www3.gzb.comsecretName: tls-secretrules:- host: www3.gzb.comhttp:paths:- path: /pathType: Prefixbackend:service: name: nginx-svcport:number: 80kubectl apply -f ingress-https.yaml

应用配置：

使用kubectl apply -f ingress-https.yaml命令将这些配置应用到Kubernetes集群中。

查看Service信息：

使用kubectl get svc -n ingress-nginx命令获取Ingress Controller的Service信息。会看到了ingress-nginx服务，它是一个NodePort类型的服务，监听端口80和443，但没有外部IP地址。

kubectl get svc -n ingress-nginx

现在，已经为www3.gzb.com配置了HTTPS代理访问。

访问测试

使用本地的hosts文件来解析域名www3.gzb.com到一个特定的IP地址

编辑本地`hosts`文件：

在Windows系统的C:\Windows\System32\drivers\etc\目录下，编辑hosts文件。
添加一行记录，将IP地址192.168.41.36映射到域名www3.gzb.com。这样，当计算机尝试访问www3.gzb.com时，它将被解析到192.168.41.36。

访问HTTPS服务：

使用谷歌浏览器（或其他浏览器）访问https://www3.gzb.com:32133。这里，32133是Ingress Controller的NodePort端口号，用于HTTPS流量。

请注意，由于使用的是NodePort而不是外部IP地址，这种访问方式通常只适用于集群内部或者在知道NodePort端口号的情况下。对于外部用户，他们需要通过域名解析到Ingress Controller的外部IP地址，并且Ingress Controller需要配置为使用您创建的TLS证书来处理HTTPS请求。

八、 Nginx 进行 HTTP身份验证（BasicAuth）

在Kubernetes集群中配置Nginx Ingress Controller以实现基本的HTTP身份验证（BasicAuth）

环境准备

创建基本认证目录：

使用mkdir命令创建一个新的目录/opt/ingress-nodeport/basic-auth。
使用cd命令切换到该目录。

mkdir /opt/ingress-nodeport/basic-auth
cd　/opt/ingress-nodeport/basic-auth

生成用户密码认证文件：

使用yum -y install httpd命令安装httpd软件包，这是为了使用htpasswd工具。
使用htpasswd -c auth zhangsan命令创建一个名为auth的用户认证文件，其中zhangsan是用户名。这将提示您输入密码。

yum -y install httpd
htpasswd -c auth zhangsan            #认证文件名必须为 auth

创建Secret资源：

使用kubectl create secret generic basic-auth --from-file=auth命令创建一个新的Kubernetes Secret资源，名为basic-auth，并将之前生成的auth文件作为数据。

kubectl create secret generic basic-auth --from-file=auth

创建Ingress资源：

使用vim编辑器创建一个名为ingress-auth.yaml的YAML文件。
在该文件中定义了一个Ingress资源，名为ingress-auth，它包含了基本认证的配置。
使用注解设置了认证类型（basic）、认证使用的Secret资源名称（basic-auth）以及认证窗口提示信息。
定义了一个规则，当访问auth.gzb.com时，流量将被路由到nginx-svc服务的端口80。

vim ingress-auth.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-authannotations:#设置认证类型basicnginx.ingress.kubernetes.io/auth-type: basic#设置secret资源名称basic-authnginx.ingress.kubernetes.io/auth-secret: basic-auth#设置认证窗口提示信息nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - zhangsan'
spec:rules:- host: auth.gzb.comhttp:paths:- path: /pathType: Prefixbackend:service: name: nginx-svcport:number: 80

具体详细设置方法可参考官网 https://kubernetes.github.io/ingress-nginx/examples/auth/basic/

应用Ingress配置：

使用kubectl apply -f ingress-auth.yaml命令将Ingress配置应用到Kubernetes集群中。

kubectl apply -f ingress-auth.yaml

完成这些步骤后，当用户尝试访问auth.gzb.com时，他们将被提示输入用户名和密码。只有输入正确的凭据后，才能访问该域名下的服务。

访问测试

获取Ingress Controller的Service信息：

使用kubectl get svc -n ingress-nginx命令查看Ingress Controller的Service信息。可以看到了ingress-nginx服务，它是一个NodePort类型的服务，监听端口80和443，没有外部IP地址。

kubectl get svc -n ingress-nginx

修改本地`hosts`文件：

将一行记录添加到/etc/hosts文件中，将IP地址192.168.41.36映射到域名auth.gzb.com。这样，当您的计算机尝试访问auth.gzb.com时，它将被解析到192.168.41.36。

echo '192.168.41.36 auth.gzb.com' >> /etc/hosts

浏览器访问：

使用浏览器尝试访问http://auth.gzb.com:32383。这里，32383是Ingress Controller的NodePort端口号。

浏览器访问：http://auth.gzb.com:32383

九、配置nginx实现URL重写

在Kubernetes集群中配置Nginx Ingress Controller以实现URL重写。

Nginx Ingress Controller的注解配置说明

这些注解用于定制Ingress的行为。以下是每个注解的详细说明：

nginx.ingress.kubernetes.io/rewrite-target：
这个注解用于指定重定向流量的目标URI。当希望请求被重写到不同的路径或主机时使用。例如，如果有一个旧的URL路径需要更新，可以使用这个注解来自动重定向用户到新的路径。
nginx.ingress.kubernetes.io/ssl-redirect：
这个注解是一个布尔值，用于指示是否仅通过SSL（HTTPS）重定向到Ingress。当Ingress包含证书时，默认值为true。这意味着，如果启用了SSL，所有HTTP请求都会被重定向到HTTPS。
nginx.ingress.kubernetes.io/force-ssl-redirect：
这也是一个布尔值，用于强制所有流量通过HTTPS，即使Ingress没有配置TLS证书。这可以用于确保所有流量都是安全的，即使在某些情况下可能还没有准备好SSL证书。
nginx.ingress.kubernetes.io/app-root：
这个注解定义了Ingress Controller必须重定向的应用程序根。如果应用程序的根路径不是'/'，可以使用这个注解来指定正确的根路径。
nginx.ingress.kubernetes.io/use-regex：
这个注解也是一个布尔值，用于指示Ingress上定义的路径是否使用正则表达式。如果设置为true，路径匹配将使用正则表达式，这允许更复杂的匹配逻辑，例如捕获路径中的特定部分。

这些注解提供了对Ingress Controller行为的细粒度控制，使得可以根据具体的应用需求来配置Ingress资源。在创建Ingress资源的YAML文件时，可以在metadata.annotations部分添加这些注解来实现所需的功能。

创建重写Ingress资源：

使用vim编辑器创建一个名为ingress-rewrite.yaml的YAML文件。
在该文件中定义了一个Ingress资源，名为nginx-rewrite，它包含了URL重写的注解配置。
注解nginx.ingress.kubernetes.io/rewrite-target设置为http://www1.gzb.com:32383，这意味着所有发送到re.gzb.com的流量都将被重定向到这个目标URI。

vim ingress-rewrite.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: nginx-rewriteannotations:nginx.ingress.kubernetes.io/rewrite-target: http://www1.gzb.com:32383
spec:rules:- host: re.gzb.comhttp:paths:- path: /pathType: Prefixbackend:#由于re.gzb.com只是用于跳转不需要真实站点存在，因此svc资源名称可随意定义service: name: nginx-svcport:number: 80

应用Ingress配置：

使用kubectl apply -f ingress-rewrite.yaml命令将Ingress配置应用到Kubernetes集群中。

kubectl apply -f ingress-rewrite.yaml

修改本地`hosts`文件：

将一行记录添加到/etc/hosts文件中，将IP地址192.168.41.36映射到域名re.gzb.com。

echo '192.168.41.36 re.gzb.com' >> /etc/hosts

浏览器访问：

使用浏览器尝试访问http://re.gzb.com:32383。这里，32383是Ingress Controller的NodePort端口号。

浏览器访问：http://re.gzb.com:32383