vlambda博客
学习文章列表

1.1 生产环境如何实现蓝绿部署？
1.1.1 什么是蓝绿部署？蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的、正在运行的系统，只是系统版本和对外服务情况不同。开发新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。 蓝色系统不对外提供服务，用来做什么呢？用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统： 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。1.1.2 蓝绿部署的优势和缺点优点：1、更新过程无需停机，风险较少2、回滚方便，只需要更改路由或者切换DNS服务器，效率较高缺点：1、成本较高，需要部署两套环境。如果新版本中基础服务出现问题，会瞬间影响全网用户；如果新版本有问题也会影响全网用户。2、需要部署两套机器，费用开销大3、在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险4、负载均衡器/反向代理/路由/DNS处理不当，将导致流量没有切换过来情况出现
实战1：通过k8s实现线上业务的蓝绿部署
下面实验需要的镜像包在课件，把镜像压缩包上传到k8s的各个工作节点，docker load -i解压：docker load -i myapp-lan.tar.gzdocker load -i myapp-lv.tar.gz
Kubernetes不支持内置的蓝绿部署。目前最好的方式是创建新的deployment，然后更新应用程序的service以指向新的deployment部署的应用
1.创建蓝色部署环境（新上线的环境，要替代绿色环境）
下面步骤在k8s的控制节点操作：
kubectl create ns blue-green
cat lan.yaml
然后可以使用kubectl命令创建部署。kubectl apply -f lan.yaml
验证部署是否成功:kubectl get pods -n blue-green
显示如下：NAME READY STATUS RESTARTS AGEmyapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 53smyapp-v1-67fd9fc9c8-24tbp 1/1 Running 0 53smyapp-v1-67fd9fc9c8-cw59c 1/1 Running 0 53s
2.创建绿色部署环境（原来的部署环境）cat  lv.yaml
可以使用kubectl命令创建部署。kubectl apply -f lv.yaml
创建前端servicecat service_lanlv.yaml 
更新服务：kubectl apply -f service_lanlv.yaml
在浏览器访问http://k8s-master节点ip:30062 显示如下： 
修改service_lanlv.yaml 配置文件，修改标签，让其匹配到蓝程序（升级之后的程序） cat service_lanlv.yaml
更新资源清单文件：kubectl apply -f service_lanlv.yaml在浏览器访问http://k8s-master节点ip:30062 显示如下： 
实验完成之后，把资源先删除，以免影响后面实验：kubectl delete -f lan.yamlkubectl delete -f lv.yamlkubectl delete -f service_lanlv.yaml
1.2 通过k8s实现滚动更新-滚动更新流程和策略1.2.1 滚动更新简介滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义），例如第一批1台，第二批10%，第三批50%，第四批100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 
1.2.2 在k8s中实现金滚动更新首先看下Deployment资源对象的组成：kubectl explain deploymentkubectl explain deployment.specKIND: DeploymentVERSION: apps/v1RESOURCE: spec <Object>DESCRIPTION: Specification of the desired behavior of the Deployment. DeploymentSpec is the specification of the desired behavior of the Deployment.FIELDS: minReadySeconds <integer> Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready) paused <boolean> Indicates that the deployment is paused.#暂停，当我们更新的时候创建pod先暂停，不是立即更新 progressDeadlineSeconds <integer> The maximum time in seconds for a deployment to make progress before it is considered to be failed. The deployment controller will continue to process failed deployments and a condition with a ProgressDeadlineExceeded reason will be surfaced in the deployment status. Note that progress will not be estimated during the time a deployment is paused. Defaults to 600s. replicas <integer> Number of desired pods. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1. revisionHistoryLimit <integer>#保留的历史版本数，默认是10个 The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10. selector <Object> -required- Label selector for pods. Existing ReplicaSets whose pods are selected by this will be the ones affected by this deployment. It must match the pod template's labels. strategy <Object>#更新策略，支持的滚动更新策略 The deployment strategy to use to replace existing pods with new ones. template <Object> -required- Template describes the pods that will be created.
kubectl explain deploy.spec.strategyKIND: DeploymentVERSION: apps/v1RESOURCE: strategy <Object>DESCRIPTION: The deployment strategy to use to replace existing pods with new ones. DeploymentStrategy describes how to replace existing pods with new ones.FIELDS: rollingUpdate <Object> Rolling update config params. Present only if DeploymentStrategyType = RollingUpdate. type <string> Type of deployment. Can be "Recreate" or "RollingUpdate". Default is RollingUpdate.#支持两种更新，Recreate和RollingUpdate #Recreate是重建式更新，删除一个更新一个 #RollingUpdate 滚动更新，定义滚动更新的更新方式的，也就是pod能多几个，少几个，控制更新力度的
kubectl explain deploy.spec.strategy.rollingUpdateKIND: DeploymentVERSION: apps/v1RESOURCE: rollingUpdate <Object>DESCRIPTION: Rolling update config params. Present only if DeploymentStrategyType = RollingUpdate. Spec to control the desired behavior of rolling update.FIELDS: maxSurge <string> The maximum number of pods that can be scheduled above the desired number of pods. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up. Defaults to 25%. Example: when this is set to 30%, the new ReplicaSet can be scaled up immediately when the rolling update starts, such that the total number of old and new pods do not exceed 130% of desired pods. Once old pods have been killed, new ReplicaSet can be scaled up further, ensuring that total number of pods running at any time during the update is at most 130% of desired pods.
#我们更新的过程当中最多允许超出的指定的目标副本数有几个； 它有两种取值方式，第一种直接给定数量，第二种根据百分比，百分比表示原本是5个，最多可以超出20%，那就允许多一个，最多可以超过40%，那就允许多两个 maxUnavailable <string> The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set to 30%, the old ReplicaSet can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old ReplicaSet can be scaled down further, followed by scaling up the new ReplicaSet, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.#最多允许几个不可用假设有5个副本，最多一个不可用，就表示最少有4个可用
deployment是一个三级结构，deployment控制replicaset，replicaset控制pod，例子：用deployment创建一个pod cat deploy-demo.yaml
更新资源清单文件：kubectl apply -f deploy-demo.yaml
查看deploy状态：kubectl get deploy -n blue-green
显示如下：NAME READY UP-TO-DATE AVAILABLE AGEmyapp-v1 2/2 2 2 60s
创建的控制器名字是myapp-v1 kubectl get rs -n blue-green 显示如下：AME DESIRED CURRENT READY AGEmyapp-v1-67fd9fc9c8 2 2 2 2m35s
创建deploy的时候也会创建一个rs（replicaset），67fd9fc9c8 这个随机数字是我们引用pod的模板template的名字的hash值 
kubectl get pods -n blue-green
显示如下：NAME READY STATUS RESTARTS AGEmyapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 3m23smyapp-v1-67fd9fc9c8-np57d 1/1 Running 0 3m23s
通过deployment管理应用，在更新的时候，可以直接编辑配置文件实现，比方说想要修改副本数，把2个变成3个 cat deploy-demo.yaml 直接修改replicas数量，如下，变成3spec: replicas: 3
修改之后保存退出，执行kubectl apply -f deploy-demo.yaml 
注意：apply不同于create，apply可以执行多次；create执行一次，再执行就会报错有重复。kubectl get pods -n blue-green显示如下：NAME READY STATUS RESTARTS AGEmyapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 8m18smyapp-v1-67fd9fc9c8-4bv5n 1/1 Running 0 8m18smyapp-v1-67fd9fc9c8-cw59c 1/1 Running 0 18s
上面可以看到pod副本数变成了3个 
#查看myapp-v1这个控制器的详细信息kubectl describe deploy myapp-v1 -n blue-green#显示如下：Name: myapp-v1Namespace: blue-greenCreationTimestamp: Sun, 21 Mar 2021 18:46:52 +0800Labels: <none>Annotations: deployment.kubernetes.io/revision: 1Selector: app=myapp,version=v1Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableStrategyType: RollingUpdate#默认的更新策略rollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surge#最多允许多25%个pod，25%表示不足一个，可以补一个Pod Template: Labels: app=myapp version=v1 Containers: myapp: Image: janakiramm/myapp:v1 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none>Conditions: Type Status Reason ---- ------ ------ Progressing True NewReplicaSetAvailable Available True MinimumReplicasAvailableOldReplicaSets: <none>NewReplicaSet: myapp-v1-67fd9fc9c8 (3/3 replicas created)Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 3m26s deployment-controller Scaled down replica set myapp-v1-67fd9fc9c8 to 2 Normal ScalingReplicaSet 2m1s (x2 over 10m) deployment-controller Scaled up replica set myapp-v1-67fd9fc9c8 to 3
例子：测试滚动更新在终端执行如下：
kubectl get pods -l app=myapp -n blue-green -w 
打开一个新的终端窗口更改镜像版本，按如下操作： vim deploy-demo.yaml
把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2
保存退出，执行 
kubectl apply -f deploy-demo.yaml 
再回到刚才监测的那个窗口，可以看到信息如下：
NAME READY STATUS RESTARTS AGEmyapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 22mmyapp-v1-67fd9fc9c8-4bv5n 1/1 Running 0 22mmyapp-v1-67fd9fc9c8-cw59c 1/1 Running 0 14mmyapp-v1-75fb478d6c-24tbp 0/1 Pending 0 0smyapp-v1-75fb478d6c-24tbp 0/1 Pending 0 0smyapp-v1-75fb478d6c-24tbp 0/1 ContainerCreating 0 0smyapp-v1-75fb478d6c-24tbp 1/1 Running 0 11smyapp-v1-67fd9fc9c8-cw59c 1/1 Terminating 0 15mmyapp-v1-75fb478d6c-f52l6 0/1 Pending 0 0smyapp-v1-75fb478d6c-f52l6 0/1 Pending 0 0smyapp-v1-75fb478d6c-f52l6 0/1 ContainerCreating 0 0smyapp-v1-67fd9fc9c8-cw59c 0/1 Terminating 0 15mmyapp-v1-75fb478d6c-f52l6 1/1 Running 0 11smyapp-v1-67fd9fc9c8-4bv5n 1/1 Terminating 0 23mmyapp-v1-75fb478d6c-jlw28 0/1 Pending 0 0smyapp-v1-75fb478d6c-jlw28 0/1 Pending 0 0smyapp-v1-75fb478d6c-jlw28 0/1 ContainerCreating 0 0smyapp-v1-75fb478d6c-jlw28 1/1 Running 0 1s
pending表示正在进行调度，ContainerCreating表示正在创建一个pod，running表示运 行一个pod，running起来一个pod之后再Terminating（停掉）一个pod，以此类推，直 到所有pod完成滚动升级
在另外一个窗口执行kubectl get rs -n blue-green显示如下：NAME DESIRED CURRENT READY AGEmyapp-v1-75fb478d6c 3 3 3 2m7smyapp-v1-67fd9fc9c8 0 0 0 25m
上面可以看到rs有两个，下面那个是升级之前的，已经被停掉，但是可以随时回滚 
kubectl rollout history deployment myapp-v1 -n blue-green
查看myapp-v1这个控制器的滚动历史，显示如下：deployment.apps/myapp-v1 REVISION CHANGE-CAUSE1 <none>2 <none>
回滚操作如下： kubectl rollout undo
1.2.3 自定义滚动更新策略maxSurge和maxUnavailable用来控制滚动更新的更新策略取值范围数值1. maxUnavailable: [0, 副本数]2. maxSurge: [0, 副本数]注意：两者不能同时为0。比例1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；注意：两者不能同时为0。建议配置1. maxUnavailable == 02. maxSurge == 1这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。
总结：maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
自定义策略：修改更新策略：maxUnavailable=1，maxSurge=1 kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}' -n blue-green
查看myapp-v1这个控制器的详细信息kubectl describe deployment myapp-v1 -n blue-green
显示如下：RollingUpdateStrategy: 1 max unavailable, 1 max surge
上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge 这个rollingUpdate更新策略变成了刚才设定的，因为我们设定的pod副本数是3，1和1表示最少不能少于2个pod，最多不能超过4个pod 这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的
1.3 通过k8s完成线上业务的金丝雀发布1.3.1 金丝雀发布简介金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。 金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试）。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。 如果金丝测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
 优点：灵活，策略自定义，可以按照流量或具体的内容进行灰度(比如不同账号，不同参数)，出现问题不会影响全网用户缺点：没有覆盖到所有的用户导致出现问题不好排查
1.3.2 在k8s中实现金丝雀发布打开一个标签1监测更新过程 kubectl get pods -l app=myapp -n blue-green -w
打开另一个标签2执行如下操作： kubectl set image deployment myapp-v1 myapp=janakiramm/myapp:v2 -n blue-green && kubectl rollout pause deployment myapp-v1 -n blue-green
回到标签1观察，显示如下：NAME READY STATUS RESTARTS AGEmyapp-v1-67fd9fc9c8-5fd2f 1/1 Running 0 86smyapp-v1-67fd9fc9c8-92mdr 1/1 Running 0 86smyapp-v1-75fb478d6c-wddds 0/1 Pending 0 0smyapp-v1-75fb478d6c-wddds 0/1 Pending 0 0smyapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 0smyapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 1smyapp-v1-75fb478d6c-wddds 1/1 Running 0 2s
注：上面的解释说明把myapp这个容器的镜像更新到janakiramm/myapp:v2版本 更新镜像之后，创建一个新的pod就立即暂停，这就是我们说的金丝雀发布；如果暂停几个小时之后没有问题，那么取消暂停，就会依次执行后面步骤，把所有pod都升级。
解除暂停：回到标签1继续观察：
打开标签2执行如下：kubectl rollout resume deployment myapp-v1 -n blue-green在标签1可以看到如下一些信息，下面过程是把余下的pod里的容器都更的版本：NAME READY STATUS RESTARTS AGEmyapp-v1-67fd9fc9c8-5fd2f 1/1 Running 0 86smyapp-v1-67fd9fc9c8-92mdr 1/1 Running 0 86smyapp-v1-75fb478d6c-wddds 0/1 Pending 0 0smyapp-v1-75fb478d6c-wddds 0/1 Pending 0 0smyapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 0smyapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 1smyapp-v1-75fb478d6c-wddds 1/1 Running 0 2smyapp-v1-67fd9fc9c8-92mdr 1/1 Terminating 0 10mmyapp-v1-75fb478d6c-z6f5z 0/1 Pending 0 0smyapp-v1-75fb478d6c-z6f5z 0/1 Pending 0 0smyapp-v1-75fb478d6c-z6f5z 0/1 ContainerCreating 0 0smyapp-v1-75fb478d6c-z6f5z 0/1 ContainerCreating 0 1smyapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10mmyapp-v1-75fb478d6c-z6f5z 1/1 Running 0 2smyapp-v1-67fd9fc9c8-5fd2f 1/1 Terminating 0 10mmyapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10mmyapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10mmyapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10mmyapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10mmyapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10m
kubectl get rs -n blue-green可以看到replicaset控制器有2个了NAME DESIRED CURRENT READY AGEmyapp-v1-67fd9fc9c8 0 0 0 13mmyapp-v1-75fb478d6c 2 2 2 7m28s
回滚：如果发现刚才升级的这个版本有问题可以回滚，查看当前有哪几个版本： kubectl rollout history deployment myapp-v1 -n blue-green显示如下：deployment.apps/myapp-v1 REVISION CHANGE-CAUSE1 <none>2 <none>上面说明一共有两个版本，回滚的话默认回滚到上一版本，可以指定参数回滚：kubectl rollout undo deployment myapp-v1 -n blue-green --to-revision=1#回滚到的版本号是1kubectl rollout history deployment myapp-v1 -n blue-green显示如下：deployment.apps/myapp-v1 REVISION CHANGE-CAUSE2 <none>3 <none>上面可以看到第一版没了，被还原成了第三版，第三版的前一版是第二版kubectl get rs -n blue-green -o wide 显示如下：NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORmyapp-v1-67fd9fc9c8 2 2 2 18m myapp janakiramm/myapp:v1 app=myapp,pod-template-hash=67fd9fc9c8,version=v1myapp-v1-75fb478d6c 0 0 0 12m myapp janakiramm/myapp:v2 app=myapp,pod-template-hash=75fb478d6c,version=v1
以看到上面的rs已经用第一个了，这个就是还原之后的rs
实战2：七层调度器Ingress Controller安装和配置

实战3：通过Ingress-nginx实现灰度发布
Ingress-Nginx是一个K8S ingress工具，支持配置Ingress Annotations来实现不同场景下的灰度发布和测试。 Nginx Annotations 支持以下几种Canary规则：
假设我们现在部署了两个版本的服务，老版本和canary版本
nginx.ingress.kubernetes.io/canary-by-header：基于Request Header的流量切分，适用于灰度发布以及 A/B 测试。当Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。
nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为60意味着60%流量转到canary。权重为 100 意味着所有请求都将被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口。
部署服务：这里我们服务的 deployment 就不展示了，service 配置如下：# 测试版本apiVersion: v1kind: Servicemetadata: name: hello-service labels: app: hello-servicespec:ports:- port: 80 protocol: TCPselector: app: hello-service# canary 版本apiVersion: v1kind: Servicemetadata: name: canary-hello-service labels: app: canary-hello-servicespec:ports:- port: 80 protocol: TCPselector: app: canary-hello-service
根据权重转发：ingress 配置如下：apiVersion: extensions/v1beta1kind: Ingressmetadata: name: canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "30"spec: rules: - host: canary-service.abc.com http: paths: - backend: serviceName: canary-hello-service  servicePort: 80测试结果如下：$ for i in $(seq 1 10); do curl http://canary-service.abc.com; echo '\n'; done
hello world-version1hello world-version1hello world-version2hello world-version2hello world-version1hello world-version1hello world-version1hello world-version1hello world-version1hello world-version1根据请求头转发：annotation 配置如下（ingress 其余部分省略）annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "test"测试结果如下：$ for i in $(seq 1 5); do curl -H 'test:always' http://canary-service.abc.com; echo '\n'; donehello world-version1hello world-version1hello world-version1hello world-version1hello world-version1$ for i in $(seq 1 5); do curl -H 'test:abc' http://canary-service.abc.com; echo '\n'; donehello world-version2hello world-version2hello world-version2hello world-version2hello world-version2根据cookie转发：使用cookie来进行流量管理的场景比较适合用于A/B test，比如用户的请求 cookie 中含有特殊的标签，那么我们可以把这部分用户的请求转发到特定的服务进行处理。annotation 配置如下: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-cookie: "like_music"测试结果如下：$ for i in $(seq 1 5); do curl -b 'like_music=1' http://canary-service.abc.com; echo '\n'; donehello world-version1hello world-version1hello world-version1hello world-version1hello world-version1$ for i in $(seq 1 5); do curl -b 'like_music=always' http://canary-service.abc.com; echo '\n'; donehello world-version2hello world-version2hello world-version2hello world-version2hello world-version2三种annotation按如下顺序匹配canary-by-header > canary-by-cookie > canary-weight