Google Kubernetes引擎上使用Istio简化微服务 — 第III部分
作者：Nithin Mallya
翻译：狄卫华
原文：Simplifying Microservices with Istio in Google Kubernetes Engine — Part III
本系列翻译链接：
我所写的关于 Istio 的文章是 Istio 非常棒的官方文档 中的一部分。如果想了解更多，请阅读官方文档。
在本系列的 Part I 中，我们看到如何使用 Istio 来简化我们的微服务之间的通信。
在本系列的 Part II 中，我们学会了使用 Istil egress 规则来控制访问服务网格外面的服务。
在这个部分，我们将会看到如何实现金丝雀（Canary）发布和使用 Istio 进行流量迁移。
背景知识： 在以前的文章中，我详细解释了我们如何使用 Kubernets 实现蓝绿（Blue/Green）发布。通过蓝绿发布可以让我们在相同的生产环境中部署应用的当前版本和一个新的版本，通过零宕机部署（ Zero Downtime Deployments）来保证用户不会在我们切换新版本的时候受到影响。系统中同时存在两个版本（当前版本和新版本）也可以让我在新版本遇到问题的时候，能够回滚到当前的版本。
与此同时，我们也需要一种机制能够将流量引入（或者停止）到我们新版本的应用，同时监控是否有不利的影响。金丝雀部署或发布（Canary）则可以实现这一目的。
不太有趣的事实：当矿工进入矿场时带着金丝雀。 任何有毒气体首先会杀死金丝雀，从而警告他们离开矿区。
同样在程序部署方面，通过金丝雀部署，我们可以将新版本的程序部署到生产环境中，并仅向该新部署的版本发送一小部分流量。 这个新版本将与当前版本并行运行，我们则能够在将所有流量切换到新版本之前的任何问题提前发现。
例如：我们的应用 v1 版本可以占据 90％ 的流量，而v2版本可以占据其他 10％。 如果一切运行正常，我们可以将v2 版本流量增加到 25％，50％，最终达到 100％。 Istio 金丝雀部署的另一个优点是我们可以根据请求中的自定义头部信息增加流量。 例如将具有特定 cookie 标头值的流量的 10％ 至我们应用的v2版本。
注意：尽管金丝雀部署 “可以” 与A / B测试结合使用，用来了解用户如何从业务度量标准角度对新版本做出反应，但真正的动机是确保应用程序从功能角度满足需求。 此外，企业所有者可能希望运行A / B测试活动的时间更长（例如：许多天甚至几周），而不是金丝雀部署可能需要的时间。 因此将它们分开是明智的做法。
实际操作
我们从 Part I 中了解到，我们的 PetService 与 PetDetailsService（v1）和 PetMedicalHistoryService（v1）进行通信。 调用PetService的输出如下所示：
1 | $ curl http://108.59.82.93/pet/123 |
在上面的响应消息中，你会注意到宠物品种（petBreed）对应的值是 “Dog”。 然而 Maximus 恰好是 “German Shepherd Dog” （德国牧羊犬），我们需要修改 PetDetailsService，以便正确返回品种。
所以我们现在创建 PetDetailsService的 v2 版本，它将返回 “German Shepherd Dog”。 同时我们希望确保将所有流量推送到v2之前，让一小部分用户测试此 v2 版本的服务。
在下面的图1中，我们将流量配置为 50％ 的请求发送到 v1 和 50％ 至v2，即我们的金丝雀部署署（它可以是任何数字比例，具体取决于我们修改范围大小，并尽量减少任何负面影响）。
图1 我们采用金丝雀部署方式部署 PetDetailsService v2版本并迁移流量
步骤
创建 PetDetailsService v2 版本并像以前一样进行部署（参见 petdetailservice/kube 目录下的 petinfo.yaml）
1
2
3
4
5
6$ kubectl get pods
NAME READY STATUS RESTARTS AGE
petdetailsservice-v1-2831216563-qnl10 2/2 Running 0 19h
petdetailsservice-v2-2943472296-nhdxt 2/2 Running 0 2h
petmedicalhistoryservice-v1-28468096-hd7ld 2/2 Running 0 19h
petservice-v1-1652684438-3l112 2/2 Running 0 19h
创建 RouteRule 分流 petdetailsservice 50%的请求至 v1 版本，50%的请求至 v2，如下所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20$ cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: petdetailsservice-default
spec:
destination:
name: petdetailsservice
route:
- labels:
version: v1
weight: 50
- labels:
version: v2
weight: 50
EOF
$ istioctl get routerule
NAME KIND NAMESPACE
petdetailsservice-default RouteRule.v1alpha2.config.istio.io default- 现在，如果我们访问PetService，就应该看到替代请求分别返回 “Dog” 和 “German Shepherd Dog”，如下所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29$ curl http://108.59.82.93/pet/123
{
"petDetails": {
"petName": "Maximus",
"petAge": 5,
"petOwner": "Nithin Mallya",
"petBreed": "Dog"
},
"petMedicalHistory": {
"vaccinationList": [
"Bordetella, Leptospirosis, Rabies, Lyme Disease"
]
}
}
$ curl http://108.59.82.93/pet/123
{
"petDetails": {
"petName": "Maximus",
"petAge": 5,
"petOwner": "Nithin Mallya",
"petBreed": "German Shepherd Dog"
},
"petMedicalHistory": {
"vaccinationList": [
"Bordetella, Leptospirosis, Rabies, Lyme Disease"
]
}
}已经可以正常工作。
这引出了一个问题：我们不能用 Kubernetes 金丝雀部署 来做到这一点吗？ 简短的答案是肯定的。
但是，步骤涉及更多并且存在限制：
仍然可以创建 2 个 PetDetailsService 部署（v1和v2），但需要在部署期间手动限制 v2 副本的数量，以维持v1：v2 比例，例如可以使用 10 个副本部署 v1，并使用2个副本部署 v2 以实现 10:2 负载平衡。
由于所有的 pod 无论版本是否相同会被同样对待，Kubernetes集群中的流量负载平衡仍然受到随机性的影响。
基于流量的自动扩容也会遇到问题，因为我们需要单独自动缩放2个部署，这些部署可以根据每个服务的流量负载分布来表现不一致。
如果我们想根据某些标准（例如请求头部信息）为某些用户允许/限制流量，则基于Kubernetes金丝雀部署 可能无法实现此目的。
结论：您刚刚看到创建Canary部署以及使用 Istio 控制流量是多么容易。 而且 Maximus 也很开心！
资源
- 本系列 Part I : https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-i-849555f922b8
- 本系列 Part I : https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-ii-7461b1833089
- Istio网站 https://istio.io/
- DevOxx Istio 展示 Ray Tsang: https://www.youtube.com/watch?v=AGztKw580yQ&t=231s
- 样例的 Github 地址: https://github.com/nmallya/istiodemo
- Kubernetes: https://kubernetes.io/
除特别声明本站文章均属原创（翻译内容除外），如需要转载请事先联系，转载需要注明作者原文链接地址。