Kubernetes 对外服务

概述

Kubernetes 暴露服务的有三种方式：分别为 LoadBlancer Service、NodePort Service、Ingress。

官网对 Ingress 的定义为管理对外服务到集群内服务之间规则的集合，通俗点讲就是它定义规则来允许进入集群的请求被转发到集群中对应服务上，从来实现服务暴露。

Ingress 能把集群内 Service 配置成外网能够访问的 URL，流量负载均衡，终止SSL，提供基于域名访问的虚拟主机等等。

LoadBlancer

LoadBlancer Service 是 Kubernetes 结合云平台的组件，如国外 GCE、AWS、国内阿里云等等，使用它向使用的底层云平台申请创建负载均衡器来实现，有局限性，对于使用云平台的集群比较方便。

NodePort

NodePort Service 是通过在节点上暴露端口，然后通过将端口映射到具体某个服务上来实现服务暴露

对于集群来说，随着 Service 的不断增加，需要的端口越来越多，很容易出现端口冲突，而且不容易管理，当然对于小规模的集群服务，还是比较不错的。

Ingress

Ingress 使用开源的反向代理负载均衡器来实现对外暴漏服务，比如 Nginx、Apache、Haproxy等，用的最多的是使用nginx来做的，Nginx Ingress 一般有三个组件组成

ingress

ingress 是kubernetes的一个资源对象，用于编写定义规则。将nginx的配置抽象成一个Ingress对象，当用户每添加一个新的服务，只需要编写一个新的ingress的yaml文件即可

反向代理负载均衡器

通常以Service的Port方式运行，接收并按照ingress定义的规则进行转发，通常为nginx，haproxy，traefik等，本文使用nginx

ingress-controller

监听apiserver，获取服务新增，删除等变化，并结合ingress规则动态更新到反向代理负载均衡器上，并重载配置使其生效

整体结构

以上三者有机的协调配合起来，就可以完成 Kubernetes 集群服务的暴漏

Ingress-nginx介绍

Ingress-nginx组成

ingress-nginx-controller

根据用户编写的ingress规则（创建的ingress的yaml文件），动态的去更改nginx服务的配置文件，并且reload重载使其生效（是自动化的，通过lua脚本来实现）

ingress资源对象

将Nginx的配置抽象成一个Ingress对象，每添加一个新的Service资源对象只需写一个新的Ingress规则的yaml文件即可（或修改已存在的ingress规则的yaml文件）

Ingress 资源对象是 Kubernetes 内置定义的一个对象，是从 Kuberenets 集群外部访问集群的一个入口，将外部的请求转发到集群内不同的 Service 上，其实就相当于 nginx、haproxy 等负载均衡代理服务器，可能你会觉得我们直接使用 nginx 就实现了，但是只使用 nginx 这种方式有很大缺陷，每次有新服务加入的时候怎么改 Nginx 配置？不可能让我们去手动更改或者滚动更新前端的 Nginx Pod 吧？那我们再加上一个服务发现的工具比如 consul 如何(然后利用consul-template去自动刷新我们的nginx配置)？貌似是可以，对吧？Ingress 实际上就是这样实现的，只是服务发现的功能自己实现了，不需要使用第三方的服务了，然后再加上一个域名规则定义，路由信息的刷新依靠 Ingress Controller 来提供。

注意：这里写的是ingress，但其实是ingress-controller在起作用，这里的路由规则可能是一个域名，或者是一个Path路径，都是可以去做一个路由的匹配

组件说明

externalLB : 外部的4层负载均衡器
ingress-nginx : nodePort 类型的 service 为 ingress-nginx 的 pod 接入外部流量
ingress-nginx : ingress-nginx pod, 负责创建负载均衡
Ingress 根据后端 Service 实时识别分类及 IP 把结果生成配置文件注入到 ingress-nginx pod 中
site1 : Service 对后端的pod 进行分类(只起分类作用)

Ingress工作原理

Ingress 的实现分为两个部分 Ingress Controller 和 Ingress

截至目前，nginx-ingress 已经能够完成 7/4 层的代理功能（4 层代理基于 ConfigMap，感觉还有改进的空间）；Nginx 的 7 层反向代理模式，可以简单用下图表示：

Nginx 对后端运行的服务（Service1、Service2）提供反向代理，在配置文件中配置了域名与后端服务 Endpoints 的对应关系。
客户端通过使用 DNS 服务或者直接配置本地的 hosts 文件，将域名都映射到 Nginx 代理服务器。
当客户端访问 service1.com 时，浏览器会把包含域名的请求发送给 nginx 服务器，nginx 服务器根据传来的域名，选择对应的 Service，这里就是选择 Service 1 后端服务，然后根据一定的负载均衡策略，选择 Service1 中的某个容器接收来自客户端的请求并作出响应。

过程很简单，nginx 在整个过程中仿佛是一台根据域名进行请求转发的“路由器”，这也就是7层代理的整体工作流程了！

工作原理

对于 Nginx 反向代理做了什么，我们已经大概了解了

在 k8s 系统中，后端服务的变化是十分频繁的，单纯依靠人工来更新nginx 的配置文件几乎不可能，nginx-ingress 由此应运而生，Nginx-ingress 通过监视 k8s 的资源状态变化实现对 nginx 配置文件的自动更新

nginx-ingress 模块在运行时主要包括三个主体：NginxController、Store、SyncQueue。
Store 主要负责从 kubernetes APIServer 收集运行时信息，感知各类资源（如 ingress、service等）的变化，并及时将更新事件消息（event）写入一个环形管道。
SyncQueue 协程定期扫描 syncQueue 队列，发现有任务就执行更新操作，即借助 Store 完成最新运行数据的拉取，然后根据一定的规则产生新的 nginx 配置，（有些更新必须 reload，就本地写入新配置，执行 reload），然后执行动态更新操作，即构造 POST 数据，向本地 Nginx Lua 服务模块发送 post 请求，实现配置更新。
NginxController 作为中间的联系者，监听 updateChannel，一旦收到配置更新事件，就向同步队列 syncQueue 里写入一个更新请求。

Ingress解决痛点

动态配置服务

如果按照传统方式，当新增加一个服务时，我们可能需要在流量入口加一个反向代理指向我们新的服务，而使用ingress，只需要配置好ingress，当服务启动时，会自动注册到ingress当中，不需要额外的操作。

减少不必要的Port暴露

我们知道部署k8s时，是需要关闭防火墙的，主要原因是k8s的很多服务会以nodeport方式映射出去，这样对于宿主机来说是非常的不安全的，而ingress可以避免这个问题，只需要将ingress自身服务映射出去，就可代理后端所有的服务，则后端服务不需要映射出去。

安装Ingress-nginx

可以将上面的Ingress理解为在集群的前端加了一个Nginx，用来提供Nginx所能提供的一切功能，例如基于url的反向代理，https认证，用户鉴权，域名重定向等等

注意事项

需要注意以下几点

Nginx是基于url的，如果没有DNS解析url到集群中任意ip可以考虑hosts文件劫持
Nginx的本质也是NodePort的方式暴露给集群外的一个特殊Service
Nginx的配置文件根据Ingress的规则自动添加和修改

拉取配置

从GitHub上下载yaml文件：官方地址，注意对应k8s版本

1	wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

如果上面地址下载失败，可以使用最后完整的配置文件，如果使用官网的，可能需要换镜像地址，因为官网下载的镜像很大可能会失败

修改镜像资源地址

由于官网镜像国内网络无法下载，所以我们需要修改yaml规约文件中的镜像资源地址。主要修改两个镜像资源如下：

registry.k8s.io/ingress-nginx/controller
registry.k8s.io/ingress-nginx/kube-webhook-certgen

我们使用阿里云的镜像资源地址阿里云镜像仓库,注意实现需要登录才能进入查找镜像

点进去查看奖项详情

使用阿里云的镜像地址替换掉k8s官网的镜像地址

对于kube-webhook-certgen操作时一样的，只是搜索替换的换成kube-webhook-certgen

编辑配置

注意注释掉 externalTrafficPolicy: Local的配置

完整配置

完整的配置如下，可以直接使用

1	vi deploy.yaml

对照如下deploy.yaml

apiVersion: v1
kind: Namespace
metadata:
  labels:
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  name: ingress-nginx
---
apiVersion: v1
automountServiceAccountToken: true
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx
  namespace: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission
  namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx
  namespace: ingress-nginx
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - configmaps
  - pods
  - secrets
  - endpoints
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses/status
  verbs:
  - update
- apiGroups:
  - networking.k8s.io
  resources:
  - ingressclasses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resourceNames:
  - ingress-controller-leader
  resources:
  - configmaps
  verbs:
  - get
  - update
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission
  namespace: ingress-nginx
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - nodes
  - pods
  - secrets
  - namespaces
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses/status
  verbs:
  - update
- apiGroups:
  - networking.k8s.io
  resources:
  - ingressclasses
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission
rules:
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - validatingwebhookconfigurations
  verbs:
  - get
  - update
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx
  namespace: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ingress-nginx
subjects:
- kind: ServiceAccount
  name: ingress-nginx
  namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission
  namespace: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
  name: ingress-nginx-admission
  namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ingress-nginx
subjects:
- kind: ServiceAccount
  name: ingress-nginx
  namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
  name: ingress-nginx-admission
  namespace: ingress-nginx
---
apiVersion: v1
data:
  allow-snippet-annotations: "true"
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-controller
  namespace: ingress-nginx
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  #externalTrafficPolicy: Local
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - appProtocol: http
    name: http
    port: 80
    protocol: TCP
    targetPort: http
  - appProtocol: https
    name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-controller-admission
  namespace: ingress-nginx
spec:
  ports:
  - appProtocol: https
    name: https-webhook
    port: 443
    targetPort: webhook
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  minReadySeconds: 0
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/component: controller
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/name: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/component: controller
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: ingress-nginx
    spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
        - --election-id=ingress-controller-leader
        - --controller-class=k8s.io/ingress-nginx
        - --ingress-class=nginx
        - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
        - --validating-webhook=:8443
        - --validating-webhook-certificate=/usr/local/certificates/cert
        - --validating-webhook-key=/usr/local/certificates/key
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: LD_PRELOAD
          value: /usr/local/lib/libmimalloc.so
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.2.1
        imagePullPolicy: IfNotPresent
        lifecycle:
          preStop:
            exec:
              command:
              - /wait-shutdown
        livenessProbe:
          failureThreshold: 5
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: controller
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        - containerPort: 443
          name: https
          protocol: TCP
        - containerPort: 8443
          name: webhook
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          requests:
            cpu: 100m
            memory: 90Mi
        securityContext:
          allowPrivilegeEscalation: true
          capabilities:
            add:
            - NET_BIND_SERVICE
            drop:
            - ALL
          runAsUser: 101
        volumeMounts:
        - mountPath: /usr/local/certificates/
          name: webhook-cert
          readOnly: true
      dnsPolicy: ClusterFirst
      nodeSelector:
        kubernetes.io/os: linux
      serviceAccountName: ingress-nginx
      terminationGracePeriodSeconds: 300
      volumes:
      - name: webhook-cert
        secret:
          secretName: ingress-nginx-admission
---
apiVersion: batch/v1
kind: Job
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission-create
  namespace: ingress-nginx
spec:
  template:
    metadata:
      labels:
        app.kubernetes.io/component: admission-webhook
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
        app.kubernetes.io/version: 1.2.1
      name: ingress-nginx-admission-create
    spec:
      containers:
      - args:
        - create
        - --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc
        - --namespace=$(POD_NAMESPACE)
        - --secret-name=ingress-nginx-admission
        env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.1.1
        imagePullPolicy: IfNotPresent
        name: create
        securityContext:
          allowPrivilegeEscalation: false
      nodeSelector:
        kubernetes.io/os: linux
      restartPolicy: OnFailure
      securityContext:
        fsGroup: 2000
        runAsNonRoot: true
        runAsUser: 2000
      serviceAccountName: ingress-nginx-admission
---
apiVersion: batch/v1
kind: Job
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission-patch
  namespace: ingress-nginx
spec:
  template:
    metadata:
      labels:
        app.kubernetes.io/component: admission-webhook
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
        app.kubernetes.io/version: 1.2.1
      name: ingress-nginx-admission-patch
    spec:
      containers:
      - args:
        - patch
        - --webhook-name=ingress-nginx-admission
        - --namespace=$(POD_NAMESPACE)
        - --patch-mutating=false
        - --secret-name=ingress-nginx-admission
        - --patch-failure-policy=Fail
        env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.1.1
        imagePullPolicy: IfNotPresent
        name: patch
        securityContext:
          allowPrivilegeEscalation: false
      nodeSelector:
        kubernetes.io/os: linux
      restartPolicy: OnFailure
      securityContext:
        fsGroup: 2000
        runAsNonRoot: true
        runAsUser: 2000
      serviceAccountName: ingress-nginx-admission
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: nginx
spec:
  controller: k8s.io/ingress-nginx
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.2.1
  name: ingress-nginx-admission
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: ingress-nginx-controller-admission
      namespace: ingress-nginx
      path: /networking/v1/ingresses
  failurePolicy: Fail
  matchPolicy: Equivalent
  name: validate.nginx.ingress.kubernetes.io
  rules:
  - apiGroups:
    - networking.k8s.io
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - ingresses
  sideEffects: None

应用配置

1	kubectl apply -f deploy.yaml

查看详情

我们可以通过如下命令查看部署详情

1	kubectl get pod -ningress-nginx

出现如下状状态表示已经部署成功

解决LoadBalancer问题

查看service详情

下面我们看下Service的详情

1	kubectl get service -n ingress-nginx

我们发现ingress-nginx-controller的EXTERNAL-IP处于pending状态，这是因为service类型是LoadBalancer，需要有外部负载均衡器来分配IP，如果没有事先安装负载均衡器，就会一直处于pending状态

安装MetalLB

我们可以事先安装MetalLB负载均衡器来解决这个办法，具体安装可以参考《MetalLB 安装》

查看service详情

安装完成MetalLB 后再次查看service详情

1	kubectl get service -n ingress-nginx

我们发现这个时候EXTERNAL-IP已经有值了

查看Controller日志

1	kubectl logs -f ingress-nginx-controller-97bf8bdc7-q8pg7 -n ingress-nginx

当看到下面的信息证明 ingress-nginx 部署成功了，这里我们安装的是最新版本的控制器

查看ingressclass

安装完成后会自动创建一个名为 nginx 的 IngressClass 对象

1	kubectl get ingressclass

创建Ingress-nginx

下面就来创建我们自己的Ingress-nginx

创建资源清单

创建Nginx服务

1	vi nginx_nodeport.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes: 
        - name: html
          emptyDir: {}
      containers:
      - name: nginx
        image: docker.io/library/nginx:1.20
        ports:
        - containerPort: 80
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      - name: sidecar
        image: docker.io/library/alpine
        volumeMounts:
        - name: html
          mountPath: /html
        command: ["/bin/sh", "-c"]
        args:
        - while true; do
            echo $(hostname) $(date) >> /html/index.html;
          sleep 6000;
          done
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32134

创建Tomcat服务

1	vi tomcat_nodeport.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tomcat
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat-pod
        image: docker.io/library/tomcat:9.0
---
apiVersion: v1
kind: Service
metadata:
  name: tomcat-svc
spec:
  type: NodePort
  selector:
    app: tomcat
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
    nodePort: 32135

创建资源清单

1 2	kubectl apply -f nginx_nodeport.yaml kubectl apply -f tomcat_nodeport.yaml

查看部署

1 2	kubectl get pod -o wide kubectl get service -o wide

可以看到通过nodeport暴露的方式是没有问题的，但是到该种方式在大规模的集群服务中，有很大的缺陷，所以接下来通过ingress-nginx进行实现。

创建ingress规则

创建该规则就是用于分别代理后端的tomcat和nginx服务

在下面的 Ingress 资源对象中我们使用配置 ingressClassName: nginx 指定让我们安装的 ingress-nginx 这个控制器来处理我们的 Ingress 资源，配置的匹配路径类型为前缀的方式去匹配 /，将来自域名ingress.test.com 的所有请求转发到 my-nginx 服务的后端 Endpoints 中去

1	vi ingress-rule.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx #使用 nginx 的 IngressClass（关联的 ingress-nginx 控制器）
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /   #nginx的网页根目录：/
        pathType: Prefix
        backend:
          service: #将所有请求发送到 my-nginx 服务的 80 端口
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

注意：不过需要注意大部分Ingress控制器都不是直接转发到Service,而是只是通过Service来获取后端的Endpoints列表(因此这里的svc只起到了一个服务发现的作用)，直接转发到Pod，这样可以减少网络跳转，提高性能!!!

应用配置

1
2
3

kubectl apply -f ingress-rule.yaml
# 查看绑定信息
kubectl get ingresses -o wide

我们发现地址地址栏已经显示虚拟IP了，代表我们已经部署成功

查看配置详情

1 2	# 查看describe查看详细信息 kubectl describe ingress test-ingress

查看配置规则

test-ingress 启动后会自动创建nginx转换规则，我们可以看下配置规则

1
2
3

kubectl get pods -n ingress-nginx
kubectl exec -it ingress-nginx-controller-97bf8bdc7-q8pg7 -n ingress-nginx -- bash
# cat nginx.conf

通过查看nginx配置文件，我们可以清楚的知道之前所说的ingress-controller会根据我们编写的ingress规则（代理后端应用），动态的去更改nginx的配置文件

请求访问

下面我们演示下如何使用域名进行请求访问集群内的服务

配置Host文件

因为基于nginx的请求，并且配置了虚拟主机，我们第一步是配置一下host文件，将我们的虚拟IP配置上去

1	vi /etc/hosts

在windows主机上将node02的ip地址添加到hosts文件中，做域名解析：#修改路径：C:\Windows\System32\drivers\etc\hosts（需要给予修改权限）

1	192.168.245.100 ingress.test.com

请求Nginx

我们可以通过浏览器请求nginx，并且多长访问发现可以负载均衡

1	http://ingress.test.com/

请求Tomcat

1	http://ingress.test.com/tomcat

我们发现出现了经典的404页面

请求流程

下图显示了客户端是如何通过 Ingress 控制器连接到其中一个 Pod 的流程

客户端首先对ingress.test.com执行 DNS 解析，得到 Ingress 控制器所在节点的 IP，然后客户端向 Ingress 控制器发送 HTTP 请求，然后根据 Ingress 对象里面的描述匹配域名，找到对应的 Service 对象，并获取关联的 Endpoints 列表，将客户端的请求转发给其中一个 Pod

Ingress-Nginx高级使用

下面是一些常用的配置，如果我们还想进行一些自定义配置，则有几种方式可以实现：使用 Configmap 在 Nginx 中设置全局配置、通过 Ingress 的 Annotations 设置特定 Ingress 的规则、自定义模板

配置TLS

通过部署ingress后，我们现在使用的是http的方式，为后端应用的安全考虑为所有的pod都颁发一个证书，我们只需为ingress代理的域名颁发证书就能够实现

TLS概述

Ingress 资源对象还可以用来配置 Https 的服务，可以通过设定包含 TLS 私钥和证书的 Secret 来保护 Ingress。 Ingress 只支持单个 TLS 端口 443，如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用，需要注意 TLS Secret 必须包含名为 tls.crt 和 tls.key 的键名

创建CA证书

我们先创建一个证书

1
2
3

mkdir ssl&&cd ssl
openssl genrsa -out nginx.key 2048
openssl req -new -x509 -key nginx.key -out nginx.crt -subj /C=CN/ST=Beijing/L=Beijing/O=ssltest/CN=ingress.test.com

其中CN=ingress.test.com为想要访问的域名

创建secret

我们创建一个保存nginx私钥的secret

1	kubectl create secret tls nginx-secret --cert=nginx.crt --key=nginx.key

编辑ingress配置

1	vi ingress-rule.yaml

在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道，我们需要确保创建的 TLS Secret 创建自包含 ingress.test.com 的公用名称的证书

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ingress.test.com
    secretName: nginx-secret
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /   #nginx的网页根目录：/
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

应用配置

1	kubectl apply -f ingress-rule.yaml

验证访问

直接在浏览器中访问http://ingress.test.com/，我们发现已经可以进行https访问

内部认证

在 Ingress 对象上配置一些基本的 Auth 认证，比如 Basic Auth

创建密码文件

我们可以在 Ingress 对象上配置一些基本的 Auth 认证，比如 Basic Auth，可以用 htpasswd 生成一个密码文件来验证身份验证

#记得安装下httpd-tools软件包，htpasswd命令依赖于这个软件包
yum install -y httpd-tools
mkdir basic-auth&&cd basic-auth
#htpasswd创建一个auth的密码文件，用户名是root
htpasswd -c auth root
cat auth

输入的用户名和密码都是root

创建secret

下面需要创建一个secret的对象保存密码

1 2	kubectl create secret generic basic-auth --from-file=auth kubectl describe secrets basic-auth

然后根据上面的 auth 文件创建一个 secret 对象

编辑Ingress文件

1	vi ingress-rule.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic  # 认证类型
    nginx.ingress.kubernetes.io/auth-secret: basic-auth  # 包含 user/password 定义的 secret 对象名
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - root'  # 要显示的带有适当上下文的消息，说明需要身份验证的原因
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ingress.test.com
    secretName: nginx-secret
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /   #nginx的网页根目录：/
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

应用配置

然后对上面的 my-nginx 应用创建一个具有 Basic Auth 的 Ingress 对象

1	kubectl apply -f ingress-rule.yaml

验证访问

直接在浏览器中访问http://ingress.test.com/，然后通过下面的命令或者在浏览器中直接打开配置的域名进行测试，我们发现已经需要输入用户名密码了

输入用户名密码后就可以正常访问了

外部认证

除了可以使用我们自己在本地集群创建的 Auth 信息之外，还可以使用外部的 Basic Auth 认证信息

查看外部认证

比如我们使用 https://httpbin.org (国外网站，打开贼慢😓)的外部 Basic Auth 认证，创建如下所示的 Ingress 资源对象：

编辑Ingress文件

1	vi ingress-rule.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    # 配置外部认证服务地址，最后路径是用户名密码 user/passwd
    nginx.ingress.kubernetes.io/auth-url: https://httpbin.org/basic-auth/user/passwd
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ingress.test.com
    secretName: nginx-secret
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /   #nginx的网页根目录：/
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

应用配置

1	kubectl apply -f ingress-rule.yaml

验证访问

上面的资源对象创建完成后，直接在浏览器中访问http://ingress.test.com/，再进行简单的测试

输入用户名密码user/passwd 就可以访问了

URL重写

URL重写概述

ingress-nginx 很多高级的用法可以通过 Ingress 对象的 annotation 进行配置，比如常用的 URL Rewrite 功能。很多时候我们会将 ingress-nginx 当成网关使用，比如对访问的服务加上 /app 这样的前缀，在 nginx 的配置里面我们知道有一个 proxy_pass 指令可以实现：

1
2
3

location /app/ {
  proxy_pass http://127.0.0.1/remote/;
}

可能要加上/app，或者/gateway，/api，特别是在我们微服务里，我们很多时候要把我们的微服务提供的一些接口给它聚合在某一个子路径下面去，比如果/api.或者/api/v1下面，当然这些功能我们可以直接在网关层ingress这里实现这样的功能。

proxy_pass 后面加了 /remote 这个路径，此时会将匹配到该规则路径中的 /app 用 /remote 替换掉，相当于截掉路径中的 /app。同样的在 Kubernetes 中使用 ingress-nginx 又该如何来实现呢？我们可以使用 rewrite-target 的注解来实现这个需求。比如现在我们想要通过 rewrite.qikqiak.com/gateway/ 来访问到 Nginx 服务，则我们需要对访问的 URL 路径做一个 Rewrite，在 PATH 中添加一个 gateway 的前缀，关于 Rewrite 的操作在 ingress-nginx 官方文档中也给出对应的说明:

rewrite-target

按照要求我们需要在 path 中匹配前缀 nginx，然后通过 rewrite-target 指定目标

效果说明

我们当前访问https://ingress.test.com/nginx显示如下界面

我们的效果是访问https://ingress.test.com/nginx相当于访问https://ingress.test.com/

编辑资源清单

1	vi ingress-rule.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ingress.test.com
    secretName: nginx-secret
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /nginx(/|$)(.*) #(/|$)代表可能/nginx 或者/nginx/
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

应用配置

1	kubectl apply -f ingress-rule.yaml

验证访问

更新后，我们可以预见到直接访问域名肯定是不行了，因为我们没有匹配 / 的 path 路径

但是我们带上 nginx 的前缀再去访问:

我们可以看到已经可以访问到了，这是因为我们在 path 中通过正则表达式/nginx(/|$)(.*) 将匹配的路径设置成了 rewrite-target 的目标路径了，所以我们访问https://ingress.test.com/nginx 的时候实际上相当于访问的就是后端/了

app-root

要解决我们访问主域名出现 404 的问题，我们可以给应用设置一个 app-root 的注解，这样当我们访问主域名的时候会自动跳转到我们指定的 app-root 目录下面

编辑资源清单

1	vi ingress-rule.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/app-root: /nginx/ #修改点1：添加app-root注解
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ingress.test.com
    secretName: nginx-secret
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /nginx(/|$)(.*) #(/|$)代表可能/nginx 或者/nginx/
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

应用配置

1	kubectl apply -f ingress-rule.yaml

验证访问

这个时候我们更新应用后访问主域名 ingress.test.com 就会自动跳转到 ingress.test.com/nginx/ 路径下面去了

configuration-snippet

但是还有一个问题是我们的 path 路径其实也匹配了 /app 这样的路径，可能我们更加希望我们的应用在最后添加一个 / 这样的 slash

编辑资源清单

1	vi ingress-rule.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/app-root: /nginx/
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/configuration-snippet: | #修改点1：
      rewrite ^(/gateway)$ $1/ redirect;
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ingress.test.com
    secretName: nginx-secret
  rules:
  - host: ingress.test.com   #后端应用通过该域名进行访问
    http:
      paths:
      - path: /nginx(/|$)(.*) #(/|$)代表可能/nginx 或者/nginx/
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
      - path: /tomcat   #tomcat的网页更目录：/tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-svc
            port:
              number: 8080

应用配置

1	kubectl apply -f ingress-rule.yaml

验证访问

更新后我们的应用就都会以 / 这样的 slash 结尾了，这样就完成了我们的需求，如果你原本对 nginx 的配置就非常熟悉的话应该可以很快就能理解这种配置方式了

灰度发布

在日常工作中我们经常需要对服务进行版本更新升级，所以我们经常会使用到滚动升级、蓝绿发布、灰度发布等不同的发布操作。

而 ingress-nginx 支持通过 Annotations 配置来实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景

发布规则

ngress-nginx可以通过annotations实现不同的发布规则

注意：金丝雀规则按优先顺序进行排序：canary-by-header > canary-by-cookie > canary-weight

nginx.ingress.kubernetes.io/canary-by-header

基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always 时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较

nginx.ingress.kubernetes.io/canary-by-header-value

要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (canary-by-header) 一起使用。

nginx.ingress.kubernetes.io/canary-weight

基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求，权重为 100 意味着所有请求都将被发送到 Canary 入口。

基于 cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always 时，它将被路由到 Canary 入口；当 cookie 值设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

规则分类

总的来说可以把以上的四个 annotation 规则划分为以下两类：

基于权重的 Canary 规则

基于用户请求的 Canary 规则

环境准备

创建Production资源清单

首先创建一个 production 环境的应用资源清单

1	vi production.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: production
  template:
    metadata:
      labels:
        app: production
    spec:
      volumes:
        - name: html
          emptyDir: {}
      containers:
      - name: nginx
        image: docker.io/library/nginx:1.20
        ports:
        - containerPort: 80
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      - name: sidecar
        image: docker.io/library/alpine
        volumeMounts:
        - name: html
          mountPath: /html
        command: ["/bin/sh", "-c"]
        args:
        - while true; do
            echo 'production' >> /html/index.html;
          sleep 6000;
          done
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc-production
spec:
  selector:
    app: production
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: production
spec:
  ingressClassName: nginx
  rules:
  - host: ingress.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-production
            port:
              number: 80

创建Canary资源清单

参考将上述 Production 版本的 production.yaml 文件，再创建一个 Canary 版本的应用

1	vi canary.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-canary
spec:
  replicas: 2
  selector:
    matchLabels:
      app: canary
  template:
    metadata:
      labels:
        app: canary
    spec:
      volumes:
        - name: html
          emptyDir: {}
      containers:
      - name: nginx
        image: docker.io/library/nginx:1.20
        ports:
        - containerPort: 80
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      - name: sidecar
        image: docker.io/library/alpine
        volumeMounts:
        - name: html
          mountPath: /html
        command: ["/bin/sh", "-c"]
        args:
        - while true; do
            echo 'canary' >> /html/index.html;
          sleep 6000;
          done
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc-canary
spec:
  selector:
    app: canary
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

创建应用

1 2	kubectl apply -f production.yaml kubectl apply -f canary.yaml

接下来就可以通过配置 Annotation 规则进行流量切分了

基于权重

基于权重的流量切分的典型应用场景就是蓝绿部署，可通过将权重设置为 0 或 100 来实现。

例如，可将 Green 版本设置为主要部分，并将 Blue 版本的入口配置为 Canary，最初，将权重设置为 0，因此不会将流量代理到 Blue 版本，一旦新版本测试和验证都成功后，即可将 Blue 版本的权重设置为 100，即所有流量从 Green 版本转向 Blue

创建Ingress

创建一个基于权重的 Canary 版本的应用路由 Ingress 对象

1	vi canary-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"   # 要开启灰度发布机制，首先需要启用 Canary
    nginx.ingress.kubernetes.io/canary-weight: "30"  # 分配30%流量到当前Canary版本
spec:
  ingressClassName: nginx
  rules:
  - host: ingress.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-canary
            port:
              number: 80

应用配置

1	kubectl apply -f canary-ingress.yaml

验证测试

Canary 版本应用创建成功后，接下来我们在命令行终端中来不断访问这个应用，观察返回内容的变化

1	for i in $(seq 1 10); do curl -s ingress.test.com ;done;

由于我们给 Canary 版本应用分配了 30% 左右权重的流量，所以上面我们访问10次有3次访问到了 Canary 版本的应用，符合我们的预期

基于Request Header

基于Request Header 进行流量切分的典型应用场景即灰度发布或 A/B 测试场景。

在上面的 Canary 版本的 Ingress 对象中新增一条 annotation 配置 nginx.ingress.kubernetes.io/canary-by-header: canary（这里的 value 可以是任意值），使当前的 Ingress 实现基于 Request Header 进行流量切分，由于 canary-by-header 的优先级大于canary-weight，所以会忽略原有的 canary-weight 的规则

编辑资源清单

1	vi canary-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"   # 要开启灰度发布机制，首先需要启用 Canary
    nginx.ingress.kubernetes.io/canary-by-header: canary  # 基于header的流量切分
    nginx.ingress.kubernetes.io/canary-weight: "30"  # 分配30%流量到当前Canary版本
spec:
  ingressClassName: nginx
  rules:
  - host: ingress.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-canary
            port:
              number: 80

应用配置

1	kubectl apply -f canary-ingress.yaml

请求访问

更新上面的 Ingress 资源对象后，我们在请求中加入不同的 Header 值，再次访问应用的域名。

注意：当 Request Header 设置为 never 或 always 时，请求将不会或一直被发送到 Canary 版本，对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他 Canary 规则进行优先级的比较。

1	for i in $(seq 1 10); do curl -s -H "canary:never" ingress.test.com ;done;

这里我们在请求的时候设置了 canary: never 这个 Header 值，所以请求没有发送到 Canary 应用中去，如果设置为其他值呢：

1	for i in $(seq 1 10); do curl -s -H "canary:other-value" ingress.test.com ;done;

由于我们请求设置的 Header 值为 canary: other-value，所以 ingress-nginx 会通过优先级将请求与其他 Canary 规则进行优先级的比较，我们这里也就会进入 canary-weight: "30" 这个规则去

修改规则

这个时候我们可以在上一个 annotation (即 canary-by-header）的基础上添加一条 nginx.ingress.kubernetes.io/canary-by-header-value: user-value 这样的规则，就可以将请求路由到 Canary Ingress 中指定的服务了

1	vi canary-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"   # 要开启灰度发布机制，首先需要启用 Canary
    nginx.ingress.kubernetes.io/canary-by-header-value: user-value
    nginx.ingress.kubernetes.io/canary-by-header: canary  # 基于header的流量切分
    nginx.ingress.kubernetes.io/canary-weight: "30"  # 分配30%流量到当前Canary版本
spec:
  ingressClassName: nginx
  rules:
  - host: ingress.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-canary
            port:
              number: 80

同样更新 Ingress 对象后，重新访问应用，当 Request Header 满足 canary: user-value时，所有请求就会被路由到 Canary 版本：

1	for i in $(seq 1 10); do curl -s -H "canary:user-value" ingress.test.com ;done;

与基于 Request Header 的 annotation 用法规则类似

例如在 A/B 测试场景下，需要让地域为北京的用户访问 Canary 版本，那么当 cookie 的 annotation 设置为 nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing"，此时后台可对登录的用户请求进行检查，如果该用户访问源来自北京则设置 cookie users_from_Beijing 的值为 always，这样就可以确保北京的用户仅访问 Canary 版本。

编辑资源清单

同样我们更新 Canary 版本的 Ingress 资源对象，采用基于 Cookie 来进行流量切分

1	vi canary-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"   # 要开启灰度发布机制，首先需要启用 Canary
    nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing"  # 基于 cookie
    nginx.ingress.kubernetes.io/canary-weight: "30"  # 分配30%流量到当前Canary版本
spec:
  ingressClassName: nginx
  rules:
  - host: ingress.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-canary
            port:
              number: 80

应用配置

1	kubectl apply -f canary-ingress.yaml

请求访问

更新上面的 Ingress 资源对象后，我们在请求中设置一个 users_from_Beijing=always 的 Cookie 值，再次访问应用的域名

1	for i in $(seq 1 10); do curl -s -b "users_from_Beijing=always" ingress.test.com ;done;

我们可以看到应用都被路由到了 Canary 版本的应用中去了，如果我们将这个 Cookie 值设置为 never，则不会路由到 Canary 应用中