K8S-ingress

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