Kubernetes 使用 Ingress 实现灰度发布功能

使用 Ingress 实现灰度发布

一、Canary 规则说明

Ingress-Nginx 是一个K8S ingress工具，支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试（ Ingress-Nginx 是在0.21.0 版本中，引入的Canary 功能）。 Nginx Annotations 支持以下 4 种 Canary 规则：

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

注意：金丝雀规则按优先顺序进行如下排序：

canary-by-header - > canary-by-cookie - > canary-weight

我们可以把以上的四个 annotation 规则可以总体划分为以下两类：

基于权重的 Canary 规则：

基于用户请求的 Canary 规则：

二、部署测试用例

1. 部署正式版本服务

首先创建一个 deployment 代表正式版本的服务，编写 yaml 内容如下：

---

apiVersion: v1

kind: Namespace

metadata:

  name: ns-myapp

  labels:

    name: ns-myapp

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: production

  namespace: ns-myapp

spec:

  replicas: 1

  selector:

    matchLabels:

      app: production

  template:

    metadata:

      labels:

        app: production

    spec:

      containers:

      - name: production

        image: mirrorgooglecontainers/echoserver:1.10

        ports:

        - containerPort: 8080

        env:

          - name: NODE_NAME

            valueFrom:

              fieldRef:

                fieldPath: spec.nodeName

          - name: POD_NAME

            valueFrom:

              fieldRef:

                fieldPath: metadata.name

          - name: POD_NAMESPACE

            valueFrom:

              fieldRef:

                fieldPath: metadata.namespace

          - name: POD_IP

            valueFrom:

              fieldRef:

                fieldPath: status.podIP

---

apiVersion: v1

kind: Service

metadata:

  name: production

  namespace: ns-myapp

  labels:

    app: production

spec:

  ports:

  - port: 80

    targetPort: 8080

    protocol: TCP

    name: http

  selector:

    app: production

为这个服务创建 Ingress 路由规则，yaml 文件内容如下：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: production

  namespace: ns-myapp

  annotations:

    kubernetes.io/ingress.class: nginx

spec:

  rules:

  - host: ingress.test.com

    http:

      paths:

      - backend:

          serviceName: production

          servicePort: 80

应用以上 yaml 文件，创建完成后在 k8s 中查看到如下信息：

[k8s-master ~]# kubectl get ingress -n ns-myapp

NAME         CLASS    HOSTS              ADDRESS        PORTS   AGE

production   <none>   ingress.test.com   10.16.13.201   80      4m25s

[k8s-master ~]# kubectl get pod -n ns-myapp

NAME                          READY   STATUS    RESTARTS   AGE

production-5698c4565c-jmjn5   1/1     Running   0          7m11s

此时在命令行中访问 ingress.test.com 可以看到如下内容：

# curl ingress.test.com

Hostname: production-5698c4565c-jmjn5

Pod Information:

	node name:	dumlog013201

	pod name:	production-5698c4565c-jmjn5

	pod namespace:	ns-myapp

	pod IP:	10.42.0.74

Server values:

	server_version=nginx: 1.13.3 - lua: 10008

Request Information:

	client_address=10.16.13.201

	method=GET

	real path=/

	query=

	request_version=1.1

	request_scheme=http

	request_uri=http://ingress.test.com:8080/

Request Headers:

	accept=*/*

	host=ingress.test.com

	user-agent=curl/7.64.1

	x-forwarded-for=10.2.130.18

	x-forwarded-host=ingress.test.com

	x-forwarded-port=80

	x-forwarded-proto=http

	x-real-ip=10.2.130.18

	x-request-id=3019362be59228ee2284f5737fa39eb1

	x-scheme=http

Request Body:

	-no body in request-

2. 部署 Canary 版本服务

接下来创建一个 Canary 版本的服务，用于作为灰度测试。

参考将上述 Production 版本的 production.yaml 文件，再创建一个 Canary 版本的应用，包括一个 Canary 版本的 deployment 和 service (为方便快速演示，仅需将 production.yaml 的 deployment 和 service 中的关键字 production 直接替换为 canary，实际场景中可能涉及业务代码变更)。

三、基于权重的 Canary 规则测试

基于权重的流量切分的典型应用场景就是蓝绿部署，可通过将权重设置为 0 或 100 来实现。例如，可将 Green 版本设置为主要部分，并将 Blue 版本的入口配置为 Canary。最初，将权重设置为 0，因此不会将流量代理到 Blue 版本。一旦新版本测试和验证都成功后，即可将 Blue 版本的权重设置为 100，即所有流量从 Green 版本转向 Blue。

使用以下 canary.ingress 的 yaml 文件再创建一个基于权重的 Canary 版本的应用路由 (Ingress)。

注意：要开启灰度发布机制，首先需设置 nginx.ingress.kubernetes.io/canary: "true" 启用 Canary，以下 Ingress 示例的 Canary 版本使用了基于权重进行流量切分的 annotation 规则，将分配 30% 的流量请求发送至 Canary 版本。

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: canary

  namespace: ns-myapp

  annotations:

    kubernetes.io/ingress.class: nginx

    nginx.ingress.kubernetes.io/canary: "true"

    nginx.ingress.kubernetes.io/canary-weight: "30"

spec:

  rules:

  - host: ingress.test.com

    http:

      paths:

      - backend:

          serviceName: canary

          servicePort: 80

接下来在命令行中使用如下命令访问域名 ingress.test.com 100次，计算每个版本分配流量的占比：

c=0;p=0;for i in $(seq 100); do result=$(curl -s ingress.test.com | grep  Hostname | awk -F: '{print $2}'); [[ ${result} =~ ^[[:space:]]canary ]] && let c++ || let p++; done;echo "production:${p}; canary:${c};"

可以得到如下结果：

production:73; canary:28;

四、基于用户请求的 Canary 规则测试

1. 基于 Resquest Header

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

给 Canary 版本的 Ingress 新增一条 annotation ：nginx.ingress.kubernetes.io/canary-by-header: canary（这里的 annotation 的 value 可以是任意值），使当前的 Ingress 实现基于 Request Header 进行流量切分。

将 Canary 版本 Ingress 的 yaml 文件修改为如下内容：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: canary

  namespace: ns-myapp

  annotations:

    kubernetes.io/ingress.class: nginx

    nginx.ingress.kubernetes.io/canary: "true"

    nginx.ingress.kubernetes.io/canary-weight: "30"

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

spec:

  rules:

  - host: ingress.test.com

    http:

      paths:

      - backend:

          serviceName: canary

          servicePort: 80

说明：金丝雀规则按优先顺序 canary-by-header - > canary-by-cookie - > canary-weight 进行如下排序，因此上面的 ingress 将忽略原有 canary-weight 的规则。

由于上面的 ingress 规则中没有对 canary-by-header: "canary" 提供具体的值，也就是 nginx.ingress.kubernetes.io/canary-by-header-value 规则，所以在访问的时候，只可以为 canary 赋值 never 或 always，当 header 信息为 canary:never 时，请求将不会发送到 canary 版本；当 header 信息为 canary:always 时，请求将会一直发送到 canary 版本。示例如下：

[k8s-master ~ ]# curl -s -H "canary:never" ingress.test.com | grep Hostname

Hostname: production-5698c4565c-jmjn5

[k8s-master ~ ]# curl -s -H "canary:always" ingress.test.com | grep Hostname

Hostname: canary-79c899d85-992nw

也可以在上一个 annotation （即 canary-by-header）的基础上添加一条 nginx.ingress.kubernetes.io/canary-by-header-value: user-value 。用于通知 Ingress 将匹配到的请求路由到 Canary Ingress 中指定的服务。

将 Canary 版本 Ingress 的 yaml 文件修改为如下内容：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: canary

  namespace: ns-myapp

  annotations:

    kubernetes.io/ingress.class: nginx

    nginx.ingress.kubernetes.io/canary: "true"

    nginx.ingress.kubernetes.io/canary-weight: "30"

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

    nginx.ingress.kubernetes.io/canary-by-header-value: "true"

spec:

  rules:

  - host: ingress.test.com

    http:

      paths:

      - backend:

          serviceName: canary

          servicePort: 80

上面的 ingress 规则设置了 header 信息为 canary:true，也就是只有满足这个 header 值时才会路由到 canary 版本。示例如下：

[k8s-master ~ ]# curl -s ingress.test.com | grep Hostname

Hostname: production-5698c4565c-jmjn5

[k8s-master ~ ]# curl -s -H "canary:test" ingress.test.com | grep Hostname

Hostname: production-5698c4565c-jmjn5

[k8s-master ~ ]# curl -s -H "canary:true" ingress.test.com | grep Hostname

Hostname: canary-79c899d85-992nw

五、基于 Cookie 的 Canary 规则测试

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

将 Canary 版本 Ingress 的 yaml 文件修改为如下内容：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: canary

  namespace: ns-myapp

  annotations:

    kubernetes.io/ingress.class: nginx

    nginx.ingress.kubernetes.io/canary: "true"

    nginx.ingress.kubernetes.io/canary-by-cookie: "user_from_beijing"

spec:

  rules:

  - host: ingress.test.com

    http:

      paths:

      - backend:

          serviceName: canary

          servicePort: 80

访问示例如下：

[k8s-master ~ ]# curl -s -b "user_from_beijing=always" ingress.test.com | grep Hostname

Hostname: canary-79c899d85-992nw

[k8s-master ~ ]# curl -s -b "user_from_beijing=no" ingress.test.com | grep Hostname

Hostname: production-5698c4565c-jmjn5