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).
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/apink/p/15703192.html