K8S之实现业务的金丝雀发布
金丝雀发布的由来:17 世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;当瓦斯含量超过一定限度时,虽然人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为瓦斯检测指标,以便在危险状况下紧急撤离。金丝雀发布(又称灰度发布、灰度更新):一般先发1台,或者一个小比例,例如2%的服务器,主要做流量验证
如何实现金丝雀发布
金丝雀发布简介
金丝雀发布的由来: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个了
更多推荐
所有评论(0)