一个企业的网站建设,百度指数app下载,最好的免费软件网站建设,网站建设需要提供什么目录
一、 对外服务
service策略的作用
外部访问方案
适用场景和限制
ingress如何实现对外服务
ingress 概念
定义
组成
工作原理
总结
二、 部署 nginx-ingress-controller
创建 ingress-controller pod及相关资源
创建目录#xff1a;
下载配置文件
修改 集群…目录
一、 对外服务
service策略的作用
外部访问方案
适用场景和限制
ingress如何实现对外服务
ingress 概念
定义
组成
工作原理
总结
二、 部署 nginx-ingress-controller
创建 ingress-controller pod及相关资源
创建目录
下载配置文件
修改 集群角色(ClusterRole) 资源配置
暴露ingress服务
暴露的三种方式
三、 采用DaemonSetHostNetworknodeSelector暴露服务
先指定控制器运行在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 配置文件
四、 采用DeploymentNodePort模式的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来暴露服务。这通常在公有云平台上使用但受限于云平台的支持并且可能需要额外的费用。 externalIPsService 可以被分配一个或多个外部 IP 地址。如果这些 IP 地址能够路由到集群中的一个或多个节点那么服务就会通过这些 IP 地址暴露。流量通过这些外部 IP 进入集群后会被路由到 Service 的 Endpoint。 IngressIngress 提供了一种更为高效的方式它允许使用一个或少量的公网 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、roleServiceAccount等等所有部署ingress-controller需要的资源。
修改 集群角色(ClusterRole) 资源配置
clusterRole用于定义集群中资源的权限
vim mandatory.yaml
......
apiVersion: rbac.authorization.k8s.io/v1beta1
#RBAC相关资源从1.17版本开始改用rbac.authorization.k8s.io/v1rbac.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服务
暴露的三种方式 方式一DeploymentLoadBalancer 模式的 Service 这种方式适用于在公有云环境中部署 Ingress。首先使用 Deployment 来部署 ingress-controller。 然后创建一个 type 为 LoadBalancer 的 Service这个 Service 会与 ingress-controller 的 Pod 关联。 大多数公有云服务提供商会为 LoadBalancer 类型的 Service 自动创建一个负载均衡器并分配一个公网 IP 地址。 只需要将域名解析到这个公网 IP 地址就可以实现服务的外部访问。 方式二DaemonSetHostNetworknodeSelector 使用 DaemonSet 部署 ingress-controller这样可以确保在每个节点上都运行一个 ingress-controller 的 Pod。 通过设置 hostNetwork: true使得 Pod 直接使用宿主机的网络命名空间这样 Pod 就可以直接使用宿主机的 IP 地址和端口。 使用 nodeSelector 可以选择特定的节点来部署 ingress-controller。 这种方式下Ingress 控制器所在的节点就像传统的边缘节点例如机房入口的 Nginx 服务器。 这种方式的优点是请求链路简单性能较好。但缺点是每个节点只能部署一个 ingress-controller Pod因为它们直接使用了宿主机的网络和端口。 方式三DeploymentNodePort模式的 Service 同样使用 Deployment 来部署 ingress-controller。 创建一个 type 为 NodePort 的 Service这样 Ingress 会暴露在集群节点的 IP 地址上的一个特定端口。 NodePort 模式会为每个节点分配一个随机端口通常你会在前面设置一个负载均衡器来转发请求到这些端口。 这种方式适用于宿主机 IP 地址相对固定且不会变化的场景。 虽然 NodePort 方式简单方便但由于多了一层网络地址转换NAT在高并发情况下可能会对性能产生影响。
三、 采用DaemonSetHostNetworknodeSelector暴露服务
先指定控制器运行在node02节点上
为节点添加标签
kubectl label node node02 ingresstrue查看节点标签
kubectl get nodes --show-labels这个命令会列出所有节点及其标签。可以在输出中查找 node02 节点确认 ingresstrue 标签已经被成功添加。
修改 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: 10254prometheus.io/scrape: truespec:# 使用主机网络hostNetwork: true# 选择节点运行nodeSelector:ingress: trueserviceAccountName: 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 只在带有 ingresstrue 标签的节点上运行。
在所有 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 backendIngress 资源没有匹配的 rule 对象时流量就会被导向这个 default backend。
这样只要访问 node 主机有公网 IP就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话可以在多个 node上部署并在前面再搭建一套 LVSkeepalived 做负载均衡。
创建 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 规则处理的详细信息。
四、 采用DeploymentNodePort模式的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) didnt match node selector 的警告时这意味着 Pod 的调度请求无法找到符合其节点选择器nodeSelector的节点。这通常发生在 Pod 定义中指定了特定的节点选择器但是集群中没有节点带有相应的标签。
要解决这个问题有两个选择
给需要调度的节点添加标签 如果 Pod 需要在特定的节点上运行需要确保这些节点有正确的标签。可以使用 kubectl label nodes 命令来给节点添加标签。例如如果 Pod 需要在操作系统为 Linux 的节点上运行
kubectl label nodes node_name kubernetes.io/oslinux将 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选择器为namenginx。 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。由于在集群内部执行这些命令您可以直接使用NodePort32383来访问这些服务。 会收到了两个不同的响应每个响应都显示了相应的应用版本v1和v2这表明Ingress规则正确地将请求路由到了对应的后端服务。
curl www1.gzb.com:32383
Hello MyApp | Version: v1 | a hrefhostname.htmlPod Name/acurl www2.gzb.com:32383
Hello MyApp | Version: v2 | a hrefhostname.htmlPod 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被设置为/CNnginxsvc/Onginxsvc这通常代表证书的通用名称Common Name和组织名称Organization。 证书有效期设置为365天使用2048位的RSA密钥。
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj /CNnginxsvc/Onginxsvc创建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配置文件 在该文件中定义一个Deploymentnginx-app它包含两个Nginx容器的副本。 定义一个Servicenginx-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-fileauth命令创建一个新的Kubernetes Secret资源名为basic-auth并将之前生成的auth文件作为数据。
kubectl create secret generic basic-auth --from-fileauth创建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 这个注解是一个布尔值用于指示是否仅通过SSLHTTPS重定向到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
