Kubernetes Ingress

What's Ingress

---

ingress的定义

1. Kubernetes管理外部请求访问集群内部的Service而提供的API对象，典型的访问如HTTP请求
2. ingress提供集群外部请求到集群内部Service的HTTP / HTTPS的路由信息，具体路由信息由ingress中的rules所控制

ingress功能

1. 提供外部入站请求至集群内部Service
2. 提供流量负载均衡
3. 提供 SSL / TLS
4. 提供基于virtual host托管

为什么使用ingress

众所周知，对外提供服务，服务暴露的3种方式

1. nodePort
2. LoadBalance
3. ingress

其中nodePort & LoadBalance有以下缺点

• 消耗资源

增加主机节点的端口、每个ingress需要独立的公网地址&独立的负载均衡实例

• 管理复杂

增加对端口记录配置清单（应用系统功能对应端口）通常形式为nodeIP:nodePort，前端入口需要手动配置独立的Nginx等其它反向代理服务器

如果是LoadBalance类型，需要对每个ingress对应的负载均衡实例进行维护，如果应用系统非常庞大，那么产生的前端入口负载均衡实例会相当多，从而提高管理复杂性，提高管理成本，配置复杂；而且对负载均衡的功能有所要求（比如HTTP 7层，HTTP header/cookie/URL转发等）

• 容错性低

不管是nodePort & LoadBalance类型，无疑降低集群容错性，因为配置复杂，管理复杂，那么在日常使用中犯错的概率就会增加

ingress却很好的规避这些劣势，ingress Controller实际就是一个反向代理服务器，可以理解为nginx harpoxy等其它，具体参考官方文档

DefaultBackend

---

当接收到来自外部的请求时，但是与ingress路由规则无法匹配时，将转发到defaultbackend，

通常defaultbackend配置在ingress controller中，并非配置在具体的ingress rules某条规则中

Resource backedns

---

参考官方链接

https://kubernetes.io/zh/docs/concepts/services-networking/ingress/#resource-backend

在配置ingress rule时通常要指定backend后端具体配置，官方支持二种形式

1. resource
2. service

在同一条rules中二者是互斥的，只能指其中一种形式，resource通常是ingress对象（ingress object），最常用的配置就是针对访问对象存储、静态资源

• 参考配置

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: ingress-resource-backend
  spec:
    defaultBackend:
      resource:
        apiGroup: k8s.example.com
        kind: StorageBucket
        name: static-assets
    rules:
      - http:
          paths:
            - path: /icons
              pathType: ImplementationSpecific
              backend:
                resource:
                  apiGroup: k8s.example.com
                  kind: StorageBucket
                  name: icon-assets

路径类型（pathType）

---

Kubernetes中的ingress，在配置rules中path，每个path都有对应路径类型，具体pathType分为如下

1. ImplementationSpecific
2. Exact
3. Prefix

第一种 ImplementationSpecific，使用该种路径类型，如何匹配将取决于定义的ingressClass

第二种 Exact，精确匹配 URL 路径，且区分大小写

第三种 Prefix，基于以 / 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个完成。 路径元素指的是由 / 分隔符分隔的路径中的标签列表。 如果每个 p 都是请求路径 p 的元素前缀，则请求与路径 p 匹配

值得注意的是：如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配 （例如：/foo/bar 匹配 /foo/bar/baz, 但不匹配 /foo/barbaz）

具体详细路径匹配规则，参考官方文档，如下

https://kubernetes.io/zh/docs/concepts/services-networking/ingress/#path-types

多重匹配

当一条ingress资源中包含多个路径时，每个路径的配置都需要指定一种路径类型，发起请求访问时，匹配的规则应符合如下顺序

1. 优先匹配最长的path
2. 如果仍然有二条相同的路径，则Exact优先于Prefix

IngressClass

---

在kubernetes集群中，可以部署多个Ingress Controller，通常不同的Ingress Controller对应不同的Ingress，因此需要对Ingress指定对应Ingress Controller

如果要部署多个Ingress Controller时，不同版本指定不同的Ingress Controller使用参数--ingress-class，而高于Kubernetes v1.18.0官方已弃用--ingress-class，改为--controller-class

1. 创建Ingress Controller
   

   # 新版本
   # ingress-nginx Deployment/Statfulset
   spec:
     template:
        spec:
          containers:
            - name: ingress-nginx-internal-controller
              args:
                - /nginx-ingress-controller
                - '--controller-class=k8s.io/internal-ingress-nginx'
               ...
   

2. 创建Ingress Class

   # ingress-nginx IngressClass
   apiVersion: networking.k8s.io/v1
   kind: IngressClass
   metadata:
     name: internal-nginx
   spec:
     # 注意下面的Controller与刚才创建的Ingress Controller中的--controller-class参数的值相对应
     controller: k8s.io/internal-ingress-nginx
     ...

3. 创建具体的ingress，创建时需要指定Ingress Controller，则引用上面创建的Ingress Class的metadata.name字段的值

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
   spec:
     ingressClassName: internal-nginx
     ...

具体官方文档地址，如下

https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/

在创建ingress时，需要注意kubernetes的apiVersion，如下

引用官方文档

Running on Kubernetes versions older than 1.19

• Ingress resources evolved over time. They started with apiVersion: extensions/v1beta1, then moved to apiVersion: networking.k8s.io/v1beta1 and more recently to apiVersion: networking.k8s.io/v1.
• Here is how these Ingress versions are supported in Kubernetes: - before Kubernetes 1.19, only v1beta1 Ingress resources are supported - from Kubernetes 1.19 to 1.21, both v1beta1 and v1 Ingress resources are supported - in Kubernetes 1.22 and above, only v1 Ingress resources are supported
• And here is how these Ingress versions are supported in NGINX Ingress Controller: - before version 1.0, only v1beta1 Ingress resources are supported - in version 1.0 and above, only v1 Ingress resources are
• As a result, if you're running Kubernetes 1.19 or later, you should be able to use the latest version of the NGINX Ingress Controller; but if you're using an old version of Kubernetes (1.18 or earlier) you will have to use version 0.X of the NGINX Ingress Controller (e.g. version 0.49).
• The Helm chart of the NGINX Ingress Controller switched to version 1 in version 4 of the chart. In other words, if you're running Kubernetes 1.19 or earlier, you should use version 3.X of the chart (this can be done by adding --version='<4' to the helm install command).