Ingress作用
-
7层负载均衡
我们知道service可以通过kube-proxy实现4层负载均衡，而ingress规则配置的后端是service，ingress似乎只起到反向代理的作用，且只能借助service实现4层负载均衡。但实际上，当我们配置了Ingress规则后，kube-proxy就不再起作用，ingress-controller会直接从service所属的endpoints中选择一个Pod，将流量直接转发到该Pod上，从而实现7层负载均衡。
image.png - 小成本对外暴露服务
当我们要把集群中的服务对外暴露时，通常要创建LB类型或者是NodePort类型的Service。在生产上，一般都使用LB类型的Service，当我们服务很多时，需要用到的LB就会非常多，成本相对就较高，如果再绑定下域名就更麻烦了。而使用Ingress只用把Ingress服务暴露出去，就可以把外部流量导入到集群中。
一般ingress-controller都是通过deployment形式部署的，只需要再创建一个LB类型的service（调试环境也可以使用NodePort类型Service。），后端为ingress-controller，将该ingress-controller暴露出去即可。
当然，通过这种方式暴露集群的服务，存在一个问题是ingress-controller可能成为一个性能瓶颈点。
Ingress-Nginx 规则配置
首先区分一下ingress规则和ingress-controller的作用。我们创建ingress的时候，实际上是创建ingress规则，也就是转发规则，而真正实现流量转发的是ingress-controller。ingress-controller会list/watch ingress规则，当流量进来后，根据ingress规则，将流量转发到不同的后端服务。
ingress-nginx是k8s官方实现的基于nginx的ingress-controller。规则配置的示例如下：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
namespace: default
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/use-regex: "true"
spec:
rules:
- host: test-ingress.com
http:
paths:
- path: /foo
backend:
service:
name: web1-service
port:
number: 8080
pathType: ImplementationSpecific
- path: /bar
backend:
service:
name: web1-service
port:
number: 8080
pathType: ImplementationSpecific
- host：指定服务访问域名。
- path：指定访问的URL路径。LB将流量转发到backend之前，所有的入站请求都要先匹配host和path。
- backend：由服务名称和服务端口组成。
- 服务名称：Ingress转发的backend服务名称。
- 服务端口：服务暴露的端口。
注：根据云厂商的不同，ingress规则配置的语法也不同。
参考
https://marcuseddie.github.io/2021/K8s-Network-Architecture-section-two.html
