十八. Kubernetes Ingress

一. Ingress 基础解释

1. 官方文档
2. 什么是Ingress: Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP和HTTPS。Ingress 可以提供负载均衡、SSL 和基于名称的虚拟托管,提供了负载均衡,缓存, api网关防火墙等功能
3. 先说一下k8s中使用service方式对外暴露服务时的问题:

k8s 基于service对外暴露服务时主要有两种方式：NotePort, LoadBalance， 此外externalIPs也可以使各类service对外提供服务，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个service一个LB又有点浪费和麻烦，并且需要k8s之外的支持

1. 为什么需要Ingress?

1. Service可以使用NodePort暴露集群外访问端口,性能低,暴露端口不安全,并且例如大型应用集群使用该方式暴露时端口不够用,不好管理
2. 缺少Layer7的统一访问入口,可以负载均衡,限流等,也就是指没有应用层无法解析数据包,根据请求数据进行指定操作,例如根据请求参数路由,限流,负载等等
3. Ingress 公开了从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。
4. 使用Ingress作为整个集群统一的入口，配置Ingress规则,根据规则将请求转到对应的Service

1. ingress相当于一个7层的负载均衡器,可以看成一个网关，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则
   
2. ingress中包括：ingressController和ingressResources

1. ingress controller：是一个deployment，实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。
2. ingress resources：这个就是一个类型为Ingress的k8s api对象了，这部分则是面向开发人员

二. ingressController 安装

1. ingresscontroller：是一个deployment,实现方式有多种, 当前使用nginx,一个改版的nginx,也有两种IngressNginx和nginxIngress

1. IngressNginx: 这是k8s官方做的,会及时更新一些特性,性能很高,被广泛采用官方文档
2. nginxIngress: 这是nginx官方适配k8s做的分为开源版和nginx plus版(收费)文档地址

1. 实际整个ingress就可以理解为安装ingressController,而现在ingressController通常用改版的nginx, 所以ingressController就是一个nginx,反过来看ingress就是选择指定节点安装改版的nginx,通过这个nginx编写需要的yaml,实现指定功能,其中包含负载均衡,缓存, api网关防火墙等
2. 可以选择k8s中指定一个或多个节点部署ingressController也就是nginx,如果修改其中一个,会自动同步
3. 自建集群使用 裸金属安装方式需要如下修改：

1. 修改ingress-nginx-controller镜像为 registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/ingress-nginx- controller:v0.46.0
2. 修改Deployment为DaemonSet比较好
3. 修改Container使用主机网络，直接在主机上开辟 80,443端口，无需中间解析，速度更快
4. Container使用主机网络，对应的dnsPolicy策略也需要改为主机网络的
5. 修改Service为ClusterIP，无需NodePort模式了
6. 修改DaemonSet的nodeSelector: ingress-node=true 。这样只需要给node节点打上 ingress- node=true 标签，即可快速的加入/剔除 ingress-controller的数量

1. 安装完毕后,配置使用只需要编写Ingress的yaml文件即可, 一个Ingress的yaml配置文件就是nginx的一项应用配置
2. 另外还有nginx服务本身的全局配置

1. “kubectl edit cm ingress-nginx-controller -n ingress-nginx”
2. 修改配置添加"data: 配置项:配置值"保存退出即可
3. 服务本身配置项参考官方文档:configmap

1. 在使用ingressNginx时,给nginx添加功能只需要在编写nginx 的yaml应用配置项时配置一下对应的Annotations即可官方文档:annotations

六. ingress 使用示例

1. 选择k8s中指定一个或多个节点部署ingressController也就是nginx

1. 针对服务封装service,内网部署,对外关闭所有端口更安全,例如service使用ClusterIP或者无头服务类型
2. ingressController 选择指定k8s节点安装改版nginx,称为ingressNginx
3. 编写yaml配置nginx中监听的域名与对应service映射关系,通过nginx代理service服务,多个nginx域名配置完毕后会相互同步
4. 此时请求服务域名,先到达nginx,由nginx将请求发送给指定的service
5. 在nginx上层也可以添加负载均衡器(例如使用云服务商提供的负载均衡器,F5等),对nginx进行负载均衡
6. 此时我们只需要设置好域名与ip的映射关系,请求的域名被nginx拦截,然后负载到指定的service
   

1. 实际整个ingress就可以理解为安装ingressController,而现在ingressController通常用改版的nginx, 所以ingressController就是一个nginx,反过来看ingress就是选择指定节点安装改版的nginx,通过这个nginx编写需要的yaml,实现指定功能,其中包含负载均衡,缓存, api网关防火墙等
2. ingress yaml 示例,一个Ingress的yaml配置文件就是nginx的一项应用配置

rules中配置拦截"test.com"域名,使用Prefix 前缀匹配拦截前缀为"/bbbbbc/"请求,将这个请求,路由到名为cluster-service的service上

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: default
  annotations: #基于k8s注解为nginx添加其他功能,例如当前"nginx.ingress.kubernetes.io/limit-rps" 表示设置限流
    nginx.ingress.kubernetes.io/limit-rps: 1
spec:
  defaultBackend: #接收到未设置映射路径的请求时路由的目标服务,相当于提供一个默认值
    service:
      name: php-apache
      port:
        number: 80
  rules: #路由设置
  - host: test.com #指定监听的主机域名(对标以前nginx中监听的server中的域名)
    http: #指定请求路由规则
      paths:
      - path: /bbbbbc #拦截的url
        pathType: Prefix #匹配规则: Prefix前缀匹配, Exact精确匹配, ImplementationSpecific自定义匹配
        backend: #设置当前拦截请求路由到的目标service
          service:
            name: cluster-service #目标service名
            port:
              number: 80 #目标service端口号
           #resource: #指定资源
           
  - host: demo.com #指定监听的主机域名(对标以前nginx中监听的server中的域名)
    http: #指定请求路由规则
      paths:
      - path: /ssss #拦截的url
        pathType: Prefix #匹配规则: Prefix前缀匹配, Exact精确匹配, ImplementationSpecific自定义匹配
        backend: #设置当前拦截请求路由到的目标service
          service:
            name: cluster-service #目标service名
            port:
              number: 80 #目标service端口号
           #resource: #指定资源

1. ingress yaml编写完成后会应用到k8s安装的所有ingress nginx上,并且后续修改一个,多个nginx会互相同步

pathType 详细：

1. Prefix: 基于以 / 分隔的 URL 路径前缀匹配,区分大小写
2. Exact: 精确匹配 URL 路径，且区分大小写。
3. ImplementationSpecific: 对于这种路径类型，匹配方法取决于 IngressClass。 具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理

1. 注意如果没有指定路由规则

annotations 基于k8s注解为 nginx 添加功能示例

1. 在使用ingressNginx时,给nginx添加功能只需要在编写nginx 的yaml应用配置项时配置一下对应的Annotations即可官方文档:annotations
2. 以添加限流功能为例: 在文档上找到限流相关注解在Rate Limiting下,官方文档:Rate Limiting
   
   
3. yaml示例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: default
  annotations: #基于k8s注解为nginx添加其他功能,例如当前"nginx.ingress.kubernetes.io/limit-rps" 表示设置限流每秒允许一个请求
    nginx.ingress.kubernetes.io/limit-rps: 1 #添加限流功能,每秒允许一个请求
spec:
  defaultBackend: #接收到未设置映射路径的请求时路由的目标服务,相当于提供一个默认值
    service:
      name: php-apache
      port:
        number: 80
  rules: #路由设置
  - host: test.com #指定监听的主机域名(对标以前nginx中监听的server中的域名)
    http: #指定请求路由规则
      paths:
      - path: /bbbbbc #拦截的url
        pathType: Prefix #匹配规则: Prefix前缀匹配, Exact精确匹配, ImplementationSpecific自定义匹配
        backend: #设置当前拦截请求路由到的目标service
          service:
            name: cluster-service #目标service名
            port:
              number: 80 #目标service端口号
           #resource: #指定资源

路径重写

1. 接收请求时,重写原请求路径,使用"annotations:nginx.ingress.kubernetes.io/rewrite-target" 配置路径重写规则官方文档

1. 下方示例中实习效果,如果访问请求为"test.com/api/ssss",会将路径修改为"目标服务service名/sss"去除了"/api"
2. 使用场景: 例如前后端分离是,前后端代码部署在同一个服务器上,通过指定路径前缀判断访问前端还是后端,在访问后端时,去除标识前缀访问实际接口路径

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-aaa
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2 #保留的部分
spec:
  defaultBackend: ## 只要未指定的映射路径
    service:
      name: php-apache
      port:
        number: 80
  rules:
  - host: test.com #监听的域名
    http:
      paths:
      - path: /api(/|$)(.*) #path中需要使用正则表达式定义路径，并在rewrite-target中结合捕获组一起使用
        pathType: Prefix #拦截规则
        backend:
          service:
            name: test-service #目标service名字
            port:
              number: 80

Session Affinity 会话保持

1. 多副本负载均衡时,同一个用户的多次访问负载到同一个副本上官方文档
2. 部署一个三个Pod的Deployment并封装Service,用来测试Session Affinity

apiVersion: v1
kind: Service
metadata:
  name: session-affinity
  namespace: default
spec:
  selector:
    app: session-affinity
  type: ClusterIP
  ports:
  - name: session-affinity
    port: 80
    targetPort: 80
    protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name:  session-affinity
  namespace: default
  labels:
    app:  session-affinity
spec:
  selector:
    matchLabels:
      app: session-affinity
  replicas: 3
  template:
    metadata:
      labels:
        app:  session-affinity
    spec:
      containers:
      - name:  session-affinity
        image:  nginx

1. 编写具有会话亲和的ingress, 利用每次请求携带同样的cookie,来标识是否是同一个会话

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: session-test
  namespace: default
  annotations: #设置会话保持
    nginx.ingress.kubernetes.io/affinity: "cookie" #
    nginx.ingress.kubernetes.io/session-cookie-name: "key-session" #cookie名字
spec:
  rules:
  - host: test.com #监听域名
    http:
      paths:
      - path: /   #如果此处的路径以前有配置过,已最后一次为准
        pathType: Prefix
        backend:
          service:
            name: session-affinity #目标service名
            port:
              number: 80

1. 当设置了会话保持

1. 接收到请求后通过"nginx.ingress.kubernetes.io/affinity"会向相求中添加cookie参数,并且后续请求都会携带cookie,统一cookie下的请求会负载到同一个副本上
2. 默认cookie的key为"INGRESSCOOKIE",可以使用"nginx.ingress.kubernetes.io/session-cookie-name"自定义,

配置SSL

1. 首先要生成证书(也可以去青云申请免费证书进行配置)

//1.生成测试证书命令,解释:
//-x509:生成x509证书
//-days 365: 有效时间365天
//rsa:2048: 使用rsa的2048位加密算法
//tls.key: 指定证书的key文件
//tls.cert:指定证书文件
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.cert
-subj "/CN=组织机构域名.com/O=组织名.com"

//2.根据上面指定的证书key与证书文件执行命令,创建证书秘钥
kubectl create secret tls 生成秘钥文件名-tls --key tls.key --cert tls.cert

//3.查看秘钥资源命令,能获取到前面创建的秘钥文件
kubectl get secret 

//4.进入秘钥文件,以yaml展示,在文件内部有一个"tls.crt","tls.key"
kubectl get secret 秘钥文件名-tls -o yaml

1. 通过上面配置了免费的ssl证书,生成了秘钥文件,在编写ingress时,在内部的tls属性中配置即可

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: default
spec:
  tls:
   - hosts:
     - test.com #监听需要使用证书的域名
     secretName: 生成的秘钥文件-tls
  rules:
  - host: 监听域名.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-nginx-svc
            port:
              number: 80

灰度发布

1. k8s中可以使用Service配合Deployment进行金丝雀部署,但是不能自定义灰度逻辑，比如指定用户进行灰度,可以使用Ingress进行灰度
2. 基于Ingress中可以对请求拆解包,根据请求标识判断将请求路由到指定service官方文档:Canary实现流程

1. 在更新版本上线时,原版本service与对应的ingress继续提供服务,
2. 部署新版本的service,对应新版本的ingress
3. 新版本ingress与老版本的ingress监听相同域名, 但是新版本中配置获取请求中的指定参数标识,如果表示存在,才将请求路由到rules中配置的新版本service上

1. Ingress基于annotations注解实现金丝雀部署功能:

1. “nginx.ingress.kubernetes.io/canary”: 为true表示开启
2. 在获取路由表示时提供了:“canary-by-header”," canary-by-cookie"与"canary-weight"(权重)三种,可以共同作用,有优先级
3. 如果通过"canary-by-header"," canary-by-cookie"与"canary-weight"获取到了需要的请求参数,则将请求路由到rules中指定的service上

1. ingress金丝雀示例与以"nginx.ingress.kubernetes.io/canary-by-header"为例解释:

1. "nginx.ingress.kubernetes.io/canary-by-header"设置获取key为"headerKey"请求头参数
2. 默认情况下"headerKey"获取到的参数为"always"时将请求路由到下方rules指定的新表service上"v2-service",如果获取到的请求参数为"never",那么这个请求会通过原ingerss路由
3. 也可以通过对应的注解指定灰度标识值,例如"nginx.ingress.kubernetes.io/canary-by-header-value",设置参数为"ssss"表示当通过"headerKey"获取到的参数为"ssss"时,将请求路由到v2-service上

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-02-haha
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"  ## 代表这是金丝雀版本
    nginx.ingress.kubernetes.io/canary-by-header: "headerKey"  
    ## headerKey= always：流量路由到金丝雀版本
    ## headerKey= never: 流量永远不会路由到金丝雀版本
    # nginx.ingress.kubernetes.io/canary-by-header-value: "ssss"
    nginx.ingress.kubernetes.io/canary-by-cookie: "cccc"
    ## cccc = always：流量路由到金丝雀版本
    ## cccc = never: 流量永远不会路由到金丝雀版本
    nginx.ingress.kubernetes.io/canary-weight: "50" #权重,当前表示50%的到达下方的v2-service上
    ## 优先级:canary-by-header -> canary-by-cookie -> canary-weight

spec:
  rules:
  - host: test.canary.com #监听域名
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: v2-service #目标service
            port:
              number: 80