k8s 对外服务之 Ingress（七层代理）

一 Ingress 简介理论方面

1， k8s service 作用

对集群内部：

它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制

对集群外部：

对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。

2，外部的应用能够访问集群内的服务的方法

●NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是沟通service网络、Pod网络和节点网络的桥梁。
测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的端口管理就是个灾难。因为每个端口只能是一种服务，端口范围只能是 30000-32767。

●LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。受限于云平台，且通常在云平台部署LoadBalancer还需要额外的费用。
在service提交后，Kubernetes就会调用CloudProvider在公有云上为你创建一个负载均衡服务，并且把被代理的Pod的IP地址配置给负载均衡服务做后端。

●externalIPs：service允许为其分配外部IP，如果外部IP路由到集群中一个或多个Node上，Service会被暴露给这些externalIPs。通过外部IP进入到集群的流量，将会被路由到Service的Endpoint上。

●Ingress：只需一个或者少量的公网IP和LB，即可同时将多个HTTP服务暴露到外网，七层反向代理。
可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则。

在 Kubernetes (k8s) 中，NodePort, LoadBalancer, externalIPs, 和 Ingress 都是用来暴露服务到集群外部的不同方法，各自有其特定的使用场景和特点：

NodePort

概念：NodePort 服务会在集群中每个节点上打开一个特定的端口，并将这个端口上的流量转发到 Service 的 backend pod 上。它是 Kubernetes 内置的最简单的一种服务暴露方式。 nodeport 简单粗暴理解就是把容器端口映射真机端口再通过 kube-proxy 的 pod 处理流量
使用场景：适用于测试环境或小规模部署，不需要复杂的负载均衡设置，只需要直接通过节点 IP 和 NodePort 访问服务。
区别：相对简单，但不够灵活，随着服务数量增加，管理众多端口变得困难。

LoadBalancer

概念：LoadBalancer 类型的服务会利用云提供商的负载均衡器（如 AWS ELB、GCP LB 等），自动创建一个外部负载均衡器，并将流量分发到集群中的节点。
使用场景：适用于生产环境，需要高可用性和自动扩展的服务。尤其适合需要云提供商负载均衡支持的场景。
区别：提供了更高级的流量管理和负载均衡功能，但依赖于云提供商支持，可能产生额外费用。

externalIPs

概念：通过 externalIPs 字段，可以在 Service 定义中直接指定一个或多个外部 IP 地址，集群会将这些 IP 地址绑定到 Service 上，从而允许外部流量直接通过这些 IP 访问服务 externalIPs 简单粗暴理解就是把想要通过的ip 开小灶告诉service
使用场景：适用于已有外部负载均衡器或具有固定公网 IP 的情况，希望直接利用这些资源来路由流量到 Service。
区别：提供了灵活性，允许使用自定义的外部 IP，但配置和管理外部负载均衡器的责任在于用户。

Ingress

概念：Ingress 是一种更高级的流量路由规则集合，它根据 HTTP/HTTPS 路径或主机头等规则，将外部请求路由到集群内的不同服务。通常背后需要一个 Ingress Controller（如 Nginx Ingress Controller）来实现实际的路由逻辑。
使用场景：适用于微服务架构，特别是当有多个服务需要对外暴露，并且需要基于 URL 路径或主机名进行路由时。
区别：提供了一层七层（应用层）的路由，支持复杂的路由规则，如路径基于的路由、TLS 终端等，非常适合现代微服务架构。 ingress 简单粗暴理解就是有个nginx 的pod（实际是ingress controller）做七层反向代理

总结

选择依据：选择哪种暴露方式取决于服务的需求、部署环境以及对可扩展性、安全性、成本控制的要求。对于简单的服务或测试环境，NodePort 或 externalIPs 可能足够；而对于生产环境、复杂路由需求或需要云提供商支持的高可用服务，则倾向于使用 LoadBalancer 或 Ingress。

3, Ingress 组成

3.1 Ingress

●ingress： nginx配置文件
ingress是一个API对象，通过yaml文件来配置，ingress对象的作用是定义请求如何转发到service的规则，可以理解为配置模板。
ingress通过http或https暴露集群内部service，给service提供外部URL、负载均衡、SSL/TLS以及基于域名的反向代理。ingress要依靠 ingress-controller 来具体实现以上功能。

3.2 ingress-controller

●ingress-controller：当做反向代理或者说是转发器
ingress-controller是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。
ingress-controller并不是k8s自带的组件，实际上ingress-controller只是一个统称，用户可以选择不同的ingress-controller实现，目前，由k8s维护的ingress-controller只有google云的GCE与ingress-nginx两个，其他还有很多第三方维护的ingress-controller，具体可以参考官方文档。但是不管哪一种ingress-controller，实现的机制都大同小异，只是在具体配置上有差异。
一般来说，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等等。

4， Ingress 工作原理

（1）ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化，
（2）然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置，
（3）再写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中，
（4）然后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。

二部署 nginx-ingress-controller

这是ingress 的必不可少的组件为下面ingress的三种模式做准备

1，部署ingress-controller pod及相关资源

准备 mandatory.yaml

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

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

上面可能无法下载，可用国内的 gitee
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml

2, 修改 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

三 ingress 暴露服务的方式介绍

1, 数据流向

2, 三种模式

2.1，方式一：Deployment+LoadBalancer 模式的 Service

如果要把ingress部署在公有云，那用这种方式比较合适。用Deployment部署ingress-controller，创建一个 type为 LoadBalancer 的 service 关联这组 pod。大部分公有云，都会为 LoadBalancer 的 service 自动创建一个负载均衡器，通常还绑定了公网地址。只要把域名解析指向该地址，就实现了集群服务的对外暴露

2.2，方式二：DaemonSet+HostNetwork+nodeSelector

用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用HostNetwork直接把该pod与宿主机node的网络打通，直接使用宿主机的80/433端口就能访问服务。这时，ingress-controller所在的node机器就很类似传统架构的边缘节点，比如机房入口的nginx服务器。该方式整个请求链路最简单，性能相对NodePort模式更好。缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress-controller pod。比较适合大并发的生产环境使用。

在这种模式下，"守护运行的程序"指的是那些通过 DaemonSet 部署，并配置为使用宿主机网络，且根据 nodeSelector 精确调度到目标节点上的容器化应用

2.3，方式三：Deployment+NodePort模式的Service

同样用deployment模式部署ingress-controller，并创建对应的service，但是type为NodePort。这样，ingress就会暴露在集群节点ip的特定端口上。由于nodeport暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定的环境ip地址不变的场景。

NodePort方式暴露ingress虽然简单方便，但是NodePort多了一层NAT，在请求量级很大时可能对性能会有一定影响。

3，三种模式比较

方法2之所以使用DaemonSet而不是Deployment，主要是因为其特殊的部署需求和网络模型：

1. **特定节点部署**：使用DaemonSet能够确保ingress-controller的Pod在每个选定的节点上运行一个实例。这对于需要在每个节点上直接利用宿主机网络和端口（如80和443）部署ingress-controller的场景非常有用。这种方式下，每个节点都直接参与外部流量的接入，无需额外的负载均衡器在Pod和节点间做转发，简化了网络路径，提高了性能。
2. **网络直通**：HostNetwork模式允许Pod直接使用宿主机的网络命名空间，意味着Pod可以直接监听宿主机的端口（如80和443）。这对于ingress场景特别重要，因为HTTP(S)流量通常就是通过这些标准端口进入。通过这种方式，ingress-controller能直接处理流入这些端口的流量，避免了额外的网络层跳转和NAT转换，从而提高处理能力。

相比之下，方法1（Deployment + LoadBalancer）和方法3（Deployment + NodePort）采用Deployment是因为它们的需求和网络模型不同：

- **方法1（Deployment + LoadBalancer）**：适用于需要云提供商自动管理外部负载均衡器的场景。在这种情况下，通常希望由云平台动态分配和管理负载均衡资源，以及公网IP，而Deployment能灵活地管理ingress-controller的Pod副本，以实现高可用性和自动伸缩。
- **方法3（Deployment + NodePort）**：虽然也是使用Deployment部署ingress-controller，但它依赖于NodePort来暴露服务，这种方式更为通用，不局限于特定云环境。每个节点上都会开放一个特定的端口来接收流量，但这个端口可能是随机或指定的非标准端口，之后可能还需要额外的负载均衡器或DNS配置来路由到这些节点。这种方法更加灵活，适用于多种环境，尤其是那些不提供或不需要高级负载均衡服务的场景。

综上所述，每种部署方式的选择取决于具体的基础设施、网络需求、性能要求以及运维便利性等因素。DaemonSet在需要直接利用节点网络资源，简化网络路径并提高性能的场景下是优选方案；而Deployment则提供了更广泛的部署灵活性，适用于需要动态伸缩、云负载均衡集成或节点端口随机分配的场景。

四实验模拟 DaemonSet+HostNetwork+nodeSelector

1，指定 nginx-ingress-controller 运行在 node02 节点

kubectl label node node02 ingress=truekubectl get nodes --show-labels

2，修改 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
......

3，node上传nginx-ingress-controller 镜像

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

cd /opt/ingress
tar zxvf ingree.contro.tar.gz
docker load -i ingree.contro.tar

4，启动 nginx-ingress-controller

5，查看pod cm daemonset

发现 pod 一直起不来

去查看原因报错误码500 端口占用（因为hostnetwork 用的是真机的80端口）

查看详细信息说探针启动失败

解决办法：将该node 占用了 80端口的 pod 删了

查看pod

查看 cm daemonset

到 node02 节点查看

由于配置了 hostnetwork，nginx 已经在 node 主机本地监听 80/443/8181 端口。其中 8181 是 nginx-controller 默认配置的一个 default backend（Ingress 资源没有匹配的 rule 对象时，流量就会被导向这个 default backend）。
这样，只要访问 node 主机有公网 IP，就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话，可以在多个 node
上部署，并在前面再搭建一套 LVS+keepalived 做负载均衡。

6，创建 ingress 规则

创建一个 deploy 和 svc

vim service-nginx.yamlapiVersion: 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

7，创建 ingress

#方法一：（extensions/v1beta1 Ingress 在1.22版本即将弃用）
vim ingress-app.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: nginx-app-ingress
spec:rules:- host: www.kgc.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.kgc.comhttp:paths:- path: /pathType: Prefix     backend:service:name: nginx-app-svcport:number: 80

apiVersion: networking.k8s.io/v1：这一行指定了使用的API版本，这里是networking.k8s.io/v1，表示Ingress资源的定义遵循Kubernetes网络API的v1版本。

kind: Ingress：这一行声明了资源的类型为"Ingress"，意味着这是用来创建一个Ingress资源的配置。

metadata: - 这个部分包含了资源的元数据信息。

name: nginx-app-ingress：定义了Ingress资源的名称为"nginx-app-ingress"，这个名字在Kubernetes集群内部唯一标识这个Ingress资源。

spec: - 这部分描述了Ingress的具体规格或配置。

rules: - 规则列表，定义了不同路径和主机名如何映射到后端服务。

- host: www.kgc.com：定义了一条规则，指定了请求的主机名为"www.kgc.com"。这意味着所有针对此域名的请求都将根据此规则进行路由。

http: - 表示接下来的配置是关于HTTP协议的。

paths: - 路径列表，定义了不同的URL路径如何映射到后端服务。

- path: /：定义了一条路径规则，匹配所有以"/"开头的请求路径，即根路径。

pathType: Prefix：指定了路径匹配的类型为"Prefix"。这意味着只要请求的路径以定义的路径（在这里是"/"）开始，就匹配这条规则。

backend: - 定义了请求被转发到的后端服务。

service: - 指定后端服务的详细信息。

name: nginx-app-svc：指定了后端服务的名称为"nginx-app-svc"，即请求将被路由到名为"nginx-app-svc"的服务上。

port: - 指定服务的端口号。

number: 80：指定了服务监听的端口为80，即HTTP默认端口。这意味着Ingress会将流量转发到该服务的80端口上。

总结来说，这段配置定义了一个Ingress资源，它将所有发送到"www.kgc.com"域名且路径以"/"开头的HTTP请求路由到名为"nginx-app-svc"的Kubernetes服务的80端口上。

8，执行yaml

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

查看pod 和 ingress (理解为后端服务器和负载均衡服务器)

9，测试访问

本地 host 添加域名解析

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.217.99 master01
192.168.217.66 node01
192.168.217.77 node02
192.168.217.77 www.kgc.com

10，查看 nginx-ingress-controller

这就是 ingress 的工作原理

五实验模拟 Deployment+NodePort模式的Service

1，清空之前实验环境

2，下载 nginx-ingress-controller 和 ingress-nginx 暴露端口配置文件

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

3，在所有 node 节点上传镜像包 ingress-controller-0.30.0.tar

在所有 node 节点上传镜像包 ingress-controller-0.30.0.tar 到 /opt/ingress-nodeport 目录，并加载镜像

docker load -i ingree.contro-0.30.0.tar

4，修改 mandatory_(1).yaml 文件

确保每个node 都有该标签

5，执行yaml 文件查看

查看pod 等

6，创建service资源

svc 模式是 nodeport 且要把这个svc 和nginx-ingress-controller 绑定


[root@master01 in-nodeport]#cat service-nodeport.yaml 
apiVersion: v1
kind: Service
metadata:name: ingress-nginxnamespace: ingress-nginx      #所在命名空间，需要先执行mandatory.yaml文件创建labels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
spec:type: NodePortports:- name: httpport: 80targetPort: 80protocol: TCP- name: httpsport: 443targetPort: 443protocol: TCPselector:app.kubernetes.io/name: ingress-nginx         app.kubernetes.io/part-of: ingress-nginx
#此标签是nginx-ingress-controller的标签，该service绑定该标签，
#将nginx-ingress-controller以NodePort的形式暴露出去

创建service资源

[root@master01 in-nodeport]#kubectl apply -f service-nodeport.yaml[root@master01 ingress-nodeport]#kubectl get svc -n ingress-nginx 
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.96.67.162   <none>        80:31101/TCP,443:30796/TCP   11s

7，创建Deployment

[root@master01 in-nodeport]#vim deployment.yaml 
[root@master01 in-nodeport]#cat deployment.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[root@master01 in-nodeport]#kubectl apply -f deployment.yaml 
deployment.apps/nginx01-ingress created
[root@master01 in-nodeport]#kubectl get pod -owide
NAME                               READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
nginx01-ingress-5d89744488-g7v6w   1/1     Running   0          8s    10.244.2.7     node02   <none>           <none>
nginx01-ingress-5d89744488-x66jh   1/1     Running   0          8s    10.244.1.215   node01   <none>           <none>
------------------------------------------------------------------------------------
#自定义web访问界面
[root@master01 in-nodeport]#kubectl exec -it nginx01-ingress-5d89744488-g7v6w bash
root@nginx01-ingress-5d89744488-g7v6w/~# echo "this is web01" >/usr/share/nginx/html/index.html 
root@nginx01-ingress-5d89744488-g7v6w/~# exit
exit
[root@master01 in-nodeport]#kubectl exec -it nginx01-ingress-5d89744488-x66jh bash
root@nginx01-ingress-5d89744488-x66jh:/# echo "this is web02" >/usr/share/nginx/html/index.html
root@nginx01-ingress-5d89744488-x66jh:/# exit
exit

8，创建service 规则

[root@master01 in-nodeport]#vim service.yaml [root@master01 in-nodeport]#cat service.yaml apiVersion: v1
kind: Service
metadata:name: in-ng-svc
spec:type: NodePort                 #设置类型为NodePort，用于暴露端口ports:- port: 80targetPort: 80selector:nginx-label: nginx01[root@master01 in-nodeport]#kubectl apply -f service.yaml 
service/in-ng-svc created[root@master01 in-nodeport]#kubectl get svc in-ng-svc 
NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
in-ng-svc   NodePort   10.96.174.168   <none>        80:32502/TCP   10s

8，创建Ingress规则

[root@master01 in-nodeport]#vim ingress.yaml
[root@master01 in-nodeport]#cat ingress.yaml
apiVersion: networking.k8s.io/v1     #网络API组的v1版本。
kind: Ingress                        #创建一个Ingress 资源
metadata:name: nginx-ingress-test
spec:rules:                       #定义ingress规则- host: www.china.com        #指定当HTTP请求的Host头部为www.benet.com时触发规则http:                      #定义HTTP路由规则  paths:                   #定义路径列表及其对应的后端服务- path: /                #定义要匹配的路径。这里使用了根路径，也就是web服务的站点目录pathType: Prefix       #表示使用前缀匹配方式backend:               #定义与上述路径匹配时应该路由到的后端服务service:             #指定后端服务的名称name: in-ng-svc    #port:              #定义后端服务的端口number: 80       #端口号为80
-------------------------------------------------------------------------------------
#上述文件表示，客户端通过www.china.com访问时，会触发定义的ingress规则，
#而后通过ingress-controller转发到指定的后端服务(service)当中，后端服务再将请求转发给绑定的pod
[root@master01 in-nodeport]#kubectl apply -f ingress.yaml
ingress.networking.k8s.io/nginx-ingress-test created
[root@master01 in-nodeport]#kubectl get ingress
NAME                 CLASS    HOSTS           ADDRESS   PORTS   AGE
nginx-ingress-test   <none>   www.china.com             80      9s

9，用客户端进行访问

可以看到，访问的方式，是以轮询的方式，发送到deployment管理的pod上。因为，它的数据流向是
1.用户将请求发送到ingress-controller，而后ingress-controller根据请求的Hosst头部信息，
也就是www.china.com触发ingress规则
2.ingress-controller通过ingress规则，获取到关联的service，以及endpoints关联地址
3.service会将流量平均分配，而后将地址返回给ingress-controller
4.ingress-controller最后将请求发送给合适的pod