概述除了服务发现、顶层指标和TLS，linkerd 也提供一种称为dtabs的强大的路由语言，它可以更改应用拓扑中的请求，甚至是单独某个请求的请求路径。本文中，我们会给您展示如何使用linkerd作为服务网格对新代码进行CI/CD管道最后一步的蓝绿发布。
注意：这是关于Linkerd、Kubernetes和service mesh的系列文章其中一篇，其余部分包括：
1.Top-line service metrics
2.Pods are great, until they’re not
3.Encrypting all the things
4.Continuous deployment via traffic shifting(本文)
5.Dogfood environments, ingress, and edge routing
6.Staging microservices without the tears
7.Distributed tracing made easy
8.Linkerd as an ingress controller
9.gRPC for fun and profit
10.The Service Mesh API
11.Egress
12.Retry budgets, deadline propagation, and failing gracefully
13.Autoscaling by top-line metrics
这个系列之前的安装，我们已经示范了如果使用类似linderd这样的服务网格工具捕获顶层服务指标和透明的给应用添加TLS，而无需修改应用的代码。
本文中，你可以看到关于使用linkerd路由规则（称为dtabs）的示例——在CI/CD管道的最后一步的蓝绿部署中，在服务的新旧版本间切换请求流量。
持续部署（CD）是持续集成（CI）的一个扩展，在这个过程里，基于连续的基础设施，代码被推送到生产。这个过程是与开发过程强耦合的。当然，它依赖于高度的自动化，以求缩短开发与部署之间的时间，以便公司可以快速的迭代他们的产品。
对于多服务或是微服务架构，CD过程的最后一步部署步骤，它本身是有风险的，因为运行时环境决定着很多运行时行为，尤其生产上还跑着量。在这种情况下，类似蓝绿部署那种平滑的对外就很重要了。
在多个linkerd之间调配流量，需要一个中央的流量控制工具。我们推荐namerd，一个提供路由规则的服务，它有提供路由规则服务的API并做了持久化存储。你可以通过阅读我们之前的博文routing in linkerd来了解更多关于namerd如何与生产系统集成的信息。
我们将通过linkerd-examples github 仓库中的一个示例应用来演示蓝绿部署。这个示例程序是个”hello world”的微服务应用，由一个”hello”服务接收进来的请求，并且调用”world”服务，之后返回。Jenkins作为自动化工具，我们使用Jenkins Pipeline插件部署新版本的”world”服务。
在开始持续发布前，我们需要先初始化部署hello world应用到Kubernetes，通过linkerd和namerd路由请求。这些通过使用linkerd-examples中的Kubernetes配置很容易做到这一点。
第一步: 安装NAMERD
我们从安装namerd开始，namerd管理着dtabs，而dtabs是我们用来编排蓝绿部署的。此处请注意所用的namerd configuration使用ThirdPartyResource APIs，并依赖于Kubernetes 1.2+的集群且启用了ThirdPartyResource。
使用默认的Kubernetes namespace安装namerd，运行：
kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/namerd.yml
通过查看namerd的管理页面可以确定安装是否成功（注意需要等几分钟以便 ingress IP可用）：
NAMERD_INGRESS_LB=$(kubectl get svc namerd -o jsonpath="{.status.loadBalancer.ingress[0].*}") open http://$NAMERD_INGRESS_LB:9991 # on OS X
如果外部负载均衡对集群不可见，则使用hostIP：
NAMERD_HOST_IP=$(kubectl get po -l app=namerd -o 'jsonpath={.items[0].status.hostIP}') open http://$NAMERD_HOST_IP:$(kubectl get svc namerd -o 'jsonpath={.spec.ports[2].nodePort}') # on OS X
管理页面显示所有已配置的namerd namespace，可以看到我们已经配置了两个namespace：external和internal，针对本次技术部署，我们更多的关注internal这个namesapce。
除了管理UI，我们也会使用一个叫namerctl的工具直接与namerd交互。这个工具将用于供部署脚本调用，来切流量到新部署的服务上。本地安装运行：
go get -u github.com/linkerd/namerctl go install github.com/linkerd/namerctl
这个工具使用NAMERCTL_BASE_URL这个环境变量连接namerd，为了连到我们刚刚部署到Kubernetes的namerd的版本，设置环境变量如下：
export NAMERCTL_BASE_URL=http://$NAMERD_INGRESS_LB:4180
或者直接使用hostIP：
export NAMERCTL_BASE_URL=http://$NAMERD_HOST_IP:$(kubectl get svc namerd -o 'jsonpath={.spec.ports[1].nodePort}')
现在用namerctl来展现internal下的dtab：
$ namerctl dtab get internal # version MjgzNjk5NzI= /srv => /#/io.l5d.k8s/default/http ; /host => /srv ; /tmp => /srv ; /svc => /host ; /host/world => /srv/world-v1 ;
最后一行，dtab映射world服务的逻辑名到当前部署的world服务版本上：world-v1。在生产系统，版本号可以是摘要、日期或其它任何可以保证名字唯一的。我们用这个dtab入口把新版本的world服务安全的引入生产环境。
第二步: 安装LINKERD
下面我们就要安装linkerd并配置它使用namerd解析请求路由。安装linkerd为DaemonSet（比如每个host一个实例）在默认的Kubernetes namespace，运行：
kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd-namerd.yml
同样的，通过管理界面确定安装成功（等待几分钟以便ingress IP可用）：
L5D_INGRESS_LB=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}") open http://$L5D_INGRESS_LB:9990 # on OS X
或者如果外部的负载均衡不可见，就使用hostIP：
L5D_HOST_IP=$(kubectl get po -l app=l5d -o 'jsonpath={.items[0].status.hostIP}') open http://$L5D_HOST_IP:$(kubectl get svc l5d -o 'jsonpath={.spec.ports[3].nodePort}') # on OS X
下面的步骤中，我们依然会使用管理界面确认蓝绿部署的步骤：
第三步: 安装样例应用
现在我们要在默认的namespace下安装hello和world应用。这些应用依赖Kubernetes downward API提供的nodeName来发现Linkerd。要检查你的集群是否支持nodeName，可以运行一下这个测试job：
kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/node-name-test.yml
然后看一下日志：
kubectl logs node-name-test
如果你看到了一个IP，恭喜！继续吧，部署hello和world应用：
kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/hello-world.yml
如果你看到一句：”server can’t find …” 这样的错误，部署hello-world的原版本，那个依赖于hostIP而不是nodeName：
kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/hello-world-legacy.yml
我们实际上有个已经起作用的服务网格以及一个使用它的应用。你通过发送流量到linkerd的外部IP看到完整的安装生效了：
$ curl $L5D_INGRESS_LB Hello (10.196.2.5) world (10.196.2.6)!!
或者直接使用hostIP：
$ L5D_INGRESS_LB=$L5D_HOST_IP:$(kubectl get svc l5d -o 'jsonpath={.spec.ports[0].nodePort}') $ curl $L5D_INGRESS_LB Hello (10.196.2.5) world (10.196.2.6)!!
如果一切都正常工作了，就可以看到类似上面的“Hello world”消息，以及处理请求的pod的IP。
现在使用Jenkins去实现蓝绿部署前面已经发布的world服务。
设置JENKINS
开始部署buoyantio/jenkins-plus Docker镜像到Kubernetes集群。这个镜像提供基础jenkins镜像，并包含我们需要的kubectl 和namerd二进制文件，同时还有我们要用于部署过程的一些插件及预配置的管道。管理任务使用Jenkins Pipeline plugin和定制化Groovy脚本来处理蓝绿发布的第一个步骤。
部署Jenkins镜像到默认的Kubernetes namespace，运行：
kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/jenkins.yml
通过Jenkins的web界面可以确认安装是否成功（注意ingress IP生效需要占用几分钟时间）：
JENKINS_LB=$(kubectl get svc jenkins -o jsonpath="{.status.loadBalancer.ingress[0].*}") open http://$JENKINS_LB # on OS X
或者如果外部的负载均衡不可见，使用hostIP：
JENKINS_HOST_IP=$(kubectl get po -l app=jenkins -o 'jsonpath={.items[0].status.hostIP}') open http://$JENKINS_HOST_IP:$(kubectl get svc jenkins -o 'jsonpath={.spec.ports[0].nodePort}') # on OS X
这时应该可以在界面中看到”hello_world”任务。
提交代码
下面就该对world服务的代码做点儿修改，并用Jenkins任务把它们部署到生产环境。要做这些事情，先从fork Github上的linkerd-examples仓库开始。一旦你创建了一个fork，在本地拷贝你的fork：
git clone https://github.com/esbie/linkerd-examples.git cd linkerd-examples
针对这个示例，我们要修改控制world服务的输出的文本文件。world服务默认是输出“world”字符串：
$ cat k8s-daemonset/helloworld/world.txt world
我们来给它加点佐料：
echo "hal, open the pod bay doors" > k8s-daemonset/helloworld/world.txt
提交：
git commit -am "Improve the output of the world service" git push origin master
下面该把修改部署到生产上了。
运行这个Job
随着我们修改的提交，以及推送到linkerd-example仓库，我们开启了使用”hello_world”管道任务安全的部署更改到生产的征程。管道的所有6个步骤都使用定制开发的Groovy脚本控制，下面有更多的介绍。部署完全是自动化的，管道中的三处位置会有暂停让人工介入确认关键的指标后才能继续进行。
用参数构建
要开始部署，在Jenkins界面点击进入“hello_world”任务，然后点击侧栏的“Build with the parameter”。你会看到一个页面，在这页面上允许你自己定义部署方式，页面看起来是这样的：
修改gitRepo的值为你fork的linkerd-exampes仓库，并点击“Build”按钮。注意确定你是否已经提交了修改到单独的分支上，同时也需要修改gitBranch的值为你分支的名字。
CLONE
管道的第一步是克隆你在构建参数中指定的git仓库。
DEPLOY
第二步是把world服务的新版本部署到集群，不给它分流量。脚本确定当前部署的world服务版本是world-v1，因此它创建了一个新的称为world-v2的服务并部署到Kubernetes集群。你会看到两个版本的world服务运行着。
$ kubectl get po | grep world world-v1-9eaxk 1/1 Running 0 3h world-v1-kj6gi 1/1 Running 0 3h world-v1-vchal 1/1 Running 0 3h world-v2-65y9g 1/1 Running 0 30m world-v2-d260q 1/1 Running 0 30m world-v2-z7ngo 1/1 Running 0 30m
即便world-v2版本已经部署完了，我们也并没有对生产环境的流量做任何修改。Linkerd和namerd仍然配置为路由所有的world服务到原有的world-v1版本。在给新部署的服务导流量前完整的部署好新服务，是蓝绿发布的关键。
集成测试
一旦新版本服务部署完成，脚本会触发一个测试请求去验证新版本服务可以访问。如果测试通过，它会暂停发布过程等待我们的了解新版本是否正常。
这时候，我们要确定新的pod按期望的方式运行了——不止是它们自己跑好了，还得跟生产环境的其它部分结合好了。通常它会调用部署到一个独立的内测集群，结合一些发送或重放生产流量的机制。
既然我们使用了linkerd，那就可以显著的简化这个操作，通过利用linkerd的per-request routing特性来完成同样的事，而不必特地用一个内测（staging）环境。
Jenkins的界面上有dtab而不用关心我们需要去路由请求到新版本的服务，我们可以发起自己的请求：
$ curl -H 'l5d-dtab: /host/world => /tmp/world-v2' $L5D_INGRESS_LB Hello (10.196.2.5) hal, open the pod bay doors (10.196.1.17)!!
成功了！ 我们的请求路由到了world-v2服务，它返回了我们添加到分支上的新的world文本。虽然我们可以访问到最新的服务，但除了我们刚造的这个请求之外，不能改变任何生产的流量行为，还是没有什么意义 。
我们可以通过省略l5d-dtab头并确定我们仍然可以收到world-v1的应答。
$ curl $L5D_INGRESS_LB Hello (10.196.2.5) world (10.196.2.6)!!
如果每一件事都看起来好了，我们就点击“OK，我已经完成了人工测试”开始pipeline的下一步。
切换流量(10%)
一些人工测试之后，我们已经准备好开始蓝绿发布了，先发送10%的生产流量到新部署的新版本服务。这个脚本会修改路由策略并再次暂停，询问我们在进一步处理10%流量前，是否一切都正常。
注意如果有用户在pipeline的任何一步退出，脚本都假定新服务存在错误，并且自动回滚路由修改，把所有流量都切回到原服务。如果有我们切流量时没有下掉原有的服务，那流量切回去也是分分钟的事。
我们可以通过发送10个请求来看是否符合我们预期的10%的流量。
$ for i in {1..10}; do curl $L5D_INGRESS_LB; echo ""; done Hello (10.196.2.5) world (10.196.1.16)!! Hello (10.196.2.5) world (10.196.1.16)!! Hello (10.196.2.5) hal, open the pod bay doors (10.196.2.13)!! Hello (10.196.2.5) world (10.196.2.6)!! Hello (10.196.1.13) world (10.196.2.6)!! Hello (10.196.1.13) world (10.196.2.6)!! Hello (10.196.2.5) world (10.196.1.16)!! Hello (10.196.2.5) world (10.196.2.6)!! Hello (10.196.1.14) world (10.196.2.6)!! Hello (10.196.1.14) world (10.196.1.16)!!
看起来是好了！现在也是一个检查linkerd的管理面板的好时机，在那里可以了解新服务是否健康。如果你的应用稳定的收到一小部分流量，那面板可能会是这个样子：
切换流量(100%)
这一步，脚本会切更多的流量到新版本服务上。作为简单的例子，我们立即把流量切到100%，但在实际部署中，你可以在pipeline中分多步切不同比例的流量。
$ curl $L5D_INGRESS_LB Hello (10.196.2.5) hal, open the pod bay doors (10.196.2.13)!!
一但我们确定world-v2已经成功的处理100%的生产请求，就可以进行最后一步，点击jenkins UI上的“OK, everything looks good”。
清理
在最后一步，脚本通过把路由永久指向新版本的服务结束了发布过程。它也停用了前一版本的服务，虽然原服务仍然在集群运行着，但已经接收不到任何流量了。
$ namerctl dtab get internal # version MTIzMzU0OTE= /srv => /#/io.l5d.k8s/default/http ; /host => /srv ; /tmp => /srv ; /http/*/* => /host ; /host/world => /srv/world-v2 ;
我们可以验证老版本是否已经停用：
$ kubectl get po | grep world world-v2-65y9g 1/1 Running 0 1h world-v2-d260q 1/1 Running 0 1h world-v2-z7ngo 1/1 Running 0 1h
每一项都好着。开始一个子过程去部署world-v3版的服务，逐步切量，然后如果部署成功，就把它置为当前版本。
本文中，我们展示了一个基本的流程：整合linkerd，namerd和Jenkins在CD的pipeline的最后一个步骤从旧版本的服务向新版本服务逐量切流量。我们也展示了linkerd的分请求路由的能力，可以帮助我们预跑新版本服务而无需独立出一个staging集群——通过使用l5d-dtab头把新的服务加到生产的拓扑接收请求。
最后，我们展示了如何做基于百分比的流量切换，可以集成到jenkins的输入步骤，允许人为交互的把流量从0%增长到100%。
这是个很简单的例子，但我们希望它能够演示基本的在CD中使用service mesh路由的模式，以及提供一个模板可供定制应用于你们自己的组织的工作流中。
本文转自kubernetes中文社区-Kubernetes的service mesh – 第四部分：通过流量切换持续部署
