金丝雀发布简介

金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。
金丝雀发布（又称灰度发布、灰度更新）：一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试）。

简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。 如果金丝测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

优缺点

优点：灵活，策略自定义，可以按照流量或具体的内容进行灰度(比如不同账号，不同参数)，出现问题不会影响全网用户
缺点：没有覆盖到所有的用户导致出现问题不好排查

在k8s中实现金丝雀发布

实践描述：
一个服务部署6个pod，更新了部分pod里服务的版本：用的新的代码做的镜像，通过测试再更新剩余的。

1、创建资源

vim  myapp.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: canary
spec:
  replicas: 6
  selector:
   matchLabels:
    app: myapp
  template:
   metadata:
    labels:
     app: myapp
   spec:
    containers:
    - name: myapp-container
      image: janakiramm/myapp:v1
      imagePullPolicy: IfNotPresent
      ports:
      - containerPort: 80

在终端1更新服务并监测更新过程

kubectl apply -f myapp.yaml

kubectl get pods -l app=myapp -n canary -w

2、开始升级一个服务
打开另一个终端2执行如下操作：

kubectl set image deployment myapp myapp-container=janakiramm/myapp:v2  -n canary && kubectl rollout pause deployment myapp -n canary

回到终端1观察，显示如下：

注：上面的解释说明把myapp-container这个容器的镜像更新到janakiramm/myapp:v2版本 ，更新镜像之后，创建3个新的pod就立即暂停；
如果暂停几个小时之后没有问题，那么取消暂停，就会依次执行后面步骤，把所有pod都升级。

3、解除暂停，升级剩余服务

打开终端2执行如下

kubectl rollout resume deployment myapp -n canary

回到终端1继续观察

在终端1可以看到执行后是把余下的pod里的容器都更的版本

kubectl get rs -n canary

可以看到replicaset控制器有2个了